Agentic RAG与深度研究：从检索决策到证据核验的工程实践

上篇聊完了Agent的整体框架之后，这篇把焦点收窄到一个我私心认为最贴近工业落地价值的方向：Agentic RAG 与深度研究（Deep Research）。过去半年我自己的实验体感是，第一代RAG系统几乎全部卡在"检索对但答错"和"检索错就答得更错"这两个问题上，而Agentic RAG给出的解法不是换一个更大的模型，也不是堆更多向量库，而是把"检索"从一次性的前置步骤，升级成一个由Agent主导的、可迭代的决策过程。

这篇总结我会尽量把论文里的思想（ReAct、Self-RAG、CRAG这类）和工业界的工程实现对齐着讲，重点落在四块：检索怎么由Agent驱动、证据核验怎么做才不是摆设、长程研究场景下上下文和状态怎么管，以及效率边界到底在哪——也就是深度研究成本失控之前，你还能压榨出多少价值。

1. 从传统RAG到Agentic RAG：检索不再是"取数"，而是"决策"

1.1 传统RAG的"三板斧"为什么在复杂问题上失灵

传统RAG的流程干净利落：用户问题进来，embedding化，去向量库召回top-k，拼到Prompt里让模型作答。这套东西在"知识库问答""文档问答"这类场景里够用，问题在于它默认了一个前提——用户的问题可以一次性地映射到正确的检索意图上。

但在深度研究场景里，这个前提经常不成立。举个例子，用户问的是一个跨源头的综合问题，比如"对比一下几家主流向量数据库在亿级规模下的写放大和查询延迟表现"。传统RAG的做法是把这句话整体embedding，然后去检索。问题是"主流向量数据库"是个模糊范畴，不同源文档说得可能是Milvus、Qdrant、Weaviate或者Elasticsearch的向量插件，单次top-k召回可能只覆盖其中一个，或者召回的全是产品介绍页而不是性能基准。最终生成的答案看着有引文、有数字，但实际是拿局部信息硬凑了一个全局结论。

更深一层的问题在于，传统RAG没有"反馈机制"。模型引用了某篇文档，但文档本身和问题只沾一点边，系统不会发现，也不会重新检索。没有验证环节，就谈不上自我纠错。所以你Review答案时会发现一个典型怪象：每一句话单独拿出来都是有出处的，但整段回答的推理路线是断裂的。这就是第一代RAG在深度研究问题上系统性失灵的根本原因——流程上的缺陷，不是模型能力或检索质量能单独弥补的。

1.2 Agentic RAG的本质变化：从"检索即服务"到"检索即工具"

Agentic RAG的论文视角（包括Self-RAG、CRAG、以及更早的ReAct范式）其实在反复论证一件事：检索行为本身应该被纳入模型的推理循环，而不是外挂的取数接口。

ReAct的核心贡献在于把"推理轨迹"和"行动序列"交织在一起。放到RAG场景里，就是模型可以先表达"我需要了解A公司的性能数据"，然后调用检索工具，拿到结果以后不急着生成，而是继续推理"现在有了A的数据，但B和C的数据还缺失，而且B和C的对比维度可能与A不一致"，于是再次检索。这个"推理-行动-观察-再推理"的循环，本质上是把用户原本需要在多轮对话里手动完成的信息搜集动作，内化成了Agent的自主行为。

Self-RAG则引入了"反思"（reflection）机制。模型在生成回答之前，要对检索到的每个片段做一个相关性评估：这个片段对我的回答有帮助吗？支持还是反驳？有没有信息缺失？相当于给RAG加了一个内部质检岗。CRAG更进一步提了"检索纠错"——当检索结果质量很差的时候，系统要有能力判断出来，并且触发补救动作（比如换关键词重新检索、从网页抓取原文、或者干脆告诉用户当前信息不足）。

把这些论文思想收敛到工程实现上，我自己的理解是：Agentic RAG不是某一个具体的算法，而是一套行为准则。Agent拥有检索工具的使用权、暂停权、验证权和重试权。它不再是被动接受检索结果，而是像人一样"查资料——怀疑——再查——交叉验证——下结论"。

1.3 工业界落地时的最小可行形态

论文里的反思机制说得容易，落到工程上要拆成具体模块。我在项目里落地的最小可行形态大概是这样的：一个主Agent负责对话和推理，派生了三个子能力——查询改写器（把原始问题改写成适合检索的子问题）、检索控制器（决定用哪个工具、召回多少条、是否需要二次检索）、证据检查器（对生成内容做引用校验）。这些子能力在实现上就是给大模型注册不同的工具函数，加上一套Routing规则。

实际运行中，我强烈建议不要把"反思"做成无限循环的自我对话，而是给一个明确的迭代上限——我自己的经验是max_iteration设成3到4轮就够了，超过这个数，边际收益急剧下降，纯粹浪费token和时间。这个数字不是拍脑袋定的，后面讲效率边界的时候我会详细给一组实测数据。

2. 深度研究场景下的检索策略：多跳查询分解与动态情报补齐

2.1 深度研究到底"深"在哪里

深度研究对检索的正常理解，不是"一次检索更长时间"，而是"多轮检索每轮都有不同目的"。我拆解下来，深度研究任务里Agent的检索动作大概可以分三类：

第一类是广度铺开：先对问题做粗粒度的情报收集，搞清楚这个领域里有哪些关键主体、关键术语、关键争议点。这一轮检索的query应该偏宽，比如"向量数据库 性能对比 基准"，目的是拿到一个领域地图。

第二类是深度挖掘：在初步的情报里识别出2到3个值得深挖的方向，针对性地做精确检索。这一轮的query要具体得多，比如"Milvus vs Qdrant write amplification benchmark 2024"。

第三类是交叉验证：针对某个特定论断，找多个独立信源来核实。这一轮考验的不是检索能力，而是"找不同表述下的同一事实"的能力。

第一代RAG体系里，这三类动作往往是用户自己做的——用户自己搜一遍、自己再搜一遍、自己来回对比。Agentic RAG要做的就是把这三个动作自动化，并且按顺序组织好。

2.2 查询分解的三条路线：BFS、DFS与混合策略

查询分解是深度研究Agent的"第一步棋"。工业界常见的分解策略可以归纳为三种范式：

• 广度优先（BFS）：把原始问题先拆成若干个独立的子问题，并行发起检索。适合"比较类"问题——比如"对比A、B、C三款产品"，拆成三个独立的产品调研是自然且高效的。
• 深度优先（DFS）：沿着一条推理线追下去，每一步都基于上一步的检索结果生成新的子问题。适合"因果类"或"机制类"问题——比如"某系统为什么性能退化"，要先搞清楚架构，再查具体组件的瓶颈，最后查参数配置。
• 混合策略：先BFS铺开，识别出高价值线索，再对线索做DFS深挖，最后再回到BFS补缺失。这是目前深度研究产品（包括OpenAI的Deep Research、Google的Deep Research）普遍采用的思路。

工程上实现混合策略，关键是给Agent一个"动态选题"的能力。我在具体实现时给Agent注册了一个research_note工具——允许它在研究过程中维护一张半结构化的笔记表（内容摘要、来源URL、可信度评估、待验证点）。每完成一轮检索，Agent就更新一次笔记，然后基于笔记内容决定下一轮检索的方向。这个设计让Agent的行为变得像一个真正的研究助手，而不是一堆无头苍蝇式的检索动作。你也可以用复杂的自回归采样或CDP算法来合成检索路径，但工程上维护一张笔记表的性价比远高于引入复杂的规划算法。

关于知识图谱在查询路径规划中的作用，我的观点是：如果你的领域有成熟的知识图谱，用它来做关系推理（比如"X公司的子公司是Y"）是非常高效的；但如果没有现成的图谱，让Agent现搭一个图谱的效率非常低，不如直接用检索-笔记-再检索的模式。因为Agent在运行期构建的知识图谱很可能充满噪声，错误的实体关系会把后续检索带偏，得不偿失。

2.3 检索工具的分工：一个Agent可以有三个"搜索框"

深度研究场景对检索工具的粒度要求远高于普通RAG。我在实际项目里标配了三个检索工具，各自负责不同层级的信息：

• web_search（通用网络搜索）：负责广度铺开和最新信息的获取，返回标题、摘要、URL列表。
• doc_search（私有库/知识库检索）：负责在受控的文档集里做精确召回，用的是常规的向量检索加关键词混合。
• web_extract（网页内容抽取）：负责对具体URL做全文抓取和正文清洗，提取关键段落。

三个工具的分工非常关键。如果只用web_search，Agent拿到的永远是摘要级信息，对细节论证无能为力；如果一上来就用web_extract，又会陷入"网址海洋"，抓了一堆网页但没法判断价值。正确用法是：先用web_search定位高潜力URL，再用web_extract深挖，最后用doc_search补充内部知识。

另外，结构化数据检索（查数据库、查API）在这个体系里应该单独一个工具。不要试图让大模型直接对着数据表做推理，正确做法是让Agent通过自然语言调用一个"查询执行器"，把问题转成SQL或API请求，拿回结果后再推理。这一步我踩过坑：一开始让Agent直接操作数据库接口，结果它生成了完全错误的过滤条件，还振振有词地给出了答案。后面改成"Agent只负责生成查询意图，具体执行交给确定性代码"之后，错误率急剧下降。

2.4 检索结果去重与合并：别让相似内容稀释了注意力

深度研究跑几轮之后，检索结果是会膨胀的。尤其用了混合策略，很容易出现五六个来源讲的是同一件事——同一个官方公告被一堆技术媒体转载，每篇措辞略有不同。如果傻乎乎地把这些都塞进上下文，你就等着被反复重复的信息淹没。

我的做法是对检索结果做两层处理：第一层是去重，按文本相似度（简单点就用MinHash或SimHash）聚类，每簇只保留权威性最高的那篇；第二层是合并，如果多个来源涉及同一事实但数字有出入，不作取舍，而是作为"冲突信息"保留下来，进入后面的证据核验环节，让Agent去判断哪个可靠或者标注不确定。这里必须强调：不要用大模型做去重，太贵也没必要，传统去重算法又快又稳。大模型的价值在"判断冲突"，不在"识别重复"。

3. 证据核验：怎么让Agent为自己的每一个论断负责

3.1 幻觉问题的真相：不是"模型不会"，而是"判定不会"

很多人把Agent幻觉归咎于模型能力不足，但我在实践中发现，更强的模型（比如用更先进的模型做同样的流程）确实能降低幻觉率，但永远消灭不了。因为幻觉的真正来源是模型在生成时只做了"语义续写"，并没有为每个论断做"证据检查"。

模型生成一句"论文中的benchmark显示X系统比Y系统快3.2倍"，它在生成时只是沿着语言概率把这句话续写了出来，并没有检查"X系统在论文中是否真的被评测过"。你要它不幻觉，就要强迫它在生成这句话之前，先找出支撑这个数字的原文片段。这就是证据核验的核心思路：把"隐性的事实检查"变成"显式的推理动作"。

3.2 证据核验的工程链路：从"引用溯源"到"原文比对"

实际项目中，我做的证据核验不是一个"事后检查"，而是一个贯穿生成周期的三层链路：

第一层是引用界限（Citation Grounding）：模型生成时必须对每个关键论断给出引用来源（文档ID或URL）。这个可以用Prompt约束强制实现，更稳的做法是用结构化输出（如JSON mode / function calling）让模型按"论断+引用"的格式生成，而不是自由文本。没有引用的论断，Answers会被视为低置信度，需要重读来源或删除。

第一层是原文比对（Verbatim Check）：有了引用之后，系统自动提取引用的原文片段，和生成的论断做一次语义相似度比对。这个"比对"我不建议用大模型做——贵，且对短文本的相似度判断并不比普通NLP方法好多少；用一个细粒度的embedding模型加对齐算法（比如计算句子级别的逐句相似度）就够了。只有当相似度低于阈值时，才把原文片段和论断交给大模型做一次"复核"，判断到底是引用错误还是表述偏差。

第三层是多源交叉：对关键论断，同一事实至少要两个独立来源支持。这个逻辑在论文里叫Multi-hop Verification，工业界落地时不要对所有句子都做多源验证，成本太高。我给每个论断定一个"关键度"标签——直接影响结论的论断（比如性能数字、价格、发布日期）强制多源交叉，背景铺垫性内容只做单源核验。这样可以把核验成本控制在一个可接受的范围。

3.3 证据核验里的"人为制造冲突"设计

我在这里分享一个从实际踩坑中提炼出的设计思路——主动让Agent面对冲突信息。

深度研究场景里，不同来源的信息经常互相矛盾。很多Agent设计倾向于回避矛盾，把最"主流"的观点当答案输出。但我发现，如果在检索阶段故意保留冲突信息（不去强制统一），并在生成阶段要求Agent明确区分"事实A说X，事实B说Y，两者存在矛盾，原因可能是……"，产出质量会显著提升。原因很简单：深度研究报告的真正价值不在于给出唯一确定的结论，而在于把不确定性结构化。用户要的是"哪些是靠谱的、哪些是有争议的、哪些是未知的"，这个结构化的不确定性本身就是深度研究的核心产出。

实现上要注意给模型一个"不确定"的合法出口。如果你在Prompt里把所有问题都设置成"必须回答"，模型就会编一个答案；如果你允许它输出"信息不足，无法确认"，它反而会更诚实地面对证据缺口。这个看似简单的设计，对报告可信度的提升是肉眼可见的。

3.4 核验循环的最优形态：有限迭代，而不是无限自省

Self-RAG风格的反思机制如果不加约束，会变成"模型自己质疑自己，再自己回答，再质疑……"的无底洞。我在工程上把核验循环设计成"验证-修订-再验证"的三段式，最多跑两轮：

第一轮：生成初稿，标注引用，做原文比对，标记低置信论断。 第二轮：只针对低置信论断做定向的补充检索和修订，其他部分不动。 如果第二轮之后仍有低置信论断，不是继续迭代，而是将其标记为"存疑"放入报告的"不确定性清单"。

这套设计的合理性在于：大模型的自我反思存在"同源偏差"——让同一个模型质疑自己，它往往会维护自己最初的答案，而不是真正找错。所以有效的修订动作必须引入"新信息"（补充检索的原文、另一篇文档的证据），而不是让模型空转思考。如果拿不到新信息，修订再多轮也是原地打转。

4. 长程研究的上下文管理：笔记系统、状态追踪与故障恢复

4.1 token膨胀是长程研究的头号杀手

深度研究任务动辄几十轮检索、几百个文档片段、数万token的中间结果。如果你把所有中间结果都堆进上下文，5轮之后模型就开始"失忆"——它丢失了最早检索到的关键信息，甚至在引用时张冠李戴。这个问题业内叫"Lost in the Middle"或者更宽泛的"上下文过载"。在Agentic RAG里，上下文不再是"信息载体"，而是稀缺资源，需要做显式的资源管理。

4.2 用"外部笔记系统"代理"模型记忆"

我目前用得最稳的上下文管理方案，是给Agent配套一个外部笔记系统（就是我前面提到的research_note），而不是依赖模型自己的记忆。每条笔记是一个结构化的对象，包含：

• topic（主题标签，方便后期检索）
• content（经过压缩的内容摘要，控制在150字以内）
• source（来源URL或文档ID）
• confidence（可信度：高/中/低/冲突）

模型的上下文里只保留两类东西：当前最新一轮推理的短时记忆（比如最近的检索结果和正在思考的推理链），以及笔记系统的高层索引（笔记的主题标签和一句话摘要）。当模型需要某个早期细节时，它先查索引，再通过一个get_note工具把完整笔记拉回上下文。

这套"索引在上下文，正文在外存"的设计，本质上模仿了人类研究者做笔记的方式——不是把读过的所有内容背下来，而是记住"笔记记在了哪里、大概什么内容"。工程上的好处显而易见：上下文占用稳定在几千token级别，不会随着研究深度的增加而线性膨胀。

4.3 任务状态追踪与Checkpoint：让研究任务"断点续传"

深度研究跑起来往往要好几分钟甚至更长。线上服务如果走到一半进程崩了、网络超时了、或者用户关掉了页面，整个任务就前功尽弃，这是工业落地时最难受的问题。

我的解法是把任务状态做成持久化对象，每一步都打Checkpoint。状态对象包括：研究目标（原始问题和约束条件）、已收集的笔记列表、当前循环轮次、已完成的子任务列表、待办子任务列表、以及一个"临时裁决"字段（例如"已确认A公司数据足够，B公司数据待补充"）。每完成一轮检索-笔记-核验的循环，就把整个状态对象写一次存储（可以是Redis或普通的数据库）。

这样即便任务中断，恢复时只需要从最后一个Checkpoint加载状态，让Agent把线程接起来继续跑。更重要的是，这个状态对象为"用户可干预"提供了可能——用户可以在中途查看Agent的研究进展，然后追加指令或者修正方向。这个能力在深度研究产品形态上是刚需，没有Checkpoint机制是做不到的。

4.4 失败恢复：限流、超时与降级策略

长程研究会频繁触发外部API调用（搜索接口、网页抓取、模型推理），任何一环都可能出问题：搜索接口限流、网页返回404、模型回答被截断、格式校验失败。我总结的恢复策略是"分层降级"：

第一层是重试：对超时和5xx类错误，指数退避重试最多3次。 第二层是替换：一个搜索源失败，换另一个搜索源；一个网页抽不出来，标注"源不可用"并跳过，不影响整体流程。 第三层是降级输出：如果核心逻辑多次失败导致无法完成完整研究，不允许Agent硬给一个看起来完整的答案——应该明确告诉用户"研究过程中部分环节失败，当前结论可能不完整，建议重试"。这个"允许不完整"的降级策略，比硬撑一个假完整的报告要诚实得多，对用户来说也更可靠。

5. 效率边界：深度研究到底要烧多少钱，多深的深度才有意义

5.1 一次深度研究的成本结构拆解

把深度研究任务做成产品的时候，你会立刻发现成本是个绕不开的话题。我自己实测一组典型数据（基于中等规模任务：目标是对一个垂直领域做5个子方向的调研，每方向2-3轮检索）：

• 模型推理token消耗：约 150万-250万 token（其中Agent推理链约 30万，检索结果注入约 80万，核验和报告生成约 100万）
• 外部API调用次数：搜索接口 20-40 次，网页抽取 10-20 次
• 总耗时：3-8 分钟（如果并发度做得好可以压到 2 分钟上下）

换算成成本的话，按主流模型的定价水平，单次深度研究的模型成本大约在 0.3-1 美元这个量级。如果要做成C端产品免费开放，这个成本是完全扛不住的；作为企业内部的"深度调研助手"，这个成本则是完全可以接受的——毕竟一个分析师人工调研三个小时的人力成本远超这个数。

5.2 质量-深度-成本的三维权衡：每条"额外深度"的边际收益递减

我做过一组对比实验：同样一个研究任务，分别限制迭代轮数为 1、3、5、8，然后请行业内的同事盲评输出质量。结果很有意思：

数据说明一个扎心的事实：深度研究的边际收益在3-5轮之后急剧衰减。第8轮相比第5轮只提升了3个质量分，成本却多了70%。原因是绝大多数有价值的信息在头几轮检索里已经被扫过了，后面几轮基本上是在重复确认和边际补充。所以我的建议是：把默认迭代上限设在4-5轮，除非任务本身确实需要极深的历史背景排查，否则不要轻易调高。

5.3 什么时候不要用深度研究

效率边界不仅包括"多深才划算"，还包括"什么时候根本不该上深度研究"。我的判断准则很明确：

• 如果用户问题本身是"已知答案的确定性问题"（比如查一个产品的发布日期、某个术语的定义），深度研究是纯浪费，一个轻量RAG或者普通搜索就够了。深度研究对这类问题的答案不会更好，只会更慢更贵。
• 如果用户对实时性要求很高（比如问"刚才那场球的比分"），深度研究的分钟级延迟根本满足不了。
• 如果用户问题的信息本身就稀缺（一个非常冷门的话题，全网只有一两篇相关文章），深度研究的"多源交叉验证"做不了，硬做只会产生大量幻觉，因为模型会把"没有证据"当成"可以自由发挥"。

在这些场景下，正确做法是先用一个轻量分类器判断问题类型，命中"简单查询"就直接走轻量通路，只有判断为"复杂多源研究型问题"时才触发深度研究Agent。我见过太多团队抱着"Agent能搞定一切"的心态，把深度研究用在所有问题上，结果是成本爆炸、用户等待时间变长、答案反而更不稳定。

5.4 工业界部署时另一个常被忽略的优化点：并行度

深度研究的耗时和成本还有一个隐藏瓶颈——检索循环的串行化。很多Agent在做多子任务时是一个个顺序执行的，导致总耗时线性叠加——这完全是可以避免的。工业界落地时一定要把"可并行的子任务"识别出来，并行发起检索（BFS阶段天然可并行），把整个研究耗时压到原来的三分之一甚至更低。

并行度优化的实现细节是，把主Agent的"待办子任务"队列设计成可以批量下发、批量回收的结构。每个子任务独立执行、独立写笔记，主Agent在所有并行任务完成后做汇总推理。这里要小心：并行任务的数量不要超过上下文能承载的结果数量上限。我有一个经验值——同一轮并行最多4到6个子任务，再多的话返回结果太长，主Agent处理不过来，反而内存爆炸、推理质量下降。

另外，实际部署时必须给外部API调用加并发上限和超时熔断。深度研究是长任务，API供应商的限流策略通常很严格，不加并发控制的话高频调用会被直接拒绝，整个研究链条就断了。

回到这篇总结的核心：Agentic RAG 不是"给RAG加了个Agent外壳"，深度研究也不是"让Agent跑得越久越好"。检索决策权、证据核验闭环、长程状态管理、效率边界控制——这四件事做到位了，深度研究才有真正的产品价值。如果只学一件事，我建议你记住"3-5轮迭代上限 + 外部笔记系统 + 多源交叉验证"这个最小铁三角，先拿它跑通一个业务场景，再谈更多花活。