Where Do Deep-Research Agents Go Wrong? Review

0. Introduction

Paper link

HTML link

Code link

Data link

Deep-research agent를 평가할 때 보통 마지막 답이 맞았는지를 본다. 하지만 실제로 agent를 운영해 보면 더 중요한 질문은 따로 있다. 실패한 답이 나왔을 때, trajectory의 어느 span에서 처음으로 잘못된 commitment가 생겼는가다.

이 논문은 바로 그 질문을 benchmark와 auditing framework로 만든다. 단순히 “agent가 틀렸다”가 아니라, search, evidence inspection, hypothesis update, final synthesis로 이어지는 긴 trajectory 안에서 어떤 span이 해로운 error span인지 찾게 만든다. 그리고 이를 위해 TELBench라는 benchmark와 DRIFT라는 claim-centric auditing framework를 제안한다.

한 줄 요약: 이 논문은 deep-research agent의 최종 정답률 대신 trajectory 내부의 harmful error span을 찾는 문제를 정의하고, 1,000개 verified instance로 구성된 TELBench와 claim support를 추적하는 DRIFT auditing pipeline을 제안한다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

• Deep research agent의 reliability를 final answer metric이 아니라 process-level diagnostic 문제로 본다.
• Long trajectory에서 harmless exploration과 harmful commitment를 구분하는 labeling 기준을 꽤 명확히 제시한다.
• DRIFT는 더 큰 model을 쓰는 접근보다, claim ledger, support checking, dependency tracing 같은 구조적 audit이 왜 필요한지 보여준다.
• Agent evaluation, browser agent, research automation, internal QA pipeline을 만드는 팀에게 바로 재사용 가능한 설계 힌트가 많다.

이 논문의 핵심 메시지는 단순하다. Deep-research agent가 틀리는 이유는 마지막 summary에서 갑자기 생기는 것이 아니라, 앞선 span에서 약하게 지지된 claim이 점점 사실처럼 재사용되면서 생긴다. 그래서 평가도 final answer 하나가 아니라, trajectory 안의 claim lifecycle을 봐야 한다.

1. Problem Setting

1-1. Problem definition

이 논문이 겨냥하는 문제는 deep-research agent trajectory의 span-level error localization이다.

Deep-research agent는 보통 아래 과정을 길게 수행한다.

1. User question을 이해하고 plan을 세운다.
2. Search query를 만든다.
3. 여러 source를 탐색한다.
4. Evidence를 추출하고 비교한다.
5. Candidate answer를 좁힌다.
6. Final response를 합성한다.

기존 평가는 대부분 마지막 답의 correctness를 본다. 이 방식은 agent가 성공했는지 실패했는지는 알려주지만, 어느 step이 failure를 만들었는지는 알려주지 못한다.

이 논문은 trajectory를 ordered semantic span으로 바꾼다. Span은 raw event 하나보다 크고, 전체 trajectory보다는 작은 단위다. 예를 들어 같은 search target 아래에서 발생한 query rewrite와 evidence collection은 하나의 span으로 묶을 수 있고, verification target이 바뀌면 span boundary가 생긴다.

그 다음 문제는 다음처럼 정의된다.

• Input: question과 ordered raw span texts
• Output: harmful error span indices
• Constraint: gold labels, manual notes, judge results, span type, generated summaries는 input에 넣지 않는다
• Goal: benign exploration, failed search, tentative hypothesis, harmless noise와 실제 harmful error span을 구분한다

여기서 중요한 점은 “실패한 search” 자체가 곧 error는 아니라는 것이다. Agent가 search를 시도했지만 좋은 evidence를 못 찾고, 이후 그 hypothesis를 버렸다면 이는 정상 exploration에 가깝다. 반대로 약한 evidence만 보고 특정 entity나 constraint를 확정한 뒤, 이후 reasoning이 그 claim에 의존하면 harmful error가 된다.

1-2. Why previous approaches are insufficient

기존 agent evaluation은 세 가지 면에서 부족하다.

첫째, outcome-level evaluation은 diagnosis가 아니다. Final answer가 맞았다는 것은 trajectory가 완전히 건강했다는 뜻이 아니다. 논문은 successful trajectory 중에서도 process error가 포함된 경우가 있음을 보여준다. 즉 정답을 맞힌 trajectory에도 위험한 intermediate commitment가 들어 있을 수 있다.

둘째, step-level reasoning benchmark는 deep-research trajectory와 형태가 다르다. Math CoT나 짧은 tool trace에서는 step boundary가 비교적 명확하다. 하지만 deep-research trajectory는 search, source inspection, query rewrite, candidate pruning, answer synthesis가 섞이고, raw log도 framework마다 다르다.

셋째, LLM에게 전체 log를 그대로 주고 “어디가 틀렸나”를 묻는 방식은 불안정하다. 긴 trajectory에서는 실패한 search와 harmful commitment가 섞인다. 일반 auditor는 최종 답에 가까운 span에 과도하게 끌리거나, early unsupported claim을 놓치기 쉽다.

정리하면 이 논문이 보는 병목은 agent capability 자체가 아니라 agent failure를 디버깅하는 관찰 단위다. Deep research에서는 answer correctness보다 “어느 claim이 언제 unsupported commitment가 되었는가”가 더 실용적인 debugging target이 된다.

2. Core Idea

2-1. Main contribution

이 논문의 핵심 기여는 세 가지다.

1. TELBench dataset
   • 2,790개 real deep-research agent trajectory를 수집하고, semantic span 단위로 error label을 붙인다.
   • 이 중 verified 1,000개 instance를 TELBench로 구성한다.
   • 각 instance는 easy 600개, hard 400개로 나뉘며, 평균 11.95개 semantic span을 가진다.
2. Span-level error definition
   • Error span은 mistaken, unsupported, contradicted, prematurely committed judgment를 introduce, rely on, amplify, finalize해서 answer path에 영향을 주는 span이다.
   • Failed search, tentative hypothesis, recovered mistake, tool noise는 그 자체로 error가 아니다.
   • 이 distinction이 TELBench의 가장 중요한 설계다.
3. DRIFT framework
   • DRIFT는 span을 독립적으로 분류하지 않는다.
   • 먼저 trajectory 전체에서 claim ledger를 만든다.
   • 그 다음 각 claim이 trajectory evidence로 support되는지 확인한다.
   • 마지막으로 unsupported or conflicting claim이 어느 span에서 harmful commitment가 되었는지 backtrace한다.

2-2. Design intuition

DRIFT의 설계 직관은 꽤 명확하다.

첫째, long trajectory에서는 error가 local event가 아니라 claim propagation 문제다. 어떤 claim은 처음에는 단순 candidate일 수 있다. 하지만 이후 span에서 그 candidate가 확정된 premise처럼 쓰이면 그 순간 harmful해진다.

둘째, support 여부와 harmful 여부는 다르다. 약한 support를 가진 claim이 있어도, agent가 그 claim을 버리면 큰 문제가 아니다. 반대로 weak support claim을 final answer의 핵심 근거로 쓰면 error가 된다.

셋째, general agentic auditor를 붙이는 것만으로는 충분하지 않다. Codex나 Claude Code 같은 일반 agentic auditing wrapper는 더 복잡한 workflow를 만들 수 있지만, trajectory-specific diagnosis structure가 없으면 harmless span과 harmful span을 안정적으로 분리하기 어렵다.

내 해석으로는 이 논문은 agent benchmark paper이면서 동시에 “agent observability” paper에 가깝다. 운영 관점에서 필요한 것은 더 좋은 final score 하나가 아니라, agent가 어떤 evidence를 보고 어떤 claim을 확정했는지 추적할 수 있는 audit trail이다.

3. Architecture / Method

3-1. Overview

Item	Description
Problem	Deep-research trajectory에서 harmful error span을 찾는 문제
Dataset	TELBench
Instance unit	Question plus ordered semantic spans
Label	Error or non-error span
Main framework	DRIFT
Key idea	Claim-centric auditing
Main modules	Claim Keeper, Support Seeker, Dependency Tracer
Metrics	Macro precision, macro recall, macro F1, first-error accuracy
Main message	Final answer correctness만으로는 agent reliability를 설명하기 어렵다

3-2. Module breakdown

1) Semantic span construction

Raw log는 그대로 쓰기 어렵다. Tool call, result, retry, manager message, subagent action, usage record가 섞여 있기 때문이다. 논문은 framework-specific log를 unified execution-unit sequence로 normalize한 뒤, semantic objective가 바뀌는 지점에서 span을 나눈다.

Boundary signal은 대략 다음과 같다.

• Search target이 바뀌는 경우
• Candidate set이 바뀌는 경우
• Time scope가 바뀌는 경우
• Verification criterion이 바뀌는 경우
• Reasoning objective가 바뀌는 경우

이 방식의 장점은 span이 raw event보다 의미 있고, full trajectory보다 localization에 적합하다는 점이다. 단점은 segmentation 자체가 evaluation quality에 큰 영향을 준다는 점이다. 실제 내부 agent log에 적용하려면 span segmentation rule을 domain에 맞게 다시 잡아야 할 가능성이 높다.

2) Error span annotation

TELBench에서 error span은 단순한 mistake가 아니다. 논문 기준으로 error span은 아래 중 하나를 수행해야 한다.

• 잘못된 judgment를 introduce한다.
• unsupported claim에 rely한다.
• 잘못된 claim을 amplify한다.
• contradicted claim을 finalize한다.
• premature commitment를 통해 answer path에 영향을 준다.

반대로 아래는 그 자체로 error가 아니다.

• Normal exploration
• Failed search
• Tentative hypothesis
• Recovered mistake
• Tool noise

이 기준은 실무적으로 중요하다. Agent log에는 실패처럼 보이는 행동이 많다. 하지만 모든 failed search를 error로 label하면 model은 exploration 자체를 억제하는 방향으로 학습될 수 있다. TELBench는 “틀린 시도”와 “해로운 확정”을 분리하려고 한다.

3) Claim Keeper

Claim Keeper는 trajectory 전체를 읽고 decision-relevant claim ledger를 만든다.

Claim은 단순 문장이 아니라 agent가 trajectory 안에서 사용하는 commitment다. 예를 들면 다음이 claim이 될 수 있다.

• 특정 entity가 답의 후보라는 판단
• 특정 constraint가 만족되었다는 판단
• 어떤 source가 충분히 authoritative하다는 판단
• search coverage가 충분하다는 판단
• 계산이 완료되었다는 판단
• 더 이상 답을 만들 수 없다는 판단

Claim ledger에는 다음 정보가 들어간다.

Field	Meaning
Claim text	Agent가 만든 decision-relevant claim
Introduced span	Claim이 처음 등장한 span
Consequential span	Claim이 answer path에 실제 영향을 주기 시작한 span
Reuse spans	이후 claim을 재사용한 span들
Claim type	Entity, constraint, evidence, retrieval, compute, process 등
Status	Exploratory, tentative, consequential, finalized 등

핵심은 exploratory claim과 consequential claim을 분리하는 것이다. Query에 candidate name이 들어간 것은 exploration일 수 있다. 하지만 그 candidate를 검증 없이 답의 전제로 사용하면 consequential commitment가 된다.

4) Support Seeker

Support Seeker는 Claim Keeper가 만든 claim이 trajectory evidence로 얼마나 support되는지 본다.

Support status는 네 가지다.

Status	Meaning
Direct	Trajectory evidence가 decisive link를 직접 establish한다
Weak	관련 evidence는 있지만 decisive link가 partial, implicit, snippet-based, unchecked 상태다
Missing	claim을 establish하는 shown support가 없다
Conflicting	shown evidence가 claim과 충돌한다

이 단계가 바로 error span을 출력하지는 않는다. 이유는 단순하다. Weak or missing support claim이라도 trajectory에서 버려졌다면 harmful error가 아닐 수 있다. Support Seeker의 역할은 위험한 claim 후보를 드러내는 것이다.

5) Dependency Tracer

Dependency Tracer는 support risk가 있는 claim이 실제 answer path에 어떤 영향을 줬는지 추적한다.

특히 다음을 본다.

• 해당 claim이 commitment로 사용되었는가
• 이후 reasoning으로 propagate되었는가
• computation이나 comparison의 입력으로 쓰였는가
• answer를 포기하거나 후보를 제거하는 근거가 되었는가
• final answer에서 finalized되었는가

DRIFT는 unsupported or conflicting claim이 commit, reuse, amplify, finalize되는 span을 error로 mark한다. 이 구조 덕분에 단순히 suspicious한 span을 많이 찍는 방식이 아니라, claim dependency를 따라 harmful span을 고르려 한다.

4. Training / Data / Recipe

4-1. Data

TELBench의 data pipeline은 다음처럼 볼 수 있다.

Stage	Description
Task source	GAIA-val, XBench, BrowseComp-test
Task count	BrowseComp downsample 후 465 tasks
Agent frameworks	MiroFlow, OAgent
Backbone models	GPT-5, Gemini-2.5-Pro, Claude-Sonnet-4.5
Raw trajectory count	2,790 trajectories
Error-bearing candidate pool	1,890 trajectories
Verified TELBench	1,000 instances
Difficulty split	600 easy, 400 hard
Average span count	11.95 semantic spans per trajectory

Annotation pipeline도 상당히 무겁다. 먼저 서로 다른 frontier model family의 두 LLM annotator가 high-recall candidate error span을 제안한다. 그 뒤 agent system과 browsing behavior에 익숙한 expert annotator가 full trajectory를 읽고 label을 검증한다. 논문은 7명의 expert annotator가 각각 300시간 이상 trajectory reading, evidence checking, label revision, adjudication에 사용했다고 설명한다.

이 데이터셋의 중요한 점은 final-answer failure만 모은 것이 아니라는 점이다. 목표는 “틀린 답 모음”이 아니라 “trajectory 내부에서 검증 가능한 harmful error span을 찾는 diagnostic set”이다.

4-2. Mechanism labels

Binary error label 이후에는 analysis용 mechanism label을 붙인다.

Operation-stage label은 8가지다.

1. Planning
2. Retrieval
3. Source verification
4. Extraction
5. Computation
6. Decision-making
7. Recovery
8. Finalization

Error span에는 primary-fault label도 붙는다. 논문은 free-form rationale을 cluster하고 manually normalize해서 18개 primary faults, 6개 fault family로 정리한다.

중요한 제한은 evaluation input에는 이런 mechanism label이 들어가지 않는다는 점이다. Model은 question과 ordered raw span text만 보고 error span을 찾아야 한다. Mechanism label은 결과 분석과 error taxonomy를 위한 장치다.

4-3. Evaluation recipe

TELBench의 evaluation은 span-level metric과 temporal metric을 같이 본다.

Metric	Meaning
Macro precision	Error로 찍은 span 중 label과 맞는 정도
Macro recall	실제 error span을 얼마나 찾는지
Macro F1	Precision and recall의 균형
First-error accuracy	가장 이른 harmful error span을 맞히는지

여기서 first-error accuracy가 특히 중요하다. Agent debugging에서 “어딘가 틀렸다”를 찾는 것과 “처음 틀어진 지점”을 찾는 것은 다르다. 후자가 되어야 실제로 prompt, tool, search policy, verifier를 고칠 수 있다.

비교 대상은 크게 네 종류다.

• Bare LLM
• Codex style general agentic auditor
• Claude Code style general agentic auditor
• DRIFT

모든 framework는 동일한 input, 즉 question과 ordered semantic spans를 받는다. 각 setting은 세 번 반복된다.

5. Evaluation

5-1. Main results

논문의 핵심 결과는 DRIFT가 여러 backbone model에서 bare full trajectory prompting과 general agentic auditor보다 더 나은 span-level localization을 보인다는 것이다.

원문 Table 2 기준 overall macro-F1만 요약하면 다음과 같다. 단, arXiv HTML에서는 superscript improvement 숫자가 붙어 보이므로 최종 게시 전 PDF table을 다시 확인하는 것이 좋다.

Backbone	Bare overall F1	DRIFT overall F1	Bare FEA	DRIFT FEA
DeepSeek-V3.2	22.46	50.51	10.30	23.70
GPT-5.4	33.93	52.48	14.90	20.80
Claude-Sonnet-4.6	21.89	54.91	11.30	24.10
Gemini-2.5-Pro	31.01	48.41	15.70	19.90

논문 abstract에서는 DRIFT가 span-level error localization과 first-error accuracy를 최대 30 percentage point까지 개선한다고 요약한다. 하지만 여기서 더 중요한 것은 absolute score 자체보다 pattern이다.

DRIFT는 precision과 recall을 함께 개선한다. 즉 단순히 의심스러운 span을 더 많이 찍어서 recall만 올리는 방식이 아니라, claim ledger와 support checking을 통해 harmless exploration을 어느 정도 걸러낸다는 뜻이다.

5-2. What really matters in the experiments

1) First-error localization은 여전히 어렵다

DRIFT가 macro-F1을 크게 올려도 first-error accuracy는 여전히 낮다. 특히 hard split에서는 더 그렇다. 이는 error localization과 first-error localization이 다른 능력이라는 뜻이다.

실무적으로는 이 부분이 제일 중요하다. Agent log를 디버깅할 때 전체 failure region을 찾는 것만으로는 충분하지 않다. Prompt를 고쳐야 하는지, search policy를 고쳐야 하는지, evidence verifier를 넣어야 하는지는 첫 harmful commitment가 어디서 생겼는지에 달려 있다.

2) Scaling alone is insufficient

논문은 Qwen variants에서 model scale 증가가 trajectory diagnosis 성능을 단조롭게 올리지 않는다고 분석한다. 이는 deep-research agent debugging이 단순 backbone capacity 문제가 아니라는 뜻이다.

이 결과는 설계 관점에서 꽤 강한 메시지다. Agent reliability를 높이려면 더 큰 model을 auditor로 붙이는 것만으로는 부족하다. Log를 claim, support, dependency로 구조화하는 관찰 방식이 필요하다.

3) Span complexity가 커질수록 어렵다

Further analysis에서는 span complexity가 증가할수록 Bare와 DRIFT 모두 성능이 떨어진다. 다만 DRIFT는 span bucket 전반에서 Bare보다 일관되게 높게 나온다.

이 결과는 실제 서비스에 직접 연결된다. Real agent log는 benchmark보다 더 길고 noisy할 수 있다. 따라서 production 환경에서는 span segmentation, summarization, evidence indexing, claim graph compression 같은 engineering이 DRIFT류 방법의 성능을 좌우할 가능성이 크다.

4) Module ablation은 claim-level auditing의 가치를 보여준다

Ablation은 bare prediction, Claim Keeper, Claim Keeper plus Support Seeker, full DRIFT를 비교한다. 성능은 module을 추가할수록 올라간다. 논문은 가장 큰 gain이 claim-level auditing에서 나오고, support checking과 dependency tracing이 evidence grounding과 localization을 더 보완한다고 해석한다.

이 지점이 DRIFT의 핵심이다. Span을 독립적으로 scoring하는 대신, trajectory 내부에서 claim이 어떻게 생기고, 어떤 evidence를 만나고, 어디서 확정되는지 보는 구조가 효과를 만든다.

5) Error type coverage가 중요하다

Bare model은 explicit error는 어느 정도 잡지만, source verification, constraint semantics, unsupported commitment, omitted constraint check처럼 support 검증이 필요한 failure에는 약하다. DRIFT는 evidence and constraint 관련 error에서 특히 큰 개선을 보인다.

Deep research failure의 많은 부분은 “정보가 없다”가 아니라 “정보가 충분하다고 착각한다”에서 나온다. 이 차이를 잡으려면 claim support status를 별도로 두는 것이 자연스럽다.

6. Limitations

1. First-error accuracy는 아직 낮다.
   • DRIFT는 span-level F1을 올리지만, 가장 이른 harmful span을 정확히 맞히는 능력은 제한적이다.
   • Long trajectory debugging에서 실제로 가장 필요한 것은 early root cause localization이므로, 이 부분은 아직 열려 있다.
2. Dataset coverage는 넓지만 무한하지 않다.
   • TELBench는 GAIA-val, XBench, BrowseComp-test 기반 task와 MiroFlow, OAgent framework에서 만들어졌다.
   • 실제 enterprise agent, private knowledge base, codebase agent, multi-modal research workflow로 옮기면 error distribution이 달라질 수 있다.
3. Span segmentation에 의존한다.
   • Semantic span boundary가 흔들리면 label도 흔들린다.
   • Production system에 적용하려면 framework-specific raw event를 stable semantic span으로 바꾸는 logging contract가 먼저 필요하다.
4. Annotation cost가 높다.
   • LLM-assisted expert review를 거쳤고, expert annotator들이 매우 많은 시간을 사용했다.
   • 새로운 domain에서 같은 품질의 TELBench류 benchmark를 만들려면 annotation guideline과 reviewer training이 필요하다.
5. Completed trajectory diagnosis에 초점이 있다.
   • DRIFT는 완료된 trajectory를 audit한다.
   • 실시간으로 agent를 중단하거나, search query를 수정하거나, evidence verification을 강제하는 intervention policy까지 직접 제안하지는 않는다.
6. 원문 안에 version naming 확인 포인트가 있다.
   • arXiv abstract와 setting text에서는 Claude-Sonnet-4.5가 보이지만, HTML table row에는 Claude-Sonnet-4.6으로 보인다.
   • 최종 게시 전 PDF table과 source를 기준으로 model name을 다시 확인하는 것이 안전하다.

7. My Take

7-1. Why this matters for my work

이 논문의 가장 큰 가치는 “agent evaluation을 final answer scoring에서 trajectory observability로 끌어온다”는 점이다.

LLM agent를 실제로 운영할 때 가장 답답한 순간은 점수가 낮게 나오는 순간이 아니라, 왜 낮게 나왔는지 모를 때다. 특히 deep research agent는 retrieval, browsing, source verification, synthesis가 섞여 있어서 final answer만 보면 병목이 search인지 reasoning인지 evidence grounding인지 알기 어렵다.

DRIFT는 이 문제를 claim lifecycle로 본다. Claim이 언제 생겼고, 어디서 support를 얻었으며, 어떤 span에서 확정되었는지 기록한다. 이 관점은 evaluation뿐 아니라 agent logging format 설계에도 유용하다.

7-2. Reuse potential

이 논문의 재사용 가능성은 꽤 높다.

1. Internal agent trace QA
   • 사내 research agent, document QA agent, browser agent의 실패 log를 semantic span으로 나누고 error span을 annotate할 수 있다.
   • 이후 TELBench와 비슷한 internal diagnostic benchmark를 만들 수 있다.
2. Agent observability dashboard
   • Final answer score 대신 claim ledger, support status, dependency path를 보여주는 debugging UI를 만들 수 있다.
   • 특히 customer-facing agent에서는 “어떤 source가 어떤 claim을 지지했는가”를 audit trail로 남기는 것이 중요하다.
3. Training data filtering
   • 실패 trajectory 전체를 버리는 대신, harmful span과 benign exploration을 분리해 후처리할 수 있다.
   • Rejection sampling이나 preference data construction에서 더 세밀한 signal을 만들 수 있다.
4. Runtime intervention
   • DRIFT 자체는 offline audit에 가깝지만, Support Seeker의 missing or weak status는 runtime verifier로 바꿀 여지가 있다.
   • 예를 들어 final answer 전에 consequential claim 중 weak support가 있으면 추가 search나 source verification을 강제할 수 있다.

7-3. Follow-up papers

• AgentProcessBench: diagnosing step-level process quality in tool-using agents
• TRAIL: agent trace issue localization 계열 work
• ProcessBench: process-level reasoning error identification
• DeepResearch Bench, DeepResearchGym, DRBench 계열 deep research evaluation benchmark
• GrepSeek: direct corpus interaction search agent
• Harness-1: state-externalizing search agent RL

8. Summary

• 이 논문은 deep-research agent 평가를 final answer correctness에서 span-level error localization으로 옮긴다.
• TELBench는 2,790개 real trajectory에서 출발해 1,000개 verified diagnostic instance를 만든 benchmark다.
• Error span은 failed search가 아니라 unsupported or conflicting claim이 answer path에 영향을 주는 harmful commitment다.
• DRIFT는 Claim Keeper, Support Seeker, Dependency Tracer로 claim lifecycle을 추적한다.
• 실험은 DRIFT가 bare prompting과 generic agentic auditor보다 나은 localization을 보이지만, first-error localization은 여전히 어렵다는 점도 함께 보여준다.