05. τ-bench와 pass^k

쉽게 읽기

한 줄: 에이전트 평가에서 “정답 한 번 맞춘 것”보다 “매번 일관되게 맞추는가”가 더 중요하다는 걸 보여준 벤치마크 — 같은 문제를 k번 풀어 다 맞은 비율(pass^k)을 측정한다.

비유: 시험에서 한 번 100점 받는 것과 5번 시험에서 5번 다 100점 받는 것은 다른 능력. 운으로 한 번 맞은 학생과 진짜로 아는 학생을 구분하는 채점 방식.

이 문서에서 챙길 3가지

1. pass@k(k번 시도 중 한 번이라도 성공)와 pass^k(k번 모두 성공)는 정반대의 관점 — 후자가 진짜 신뢰성 측정
2. τ-bench는 시뮬레이션 사용자와 멀티턴 대화로 평가하고, 작업 완료 + 정책 준수까지 봐서 “꼼수 결과”를 잡아냄
3. 본 실험에서도 같은 태스크 3회 반복(P3 pass^3)으로 Hermes 학습 징후를 잡으려 함

1. 정의

τ-bench (tau-bench)는 Sierra가 2024년 공개한 tool-using 에이전트의 실제 도메인 평가 벤치마크다. 두 가지가 핵심 차별점:

1. 사용자도 시뮬레이션 — 정답 입력 한 줄이 아닌, 시뮬레이션 사용자와의 멀티턴 대화 속에서 에이전트를 평가.
2. 정책 준수까지 측정 — 작업을 완료했어도 도메인 규칙(환불 정책, 변경 수수료 등)을 어기면 fail.

두 도메인 (retail, airline)을 갖고 있으며, 각 태스크는 데이터베이스 종료 상태 를 정답 상태와 비교해 평가한다. 추가로 pass^k 라는 일관성/신뢰성 메트릭을 도입해 산업계에 큰 영향을 주었다.

후속작 τ²-bench (2025)는 dual-control conversational 평가로 확장. 사용자와 에이전트 둘 다 행동 권한이 있는 상황을 본다.

2. 핵심 메커니즘

2.1 환경 구조

[시뮬레이션 사용자 (LLM, persona + goal 보유)]
        ⇅ 자연어 대화
[평가 대상 에이전트 (function-calling LLM)]
        ⇅ 툴 호출
[도메인 DB + 정책 문서]

사용자 LLM: 페르소나(예: “내 항공편 변경하고 싶다, 출발일 임박”) + 숨긴 goal(예: “수수료 면제 받기”). 에이전트 응답에 자연스럽게 반응.

에이전트: 툴 (DB 조회·수정 API) + 시스템 프롬프트(정책 문서) 부여. 사용자 요청을 정책에 맞게 처리해야 함.

평가: 대화 종료 시 DB 상태 ≡ 정답 상태? + (선택) 정책 위반 step 카운트.

2.2 정책 준수의 의미

τ-bench의 진짜 가치는 여기 있다. 단순 task completion은 다른 벤치도 한다. τ-bench는:

“옳은 결과로 가는 과정에서 정책을 어기지 않았는가.”

예시 — airline 도메인의 정책:

• “출발 24시간 이내 변경은 풀-수수료”
• “마일리지 회원 골드 등급 이상은 1회 면제”

에이전트가 사용자 동정심에 휘둘려 정책 외 면제 를 해주면 — DB 상태는 사용자 만족(변경됨) 이지만, 회사 정책 위반. fail.

이게 LLM 에이전트의 새로운 약점을 드러냈다: agreeableness가 비즈니스 손해로 직결.

2.3 pass^k — 일관성 메트릭

기존 벤치마크는 보통 pass@k (= k번 시도 중 적어도 한 번 성공) 를 본다. ICML 코드 평가의 표준.

τ-bench는 정반대인 pass^k 를 도입:

$$\text{pass}^k = \Pr[\text{모든 } k\text{ 회 시도가 성공}]$$

중요: ^ 은 지수 (모두 성공). @ 은 집합 (적어도 하나).

메트릭	정의	측정하는 것
pass@1	1회 시도 성공률	평균 능력
pass@k	k회 시도 중 1+ 성공 비율	다양 sampling으로 최선 발견 (벤치 가능성)
pass^k	k회 모두 성공 비율	재현성/신뢰성

왜 이게 중요한가? 프로덕션에서 한 고객을 한 번만 응대하지 않는다. 100명이 같은 요청을 했을 때 99명에게 정상, 1명에게 정책 위반은 큰 문제. pass^k는 그걸 잡는다.

보고된 SOTA 수치 (논문): 함수호출 SOTA(gpt-4o)도 retail에서 pass^8 < 25%. 즉 같은 요청을 8번 던지면 적어도 1번은 정책 위반/실수 가 75%+ 확률로 발생. 충격적 수치였음.

2.4 평가 시 디테일

• Database state diff: SQL 또는 dict 비교. 순서 무관, 추가 필드 무관, 핵심 변경만 매치.
• 멀티턴 대화: 사용자 LLM의 randomness가 매 시도 다른 발화를 만들어냄 → pass^k가 의미 있음 (에이전트의 대화 강건성 도 측정).
• 함수호출 정확도와 별개로, 어떤 함수를 부르지 말아야했나도 평가 가능 (정책 위반).

3. 강점과 약점

강점	약점
정책 준수를 작업 완료와 분리해 측정	두 도메인 (retail, airline) — 일반화 약
pass^k로 재현성 명시화	시뮬레이션 사용자라 진짜 사용자 행동 미반영
DB state 비교 → exact match 같은 자동 채점	DB 모델링이 도메인마다 새로 필요
함수호출 SOTA의 한계 노출	시뮬레이션 사용자 LLM의 품질이 평가 신뢰도에 직결
산업계 정책-aware 에이전트 표준 자극	멀티턴이라 비용 ↑

4. 대안과의 비교

벤치	tool-use?	멀티턴?	정책?	일관성?
BFCL	Y	N	N	N (pass@1만)
ToolBench	Y	partial	N	N
τ-bench	Y	Y	Y	Y (pass^k)
AgentBench	Y	varies	N	N
GAIA	partial	N	N	N

τ-bench의 자리는 명확하다: 고객 응대 류 멀티턴 + 정책 평가. 다른 벤치엔 못 미치는 자리.

5. 우리 실험에의 적용

τ-bench를 그대로 쓸 수는 없다 — 도메인이 다르고, retail/airline 환경이 우리 페르소나와 무관. 하지만 두 아이디어 는 직접 가져올 가치가 크다.

5.1 pass^k 도입 — H2 가설의 직접 증거

본 실험의 H2: “Hermes가 둘째 주에 따라잡거나 역전”. 이는 반복 일관성 가설이다. Hermes의 학습이 진짜라면 같은 태스크 3회차 모두 성공해야 함.

현 §6 메트릭(“반복 가속 = 같은 태스크 3회차가 1회차 대비 몇% 빨라졌나”) 은 속도만 본다. 일관성은 안 본다.

제안:

• 정형 태스크 (T1, T2, T8) 를 매주 3회씩 의도적으로 반복
• 각 회차별로 결과물 품질(rubric 4-차원) 채점
• pass^3 (3회 모두 종합 ≥ 4) 비율을 도구별·태스크별 집계
• Hermes pass^3 / OpenClaw pass^3 비교

기대 결과:

• H2 참 → Hermes의 pass^3 가 OpenClaw보다 높음 (특히 둘째 주)
• H2 거짓 → 두 도구 pass^3 비슷 또는 OpenClaw 우위 (셋업이 곧 재현성)

이 한 메트릭만 추가해도 본 실험의 결정 매트릭스 (§9) 가 정량 결정 가능해진다.

5.2 정책 준수 — 페르소나 모드

τ-bench의 정책 = 우리의 페르소나 모드 강제 (§7).

• “코드/JSON/YAML 직접 작성 금지” → 정책
• “셋업 도와줘 형이 깔아줘 모드” → 정책

OpenClaw가 결과는 좋은데 민지에게 코드 보여달라고 요구하는 순간 → τ-bench 식으로 fail. 현 측정은 이걸 “셋업 가능 여부 (Y/도움받음/N)” 정도로만 잡는다.

제안 — Policy violation event 카운트:

각 태스크 실행에서 다음을 trajectory(hook log) 에서 자동 검출:

• 에이전트 응답에 코드 블록 등장 → +1 위반
• 에이전트가 YAML/JSON 편집을 요청 → +1 위반
• 에이전트가 터미널 명령 직접 입력 요구 → +1 위반 (단 “내가 이거 실행할게” 는 OK)

이 카운트는 hook 로그의 텍스트 검색으로 거의 자동 가능. 민지에게 부담 X.

5.3 사용자 시뮬레이션? — 미적용

τ-bench의 사용자 LLM 아이디어는 우리 실험엔 오히려 해로움. 우리는 진짜 페르소나 (민지) 를 쓰는 것이 목적. 시뮬레이션은 시뮬레이션이 가진 한계(자연 사용자의 변덕·실수·재질문 부족)를 그대로 받게 됨.

다만 후속 실험 (예: Hermes vs OpenClaw 자동 평가 파이프라인) 에서는 도입 검토 가치 있음.

6. 더 읽을거리

• Yao et al., “τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains” (2024) — τ-bench 원 논문, retail·airline 도메인과 pass^k 도입
• Sierra Research, tau-bench GitHub — 코드·태스크·평가 스크립트 1차 저장소
• τ²-bench paper (2025) — 사용자도 행동 권한을 갖는 dual-control 확장 벤치
• Toloka, “TAU-bench extension: benchmarking policy-aware agents” — 정책 인지 에이전트의 산업 적용 케이스 보고

---

다음 장 미리보기

τ-bench는 “tool + user + policy” 라는 좁은 영역의 깊은 평가였다. 더 넓은 범용 보조 능력은 어떻게 측정할까. GAIA(165 multi-step 문항) 와 AgentBench(8개 환경)이 이 자리를 잡고 있다. 06장.

이 장에서 확실히 알아야 하는 것

• τ-bench의 두 차별점(시뮬레이션 사용자, 정책 준수)을 외워서 말할 수 있다.
• pass@k 와 pass^k의 정확한 수식 차이를 안다.
• gpt-4o 의 pass^8 < 25% 가 의미하는 바를 한 줄로 설명할 수 있다.
• 본 실험에 pass^3 를 도입할 구체적 절차(태스크/주기/임계)를 안다.
• 페르소나 모드 위반을 정책 위반 카운트로 자동화하는 아이디어를 이해한다.