멀티모달 에이전트가 25번 도구를 써도 답을 찾을까: AgentVista

AgentVista는 사진 한 장의 정답률이 아니라 현실적인 시각 자료를 조사, 확대, 검색, 코드 처리하며 25턴 넘게 해결하는 능력을 평가하고, 최고 설정도 27.3%에 머물렀다고 보고합니다. 이 결과는 긴 도구 연쇄에서 작은 관측 오류가 계획 전체로 번지는 문제를 보여 줍니다. 제품에서는 최종 정답뿐 아니라 첫 오류, 도구 비용, 근거 회수와 중단 행동을 함께 평가해야 합니다.

25개 하위 도메인과 7개 범주가 어려운 이유

문항은 정돈된 교과서 그림보다 노이즈가 있는 배선 사진, 복잡한 대중교통 노선도, 세부 요소가 많은 UI처럼 현실에 가까운 시각 자료를 사용합니다. 25개 하위 도메인을 7개 범주로 묶어 한 종류의 이미지 인식 능력만으로 높은 점수를 얻기 어렵게 구성합니다.

문제를 푸는 동안 웹, 이미지 검색, 페이지 탐색, 코드 기반 이미지 처리 같은 도구를 함께 사용합니다. 작은 글자를 보기 위해 이미지를 자르거나 대비를 높이고, 찾은 문서와 원본 사진을 대조하는 식입니다. 정답을 아는 모델보다 어떤 추가 증거가 필요한지 판단하는 에이전트를 시험합니다.

긴 도구 연쇄에서는 어디서 무너지나

어려운 사례는 도구 호출과 계획 수정을 25턴 이상 요구합니다. 초반 검색어가 틀리거나 잘못된 이미지 영역을 확대한 경우, 이후 단계는 잘못된 관측을 근거로 이어질 수 있습니다. 최종 오답만 세면 인식, 검색, 코드, 계획 중 어느 단계가 원인인지 알 수 없습니다.

평가할 때는 첫 잘못된 행동, 같은 도구의 반복 호출, 유효한 근거를 찾은 뒤 결론까지 이어졌는지를 기록해야 합니다. 최종 정확도와 별도로 경로 성공률을 두면 모델 교체가 필요한지, 도구 인터페이스를 고쳐야 하는지 구분하기 쉽습니다.

27.3%는 어떤 조건의 결과인가

논문은 도구를 제공한 Gemini-3-Pro 설정의 전체 정확도를 27.3%로 보고합니다. 이는 해당 모델, 도구, 문항과 채점 조건의 결과이며 모든 멀티모달 업무의 성공률이 27.3%라는 뜻은 아닙니다. 반대로 기존 단발성 벤치마크 점수가 높다는 이유로 장기 작업도 성공한다고 가정할 수도 없습니다.

재현할 때는 정확도와 함께 평균 턴 수, 토큰, 실행 코드 수, 검색 호출 수, 총 지연을 공개해야 합니다. 25턴의 정답 하나가 짧은 오답보다 비싸므로 업무의 오류 비용과 응답 시간에 따라 허용 전략이 달라집니다.

제품 평가에는 작은 실패 세트를 먼저 쓴다

AgentVista 전체를 매번 실행하기 어렵다면 실제 제품에서 자주 틀리는 시각 자료 20~50개를 골라 축소 평가를 만들 수 있습니다. 원본 확대, 문서 검색, 계산처럼 필요한 도구를 명시하고 각 단계의 성공 조건을 둡니다. 모델이 도구 결과를 인용했는지와 근거 없는 결론을 냈는지도 검사합니다.

이 벤치마크는 현재 에이전트의 한계를 드러내는 진단 도구이지, 90점에 도달해야만 모든 제품을 만들 수 있다는 기준은 아닙니다. 자동 실행 범위는 성공률이 충분한 하위 작업으로 제한하고, 긴 경로에는 중간 승인과 중단 조건을 남겨야 합니다.

arXiv 논문, 논문 페이지

문항 난이도는 어떤 단계에서 생기나

작은 글자를 읽는 문제는 단순 OCR처럼 보이지만 어느 영역을 확대할지, 방향을 바로잡을지, 표와 범례를 연결할지가 먼저 필요합니다. 노선도는 색과 선을 인식한 뒤 환승 규칙을 계산해야 하고, 배선 사진은 부품 식별과 안전 지식을 외부 문서에서 찾아야 할 수 있습니다. 한 점수 안에 perception, retrieval, reasoning이 섞입니다.

따라서 실패를 문항 범주만으로 나누는 것으로는 부족합니다. 원본에서 필요한 region을 찾았는지, preprocessing으로 정보가 개선됐는지, 검색어가 올바른 개념을 담았는지, 찾은 source를 결론에 사용했는지를 단계별 label로 둡니다. Model이 이미 충분한 시각 근거를 갖고도 불필요하게 web을 검색하는 경우도 효율 실패입니다.

긴 trajectory가 필요한 문항과 agent가 헤매서 길어진 문항도 구분합니다. 정답 agent의 최소 유효 경로를 사람이 대략 표시하고, 반복 호출과 되돌아간 step을 세면 계획 품질을 볼 수 있습니다. 단순한 평균 턴 감소가 필요한 증거를 생략하는 shortcut이 아닌지 정확도와 함께 봅니다.

도구 interface는 어떻게 평가를 바꾸나

Crop 도구가 좌표를 어떤 기준으로 받는지, image search가 thumbnail만 돌려주는지, browser가 동적 page를 읽는지에 따라 같은 model도 결과가 달라집니다. Tool description과 output schema, error message를 평가 환경에 포함해야 model 비교가 공정합니다.

이미지 처리 코드는 sandbox에서 제한된 library와 자원만 사용하게 하고 생성 파일을 trajectory에 연결합니다. Code가 실행됐다는 사실보다 출력 image가 실제로 대비나 확대를 개선했는지 확인합니다. 실패한 code를 model이 수정하는 능력과 무한 반복을 막는 limit도 필요합니다.

Web 검색 결과에는 URL, 제목, 날짜와 발췌문을 남깁니다. Model이 검색 snippet만 보고 결론을 내리는지 본문을 열어 확인하는지 구분하고, 출처가 없는 주장은 별도 오류로 표시합니다. Search engine 결과가 바뀔 수 있으므로 benchmark 재현에는 snapshot 또는 query 시각이 필요합니다.

trajectory는 어떤 기준으로 채점할까

최종 정답 점수 외에 evidence acquisition, tool efficiency, recovery, grounding의 네 축을 둘 수 있습니다. 필요한 image region과 source를 찾았는지, 중복 호출이 얼마나 있었는지, 잘못된 시도 뒤 계획을 바꿨는지, 최종 문장이 근거를 따르는지 평가합니다.

첫 오류만 찾으면 downstream 실패를 설명하기 좋지만 이후 recovery 능력을 놓칠 수 있습니다. 첫 오류와 마지막으로 올바른 경로에 복귀한 step을 함께 기록합니다. 초반 OCR이 틀렸어도 source 대조로 고친 agent는 처음부터 맞았지만 근거 없이 답한 agent와 다른 강점을 보입니다.

정답을 모르는 상태에서 “완료”를 선언하는 calibration도 중요합니다. 근거가 부족하면 추가 도구를 요청하거나 답을 보류해야 합니다. Confidence가 높지만 오답인 사례와 불필요하게 긴 탐색 뒤 같은 오답을 낸 사례를 별도 failure set으로 둡니다.

제품용 축소 평가는 어떻게 만들까

실제 사용자 자료에서 개인정보를 제거한 뒤 UI screenshot, 사진, 도표, scan 문서를 균형 있게 고릅니다. 각 문항에 허용 도구, 정답 근거, 최대 시간과 실패 비용을 적습니다. 모델이 접근할 수 없는 내부 문서를 요구하는 문제는 평가에서 제외하거나 별도 tool로 제공합니다.

단일 VLM 답변, 고정 preprocessing+VLM, full agent의 세 기준을 비교합니다. Agent가 정확도를 조금 올려도 latency와 비용이 크게 늘 수 있고, 간단한 crop pipeline만으로 같은 이득을 얻을 수도 있습니다. 사람 검토 시간까지 포함해야 자동화의 실제 절감 효과가 드러납니다.

정답률이 충분한 하위 도메인만 자동화하고 나머지는 evidence bundle을 사람에게 전달할 수 있습니다. Agent의 역할을 최종 판정과 조사 보조로 나누면 낮은 전체 benchmark 점수에서도 안전한 제품 범위를 찾을 수 있습니다.

긴 작업에는 어떤 안전장치가 필요한가

최대 턴만 두면 마지막 순간에 중요한 검증을 못 할 수 있습니다. 전체 token, 시간, 검색 횟수와 함께 “새 근거가 없는 연속 step” 제한을 둡니다. 중간에 비용 상한에 가까워지면 현재까지의 근거와 남은 질문을 반환하도록 합니다.

Browser와 code tool은 file, network 권한을 최소화하고 외부 상태 변경을 금지합니다. 평가 문제를 푸는 과정에서 임의 upload나 login을 시도하지 못하게 해야 합니다. 민감 이미지가 search query나 외부 model에 전송되는지도 전체 경로에서 확인합니다.

함께 읽으면 이해가 이어지는 글

• MCP 서버를 만들었다고 착각하기 쉬운 이유: Host, Client, Server와 도구 호출 흐름 — MCP가 prompting 기법이 아니라 host와 외부 도구를 잇는 protocol임을 설명하고, resources, tools, prompts의 역할, 기존 날씨 예제가 실제로는 client 코드인 문제와 보안 체크리스트를…
• system_prompts_leaks: AI 모델들의 숨겨진 뇌 구조와 프롬프트 아키텍처 해설 — 글로벌 AI 기업들의 1급 비밀인 ‘시스템 프롬프트’ 유출본을 집대성한 system_prompts_leaks 저장소를 심층 분석합니다. 각 모델의 행동 강령, 도구 사용 규칙, 그리고 프롬프트 엔지니어링의 최신 진화 트렌드를…
• AI 에이전트, 멀티모달, 설명가능 AI, 무엇부터 도입해야 할까? — 에이전트 AI, 멀티모달 AI, 설명 가능한 AI를 실행, 입력, 검증이라는 도입 목적에 맞춰 비교하고 선택 기준과 주의점을 정리합니다.

자주 묻는 질문

AgentVista 27.3%를 우리 멀티모달 에이전트의 예상 성공률로 써도 되나요?

해당 모델, 도구, 문항, 채점 조건의 결과이므로 그대로 사용할 수 없습니다. 실제 업무 자료와 허용 도구로 작은 평가 세트를 만들고 정확도, 턴, 비용, 사람 개입을 다시 측정해야 합니다.

도구 호출 횟수를 늘리면 어려운 문제를 더 잘 풀 수 있나요?

필요한 증거를 찾을 기회는 늘지만 잘못된 검색과 반복 호출, 지연, 비용도 커집니다. 각 호출이 새 근거를 만들었는지와 중단 조건을 평가해야 합니다.

최종 답이 맞으면 에이전트 경로도 성공한 건가요?

우연히 맞거나 잘못된 근거에서 정답을 낼 수 있습니다. 첫 오류, 도구 결과 사용, 근거 인용, 재시도와 최종 답을 함께 채점해야 재현 가능한 성공인지 알 수 있습니다.