Agentic RAG与深度研究实战：检索规划、证据核验与工程落地

在Agent相关的技术讨论里，“Agentic RAG”和“深度研究（Deep Research）”这两个词，今年基本是被提及频率最高的两个方向。一方面，RAG从早期的“向量检索+拼接提示词”演变成了由Agent编排的复杂流水线，检索不再是一次性的，而是多轮、带判断、带反思的。另一方面，深度研究类产品（比如各种AI调研助手）把“给定一个宽泛问题，自动产出带参考文献的长报告”变成了可能。

这篇文章是Agent论文与工业界实战总结的第二篇，重点聊聊我在落地Agentic RAG和深度研究系统时遇到的核心问题：检索规划怎么做、证据核验怎么落地、长程任务如何不跑偏，以及效率和成本边界在哪里。内容偏工程实践，也穿插一些论文观点，适合正在搞Agent应用、RAG系统优化，或者想自己搭深度研究工具的人参考。

1. 从传统RAG到Agentic RAG：为什么要“Agent化”

很多团队早期做RAG，走的是经典链路：用户query进来，embedding召回top-k文档，重排后把片段拼到上下文里，让大模型基于片段生成回答。这个流水线在知识库问答场景下足够用，但如果问题是多跳的、需要对比多个来源、需要迭代搜索的，传统RAG就暴露出明显的短板——它没有“判断”能力。

1.1 传统RAG的三个硬伤

第一个硬伤是召回质量直接决定答案质量，而且无法补救。如果embedding阶段就没召回相关文档，后面做得再好也白搭。第二个硬伤是缺乏多轮推理能力，复杂问题通常需要拆解成子问题，逐个搜索、验证、再汇总，传统RAG做不了这个循环。第三个硬伤是证据不透明，回答可能综合了多个文档，但用户根本不知道哪句话来自哪个来源，出了错也没法追溯。

这三个问题，本质上是因为RAG链路里“检索”是单向的、机械的。Agentic RAG的思路是把大模型作为调度中心，让模型自己决定：现在要不要检索？检索什么？检索结果够不够？要不要换一种方式再检索一次？这个转变，从“一次检索定生死”变成了“多轮检索动态逼近答案”。

1.2 Agentic RAG的几种范式

在实际工程里，Agentic RAG大概有这么几种范式可以选：

• 路由式（Routing）：模型先判断query属于哪种类型，然后决定走向量检索、走SQL查询、还是直接生成。这个适合意图分叉明显的场景，比如“帮我把薪资表按部门汇总”和“介绍一下我们公司的考勤制度”就走完全不同的通道。

• 规划式（Planning）：模型先把复杂query拆成子问题，然后逐个检索、逐个回答，最后统一汇总。这个就是深度研究的雏形。

• 反思式（Reflection）：模型生成回答后，自己审视一遍“我的答案有没有事实依据？有没有矛盾？”如果发现问题，再触发补充检索。这个适合对准确率要求高的场景。

• 多代理协作式（Multi-Agent）：不同Agent分管不同职责，比如Planner负责拆解问题，Retriever负责搜索，Verifier负责核验，Critic负责挑错，它们之间通过消息传递协作。

选型时我的建议是：能用路由式解决的不要上规划式，能用规划式解决的不要上一整套Multi-Agent。复杂度每上升一层，延迟、成本、出Bug的概率都跟着上升。工业界第一原则是够用就好。

1.3 工业界落地时最容易被忽略的事

有很多团队在Demo阶段效果不错，一上生产就崩，最常见的坑有三个。第一，没有做检索结果的置信度判断，导致模型拿低相关的片段强行作答。第二，没有设计多轮检索的终止条件，Agent会在“再搜一次”的循环里出不来，token消耗爆炸。第三，没有把“溯源”和生成解耦，用户要的是答案带出处，而不是答案本身。

这些问题我在后面的章节会展开讲。这里先记住一个核心认知：Agentic RAG不是一个模型，也不是一个检索器，而是一套由“决策、执行、验证”组成的闭环系统。理解了这个，后面所有设计都是围绕怎么把这个闭环做得稳健、高效。

2. 深度研究的检索规划：从“搜一次”到“系统性调研”

深度研究和普通多轮问答最大的区别，在于任务的规模：一个深度研究任务可能要探索几十个信息源，跨多个子主题，最终产出的报告甚至会有几千字。如果检索规划做得不好，Agent会在信息的海洋里迷失方向。

2.1 问题的分解是研究的灵魂

拿到一个宽泛的研究主题，比如“对比Transformer和Mamba在长文本建模上的效果”，不能直接拿这句话去检索。检索系统很难对一整句复合query返回高质量的、细粒度不同的结果。正确的做法是先做问题分解：

• 一级分解：把主题拆成背景、方法论、对比指标、实验结论、开源实现、业界案例等几个维度。

• 二级分解：每个维度继续下沉，比如“对比指标”可以继续拆成“困惑度对比”、“吞吐量对比”、“显存占用对比”、“长距离依赖任务的benchmark对比”。

• 数据需求映射：为每个叶子子问题定义“要找什么类型的证据”，是找论文、技术博客、GitHub Readme，还是榜单数据。

这个分解过程，最早在STaR和ReAct论文里就能看到雏形，后来在LangChain、LlamaIndex的文档里被工程化成了Plan-and-Solve模式。我的经验是，与其让模型在运行时自由发挥拆解，不如给它一套固定的分解框架（用few-shot exemplar喂进去），产出稳定得多。

2.2 并行检索与延迟优化

深度研究任务子问题数量往往很多，如果串行执行，假设一个子问题平均要2秒检索时间，20个子问题就是40秒，用户早就流失了。所以工程上必须做并行。

我常用的做法是两阶段：先做“粗并行”，把所有一级子问题同时发出去，每个子问题各自走一遍“搜索-阅读-提炼”的循环；之后做“融合”，把各分支产出的中间结果汇总，再做一次交叉验证和查漏补缺。这个过程中需要控制的是并行度——不是越大越好，因为检索接口、下游LLM的并发限制、以及汇总阶段的上下文长度限制，都会制约并行上限。

另外一个细节是动态规划：所有子问题同时启动，有些分支早早完成，有些分支卡住了。最好设计一个“早停机制”，对高质量来源覆盖率已经足够的分支提前结束，把预算留给困难分支。工业界有不少团队把预算控制做成了参数化的，比如给每个子问题分配token预算的百分比，跑完一个分支就回收剩余预算。

2.3 来源多样性与信息覆盖度

搜索返回的结果通常存在“同质化”问题——翻来覆去都是同一批知名博客或新闻稿，小众却有价值的观点反而被淹没了。做深度研究时，信息覆盖度的评估指标可以这么设计：

• 来源多样性：检索结果来自多少个不同域名、多少类不同载体（论文、官方文档、代码库、社区讨论）。

• 角度覆盖度：对于争议性话题，正反两方的观点是否都出现了。比如对比框架A和B，不能只搜到A的拥护者写的内容，得有B的视角。

• 信源层级：优先度排序应该是学术论文/官方文档 > 权威机构报告 > 知名技术博客 > 个人博客 > 论坛讨论。

要实现这些，光靠通用搜索引擎不行。我在工程里加了一层“来源偏好路由”，如果子问题里出现了“论文”“benchmark”等词，优先走学术搜索接口；如果出现了“报错”“怎么用”，优先走开发者社区和官方文档。这个路由规则可以是硬编码的，也可以让模型判断。工业化第一版我建议硬编码，稳定可控。

2.4 检索失败怎么办：纠错与重试

真实检索中，大概率会遇到召回结果为空、搜索接口超时、或者返回的内容全是广告垃圾的情况。如果没有异常兜底，Agent会拿垃圾信息硬编一篇漂亮但错误的内容。我的设计原则是“检索失败必须显式反馈给生成模块”。

具体来说，每一步检索返回后，我会让模型打一个“检索质量分”（0到1），低于阈值的触发补救路径：换关键词重搜、换搜索源重试、或者改用外部知识库。如果多轮补救仍然失败，这个子问题会标记为“低置信度”，在最终报告里明确呈现为“该部分信息未能验证”，而不是让模型强行编造。这个机制看起来简单，但对报告可信度的提升效果是决定性的。

3. 证据核验：深度研究的“事实底线”

深度研究产品能不能被用户信任，很大程度上取决于证据核验做得好不好。传统的RAG产品只需要“引用来源”，但这远远不够。真正的证据核验，要求系统能回答三个问题：

• 这个信息来源是否可靠？
• 这个信息是否支持回答中的论断？
• 多个来源之间是相互印证，还是存在矛盾？

3.1 证据链的分级体系

我在项目中把证据分为三个层级，方便系统化区分：

• 一级证据：直接被引用片段支持，能精确到段落或图表。比如“根据论文xx第3节实验，Mamba在10k长度下推理速度比Transformer快1.8倍”，这就是一级证据。

• 二级证据：多个来源交叉印证同一个结论，但每个来源都只是间接支持。比如三篇博客都提到了某个模型的显存占用较低，但都没有给出精确数据，这就是二级证据。

• 三级证据：仅有单一来源，或者仅仅是大模型的内部知识。这种信息需要在报告中明确降级展示，避免用户误以为是经过多方验证的事实。

这个分级不是拍脑袋定的，我参考了学术综述里evidence grading的标准框架，结合RAG的特性做了简化。落地时，让模型在生成的每个关键论断后面附加一个证据等级标签，后处理阶段再根据标签决定展示样式。

3.2 交叉验证与矛盾检测

深度研究里最棘手的情况，是不同来源给出了矛盾的结论。比如论文A说某种训练方式能提升模型精度，论文B却说在更大规模实验下没有显著提升。这时候如果系统不做矛盾检测，报告就会呈现两种自相矛盾的说法，用户直接对产品失去信任。

我的做法是在汇总阶段加一个独立的“矛盾检查器”。它把各分支提炼出的结构化事实（用(s，p，o)三元组或自然语言短句表示）放在一起比对，判断是否存在互斥关系。如果检测到矛盾，不是强行选边站，而是生成一个“争议区”，把两方观点、各自支持来源、双方实验条件的差异都列出来，让用户自己判断。

这个模块一开始是用规则做的——关键词匹配+语义相似度，效果一般。后来改成让大模型专门扮演“审稿人”角色，效果好了很多。但要注意成本，这个模块只对“重要结论”运行，不跑全量。

3.3 引用的颗粒度：从“给了链接”到“精确到段落”

用户对引用的要求是越来越高的。最早给一个网页链接就行，后来需要定位到页面里的某个章节，现在最理想的状态是定位到某个段落或某张图表。

实现精确段落引用，核心在于“检索单元”的粒度切分。我对文档做预处理时，不是简单把整篇文档切成500字的小块，而是先用NLP做段落边界识别，再对小段落做拼接合并。这样检索返回的片段天然对应一个完整的论述单元，引用的时候可以直接说“见文档3.2节”或“见第4段”。

另外，引用必须伴随“生成端”的控制：模型在作答时，我强制要求它每个事实性句子都要标注来源ID。用结构化输出约束（JSON模式或语法约束解码）让它输出类似“截至2025年Q3，该模型在xxx榜单上排名第一。来源: [doc_id=12, section=3.2]”的形式。后期再做引用验证，检查这个doc_id是否真的包含该论断。这一步能过滤掉模型“幻觉参考”的问题——引用来源是真实存在的，但内容完全对不上，这在早期版本里大量出现。

3.4 “无据可说”时的策略

深度研究很难保证每个子问题都能找到完美证据。信息不足有两种情况：一种是证据太少，另一种是证据太散、不足以支撑强结论。

在工程上，我会给模型明确的指令——如果证据不足，允许输出“该问题当前公开资料中缺乏直接证据”，但禁止只丢这么一句话交差。正确的输出方式应该是：说明尝试了哪些检索方向、找到了哪些相关但非决定性的信息、这些信息指向什么可能的结论，并明确标注置信度。这样既保持诚实，又不让用户觉得产品什么都不会。

事实核查（Factuality Check）模块是这一整套机制的最后一环。报告生成完毕后，再跑一次“回溯核查”：对报告里的每一个关键论断，反向检索一遍，看是否有来源支持。这一步不怕慢，因为是异步后处理，不影响首屏返回。跑完之后，给报告打一个整体事实可信度分（0到100），低分的会退回上游重新生成。有的团队觉得这个环节多此一举，但实测下来，它能拦截掉大约10%到15%的严重事实错误，是RAG产品上信任感的基石。

4. 长程研究的稳态执行与效率边界

深度研究任务动辄要跑几分钟甚至更久，执行过程的稳定性和资源效率，是工业界落地的生死线。实验室里跑通一个脚本很容易，但要支撑一个日请求量上千的在线服务，完全是另一回事。

4.1 超长上下文的规划与管理

深度研究过程会产生大量中间结果，如果全部无脑塞进上下文，很快会超出上下文窗口。我踩过的坑是：让Agent自由累积信息，跑到第8个子任务时，上下文里全是前7个子任务的原始文档，模型开始“遗忘”最初的问题目标。

后来我引入了“状态摘要”机制——每完成一个子任务，不是把原始结果全部丢弃，也不是全部保留，而是压成三层：原始简要信息（关键数据点、来源ID）、结构化摘要（300字以内，保留核心结论和证据等级）、全局状态（已完成哪些子问题、剩余哪些子问题、当前主线结论）。新的子任务只需要感知“全局状态+相关分支摘要”，不需要重新读原始语料。这个设计大幅降低了token消耗，还提升了长时间任务的一致性。

4.2 步进式执行：每一轮都能被观测

长程Agent系统在生产环境最大的风险是“黑盒失控”——任务跑了一半，你不知道它在做什么，也不知道它还要跑多久。我的做法是引入步进式状态机，把任务生命周期划分为几个显式阶段：规划中、检索中、核验中、汇总中、复核中。

每个阶段都向外暴露结构化的事件日志（event log），包括当前阶段、已消耗token数、已搜索关键词、已返回来源列表。这样既方便给用户展示进度条（提升等待耐心），也方便自己排查问题。我还设了熔断机制：单次任务的检索次数上限、token消耗上限、时间上限。任何一个先触顶，任务自动进入“基于已有材料汇总”的降级模式，而不是无限跑下去。

4.3 效率边界：延迟、成本与精度的三角约束

如果说长程研究是一辆车，那延迟、成本、精度就是三个互相别扭的乘客。任何一方坐得更舒服了，另外一方就得憋屈。我实测下来，一组典型的参考数据是：

• 20个检索步的深度研究，串行执行大约需要4到6分钟，token消耗在200k到400k之间。

• 通过并行检索，能把延迟压到2分钟以内，但并发提升的同时，汇总阶段的上下文拼接会更拥挤，偶尔反而降低精度。

• 如果只追求精度，不做并行和压缩，成本最高可以再翻一倍。

在这个三角约束下，我一般建议的策略不是硬优化单一指标，而是按用户类型分级。C端用户走轻量模式，最多15个检索步，突出效率和成本控制；B端用户走深度模式，允许40到60步检索，产出的报告更详尽，成本也更高。本质上就是在产品层面做成不同的档位，而不是一套参数打天下。

4.4 长程任务漂移：从“跑偏”到“拉回来”

长程研究最常见的失败模式不是报错，而是“静默漂移”。任务开始还在研究原问题，跑到中后期，Agent渐渐被一些细节话题带走，最终报告成了某个子主题的深度专题，主问题反而没解答清楚。

防止漂移，除了前面说的全局状态摘要，还需要有“主线对齐”的机制。我每完成3个子任务，就调用一次轻量检查：当前报告骨架和原始用户query还是否一致？新增内容和主问题的相关性打分低不低？如果漂移超标，触发重规划：删掉偏离的分支，重新聚焦核心问题。这个重规划在必要时可以回滚到上一轮状态，保证长跑任务的稳定性。

5. 工业界落地实践中的评测与避坑

最后分享一些评评测和落地时非常容易被忽视的东西。深度研究这类Agent系统的评测，比传统RAG复杂得多，因为它跑一次要几十秒钟，想回归测试又费钱又费时。

5.1 Agentic RAG的评测指标设计

整套系统的评测，单看最终报告质量是不够的，因为出错的环节可能发生在检索、分解、核验或汇总任何一个模块。我把评测拆成三个层级：

• 流程质量：规划的子问题覆盖率（子问题和用户query的相关性）、检索尝试次数是否合理、是否发生了漂移。

• 组件质量：检索模块单独评测（召回率、来源多样性）、核验模块单独评测（矛盾检出率、引用无误率）。

• 结果质量：最终报告的完整性、事实正确率、引用命中率、可读性。

层级化评测的最大好处是出了问题能快速定位到环节，不用猜。我这边的做法是每个评测样本存一份meta日志，复盘的时候直接看子任务级的指标，比如某个子任务检索质量分只有0.3，那问题大概率在检索关键词设计，而不是在汇总策略。

5.2 人工评测与自动化评测的平衡

自动化评测没法完全替代人工判断。事实正确率可以用LLM-as-a-Judge粗筛，但“报告是否抓住了用户真正关心的重点”这种问题，模型很难拿捏。我不太建议一开始就追求全自动化，更好的方式是先跑一批人工标注的黄金测试集（golden set），问题类型覆盖对比型、调研型、数据查询型等，用这套数据集卡基线，之后每次改动都先跑一遍黄金集，再结合线上指标的回归情况判断改动是否有效。

5.3 常见问题速查：运行、观测与成本

我在排查线上问题时，积累了一张问题定位的速查表，很多问题一看现象就能猜个八九不离十：

这类问题如果等线上用户反馈，通常已经造成了比较严重的体验问题。我的经验是日志和观测体系要前置，每一步Agent决策都落一条可读日志，出问题能复盘到具体步数，而不是面对一个笼统的“任务失败”状态干瞪眼。

5.4 Agentic RAG的架构选型建议

最后聊几句架构选型的私人体会。现在LangGraph、LlamaIndex、CrewAI这些框架各有拥趸，但我不建议一上来就套一个特别重的框架。工业界我见过太多团队被框架抽象坑了，调试复杂、黑盒多、升级踩坑。

第一版如果团队规模小、目标明确，我建议用代码直接编排流程（Python + asyncio + 原生LLM接口），把每个环节显式写成函数，流程清晰、好调Bug。等流程稳定了，再评估要不要通过框架来承接多Agent扩展，那时选择会更有依据。框架是帮人管理和扩展复杂度的，不是用来给项目增加复杂度的。

这个系列后面我还会继续更新，重点可能会放到Agent的长期记忆设计、多Agent协作的通信协议、以及RAG系统在真实业务场景中的评测实践上。如果你也在落地类似系统，欢迎多交流。