Agentic RAG 这个词在过去一年里被提得越来越多但真正把它跑通、跑稳、跑出效率边界的人其实不多。我过去一段时间既读过不少论文也在实际项目里搭过几套面向深度研究场景的检索系统踩过的坑从检索召回率虚高到证据链断裂导致结论不可信都有。这篇总结想聊的不是概念科普而是把 Agentic RAG 拆成三个真正决定成败的环节检索策略怎么设计、证据核验怎么做、长程研究任务怎么控制效率边界。如果你正在做知识问答、行业研究、竞品分析、专利检索这类需要多跳推理多源取证的系统或者你已经在用 RAG 但发现单轮检索根本撑不住复杂问题那这篇内容应该能帮你少走一些弯路。1. 从单轮 RAG 到 Agentic RAG问题到底出在哪1.1 单轮检索的天花板比想象中低大多数人第一次接触 RAG做的都是用户提问→向量检索 top-k→拼进 prompt→生成答案这条链路。这个方案在事实型问答上表现还行比如某公司成立于哪一年这种问题一次检索基本能命中。但一旦问题变成对比 A 公司和 B 公司在过去三年专利布局上的差异并判断哪一家的技术路线更偏向边缘计算单轮检索就彻底不够用了。原因很直接这个问题需要多个子目标。你得先找到 A 公司的专利集合再找到 B 公司的专利集合然后按技术分类做筛选最后还要做对比推理。单轮检索只能给你一堆看起来相关的片段但这些片段可能只覆盖了 A 公司或者只覆盖了某个年份信息是残缺的。模型拿到残缺信息后要么硬编一个答案要么含糊其辞。这就是为什么很多 RAG 系统在 demo 阶段惊艳上线后用户却觉得答非所问。我在实际项目里做过一个统计对于需要两个以上信息源交叉的问题单轮 top-5 检索的完整覆盖率不到 40%。也就是说超过一半的复杂问题模型从一开始就没拿到完整材料。1.2 Agentic RAG 的本质是把检索变成决策过程Agentic RAG 和普通 RAG 的核心区别不在于用了多强的模型而在于检索本身变成了一个由 Agent 驱动的、带反馈的决策循环。普通 RAG 的检索是一次性动作Agentic RAG 的检索是多轮策略。具体来说Agent 需要做几件事第一把原始问题拆成可执行的子查询第二判断每个子查询该用什么检索方式语义检索、关键词检索、结构化过滤第三拿到结果后评估够不够不够就改写查询再来一轮第四把多轮结果做证据整合标注每条结论的来源。这四步里任何一步偷懒最终答案的可信度都会塌方。我习惯把 Agentic RAG 理解成一个研究助理而不是搜索引擎。搜索引擎给你链接研究助理给你结论并且告诉你结论是怎么来的。这个定位差异决定了系统设计的重心完全不同。1.3 为什么现在才火三个前置条件成熟了Agentic RAG 不是新概念但直到最近才真正可落地背后有三个条件同时成熟。一是模型的指令遵循和工具调用能力上来了Agent 能稳定地按格式输出我要检索什么而不是胡言乱语二是长上下文窗口让多轮检索结果的拼接成为可能以前塞不下三是检索基础设施变便宜了向量库、混合检索、重排序模型都有成熟的开源方案。但要注意条件成熟不等于没有边界。我见过太多团队一上来就堆 Agent 轮数结果延迟爆炸、成本失控用户体验反而更差。效率边界这个问题后面会专门用一章来讲。2. 检索策略设计混合检索、查询改写与多跳规划2.1 纯向量检索为什么在专业场景里不够用向量检索的强项是语义相似弱项是精确匹配。在通用问答里这不是大问题但在专业场景里是致命的。举个例子用户问eimt 2023 已被 ei 检索的会议有哪些这里eimt 2023和ei 检索都是强精确信号。向量检索可能给你返回一堆2023 年某会议被某数据库收录的泛化内容但就是漏掉那个具体的会议缩写。我在做专利检索相关系统时体会特别深。专利号、分类号、申请人名称这些字段用向量检索几乎必然翻车因为它们的语义信息很弱就是一个标识符。这时候必须上关键词检索或者结构化过滤。所以我的基本配置是混合检索向量检索负责语义召回BM25 或倒排索引负责精确召回两路结果用 RRFReciprocal Rank Fusion做融合。RRF 的好处是不需要调权重对两路分数的量纲不敏感实测下来比加权求和稳得多。# RRF 融合的简化实现 def rrf_fusion(vector_results, keyword_results, k60): scores {} for rank, doc in enumerate(vector_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) for rank, doc in enumerate(keyword_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)这个 k 值一般取 60是原论文的经验值我试过 40 到 80差异不大不用太纠结。2.2 查询改写把人话翻译成检索语言用户的问题往往不适合直接拿去检索。比如帮我看看最近那个很火的国产大模型在长文本上表现怎么样这里面最近很火那个都是模糊指代直接检索必然召回一堆噪声。Agent 的第一步应该是把这类问题改写成明确的检索查询比如2024 年国产大模型长文本能力评测对比。查询改写有几个常用套路。一是指代消解把那个它替换成具体实体二是时间归一化把最近变成具体时间范围三是术语标准化把口语词映射到领域术语比如图文检索要能映射到跨模态检索或image-text retrieval四是子查询拆分把复合问题拆成多个独立查询。这里有个经验改写不要一步到位追求完美而是够用就好边检索边修正。我早期试过让模型一次性生成完美查询结果模型为了完美过度改写反而丢了原始意图。后来改成先生成一个粗查询检索一轮后根据结果再决定要不要细化效果明显更好。2.3 多跳规划什么时候该跳什么时候该停多跳检索是 Agentic RAG 的核心能力但也是最容易失控的地方。所谓多跳就是第一轮检索的结果会作为第二轮检索的输入。比如先检索到某专利的申请人再用这个申请人去检索该申请人的其他专利。问题在于跳数不是越多越好。我见过一个系统设计了最多 5 跳结果很多简单问题也被强行跳了 5 轮延迟从 2 秒涨到 15 秒答案质量却没提升。后来我们加了一个停止判断每一轮检索后让模型评估当前证据是否足以回答问题如果够了就停。停止判断的 prompt 我一般这么写当前已收集的证据如下[证据列表]。原始问题是[问题]。请判断这些证据是否足以完整回答该问题如果足以回答输出 STOP如果不足以回答请说明还缺什么信息并生成下一轮检索查询。这个判断的准确率直接决定效率。实测下来加上停止判断后平均跳数从 3.2 降到 1.8而答案完整率基本没掉。2.4 重排序别让 top-k 里的噪声毁掉上下文混合检索召回的结果排序往往不够精细。这时候需要重排序模型reranker做二次精排。重排序模型通常是 cross-encoder 结构把 query 和 doc 拼在一起打分精度比向量相似度高不少但速度慢所以只适合对少量候选做精排。我的常规配置是混合检索召回 top-50重排序精排到 top-8再送进生成。这个 50 到 8 的比例是试出来的召回太少会漏精排太多会引入噪声。重排序模型我一般用开源的 bge-reranker 系列中文场景表现稳定。有个细节要注意重排序的分数阈值比 top-k 更重要。如果所有候选的分数都很低说明这一轮检索本身就没找到相关内容这时候应该触发查询改写重检而不是硬把低分结果塞进去。我一般设一个阈值低于阈值的直接丢弃宁可让 Agent 再检一轮。3. 证据核验让每条结论都能追溯到源头3.1 幻觉的根源不是模型爱编而是证据链断了很多人把幻觉归咎于模型爱编造但我在实际排查中发现大部分幻觉的根源是证据链断裂。模型拿到几个片段片段之间没有明确的逻辑连接模型为了把话说圆就自己补了一段。补的那段就是幻觉。所以证据核验的核心目标不是让模型别编而是让模型有完整的证据可依并且强制它标注每条结论对应哪条证据。只要证据链完整且可追溯幻觉会大幅下降。具体做法是在生成阶段要求模型对每个关键结论标注来源编号格式如根据[1][3]A 公司的专利集中在 XX 领域。如果某个结论找不到对应来源模型应该明确说这一点缺乏证据支持而不是硬答。3.2 交叉验证同一事实至少两个独立来源对于关键事实我要求至少两个独立来源交叉验证。这里的独立很重要如果两个来源其实是同一篇内容的转载那不算独立。判断独立性可以看域名、作者、发布时间等元信息。交叉验证在专利检索、行业研究这类场景里尤其重要。比如你要判断某技术路线是否是主流只看一篇分析文章不够得看多篇来自不同机构的报告是否指向同一结论。如果来源之间有冲突Agent 应该把冲突呈现出来而不是选一个自己觉得对的。我一般会在证据整合阶段加一个冲突检测步骤把所有证据按事实点聚类如果同一事实点下有相互矛盾的陈述就标记为存在争议在最终答案里明确提示用户。3.3 引用粒度段落级还是句子级引用粒度是个容易被忽略但很影响体验的细节。段落级引用实现简单但用户点进去还得自己找句子级引用精确但实现成本高而且容易因为分句错误导致引用错位。我的折中方案是段落级定位句子级高亮。存储时按段落切分并保留段落 ID生成时引用到段落同时在段落内用偏移量标出具体句子。这样用户点引用能直接跳到段落并且看到高亮的那句话。实现上需要在切分时记录每个句子的字符偏移稍微麻烦一点但体验提升明显。3.4 证据不足时的拒答设计一个成熟的 Agentic RAG 系统必须学会说我不知道。我见过太多系统明明没检索到相关内容还是硬生成一段看似合理的答案这是最伤用户信任的。拒答的判断逻辑我一般分三层第一层检索结果为空或全部低于阈值直接拒答第二层检索到了内容但重排序后最高分仍低于阈值提示找到一些相关内容但置信度较低第三层证据能覆盖问题的一部分但不完整回答已知部分并明确说明以下方面缺乏证据。这三层判断的阈值需要根据业务调。研究类场景可以宽松一点允许低置信度回答但必须标注事实核查类场景要严格宁可拒答也不能错。4. 长程研究多轮任务的状态管理与上下文控制4.1 长程研究的难点是记不住和记太杂长程研究任务比如分析某行业过去五年的技术演进并预测未来方向往往需要几十轮检索和推理。这时候两个问题会同时出现一是 Agent 记不住前面检索过什么导致重复检索二是上下文里塞了太多无关内容把关键信息淹没了。这两个问题本质上是同一个问题的两面状态管理没做好。我的做法是维护一个显式的研究状态而不是把所有东西都塞进上下文。研究状态包括已确认的事实、待验证的假设、已检索过的查询、待检索的查询、当前的结论草稿。每一轮只把当前需要的部分放进上下文其余的存在外部状态里。4.2 用研究大纲锚定方向防止跑偏长程任务最容易跑偏。Agent 检索着检索着就跑到一个无关的细分领域去了。防止跑偏的办法是先生成一个研究大纲把大问题拆成几个必须回答的子问题每轮检索都对照大纲检查我现在在回答哪个子问题。大纲不是一成不变的检索过程中如果发现新的重要方向可以动态加进去但要有明确的加入理由。我一般要求 Agent 在加新方向时说明这个方向为什么对回答主问题必要避免无意义发散。4.3 上下文压缩摘要、去重与关键信息提取长程任务的上下文管理核心是压缩。压缩有三个手段摘要、去重、关键信息提取。摘要是指把已完成的检索轮次压缩成简短结论而不是保留原始片段。比如第 3 轮检索确认了 A 公司在 2021 年申请了 15 项相关专利而不是保留那 15 项专利的原始文本。去重是指识别内容重复的片段。不同来源经常有大量重复内容尤其是新闻转载。我一般用 MinHash 或简单的文本相似度做去重相似度超过 0.9 的只保留一条。关键信息提取是指从长文档里只抽取与当前子问题相关的部分。一篇 5000 字的报告可能只有 200 字和当前问题相关那就只留这 200 字。这三个手段组合使用能把长程任务的上下文控制在可接受范围内。我实测过一个 30 轮的研究任务不做压缩上下文会涨到 20 万 token压缩后稳定在 3 万 token 左右。4.4 检查点与回滚长任务必须能存档长程任务跑到一半失败是常事可能是模型调用超时可能是某个检索源挂了。如果没有检查点机制整个任务就得重跑成本极高。我的做法是每完成一个子问题就存一次检查点记录当前的研究状态、已确认事实、结论草稿。如果后续失败可以从最近的检查点恢复而不是从头再来。这个机制在调试阶段尤其有用可以反复从某个中间状态试不同的后续策略。5. 效率边界延迟、成本与质量的三角权衡5.1 延迟的三个来源检索、推理、重排序Agentic RAG 的延迟主要来自三块检索向量检索关键词检索、推理模型生成查询和判断、重排序。我实测过一个中等规模系统单轮延迟大概是检索 200ms、推理 800ms、重排序 300ms加起来 1.3 秒。如果跑 3 轮就是 4 秒左右。用户对延迟的容忍度大概是2 秒以内感觉流畅2 到 5 秒可接受超过 5 秒开始烦躁超过 10 秒基本会放弃。所以 3 轮左右是个比较舒服的平衡点。如果业务要求更快就得在轮数和每轮开销上做取舍。5.2 成本控制不是所有查询都值得多轮多轮检索的成本是单轮的几倍。如果所有查询都走多轮成本会失控。我的做法是做查询分级简单事实型查询走单轮复杂推理型查询走多轮。分级的判断可以先用一个轻量分类器或者让模型在生成查询时顺便输出一个复杂度标签。分级之后我实测成本能降 40% 左右而复杂问题的质量不受影响。这个思路本质上是把资源花在刀刃上。5.3 质量与效率的帕累托前沿质量、延迟、成本三者不可能同时最优只能找帕累托前沿。我的经验是先定死延迟上限比如 5 秒在这个约束下最大化质量如果质量不达标再考虑放宽延迟或增加成本。具体调参时我一般按这个顺序优化先调检索召回数量影响召回率再调重排序阈值影响精度再调最大轮数影响完整性最后调模型大小影响推理质量。这个顺序是因为前面的调整对延迟影响小、对质量影响大性价比高。5.4 缓存与复用相同子问题不要重复检索长程任务里不同轮次经常会有重复的子查询。比如分析多家公司时都会查行业整体趋势这个查询结果可以复用。我一般会维护一个查询缓存key 是归一化后的查询value 是检索结果。命中缓存直接返回省一次检索。缓存要注意失效策略。如果数据源更新频繁缓存时间要短如果是相对静态的知识库可以缓存久一点。我一般设 1 小时到 1 天不等看数据更新频率。6. 实战中的几个具体坑与应对6.1 坑一向量库的相似但不相关向量检索经常返回语义相似但实际不相关的结果。比如查某专利的技术方案返回一堆专利撰写技巧的文章语义上确实相似但完全没用。应对办法是在检索时加入意图过滤。我一般会在查询里显式带上意图标签比如检索目标专利技术方案原文让检索更聚焦。另外重排序阶段可以加一个相关性判断的 prompt让模型判断候选是否真的回答了查询意图不相关的直接剔除。6.2 坑二多轮检索的查询漂移多轮检索时查询会一轮轮改写改着改着就偏离原始问题了。比如原始问题是某技术的成熟度改到第三轮变成了某技术的实现细节方向完全变了。应对办法是每轮改写后和原始问题做一次意图一致性检查。如果偏离超过阈值就回退到上一轮的查询重新改写。这个检查可以用简单的语义相似度也可以用模型判断。6.3 坑三证据冲突时的和稀泥当证据冲突时模型倾向于和稀泥说不同来源有不同说法就完事了。但用户要的是判断不是罗列。我的做法是要求模型在冲突时给出倾向性判断理由。比如虽然来源 A 和 B 说法不同但 A 的数据来源更权威、时间更新因此倾向于 A 的结论。这样既呈现了冲突又给了用户可操作的判断。6.4 坑四长任务的中途遗忘长任务跑到后面模型会忘记前面确认过的事实。这是上下文压缩的副作用——压得太狠关键信息丢了。应对办法是在压缩时保留一个核心事实清单这个清单不参与压缩始终放在上下文里。清单只记录最关键的已确认事实控制在几百 token 以内。这样模型始终能看到我已经确认了什么不会重复劳动。7. 我对 Agentic RAG 落地节奏的一点个人看法做了几套系统之后我最大的体会是Agentic RAG 的难点不在能不能做而在值不值得做。很多场景其实单轮 RAG 加一个好的重排序就够了硬上 Agent 反而增加复杂度和成本。判断标准很简单如果你的问题里超过 30% 需要多源交叉或多跳推理那 Agentic RAG 值得投入如果大部分是事实型问答先把单轮 RAG 做扎实。另外证据核验这块的投入回报比最高。我见过不少团队把精力全花在检索优化上结果答案还是不可信问题就出在证据链没做好。检索是找材料证据核验是把材料变成可信结论后者才是用户真正买单的部分。最后说个实操小技巧调试 Agentic RAG 时一定要把每一轮的查询、检索结果、判断理由都打日志。我早期调试时只看最终答案根本不知道哪一轮出了问题。后来把中间过程全打出来才发现很多问题出在查询改写那一步而不是检索本身。日志粒度建议细到每轮每步虽然吵但排查效率高得多。