VAKRA 벤치마크 분석: 에이전트 추론, 도구 사용 및 실패 모드

TL;DR

Hugging Face는 62개 도메인에 걸쳐 8,000개 이상의 로컬 호스팅 API를 포함하는 실행 가능한 스위트인 VAKRA 벤치마크를 출시했습니다. 이 벤치마크는 AI 에이전트의 구성적 추론, 도구 선택, 멀티 홉 워크플로우 및 정책 준수 능력을 테스트합니다. 현재 최첨단(SOTA) 모델들은 저조한 성능을 보이며, 이는 실제 배포를 위한 중대한 격차를 드러냅니다.

VAKRA란 무엇인가?

VAKRA는 AI 에이전트가 기업 환경과 유사한 환경에서 얼마나 잘 추론하고 행동할 수 있는지를 평가하기 위해 설계된 도구 기반의 실행 가능한 벤치마크입니다. 기존의 고립된 기술 테스트와 달리, VAKRA는 에이전트가 전체 다단계 워크플로우를 실행하도록 요구하고 검증을 위한 실행 트레이스를 제공함으로써 API 및 문서에 대한 구성적 추론을 측정합니다.

주요 통계:

실제 데이터베이스를 기반으로 하는 8,000개 이상의 로컬 호스팅 API.
비즈니스 인텔리전스, 대시보드 및 문서 검색을 아우르는 62개 도메인.
구조화된 API 호출과 비구조화된 문서 검색이 혼합된 3~7단계 추론 체인 포함.
네 가지 역량 그룹이 서로 다른 기술 세트(API 체이닝, 도구 선택, 멀티 홉 추론, 정책 제약이 있는 멀티 소스 추론)를 테스트합니다.

벤치마크, 데이터셋, 리더보드 및 코드는 Hugging Face와 GitHub에서 공개적으로 사용할 수 있습니다.

역량 1 – 비즈니스 인텔리전스 API를 이용한 API 체이닝

인스턴스: 54개 도메인에 걸쳐 2,077개.
도구 컬렉션: SLOT-BIRD (7개 범용 도구) 및 SEL-BIRD (확장된 도메인 특화 getter).
워크플로우: 가벼운 미리보기를 로드하고 서버를 구성하기 위한 get_data(tool_universe_id)로 시작하여, 데이터 필터링 및 선택을 위한 1~12개의 체인된 도구 호출이 이어집니다.

예시 JSON 요청 (단순화됨):

{
  "query": "Which football team has a build-up play speed of 31 …?",
  "tool_calls": [
    {"name": "get_data", "arguments": {"tool_universe_id": "..."}, "label": "retrieved_data_1"},
    {"name": "select_data_equal_to", "arguments": {"data_label": "retrieved_data_1", "key_name": "play_speed", "value": 31}, "label": "FILTERED_DF_0"},
    ..
  ],
  "answer": "FC Barcelona"
}

도전 과제: 대규모의 동적인 세트에서 올바른 도구를 선택하고 많은 선택적 매개변수를 제공하는 것.

역량 2 – 대시보드 API를 이용한 도구 선택

인스턴스: 17개 도메인에 걸쳐 1,597개.
도구 컬렉션: FastAPI를 통해 제공되고 MCP 서버로 래핑된 REST-BIRD.
도메인 규모: 도메인당 6~328개의 도구 (평균 116개).
제약 사항: OpenAI의 128개 항목 도구 목록 제한으로 인해 에이전트는 짧은 목록 생성(shortlisting) 메커니즘을 구현해야 합니다. 베이스라인은 단순한 휴리스틱 짧은 목록 생성기를 사용합니다.
목표: 쿼리에 대해 단 하나의 올바른 엔드포인트 스타일 API를 식별하는 것.

역량 3 – 대시보드 API를 이용한 멀티 홉 추론

인스턴스: 38개 도메인에 걸쳐 869개.
요구 사항: 1~5개의 논리적 홉; 각 홉은 올바른 API를 호출하고 적절한 인수를 전달해야 합니다.
관찰 결과: 홉 깊이가 증가함에 따라 정확도가 급격히 떨어지며, 이는 여러 API 호출을 체이닝하는 것이 현재 모델들에게 주요한 어려움임을 확인시켜 줍니다.

역량 4 – 멀티 홉, 멀티 소스 추론 및 정책 준수

인스턴스: 41개 도메인에 걸쳐 644개.
특징:
- 멀티 소스: 쿼리는 API → 문서 검색 (RAG) → API와 같은 시퀀스를 요구할 수 있으며, 소스 오염 방지(de-contamination)를 통해 각 홉의 답변이 단 하나의 소스에서만 제공되도록 보장합니다.
- 멀티 턴: 대화 컨텍스트가 제공됩니다; 에이전트는 현재 턴에 대해서만 답변해야 합니다.
- 도구 사용 정책: 평문 제약 조건이 어떤 지식 소스를 사용할 수 있는지 규정합니다 (예: "기술 관련 쿼리에는 문서 검색기만 사용하세요").
정책 집행: 베이스라인 에이전트는 프롬프트 앞에 제약 문장을 추가합니다; 개발자는 더 정교한 체크를 구현할 수 있습니다.

평가 프레임워크

VAKRA는 에이전트의 도구 실행 정확도와 최종 답변 품질 모두를 검증하는 실행 중심의 폭포수 스타일 파이프라인을 사용합니다.

정책 준수 (역량 4만 해당) – 프로그래밍 방식으로 검증됨.
도구 호출 시퀀스 검증 – 예측된 호출이 실행됩니다; 응답은 정답(ground-truth) 응답과 비교됩니다.
- 정확한 일치가 실패할 경우, LLM 기반 평가기(CRAG에서 수정됨)가 예측된 궤적이 필요한 모든 정보를 검색하는지 확인하여, 대안적이지만 유효한 도구 시퀀스를 허용합니다.
최종 응답 평가 – LLM 심사위원이 답변이 실행된 도구 출력에 근거하고 사실적으로 참조와 일치하는지 확인합니다.

점수 산정

네 가지 역량 모두 동일한 가중치를 가집니다:

$$\text{Leaderboard Score}=\frac{1}{4}\sum_{i=1}^{4}\text{Capability}_i$$

역량 1-3: 단순 정확도 (정확한 쿼리 / 총 쿼리).
역량 4: 멀티 소스 쿼리는 더 높은 난이도를 반영하여 가중치를 두 배로 적용합니다.

오류 분석 – 에이전트가 무너지는 지점

분석은 첫 번째 실패 지점에 따라 오류를 분류합니다:

잘못된 도구 선택.
누락되거나 환각된 매개변수.
잘못된 매개변수 값.
부정확하거나 근거 없는 최종 응답.

API 체이닝 (역량 1)

최고 모델: GPT-OSS-120B, 주로 도구 스키마에 대한 우수한 이해와 선택적 매개변수에 대한 견고한 처리 덕분입니다.
오류 패턴: SLOT-BIRD 컬렉션을 사용하는 모델은 매개변수 명명에서 어려움을 겪었습니다; SEL-BIRD를 사용하는 모델은 더 큰 도구 세트 때문에 더 많은 도구 선택 실수를 범했습니다.

대시보드 도구 선택 (역량 2)

최고 모델: Gemini-3-flash-preview, 모든 오류 카테고리에서 다른 모델들을 압도했습니다.
주요 오류: 도구 선택 실패 및 잘못된 매개변수 값; 도구 호출이 성공하더라도 최종 답변의 합성은 여전히 과제로 남았습니다.

멀티 홉 추론 (역량 3)

추세: 홉 깊이에 따라 정확도가 감소합니다 (1-hop > 2-hop > 3+ -hop). 모든 모델이 동일한 패턴을 보이며, 이는 여러 API 호출을 체이닝하는 것이 오류 전파를 증폭시킨다는 것을 확인시켜 줍니다.

멀티 홉 멀티 소스 및 정책 (역량 4)

하이브리드 홉: API 호출과 문서 검색이 모두 필요한 인스턴스가 가장 어렵습니다; 순수 API 또는 순수 RAG 홉에 비해 성능이 급격히 떨어집니다.
정책 영향: 모델들은 일반적으로 정책을 잘 따르지 않습니다; 대부분의 모델은 정책이 가장 관련성 높은 소스를 제한할 때 눈에 띄는 정확도 저하를 경험합니다. Granite-4.0-h-Small-32B는 예외적으로 저하가 적게 나타납니다.
특이 사항: GPT-OSS-120B는 종종 단일 홉 RAG 호출을 건너뛰고 내부 지식으로 답변합니다; Gemini-3-flash-preview는 대시보드 API에서의 강점을 활용하여 2-hop API-RAG 조합에서 뛰어난 성능을 보입니다.

에이전트 개발에 주는 시사점

도구 역량 ≠ 신뢰성: 올바른 API를 선택하는 것은 문제의 일부일 뿐입니다; 에이전트는 매개변수를 관리하고, 다단계 워크플로우를 실행하며, 외부 제약 조건을 준수해야 합니다.
실행 중심 지표의 중요성: 전통적인 답변 전용 점수는 중간 단계의 실패를 숨깁니다; VAKRA의 궤적 기반 평가는 이러한 격차를 드러냅니다.
정책 처리는 취약한 부분: 실제 배포에는 규정 준수 또는 보안 정책이 적용되는 경우가 많습니다; 현재 모델들은 이러한 제약을 추론에 통합하는 데 어려움을 겪고 있습니다.
개발 목표로서의 벤치마크: 에이전트가 어디서 무너지는지 노출함으로써, VAKRA는 도구 사용 모듈, 짧은 목록 생성 메커니즘 및 정책 인식 프롬프팅을 개선하기 위한 구체적인 로드맵을 제공합니다.

VAKRA 시도해보기

데이터셋: https://huggingface.co/datasets/ibm-research/VAKRA
리더보드 및 제출: https://github.com/IBM/vakra?tab=readme-ov-file#submitting-to-the-live-leaderboard
코드 및 평가기: https://github.com/IBM/vakra

에이전트를 벤치마크에 실행하여 도구 선택, 멀티 홉 추론 또는 정책 준수 중 어디에서 실패하는지 확인하고, VAKRA가 제공하는 상세한 오류 분석을 바탕으로 반복 개선하십시오.