1. 从传统 RAG 到 Agentic RAG为什么“检索一次”不够用了做检索增强生成RAG的同学大概都有过这种体验搭一个“向量库 相似度 Top-K 拼进 Prompt”的流水线跑 Demo 的时候效果惊艳一上真实业务就露馅。用户问一个稍微绕一点的问题比如“对比 A 方案和 B 方案在成本、交付周期上的差异并给出适用场景”传统 RAG 往往只召回几段语义相近的碎片模型拿着这些碎片硬编答案看着像那么回事细看全是漏洞。这就是 Agentic RAG 要解决的核心痛点。传统 RAG 的本质是一次性检索把用户 query 编码成向量去库里捞最相似的 K 条然后交给模型生成。它假设“最相似的文本就是最有用的证据”但这个假设在复杂任务里经常不成立。真实的研究型问题往往需要多跳推理、需要交叉验证、需要根据中间结果动态调整检索方向——这些都不是一次 Top-K 能搞定的。Agentic RAG 的思路是把“检索”从一个静态步骤升级成一个由 Agent 驱动的动态过程。Agent 会自己决定现在该不该检索、检索什么、用哪个工具检索、检索回来的东西够不够、不够的话下一步查什么。它把 RAG 从“检索-生成”的两段式管道变成了“规划-检索-核验-再检索-综合”的闭环。我个人的判断是这个转变的意义不亚于当年从规则系统到机器学习的跨越。因为它改变的不是某个环节的精度而是整个系统的问题解决范式。传统 RAG 是一个函数输入 query 输出 answerAgentic RAG 是一个过程输入目标输出经过验证的结论。1.1 传统 RAG 的三个硬伤先把传统 RAG 的问题说透才能理解 Agentic RAG 到底在补什么。第一召回与相关性脱节。向量相似度高不等于对回答有用。我做过一个专利检索的场景用户问“某类电池材料的制备工艺”向量库召回了一堆标题里带“电池”“材料”的综述文章但真正关键的几篇具体工艺专利因为措辞差异没被召回。相似度衡量的是语义距离不是证据价值。第二无法处理多跳问题。“A 公司的创始人是谁他后来创办的 B 公司主打什么产品”——这种问题需要先查 A 的创始人再拿这个人名去查 B。传统 RAG 一次性检索要么两段都召回但拼不到一起要么只召回其中一段。多跳推理是 Agentic RAG 最典型的用武之地。第三缺乏自我纠错。传统 RAG 检索完就生成模型没有机会说“这些证据不够我再查一次”。它只能基于给定上下文硬答答错了也没有反馈回路。Agentic RAG 引入了核验环节让系统能判断证据是否充分、是否矛盾然后决定下一步动作。1.2 Agentic RAG 的能力边界在哪里这里要泼一盆冷水。Agentic RAG 不是银弹它用更多的检索次数和更长的推理链换取了更高的准确率代价是延迟和成本。我在实际项目里测过一个需要 3-4 轮检索的研究型问题端到端耗时是传统 RAG 的 5-8 倍Token 消耗是 10 倍以上。所以效率边界是 Agentic RAG 落地时必须算清楚的一笔账。不是所有问题都值得上 Agent简单的事实查询用传统 RAG 又快又便宜。判断标准很简单如果一个问题需要人类研究员查三次以上资料才能回答那它才值得用 Agentic RAG。这个经验法则帮我省了很多过度设计的坑。2. 检索环节的深水区从向量召回走向混合与语义检索检索是 Agentic RAG 的地基地基不牢后面的核验和综合全是空中楼阁。这一块我想展开讲讲因为太多人把检索简单等同于“调个向量库 API”。2.1 混合检索为什么单一向量召回不够纯向量检索有个致命弱点它对精确匹配不敏感。用户搜一个具体的型号“XXL-JOB 日志检索”向量检索可能召回一堆讲“任务调度日志”的泛化文章但真正讲 XXL-JOB 这个具体框架的反而排在后面。因为向量把“XXL-JOB”这个专有名词的语义稀释了。解决办法是混合检索Hybrid Retrieval向量召回负责语义相似关键词召回BM25负责精确匹配两路结果融合排序。融合算法常用 RRFReciprocal Rank Fusion它对不同召回源的分数尺度不敏感只看得票排名工程上很稳。我实测下来混合检索在专有名词密集的场景专利、代码、产品文档比纯向量召回提升明显召回率能涨 15-25 个百分点。代价是要维护两套索引但这点成本相比效果提升完全值得。2.2 语义检索的进阶玩法查询改写与多查询用户的问题往往不是最优的检索 query。口语化的提问、省略的指代、模糊的表述都会让检索效果打折。Agentic RAG 里Agent 可以在检索前先做查询改写把“那个电池的工艺咋做的”改写成“锂电池正极材料制备工艺流程”再拿去检索。更进一步是多查询检索让模型针对一个问题生成 3-5 个不同角度的子查询分别检索后合并结果。这招对覆盖长尾证据特别有效。比如研究“某技术的效率边界”可以拆成“该技术性能指标”“该技术瓶颈”“该技术对比方案”三个子查询召回的证据面就宽多了。注意多查询会成倍增加检索开销建议限制在 3-5 个并且对子查询做去重否则容易召回大量重复内容浪费上下文窗口。2.3 检索粒度段落、句子还是整篇检索粒度是个容易被忽视但影响巨大的参数。整篇文档召回上下文完整但噪声大句子级召回精准但容易丢上下文段落级是折中也是我目前最推荐的默认粒度。在专利检索这类场景我甚至会用层级检索先召回相关专利再在专利内部定位到具体段落。这样既保证了文档级的相关性又提供了段落级的精准证据。实现上就是两阶段检索第一阶段粗排文档第二阶段细排段落。3. 证据核验让 Agent 学会说“我不确定”检索回来一堆文档直接丢给模型生成这是传统 RAG 的做法。Agentic RAG 多了一步核验。这一步是区分“看起来对”和“确实对”的关键。3.1 证据充分性判断Agent 需要判断当前召回的证据够不够回答这个问题这个判断可以交给模型做给它一个 prompt“基于以下证据能否完整回答用户问题如果不够还缺什么信息”模型会输出一个判断和缺口描述Agent 据此决定是否继续检索。我踩过的坑是模型倾向于说“够了”哪怕证据其实不充分。解决办法是强制模型列出证据与问题各要点的对应关系哪个要点没有证据支撑就标出来。这种结构化输出比让模型直接判断“够不够”可靠得多。3.2 交叉验证与矛盾检测研究型任务里不同来源的证据经常互相矛盾。Agentic RAG 的价值在于它能发现并处理矛盾而不是随机选一个信。做法是让 Agent 对关键结论做交叉验证同一个事实至少要有两个独立来源支撑才采信。如果来源冲突就标注出来要么继续检索找第三方证据要么在最终答案里明确说明存在分歧。这个机制在深度研究场景里特别重要因为研究报告的可信度就建立在证据的可靠性上。3.3 引用溯源每个结论都要有出处Agentic RAG 生成的答案每个关键结论都应该能追溯到具体证据。这不仅是可信度问题也是可审计性问题。实现上让模型在生成时标注引用编号然后做一次引用校验检查每个引用编号对应的证据是否真的支持该结论。我见过太多系统引用是“装饰性”的随便挂几个来源实际内容对不上。真正的引用溯源需要校验环节虽然增加成本但在专业场景法律、医疗、专利是刚需。4. 长程研究当 Agent 需要连续工作几十分钟长程研究是 Agentic RAG 最硬核的场景。用户给一个开放目标比如“调研某技术路线的产业化现状”Agent 需要自主规划、连续检索、逐步深入最后产出一份结构化报告。这个过程可能持续几十轮交互对系统的规划能力和状态管理是巨大考验。4.1 任务分解与规划长程研究的第一步是把大目标拆成可执行的子任务。Agent 需要生成一个研究计划先查什么、再查什么、每个子任务的目标是什么。这个计划不是一成不变的Agent 要根据中间结果动态调整。我的经验是计划要分层顶层是研究大纲3-5 个核心问题中层是每个问题的检索策略底层是具体查询。分层的好处是当某个子任务卡住时Agent 可以在中层调整策略而不必推翻整个计划。4.2 状态管理与上下文压缩长程研究最大的技术挑战是上下文爆炸。几十轮检索下来累积的证据可能几十万字远超模型上下文窗口。必须做上下文压缩把已消化的证据总结成要点只保留原始证据的引用需要时再回查。我常用的策略是滚动摘要每完成一个子任务就把该任务的证据和结论压缩成一段摘要原始证据存到外部存储。后续推理基于摘要进行需要细节时再按引用回查。这样上下文始终保持在可控范围。4.3 效率边界什么时候该停长程研究必须有终止条件否则 Agent 会无限检索下去。终止条件可以是证据充分性达标、达到最大轮次、边际收益递减新一轮检索没有带来新信息。边际收益递减是最实用的终止信号。我让 Agent 每轮检索后评估“本轮新增信息量”如果连续两轮新增信息低于阈值就停止检索进入综合阶段。这个机制能有效避免 Agent 在信息饱和后继续空转。5. 效率边界与工程取舍Agentic RAG 的成本账前面讲了这么多能力最后必须回到工程现实Agentic RAG 很贵。贵在延迟、贵在 Token、贵在系统复杂度。这一章专门算这笔账。5.1 延迟与成本的量化分析我做过一组对比测试同一个问题集传统 RAG 平均延迟 1.2 秒Agentic RAG 平均 8.5 秒Token 消耗传统 RAG 约 2KAgentic RAG 约 25K。这个差距在规模化后会非常可观。所以落地时必须做分级路由简单问题走传统 RAG复杂问题才走 Agentic RAG。路由判断可以用一个轻量分类器或者让模型先判断问题复杂度。这个设计能省下大量成本。5.2 缓存与复用策略Agentic RAG 的检索结果有很强的复用性。同一个子查询在不同研究任务里可能重复出现缓存检索结果能显著降本。我一般会做两级缓存查询级缓存相同 query 直接返回和证据级缓存相同文档片段不重复处理。5.3 模型选型不是越大越好Agentic RAG 里不同环节对模型能力要求不同。规划、核验这类需要强推理的环节用大模型查询改写、摘要压缩这类相对简单的环节可以用小模型。混合选型能在保证效果的同时把成本压下来。我实测过把摘要压缩换成小模型整体成本降了 30%效果几乎无损。6. 常见问题与排查技巧实录这一章是我踩坑踩出来的经验都是文档里不会写的。问题一Agent 陷入检索死循环。表现是反复检索相似内容不推进。原因通常是证据充分性判断失效Agent 总觉得“还差一点”。解决办法是设置硬性轮次上限并且每轮强制要求 Agent 说明“本轮检索与上轮的差异”没有差异就强制终止。问题二引用编号错乱。长上下文里模型经常把引用编号搞混。解决办法是每轮检索后重新编号并且在 prompt 里明确当前可用的引用范围。别指望模型记住几十轮前的编号。问题三核验环节过于严格导致无法收敛。有些场景证据本身就是有限的Agent 一直找不到“充分”证据。这时候要允许 Agent 在证据不足时输出“基于现有证据的初步结论”并标注不确定性而不是死等完美证据。问题四多查询召回大量重复。子查询角度没拉开召回内容高度重叠。解决办法是在生成子查询时强制要求角度互斥并且对召回结果做去重。问题典型表现排查方向解决手段检索死循环反复查相似内容充分性判断失效轮次上限 差异强制说明引用错乱编号对不上证据上下文过长每轮重编号 范围限定核验不收敛一直找不到充分证据阈值过严允许带不确定性的初步结论召回重复多查询结果重叠子查询角度未拉开角度互斥 结果去重7. 我在实际项目中的几点体会做 Agentic RAG 这一年多最大的体会是别一上来就追求全自动。我最早做的版本想让 Agent 完全自主结果各种失控。后来改成“人在关键节点确认”的半自动模式稳定性大幅提升。比如研究计划生成后让用户确认一下检索方向跑偏时让用户纠偏这些人工介入点反而让系统更可用。另一个体会是评估体系要先建。Agentic RAG 的链路长出问题很难定位。我后来建了一套分环节的评估检索召回率、核验准确率、引用正确率、最终答案质量每个环节单独测。这样出问题能快速定位到具体环节而不是笼统地说“效果不好”。最后分享一个实用技巧给 Agent 加一个“反思”步骤。在生成最终答案前让 Agent 自己审一遍结论有没有证据支撑、有没有遗漏重要信息、有没有逻辑跳跃。这个自审步骤成本不高但能拦下不少低级错误。我实测下来加了反思步骤后答案的事实性错误率降了差不多四成。