1. 从检索即答案到检索即决策的认知转变过去两年我经手过不下二十个 RAG 相关的项目从最简单的文档切片向量检索拼 prompt三件套到后来涉及多跳推理、跨库联合查询的复杂系统。说实话早期那套朴素 RAG 在 demo 阶段确实惊艳但一旦进入真实业务场景问题就集中爆发了用户问上季度华东区退货率最高的三个品类分别是什么原因导致的系统检索回来一堆退货政策文档和几个不相干的品类介绍然后模型开始一本正经地胡说八道。这个现象背后其实是一个根本性的认知错位——我们把检索当成了答案但检索本质上只是证据收集的一个环节。真正成熟的 RAG 系统应该像一位经验丰富的分析师先理解问题到底在问什么再规划需要哪些信息、从哪里获取然后去收集证据最后还要判断证据是否充分、是否矛盾、是否需要补充检索。这套流程就是现在大家常说的Agentic RAG。这篇文章我想把从查询分析、任务规划到证据控制这条完整链路拆开来讲结合我实际踩过的坑把每个环节的核心技术点、实操要点和避坑经验都摊开说清楚。不管你是刚接触 RAG 的新手还是已经搭过几套系统但效果不理想的老手应该都能从中找到可以直接抄作业的部分。2. 查询分析别急着检索先搞清楚用户到底要什么2.1 为什么查询分析是 RAG 的第一道生死线很多人做 RAG 的第一步是直接把用户 query 丢进 embedding 模型做向量检索。这个做法在简单事实型问题上没问题比如公司年假多少天但一旦遇到下面这几类 query检索质量会断崖式下跌多意图复合查询帮我对比一下 A 产品和 B 产品的退货政策另外查一下上个月这两个产品的投诉率——这里面其实包含三个子任务。指代消解依赖它的保修期是多久——它指什么如果上一轮对话在聊某款具体型号那 query 本身缺少关键实体。隐含约束条件最近有没有什么适合新手的理财产品——最近是多久适合新手的判定标准是什么领域术语歧义苹果的市值——是水果公司还是科技公司在垂直领域里这种歧义更常见。查询分析要解决的就是这些问题。它的核心目标可以概括为三件事意图识别、查询改写、复杂度评估。2.2 意图识别与查询分类的实操方法意图识别不需要一上来就上大模型。我的经验是先用一个轻量级分类器做粗筛把 query 分成几大类再针对不同类别走不同处理路径。常见的分类维度包括查询类型特征处理策略事实型单一实体单一属性直接检索单轮即可比较型出现对比区别哪个好拆分为多个子查询分别检索聚合型所有列出统计需要结构化查询或多次检索汇总推理型为什么原因导致需要多跳检索证据链构建操作型怎么如何步骤优先检索流程类文档分类器可以用小模型微调也可以直接用 prompt 让大模型输出类别标签。我实测下来用 few-shot prompt 的方式在大多数场景下准确率能到 85% 以上成本比微调低得多。关键是分类体系要贴合你的业务场景不要照搬通用分类。2.3 查询改写把人话翻译成检索友好的表达查询改写的核心目的是弥合用户表达和文档表达之间的语义鸿沟。用户说东西坏了怎么退文档里写的是商品质量问题退货流程直接检索很可能匹配不上。我常用的改写策略有这么几种同义扩展把口语化表达替换成领域标准术语同时保留原词做 OR 检索。指代消解结合对话历史把它这个替换成具体实体。约束显式化把隐含的时间、范围、条件补全成明确过滤条件。子查询拆分复合查询拆成多个独立子查询分别检索后再融合。这里有个实操细节值得注意改写后的查询不要只用一个而是生成多个变体并行检索。我一般会生成 3-5 个改写版本包括原始 query、术语标准化版本、拆解后的子查询然后做多路召回。这样做的召回率比单查询高出一大截代价只是多几次向量检索性价比很高。注意查询改写不要过度。我见过有人把 query 改得面目全非结果检索回来的东西跟原问题完全不搭。改写的原则是保真优先扩展为辅原始 query 的检索结果永远要保留在候选集里。2.4 复杂度评估决定走快车道还是慢车道不是所有 query 都值得走完整的 Agentic 流程。一个公司地址在哪的问题走查询分析任务规划多轮检索纯属浪费。所以需要一个复杂度评估环节判断这个 query 需要几跳检索、是否需要工具调用、是否需要多轮交互。我的做法是用一个简单的打分机制从几个维度评估实体数量query 里涉及几个独立实体关系深度实体之间是单跳关系还是多跳关系约束条件数有多少个过滤条件需要满足是否需要外部工具比如计算、数据库查询、API 调用打分低的走快速通道直接检索生成打分高的进入完整 Agentic 流程。这个分流机制能显著降低平均响应延迟同时保证复杂问题的处理质量。3. 任务规划把一个大问题拆成一串可执行动作3.1 任务规划在 RAG 里到底规划什么任务规划这个词听起来很玄但落到 RAG 场景里其实很具体给定一个复杂查询决定需要执行哪些检索动作、以什么顺序执行、每个动作的目标是什么。举个实际例子。用户问我们公司去年在华东区的销售额是多少跟华南区比怎么样主要原因是什么这个问题至少需要检索华东区去年销售额数据检索华南区去年销售额数据计算两者差值检索可能的原因分析文档市场报告、区域策略等综合以上信息生成回答任务规划要做的就是把这个隐式的推理链显式化变成一串可执行、可验证的动作序列。3.2 三种主流规划范式及适用场景我在不同项目里用过三种规划方式各有优劣第一种是 ReAct 范式即 Reasoning Acting 交替进行。模型先思考下一步该做什么执行一个动作观察结果再思考下一步。这种方式灵活度高适合探索性强的场景但缺点是容易陷入循环而且每一步都依赖上一步的结果延迟较高。第二种是 Plan-and-Execute 范式先一次性生成完整计划再逐步执行。这种方式效率高计划可审查但缺点是如果执行过程中发现计划有误调整不够灵活。第三种是混合式先做粗粒度规划执行过程中根据中间结果动态调整后续步骤。这是我在生产环境里用得最多的方式兼顾了效率和灵活性。规划范式优势劣势适用场景ReAct灵活适应性强延迟高易循环探索型、开放域问题Plan-Execute高效可审查调整不灵活流程明确的结构化任务混合式兼顾效率与灵活实现复杂度高大多数生产场景3.3 规划器的 prompt 设计要点规划器的输出质量直接决定后续执行效果。我在 prompt 设计上踩过不少坑总结几个关键点第一动作空间要明确且有限。不要让模型自由发挥说去查一下相关资料而要定义清楚可用动作比如search_docs、query_database、call_api、calculate、summarize等。动作越明确执行越可控。第二要求输出结构化格式。我一般要求规划器输出 JSON 格式的动作序列每个动作包含动作类型、参数、预期目标。这样后续执行器可以直接解析不需要再做自然语言理解。第三加入依赖关系标注。有些动作可以并行执行有些必须串行。让规划器标注依赖关系执行器就能做并行优化。第四设置最大步数限制。不加限制的话模型可能会规划出十几步的流程实际根本没必要。我一般限制在 5-8 步以内超过就强制要求合并或简化。3.4 规划失败的典型模式与修复规划器不是万能的我遇到过几种典型失败模式过度拆分把简单问题拆成很多步每步检索一点点最后拼不起来。修复方法是加入最小必要步骤的约束。遗漏关键步骤比如比较型问题只规划了一边的检索。修复方法是加入检查清单要求规划器自检是否覆盖了所有子问题。动作选择错误该查数据库的去查了文档库。修复方法是把动作描述写得更具体并加入 few-shot 示例。循环规划A 依赖 BB 又依赖 A。修复方法是加入依赖环检测。实操心得规划器的输出一定要做校验不能直接信任。我一般会加一层规则校验检查动作类型是否合法、依赖是否有环、步数是否超限不通过就打回重规划。4. 证据控制RAG 系统里最被低估的环节4.1 什么是证据控制为什么它决定了回答质量证据控制这个词是我自己习惯的叫法指的是在检索到一批候选证据后对证据进行筛选、验证、补充、冲突消解的一系列操作。很多 RAG 系统检索完就直接把 top-k 文档拼进 prompt这是导致幻觉和错误回答的主要原因之一。证据控制要解决的核心问题包括相关性过滤检索回来的文档里有多少是真正相关的充分性判断现有证据够不够回答问题需不需要补充检索一致性检查不同证据之间有没有矛盾时效性验证证据是不是过时了权威性排序多个来源冲突时信谁这些问题不解决模型就是在垃圾堆里找答案。4.2 相关性过滤从 top-k 到 top-quality向量检索的 top-k 结果里真正相关的可能只有一半甚至更少。我常用的过滤策略是两阶段筛选第一阶段用轻量级交叉编码器cross-encoder做精排把 top-20 压缩到 top-5。交叉编码器比向量相似度准得多因为它能建模 query 和文档的交互关系代价是计算量大所以只用在精排阶段。第二阶段用大模型做相关性判断对每个候选文档输出相关/部分相关/不相关的标签。这一步成本更高但准确率也更高。我的经验是如果精排后 top-5 里还有明显不相关的说明检索环节有问题应该回头优化查询改写或索引结构而不是靠过滤硬扛。4.3 充分性判断什么时候该停下来什么时候该继续查这是 Agentic RAG 区别于朴素 RAG 的关键能力。系统需要判断现有证据是否足以支撑一个可靠的回答。我的实现方式是让模型做一个证据充分性评估输出三种状态充分证据完整可以直接生成回答部分充分有部分证据但缺少关键信息需要补充检索不充分证据严重不足需要重新规划检索策略评估的维度包括是否覆盖了所有子问题、关键数据是否齐全、是否有权威来源支撑。这个判断不需要百分百准确但能显著减少证据不足硬答的情况。4.4 冲突消解当证据打架时怎么办多源检索几乎必然会遇到证据冲突。比如两个文档对同一个政策的描述不一致或者数据来源不同导致数字对不上。我的处理原则是优先采信权威来源官方文档 内部知识库 第三方资料优先采信时效性新的除非明确是历史版本对比冲突无法消解时如实呈现在回答里说明关于这一点存在不同说法而不是强行选一个记录冲突供人工复核生产系统里我会把冲突案例记下来定期人工审查反过来优化知识库注意不要试图让模型自己判断哪个对。模型没有事实核查能力强行让它选边站只会增加幻觉风险。正确的做法是把冲突信息结构化呈现让用户或下游系统做决策。4.5 证据链构建让回答可追溯证据控制的最后一步是把筛选后的证据组织成一条清晰的证据链每个结论都能追溯到具体来源。这不仅是为了可解释性更是为了让用户能验证回答的可靠性。我的做法是在生成回答时要求模型对每个关键陈述标注引用来源格式类似[来源1]、[来源2]。然后在回答末尾附上来源列表包含文档标题、片段位置、相关度评分。这样用户看到回答后可以快速定位到原始文档核实。5. Agentic RAG 的完整落地从架构到代码5.1 整体架构设计把前面几个环节串起来一个完整的 Agentic RAG 系统大致包含这几个模块查询分析器意图识别、查询改写、复杂度评估任务规划器生成动作序列标注依赖关系执行引擎按计划执行检索、工具调用等动作证据控制器过滤、验证、补充、消解冲突生成器基于证据链生成最终回答反馈回路根据生成结果判断是否需要重新检索这个架构的核心思想是把 RAG 从一次检索变成一个闭环决策过程。每个环节都有明确的输入输出可以独立优化和替换。5.2 关键模块的代码实现要点查询分析模块的核心是一个分类改写的 pipeline。我用 Python 写过一个简化版核心逻辑大概是这样def analyze_query(query, historyNone): # 第一步意图分类 intent classify_intent(query) # 第二步指代消解如果有对话历史 if history and has_pronoun(query): query resolve_coreference(query, history) # 第三步查询改写生成多个变体 variants rewrite_query(query, intent) # 第四步复杂度评估 complexity assess_complexity(query, intent) return { original: query, intent: intent, variants: variants, complexity: complexity }任务规划模块的关键是 prompt 设计和输出校验PLANNER_PROMPT 你是一个检索规划器。给定用户问题生成一个动作序列。 可用动作 - search_docs(query, top_k): 检索文档库 - query_db(sql): 查询结构化数据库 - calculate(expression): 执行计算 - summarize(inputs): 汇总信息 输出 JSON 格式 { steps: [ {id: 1, action: search_docs, params: {...}, depends_on: []}, ... ] } 约束 - 步数不超过 6 步 - 依赖关系不能有环 - 每个步骤必须有明确目标 证据控制模块的核心是充分性判断和冲突检测。充分性判断我一般用一个独立的 prompt让模型输出结构化评估结果def check_sufficiency(query, evidence_list): prompt f 问题{query} 现有证据{format_evidence(evidence_list)} 请评估证据是否充分输出 - status: sufficient / partial / insufficient - missing: 缺少哪些关键信息 - next_action: 建议的下一步动作 return llm.invoke(prompt)5.3 性能优化的几个实操技巧Agentic RAG 的延迟是绕不开的问题。我总结几个有效的优化手段并行化执行规划器标注了依赖关系后无依赖的动作可以并行执行。我实测下来一个 5 步的计划如果有 3 步可以并行总延迟能降低 40% 左右。缓存复用相同或相似的子查询结果可以缓存。特别是多用户场景下很多查询有重叠部分缓存命中率能到 30% 以上。分级模型不是所有环节都需要用最大的模型。查询分类、相关性判断这些小任务用小模型就够了只有最终生成和复杂规划才用大模型。这样能显著降低成本。提前终止证据充分性判断通过后立即进入生成不要为了凑满 k 条而继续检索。5.4 评估体系怎么知道系统好不好没有评估就没有优化。我一般从三个层面评估 Agentic RAG评估层面指标测量方法检索层召回率、精确率、MRR标注测试集规划层计划成功率、平均步数人工审查自动校验生成层答案准确率、引用准确率、幻觉率人工评估自动评估其中引用准确率是我最看重的指标——回答里每个引用是否真的支撑了对应的陈述。这个指标能直接反映证据控制环节的质量。6. 常见问题与排查技巧实录6.1 检索召回率低怎么办这是最常见的问题。排查顺序我一般是先看查询改写有没有问题把改写后的 query 打出来人工看很多时候是改写跑偏了。再看切片策略切片太大导致语义稀释太小导致上下文丢失。我一般用 256-512 token 的切片加 10-20% 重叠。然后看 embedding 模型通用 embedding 在垂直领域效果可能很差考虑换领域微调过的模型。最后看索引结构是不是只做了向量索引加上关键词索引做混合检索召回率通常能提升 10-20%。6.2 规划器总是规划出无效步骤这个问题我遇到过好几次根本原因通常是动作空间定义不清晰或者缺少示例。修复方法把每个动作的描述写得更具体包括参数类型、返回值格式加入 3-5 个 few-shot 示例覆盖典型场景加入输出校验不合法的计划直接打回重规划如果还是不行考虑用微调代替 prompt6.3 证据冲突导致回答自相矛盾前面讲过冲突消解的原则但实操中还有一个技巧在生成阶段明确告知模型存在冲突。不要让模型自己去发现冲突而是在 prompt 里直接说明以下证据存在冲突请如实呈现不同说法。这样能显著降低模型强行统一口径导致的幻觉。6.4 系统延迟太高Agentic RAG 的延迟天然比朴素 RAG 高但可以通过这些手段控制复杂度评估分流简单问题走快速通道并行执行无依赖的动作缓存高频子查询结果分级使用模型小任务用小模型设置超时超时后降级到朴素 RAG6.5 常见问题速查表问题现象可能原因排查方向召回率低查询改写偏差/切片不当/索引单一检查改写结果调整切片加混合检索规划无效动作空间模糊/缺示例细化动作描述加 few-shot回答矛盾证据冲突未处理加入冲突检测生成时显式说明延迟过高串行执行/模型过大并行化分级模型加缓存幻觉严重证据不足硬答加强充分性判断证据不足时拒答最后分享一个我踩过的大坑早期我为了让系统看起来更智能让模型在证据不足时也强行生成回答。结果用户信任度暴跌因为错误回答比我不知道的伤害大得多。后来我加了一条硬规则——证据充分性评估不通过时系统必须明确告知用户信息不足并说明已尝试的检索路径。这个改动之后用户满意度反而上升了因为大家更信任一个知道自己边界的系统。这套 Agentic RAG 的架构我在几个项目里迭代过从最初的两三个模块到现在完整的闭环最大的体会是RAG 的瓶颈从来不在检索本身而在检索前后的决策环节。查询分析决定了检索方向对不对任务规划决定了检索路径优不优证据控制决定了最终答案可不可靠。把这三个环节做扎实比换更牛的 embedding 模型或者更大的生成模型效果提升要明显得多。
Agentic RAG实战：从查询分析到证据控制的完整链路
1. 从检索即答案到检索即决策的认知转变过去两年我经手过不下二十个 RAG 相关的项目从最简单的文档切片向量检索拼 prompt三件套到后来涉及多跳推理、跨库联合查询的复杂系统。说实话早期那套朴素 RAG 在 demo 阶段确实惊艳但一旦进入真实业务场景问题就集中爆发了用户问上季度华东区退货率最高的三个品类分别是什么原因导致的系统检索回来一堆退货政策文档和几个不相干的品类介绍然后模型开始一本正经地胡说八道。这个现象背后其实是一个根本性的认知错位——我们把检索当成了答案但检索本质上只是证据收集的一个环节。真正成熟的 RAG 系统应该像一位经验丰富的分析师先理解问题到底在问什么再规划需要哪些信息、从哪里获取然后去收集证据最后还要判断证据是否充分、是否矛盾、是否需要补充检索。这套流程就是现在大家常说的Agentic RAG。这篇文章我想把从查询分析、任务规划到证据控制这条完整链路拆开来讲结合我实际踩过的坑把每个环节的核心技术点、实操要点和避坑经验都摊开说清楚。不管你是刚接触 RAG 的新手还是已经搭过几套系统但效果不理想的老手应该都能从中找到可以直接抄作业的部分。2. 查询分析别急着检索先搞清楚用户到底要什么2.1 为什么查询分析是 RAG 的第一道生死线很多人做 RAG 的第一步是直接把用户 query 丢进 embedding 模型做向量检索。这个做法在简单事实型问题上没问题比如公司年假多少天但一旦遇到下面这几类 query检索质量会断崖式下跌多意图复合查询帮我对比一下 A 产品和 B 产品的退货政策另外查一下上个月这两个产品的投诉率——这里面其实包含三个子任务。指代消解依赖它的保修期是多久——它指什么如果上一轮对话在聊某款具体型号那 query 本身缺少关键实体。隐含约束条件最近有没有什么适合新手的理财产品——最近是多久适合新手的判定标准是什么领域术语歧义苹果的市值——是水果公司还是科技公司在垂直领域里这种歧义更常见。查询分析要解决的就是这些问题。它的核心目标可以概括为三件事意图识别、查询改写、复杂度评估。2.2 意图识别与查询分类的实操方法意图识别不需要一上来就上大模型。我的经验是先用一个轻量级分类器做粗筛把 query 分成几大类再针对不同类别走不同处理路径。常见的分类维度包括查询类型特征处理策略事实型单一实体单一属性直接检索单轮即可比较型出现对比区别哪个好拆分为多个子查询分别检索聚合型所有列出统计需要结构化查询或多次检索汇总推理型为什么原因导致需要多跳检索证据链构建操作型怎么如何步骤优先检索流程类文档分类器可以用小模型微调也可以直接用 prompt 让大模型输出类别标签。我实测下来用 few-shot prompt 的方式在大多数场景下准确率能到 85% 以上成本比微调低得多。关键是分类体系要贴合你的业务场景不要照搬通用分类。2.3 查询改写把人话翻译成检索友好的表达查询改写的核心目的是弥合用户表达和文档表达之间的语义鸿沟。用户说东西坏了怎么退文档里写的是商品质量问题退货流程直接检索很可能匹配不上。我常用的改写策略有这么几种同义扩展把口语化表达替换成领域标准术语同时保留原词做 OR 检索。指代消解结合对话历史把它这个替换成具体实体。约束显式化把隐含的时间、范围、条件补全成明确过滤条件。子查询拆分复合查询拆成多个独立子查询分别检索后再融合。这里有个实操细节值得注意改写后的查询不要只用一个而是生成多个变体并行检索。我一般会生成 3-5 个改写版本包括原始 query、术语标准化版本、拆解后的子查询然后做多路召回。这样做的召回率比单查询高出一大截代价只是多几次向量检索性价比很高。注意查询改写不要过度。我见过有人把 query 改得面目全非结果检索回来的东西跟原问题完全不搭。改写的原则是保真优先扩展为辅原始 query 的检索结果永远要保留在候选集里。2.4 复杂度评估决定走快车道还是慢车道不是所有 query 都值得走完整的 Agentic 流程。一个公司地址在哪的问题走查询分析任务规划多轮检索纯属浪费。所以需要一个复杂度评估环节判断这个 query 需要几跳检索、是否需要工具调用、是否需要多轮交互。我的做法是用一个简单的打分机制从几个维度评估实体数量query 里涉及几个独立实体关系深度实体之间是单跳关系还是多跳关系约束条件数有多少个过滤条件需要满足是否需要外部工具比如计算、数据库查询、API 调用打分低的走快速通道直接检索生成打分高的进入完整 Agentic 流程。这个分流机制能显著降低平均响应延迟同时保证复杂问题的处理质量。3. 任务规划把一个大问题拆成一串可执行动作3.1 任务规划在 RAG 里到底规划什么任务规划这个词听起来很玄但落到 RAG 场景里其实很具体给定一个复杂查询决定需要执行哪些检索动作、以什么顺序执行、每个动作的目标是什么。举个实际例子。用户问我们公司去年在华东区的销售额是多少跟华南区比怎么样主要原因是什么这个问题至少需要检索华东区去年销售额数据检索华南区去年销售额数据计算两者差值检索可能的原因分析文档市场报告、区域策略等综合以上信息生成回答任务规划要做的就是把这个隐式的推理链显式化变成一串可执行、可验证的动作序列。3.2 三种主流规划范式及适用场景我在不同项目里用过三种规划方式各有优劣第一种是 ReAct 范式即 Reasoning Acting 交替进行。模型先思考下一步该做什么执行一个动作观察结果再思考下一步。这种方式灵活度高适合探索性强的场景但缺点是容易陷入循环而且每一步都依赖上一步的结果延迟较高。第二种是 Plan-and-Execute 范式先一次性生成完整计划再逐步执行。这种方式效率高计划可审查但缺点是如果执行过程中发现计划有误调整不够灵活。第三种是混合式先做粗粒度规划执行过程中根据中间结果动态调整后续步骤。这是我在生产环境里用得最多的方式兼顾了效率和灵活性。规划范式优势劣势适用场景ReAct灵活适应性强延迟高易循环探索型、开放域问题Plan-Execute高效可审查调整不灵活流程明确的结构化任务混合式兼顾效率与灵活实现复杂度高大多数生产场景3.3 规划器的 prompt 设计要点规划器的输出质量直接决定后续执行效果。我在 prompt 设计上踩过不少坑总结几个关键点第一动作空间要明确且有限。不要让模型自由发挥说去查一下相关资料而要定义清楚可用动作比如search_docs、query_database、call_api、calculate、summarize等。动作越明确执行越可控。第二要求输出结构化格式。我一般要求规划器输出 JSON 格式的动作序列每个动作包含动作类型、参数、预期目标。这样后续执行器可以直接解析不需要再做自然语言理解。第三加入依赖关系标注。有些动作可以并行执行有些必须串行。让规划器标注依赖关系执行器就能做并行优化。第四设置最大步数限制。不加限制的话模型可能会规划出十几步的流程实际根本没必要。我一般限制在 5-8 步以内超过就强制要求合并或简化。3.4 规划失败的典型模式与修复规划器不是万能的我遇到过几种典型失败模式过度拆分把简单问题拆成很多步每步检索一点点最后拼不起来。修复方法是加入最小必要步骤的约束。遗漏关键步骤比如比较型问题只规划了一边的检索。修复方法是加入检查清单要求规划器自检是否覆盖了所有子问题。动作选择错误该查数据库的去查了文档库。修复方法是把动作描述写得更具体并加入 few-shot 示例。循环规划A 依赖 BB 又依赖 A。修复方法是加入依赖环检测。实操心得规划器的输出一定要做校验不能直接信任。我一般会加一层规则校验检查动作类型是否合法、依赖是否有环、步数是否超限不通过就打回重规划。4. 证据控制RAG 系统里最被低估的环节4.1 什么是证据控制为什么它决定了回答质量证据控制这个词是我自己习惯的叫法指的是在检索到一批候选证据后对证据进行筛选、验证、补充、冲突消解的一系列操作。很多 RAG 系统检索完就直接把 top-k 文档拼进 prompt这是导致幻觉和错误回答的主要原因之一。证据控制要解决的核心问题包括相关性过滤检索回来的文档里有多少是真正相关的充分性判断现有证据够不够回答问题需不需要补充检索一致性检查不同证据之间有没有矛盾时效性验证证据是不是过时了权威性排序多个来源冲突时信谁这些问题不解决模型就是在垃圾堆里找答案。4.2 相关性过滤从 top-k 到 top-quality向量检索的 top-k 结果里真正相关的可能只有一半甚至更少。我常用的过滤策略是两阶段筛选第一阶段用轻量级交叉编码器cross-encoder做精排把 top-20 压缩到 top-5。交叉编码器比向量相似度准得多因为它能建模 query 和文档的交互关系代价是计算量大所以只用在精排阶段。第二阶段用大模型做相关性判断对每个候选文档输出相关/部分相关/不相关的标签。这一步成本更高但准确率也更高。我的经验是如果精排后 top-5 里还有明显不相关的说明检索环节有问题应该回头优化查询改写或索引结构而不是靠过滤硬扛。4.3 充分性判断什么时候该停下来什么时候该继续查这是 Agentic RAG 区别于朴素 RAG 的关键能力。系统需要判断现有证据是否足以支撑一个可靠的回答。我的实现方式是让模型做一个证据充分性评估输出三种状态充分证据完整可以直接生成回答部分充分有部分证据但缺少关键信息需要补充检索不充分证据严重不足需要重新规划检索策略评估的维度包括是否覆盖了所有子问题、关键数据是否齐全、是否有权威来源支撑。这个判断不需要百分百准确但能显著减少证据不足硬答的情况。4.4 冲突消解当证据打架时怎么办多源检索几乎必然会遇到证据冲突。比如两个文档对同一个政策的描述不一致或者数据来源不同导致数字对不上。我的处理原则是优先采信权威来源官方文档 内部知识库 第三方资料优先采信时效性新的除非明确是历史版本对比冲突无法消解时如实呈现在回答里说明关于这一点存在不同说法而不是强行选一个记录冲突供人工复核生产系统里我会把冲突案例记下来定期人工审查反过来优化知识库注意不要试图让模型自己判断哪个对。模型没有事实核查能力强行让它选边站只会增加幻觉风险。正确的做法是把冲突信息结构化呈现让用户或下游系统做决策。4.5 证据链构建让回答可追溯证据控制的最后一步是把筛选后的证据组织成一条清晰的证据链每个结论都能追溯到具体来源。这不仅是为了可解释性更是为了让用户能验证回答的可靠性。我的做法是在生成回答时要求模型对每个关键陈述标注引用来源格式类似[来源1]、[来源2]。然后在回答末尾附上来源列表包含文档标题、片段位置、相关度评分。这样用户看到回答后可以快速定位到原始文档核实。5. Agentic RAG 的完整落地从架构到代码5.1 整体架构设计把前面几个环节串起来一个完整的 Agentic RAG 系统大致包含这几个模块查询分析器意图识别、查询改写、复杂度评估任务规划器生成动作序列标注依赖关系执行引擎按计划执行检索、工具调用等动作证据控制器过滤、验证、补充、消解冲突生成器基于证据链生成最终回答反馈回路根据生成结果判断是否需要重新检索这个架构的核心思想是把 RAG 从一次检索变成一个闭环决策过程。每个环节都有明确的输入输出可以独立优化和替换。5.2 关键模块的代码实现要点查询分析模块的核心是一个分类改写的 pipeline。我用 Python 写过一个简化版核心逻辑大概是这样def analyze_query(query, historyNone): # 第一步意图分类 intent classify_intent(query) # 第二步指代消解如果有对话历史 if history and has_pronoun(query): query resolve_coreference(query, history) # 第三步查询改写生成多个变体 variants rewrite_query(query, intent) # 第四步复杂度评估 complexity assess_complexity(query, intent) return { original: query, intent: intent, variants: variants, complexity: complexity }任务规划模块的关键是 prompt 设计和输出校验PLANNER_PROMPT 你是一个检索规划器。给定用户问题生成一个动作序列。 可用动作 - search_docs(query, top_k): 检索文档库 - query_db(sql): 查询结构化数据库 - calculate(expression): 执行计算 - summarize(inputs): 汇总信息 输出 JSON 格式 { steps: [ {id: 1, action: search_docs, params: {...}, depends_on: []}, ... ] } 约束 - 步数不超过 6 步 - 依赖关系不能有环 - 每个步骤必须有明确目标 证据控制模块的核心是充分性判断和冲突检测。充分性判断我一般用一个独立的 prompt让模型输出结构化评估结果def check_sufficiency(query, evidence_list): prompt f 问题{query} 现有证据{format_evidence(evidence_list)} 请评估证据是否充分输出 - status: sufficient / partial / insufficient - missing: 缺少哪些关键信息 - next_action: 建议的下一步动作 return llm.invoke(prompt)5.3 性能优化的几个实操技巧Agentic RAG 的延迟是绕不开的问题。我总结几个有效的优化手段并行化执行规划器标注了依赖关系后无依赖的动作可以并行执行。我实测下来一个 5 步的计划如果有 3 步可以并行总延迟能降低 40% 左右。缓存复用相同或相似的子查询结果可以缓存。特别是多用户场景下很多查询有重叠部分缓存命中率能到 30% 以上。分级模型不是所有环节都需要用最大的模型。查询分类、相关性判断这些小任务用小模型就够了只有最终生成和复杂规划才用大模型。这样能显著降低成本。提前终止证据充分性判断通过后立即进入生成不要为了凑满 k 条而继续检索。5.4 评估体系怎么知道系统好不好没有评估就没有优化。我一般从三个层面评估 Agentic RAG评估层面指标测量方法检索层召回率、精确率、MRR标注测试集规划层计划成功率、平均步数人工审查自动校验生成层答案准确率、引用准确率、幻觉率人工评估自动评估其中引用准确率是我最看重的指标——回答里每个引用是否真的支撑了对应的陈述。这个指标能直接反映证据控制环节的质量。6. 常见问题与排查技巧实录6.1 检索召回率低怎么办这是最常见的问题。排查顺序我一般是先看查询改写有没有问题把改写后的 query 打出来人工看很多时候是改写跑偏了。再看切片策略切片太大导致语义稀释太小导致上下文丢失。我一般用 256-512 token 的切片加 10-20% 重叠。然后看 embedding 模型通用 embedding 在垂直领域效果可能很差考虑换领域微调过的模型。最后看索引结构是不是只做了向量索引加上关键词索引做混合检索召回率通常能提升 10-20%。6.2 规划器总是规划出无效步骤这个问题我遇到过好几次根本原因通常是动作空间定义不清晰或者缺少示例。修复方法把每个动作的描述写得更具体包括参数类型、返回值格式加入 3-5 个 few-shot 示例覆盖典型场景加入输出校验不合法的计划直接打回重规划如果还是不行考虑用微调代替 prompt6.3 证据冲突导致回答自相矛盾前面讲过冲突消解的原则但实操中还有一个技巧在生成阶段明确告知模型存在冲突。不要让模型自己去发现冲突而是在 prompt 里直接说明以下证据存在冲突请如实呈现不同说法。这样能显著降低模型强行统一口径导致的幻觉。6.4 系统延迟太高Agentic RAG 的延迟天然比朴素 RAG 高但可以通过这些手段控制复杂度评估分流简单问题走快速通道并行执行无依赖的动作缓存高频子查询结果分级使用模型小任务用小模型设置超时超时后降级到朴素 RAG6.5 常见问题速查表问题现象可能原因排查方向召回率低查询改写偏差/切片不当/索引单一检查改写结果调整切片加混合检索规划无效动作空间模糊/缺示例细化动作描述加 few-shot回答矛盾证据冲突未处理加入冲突检测生成时显式说明延迟过高串行执行/模型过大并行化分级模型加缓存幻觉严重证据不足硬答加强充分性判断证据不足时拒答最后分享一个我踩过的大坑早期我为了让系统看起来更智能让模型在证据不足时也强行生成回答。结果用户信任度暴跌因为错误回答比我不知道的伤害大得多。后来我加了一条硬规则——证据充分性评估不通过时系统必须明确告知用户信息不足并说明已尝试的检索路径。这个改动之后用户满意度反而上升了因为大家更信任一个知道自己边界的系统。这套 Agentic RAG 的架构我在几个项目里迭代过从最初的两三个模块到现在完整的闭环最大的体会是RAG 的瓶颈从来不在检索本身而在检索前后的决策环节。查询分析决定了检索方向对不对任务规划决定了检索路径优不优证据控制决定了最终答案可不可靠。把这三个环节做扎实比换更牛的 embedding 模型或者更大的生成模型效果提升要明显得多。