카테고리 없음

[2026-1] 김다정, 황징아이 - TaU2-Benchmark

ggoddll 2026. 3. 18. 22:31

1.  데이터셋의 구성 의의

$\tau^2$-Benchmark는 대화형 에이전트와 시뮬레이션된 사용자 사이에서 이루어지는 multi-turn interaction을 체계적으로 연구하기 위해 제안된 밴치마크이다.

 

기존 Single-Control 벤치마크의 한계

기존의 대화형 AI 에이전트 벤치마크는 대부분 single-control 환경을 가정한다. 에이전트만이 도구(tool)를 사용하여 환경과 상호작용하고, 사용자는 단순히 정보나 선호도를 제공하는 역할에 그친다. 하지만 이러한 설정은 실제 상황의 복잡성을 충분히 반영하지 못한다는 한계가 있다.

 

사용자와 에이전트의 협업 필요성 (Dual-Control의 도입 배경)

실생활에서는 에이전트와 사용자가 함께 문제를 해결하는 협업 상황이 자주 발생한다.

예를 들어 Technical Support (IT지원)과 같은 상황에서는 에이전트가 해결방법 안내를 하고 사용자가 에이전트의 지시에 따라 기기를 재부팅하거나 설정을 바꾸는 등 공유된 환경의 상태를 직접 수정해야 하는 경우가 빈번히 발생한다. 따라서 이러한 협업 상황을 평가하기 위해 Dual-Control 환경을 시뮬레이션하는 밴치마크가 필요하다.

$\tau^2$-bench에서는 에이전트와 사용자가 서로 메시지를 주고받으며 대화하고, tool을 사용해 환경과 상호작용하며, 환경으로부터 다양한 정보를 얻는 상황을 시뮬레이션한다

→ 에이전트와 사용자가 모두 도구를 사용하여 상호작용하는 Dec-POMDP 프레임워크를 소개.

 

2. 데이터셋 예시

출처 : Artificial Analysis

ex. 1)

ex.2) 

 

3. 데이터셋 관련 통계

$\tau^2$ 밴치마크는 기존 $\tau$밴치마크에서 사용된 Retail과 Airline 도메인에 새로운 Telecom 도메인을 추가하였다.

Telecom 도메인에서 총 2,285개의 생성 가능한 작업중에서 균형 잡힌 분포를 가지는 114개의 작업을 최종적으로 샘플링하였다. 이 도메인은 기존 Retail와 Airline도메인보다 더 복잡한 문제 해결과정과 에이전트 사용자 협업을 요구한다.

새롭게 추가된 Telecom 도메인은 3가지 주요 이슈 유형 (Service issue, Mobile data issue, MMS issue)으로 구성된다.

이러한 구성을 통해 \tau^2-bench는 에이전트가 복잡한 시나리오에서 인간 사용자와 효과적으로 협력하여 문제를 해결할 수 있는지를 테스트할 수 있다.

 

4. 데이터셋 구축 방법론

$\tau^2$-Bench에서는 Dual-control interaction을 Decentralized Partially Observable Markov Decision Process (Dec-POMDP)로 모델링 한다. 에이전트와 사용자가 동시에 환경에 영향을 줄 수 있는 상황을 수학적으로 표현하는 모델이라고 볼 수 있다.

 

Dec-POMDP

Dec-POMDP는 두 명의 플레이어(Agent와 User)로 구성되며 다음과 같은 요소를 포함한다.

  • Message Space : Agent와 User 사이에서 주고받는 대화 내용
  • State Space : State는 크게 두가지 (World State와 History State로)로 구성된다.
    • World State는 환경의 실제 상태를 의미한다. 예를 들어 telecom 도메인에서는 agent 가 접근할 수 있는 고객 데이터와 user의 휴대폰 설정 상태로 구성이 되어 있다.
    • History State에서 모든 기록들이 저장하게 된다.
  • Action Space : Agent와 User가 환경에서 수행할 수 있는 행동들로 구성된다. 예를 들어 Agent는 고객 정보를 조회할 수 있고 User는 네트워크 설정 변경과 같은 행동이 가능하다.
  • Observation Space : Agent와 User 각각 환경에서 얻을 수 있는 정보로 구성된다. 예를 들어 Agent는 고객의 상세정보를 확인할 수 있고 User는 휴대폰의 비행기모드가 켜져 있다와 같은 시스템 메시지를 확인할 수 있다.
  • Transition Function : 현재 state와 agent + user가 했던 행동들을 알면 새로운 state와 observation로 업데이트가 된다.
  • Reward Function : 0~1 사이의 값을 출력하고 현재 상태를 기준으로 task 성공 여부를 평가하는 global reward이다. 문제 해결에 성공을 했다면 높은 reward가 주어지고 실패를 하게 되면 낮은 reward를 갖게 되어 학습을 한다.
  • Instruction Space : Agent가 User에 대해 미리 알고 있어야하는 정보를 담고있다. 예를 들어 사용자의 현재 상황, task 정보, 예상 해결 방안 등이 포함될 수 있다.

Dec-POMDP를 사용한 이유

현실적인 협업 환경을 모델링하고 사용자 행동이 더 예측 가능해지고 자연어 프롬프트에 과도하게 의존하지 않아도 된다. 따라서 더 안정적인 사용자 시뮬레이션 환경을 만들 수 있다.

 

밴치마크 구축 방법

$\tau^2$-bench는 기존 $\tau$-bench와 유사하게 5개의 단계를 거쳐서 태스크를 구성한다.

  1. Agent Database와 Tools 생성 : LLM을 활용하여 Agent가 알아야 할 해당 도메인의 지식을 담은 Product Requirement Document (PRD)를 생성.
  2. User Database와 Tools 생성 : LLM을 활용하여 User가 사용할 데이터베이스와 도구를 생성. 사용자의 기기 상태와 사용자가 실행할 수 있는 도구를 정의. 예를 들어 Telecom 도메인에서는 휴대푠의 신호크기와 비행기모드를 끄고 킬 수 있는 도구를 생성하게 된다.
  3. Task 생성 : atomic building blocks를 이용하여 여러개의 subtask들을 생성하고 subtask들이 하나의 그룹으로 묶어 하나의 task를 구성한다. Subtask $t$는 해결 해야하는 구체적인 문제이고 하나의 subtask는 다른 subtask를 유발할 수 있다. 예를 들어 비행기모드가 켜져 있으면 데이터가 잡히지 않는 문제가 발생할 수 있다. 각 Subtask는 세가지 요소로 구성된다. 
    • Initialization Function : 초기 상태를 설정하는 함수이고 데이터베이스에 있는 값을 변경하여 문제 상황을 생성할 수 있다. (ex. set airplane mode = True)
    • Solution Function : 문제를 해결하기 위해 실행해야 하는 tool (ex. toggle airplane mode)
    • Assertion Function : task가 해결되었는지를 판단하는 최종상태 조건 (ex. assert service status connected)
    해당 Task가 성공했다고 판단되기 위해서는 모든 solution function을 실행하고 모든 assertion function을 통과해야 성공으로 간주된다. (최종 상태가 모든 조건을 만족해야 함)
  4. Domain Specific Agent Policy 생성 : Agent가 따라야하는 정책을 생성. LLM을 활용하여 문제 해결 규칙, 수행해야 할 단계, 도메인별 행동 가이드라인과 같은 domain-specific policy를 생성. Agent가 어떤 순서로 문제를 해결해야 하는지에 대한 규직을 정의
  5. Manual Refinement : 마지막 단계에서는 사람이 직접 도메인 자료를 검토하고 수정하여 더 정확하고 현실적인 형태로 개선

→ 기존 $\tau$-bench와의 차별점 : User Persona 도입. 사용자는 난이도에 따라 Easy User (어느 정도 도메인 지식이 있고 문제 해결이 비교적 수월함)와 Hard User(어르신, 기기를 잘 다루지 못하는 사용자)로 나눠서 Persona 설정을 통해 사용자에 맞게 시뮬레이션 환경을 만들 수 있다.

 

5. 데이터셋 평가 방법론

  • 총 4개의 LLM을 사용하여 평가했다 : 
    • gpt-4.1-mini
    • gpt-4.1
    • o4-mini
    • claude-3.7-sonnet

도메인별 성능 비교

  • Telecom 관련 도메인을 추가한 이유
    • 각 모델에 대해 Retail, Airline, Telecom 세 가지 도메인에서 성능을 평하 task마다 총 4번 run하고 결과는 Pass@K 지표를 통해 측정하였다. 전반적으로 Telecom은 성공률이 다른 분야에 비해 더 낮게 나타나는 경향이 있다. → Telecom 관련 작업이 다른 도메인보다 문제 해결 과정이 복잡하고 여려 단계의 추론이 필요한 가능성을 시사한다. Telecom 관련 Task를 밴치마크로 필요한 이유를 증명.
  • $\tau^2$-bench에서 에이전트의 성공 여부를 평가하는 기준
  1. 사용자와 얼마나 잘 소통하고 협력하여 문제를 해결하는가
  2. 정책 문서(policy document)에 포함된 도메인 지식을 얼마나 잘 추론하고 적용하는가
  • 분석 하기 위해 세가지 다른 설정에서 평가를 진행하였다.
  1. Default (Dual Control) : 에이전트와 사용자가 dual-control 환경에서 협력하며 문제를 해결
  2. No-User : 에이전트가 모든 권한을 가지고 단독으로 문제를 해결하고 에이전트의 추론 능력과 도구 호출(tool calling) 능력을 평가
  3. Oracle-Plan : 정답 행동 순서가 주어진 상태에서 에이전트가 사용자와 협력하여 해당 계획을 실행할 수 있는지 평가

 

평가결과 

 

[Figure. 4]

  • Dual-Control 환경에서의 성능 변화 : No-User와 Oracle-Plan에 비해 dual-control 환경에서는 정확도가 감소하는 현상이 나타났다. 이는 Agent가 환경의 제어 권한을 사용자와 공유하는 상황에서 문제를 해결하는 것이 여전히 어려움을 겪고 있다는 것을 보여준다.
  • Policy Document가 에이전트 성능에 미치는 영향 분석 : workflow 기반 정책 문서(오른쪽 그래프) 는 에이전트에게 더 구체적인 가이드라인을 제공. default이랑 no-user모드에서는 workflo 정책 문서가 기존 정책 문서보다 성능을 향상시켰지만 oracle plan에서는 오히려 성능을 떨어뜨리는 결과가 나타났다.
  • → 에이전트는 정답을 알고 있는 상황에서 새로운 정보가 제공되면 오히려 불필요한 혼란을 유발하여 성능을 저하시켰다고 설명.

 

[Figure. 6]

  • Telecom 도메인은 세 가지 주요 사용자 의도로 구성되어있다. (쉬운문제에서 복잡한 문제 순으로 service issue, mobile data issue, mms issue) mobile data issue와 mms issue 같은 복잡한 문제 유형에서 multi-stage 추론과 의사결정을 요구하기 때문에 에이전트의 실패율이 높게 나타났다.

 

[Figure. 7]

  • 사용자 페르소나가 에이전트 성능에 미치는 영향 : Easy Persona에서는 에이전트 성능이 더 높게 나타내고 Hard Persona에서는 성능이 상대적으로 낮게 나왔다. 다만 흥미로웠던 점은 페르소나 정보가 전혀 없는 경우의 성능이 Hard Persona와 비슷하거나 오히려 더 낮게 나타난다는 점이다.

→ 실제 환경에서 AI 시스템을 배포하기 전에 명확하게 정의된 사용자 페르소나를 기반으로 시스템을 테스트하는 것이 매우 중요하다는 것을 보여줌.

 

벤치마크 신뢰성 

  • 질문 : 평가 결과가 실제 모델 능력을 정확하게 반영할 수 있을까?
    1. Implementation Error : 밴치마크 시스템 자체의 코드에 문제가 생겨 잘못 구현되어 있을 가능성이 있다.
      → Implementation Error를 최소화하기 위해 : 모든 도메인에서 tool 형식을 통일. 각 도메인만다 데이터 모델을 정의. mock domain을 도입하면서 전체 시스템이 아니라 특정 기능만 분리해서 검증.
    2. Task Specification Error : Task 정의 자체가 잘못된 경우 (Task Logic 오류, 목표 상태가 잘못 정의한 경우)
      → Task Clarity and Correctness를 자체적으로 평가. 예를 들어서 각 task에서 단순한 task 설명이 아니라 task가 무엇을 테스트하는지에 대한 metadata도 추가되어 있다. 그리고 평가기준도 세분화를 합니다. 기존에는 성공과 실패만으로 평가를 했다면 environment assertion, communication assertion, natural language assertion, action assertion등 과정까지 평가를 합니다.
    3. User Simulation Error : 사용자를 대신하는 User Simulator 모델이 잘못 행동하는 경우 (agent가 실패했지만 실제로는 user simulator가 문제인 경우도 있을 수 있습니다.)
      → GPT4.1를 사용해서 agent + user simulator interaction을 생성하여 두명의 annotator가 4가지 기준(정해진 규칙을 잘 따르는지, 사용자 목표를 따르는지, tool을 올바르게 사용하는지, 대화가 자연스러운지)에 따라서 검토.
  • 벤치마크에서는 체계적인 검증 과정까지 포함해서 신뢰할 수 있는 평가 환경을 구축했다고 볼 수 있다.

6. 데이터셋 현재 벤치마크 성적

https://artificialanalysis.ai/evaluations/tau2-bench

논문에서는 소매(Retail) 및 항공(Airline) 도메인도 다루고 있으나, 논문에서 강조하는 '이중 제어'와 '사용자 가이드' 능력에 대한 분석은 주로 통신(Telecom) 도메인을 중심으로 이루어져 있어 통신(Telecom) 도메인에서의 성능을 비교한다.

 

Q1. 파라미터 수가 늘수록 점수가 오를까?

1. Llama

  • Llama 3.3 70B
  • Llama 3.2 3B > Llama 3.2 11B (Vision) > Llama 3.2 1B
  • Llama 3.1 405B > Llama 3.1 8B > Llama 3.1 70B

➡️ 뚜렷한 경향성이 보이지 않는다.

2. Qwen (3.5끼리 비교)

  • Qwen 3.5 397B A17B (95.6%) > Qwen 3.5 27B (93.9%) > Qwen 3.5 122B A10B (93.6%) > Qwen 3.5 4B (92.1%) > Qwen 3.5 35B A3B > …

➡️ 뚜렷한 경향성이 보이지 않는다.

➡️ Qwen 3.5 2B, Qwen 3.5 0.8B를 제외하고는 성능이 비슷하다.

3. Gemma

  • Gemma 3 12B > Gemma 3 27B > Gemma 3 1B > …

➡️ 뚜렷한 경향성이 보이지 않는다.

 

Q2. 주요 frontier 모델 성적은?

Grok 4.20 Beta 0309 (96.5%) > Gemini 3.1 Pro Preview (95.6%) > Claude Opus 4.6 (max) (92.1%) > GPT-5.4 (xhigh) (91.5%) > DeepSeek V3.2 (90.6%)

 

Q3. 오픈소스 최강자 대비 정확도

  • Qwen 3.5 397B A17B (95.6%) > Qwen 3.5 27B (93.9%) > Qwen 3.5 122B A10B (93.6%) > Qwen 3.5 4B (92.1%)

➡️ Qwen 3.5가 비슷한 성적을 보인다.

 

Q4. Frontier 모델 계열 내 경향

Q5. Frontier 모델 내 Reasoning 모드 차이

1. GPT (5)

  • GPT-5 Codex > GPT-5 > GPT-5 mini > GPT-5 nano
  • GPT-5 (medium) > GPT-5 (high) > GPT-5 (low) > GPT-5 (minimal)
    • medium이 high보다 0.7%p 높은 성능을 보였다.

2. Claude

  • Claude Opus 4.6 (Adaptive Reasoning, Max Effort) (92.1%) > Claude Opus 4.6 (Non-reasoning, High Effort) (84.8%) > Claude Sonnet 4.6 (Non-reasoning, High Effort) (79.5%) > Claude Sonnet 4.6 (Non-reasoing, Low Effort) (78.9%) > Claude Sonnet 4.6 (Adaptive Reasoning, Max Effort) (75.1%)
    • Opus > Sonnet
    • Opus (Reasoning, Max Effort) > Opus (Non-reasoning, High Effort)
    • Sonnet (Non-reasoning, High Effort) > Sonnet (Non-reasoning, Low Effort) > Sonnet (Reasoning, Max Effort)
  • Claude Opus 4.5 (Reasoning) (89.5%) > Claude Opus 4.5 (Non-reasoning) (86.3%) > Claude 4.5 Sonnet (Reasoning) (78.1%) > Claude 4.5 Sonnet (Non-reasoning) (70.5%) > Claude 4.5 Haiku (Reasoning) (54.7%) > Claude 4.5 Haiku (Non-reasoning) (32.5%)
    • Opus > Sonnet > Haiku
    • Reasoning > Non-reasoning

3. Grok

  • Grok 4.20 Beta 0309 (Reasoning) (96.5%) > Grok 4.1 Fast (Reasoning) (93.3%) > Grok 3 mini Reasoning (high) (90.4%) > Grok 4 (74.9%) > Grok 4.20 Beta 0309 (Non-reasoning) (69.6%) > Grok 4 Fast (Reasoning) (65.8%) > Grok 4.1 Fast (Non-reasoning) (63.7%) = Grok 4 Fast (Non-reasoning) (63.7%) > Grok 3 (48.8%)
    • Grok 4 > Grok 4 Fast
    • Reasoning > Non-reasoning

4. Gemini

  • Gemini 3.1 Pro Preview (95.6%) > Gemini 3 Pro Preview (high) (87.1%) > Gemini 3 Flash Preview (Reasoning) (80.4%) > Gemini 3 Pro Preview (low) (68.1%) > Gemini 3 Flash Preview (Non-reasoning) (43.3%) > Gemini 3.1 Flash-Lite Preview (31.3%)
    • Pro > Flash
    • Reasoning > Non-reasoning

Q6. 한국 파운데이션 모델 성적

Mi:dm K 2.5 Pro (86.5%) > K-EXAONE (Reasoning) (74.3%) > K-EXAONE (Non-reasoning) (59.1%) > Solar Open 100B (Reasoning) (48.2%)

6. 데이터셋 관련 연구

  1. 대화형 AI 에이전트를 위한 벤치마크
    1. $\tau$-bench (타우 벤치): 최근 도입된 핵심 벤치마크로, 고객 서비스(소매, 항공 분야) 같은 다회차 대화에서 AI가 도메인 규칙을 지키며 업무를 얼마나 잘 완수하는지 측정한다. $pass^k$라는 지표를 통해 성공률을 수치화한다.
    2. 관련 후속 연구
      • FlowBench: 자연어나 순서도 등을 통해 AI에게 명시적인 작업 흐름(Workflow) 지식을 주입하여 계획 능력을 테스트한다.
      • IntellAgent: 도메인 규칙이 담긴 그래프를 통해 자동으로 테스트 세트를 생성하는 효율적인 도구이다.
      • APIGen-MT: 대화 청사진(도구 호출 순서)을 만들어 AI를 미세 조정(Fine-tuning)하는 연구입니다.
      • ToolSandbox: 상태가 변하는 도구를 만들어 AI의 진행 상황을 더 세밀하게 평가한다.
      차별점: 기존 $\tau$-bench를 확장하여, AI뿐만 아니라 사용자도 공유된 환경에서 상태를 바꿀 수 있는 능력(도구 호출 등)을 갖도록 만들었다. 이를 통해 더 복잡한 상황을 테스트하고 AI의 실패 지점을 정밀하게 분석할 수 있다.
  2. 대화형 에이전트를 위한 사용자 시뮬레이션 AI 에이전트를 테스트하려면 대화 상대방인 '사용자’ 역할을 할 프로그램(시뮬레이터)이 필요하다.
    • 신뢰성 문제: 기존에는 단순히 LLM이 사용자 역할을 하도록 시키는 데 집중했지만, 본 연구는 환경(Environment) 자체를 활용해 사용자의 행동을 제약하고 유도함으로써 시뮬레이션의 신뢰도를 높이는 데 초점을 맞춘다.
    • 사용자 시뮬레이터가 상태 추적(State tracking)을 잘할수록 더 맥락에 맞는 대화가 가능해진다는 기존 연구 결과를 바탕으로 한다.
  3. 다중 에이전트(Multi-Agent) 벤치마크 여러 AI가 상호작용하는 시스템과의 관련성을 설명한다.
    • 비대칭적 관계: 이 연구의 시스템은 사용자(시뮬레이터)와 AI 에이전트가 함께 존재하므로 다중 에이전트 시스템처럼 보이지만, 목적은 다르다.
    • 핵심 목표: 순수한 협동/경쟁보다는, 에이전트가 사용자로부터 올바른 정보를 끌어내고 적절한 행동을 취해 문제를 해결하는 능력을 평가하는 데 집중한다.
    • 다양한 시나리오
      • 협력적: 함께 문제를 해결하는 문제 해결(Troubleshooting)
      • 경쟁적: 구독 서비스 해지 방어 같은 협상(Negotiation)
      • 혼합형: 사용자의 실수나 오류까지 계산하며 대화를 이끌어가는 능력

7. 한계점

  • 사용자 시뮬레이터의 도메인 확장성 부족: 도구와 환경을 결합하여 사용자 시뮬레이터의 신뢰성을 높이는 방법론을 제안했지만, 이를 기존의 항공(Airline)이나 소매(Retail) 도메인에 어떻게 적용할 수 있을지에 대해서는 아직 연구가 이루어지지 않았다.
  • 도메인 구축의 수동성: 새로운 도메인을 벤치마크에 추가하는 과정이 여전히 인간 전문가의 개입에 크게 의존하고 있다. 연구진은 산업계에서 널리 활용되기 위해서는 도메인 큐레이션 과정을 자동화하는 연구가 필수적이라고 언급했다.
  • 전문가-초보자 간의 간극 미반영: 실제 고객 지원 상황에서는 전문가(에이전트)가 기술적 지식이 부족한 초보자(사용자)의 멘탈 모델을 이해하고 그에 맞춰 설명을 조정해야 한다.
  • 장기 작업(Long-horizon tasks)에서의 신뢰성 저하: 실험 결과, 에이전트가 수행해야 할 행동(action)이 많아질수록(7개 이상) 성공률이 0에 가깝게 떨어졌다. 이를 통해 사용자와의 의사소통뿐만 아니라 긴 단계의 작업을 안정적으로 처리하는 능력 자체가 여전히 현재 AI 에이전트들의 큰 병목 구간임을 알 수 있다.
  • 사용자 시뮬레이터의 잔여 오류: 이전 벤치마크들에 비해 신뢰성이 크게 향상되었음에도 불구하고, 통신 도메인의 사용자 시뮬레이터는 여전히 16%의 전체 오류율과 6%의 치명적 오류율을 보인다. 특히 대화가 완료되기 전에 미리 종료해버리는 등의 문제가 발생하기도 했다.