ICML 2026 · τ²-Bench · Conversational Agent Evaluation

사용자도 행동하는
대화형 에이전트 벤치마크

이 페이지는 “Evaluating Conversational Agents in a Dual-Control Environment” 논문의 전체 구조를 한국어 기술문서 형식으로 재구성한 웹페이지다. 핵심 메시지는 단순하다. 실제 고객지원 환경에서는 에이전트만 도구를 쓰지 않는다. 사용자도 기기를 조작하고, 상태를 바꾸고, 에이전트의 안내를 실행한다. τ²-Bench는 이 dual-control 조건을 벤치마크의 중심 문제로 끌어올린다.

Agent

Domain PolicyCRM DBRead/Write Tools

정책을 지키면서 사용자 문제를 진단하고, 필요한 도구 호출과 설명을 조합한다.

Shared World

User

ScenarioPhone DBDevice Tools

에이전트 요청에 반응해 상태바 확인, 비행기 모드 토글, SIM 재장착 같은 행동을 수행한다.

5G · Signal 4Battery 80%
모바일 데이터가 너무 느리다.
상태바와 데이터 설정을 확인하라.
user_tools.check_status_bar() → Data Disabled
모바일 데이터를 켜고 속도 테스트를 다시 실행하라.
Problem Framing

기존 벤치마크의 공백: 단일 제어에서 이중 제어로

τ-Bench 계열의 기존 대화형 에이전트 평가에서는 에이전트가 세계를 바꾸는 도구를 사용하고, 사용자는 목표와 선호를 말하는 수동 정보 제공자에 가깝다. 그러나 기술지원, 통신장애 해결, 기기 설정 변경 같은 실제 고객지원 문제에서는 사용자가 직접 조작해야 한다.

2
제어 주체

에이전트와 사용자가 각각 도구를 갖고 같은 세계 상태에 영향을 준다.

3
Telecom intent

service_issue, mobile_data_issue, mms_issue를 중심으로 난이도를 구성한다.

2285
생성 가능한 full task

15개 atomic subtask group을 조합해 검증 가능한 대규모 태스크 공간을 만든다.

~20%
dual-control 전환 손실

No-User에서 Default로 바꾸면 pass^1이 큰 폭으로 낮아진다.

1. Dual-Control Environment

에이전트와 사용자가 서로 다른 도구와 관측 공간을 가진다. 사용자는 단순 응답자가 아니라 환경을 조작하는 참여자다.

2. Compositional Generator

초기화 함수, 해결 함수, assertion 함수를 가진 atomic subtask를 조합해 정답 검증 가능성과 도메인 커버리지를 동시에 확보한다.

3. Reliable User Simulator

사용자 시뮬레이터를 자연어 프롬프트만으로 통제하지 않고, 사용자 도구와 관측 가능한 상태로 강하게 제약한다.

4. Failure Diagnosis

Default, No-User, Oracle Plan을 비교해 순수 추론 실패와 의사소통·조정 실패를 분리한다.

Formal Model

τ²-Bench의 Dec-POMDP 형식화

논문은 dual-control 대화를 Decentralized Partially Observable Markov Decision Process로 정의한다. 핵심은 두 참여자가 동일한 전역 상태를 공유하지만, 각자 다른 도구, 관측, 정보, 행동 가능성을 가진다는 점이다.

정의

(S, {Aᵢ}, {Oᵢ}, T, R, U, M), i ∈ {agent, user}

전역 상태 S = S_world ⊗ S_history는 agent-side CRM, user-side phone state, 전체 상호작용 기록으로 구성된다. 매 턴에는 정확히 한 참여자만 메시지 또는 도구 호출을 수행한다.

설계 효과

사용자 행동을 도구로 제한하면 사용자 시뮬레이터가 임의 정보를 꾸며내는 공간이 줄어든다.

에이전트 평가는 “정답 계획을 아는가”뿐 아니라 “사용자가 올바른 행동을 하도록 유도하는가”까지 포함한다.

기술지원처럼 상태 확인, 원인 진단, 순차적 조치가 필요한 문제를 더 사실적으로 모델링한다.

Message M

사용자와 에이전트가 교환하는 자연어 메시지 전체 공간.

Action Aᵢ

도구 호출 또는 메시지. 사용자도 toggle_airplane_mode() 같은 write tool을 사용할 수 있다.

Observation Oᵢ

도구 반환값 또는 상대 메시지. 각 참여자는 부분 관측만 받는다.

Reward R

최종 상태가 assertion을 만족하는지에 따라 성공/실패 보상을 부여한다.

Domain Construction

Telecom 도메인과 태스크 생성 파이프라인

논문은 telecom을 새로운 dual-control 도메인으로 구현한다. 에이전트는 고객·회선·요금제·청구서·기기 DB를 조회·수정하고, 사용자는 모의 스마트폰의 상태를 확인·변경한다.

Agent DB & Tools

LLM이 PRD, schema, 함수 구현, mock DB, unit test를 생성하고 사람이 정제한다.

User DB & Tools

사용자 측 phone state와 read/write device tool을 만든다.

Programmatic Tasks

초기화·해결·검증 함수로 atomic subtask를 정의하고 조합한다.

Agent Policy

통신 기술지원 절차와 도메인 정책을 생성한다.

Manual Refinement

도구, 정책, subtask, task assertion을 함께 검토해 품질을 개선한다.

도메인 통계

항목RetailAirlineTelecom
Agent DB500 users, 50 products, 1,000 orders500 users, 300 flights, 2,000 reservations5 plans, 9 lines, 4 customers
Agent Tools7 write, 6 read6 write, 6 read6 write, 7 read
User Tools--15 write, 15 read
Tasks11550114 sampled / 2285 full

Atomic Subtask 구조

각 subtask t는 세 요소로 정의된다.

t = ({f_init_t,k}, {f_sol_t,k}, {f_assert_t,k})

init 문제 상태를 만든다. 예: 비행기 모드 ON.

solution 문제를 해결하는 agent/user tool sequence다.

assertion 최종 세계 상태가 해결 조건을 만족하는지 검증한다.

service_issue

통화·문자·기본 셀룰러 연결이 동작하지 않는 문제. 평균 해결 action 2.31개.

mobile_data_issue

모바일 데이터가 연결되지 않거나 너무 느린 문제. 평균 해결 action 4.31개.

mms_issue

사진·그룹 메시지 등 MMS 송수신 문제. 평균 해결 action 6.00개로 가장 어렵다.

Experimental Results

성능 결과: dual-control은 현재 LLM의 약점이다

실험은 gpt-4.1, gpt-4.1-mini, o4-mini, claude-3.7-sonnet을 평가한다. user simulator는 gpt-4.1이고, 각 task는 temperature 0에서 4회 실행된다.

가장 쉬운 조건

Retail은 전반적으로 가장 높은 성공률을 보인다. claude-3.7-sonnet의 retail pass^1은 0.79다.

가장 어려운 조건

Telecom은 dual-control 때문에 더 어렵다. gpt-4.1은 retail 0.74, airline 0.56에서 telecom 0.34로 떨어진다.

일관성 문제

Telecom은 k가 증가할수록 pass^k가 더 빠르게 낮아진다. 반복 실행 안정성까지 취약하다는 뜻이다.

RetailAirlineTelecom

Original Policy

Workflow Policy

Default

에이전트와 사용자가 실제처럼 협업한다. reasoning과 coordination이 모두 필요하다.

No-User

에이전트가 사용자 도구까지 직접 제어한다. 사용자 안내 부담을 제거해 순수 추론·도구 사용 능력을 본다.

Oracle Plan

정답 도구 호출 sequence를 제공한다. 계획 수립 부담을 제거하고 실행·협업 능력만 본다.

Issue type별 평균 pass^k

Persona type별 평균 pass^k

핵심 패턴은 명확하다. 서비스 문제는 상대적으로 쉽고, 모바일 데이터와 MMS는 선행 조건 확인과 다단계 진단이 필요해 실패율이 높다. Easy persona가 Hard persona보다 대체로 높은 성공률을 보이며, persona를 명시하지 않는 None 조건도 반드시 쉬운 조건은 아니다.

DomainConversationsCritical ErrorsBenign ErrorsTotal Errors해석
airline10013 (13%)34 (34%)47 (47%)자연어 지시 기반 simulator의 오류가 가장 크다.
retail506 (12%)14 (28%)20 (40%)대화 구조 위반, 조기 종료, 누락 constraint가 발생한다.
telecom503 (6%)5 (10%)8 (16%)도구로 사용자 행동을 제약해 총 오류율이 크게 낮아진다.

Retail failure

대화 구조 위반 11/20, 조기 종료 3/20, 비근거 참조 2/20, constraint 누락 4/20.

Airline failure

constraint 누락 11/47, 대화 구조 위반 19/47, 비근거 참조 15/47, 조기 종료 2/47.

Telecom failure

annotated 8개 오류가 모두 조기 종료다. 도구 기반 제약이 hallucination형 오류를 줄인다.

Appendix Compression

부록까지 포함한 구조화 요약

부록은 형식 정의, telecom 세부 태스크, 예시 trajectory, 원본 τ-Bench 검증, 프롬프트, 도메인 정책, 기술지원 workflow graph, user simulator 오류 유형, LLM 사용 내역으로 구성된다.

A. Full Dec-POMDP Formalism

Message, State, Action, Observation, Transition, Reward, Instruction space를 각각 정의한다. 핵심은 S_world가 agent DB와 user DB로 나뉘며, S_history가 메시지와 도구 호출 기록을 저장한다는 점이다.

B. Telecom Domain, Persona, Task Factorization

Persona

Easy는 스마트폰 기본 기능에 익숙하고 단계별 안내를 잘 따른다. Hard는 64세 은퇴한 사서로 기술 용어와 기기 조작에 불안감을 가진다.

Decomposition Property

IsTriggered_I(s) ⇔ ⋁ⱼ RCⱼ(s)

사용자에게 보이는 issue는 하나 이상의 독립 root cause가 활성화될 때만 발생한다.

Subtasksservice_issuemobile_data_issuemms_issueTotal
298825
398926
496621
5+2142642
Total293649114
B.4-B.6 Example Task and Trajectories

대표 예시는 [service_issue]airplane_mode_on|unseat_sim_card다. 사용자는 John Smith이며 전화번호는 555-123-2002다. 초기 상태는 비행기 모드 ON과 SIM 카드 미장착이다. 성공 조건은 assert_service_status(expected_status="connected")가 참이 되는 것이다.

Default trajectory에이전트가 사용자에게 네트워크 상태 확인을 요청한다. 사용자는 도구로 비행기 모드와 SIM 상태를 확인한다. 에이전트가 비행기 모드 OFF와 SIM 재장착을 순서대로 안내한다.
No-User trajectory에이전트가 모든 agent/user tool을 직접 호출한다. 대화 조정 비용이 제거되고 순수 해결 sequence 실행 능력이 평가된다.
C. Original τ-Bench Verification

구현 오류를 줄이기 위해 통합 tool formalism, domain data model, mock domain unit test를 사용한다. 태스크 오류를 줄이기 위해 구조화된 task metadata, 평가 기준 분리, 반복 review process, programmatic generation을 적용한다.

D. Prompts

Agent prompt는 정책을 따르며 한 턴에 메시지 또는 도구 호출 하나만 수행하도록 제한한다. User prompt는 자연스러운 대화를 생성하되 scenario instruction을 엄격히 따르고, agent가 요청한 경우에만 user tool을 호출하도록 제한한다. 완료 시 ###STOP###, 전환 시 ###TRANSFER###, 정보 부족 시 ###OUT-OF-SCOPE###를 사용한다.

E. Domain Policies

Retail

사용자 인증, pending/delivered order 처리, 명시적 확인, 환불 방식, 교환/반품 규칙을 엄격히 정의한다.

Airline

예약 생성·변경·취소, cabin class, passenger, baggage, insurance, compensation 규칙을 포함한다.

Telecom

고객 조회, 연체 청구서 결제, 회선 정지 해제, 데이터 refueling, 요금제 변경, 로밍, 기술지원 정책을 포함한다.

E.2.4 Telecom Troubleshooting Workflow Graphs

service_issue

상태바 확인 → 비행기 모드 확인 → SIM 상태 확인 → APN reset + reboot → 회선 정지 원인 확인 → 결제/재개 또는 human transfer.

mobile_data_issue

속도 테스트 → service issue 선행 해결 → roaming/data switch/data usage 확인 → refuel 또는 plan 변경 → data saver, network mode, VPN 확인.

mms_issue

MMS 가능 여부 확인 → service와 mobile data 선행 검증 → 2G 여부, Wi-Fi Calling, app permission, MMSC URL/APN 확인.

F-G. User Simulator Quality and LLM Use

retail과 airline 오류는 대화 구조 위반, constraint 누락, 비근거 참조, 조기 종료가 주요 원인이다. telecom 오류는 모두 조기 종료 형태로 나타난다. 논문 작성 과정에서 LLM은 문법 교정, 문장 흐름 개선, 용어 일관성 유지에만 사용되었다고 밝힌다.

Technical Takeaways

연구적 시사점과 한계

τ²-Bench는 “에이전트가 정답을 아는가”보다 “사용자를 올바르게 움직이게 만드는가”를 평가한다는 점에서 실사용형 에이전트 벤치마크 설계에 중요한 전환점을 제공한다.

시사점

상태를 가진 사용자 도구는 사용자 시뮬레이터의 신뢰성을 높인다. 또한 Default/No-User/Oracle Plan 비교는 reasoning, planning, communication, coordination 오류를 분해하는 실용적 방법을 제공한다.

한계

도메인 확장은 여전히 전문가 개입에 의존한다. airline/retail에도 user tool을 적용하는 일반화가 아직 검증되지 않았다. 또한 실제 고객지원의 expert-novice gap, 즉 사용자의 정신모형에 맞춘 설명 적응 능력은 명시적으로 모델링하지 않는다.

한 문장 정리

τ²-Bench의 핵심 기여는 대화형 에이전트 평가를 “도구를 잘 쓰는 단일 에이전트”에서 “도구를 가진 사용자와 함께 불완전한 정보를 조정하는 협업 시스템”으로 확장한 데 있다.