Benchmarking the Benchmarks: Evaluating Benchmarks for Conversational Agents

Meta info.

• Authors: Noam Koren, Roy Bar-Haim, Abigail Goldsteen
• Affiliation: IBM Research
• Paper: https://arxiv.org/abs/2608.06329
• Published: August 6, 2026 (arXiv preprint)

TL; DR

conversational agent는 시나리오 + 초기 DB 상태 + 정답 행동으로 이루어진 task 묶음(벤치마크)을 실제 실행하여 평가하는데, 정작 그 벤치마크가 잘 만들어졌는지는 검증되지 않는다는 문제 지적.
비교할 (human-curated) 정답 벤치마크도, agent 실행도 없이 LLM judge만으로 (1) 시나리오-정답 행동-policy가 서로 모순되지 않는지 (2) task가 policy와 충돌하는 어려운 상황을 포함하는지 (3) policy 항목이 골고루 시험되는지를 재는 4개 metric 제안.
생성 모델 능력 차이, 통제된 품질 저하 perturbation, human annotation 세 축으로 이 metric이 실제 품질 차이를 잡아낸다는 것을 검증함.

Background

• task-oriented conversational agent (Mohammadi et al., 2025; Yehudai et al., 2026)
  • 고객지원, 여행, enterprise workflow에 이미 배포되었으나,
  • static QA와 달리 multi-turn으로 상호작용하면서
  • domain policy를 지키고 + 실제 환경을 조작하고 + tool까지 써야 하므로,
  • 자율성이 커질수록 평가 자체가 같이 어려워짐
• 현행 벤치마크 구축 방식은 사람이 만드느냐 vs. 기계가 만드느냐
  • manually curated 계열:
    • τ-BENCH (Yao et al., 2024), τ²-BENCH (Barres et al., 2025)
    • 현실적인 task와 user request, 환경 상태, 기대 결과를 사람이 직접 설계
    • domain 전문성부터 tool/DB 시뮬레이션과 기대 행동 명세까지 전부 사람 손을 태워야 함 → 비용문제
  • 자동 생성 계열:
    • API-Bank (Li et al., 2023), ToolLLM (Qin et al., 2024), INTELLAGENT (Levi and Kadar, 2025)
    • manual curation을 건너뛰면 == 암묵적 품질 통제까지 같이 간과
• 벤치마크 품질에 대한 의심
  • synthetic 벤치마크는 human-curated 데이터와 대표성, 난이도, 심지어 유도되는 model ranking까지 차이 (Maheshwari et al., 2024)
    • 445개 벤치마크를 검토 결과 널리 쓰이는 manual 벤치마크에도 construct validity 문제가 만연 (Bean et al., 2025)
  • 본 연구가 기반으로 삼는 τ-bench조차 결함 있고 모호한 task를 포함한다고 보고, 그 수정판이 뒤에서 평가 대상이 되는 τ³-bench (Cuadron et al., 2025)
• 공백: 벤치마크를 체계적으로 평가하려는 시도는 있지만 conversational agent 관련은 아직 출발점
  • Benchmark² (Qian et al., 2026): MMLU/ARC 같은 closed-form 벤치마크를 model ranking 일관성과 모델 간 변별력으로 평가
    • 벤치마크마다 다수의 LLM을 실제로 실행해야함 → open-ended 대화 setting에서 비용문제
  • tool-using LLM용 synthetic data 품질을 본 연구(Iskander et al., 2024): conversational agent 설정과는 결이 다름
  • INTELLAGENT: 자신의 검증조차 τ-BENCH 성능과의 상관으로 대체
    • 이는 reference 벤치마크가 존재해야만 성립하는 간접 증거라고 주장
• TL; DR: policy에 근거해 conversational agent 벤치마크를 평가하는 방법이 없고, 그래서 탐지되지 않은 결함이 agent 능력에 대한 잘못된 결론으로 이어질 수 있다는 것이 이 논문이 겨냥하는 공백

Problem States

비교 대상이나 agent 실행도 없이 벤치마크 품질을 잴 수 있어야 하고 점수보다는 문제의 위치 식별 가능하도록

• 조건 1 ) reference-free: 비교 기준이 될 human-curated 벤치마크가 늘 존재하지는 않음
  • model ranking 일치, 통계적 유사도 == reference를 전제하는 방식 → 애초에 적용 불가한 경우가 다수이므로
• 조건 2 ) 실행 비용 없이: 벤치마크 하나 평가하자고 여러 agent를 돌리는 등 비효율 지양
  • closed-form QA에서는 가능, multi-turn + tool 설정에서 비용적 한계
• 조건 3 ) task 내부 정합성: description ↔ expected behavior ↔ policy 삼자 무모순
  • synthetic task는 이 셋이 파이프라인 안에서 따로 생성 → 구조적으로 어긋날 여지
• 조건 4 ) policy 기준의 난이도 + 포괄성
  • 시나리오가 단순하면 → agent 간 점수 차이가 적을 것이므로 변별 실패
  • policy 항목 일부만 건드리면 → 평가 결과 자체가 편향될 우려
• 조건 5 ) actionable diagnostic: 점수만으로는 벤치마크 개발자가 고칠 수 없으므로
  • 어떤 task가 왜 나쁜지까지 나와야 개선 루프 성립 가능

Suggestions

notation & task 정의

• benchmark evaluation: 이 벤치마크가 정합적인가 + 충분히 어려운가 + policy를 대표하는가
• 벤치마크 == domain policy 문서 1개 + 그 policy를 시험하는 task n개

  • policy 문서: 해당 domain에서 agent가 지켜야 할 constraint set, domain당 1개

    e.g. Airline policy: “탑승객 인원 수 변경 불가”, “여행자보험은 최초 예약 시에만”, “환불은 원래 결제수단으로 5~7영업일 이내”, … 등등

  • task: 그 규정을 시험하는 개별 시나리오, Airline 100개 / Retail 95개 등
  • n개 task가 전부 동일한 policy 문서 1개를 공유하기 때문에 후속의 metric 구조 연결
    • consistency 류 (2종): task마다 채점 → 평균
    • coverage: policy 항목 중 몇 개가 task들에 의해 실제로 시험되었나 → 즉 조항마다 모든 task 훑어서 검토 필요
• task 구성 Fig 2
  • description: user request를 포함한 시나리오 서술
  • expected behavior: 기대되는 agent 행동, policy와 일관되어야 함
  • initial database state: 시뮬레이션 시작 시점의 DB 상태

Consistency: Description-Expected Behavior Alignment 설명이 답안과 일치하나?

• judge에게 description + expected behavior 제공 → 정답 행동이 시나리오 요청을 제대로 받는지 판정

  e.g. description은 “예약 취소 + 환불 문의”인데 expected behavior에 취소 처리가 빠져 있지는 않은지

• 벤치마크 점수: task 하나당 1-10점 → task 전체 대상 평균 Fig 4
• judge prompt A.1
  • consistency: description의 명시적 사실과 무모순
  • no invention: description에 없는 구체 사실을 새로 생성하지 않음
    • 이름, 날짜, 도시, 항공편 번호, 멤버십 등급, 결제수단을 직접 열거 → 판단 여지를 좁히려는 시도
  • coverage: description이 함의하는 핵심 결과를 누락하지 않음 (후속의 Policy Violations Coverage와는 무관한 prompt 내부 기준)
  • relevance: 요구되지도 함의되지도 않은 행동을 추가하지 않음
  • metric이 문체 평가로 새지 않도록 글의 질과 현실성은 평가 대상에서 명시적으로 제외시켰다고

Consistency: Policy-Expected Behavior Alignment policy를 똑바로 지키나?

• judge에게 policy 문서까지 제공 → 해당 시나리오에서 expected behavior의 policy 준수 여부 판정
• 판정 단위 act: expected behavior에 담긴 개별 행동 하나하나

  • 정답 행동 1개 안에 act 여러 개 → judge가 act마다 policy 허용 여부를 따짐

    e.g. user ID 요구 / 수수료 안내 / API 호출로 예약 수정 / 보상 제안 / 사람 상담원에게 이관

• 허용 판정 기준 A.2 : (a)와 (b) 둘 중 하나만 만족하면 허용

  • (a) policy에 명시되어 있음 or (b) policy가 요구하는 워크플로우의 필연적 함의

    e.g. policy에 “추가 수하물 $50” → user에게 “$50”이라 말하는 것은 (b) 별도 명시 없이도 허용

• 감점 대상:
  • invented act: (a)(b) 어디에도 안 걸리는 act가 expected behavior에 포함
  • missing-required-step: policy가 요구하는 절차가 expected behavior에 아예 빠짐
• output:
  • score(1-10)

  • reasoning(짧은 bullet 3-7): 점수를 매긴 이유

    e.g. user는 취소만 요청했는데 expected behavior가 예약 수정을 돕고 결제수단을 먼저 요구 → policy에 없는 invented act

Complexity & Coverage: policy violation 기준 만든 벤치마크에 policy 전반이 잘 반영됐나?

• 설계 전제: agent 평가의 핵심 == policy와 충돌하는 요청을 알아채고 처리하는가

  e.g. “탑승객 정보는 수정 가능, 인원 수는 변경 불가” policy에서 기존 예약의 탑승객 제거를 요구하는 task

  • compliant 시나리오가 아니라 violation을 카운트하는 이유
    • policy 항목이 시나리오와 관련 있는지만 측정 → 거의 모든 task가 대부분 항목과 엮임 → 어떤 벤치마크든 만점 근처이므로 변별 불가
    • task가 특정 항목을 실제로 위반하도록 요구 == 훨씬 강한 조건 → 벤치마크 간 차이가 남는 신호
• policy 항목 목록: policy 문서 내 annotated span
  • TOOLGUARD (Zwerdling et al., 2025)로 초기 span 생성 → 저자 1인이 검토 및 수정한 semi-automatic 방식
• 벤치마크 점수 출력: judge가 description + 초기 DB 상태로 각 task의 위반 항목 집합을 출력

\[S_{\text{v\_cov}}(B) = \frac{1}{N}\big|\lbrace k : |T(p_k)| \ge K \rbrace\big|, \qquad T(p_k) = \lbrace t : k \in V(t)\rbrace\]

• Policy Violations per Task: task 하나가 평균 몇 개 항목을 건드리는가 == complexity
• Policy Violations Coverage: 전체 policy 항목 중 최소 $K$개 task가 위반한 항목의 비율 == coverage, 실험에서 $K=3$
• $N$: policy 항목 수, $T(p_k)$: 항목 $p_k$를 위반하는 task 집합
• $K$: 일부 task가 스치고 지나간 항목은 제대로 시험된 것으로 치지 않겠다
• 위반 판정 제외 규칙 prompt에 명시 == 무엇을 위반으로 볼지가 좁게 통제 B
  • user가 아니라 agent 행동을 규율하는 policy는 제외, 단 user가 우회나 위반을 요구하면 포함
  • 인증 및 정보 제공 요구 policy도 제외, 단 시나리오가 정보 미제공이나 오제공을 명시하면 포함
  • agent가 올바르게 처리했다고 서술되어 있어도 위반은 위반으로 카운트

검증 장치 1: Benchmark Ordering Score

• 전제: 강한 모델이 더 나은 벤치마크를 생성함 (Grattafiori et al., 2024; Cui et al., 2024; Bubeck et al., 2023; Kim et al., 2023)
• metric이 실제로 품질 차이를 서열화하는지 재기 위한 meta-metric: 이 partial order → 8개 pairwise 제약 유도 → 만족한 제약의 비율이 점수, 1.0이면 전부 만족
  • absolute scale 문제 우회하고 rank를 맞추는가만 확인
  • 생성 모델 능력에 따라 3-tier 분할
    • Top: GPT-5.4, Claude-4.5-Sonnet
    • Medium: Llama-3.3-70B, Llama-3.1-8B
    • Small: Llama-3.2-1B

검증 장치 2: 통제된 perturbation

• 생성 모델 변주만으로는 품질 차이의 크기를 통제할 수 없으므로 성격이 반대되는 축 추가
  • 생성 모델 변주: 현실적이나 차이의 크기는 통제 불가
  • perturbation: 비현실적이나 차이가 정확히 통제됨
• Expected Behavior Swapping: task의 20/40/60/80%에서 expected behavior를 서로 교환
  • description ↔ expected behavior 정렬만 선택적 파괴
  • Description-Expected가 비율에 따라 단조 하락해야 함
• Cross-Domain Policy Swapping: Airline task를 Retail policy로, 그 반대로 평가
  • policy 기반 3개 지표가 크게 하락해야 함

Effects

• Experimental setup
  • 벤치마크 생성: INTELLAGENT 파이프라인 Fig 3
    • policy를 flow로 분해 → policy graph 구축 → random walk로 policy 부분집합 샘플 → description과 expected behavior 생성 → entity 인스턴스화 및 초기 DB 상태 구성
      • 기본 설정은 전 단계 GPT-4o (edge scoring만 GPT-4o-mini)
      • 선택된 단계만 교체해 품질 차이 유도
    • 최종 구성 단계는 약한 모델이 처리 불가 → 모든 configuration에서 GPT-4o 고정
      • 실제 조작 변수는 policy 추출 + description/expected behavior 생성 단계로 한정
    • generator 5종: GPT-5.4, Claude-4.5-Sonnet, Llama-3.3-70B, Llama-3.1-8B, Llama-3.2-1B
    • domain 2종(τ-bench 기반): Airline 100 task + Retail 95 task → 총 975 synthetic task
  • judge 3종: GPT-5.4, Claude-4.5-Sonnet, Gemini-2-Flash
    • perturbation 실험만 Gemini-2-Flash 단독
  • human validation: 5개 generator 전체에서 50 task 샘플, 저자 1인이 LLM judge와 동일 기준으로 채점
    • 순서형 점수 + tie 존재 → Kendall’s $\tau_b$, two-sided p-value
  • manually curated 적용: τ³-BENCH Airline 50 task, judge는 Claude-4.5-Sonnet + GPT-5.4
    • nl_assertions 필드를 expected behavior로 매핑
    • task별 독립 DB 없이 공유 DB 사용 → violation judge 입력에서 초기 DB 상태 제거
    • description과 DB가 따로 작성됨 → Description-Expected에서 no invention 기준 제거
    • Retail은 대부분 task에 expected behavior annotation 부재 → 제외
• Results
  • generator별 순위 Fig 4 Tab 2: 4개 지표 모두 강한 모델의 벤치마크에 일관되게 높은 점수
    • Airline: 모든 지표 x 모든 judge에서 ordering score 1.00
    • Retail: 평균 0.92 / 전체 평균 0.96
    • Policy Violations Count: 전 judge + 전 domain 완벽 순위정렬 → 4개 중 가장 안정적
    • judge별 평균: GPT-5.4와 Claude-4.5-Sonnet 0.97 vs. Gemini-2-Flash 0.94
  • expected behavior swapping Fig 5: 0 → 80%로 갈수록 Description-Expected 단조 하락
    • 두 domain + 5개 generator 전부 동일 패턴 → task coherence 저하에 민감함 입증
  • cross-domain policy swapping Fig 6: policy 기반 3개 지표 모두 큰 폭 하락
    • task와 policy의 mismatch를 감지한다는 근거
  • human validation Tab 3: 3 metric x 3 judge == 9개 상관 전부 positive + 통계적 유의
    • $\tau_b$ 0.32~0.67, p-value 10^-6 미만 ~ 0.011
    • 강한 일치: Policy Violations Count 0.55~0.67
    • alignment 계열: 0.32~0.55로 상대적 열세
    • judge-human 일치 + 강한 모델이 더 나은 벤치마크를 만든다는 전제까지 뒷받침한다고 주장
  • qualitative diagnostic Fig 7/8/9: Policy-Expected 저점수 task + Gemini rationale을 GPT-5로 클러스터링 → 수동 정제
    • 반복 실패 5 유형:
      • hallucinated workflow stage 또는 미지원 행동
      • 필수 정보 수집 누락
      • 실행 전 명시적 확인 누락
      • 잘못된 보상 처리
      • 금지된 행동
    • 결함 유형이 구분되기에 점수 평가를 넘어선 진단 도구로 사용 가능하다고 주장

Personal note. 개인적으로는 tau bench 연구자들이 직접 건드는 문제라 관심이 가서 읽었는데, 본인 연구 포함 최근 벤치마크 연구들을 메타레벨에서 지적하려는 연구라고 보입니다. 아쉬운점부터 언급하면 LLM judge가 보는 입력(policy 문서, description, expected behavior)이 generator가 봤던 입력과 사실상 동일하고, 그 품질에 대한 근거가 강한 모델이 더 좋은 벤치마크를 만든다는 컨벤션인데, 그 가정의 독립 검증은 저자 본인 1명이 매긴 50개 task…?인 부분이 되게 큰 한계로 느껴지기는 하고요.. 좀 눈에 띄게 마음에 걸린 부분은 human validation이 judge-human 일치를 확인했는데 (여기까지는 그럴듯한데) 그걸 다시 generator-품질 가정의 근거로 되돌려 쓰는 순환논리 흐름이 타당한건지 의심스럽기는 하고요… 다만 필요한 연구의 시발점은 될 것 같습니다. 어쨌든 프레이밍하기로는 LLM이 문제를 풀어놓은 다음 평가해야되는 문제를 피하고자 실제 벤치마크를 execute하지는 않는다는걸 셀링포인트로 잡긴 하는데 그럼에도 불구하고 어쨌든 벤치마크의 존재 이유가 agent 변별해보겠다라면 실제 이 프레임워크 상에서 점수 높은 벤치마크가 실제로 agent를 더 잘 변별하는지는 한번은 재봤어야하지 않나? 싶긴 합니다. 그래도 소개해보고 싶었던 이유는 그냥 관련있냐를 물어보면 당연 관련있다고 대답할테니, 대신 제약을 위반했는지로 카운팅하게 한 점은 똑똑했던 것 같습니다. 뭔가 리워드 모델링 할 때 써봄직 한 것도 같고..