Deep Research 最有价值的地方，不是让模型多读几页材料，而是让它知道先读什么、读到哪里要停下来追问、什么时候该回头补证据。
普通 RAG 像是把一摞资料搬到写作者桌上。Deep Research 更像派出一位研究员。他不会从第一页读到最后一页就开始写，而是先画出问题地图，沿着线索去几个关键地点，遇到矛盾就折返，发现空白再补查，最后把这段调查路线写进报告。
把它放到工程系统里看，Deep Research 更接近一种 Agentic Search。它不是在普通 RAG 后面接一个更长的总结器，而是让模型围绕一个复杂问题持续规划、搜索、阅读、修正方向、比较证据，最后生成带依据的报告 [1][2][3]。
这也是它和 LongTraceRL 这类工作的内在一致之处。LongTraceRL 关注的是如何让模型从搜索智能体的轨迹中学习长上下文推理：哪些页面被打开，哪些材料看似相关但最终没有被引用，哪些中间实体必须被覆盖，哪些干扰文档最容易误导模型 [9]。换到复杂业务报告生成里，问题几乎一样：系统不应该只保留最终命中的相关材料，而应该保留和组织一条研究轨迹，让模型在写作前经历“提出假设、寻找支持、寻找反证、修正判断”的过程。
所以，复杂业务场景里的 Deep Research，不是一个比 RAG 更大的盒子。它更像几条技术线索汇到同一个地方：Agentic RAG 让模型自己调用工具 [7][8]，自反式检索让模型检查证据 [5]，纠错式检索处理低质量召回 [6]，搜索轨迹学习则把研究过程本身变成训练信号 [9]。
可靠报告不是一次检索后的文本续写，而是一条被规划、验证和修正过的搜索推理轨迹。
从 RAG 到 Agentic Search
传统 RAG 的形态很简单：
用户问题
↓
检索相关 chunk
↓
拼接上下文
↓
生成答案这种方式解决了大模型凭空生成的问题，但它默认了一个前提：只要找到“相关材料”，生成就会可靠。
在简单问答里，这个前提大体成立。比如问“等待期是多少天”，只要找到条款中写等待期的句子，答案就比较稳定。
但复杂业务报告不是简单问答。保险产品解读、合同风险审查、企业尽调、政策合规分析、投研报告、招投标材料评估，都有一个共同特点：真正影响结论的材料，往往不是最显眼、最相似、最顺着问题回答的那一段，而是藏在定义、例外、限制、反向条款和跨文档对照里。
例如销售页写：
可续保至 100 周岁。
如果系统只围绕“续保”做相关性检索，模型很容易写出：
该产品支持续保至 100 周岁。
这句话看起来有依据，但它可能遗漏了正式条款中的关键条件：
保险期间届满后，投保人可申请续保，经保险公司审核同意后方可续保。
这时，改变结论的往往不是“续保”这个显眼词，而是“申请”“审核同意”“保险公司有权决定”这些限制性材料。
复杂业务报告不能停在一次性 retrieve-then-generate。模型得主动决定接下来查什么、为什么查、当前证据够不够、有没有反向材料、结论是不是该收窄。
现有研究其实是一条线
几个相关研究放在一起看，会发现它们并不是松散并列的“参考资料”。它们都在处理同一个麻烦：检索不能只做静态召回，还要能反思、纠错和规划。
Self-RAG 让模型学习何时需要检索，并用反思信号评估检索结果和自身生成。它不再盲目使用外部材料，而是把“是否需要证据”“证据是否相关”“回答是否被证据支持”放进生成过程 [5]。
CRAG 进一步指出，检索结果本身可能质量不足，因此需要检索评估器判断召回是否可靠。如果检索结果不够好，系统要过滤、分解、补充搜索，而不是把低质量上下文直接交给模型 [6]。
Agentic RAG 把这个过程推进为多步工具使用。模型不再只接收固定候选文档，而是可以调用搜索、打开文档、在文档内定位、摘要、继续搜索等工具。检索变成了一个序列决策过程 [7][8]。
OpenAI Deep Research 和 Gemini Deep Research 则把这种能力做成了产品：多步搜索、阅读、分析、综合，最后输出带引用的研究报告。它们服务的不是短问答，而是复杂知识工作 [1][2][3][4]。
LongTraceRL 从训练角度解释了为什么搜索轨迹重要。它不只让模型看到黄金证据，还利用搜索智能体实际走过的轨迹构造干扰文档，并用 rubric reward 奖励中间推理实体覆盖。模型要学的不只是“最终答案是什么”，还包括“在复杂材料中怎样搜索、怎样避开迷惑材料、怎样覆盖关键中间证据” [9]。
这些工作连起来，大致是这样一条技术脉络：
RAG：把外部材料放进上下文
↓
Self-RAG：让模型判断何时检索、如何批判证据
↓
CRAG：发现检索质量不足时进行纠错
↓
Agentic RAG：把检索变成多步工具使用和文档导航
↓
Deep Research：把 Agentic Search 产品化为复杂研究报告
↓
LongTraceRL：从搜索轨迹和中间证据覆盖中学习长上下文推理这条线索最后会落到同一个判断：可靠生成不能只靠“召回更多相关文本”，还要组织一条更好的研究轨迹。
为什么复杂业务报告需要搜索轨迹
在复杂业务场景中，报告不该只是材料的压缩版。它应该看得出系统查过什么、排除了什么、在哪些地方收窄了说法。
专家写报告时，不会只做一件事：找到相关段落，然后改写成自然语言。他会不断追问：
这个判断的依据是什么？
有没有材料反对它？
有没有定义缩窄它？
有没有例外让它不成立？
有没有销售话术和正式条款不一致？
有没有证据缺失导致不能下结论？这些追问串起来，就是搜索轨迹。
普通 RAG 通常只保留搜索结果，不保留搜索过程。但在复杂报告里，过程很重要。一个结论之所以可信，常常是因为系统曾经主动检查过哪些反向路径。
以保险产品为例，系统在写“保障范围”时，不应只检索：
保障范围
保险责任
给付责任
保障计划还应主动检索：
责任免除
不承担
除外责任
等待期
免赔额
赔付比例
医院定义
首次确诊
既往症
申请续保
审核同意
本公司有权这些词不一定和“保障范围”最相似，但它们最可能改变“保障范围较广”这个初步判断。
这就拉开了 Deep Research 和普通检索的距离：
普通检索追求相关性，研究型检索追求结论敏感性。
所谓结论敏感性，是指一段材料未必和问题最相似，却可能显著改变最后的说法。复杂业务报告最怕漏掉的，正是这种材料。
从“证据包”到“轨迹包”
如果按 Agentic Search 来设计 Deep Research，给模型的上下文就不该只是证据包，还应该有轨迹包。
证据包像是一叠照片：每张照片都是真的，但你不知道拍摄顺序、拍摄原因，也不知道侦探为什么最终相信其中几张而放弃另外几张。轨迹包更像案件卷宗：它保留了第一嫌疑人是谁、后来为什么被排除、哪条线索改变了方向、哪些证据不足以定罪。
复杂业务报告更需要案件卷宗。报告里的关键判断，往往不是由某一段文本单独决定，而是由一连串材料之间的关系决定。
证据包通常长这样：
以下是和续保相关的材料：
材料 1
材料 2
材料 3
请总结。轨迹包则应该长这样：
【当前研究问题】
这个产品是否可以被表述为保证续保至 100 周岁？
【初始支持材料】
销售页称：可续保至 100 周岁。
【进一步检查路径】
系统继续检索“申请续保”“审核同意”“保险公司有权”“产品停售”“续保条件”。
【限制性材料】
条款称：保险期间届满后，投保人可申请续保，经保险公司审核同意后方可续保。
【没有找到的材料】
未找到明确承诺“保证续保”的条款表述。
【写作约束】
不能直接写成“保证续保至 100 周岁”。应说明销售页表述受到正式条款限制。这个上下文不是单纯材料堆叠，而是在复现一个研究过程。模型读到的不只是“有哪些文本”，还有“为什么要读这些文本”“这些文本之间有什么张力”“哪些结论不能说满”。
LongTraceRL 给人的提醒也在这里：搜索轨迹中的非最终证据、干扰证据、打开但未引用的文档，并不都是噪声。它们能让模型看到困难场景里的弯路和陷阱 [9]。
业务报告也是这样。那些让结论变得不那么顺滑的材料，不该被过滤掉，反而应该被有意放进上下文。
对照式 Deep Research
复杂业务报告里的 Deep Research，可以设计成一种对照式流程。
第一步，形成初始判断。
这一步有点像“按图索骥”。系统先根据销售页、目录、章节标题和显性条款，形成一个粗糙但接近全貌的判断。它不一定准确，但能提供第一张地图。
就像你刚到一个陌生城市，手里拿到的地图比例尺很粗，地名也未必完全准确，但它至少告诉你：商业区大概在哪里，河流大概从哪里穿过，老城区可能藏在哪条路后面。没有这张地图，你只能在街道里随机游走；有了这张地图，你就可以开始有方向地验证它。
这个产品看起来保障范围较广。这个判断不是最终结论，而是第一版路线图。接下来的搜索，就是不断验证这张地图哪里准确、哪里过度简化、哪里漏画了悬崖。
第二步，寻找支持材料。
哪些条款、页面、表格支持这个判断？第三步，寻找反对材料。
哪些定义、免责、例外、限制会反对这个判断？第四步，寻找缺失材料。
有没有必须证明但原文没有明确写出的内容？第五步，修正判断。
这个判断是否应从“保障范围广”改成“保障责任较多，但实际赔付受医院范围、等待期、免赔额和责任免除限制”？第六步，生成章节 brief。
本产品在销售页中呈现出较宽的保障范围，但正式条款中多项条件会影响实际赔付，包括等待期、医院定义、免赔额、赔付比例和责任免除。报告中不宜只用“保障全面”概括，应同时说明保障边界。第七步，汇总多个章节 brief，生成最终报告。
这个过程不是把文档抽成 JSON，也不是让模型一次性总结所有材料。它更像让模型沿着专家式搜索轨迹，一步步收窄结论。
架构上如何落地
一个面向复杂业务报告的 Deep Research 系统，可以拆成五个模块。
1. 研究规划器
研究规划器负责把用户目标拆成研究视角。
保险产品解读可能拆成：
产品定位
保障责任
赔付条件
金额限制
等待期
责任免除
续保规则
理赔流程
销售页与条款差异
用户风险提示合同审查可能拆成：
付款义务
交付标准
违约责任
解除条件
责任上限
知识产权
保密义务
争议解决
单方权利这些视角不只是写作大纲，也会变成后面的搜索计划。
2. 搜索智能体
搜索智能体不只执行一个查询，而是围绕每个研究视角执行多类查询：
支持性查询：寻找承诺和正面材料
限制性查询：寻找条件、定义、范围、比例、门槛
反证性查询：寻找免责、不承担、例外、终止、拒绝、审核
缺失性查询：寻找是否存在明确承诺，若找不到则记录不确定性这一层要主动搜索那些会让当前结论变弱的材料。系统不能只顺着大路往前走，还要刻意绕到背街小巷看看：有没有一条不起眼的岔路，会把原来的结论带向完全不同的地方。
3. 阅读智能体
阅读智能体负责判断材料之间的关系。
如果搜索智能体像探路人，阅读智能体就更像法庭上的交叉询问者。它不会只问证人说了什么，还会追问：这句话支持的是哪一个主张？它有没有被另一份材料削弱？它是不是只在某个条件下成立？
它要回答：
这段材料支持哪个判断？
这段材料限制哪个判断？
这段材料是否和销售页冲突？
这段定义是否改变了责任条款的含义？
这段免责是否推翻了前面的宽泛表述？这里不必急着把所有东西抽成统一 schema。复杂业务语义很难被一个稳定的 JSON schema 完整表达，但可以通过对照式阅读任务，把自然语言里的约束关系保留下来。
4. 上下文编排器
上下文编排器负责把材料组织成轨迹包。
一个好的轨迹包应该包含：
当前研究问题
初始判断
支持材料
反向检索路径
限制材料
缺失材料
应避免的过度表达
建议形成的谨慎判断这里轮到 上下文工程 发挥作用：不是填满上下文，而是安排模型的阅读顺序和推理方向。
5. 报告生成器与批判器
报告生成器基于多个章节 brief 写成最终报告。批判器随后检查：
是否覆盖核心研究视角？
关键判断是否有证据？
是否忽略了反证材料？
是否把销售话术当成正式承诺？
是否在缺乏证据时过度断言？
是否保留了定义、免责、例外和限制？这和 Self-RAG、CRAG 的思路是一致的：生成之后还要批判，检索不足还要纠错 [5][6]。
评估重点：轨迹质量，而不只是答案质量
如果按 Agentic Search 来做 Deep Research，评估也不能只看最终报告写得好不好。
至少要看三件事。
第一，检索轨迹是否合理。
系统是否从初始问题拆出了正确研究视角？
是否进行了多轮搜索？
是否打开了关键文档？
是否追踪了定义、例外和跨文档引用？第二，反证覆盖是否充分。
每个关键结论是否都检查了可能反对它的材料？
是否检索了限制性关键词？
是否检查了免责、定义、等待期、终止、审核、除外等内容？第三，最终报告是否忠于轨迹。
报告是否反映了支持和限制之间的平衡？
是否遗漏了轨迹中发现的重要反向材料？
是否把不确定性写成确定结论？这和 LongTraceRL 的 rubric reward 有直接对应关系。它不只奖励最终答案正确，还奖励中间推理实体覆盖 [9]。复杂业务报告也应该这样评估：文章是否好读是一层，关键研究路径有没有走到，是另一层。
为什么这适用于更广泛的业务场景
保险产品只是一个典型样本。换到其他业务报告，难点仍然很像：
材料很多；
信息分散；
关键证据不显眼；
结论容易被例外修正；
报告必须可靠、可追溯、可审查。合同审查中，最重要的可能不是“双方应履行义务”，而是某个单方解除权、责任上限或违约免责。
企业尽调中，最重要的可能不是公司介绍里的增长故事，而是诉讼记录、客户集中度、关联交易和监管处罚。
政策解读中，最重要的可能不是政策目标，而是适用范围、过渡期、例外条款和执行口径。
投研报告中，最重要的也不只是公司优势，而是能推翻投资假设的反向证据。
这些场景都需要系统做同一件事：
不只寻找支持当前叙事的材料，还要寻找最可能破坏当前叙事的材料。
普通 RAG 很容易顺着当前叙事找证据。Deep Research 要多走一步：专门寻找会破坏当前叙事的材料。
结语
如果 Deep Research 只是“读更多网页、生成更长报告”，那它只是一个更贵的 RAG。
把它放回 Agentic Search，它的工程意义才清楚：模型不再被动接收检索结果，而是主动规划搜索路径、寻找证据、寻找反证、修正判断，并把这条轨迹写进报告。
这也解释了为什么 Deep Research、Agentic RAG 和 LongTraceRL 会走到一起 [1][3][7][8][9]。它们都在回答同一个问题：
如何让模型在海量材料中，不只是找到相关文本，而是学会像专家一样研究问题？
复杂业务报告生成不能只押注更大的上下文窗口，也不能只换一套更漂亮的摘要模板。更要紧的是那条搜索推理轨迹。
工程上，我们要从：
retrieve relevant chunks → generate report走向：
plan research → search support → search opposition → read contrastively → revise claims → write grounded report这条链路走完，RAG 才不只是给模型塞材料，而是开始像一个会查证的研究系统。
本文主要讨论复杂业务报告如何生成。要评测这类报告，还需要另一套工程化尺子：从总分切到 checkpoint，再用元评测指标校准评测器本身。详见 如何科学评测 Agent 生成的文本报告：从评分体系到评测器的元评测。
如果要看这套思想在真实保险报告生产链路里的完整落地，可以继续看 保险产品解读报告系统：Multi-Agent 生产链路与评测闭环。那篇文章把 Deep Research、外层 Graph、质量网关、评分 Agent 和产品评测 Agent 放到同一个系统里讨论。
参考资料
- 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