0. Abstract
기존 한계
- Language Agent가 사람 사용자와 상호작용하는 능력이나 domain-specific한 능력을 평가하지 않음.
- → but, real world application을 위해서는 꼭 필요!
제안
τ -bench
- 사용자 역할을 LLM이 대신하는 대화 시뮬레이션
- 외부 API나 정책 가이드라인 등 규칙이 있는 환경에서 제공받은 agent의 능력 평가
- 대화 후 db의 상태를 목표 상태와 비교하여 평가
pass^k
- agent의 행동 신뢰도를 여러 번 반복 실행하여 평가할 수 있도록 새로운 평가지표 pass^k 제안
결과
- GPT-4o와 같은 SOTA function calling agent 마저도 작업의 절반을 성공하지 못함.
- retail domain에서는 pass^8 수치가 25% 미만일 정도로 일관성이 부족
- agent가 일관되게 행동하고 규칙을 잘 따를 수 있도록 개선하는 방법이 필요함.
1. Introduction
현황
- 다양한 산업에서 자동화를 할 수 있는 language agent의 기대가 높아지고 있음.
- 현실 세계 시스템에 적용하기 위한 필수 요건 존재
- 사용자와 API와 장기적으로 상호작용하며 정보를 수집하고 문제를 해결해야함.
- 도메인 특화된 복잡한 정책이나 규칙을 정확하게 준수해야함.
- 일관성과 신뢰성 유지해야함. (같은 작업의 요청이 왔을 때 같은 결과! + 말투 혹은 표현의 변화에도 잘 작동해야함)
한계
- 현재 존재하는 agent benchmark들은 대부분 단순화된 instruction following 형태임.
- agent가 web, code terminal, API와 자율적으로 상호작용하지만 모든 정보가 처음부터 한 번에 주어진 형태
- 사람과의 실시간 상호작용 부재
- 도메인 특화된 규칙, 정책의 부재
제안
- τ -bench: Tool-Agent-User Interaction Benchmark
- 도메인 특화 규칙을 준수하면서 agent가 simulated human user와 programmatic API와 상호작용하는 능력 평가
- 모듈형 프레임워크로 제작
- DB, API
- 도메인 특화된 policy 문서
- 다양한 사용자 시나리오에 대한 지침과 그에 맞은 ground truth 주석
- 고객 서비스 분야에 집중
- 소매와 항공 → 사용자와 다양한 요청을 처리해아하는 두 가지 domain
- LLM으로 data 생성 (사용자 생성) + 사람이 직접 만든 주석 및 검증 작업도 수행
- 세 단계에 걸쳐서 구축됨.
- 스키마 및 API를 수작업으로 설계
- LLM으로 data entry 생성
- 사용자 simulator에 사용할 시나리오 수작업 생성 및 검증
- episode가 종료되면 db의 상태의 목표상태와 비교하여 평가
- pass^k 메트릭 도입
- k번의 독립적인 반복 시도에서 agent의 일관성 및 견고함 평가
결과
- function calling이나 ReAct처럼 단순한 구조만 가진 agent는 성능이 매우 낮음.
- GPT-4o조차도 function calling만 사용했을 때 τ-retail에서는 약 61%, τ-airline에서는 약 35% 성능을 보임.
- 반복 횟수 k가 늘어날수록 일관성 급격히 감소.
- τ-retail에서 pass^8 기준 성공률은 25% 수준까지 떨어짐.
- agent들이 표현의 다양성이나 불완전한 정보를 다룰 때 매우 취약함을 보여줌.
- 복잡한 추론, 새로운 규칙 이해, 복합 요청 처리에 약함.
2. τ -bench: A benchmark for Tool-Agent-User Interaction
Agent가 사람과 API를 함께 다루는 task를 모델링하기 위해서 마르코프 결정 과정(POMDP)로 표현
S: 상태공간 = 데이터베이스 상태($S_{db}$) ⊗ 사용자 상태($S_{user}$)
A: 행동공간 = DB에 대한 행동($A_{db}$) ∪ 사용자에 대한 응답($A_{user}$)
O: 관측공간 = DB 관측($O_{db}$) ∪ 사용자 대화 관측($O_{user}$)
T: 전이함수 = $S×A→S×O$
R: 보상함수 = $S → [0, 1]$
U: 지시공간 = 사용자로부터 주어지는 요청
+ domain-specific policy document
Databases and APIs
- 각 τ -bench에는 여러 개의 db와 api들이 있음.
- $s_{db}$를 구성하며 오직 API action $a_{db}$에 의해서만 접근하여 rw 가능.
- DB에 어떤 행동을 수행하면 $s’{db}$와 $o{db}$로 전이 발생
Domain policy
- 각 domain에는 policy 문서가 있음.
- 해당 domain의 DB 구성, 작업 절차, agent가 따라야할 제약 조건 설명
- 어떤 제약 조건은 API 내부에서 자동으로 검사되기도 함. (사용자 프로필에 없는 결제 ID 사용하는 경우 $o_{db}$로 에러 메시지 반환)
- 일부 조건은 agent가 스스로 판단해야함. (항공 domain에서 좌석에 따라서 수화물 허용량이 다르지만 agent가 예약 API 호출 시 얼마만큼의 수하물 추가 요금을 낼지 채워 넣어야함.)
User simulation
- gpt-4-0613로 사람 사용자와 상호작용하는 역할 시뮬레이션함.
- $s_{user}$: 태스크 설명이 담긴 초기 시스템 프롬프트 + 대화 history (agent와 user사이)
- 에이전트의 말 → 대화 이력에 추가 → LLM이 새 사용자 응답 생성(= 확률적 반응, 항상 똑같이 말하지 않음)
- 사용자 발화가 **“###STOP###”**이면 에피소드 종료 → 성공 여부 평가
Task instances
- τ-bench의 각 태스크 인스턴스는 두 부분으로 구성
- 사용자 시뮬레이션용 지시문 – 에이전트에겐 보이지 않음
- 사용자 ID, 목적, 선호도 등
- DB 쓰기 행동에 대한 정답 주석(annotation)
- DB에 정확히 어떤 행동을 해야 하는지 + 사용자 응답에 들어갈 핵심 정보
- 사용자 시뮬레이션용 지시문 – 에이전트에겐 보이지 않음
- 도메인 정책에 따라 결과가 하나로 정해지도록 설계됨
Reward
- $r = r_{\text{action}} \times r_{\text{output}}$: 값은 0 or 1
- DB의 최종 상태가 정답 DB 상태와 일치하면 $r_{\text{action}} = 1$
- 에이전트의 사용자 응답에 필요한 정보가 모두 포함되어 있으면 $r_{\text{output}} = 1$
- 위의 두 조건 모두 만족해야 r = 1
- 단, r = 1이 나왔다고 해도 동의 없이 환불 등과 같은 정책 위반이 있었다면 실제로는 실패로 간주될 수 있음.
- 현재 평가 지표는 rule-based 방식이지만 그럼에도 현재 agent들이 제대로 수행하지 못함.
- 복잡한 정책 판단까지 넣었을 경우는 더 성능이 떨어질 것임!
Pass^k metric
- 코드 생성 등 발견 지향 태스크에서는 주로 pass@k를 사용함.
- pass@k: k번 독립적으로 실행했을 때 그 중 적어도 1번 성공할 확률
- 고객 응대와 같이 신뢰성과 일관성이 중요한 실환경 태스크에서는 새로운 평가 지표 제안
- pass^k: 같은 태스크를 k번 독립적으로 수행했을 때, 전부 성공할 확률
- 의미는 같고 규칙도 동일한 상황에서, 에이전트가 정책을 잘 지키며 동작하는지를 평가
3. Benchmark Construction
- 여러 도메인에서 공통으로 쓸 수 있는 환경 클래스와 사용자 시뮬레이션 클래스 제공
- 도메인에 특화된 데이터
- 데이터베이스 JSON 파일
- API 파이썬 코드와 문서
- 도메인 정책 텍스트
- 태스크 인스턴스
- Stage I: Manual design of database schema, APIs, and policies
- Stage II: Automatic data generation with LMs
- Stage III: Manual task annotation and validation with agent runs
3.1 Domains
- τ-retail
- τ-airline
4. Experiments
Models
- OpenAI GPT API
- → gpt-4o, gpt-4-turbo, gpt-4-32k, gpt-3.5-turbo
- Anthropic Claude API
- → claude-3-opus, claude-3-sonnet, claude-3-haiku
- Google Gemini API
- → gemini-1.5-pro-latest, gemini-1.5-flash-latest
- Mistral API
- → mistral-large, open-mixtral-8x22b
- AnyScale API (Meta)
- → meta-llama-3-70B-instruct
Methods
- Function Calling (FC): 도메인 정책을 시스템 프롬프트에 넣고, 모델이 응답 or 툴 호출 중 선택
- ReAct (text format): Thought: ... Action: {...} 형식으로 추론 + 행동 생성
- 최소 3회 이상 반복 설정
- 최대 30회까지 agent가 행동을 할 수 있음.
- agent는 일관성을 위해 LM temperature를 0.0으로, user는 다양성을 위해 1.0으로 설정
5.1 Main results
Model comparsion
- GPT-4o가 Function Calling 방식에서 가장 성능 높음
Method comparison
- SOTA 모델들에서는 Function Calling이 항상 더 우수한 성능을 보임.
Agent consistency via pass^k
- 같은 태스크를 여러 번 성공적으로 수행할 확률은 k가 커질수록 급격히 떨어짐.
5. Discussion
- τ-bench라는 새로운 벤치마크를 제안
- 에이전트를 자동으로 테스트할 수 있으며, domain규칙을 일관되게 잘 따르는지 평가 가능