VAKRA 내부 살펴보기: 에이전트의 추론, 도구 사용 및 실패 모드

VAKRA 내부 살펴보기: 에이전트의 추론, 도구 사용 및 실패 모드

개요

VAKRA는 API와 문서 전반에 걸친 조합적 추론을 요구함으로써, AI 에이전트가 기업 환경과 유사한 환경에서 얼마나 잘 추론하고 행동하는지를 측정하는 도구 기반 실행형 벤치마크입니다. 이 벤치마크는 표면적인 도구 숙련도와 신뢰할 수 있는 엔드투엔드(end-to-end) 에이전트 행동 사이의 격차를 드러내며, 강력한 모델조차도 다단계 워크플로우에서 실패하는 경우가 많다는 것을 보여주기 때문에 중요합니다.

작업 설명

VAKRA는 62개 도메인에 걸쳐 로컬에서 호스팅되는 8,000개 이상의 API와 도메인 정렬 문서 컬렉션이 있는 실행 가능한 환경에서 각기 다른 기술 세트를 테스트하는 4가지 역량으로 구성됩니다.

역량 1: Business Intelligence API를 사용한 API 체이닝

이 역량은 54개 도메인에 걸쳐 2,077개의 테스트 인스턴스를 포함하며, 에이전트가 JSON 데이터 소스에서 답변을 도출하기 위해 SLOT-BIRD 및 SEL-BIRD 컬렉션의 도구 호출을 1~12개까지 체이닝할 것을 요구합니다. 각 인스턴스는 데이터 소스를 초기화하고 적절한 도구 세트를 노출하도록 MCP 서버를 구성하는 get_data(tool_universe_id=id) 호출로 시작됩니다.

역량 2: Dashboard API를 사용한 도구 선택

이 역량은 17개 도메인에 걸쳐 1,597개의 인스턴스를 포함하며, MCP 서버에 의해 래핑된 FastAPI를 통해 제공되는 엔드포인트 스타일 API의 확장된 REST-BIRD 컬렉션을 사용합니다. 에이전트는 도메인당 6개에서 328개(평균 116개)에 이르는 도메인별 도구 세트에서 올바른 API를 선택해야 합니다. OpenAI API Specification은 도구 목록을 128개로 제한하므로, 후보 목록을 만드는 메커니즘이 필요합니다.

역량 3: Dashboard API를 사용한 Multi-Hop 추론

Capability 3 세그먼트는 38개 주제 도메인에서 추출된 869개의 테스트 인스턴스를 보유하고 있으며, 다시 REST-BIRD API 컬렉션에 의존하지만 Multi-Hop 추론이 추가되었습니다. 질문은 1개에서 5개 사이의 논리적 홉(hop)을 요구하며, 각 홉은 API 호출에서 지원 증거를 추출하고 결합하는 과정을 포함합니다.

역량 4: Multi-Hop, Multi-Source 추론 및 정책 준수

Capability 4는 41개 도메인에 걸쳐 644개의 인스턴스를 포함하며, 도메인별 문서 인덱스, 멀티턴 대화 및 선택적 도구 사용 정책이 추가된 REST-BIRD API 컬렉션을 기반으로 구축되었습니다. 쿼리는 API, 문서 검색기 또는 이들의 조합(API-RAG-API 패턴)에서 정보를 요구할 수 있습니다. 정책은 에이전트가 특정 턴에서 어떤 지식 소스를 사용할 수 있는지 제한하는 평문 지침입니다.

평가 프레임워크

VAKRA는 최종 답변의 정확성과 전체 도구 실행 궤적의 유효성을 모두 평가하여 에이전트를 평가하며, 유효한 추론 과정을 통해 정답을 얻은 에이전트에게 보상을 줍니다.

평가 지표

VAKRA Evaluator는 예측된 최종 응답과 해당 도구 호출 궤적에 대해 작동하며, 중간 출력을 검증하기 위해 정답(ground truth)과 동일한 환경에서 예측된 호출을 실행합니다. 평가는 워터폴(waterfall) 스타일의 파이프라인을 따릅니다. Capability 4 작업의 경우, 정책 준수 여부를 먼저 확인합니다. 그다음 예측된 도구 호출 시퀀스를 정답과 비교합니다. 유효한 궤적을 가진 샘플만 최종 응답 평가로 진행됩니다.

도구 시퀀스 정확도는 각 예측된 도구를 실행하고 도구 응답 세트를 정답의 응답과 비교하여 결정하며, 대안적이지만 유효한 호출은 허용합니다. 검증 결과가 불분명한 경우, CRAG 프레임워크에서 채택된 LLM 기반 평가가 구조적 차이에도 불구하고 예측된 궤적이 필요한 모든 정보를 검색했는지 여부를 결정합니다. 최종 응답은 예측된 도구 출력에 기반하고 정답과 사실적으로 일치하는지 확인하기 위해 LLM에 의해 판단됩니다.

점수는 역량별로 계산되어 리더보드용 평균을 냅니다: Leaderboard Score = (Capability₁ + Capability₂ + Capability₃ + Capability₄) / 4. Capability 1-3은 정답 쿼리의 단순 평균입니다. Capability 4는 멀티 소스 정답 쿼리에 API 전용 또는 RAG 전용 정답 쿼리보다 두 배의 가중치를 부여합니다.

오류 분석

오류 분석은 단계별 분류를 사용하여 각 실패를 첫 번째 중단 지점(도구 선택, 인자 제공, 인자 값 또는 최종 응답 근거 생성)에 할당합니다.

실패 단계 격리

각 인스턴스를 가장 먼저 실패한 단계로 분류함으로써, 오류를 데이터셋의 서로 다른 부분으로 취급하여 중복 계산을 피하고 해석 가능한 분석을 제공합니다.

Capability 1: Business Intelligence API를 사용한 API 체이닝

이 역량의 2,077개 샘플에 대해 GPT-OSS-120B는 주로 도구 스키마에 대한 더 나은 이해와 선택적 매개변수 채우기의 견고함 덕분에 다른 모델보다 큰 차이로 성능이 뛰어났습니다. SLOT-BIRD(1,477개 샘플)에서의 오류는 GPT-OSS-120B를 제외한 모든 모델에서 잘못된 도구 인자 이름으로 인해 발생한 경우가 지배적이었던 반면, SEL-BIRD(600개 샘플)는 인자 오류는 적었지만 더 크고 동적인 도구 세트로 인해 도구 선택 오류가 더 많이 나타났습니다.

Capability 2: Dashboard API를 사용한 도구 선택

1,597개 샘플 전체에서 Gemini-3-flash-preview가 모든 오류 카테고리에서 다른 모델보다 뛰어난 성능을 보였습니다. 많은 수의 도구 옵션으로 인해 도구 선택 및 매개변수 값 선택에서 빈번한 오류가 발생하지만, 필수 매개변수를 환각하거나 건너뛰는 경우는 드뭅니다. 모든 도구 호출이 정확하더라도 모델(특히 Gemini-3-flash-preview 및 Claude-Sonnet-4-5)은 도구 응답에서 정확한 답변을 합성하는 데 어려움을 겪으며, 이는 오류 플롯의 오른쪽 끝에서 성능 저하로 나타납니다.

Multi-Hop 추론: 모델 성능에 미치는 홉 깊이의 영향

홉 깊이가 증가함에 따라 정확도가 감소합니다: 모델은 단일 홉 질문에서 가장 좋은 성능을 보이며, 2-홉에서 성능이 저하되고, 테스트된 모든 모델에서 3-홉 이상의 질문에서 성능이 더욱 저하됩니다.

Multi-Hop Multi-Source 추론: 모델 성능에 미치는 하이브리드 홉의 영향

성능은 상호작용 유형에 따라 다릅니다: 단일 API 호출(1-hop API)은 여러 API 호출(2-hop API)보다 쉽습니다. 문서 검색기(RAG 홉 또는 하이브리드 API-RAG 패턴)를 추가하면 난이도가 높아집니다. 1-hop RAG 질문에서 GPT-OSS-120B는 검색기를 호출하는 대신 파라메트릭 지식(parametric knowledge)에서 답변을 반환하는 경향이 있는데, 이는 질문이 Wikipedia 엔티티에 집중되어 있기 때문일 가능성이 높습니다. Gemini-3-flash-preview는 2-hop API-RAG 패턴에서 비교적 강력한 성능을 보이는데, 이는 dashboard-API 도구 선택 능력이 도움이 된 것으로 보입니다.

모델 성능에 미치는 정책의 영향

정책이 가장 관련성 높은 정보 소스에 대한 액세스를 제한할 때("Policy updates the answer"), Granite-4.0-h-Small-32B를 제외한 모든 모델에서 명확한 성능 저하가 발생합니다. 모델들은 제약 조건을 위반하거나 충분한 정보를 검색하지 못하며, 때로는 정책을 이해하고도 잘못된 답변을 내놓기도 합니다. 이는 모델이 도구와 소스에 대해 추론할 수는 있지만, 해당 추론에 외부 제약 조건을 통합하는 데 어려움을 겪고 있음을 나타내며, 이는 신뢰할 수 있는 실제 배포를 위한 핵심 요구 사항입니다.

결론

VAKRA는 표면적인 도구 숙련도와 견고한 엔드투엔드 에이전트 신뢰성 사이의 중대한 격차를 드러냅니다. 현대적인 모델들이 API를 선택하고 개별적인 도구 호출을 실행하는 능력은 점점 향상되고 있지만, 이 벤치마크는 이러한 능력만으로는 실제 배포에 불충분함을 보여줍니다. 모델들은 API, 문서, 대화 문맥 및 정책 요구 사항에 걸친 실행 제약 조건 하에서 조합적 추론을 수행해야 할 때 종종 무너집니다.

VAKRA를 시도해 보세요 — 당신의 에이전트는 어디서 무너집니까?

VAKRA 벤치마크에서 에이전트를 테스트하여 도구 선택, Multi-Hop 추론 또는 정책 제약 중 어디에서 실패하는지 확인해 보세요.

👉 직접 시도해 보고 에이전트가 무엇을 배웠는지 알려주세요

Sources