τ-bench

LLM 이 상담원으로서 고객과 대화하며 업무 규칙대로 요청을 처리하는지 평가한다

τ-bench(tau-bench)는 Sierra 의 Yao, Shinn, Razavi, Narasimhan 이 2024 년 6 월 발표한 벤치마크다. 이름의 τ 는 Tool-Agent-User 의 머리글자로, 도구(tool)·에이전트(agent)·사용자(user) 셋이 주고받는 상황을 평가한다는 뜻이다. 무대는 항공권 예약 변경, 온라인 쇼핑몰 반품 같은 고객 상담이다. 논문

논문이 겨냥한 부족은 세 가지다.

1. 사용자가 없다. 기존 에이전트 벤치마크는 필요한 정보를 처음에 모두 주고 에이전트가 혼자 행동하게 한다. 실제 상담에서는 사용자가 정보를 조금씩 꺼내고, 요청을 섞거나 바꾼다. BFCL 같은 도구 사용 벤치마크도 사용자가 지시 한 번에 필요한 정보를 다 주는 형태였다.
2. 지켜야 할 정책이 없다. 실제 서비스에는 “기본 이코노미 항공권은 변경할 수 없다” 같은 도메인 규칙이 있다. 에이전트가 이 규칙을 문서로 받아 따르는지는 기존 벤치마크가 보지 않았다.
3. 한 번 성공과 매번 성공을 구분하지 않는다. 고객 상담 에이전트는 같은 종류의 요청을 수천 번 처리한다. 한 번 시켜서 성공한 비율보다, 같은 과제를 여러 번 시켰을 때 매번 성공하는지가 더 중요하다. 이를 보려고 논문은 pass^k 라는 지표를 새로 정의했다.

항목	내용
만든 곳	Sierra (Yao, Shinn, Razavi, Narasimhan)
공개	2024-06-17 arXiv
규모	τ-retail 115 과제, τ-airline 50 과제
환경	가상 데이터베이스와 Python 도구, 정책 문서, LLM 사용자 시뮬레이터
지표	대화가 끝난 뒤 데이터베이스와 에이전트 발화가 정답 조건을 만족한 비율(pass^1)과 pass^k
후속	τ²-bench (2025-06), τ³-bench (2026-03)

환경은 세 참여자로 이루어진다

LLM 이 둘 등장한다: 평가받는 상담원과 고객 역할

τ-bench 를 한 번 돌리면 LLM 두 개가 서로 대화한다. 하나는 평가받는 LLM 이고, 다른 하나는 그 LLM 의 대화 상대가 되어 주는 LLM 이다.

	에이전트	사용자 시뮬레이터
정체	평가받는 LLM	사람 고객을 대신하는 LLM
맡는 역할	쇼핑몰·항공사의 상담원	문의하는 고객
처음에 받는 것	정책 문서와 도구 목록	과제 지시문 (고객이 누구이고 무엇을 원하는지)
실행마다 바뀌는가	비교하려는 모델로 바꿔 끼운다 (gpt-4o, claude-3-opus 등)	모든 실행에서 같은 모델로 고정한다 (원 논문 gpt-4-0613)
채점되는가	이 LLM 의 성공률이 벤치마크 점수다	채점하지 않는다

뒤의 결과 표에서 “gpt-4o 가 쇼핑몰 61.2%” 라는 말은, gpt-4o 를 상담원 자리에 넣고 gpt-4-0613 이 연기하는 고객과 대화시켰을 때 61.2% 의 과제를 해결했다는 뜻이다.

 사용자 시뮬레이터           <--- 대화 --->    에이전트                 <--- 도구 호출 --->  도메인 API
 (고정된 LLM, 고객 역할,                       (평가받는 LLM, 상담원 역할,                    (데이터베이스 읽기·쓰기)
  과제 지시문을 앎)                             정책 문서와 도구 목록을 앎)

• 사용자 시뮬레이터 는 에이전트가 보낸 메시지를 보고, 과제 지시문에 맞는 고객의 다음 말을 생성한다. 에이전트의 도구 호출은 보지 못한다. 원하는 일이 끝났다고 판단하면 ###STOP### 을 출력해 대화를 끝낸다.
• 에이전트 는 고객의 말을 듣고, 정책 문서를 따르며, 도구를 function calling 으로 호출해 요청을 처리한다. 데이터베이스는 도구를 통해서만 볼 수 있다.
• 도메인 API 는 JSON 데이터베이스를 읽고 쓰는 Python 함수들이다. 주문 조회처럼 상태를 바꾸지 않는 읽기 도구 와, 반품·예약 변경처럼 데이터베이스를 바꾸는 쓰기 도구 로 나뉜다.

사용자는 temperature 1.0 으로 샘플링하고 에이전트는 0.0 으로 돌린다 (§5). 사용자의 말투와 정보를 꺼내는 순서가 실행마다 달라지므로, 같은 과제라도 대화가 매번 다르게 흘러간다. 뒤의 pass^k 는 이 차이를 이용한다.

두 도메인

	τ-retail	τ-airline
과제 수	115	50
데이터베이스	사용자 500, 상품 50, 주문 1,000	사용자 500, 항공편 300, 예약 2,000
쓰기 도구	7 개	6 개
읽기 도구	8 개	7 개

출처: 논문 Table 1. 읽기 도구에는 계산기(calculate)와 상담원 연결(transfer_to_human_agents)도 포함된다.

정책 문서는 Markdown 으로 쓴 규칙 목록이다. 항공 정책에는 “기본 이코노미 항공편은 변경할 수 없다”, “그 밖의 기본 이코노미·이코노미 항공편은 여행자 보험을 샀을 때만 취소할 수 있다” 같은 문장이 있다. 쇼핑몰 정책에는 “교환이나 주문 수정 도구는 한 번만 호출할 수 있다” 가 있다.

과제 하나의 모습

논문 Figure 2(d) 의 쇼핑몰 과제다. 사용자 시뮬레이터가 받는 지시문은 대략 이렇다.

당신은 우편번호 80217 에 사는 Mei Davis 다. 물병은 반품하고, 펫 침대와 사무용 의자는 가장 싼 버전으로 교환하고 싶다. 두 가지를 한 번에 말하라. 둘 중 하나만 할 수 있다면 돈을 더 아끼는 쪽을 원하지만, 두 방법 각각으로 얼마를 아끼는지는 알고 싶다. 오늘은 빚이 있어 우울하지만 말은 아주 짧게 한다.

정답 주석은 두 부분으로 되어 있다.

1. 데이터베이스에 남아야 할 변경: return_delivered_order_items(order_id="#W2890441", item_ids=["2366567022"], payment_method_id="credit_card_1061405") 한 건. 교환은 없고 반품만 있다.
2. 에이전트가 사용자에게 말해야 할 값: 54.04 와 41.64. 지시문이 두 방법 각각의 금액을 알려 달라고 했으므로 이 두 값이 그 금액으로 보인다. 논문은 각 값의 의미를 따로 적지 않았다.

논문은 지시문을 정책과 사용자 선호를 함께 따졌을 때 결과가 하나만 나오도록 다듬었다고 설명한다. 정답에 교환 없이 반품만 있으므로, 정책과 주문 상태상 두 요청을 다 들어줄 수는 없고 반품 쪽이 사용자에게 더 유리하도록 설계된 과제로 읽힌다. 논문은 이 판단의 근거를 따로 적지 않았다. 이 해석대로라면 에이전트가 거쳐야 할 흐름은 다음과 같다.

1. 사용자 신원을 확인하고 주문 내역을 조회한다.
2. 반품과 교환을 둘 다 할 수 있는지 정책과 주문 상태를 대조한다.
3. 둘 중 하나만 가능하다는 것을 알리고, 두 방법으로 아낄 수 있는 금액을 각각 계산해 말한다.
4. 사용자가 반품을 고르면, 명시적 동의를 받은 뒤 반품 도구를 호출한다.

에이전트는 사용자가 무엇을 원하는지 처음부터 알지 못한다. 지시문은 사용자 시뮬레이터만 보므로, 선호와 조건은 대화로 알아내야 한다.

대화가 끝나는 조건과 행동 횟수 상한

대화는 무제한으로 이어지지 않는다. 원 τ-bench 코드에서 대화가 끝나는 경우는 셋이다. 환경 코드, 에이전트 루프

1. 사용자 시뮬레이터가 ###STOP### 을 출력한다. 시뮬레이터의 system prompt 는 “지시문의 목표가 이뤄지면 ###STOP### 만 출력해 대화를 끝내라” 고 지시한다. 고객이 원하는 일이 끝났다고 판단하는 쪽은 에이전트가 아니라 시뮬레이터다.
2. 에이전트가 상담원 연결 도구 transfer_to_human_agents 를 부른다. 이 도구는 쇼핑몰·항공 도메인에서 대화를 끝내는 종료 도구로 지정되어 있다.
3. 에이전트의 행동 횟수가 상한에 닿는다. 기본값은 30 번이다. 행동 한 번은 에이전트가 도구를 하나 호출하거나 사용자에게 메시지를 하나 보내는 것이다. 사용자 시뮬레이터의 말은 세지 않는다.

채점은 1 이나 2 로 끝났을 때만 한다. 3 으로 끝나면 그때 데이터베이스가 우연히 정답과 같더라도 그 실행은 0 점이다. 대화 중간에 메시지마다 채점하지도 않는다. 대화가 끝난 시점의 데이터베이스와 에이전트가 한 말을 한 번만 검사한다. 검사 방법은 아래 채점 절에 있다.

따라서 에이전트는 30 번 안에서라면 되묻고, 조회하고, 다시 확인하는 데 몇 번을 써도 된다. 대신 끝없이 확인만 하다가 상한에 닿거나, 일을 마치기 전에 상담원 연결로 넘겨 버리면 실패한다.

이 상한은 논문 본문에 없는 코드 기본값이다. τ²-bench 코드는 기준이 다르다. 에이전트·사용자·도구 사이에 메시지가 한 번 오가는 것을 한 단계로 세어 기본 200 단계까지 허용하고, 도구 호출 오류가 10 번 쌓여도 중단한다. 에이전트나 사용자가 정상적으로 끝낸 경우 말고는 모두 0 점이다. τ²-bench 설정, 채점 코드

과제를 만든 과정

1. 사람이 설계: 데이터베이스 스키마, API, 정책을 실제 서비스를 단순화해 손으로 만든다.
2. LLM 이 데이터 생성: 예시 항목 하나를 주면 GPT-4 가 비슷한 항목을 대량으로 만드는 코드를 쓴다. 작은 버그는 사람이 고친다.
3. 사람이 과제 주석: 지시문 초안으로 GPT-4-turbo 에이전트를 돌려 보고, 결과가 하나로 정해질 때까지 지시문을 고친다. 쇼핑몰 과제는 과제마다 40 번 넘게 돌려 봤다 (Figure 7).

채점: 대화가 끝난 뒤의 데이터베이스를 본다

한 번의 실행을 성공으로 칠 조건

대화가 끝나면 두 가지를 검사한다 (§3).

$$r=r_{\text{action}}\times r_{\text{output}}\in \{0,1\}$$

기호	의미
$r_{\text{action}}$	대화 후 데이터베이스가 정답 주석의 데이터베이스와 정확히 같으면 1
$r_{\text{output}}$	에이전트가 사용자에게 보낸 메시지에 정답 주석의 값(앞 예시의 54.04, 41.64)이 모두 들어 있으면 1
$r$	둘 다 1 일 때만 성공

에이전트가 어떤 순서로 도구를 불렀는지는 보지 않는다. 결과 상태만 맞으면 된다. 그래서 같은 결과에 이르는 여러 경로를 모두 정답으로 인정할 수 있고, 정답 경로 하나를 미리 정해 둘 필요가 없다.

다만 논문도 밝히듯 $r=1$ 은 성공의 필요조건일 뿐 충분조건은 아니다. 정책은 쓰기 도구를 부르기 전에 사용자의 명시적 동의를 받으라고 하는데, 동의 없이 반품을 처리해도 데이터베이스 상태는 같으므로 성공으로 채점된다.

pass^k 는 k 번 모두 성공할 확률이다

한 과제를 $n$ 번 독립적으로 돌려 $c$ 번 성공했다고 하자. 논문은 두 지표를 다음처럼 추정한다.

$${\text{pass}}^k={\mathbb{E}}_{\text{task}}\left[\frac{\left(\genfrac{}{}{0ex}{}{c}{k}\right)}{\left(\genfrac{}{}{0ex}{}{n}{k}\right)}\right]\text{pass@}k=1-{\mathbb{E}}_{\text{task}}\left[\frac{\left(\genfrac{}{}{0ex}{}{n-c}{k}\right)}{\left(\genfrac{}{}{0ex}{}{n}{k}\right)}\right]$$

기호	의미
$n$	한 과제를 실행한 횟수
$c$	그중 성공한 횟수
$k$	몇 번의 실행을 한 묶음으로 볼지
$\left(\genfrac{}{}{0ex}{}{c}{k}\right)/\left(\genfrac{}{}{0ex}{}{n}{k}\right)$	$n$ 번의 실행 중 $k$ 개를 무작위로 골랐을 때 모두 성공인 확률
${\mathbb{E}}_{\text{task}}$	이 값을 모든 과제에 대해 평균

pass^k 는 k 번 시켰을 때 k 번 모두 성공할 확률이다. 얼마나 믿고 맡길 수 있는지(신뢰성)를 본다. 코드 생성 벤치마크에서 쓰던 pass@k 는 k 번 중 한 번이라도 성공할 확률로, 해법을 찾아낼 수 있는지를 본다. $k=1$ 이면 둘은 같은 값(평균 성공률)이고, 논문의 기본 지표도 pass^1 이다.

같은 실행 기록으로 두 지표를 계산해 보자. 한 과제를 4 번 돌려 2 번 성공했다($n=4$, $c=2$).

지표	계산	값
pass^1	$\left(\genfrac{}{}{0ex}{}{2}{1}\right)/\left(\genfrac{}{}{0ex}{}{4}{1}\right)=2/4$	0.50
pass^2	$\left(\genfrac{}{}{0ex}{}{2}{2}\right)/\left(\genfrac{}{}{0ex}{}{4}{2}\right)=1/6$	0.17
pass@2	$1-\left(\genfrac{}{}{0ex}{}{2}{2}\right)/\left(\genfrac{}{}{0ex}{}{4}{2}\right)=1-1/6$	0.83

$\left(\genfrac{}{}{0ex}{}{4}{2}\right)=6$ 은 4 번의 실행에서 2 개를 고르는 경우의 수이고, 그중 둘 다 성공인 경우는 성공한 2 번을 고르는 1 가지뿐이다. 같은 기록인데 k = 2 에서 pass@2 는 0.83 으로 오르고 pass^2 는 0.17 로 내려간다. k 가 커질수록 이 차이는 더 벌어진다.

pass^k 가 떨어지는 속도는 과제별 성공률의 분포에 달려 있다

어떤 과제의 성공 확률이 $p$ 이고 실행끼리 독립이면 그 과제의 pass^k 는 $p^k$ 다. 평균 성공률이 60% 인 에이전트라도, 그 60% 가 과제들에 어떻게 나뉘어 있느냐에 따라 pass^8 이 크게 다르다.

경우	과제별 성공 확률	pass^1	pass^8
(가) 모든 과제에서 성공이 운에 달려 있다	모든 과제 $p=0.6$	0.60	$0.6^8\approx 0.017$
(나) 되는 과제는 늘 되고 안 되는 과제는 늘 안 된다	60% 과제는 $p=1$, 40% 과제는 $p=0$	0.60	0.60

(가) 에서는 pass^8 이 2% 아래로 떨어지고, (나) 에서는 pass^1 과 같다. 논문에서 gpt-4o 는 쇼핑몰 도메인 pass^1 이 60% 를 넘지만 pass^8 은 25% 미만이었다 (§5, Figure 4). 두 극단의 사이, 즉 상당수 과제에서 성공과 실패가 실행마다 갈린다는 뜻이다. pass^1 만 보면 이 차이가 보이지 않는다.

발표 당시 결과

모델별 pass^1

논문 Table 2 에서 일부를 옮겼다. 과제마다 최소 3 번 실행한 평균이다. Llama-3 는 생각과 도구 호출을 텍스트로 번갈아 쓰는 ReAct 형식으로, 나머지는 모델 API 의 function calling 기능으로 도구를 불렀다.

모델	τ-retail	τ-airline
gpt-4o	61.2	35.2
gpt-4-turbo	57.7	32.4
claude-3-opus	44.2	34.7
mistral-large	30.7	22.4
gemini-1.5-pro	21.7	14.0
gpt-3.5-turbo	20.0	10.8
meta-llama-3-70B	14.8	14.4

가장 잘한 gpt-4o 도 두 도메인 평균이 50% 를 넘지 못했다. 항공 도메인이 더 어려운데, 다음 절의 정책 제거 실험이 그 이유를 보여 준다.

정책 문서를 빼면

정책 문서를 system prompt 에서 빼고 같은 과제를 돌린 결과다 (§5.2 의 ablation).

모델	도메인	정책 있음	정책 없음
gpt-4o	τ-retail	61.2	56.8
gpt-4o	τ-airline	33.2	10.8

쇼핑몰은 정책을 빼도 4 점 남짓만 떨어지고, 항공은 3 분의 1 로 떨어진다. 쇼핑몰의 반품·교환 규칙은 상식으로 대부분 짐작되지만, 항공의 요금 등급별 변경·취소 조건 같은 규칙은 문서를 읽지 않으면 알 수 없다고 해석할 수 있다. 그런데 정책을 주어도 항공은 33.2% 에 머문다. 규칙을 읽고도 대화 중의 구체적인 상황에 맞게 적용하지 못하는 경우가 많다는 뜻이다. (이 ablation 의 정책 있음 수치 33.2 는 Table 2 의 35.2 와 다르다. 별도 실행으로 보인다.)

무엇 때문에 실패하나

gpt-4o 의 쇼핑몰 과제 115 개를 한 번씩 돌려 40 개가 실패했다. 그중 4 개는 사용자 지시문의 오타나 모호함 때문이었고 36 개가 에이전트의 실패였다 (§5.2). 에이전트 실패는 세 유형으로 나뉜다. 비율은 실패 사례 중 비중이다.

• 잘못된 인자나 정보: 가장 많았다. 도구에 넘긴 인자가 틀렸거나, 사용자에게 틀린 정보를 준 경우다.
• 잘못된 판단: 약 25%. 도메인 지식이 부족하거나 정책과 다르게 처리한 경우다.
• 복합 요청의 일부만 처리: 약 19%. 반품과 교환을 함께 요청했는데 하나만 처리하고 끝낸 경우로, 쓰기 작업이 많은 과제일수록 잦았다.

한계와 후속 버전

원 논문이 밝힌 한계

• 사용자 시뮬레이터도 틀린다. LLM 사용자가 지시문과 다른 말을 하거나, 계산을 틀리거나, 긴 대화에서 앞 내용을 잊을 수 있다. 이 오류가 에이전트의 점수로 계산된다.
• 정책 준수를 다 검사하지 못한다. 앞의 채점 절에서 본 것처럼, 쓰기 전에 동의를 받았는지는 데이터베이스 상태로 드러나지 않는다.
• 주석이 어렵다. 결과가 하나만 나오는 지시문을 쓰려면 도메인과 에이전트를 모두 잘 알아야 하고, 그래도 오류가 남는다. 이후 여러 차례 과제 수정이 이어진 이유다.
• 도메인이 둘뿐이다. 도구도 모두 합쳐 28 개다.

τ²-bench: 사용자도 도구를 쓴다

τ²-bench 는 Sierra 와 University of Toronto 의 Barres et al. 이 2025 년 6 월 발표했다. 논문

τ-bench 에서는 에이전트만 도구를 쓰고, 사용자는 정보를 말로 전달할 뿐이었다. 통신사 기술 지원 같은 상황은 다르다. 문제가 사용자의 휴대폰에 있으면, 에이전트는 휴대폰을 직접 조작할 수 없고 사용자에게 “비행기 모드를 꺼 보세요” 라고 안내해 사용자가 하게 해야 한다. τ²-bench 는 이렇게 에이전트와 사용자가 같은 환경을 각자의 도구로 바꾸는 상황(dual control) 을 새 telecom 도메인으로 만들었다.

telecom 도메인	내용
과제	114 개 (생성한 2,285 개 중에서 골라 냄)
에이전트 도구	쓰기 6, 읽기 7. 요금제·회선·고객 데이터베이스
사용자 도구	쓰기 15, 읽기 15. 신호 세기 같은 상태를 가진 가상 휴대폰
사용자 시뮬레이터	gpt-4.1-2025-04-14
채점	대화 후 휴대폰 상태에 대한 검사 함수(assertion)가 모두 통과하는지

과제 하나는 이렇게 생겼다 (부록 A.2). 과제 이름 [service_issue]airplane_mode_on|unseat_sim_card 가 구성 요소를 나타낸다.

1. 초기화: 가상 휴대폰의 비행기 모드를 켜고 SIM 카드를 빼 둔다. 사용자는 화면에 “서비스 없음” 이 뜬다고만 말한다.
2. 해결: 에이전트가 원인을 좁혀 가며 안내하고, 사용자가 비행기 모드를 끄고 SIM 을 다시 꽂는다.
3. 검사: 휴대폰의 서비스 상태가 “connected” 인지 확인한다.

과제는 손으로 하나씩 쓰지 않고 생성기로 만든다. “비행기 모드 켜짐”, “SIM 빠짐” 같은 작은 고장(atomic subtask)마다 초기화·해결·검사 함수를 하나씩 만든다. 고장은 동시에 일어날 수 없는 것끼리 15 개 그룹으로 묶여 있고, 그룹마다 최대 하나씩 골라 조합하면 2,285 개 과제가 나온다. 여기서 문의 유형(서비스 불가, 모바일 데이터 불가, MMS 불가)과 고장 개수가 고르게 섞이도록 114 개를 골랐다.

같은 과제를 세 가지 방식으로 돌려 실패 원인을 나눴다 (§4.2).

모드	에이전트가 받는 것	무엇을 분리하나
Default	사용자와 대화하며 사용자가 휴대폰을 조작	기본 설정
No-User	문제 설명서를 받고 사용자 도구까지 직접 조작	사용자와 소통하는 부담을 뺀 추론 능력
Oracle Plan	정답 도구 호출 순서까지 받음	무엇을 해야 할지 알 때의 소통·실행 능력

No-User 모드의 pass^1 은 Default 보다 gpt-4.1 에서 약 18 점, o4-mini 에서 약 25 점 높았다. 같은 문제를 혼자 고칠 때보다 사용자를 통해 고치게 할 때 성공률이 그만큼 떨어진다는 뜻이다.

Default 모드 pass^1 은 gpt-4.1 이 쇼핑몰 74%, 항공 56%, telecom 34% 였다. telecom 에서 o4-mini 는 42%, claude-3.7-sonnet 은 49% 였다 (서론 기준). 모든 과제를 4 번씩 돌려 pass^k 를 계산했다.

τ²-bench 는 사용자 시뮬레이터의 오류도 직접 셌다 (Table 2). 오류 중 과제 완료를 불가능하게 만드는 것(사용자 목표와 반대되는 요청을 하거나, 되돌릴 수 없는 상태로 만드는 것)을 critical 로 따로 분류했다.

도메인	분석한 대화	시뮬레이터 오류	그중 critical
airline	100	47%	13%
retail	50	40%	12%
telecom	50	16%	6%

논문은 telecom 의 오류율이 낮은 이유를 사용자 행동을 도구와 휴대폰 상태에 묶어 둔 설계에서 찾는다. 사용자가 할 수 있는 일이 도구로 정해져 있고 자기 휴대폰 상태를 도구로 확인하니, 지시문에 없는 사실을 지어낼 여지가 줄어든다. 반면 airline·retail 에서는 대화의 열에 하나 이상에서 시뮬레이터가 과제 자체를 망칠 수 있다. 이 두 도메인에서 실패로 기록된 실행 가운데 일부는 에이전트가 아니라 시뮬레이터 때문이다.

τ²-bench 는 원래의 airline·retail 과제도 다시 검토해, 조건이 부족하거나 넘치거나 답이 여러 개인 과제를 고쳤다 (부록 B.2).

τ³-bench 와 그 이후

Sierra 는 2026 년 3 월 τ³-bench 를 발표했다. 저장소 이름은 여전히 tau2-bench 이다. Sierra 연구 페이지, 저장소

• 지식 검색 도메인 τ-Banking 추가: 핀테크 고객 상담으로, 서로 연결된 약 700 개 문서에서 필요한 규정을 찾아 계정을 바꾸는 과제다. 추론 토큰을 많이 쓰도록 설정한 최상위 모델도 pass^1 약 25.5% 에 그쳤고, 반복 실행에서 신뢰성이 크게 떨어졌다. τ-Knowledge 논문
• 음성 평가 추가: 텍스트 대신 실시간 음성으로 시뮬레이터 사용자와 통화하는 모드.
• 과제 수정 75 건 이상: 저장소 README 는 이 수정의 근거로 SABER (2025-11) 를 연결한다. 이 논문은 τ-bench 과제의 주석 오류와 조건 부족이 모델 점수의 상한을 인위적으로 눌러 왔다고 지적하고, 고친 판인 τ-Bench Verified 를 냈다.

2026-07 의 v1.0.1 은 τ-Banking 채점 오류를 고쳤으므로, 그 전 버전의 τ-Banking 점수와는 직접 비교할 수 없다. 2026-10 확인 기준 저장소 README 는 6 개 언어로 확장한 τ-bench 2.0 을 안내하며, 2.0 의 영어 결과도 1.x 리더보드 점수와 비교할 수 없다고 밝힌다. 리더보드는 taubench.com 에 있다.

τ-bench 계열의 점수를 인용할 때는 버전, 도메인, 사용자 시뮬레이터 모델, 행동 횟수 상한, 실행 횟수와 k 를 함께 적어야 비교가 성립한다. 기본값이 논문과 다른 경우도 있다. 원 τ-bench 의 실행 스크립트는 사용자 시뮬레이터 기본값이 gpt-4o 인데, 논문 실험은 gpt-4-0613 을 썼다. run.py 다른 에이전트 벤치마크와의 비교는 LLM Agent Benchmarks 에 모았다.

References

• Yao et al. (2024), τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
• Barres et al. (2025), τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment
• Shi et al. (2026), τ-Knowledge: Evaluating Conversational Agents over Unstructured Knowledge
• Cuadron et al. (2025), SABER: Small Actions, Big Errors — Safeguarding Mutating Steps in LLM Agents
• sierra-research/tau2-bench — 2026-10 확인