1. 从检索增强到智能体驱动检索的认知转变很多人第一次接触 RAG脑子里浮现的画面是这样的用户问一个问题系统把问题转成向量去向量库里捞几段最相似的文本拼进提示词丢给大模型生成答案。这套流程在 2023 年几乎成了标配也确实解决了一部分模型不知道私有知识的问题。但真正把它放到生产环境里跑上几周你就会发现一个尴尬的事实固定流水线的 RAG本质上是一次性的、盲目的检索。为什么说它盲目因为传统 RAG 的检索动作是一次性的——它不会判断这个问题到底需不需要检索不会评估检索回来的内容质量够不够更不会在发现检索结果跑偏时换个关键词重新查一遍。它就像一个只会执行一次动作的机械臂你让它抓东西它就抓一次抓没抓到、抓得对不对它不管。Agentic RAG 要解决的正是这个问题。它的核心思路是把检索这个动作从固定流水线里拆出来交给一个具备决策能力的智能体去调度。这个智能体可以决定要不要检索、检索几次、用什么查询词、检索到的内容是否足够、不够的话下一步该干什么。换句话说检索不再是流程中的一个固定环节而是智能体工具箱里的一个可调用工具。这个转变听起来只是加了个判断但实际影响是结构性的。传统 RAG 的失败模式往往是检索没命中然后模型硬编而 Agentic RAG 的失败模式变成了智能体判断失误多绕了几圈。前者是静默失败后者至少是可观测、可干预的。对于做企业级应用的人来说可观测性往往比一次性成功率更重要。这篇文章我会从零讲清楚 Agentic RAG 到底是什么、和普通 RAG 的本质区别在哪、一个最小可用的智能体检索系统该怎么搭、里面有哪些坑是我自己踩过的。适合已经了解基础 RAG、想往智能体方向进阶的开发者也适合正在评估要不要上 Agentic RAG的技术负责人。2. Agentic RAG 到底智能在哪里四个决策点拆解要理解 Agentic RAG不能停留在它更聪明这种模糊描述上。我们得把智能拆成具体的决策点看看智能体在哪些环节做了传统 RAG 做不了的事。2.1 决策点一要不要检索传统 RAG 是无条件检索的。用户问你好它也去向量库捞一遍然后拼一堆无关内容给模型。这不仅浪费算力还会污染上下文让模型被无关信息干扰。Agentic RAG 的第一个决策就是路由判断这个问题需要查知识库吗还是模型自己就能回答还是需要调用别的工具比如计算器、数据库查询这个判断通常由一个轻量级的分类器或者大模型自己完成。我实测下来用大模型做路由判断的准确率明显高于小模型分类器但延迟会高一些需要根据场景权衡。2.2 决策点二用什么查询词检索这是最容易被低估的一环。用户的原话往往不适合直接拿去检索。比如用户问你们那个退货政策是几天来着直接拿这句话去向量检索命中率可能很低因为知识库里写的是自签收之日起 7 个自然日内可申请无理由退货。查询词和文档之间存在表述鸿沟。Agentic RAG 会让智能体先对用户问题做查询改写生成一个或多个更适合检索的查询。常见做法包括把口语化问题改写成书面表述、把一个问题拆成多个子问题分别检索、生成同义词扩展查询。我一般会让智能体生成 2 到 3 个不同角度的查询词然后并行检索后合并结果召回率提升非常明显。2.3 决策点三检索结果够不够传统 RAG 拿到 top-k 结果就直接用了不管这些结果相关不相关。Agentic RAG 会加一个相关性评估环节让模型判断检索回来的内容是否真的能回答问题。如果评估结果是不够就触发下一步动作——可能是换个查询词重试可能是扩大检索范围也可能是直接告诉用户知识库里没有相关信息。这个环节的价值在于避免模型硬编。我见过太多案例检索回来的是一堆不相关内容模型为了完成任务硬生生编出一个看似合理的答案。加了相关性评估之后这种情况能减少一大半。2.4 决策点四什么时候停止这是智能体系统里最微妙的问题。检索可以一直重试但你不能让它无限循环下去。Agentic RAG 需要设定停止条件达到最大检索轮次、相关性评分超过阈值、或者连续两轮检索结果没有改善都应该触发停止。我自己的经验是最大轮次设 3 轮比较合适。超过 3 轮还没找到相关内容大概率是知识库里真的没有继续重试只是浪费 token。这个数字不是拍脑袋定的是我在几个不同知识库上跑下来观察第几轮开始收益递减得出的经验值。把这四个决策点串起来一个完整的 Agentic RAG 流程大致是这样的接收问题 → 判断是否需要检索 → 改写查询词 → 执行检索 → 评估相关性 → 不够则调整重试 → 够了则生成答案。这个流程不是线性的而是一个带循环的图结构这也是为什么很多实现会用状态机或者图编排框架来做。3. 搭建最小可用 Agentic RAG 的完整路径理论讲完了接下来是实操。我会用一个企业知识库问答的场景从零搭一个最小可用的 Agentic RAG。技术栈选择上我倾向于用现成的编排框架而不是纯手写因为状态管理和循环控制手写起来很容易出 bug。3.1 技术选型为什么我最终选了图编排而不是链式编排早期我用链式编排Chain做过一版很快就遇到瓶颈。链式结构是单向的一旦走到下一步就没法回头而 Agentic RAG 的核心恰恰是回头重试。你当然可以用各种 hack 在链里塞循环但代码会变得非常难维护。图编排Graph天然支持循环和条件分支节点之间可以任意跳转状态在节点间传递。这跟 Agentic RAG 的检索-评估-重试循环结构是天然契合的。我现在的项目基本都用图编排来做智能体流程链式编排只用在那些确实没有分支的简单场景。具体到框架LangGraph 是目前比较成熟的选择它的状态管理和检查点机制对调试非常友好。如果你用 Java 技术栈Spring AI 也在往这个方向走虽然生态还不如 Python 那边丰富但企业级项目里用起来更顺手。3.2 状态设计整个系统的记忆该怎么组织图编排的核心是状态State。所有节点读写同一个状态对象状态设计得好不好直接决定了系统能不能跑通。我的状态对象一般包含这几个字段class RAGState(TypedDict): question: str # 原始问题 rewritten_queries: list # 改写后的查询词列表 retrieved_docs: list # 检索到的文档 relevance_score: float # 相关性评分 retry_count: int # 已重试次数 final_answer: str # 最终答案 need_retrieval: bool # 是否需要检索这里有个细节值得说retry_count 必须放在状态里不能放在节点内部。因为节点每次执行都是独立的如果计数器放在节点里每次重试都会重置循环就永远停不下来。我第一次写的时候就犯了这个错跑起来直接死循环排查了半天才发现是计数器位置放错了。3.3 节点实现路由、改写、检索、评估、生成整个图由五个核心节点组成我逐个说实现要点。路由节点负责判断是否需要检索。实现上就是给大模型一个提示词让它输出需要检索或不需要检索。提示词里要明确列出哪些类型的问题需要检索涉及具体事实、数据、政策的问题哪些不需要闲聊、通用常识、纯计算。这个节点的输出直接决定流程走向。改写节点把用户问题转成检索友好的查询词。我一般让它输出 JSON 格式的查询列表方便后续解析。提示词里会强调生成 2 到 3 个不同角度的查询覆盖问题的不同侧面。实测下来多查询并行检索的召回率比单查询高 30% 以上。检索节点执行实际的向量检索。这里有个工程细节多个查询词要并行检索然后做结果去重和合并。去重不能简单按文档 ID因为同一文档的不同片段可能都相关我一般按文档 ID 片段内容哈希去重保留相关性最高的那个。评估节点判断检索结果是否足够。让模型对每个检索结果打相关性分数0 到 1然后取最高分作为整体评分。如果最高分低于阈值我一般设 0.7就判定为不够触发重试。这里要注意评估的提示词要给出明确的评分标准否则模型打分很随意。生成节点基于检索结果生成最终答案。提示词里要强调只基于提供的资料回答资料里没有的信息不要编造。如果评估节点判定资料不足生成节点应该输出根据现有资料无法回答该问题而不是硬编。3.4 条件边控制循环的关键节点之间的跳转由条件边控制。路由节点之后根据 need_retrieval 决定走检索分支还是直接生成。评估节点之后根据 relevance_score 和 retry_count 决定是重试还是生成。重试的逻辑是这样的如果评分不够且 retry_count 小于 3就回到改写节点重新生成查询词如果评分够了或者已经重试 3 次就进入生成节点。这里有个优化点重试时可以让改写节点参考上一轮的失败原因生成不同的查询词避免重复检索同样的内容。def should_retry(state): if state[relevance_score] 0.7: return generate if state[retry_count] 3: return generate return rewrite这段逻辑看起来简单但阈值和轮次这两个参数需要根据你的知识库特点调。知识库内容密集、表述规范的阈值可以设高一点知识库内容零散、口语化的阈值要设低一点否则会一直重试。4. 实测中暴露的五个典型问题与应对上面讲的是理想流程但实际跑起来问题一个接一个。我把自己踩过的坑整理出来这些是文档里不会写、只有真正跑过才知道的东西。4.1 查询改写反而降低了召回率这是最反直觉的一个坑。我一开始以为改写一定比不改写好结果在某些场景下改写后的查询词反而偏离了原意召回率不升反降。原因出在改写提示词上。如果提示词让模型自由发挥它可能会加入很多原问题没有的假设导致查询词跑偏。比如用户问退款要多久模型改写成退款处理时效和到账时间说明看起来更专业但如果知识库里写的是退款周期反而匹配不上。我的应对方法是改写提示词里明确要求保持原问题的核心意图只做表述规范化不要添加原问题没有的信息。同时保留原始查询词一起检索把改写查询和原始查询的结果合并这样即使改写跑偏原始查询还能兜底。4.2 相关性评估的假高分问题评估节点用大模型打分会遇到一个经典问题模型倾向于给高分。你让它对检索结果打 0 到 1 的分它经常给 0.8、0.9哪怕内容其实不太相关。这个问题的根源是提示词设计。如果提示词只是笼统地说评估相关性模型没有明确的判断标准就会凭感觉打分。我的做法是给出具体的评分锚点0.9 到 1.0 表示直接回答了问题0.7 到 0.9 表示包含相关信息但需要推理0.5 到 0.7 表示部分相关0.5 以下表示不相关。有了具体锚点模型打分明显更靠谱。另一个技巧是让模型先给出判断理由再给分数。强制它先分析这段内容和问题的关系是什么再打分能有效抑制乱打分。这个技巧在多个评估任务上都验证过效果稳定。4.3 多轮重试的 token 成本失控Agentic RAG 比传统 RAG 贵这是必然的。每多一轮检索和评估就多几次大模型调用。我实测下来一个平均 2 轮检索的 Agentic RAGtoken 消耗大约是传统 RAG 的 3 到 4 倍。控制成本有几个手段。第一路由和评估用便宜的小模型只有最终的答案生成用大模型。这两个环节的判断任务相对简单小模型完全够用。第二设置合理的最大轮次我前面说的 3 轮是经验值你可以根据成本预算调整。第三缓存检索结果相同或相似的查询词直接命中缓存避免重复检索。还有一个容易被忽略的点评估节点不需要对每个检索结果都打分。如果检索回来 10 个片段你只需要评估相关性最高的前 3 个后面的本来就不太可能被用到。这样能省下不少 token。4.4 检索结果去重后反而丢了关键信息前面提到多查询并行检索后要去重。我一开始按文档 ID 去重结果发现有些关键信息丢了。原因是同一文档的不同片段可能都相关按文档 ID 去重会把它们合并成一个丢失了片段级别的信息。后来改成按文档 ID 片段内容哈希去重保留每个独立片段。但这样又带来新问题同一文档的多个片段可能内容高度重叠都塞进上下文会浪费 token。最终的方案是先按片段去重再按相关性排序只保留 top-k 个片段k 根据上下文窗口大小动态调整。4.5 智能体过度思考导致延迟过高Agentic RAG 的另一个代价是延迟。传统 RAG 一次检索一次生成可能 2 秒出结果Agentic RAG 走完路由、改写、检索、评估、重试、生成可能要 8 到 10 秒。对于交互式场景这个延迟是致命的。我的优化思路是分级响应先用传统 RAG 快速给一个初步答案同时后台跑 Agentic RAG 的完整流程等完整结果出来后再更新。这样用户感知到的首屏延迟还是 2 秒左右体验好很多。另一个手段是并行化。路由判断和查询改写其实可以并行做不用等路由结果出来再改写。检索多个查询词也是并行的。把这些能并行的环节并行起来整体延迟能压下来不少。5. 从能跑到好用几个值得投入的优化方向系统能跑通只是第一步真正拉开差距的是那些让它更好用的优化。这部分我分享几个投入产出比比较高的方向。5.1 给检索加上元数据过滤纯向量检索有个天然缺陷它只看语义相似度不看其他维度的约束。用户问2024 年的销售政策向量检索可能把 2023 年的政策也捞回来因为语义上太像了。解决办法是在检索时加上元数据过滤。给每个文档片段打上时间、部门、文档类型等元数据标签检索时先按元数据过滤再做向量相似度排序。这个改动不大但对准确率的提升非常明显尤其是在文档有时间维度或分类维度的场景下。元数据的提取可以在文档入库时用大模型自动完成也可以人工标注。我一般用大模型自动提取准确率能到 90% 以上剩下的人工抽检修正。5.2 混合检索向量加关键词向量检索擅长语义匹配但对精确的关键词匹配反而不如传统的关键词检索。比如用户问一个具体的产品型号X200-Pro向量检索可能匹配到一堆相似型号而关键词检索能精确命中。混合检索就是把向量检索和关键词检索比如 BM25的结果合并各取所长。实现上两路检索并行执行然后用倒数排名融合RRF算法合并结果。RRF 的好处是不需要调权重直接按排名融合工程上很省心。我实测下来混合检索在专业术语密集的场景下召回率比纯向量检索高 20% 到 30%。这个提升在技术文档、法律条文、医疗记录这类场景里尤其明显。5.3 把评估结果反馈给检索这是一个进阶优化。评估节点判断检索结果不够时不只是触发重试还可以把为什么不够的信息反馈给改写节点。比如评估发现检索结果缺少关于退款时效的具体天数改写节点就可以针对性地生成退款到账天数这样的查询词。这个反馈机制让重试变得有的放矢而不是盲目换词。实现上评估节点的输出除了分数还要包含一段缺失信息描述改写节点读取这段描述来调整查询方向。这个改动让我的系统在重试场景下的命中率提升了不少。5.4 可观测性把每一步都记下来Agentic RAG 的流程比传统 RAG 复杂得多出问题时如果不知道是哪一步出了问题排查会非常痛苦。所以可观测性必须从一开始就做不能等出了问题再补。我的做法是记录每一步的输入输出路由判断的结果和理由、改写生成的查询词、检索返回的文档 ID 和分数、评估的评分和理由、最终生成的答案。这些日志存下来出问题时可以完整回放整个流程。更进一步可以做一个简单的可视化界面把整个流程的每一步展示出来。调试的时候一眼就能看出是哪一步跑偏了。这个投入在项目初期看起来有点重但后期排查问题的效率提升是巨大的。6. 关于 Agentic RAG 的几个常见误解在跟同行交流的过程中我发现大家对 Agentic RAG 有一些普遍的误解这里澄清几个。误解一Agentic RAG 一定比传统 RAG 好。不一定。如果你的场景是简单的 FAQ 问答知识库内容规范、问题类型单一传统 RAG 完全够用上 Agentic RAG 只是徒增复杂度和成本。Agentic RAG 的价值在复杂场景——问题类型多样、需要多跳推理、知识库内容零散。选型要看场景不要为了先进而先进。误解二智能体越多越好。有人一听多智能体就觉得高级恨不得每个环节都搞一个独立智能体。实际上智能体之间的通信成本很高协调逻辑也很复杂。我建议从单智能体起步把检索、评估、生成都作为这个智能体的工具或节点等确实遇到瓶颈了再考虑拆分。多智能体不是目标解决问题才是。误解三上了 Agentic RAG 就不需要调提示词了。恰恰相反Agentic RAG 对提示词的要求更高。因为每个节点都依赖提示词来引导模型行为提示词写得好不好直接决定整个系统的表现。我在提示词上花的时间比写代码的时间还多。误解四评估节点可以省掉。有人觉得评估节点只是锦上添花为了省成本就砍掉。但评估节点是 Agentic RAG 区别于传统 RAG 的关键——没有它系统就失去了判断检索质量的能力退化成多轮盲目检索。省这个节点的成本换来的是准确率的大幅下降不划算。7. 我个人的一些实操体会最后分享几点纯个人经验不一定对所有人适用但都是我实际跑项目攒下来的。第一先用传统 RAG 跑通再逐步加智能体能力。不要一上来就搭完整的 Agentic RAG那样出问题时你根本不知道是哪一环的问题。我的做法是先搭一个最简的传统 RAG跑通之后逐个加上路由、改写、评估、重试每加一个就测一轮确认没问题再加下一个。这样每一步的收益和问题都清清楚楚。第二评估阈值和重试轮次一定要用真实数据调。我见过有人直接抄别人的配置结果在自己的知识库上表现很差。这两个参数跟知识库的特点强相关必须拿真实问题集跑一遍看准确率和成本的曲线找到平衡点。我一般会准备 50 到 100 个真实问题做测试集跑几轮不同配置对比效果。第三不要迷信全自动。Agentic RAG 再智能也会有判断失误的时候。对于关键场景我会加一个人工兜底机制当系统连续重试都找不到答案时转人工处理而不是硬编一个答案。这个机制看起来不够智能但在实际业务里它避免了很多因为错误答案导致的麻烦。第四关注 token 成本但不要因噎废食。Agentic RAG 确实贵但如果它能把准确率从 60% 提到 85%这个成本是值得的。关键是要算清楚账错误答案带来的损失和额外 token 的成本哪个更大。在大多数企业场景里前者远大于后者。第五保持对新技术的好奇但别急着上生产。Agentic RAG 这个方向还在快速演进新的框架、新的模式层出不穷。我的态度是积极尝试、谨慎上线。新东西先在测试环境跑验证有效果、稳定了再考虑上生产。追新不是目的解决问题才是。