τ-Knowledge: Evaluating Conversational Agents over Unstructured Knowledge

Meta info.

• Authors: Quan Shi, Alexandra Zytek, Pedram Razavi, Karthik Narasimhan, Victor Barres
• Affiliation: Sierra; Princeton University
• Paper: https://arxiv.org/abs/2603.04370
• Code: https://github.com/sierra-research/tau2-bench
• Published: March 4, 2026 (arXiv preprint)

TL; DR

검색과 tool 사용을 따로 재던 기존 연구 대신, 쓸 수 있는 tool조차 문서에서 찾아내야 행동이 가능해지도록 설계한 benchmark 제안. GPT-5.2 (high)도 pass^1 25%에 그치고 정답 문서를 전부 줘도 40%를 넘지 못해, 성능 병목이 검색이 아니라 적용에 있다고 주장.

Review Video

Background

• 실 배포 환경에서 agent가 놓이는 조건
  • 회사마다 다른 사내 문서 corpus, 그 아래에 규칙과 절차가 전부 자연어로 기술
  • agent는 해당 문서를 “검색해야”
    • 무엇을 해도 되는지 알 수 있고
    • 자신에게 어떤 권한이 있는지도 파악 가능
  • 이 검색이 고객과의 real-time 대화 중에 발생
    • 고객은 요구를 부분적으로만 진술, 도중에 변경하기도
• 기존 benchmark: 조건을 통합적으로 측정하지 않고 분할
  • retrieval benchmark (BEIR, MTEB, BRIGHT)
    • 측정 대상: 질의에 대해 관련 문서를 정확히 찾아오는지 여부
    • 한계: 검색된 문서가 실제 판단과 행동을 어떻게 바꿨는지는 측정 범위 밖.
      • 잘 찾고도 잘못 행동한 경우?
  • tool use benchmark (SWE-bench, GAIA, TheAgentCompany, Tool Decathlon)
    • 측정 대상: multi-step 계획 수립, 외부 API 호출, 구조화된 절차 실행
    • 한계
      • 사용 가능한 tool 목록과 명세가 처음부터 완전히 제공, 탐색 단계가 존재하지 않음
      • 대화 상대가 없어 agent가 단독으로 문제풀이
  • multi-turn RAG benchmark (MTRAG, CORAL, RAD-Bench)
    • 측정 대상: 대화 도중의 검색까지 포함하므로 앞선 두 벤치마크보다는 현실에 근접하지만
    • 한계: 사실 확인 질의 위주. 문서를 찾아 옮기면 종료, 문서 간 대조를 요구하는 경우가 드묾.
• τ-Bench 계열(τ-bench, τ²-bench)이 상당 부분을 보완하나, tool과 절차가 여전히 사전 제공. “무엇을 할 수 있는지 알아내는” 단계 부재
  • simulated user와의 long-horizon 대화, 도메인 Policy 준수, 대화 내용이 아닌 최종 DB 상태 기반 채점 framework 확립
• 사용자 역할을 LLM에 부여하는 방식(Impersona, generative agent)의 한계
  • 사용자 prompt에 향후 전개나 정답이 포함되면 해당 사용자가 대화 중 정답 노출
  • 결과적으로 agent를 시험하는 것이 아니라 정답을 받아쓰게 하는 구도

Problem States

1. 지식 획득 실패가 결과에 흔적을 남길 것: 문서를 못 찾아도 결과가 동일하면 검색의 필요 여부를 구분할 수단이 없음 (→ Dec-POMDP formulation, discoverable tools)
2. 지식이 정형 표가 아닌 자연어 문서로 분산되어 있을 것: 단일 문서로 답이 나오지 않고 복수 문서의 대조를 요구하는 구조여야 함 (→ τ-Banking knowledge base)
3. 검색 방식에 무관할 것: embedding 검색만 측정하면 파일 탐색이나 long-context 같은 대안과 비교가 불가능 (→ retrieval configuration 설계)
4. 사용자가 정답을 노출하지 않으면서 평가 대상 상황은 유도할 것: 완전 자유 대화는 원하는 상황이 나오지 않고, 완전 대본은 정답이 유출됨 (→ flow-based user simulation)

Suggestions

Definition

• Dec-POMDP (Bernstein et al., 2002): 각 task를 agent와 user 두 주체가 함께 푸는 문제
  • 양쪽 모두 세계의 일부만 관측 가능(partially observable)
  • 어느 한쪽이 통제권을 갖지 않으며(decentralized)
  • 그 상태로 동일한 세계를 함께 변경해야 하는 문제
    • 세계: $S = S_{db} \times S_{history}$
      • $S_{db}$: 은행 DB. 계좌, 거래내역, referral 기록 등 실제 데이터
      • $S_{history}$: 지금까지 오간 대화 전체
• agent: $S_{db}$를 직접 관측하거나 수정할 수 없음
  • 문서에 기술된 tool을 호출해야만 관측 가능
  • tool 응답과 사용자 발화만으로 현재 상태 추정
  • 정보와 권한이 모두 문서를 경유, 상태 변경 전에 관련 문서의 검색과 해석이 선행
• scoring: 대화 내용이 아니라 종료 시점 DB가 목표 상태와 일치하는지로 수행

\[R : S \rightarrow [0, 1]\]

• 발화 품질이 아니라 실제 변경의 정오를 보므로 채점자의 주관이 개입할 여지가 거의 없음

τ-Banking Knowledge Base

• 구조: DB tool은 현재 상태가 무엇인지 제공, 그 상태에서 어떤 행동이 옳은지는 오직 corpus에만 기술
• Tab 1 신규 도메인 도입: fintech 고객지원 상황
  • 문서 698개, 총 194,562 tokens, 문서당 평균 278.7 tokens의 짧은 글
  • 상품 카테고리 21개, 그 하위 세부 주제 71개
  • 2 types tool: 상시 제공 14개, 문서에서 발견해야 하는 것 51개
  • task 97개: 개당 평균 문서 18.6개와 tool 호출 9.52회 필요 (최소 1회, 최대 33회)
• 대상 상품: 개인/법인 입출금 계좌, 등급별 저축계좌(Bronze부터 Diamond Elite까지), 리워드 신용카드, 후불결제 등
• 3가지 문서 종류 포함
  • policy(절차 문서): 어떤 순서로 무엇을 확인하고 어떤 tool을 호출할지 기술한 사내 매뉴얼
    • e.g. 신용카드 해지 방어 프로토콜
      • 1단계: 해지 자격 확인
        • 계류 중인 분쟁→교체카드 대기 여부→최소 개설 경과일→미결제 잔액 순으로 점검
      • 2단계: 지난 1년 내 해지 시도 이력 조회.
        • 이력이 있으면 방어 제안을 생략하고 해지로 직행
      • 3단계: 해지 사유를 질의하여 지정된 코드로 기록
      • 4단계: 사유별 대응.
        • 연회비가 사유인 경우 2년 이상 이용 고객에 한해 1년 면제를 제안
  • tool 설명 문서: tool 이름과 인자 명세가 본문 안에 문장 형태로 포함됨
  • 상품 문서: APY, 수수료, 한도, 모바일 입금 한도, referral 보너스 등의 스펙

Discoverable Tools

• [제안 tool call setup] 그 목록을 의도적으로 불완전하게 제공
  • [기존 tool call setup] 사용 가능한 tool의 목록과 명세가 시작 시점에 전부 주어짐
  • 처음부터 주어지는 tool은 14개뿐, 나머지 51개는 목록에 미존재: 따라서 해당 문단을 검색해 읽어내지 못하면 그 tool의 존재 자체를 인지 불가
    • 대신 그 이름과 인자 명세가 KB에 일반 자연어 문서 본문의 일부로 기술
    • e.g. 분쟁 처리 매뉴얼 본문: “해결 후 update_transaction_rewards_3847로 리워드를 정정하며 인자는 transaction_id와 new_rewards_earned”라는 문장이 포함된 형태
  • 목록에 없는 함수는 통상적인 function calling로 호출 불가
    • 이름을 정확히 지정해야 등록되므로, 문서를 못 찾은 경우 지정할 이름 자체가 없음
    • 부수 효과로 unlock 호출이 로그에 남아, agent가 무엇을 언제 발견했는지가 관측 가능
    • 상시 제공되는 메타 tool 2개 경유하도록 설계
      • unlock_discoverable_agent_tool(name): 문서에서 발견한 tool 이름을 등록하고 인자 명세를 수신
      • call_discoverable_agent_tool(name, kwargs): 등록된 tool을 실제로 실행
• agent의 행동 집합 $\mathcal{A}_{agent}$가 상수가 아니라 상태의 함수: 대화 시작 시 14개에서 출발, 관련 문서를 발견할 때마다 확장되는 구조
  • 기존: $\mathcal{A}{agent}$는 시작 시점에 고정 → 제안: 지금까지 읽은 내용, 즉 $S{history}$에 따라 크기가 증가함
• 평가 방법: “검색으로” 지식을 얻었기 때문에 할 수 있게 된 일이 무엇인가 == task 성공의 필요조건으로 설계
  • 기존: gold 문서와 실제 검색 문서를 대조해 recall이나 유사도로 채점함
    • task 성공과 검색 스코어가 별개: 정답 문서를 찾고도 무시한 경우는 점수가 높고, 못 찾고도 사전지식으로 맞힌 경우는 점수가 낮음
  • 제안: discoverable tool을 도입
    • 문서 미발견 → 이름 미확보 → unlock 불가 → 호출 불가 → DB 미변경 → 채점 실패 연쇄적으로 강제 == 검색 성공 여부를 별도 지표로 채점 불요, 최종 DB 상태로 판정
      • tool 이름이 벤치마크가 생성한 임의의 문자열이므로 사전지식에 의한 우회도 사전 차단

Flow-based User Simulation

• 사용자를 완전 자유 생성으로도, 고정 대본으로도 두지 않는 중간 방식
• task마다 “이런 상황이 발생하면 사용자는 이렇게 반응한다”는 조건부 규칙을 사전 정의
  • e.g. agent가 배송 방식을 질의하면 특급배송을 요청 or agent가 카드 3장을 전부 정지시키면 그 시점에 한 장은 자켓 주머니에 있었다고 진술
• 규칙이 적용되지 않는 구간은 LLM이 자유 생성하여 어휘와 표현의 자연스러움을 유지
  • 효과: 정답을 노출하지 않으면서 평가 대상 상황 유도 가능
    • 자격 미달 요청에 대한 거절 여부 확인, 대화 중간의 DB 상태 변경에 대한 적응 여부 확인 등
• 사용자 prompt의 구성은 캐릭터 설정, 신원 확인 정보, 대화 흐름, 조건부 반응 규칙
  • 요구사항을 일괄 진술하지 않고 대화 중 점진적으로 노출하도록 지시됨

벤치마크 구축: structured-to-unstructured pipeline

• Fig 2 LLM에 일괄 생성시 문서 간 값 불일치 → structured db를 먼저 구성한 후 자연어 문서로 분해
  • 문체 다양화를 위해 GPT-5, GPT-5.2, Claude-4.5-Opus, Gemini-3-Pro 등 교대 사용
• 절차
  1. 정형 DB 생성: 상품이 행, 변수가 열인 표 생성
     • 카테고리(신용카드, 저축계좌) → 하위 feature(카드 등급, 계좌 프로토콜) → feature별 변수(연회비, 캐시백률, 잔액이전 APR) 순으로 LLM 생성
     • 이를 제약 조건 시스템으로 해석, 변수 하나가 상품 공간의 축 하나이고, 실존하는 각 상품은 그 축들 위의 좌표 하나에 대응 (Stage 3에서 활용)
  2. 정형에서 비정형으로: 동일한 값이 여러 문서에 분산되지만 원본 표와의 일관성 유지
     • feature별 문서 제목 생성 → LLM이 변수 부분집합을 각 제목에 배정 → 제목과 변수를 입력받아 자연어 글 작성
  3. task와 DB 생성: 카드 재발급, 거래 분쟁, 계좌 추천 등 실제 상담 흐름을 따라 사람과 LLM이 공동 구성
     • 필요 시 문서와 tool을 그 시점에 추가
     • task마다 gold document 지정: 해당 task 완수에 필요한 최소 문서 집합
  4. human filtering: task 생성 중 표를 수정 시 수정 후에 영향받은 부분만 선별하여 파이프라인 재실행
  5. 독립 검수: task 제작에 관여하지 않은 리뷰어 2인이 별도 검사
     • 검사 항목은 기대 최종 DB 상태의 정확성, gold 문서의 완전성과 최소성, gold 문서와 문서화된 tool만으로의 해결 가능성
     • task당 최소 1회 직접 수행하여 해결 가능성을 확인
     • 대규모 실험 종료 후 전체 trajectory를 재검토, 문서를 읽지 않고 우연히 성공한 경로가 있었는지 색출

Effects

• Experimental setup
  • user: GPT-5.2 (low reasoning) simulator; task별 규칙과 자유 생성의 혼합
  • assistant(agent): reasoning을 최대로 쓰는 flagship 1개와, 응답 속도를 위한 저지연 변형 1개
    • GPT-5.2 (high/none), Claude-4.5-Opus (high), Claude-4.5-Sonnet (high), Gemini-3-Pro (high), Gemini-3-Flash (high)
    • 검색 방식
      • dense: 의미가 유사한 문서 반환
        • text-embedding-3-large, Qwen3-embedding-8B
        • KB_search tool 하나로 상위 $k=10$개 수신, 결과 확인 후 동일 턴 내 재검색 가능
      • sparse: 단어가 중복되는 문서를 반환하는 BM25
      • terminal: 문서를 전부 파일로 전개하고 shell 하나만 제공
        • grep이나 cat으로 agent가 자체 전략에 따라 탐색
      • gold: 정답 문서를 초기부터 context에 제공.
        • 검색을 제거하여 “못 찾아서 틀린 것”과 “찾고도 틀린 것”을 분리하려는 조건
    • context 초과 시 가장 오래된 검색 결과의 1/4을 삭제하고 재검색 안내 문구로 대체.
      • 실제 발생된 경우는 GPT-5.2 high에 한정, 그 경우도 1~3% 수준으로 매우 적었다고.
  • evaluation:
    • 주요 metric: 우연에 의한 성공을 배제하고자 $\text{pass}^k$.
      • task를 $k$회 시행했을 때 매회 성공할 확률 ($k \le 4$까지 측정)
    • 보조 지표
      • Document Recall: 정답 문서가 agent context에 1회 이상 등장한 비율.
        • terminal은 문서 전체가 아닌 일부만 노출되므로 ROUGE로 근사
      • Action Recall(기대 행동 중 실제 수행 비율)
      • 소요 시간, 턴당 시간
    • 유의성 검정: paired bootstrap으로 검정 (Koehn, 2004)
• Results
  • Tab 2 절대적인 성능이 매우 낮음
    • 최고 성능 조합은 GPT-5.2 (high) + terminal의 $pass^1$ 25.52으로 전체 1/4 수준
    • 검색 방식별 평균 gold 32.18 > terminal 19.20 > Qwen3-emb 17.11 ≈ BM25 17.04 ≈ text-emb-3-large 16.88
    • 정답 문서를 전부 제공한 gold에서도 최고가 Claude-4.5-Opus 40 미만, 4회 연속 성공률은 약 27로 하락
      • 실패의 원인이 미발견이 아니라 검색 후의 오적용
  • Fig 3
    • (좌) 반복 시행 시 성적이 급락하며, 하락 속도는 모델별로 상이
      • 4회 연속 성공률의 최고치는 GPT-5.2 high + Qwen3-emb 13.40
      • 단회 성공과 강건성은 별개: Gemini-3-Flash는 1회 성공률은 준수하나 반복 시 하락 폭이 가장 컸다고
    • (우) retrieval 성능이 낮아도 검색 횟수로 보완 가능하나, 비효율 증대
      • GPT-5.2 (high) + terminal과 Opus (high)는 점수가 유사하나,
        • 전자 token 소모량 약 1.7배, shell 명령 실행 횟수 약 2.3배, 시간은 약 9배 소요
        • task당 KB_search 호출이 Opus 8.7회 대비 GPT-5.2 high 18.5회
      • 검색 방식별 횟수도 상이. dense 약 10회 < BM25 11.4회 < terminal의 grep 14.5회, terminal은 그 외 shell 명령까지 포함하면 약 30회에 육박
  • terminal의 gain은 최신 reasoning 모델에 한정
    • 전체 평균으로는 terminal » dense or sparse
    • 단 reasoning off GPT-5.2에는 gain 없고, GPT-4o와 GPT-4.1도 동일
    • 또한 이 이득이 Document Recall 상승을 동반하지 않음 == 더 많이 찾아서가 아니라 동일한 자료를 더 잘 읽어서 생긴 gain으로 추정
  • ablation: 환경이 실제로 지식(검색)을 요구하는지 확인
    • 문서 접근을 차단하면 평균 $pass^1$이 약 2%로 붕괴 == task가 실제로 검색된 지식을 요구함
    • 문서 700개를 전부 system prompt에 투입해도 최고 약 12%(GPT-5.2 high, Gemini-3-Pro) == (검색으로) 선별 필요
  • 검색 실패와 검색 오적용에 의한 실패의 분리
    • gold 조건에서도 점수가 낮다 == 성능 병목이 읽고 적용하는 단계에 있다
    • Document Recall은 검색기 성능이 아니라 모델과 검색기의 조합에 달렸다 == 검색 품질이 retriever 가 아니라 agent의 질의 작성과 재시도 전략에 달린 문제
  • Fig 4 LLM 실패 사후 분석
    • 검색 비효율과 근거 없는 단정 (~23%): 요청이 모호할 때 재질의나 범위를 좁힌 검색 대신 최초 가설 고수
    • 상품과 정책의 상호 의존에 의한 오답 (~14.5%): 복수 문서 대조가 필요하나 표면 문구에 hook
    • 암묵적 순서의 미준수 (~5%): 분쟁 계류 중에는 한도 상향이 자동 거절되므로 분쟁 해소가 선행되어야 하나, 사용자가 진술한 순서대로 실행하는 등
    • 사용자 진술의 무검증 수용 (~4%): 시스템은 심사 중으로 응답했으나 사용자가 전부 승인되었다고 주장하자 확인 없이 크레딧을 적용하는 등
  • 사용자 simulator의 신뢰도 검증
    • task마다 서로 다른 agent 모델의 대화 2건 샘플링
    • 고객서비스 도메인 지식을 가진 annotator 2인이 사용자 발화를 3등급으로 라벨링
      • 등급은 문제 없음
      • 사소한 불일치
      • 올바른 agent조차 실패시킬 수 있는 치명적 오류
    • 194건 중 치명적 오류는 4건에 그쳐 이전 τ-Telecom 도메인과 유사한 수준

Personal note. 도메인이 좁아 보여서 매력도가 떨어질 수는 있는데, 저는 discoverable tool이라는 설계 자체가 궁금해서 읽었습니다. (문서를 못 찾으면 그 행동을 아예 할 수 없게 만들어버리면, 검색을 잘했는지를 따로 채점할 필요가 없어지므로..) 검색 품질 지표와 task 성공이 유리되었다는 문제를 해결하는데에 지표를 깎는 대신 설계로 없애버린 셈인데, 이게 쓰이는 벤치마크일지에 따라 유익성이 갈릴 것 같기는 합니다.

결과 쪽에서 흥미로웠던 한 가지는 terminal에 파일 쓰기 권한을 줘도 GPT-5.2는 아예 쓰지 않았고, 나머지 모델도 쓰긴 써도 다시 읽지 않았다는 부분입니다. 이건 계속 지적하고 있는 “알고 있는 걸 실행에 못 옮기는” 문제 밖에서 “쓸 수 있는 도구를 애초에 안 쓰는” 문제라 전혀 다른 차원으로 볼 수도 있을 것 같습니다.