τ-bench: 실제 도구 사용 도메인에서의 AI 에이전트 신뢰도 측정

테이블 추론과 text-to-SQL의 계보를 추적하며 몇 주를 보낸 후, 저는 시야를 넓혀 다른 질문을 던져보고 싶었습니다. 실제 사용자와 실시간 운영 루프에 투입되었을 때 현재의 에이전트들은 실제로 얼마나 잘 작동할까요? τ-bench는 제가 본 것 중 가장 솔직한 답을 제시하며, 그 수치는 매우 놀랍습니다.

논문 요약

프린스턴 대학교와 Sierra Research의 Yao, Shinn, Razavi, Narasimhan은 기존 에이전트 벤치마크의 사후 편향적인 간극을 메우기 위해 τ-bench(arXiv:2406.12045, 2024년 6월)를 발표했습니다. 대부분의 에이전트 벤치마크는 모델에 작업을 부여하고 최종 답변만을 단독으로 평가하지만, 실제 배포 환경은 그렇지 않습니다. 고객 서비스 에이전트는 대화 도중 중단되거나, 추가 질문을 받고, 모순된 정보를 전달받으며, 데이터베이스를 변경하기 전까지 열린 대화 전반에 걸쳐 비즈니스 정책을 준수해야 합니다.

τ-bench는 소매와 항공이라는 두 가지 실제 고객 서비스 도메인을 시뮬레이션 환경으로 구축하여, 하나는 언어 모델이 사용자를 연기하고 다른 하나는 에이전트 역할을 수행하게 합니다. 에이전트는 도메인별 API(주문 취소, 좌석 변경, 쿠폰 적용)와 어떤 조건에서 어떤 작업이 허용되는지 명시된 정책 문서에 접근할 수 있습니다. 평가는 중간 단계를 점수화하지 않고, 최종 데이터베이스 상태를 주석이 달린 목표 상태와 비교합니다. 저자들은 또한 pass^k라는 신뢰도 메트릭을 도입했는데, 이는 동일한 작업에 대해 k번의 독립적인 시도 중 에이전트가 얼마나 일관되게 성공하는지를 측정합니다.

핵심 아이디어

• 솔직한 메트릭으로서의 pass^k: 단일 pass@1 점수는 노이즈가 너무 많습니다. pass^k는 에이전트가 동일한 작업을 k번 다시 실행했을 때 매번 성공할 확률을 드러내며, 이는 곧 프로덕션 환경에서의 신뢰 여부를 판단하는 척도가 됩니다.
• 일관성의 절벽: 소매 분야의 GPT-4o는 pass@1에서 0.604를 기록했지만 pass@4에서는 0.383으로 급락합니다. 이는 작업의 약 60%에서 네 번의 시도 중 최소 한 번은 실패한다는 것을 의미하며, 결코 프로덕션에 안전한 에이전트라고 할 수 없습니다.
• 항공 분야가 소매보다 어렵습니다: GPT-4o의 pass@1은 0.604(소매)에서 0.420(항공)으로 떨어집니다. Claude 3.5 Sonnet(2024년 10월 버전)은 pass@1에서 소매 0.692, 항공 0.460으로 더 나은 성능을 보이지만, pass@4에서는 각각 0.462와 0.225에 그칩니다.
• 함수 호출이 ReAct보다 우수함: GPT-4o의 함수 호출 에이전트 변형(항공 분야 pass@1 = 0.420)은 동일한 백본에서 Act(0.365) 및 ReAct(0.325)보다 우수한 성능을 보였습니다. 이는 구조화된 도구 API가 형식으로 인한 실패를 줄여준다는 것을 시사합니다.
• 사용자 시뮬레이션의 변수: 저자들은 언어 모델을 사용하여 사용자를 시뮬레이션하는데, 이는 고유한 분산을 발생시킵니다. 약한 사용자 시뮬레이터는 적대적인 사용자 행동을 얼마나 충실히 반영하느냐에 따라 에이전트 점수를 낮추거나 높일 수 있습니다.
• 데이터베이스 상태 평가는 부분 점수 게임을 피합니다: 대화 단계가 아닌 최종 상태를 비교한다는 것은, 올바른 조치를 취한 후 실수로 이를 되돌린 에이전트에게 점수를 주지 않는다는 의미입니다. 이는 쓰기 가능(write-back) 시스템에 적절한 평가 방식입니다.

유효한 점과 한계점

pass^k 프레임워크는 정말 유용하며 이 특정 벤치마크보다 더 오래 지속될 것으로 보입니다. 토큰 수준의 유사성이 아닌 데이터베이스 상태를 기준으로 평가하기로 한 결정은 옳았습니다. 이는 에이전트가 올바른 말을 했는지가 아니라 실제로 작업을 완수했는지를 직접 측정하기 때문입니다.

하지만 도메인은 설계상 좁게 설정되어 있습니다. 소매와 항공은 절차적으로 깔끔합니다. 정책 문서는 유한하고 벤치마크를 위해 작성되었으며, API는 작고 명확하게 지정되어 있고, 사용자 시뮬레이터는 기본적으로 협조적입니다. 실제 비즈니스 정책 문서는 모호하며, 실제 사용자는 거짓말을 하거나 잘못 기억하고 거절에 대해 항의합니다. 저자들도 이를 인정하고 있으며, 사용자가 환경 상태를 조작하는 이중 제어 Dec-POMDP 모델로 확장한 후속 연구인 τ²-bench(arXiv:2506.07982)의 존재 자체가 단일 제어 평가가 난이도를 과소평가하고 있음을 시인하는 것입니다.

또한 pass^k가 실제로 무엇을 측정하는지에 대한 의문이 남습니다. 사용자 시뮬레이션 자체가 확률적이라면, k번의 시도에서 발생하는 분산은 에이전트의 일관성 부족과 시뮬레이터의 일관성 부족을 혼합하게 됩니다. 논문은 이를 언급하고 있지만 두 가지 분산 원인을 완전히 분리하지는 못했습니다. 안전이 중요한 애플리케이션의 경우, 에이전트가 정책을 무시하는 것인지, 사용자 의도를 잘못 읽는 것인지, 아니면 단순히 잘못된 도구 호출 형식을 선택하는 것인지 실패의 원인을 규명하고 싶을 것입니다.

llm-stats.com의 리더보드를 보면 Step-3.5-Flash와 같은 모델이 0.882를 기록하고 있는데, 평가 설정이 변경되었다는 사실을 모른다면 극적인 진전으로 보일 수 있습니다. 최신 항목들은 서로 다른 사용자 시뮬레이터 버전과 작업 분할 하에서 점수가 매겨진 것으로 보입니다. 진화하는 벤치마크에서 항목 간 비교는 항상 주의해야 합니다.

금융 AI에 중요한 이유

제가 염두에 두고 있는 Beancount 쓰기 가능 에이전트는 τ-bench가 평가하는 에이전트들과 구조적으로 동일합니다. 도메인별 도구(트랜잭션 추가, 잔액 수정, 항목 재분류), 정책 제약 조건(마감된 기간 수정 금지, 음수 잔액 생성 금지, 계정 차트 준수), 그리고 여러 턴에 걸친 대화에서 자연어로 지시를 내리는 사용자가 존재합니다.

우리에게 가장 실행 가능한 결과는 pass^k에 대한 발견입니다. Claude 3.5 Sonnet과 같은 최첨단 모델이 상대적으로 관대한 도메인인 소매 분야에서 pass@4가 0.462에 불과하다면, 실수가 트랜잭션 전반에 걸쳐 누적되고 정책 위반이 즉시 드러나지 않을 수 있는 원장 쓰기 작업에서는 비슷하거나 더 나쁜 일관성을 보일 것으로 예상해야 합니다. 단순히 pass@1을 최적화하고 끝내는 것이 아니라, 처음부터 k-시도 일관성을 고려하여 설계한다면 아키텍처가 달라집니다. 이는 보수적인 도구 사용(쓰기 전에 확인), API 호출 전 명시적인 정책 확인 단계, 커밋 전 제안된 데이터베이스 차분(diff)을 감사하는 별도의 검증 에이전트 도입을 뒷받침합니다.

데이터베이스 상태 평가 방법론 또한 직접적으로 이식 가능합니다. Beancount의 구조화된 파일 형식 덕분에 쓰기 세션 후의 실제 상태와 기대되는 원장 상태를 비교하기 쉬우며, 이는 τ-bench가 사용하는 것과 동일한 객관적인 평가 신호를 제공합니다.

더 읽어볼 거리

• τ²-bench (arXiv:2506.07982): 사용자가 도구를 호출할 수도 있는 이중 제어 환경으로 확장된 후속 연구입니다. 사용자가 수동적인 요청자가 아니라 원장 수정의 능동적인 참여자로 모델링될 때 직접적인 관련이 있습니다.
• AgentEval / GAIA (arXiv:2311.12983): 웹 브라우징과 도구 사용이 필요한 실제 작업에서 일반 AI 어시스턴트를 평가하는 GAIA 벤치마크는 τ-bench의 도메인 중심적 초점을 보완하는 유용한 자료입니다.
• WorkArena (arXiv:2403.07718): ServiceNow의 실제 엔터프라이즈 소프트웨어 작업에서 에이전트를 평가합니다. 이 도메인은 소매나 항공보다 회계 워크플로우에 더 가까우며 작업 설계 교훈을 얻기 위해 읽어볼 가치가 있습니다.