Deep Research 的价值，不是让模型读更多材料，而是让模型以更接近专家的方式组织阅读过程。
更准确地说，Deep Research 本质上是一种 Agentic Search。它不是在普通 RAG 后面加一个更长的总结器，而是让模型像研究员一样，围绕一个复杂问题持续规划、搜索、阅读、修正方向、比较证据，最后生成带依据的报告。
这也是它和 LongTraceRL 这类工作的内在一致之处。LongTraceRL 关注的是如何让模型从搜索智能体的轨迹中学习长上下文推理：哪些页面被打开，哪些材料看似相关但最终没有被引用，哪些中间实体必须被覆盖，哪些干扰文档最容易误导模型。换到复杂业务报告生成里，问题几乎一样：系统不应该只保留最终命中的相关材料，而应该保留和组织一条研究轨迹，让模型在写作前经历“提出假设、寻找支持、寻找反证、修正判断”的过程。
所以，复杂业务场景里的 Deep Research，不是一个比 RAG 更大的盒子，而是 Agentic RAG、自反式检索、纠错式检索、搜索轨迹学习共同指向的一种范式：
可靠报告不是一次检索后的文本续写，而是一条可被规划、验证和修正的搜索推理轨迹。
从 RAG 到 Agentic Search
传统 RAG 的形态很简单：
用户问题
↓
检索相关 chunk
↓
拼接上下文
↓
生成答案这种方式解决了大模型凭空生成的问题，但它默认了一个前提：只要找到“相关材料”，生成就会可靠。
在简单问答里，这个前提大体成立。比如问“等待期是多少天”，只要找到条款中写等待期的句子，答案就比较稳定。
但复杂业务报告不是简单问答。保险产品解读、合同风险审查、企业尽调、政策合规分析、投研报告、招投标材料评估，都有一个共同特点：真正影响结论的材料，往往不是最显眼、最相似、最顺着问题回答的那一段，而是藏在定义、例外、限制、反向条款和跨文档对照里。
例如销售页写：
可续保至 100 周岁。
如果系统只围绕“续保”做相关性检索，模型很容易写出：
该产品支持续保至 100 周岁。
这句话看起来有依据，但它可能遗漏了正式条款中的关键条件：
保险期间届满后，投保人可申请续保，经保险公司审核同意后方可续保。
这时，真正改变结论的不是“续保”这个显性相关材料，而是“申请”“审核同意”“保险公司有权决定”这些限制性材料。
因此，复杂业务报告需要的不是一次性 retrieve-then-generate，而是 Agentic Search：模型必须能主动决定接下来要查什么、为什么要查、当前证据是否足够、是否存在反向材料、结论是否需要收窄。
现有研究其实是一条线
如果把几个相关研究放在一起看，它们不是松散并列的“参考资料”，而是在解决同一个问题：如何把检索从静态召回，变成可反思、可纠错、可规划的研究过程。
Self-RAG 的核心是让模型学习何时需要检索，并用反思信号评估检索结果和自身生成。它不是盲目使用外部材料，而是把“是否需要证据”“证据是否相关”“回答是否被证据支持”变成生成过程的一部分。
CRAG 进一步指出，检索结果本身可能质量不足，因此需要检索评估器判断召回是否可靠。如果检索结果不够好，系统要过滤、分解、补充搜索，而不是把低质量上下文直接交给模型。
Agentic RAG 把这个过程推进为多步工具使用。模型不再只接收固定候选文档，而是可以调用搜索、打开文档、在文档内定位、摘要、继续搜索等工具。检索变成了一个序列决策过程。
OpenAI Deep Research 和 Gemini Deep Research 则是这种能力的产品化表达：它们强调多步搜索、阅读、分析、综合，并输出带引用的研究报告。它们不是“问答增强”，而是面向复杂知识工作的研究型代理。
LongTraceRL 则从训练角度解释了为什么搜索轨迹重要。它不只是让模型看到黄金证据，还利用搜索智能体实际走过的轨迹构造干扰文档，并用 rubric reward 奖励中间推理实体覆盖。也就是说，模型要学的不只是“最终答案是什么”，还包括“在复杂材料中应该怎样搜索、怎样避开迷惑材料、怎样覆盖关键中间证据”。
这些工作共同构成一条技术脉络：
RAG：把外部材料放进上下文
↓
Self-RAG：让模型判断何时检索、如何批判证据
↓
CRAG：发现检索质量不足时进行纠错
↓
Agentic RAG：把检索变成多步工具使用和文档导航
↓
Deep Research：把 Agentic Search 产品化为复杂研究报告
↓
LongTraceRL：从搜索轨迹和中间证据覆盖中学习长上下文推理这条线索的共同结论是：可靠生成的关键不再是“召回更多相关文本”，而是“组织一条更好的研究轨迹”。
为什么复杂业务报告需要搜索轨迹
在复杂业务场景中，最终报告不是材料的压缩版，而是研究过程的沉淀。
专家写报告时，不会只做一件事：找到相关段落，然后改写成自然语言。专家会不断追问：
这个判断的依据是什么？
有没有材料反对它？
有没有定义缩窄它？
有没有例外让它不成立？
有没有销售话术和正式条款不一致？
有没有证据缺失导致不能下结论？这些追问本质上就是搜索轨迹。
普通 RAG 通常只保留搜索结果，而不保留搜索过程。但在复杂报告里，过程本身非常重要。因为最终结论的可靠性，往往来自系统曾经主动检查过哪些反向路径。
以保险产品为例，系统在写“保障范围”时，不应只检索：
保障范围
保险责任
给付责任
保障计划还应主动检索：
责任免除
不承担
除外责任
等待期
免赔额
赔付比例
医院定义
首次确诊
既往症
申请续保
审核同意
本公司有权这些词不一定和“保障范围”最相似，但它们最可能改变“保障范围较广”这个初步判断。
这就是 Deep Research 和普通检索的区别：
普通检索追求相关性，研究型检索追求结论敏感性。
所谓结论敏感性，就是一段材料虽然不一定最相关，却可能显著改变最终结论。复杂业务报告最需要的，恰恰是这种材料。
从“证据包”到“轨迹包”
如果我们承认 Deep Research 本质是 Agentic Search，那么给模型的上下文也不应该只是证据包，而应该是轨迹包。
证据包通常长这样：
以下是和续保相关的材料：
材料 1
材料 2
材料 3
请总结。轨迹包则应该长这样：
【当前研究问题】
这个产品是否可以被表述为保证续保至 100 周岁？
【初始支持材料】
销售页称：可续保至 100 周岁。
【进一步检查路径】
系统继续检索“申请续保”“审核同意”“保险公司有权”“产品停售”“续保条件”。
【限制性材料】
条款称：保险期间届满后，投保人可申请续保，经保险公司审核同意后方可续保。
【没有找到的材料】
未找到明确承诺“保证续保”的条款表述。
【写作约束】
不能直接写成“保证续保至 100 周岁”。应说明销售页表述受到正式条款限制。这个上下文不是单纯材料堆叠，而是在复现一个研究过程。模型读到的不只是“有哪些文本”，还有“为什么要读这些文本”“这些文本之间有什么张力”“哪些结论不能过度表达”。
这正是 LongTraceRL 给我们的启发：搜索轨迹中的非最终证据、干扰证据、打开但未引用的文档，并不是噪声。它们反而能让模型学会什么是困难场景下的有效推理。
在业务报告中也一样。那些让结论变得不那么顺滑的材料，不应该被过滤掉，而应该被有意放进上下文。
对照式 Deep Research
可以把复杂业务报告中的 Deep Research 设计成对照式流程。
第一步，形成初始判断。
这个产品看起来保障范围较广。第二步，寻找支持材料。
哪些条款、页面、表格支持这个判断？第三步，寻找反对材料。
哪些定义、免责、例外、限制会反对这个判断？第四步，寻找缺失材料。
有没有必须证明但原文没有明确写出的内容？第五步，修正判断。
这个判断是否应从“保障范围广”改成“保障责任较多，但实际赔付受医院范围、等待期、免赔额和责任免除限制”？第六步，生成章节 brief。
本产品在销售页中呈现出较宽的保障范围，但正式条款中多项条件会影响实际赔付，包括等待期、医院定义、免赔额、赔付比例和责任免除。因此，报告中应避免仅用“保障全面”概括，而应同时说明保障边界。第七步，汇总多个章节 brief，生成最终报告。
这个过程不是把文档抽成 JSON，也不是让模型一次性总结所有材料，而是让模型沿着专家式搜索轨迹逐步收窄结论。
架构上如何落地
一个面向复杂业务报告的 Deep Research 系统，可以拆成五个模块。
1. 研究规划器
研究规划器负责把用户目标拆成研究视角。
保险产品解读可能拆成：
产品定位
保障责任
赔付条件
金额限制
等待期
责任免除
续保规则
理赔流程
销售页与条款差异
用户风险提示合同审查可能拆成：
付款义务
交付标准
违约责任
解除条件
责任上限
知识产权
保密义务
争议解决
单方权利这些视角不是写作大纲那么简单，它们同时也是搜索计划。
2. 搜索智能体
搜索智能体不只执行一个查询，而是围绕每个研究视角执行多类查询：
支持性查询：寻找承诺和正面材料
限制性查询：寻找条件、定义、范围、比例、门槛
反证性查询：寻找免责、不承担、例外、终止、拒绝、审核
缺失性查询：寻找是否存在明确承诺，若找不到则记录不确定性这一步的核心是：系统要主动搜索可能让当前结论变弱的材料。
3. 阅读智能体
阅读智能体负责判断材料之间的关系。
它要回答：
这段材料支持哪个判断？
这段材料限制哪个判断？
这段材料是否和销售页冲突？
这段定义是否改变了责任条款的含义？
这段免责是否推翻了前面的宽泛表述？这里的重点不是把所有东西抽成统一 schema，而是保留自然语言中的约束关系。复杂业务语义很难被一个稳定的 JSON schema 完整表达，但可以通过对照式阅读任务让模型处理。
4. 上下文编排器
上下文编排器负责把材料组织成轨迹包。
一个好的轨迹包应该包含：
当前研究问题
初始判断
支持材料
反向检索路径
限制材料
缺失材料
应避免的过度表达
建议形成的谨慎判断这一步是 上下文工程 的核心。我们不是填满上下文，而是在塑造模型的阅读顺序和推理方向。
5. 报告生成器与批判器
报告生成器基于多个章节 brief 写成最终报告。批判器则检查：
是否覆盖核心研究视角？
关键判断是否有证据？
是否忽略了反证材料？
是否把销售话术当成正式承诺？
是否在缺乏证据时过度断言？
是否保留了定义、免责、例外和限制？这对应 Self-RAG 和 CRAG 的精神：生成之后还要批判，检索不足还要纠错。
评估重点：轨迹质量，而不只是答案质量
如果 Deep Research 是 Agentic Search，那么评估也不能只看最终报告写得好不好。
至少要评估三类东西。
第一，检索轨迹是否合理。
系统是否从初始问题拆出了正确研究视角？
是否进行了多轮搜索？
是否打开了关键文档？
是否追踪了定义、例外和跨文档引用？第二，反证覆盖是否充分。
每个关键结论是否都检查了可能反对它的材料？
是否检索了限制性关键词？
是否检查了免责、定义、等待期、终止、审核、除外等内容？第三，最终报告是否忠于轨迹。
报告是否反映了支持和限制之间的平衡？
是否遗漏了轨迹中发现的重要反向材料？
是否把不确定性写成确定结论？这和 LongTraceRL 的 rubric reward 有直接对应关系。它不只奖励最终答案正确，还奖励中间推理实体覆盖。复杂业务报告也应类似：不仅评估最终文章是否好读，还要评估它是否覆盖了关键研究路径。
为什么这适用于更广泛的业务场景
保险产品只是一个典型样本。更广泛地看，任何复杂业务报告都面临同一种困难：
材料很多；
信息分散；
关键证据不显眼；
结论容易被例外修正；
报告必须可靠、可追溯、可审查。合同审查中，最重要的可能不是“双方应履行义务”，而是某个单方解除权、责任上限或违约免责。
企业尽调中，最重要的可能不是公司介绍里的增长故事，而是诉讼记录、客户集中度、关联交易和监管处罚。
政策解读中，最重要的可能不是政策目标，而是适用范围、过渡期、例外条款和执行口径。
投研报告中，最重要的也不只是公司优势，而是能推翻投资假设的反向证据。
这些场景都需要同一种能力：
不只寻找支持当前叙事的材料，还要寻找最可能破坏当前叙事的材料。
这就是 Deep Research 相比普通 RAG 的本质升级。
结语
如果把 Deep Research 理解成“读更多网页、生成更长报告”，那它只是一个更贵的 RAG。
但如果把它理解成 Agentic Search，它的意义就清楚了：模型不再被动接收检索结果，而是主动规划搜索路径、寻找证据、寻找反证、修正判断，并把这条轨迹沉淀为可靠报告。
这也解释了为什么 Deep Research、Agentic RAG 和 LongTraceRL 本质上是一体的。它们都在回答同一个问题：
如何让模型在海量材料中，不只是找到相关文本，而是学会像专家一样研究问题？
复杂业务报告生成的关键，不是更大的上下文窗口，也不是更漂亮的摘要模板，而是更好的搜索推理轨迹。
最终，我们要从：
retrieve relevant chunks → generate report走向：
plan research → search support → search opposition → read contrastively → revise claims → write grounded report这才是从 RAG 到 Deep Research 的真正跃迁。
参考资料
- OpenAI: Introducing deep research
- OpenAI: Deep research System Card
- Google AI for Developers: Gemini Deep Research Agent
- Google Gemini: Deep Research overview
- Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
- Corrective Retrieval Augmented Generation
- AgenticRAG: Agentic Retrieval for Enterprise Knowledge Bases
- Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
- LongTraceRL: Learning Long-Context Reasoning from Search Agent Trajectories with Rubric Rewards