1. 从检索增强到智能体编排这次到底变了什么如果你最近在关注大模型应用落地的技术演进大概率会频繁刷到Agentic RAG这个词。很多人第一次看到它会下意识觉得这不过是RAG加了个Agent的壳换汤不换药。但我实际动手搭过几套之后可以很负责任地说这个判断只对了一半。它确实是在RAG基础上叠加了智能体Agent的调度能力但真正带来的变化是把一次性检索变成了多轮自主决策的检索循环这个转变对系统架构、提示词设计、成本控制的影响是全方位的。先把概念说清楚。传统RAG的流程非常线性用户提问 → 向量检索Top-K文档 → 拼进上下文 → 模型生成答案。整个过程只有一次检索动作检索质量好不好全看那一次召回的运气。而Agentic RAG的核心思路是让模型自己决定要不要检索、检索什么、检索几次、结果够不够、要不要换个角度再查。模型从被动的信息消费者变成了主动的信息调度者。这篇内容适合谁看如果你已经写过基础的RAG Demo能跑通向量库大模型的基本链路但发现实际业务里效果总是不稳定——比如多跳问题答不对、模糊问题召回差、复杂查询漏信息——那这篇就是为你准备的。我会从架构拆解、核心组件、实操步骤、踩坑经验几个维度把Agentic RAG这套东西讲透尽量做到你照着就能复现。需要提前说明的是Agentic RAG目前没有唯一的标准实现不同团队的做法差异很大。我下面讲的是一套经过实际验证、相对通用且容易落地的方案涉及具体参数和工具选型时我会解释为什么这么选你可以根据自己的场景调整。2. Agentic RAG的架构骨架四个角色各司其职2.1 为什么不能只用一个大循环搞定刚接触这个方向时我最容易犯的错误就是写一个while循环让模型反复检索直到它说够了。听起来很简洁但实测下来问题一大堆——模型很容易陷入死循环或者检索两三次就草草收尾要么就是每次都召回一堆重复内容。根本原因在于一个模型同时承担判断、检索、评估、生成四件事认知负荷太重每件事都做不精。所以更靠谱的做法是拆角色。我目前用的架构里核心有四个组件各自职责单一、边界清晰查询规划器Query Planner负责把用户的原始问题拆解成一个或多个可检索的子查询并决定检索策略。检索执行器Retriever拿着子查询去向量库、关键词库或混合索引里捞内容返回候选文档。相关性评估器Relevance Grader对召回的文档打分判断是否真的和问题相关过滤掉噪声。答案合成器Answer Synthesizer基于筛选后的高质量上下文生成最终答案并标注引用来源。这四个角色可以由同一个大模型通过不同提示词扮演也可以用不同规模的模型分工比如评估用便宜的小模型合成用强模型。我倾向于后者因为评估这一步调用频率极高用大模型成本扛不住。2.2 一次完整请求的生命周期光说角色太抽象我拿一个真实场景走一遍。假设用户问我们上个季度上线的那个推荐系统和之前基于协同过滤的老版本相比在冷启动场景下效果提升了多少这个问题传统RAG基本答不好因为它需要跨多个文档、多个时间点去拼信息。Agentic RAG的处理链路是这样的第一步规划器把问题拆成三个子查询①推荐系统 上线时间 季度②推荐系统 协同过滤 对比 指标③冷启动 效果 提升 数据。注意这里规划器不是简单分词而是理解了问题的多跳结构。第二步检索执行器并行发起三次检索每次召回5-8篇候选文档。这里可以走混合检索——向量召回语义相近的BM25召回关键词精确匹配的两路结果合并去重。第三步评估器逐篇打分。比如某篇文档讲的是推荐系统整体架构和冷启动效果对比相关性只有0.3直接丢弃另一篇明确写了冷启动CTR提升12%相关性0.9保留。第四步合成器拿到3-5篇高相关文档生成答案并附上每句话的来源出处。整个链路下来可能调用了6-8次模型耗时比传统RAG长3-5倍但答案质量是质的飞跃。这就是为什么我说它不是加个壳——它把一次赌博式的检索变成了一个有反馈、可纠错的决策过程。2.3 和传统RAG的关键差异对照为了让你更直观地理解差异我整理了一张对照表维度传统RAGAgentic RAG检索次数固定1次动态1-N次查询构造用户原问题直接检索规划器拆解为多子查询结果过滤无或简单阈值评估器逐篇打分筛选失败处理召回差就答错可重新规划、换角度检索延迟低1-2秒高5-15秒成本低高3-10倍适用场景简单事实问答多跳推理、复杂分析这张表最关键的信息是最后两行Agentic RAG不是无脑升级而是用成本和延迟换质量。如果你的业务是简单的FAQ问答用户问营业时间是什么那传统RAG完全够用上Agentic纯属浪费。只有当问题复杂度高、对答案准确性要求严苛时这套架构才划算。3. 查询规划器整个系统里最容易被低估的一环3.1 规划质量直接决定检索上限我踩过最大的一个坑就是早期把精力全放在检索器和向量库调优上结果发现无论怎么调效果都卡在一个瓶颈。后来才意识到如果规划器拆出来的子查询本身就是错的后面检索再精准也是白搭。检索是执行规划是战略战略错了战术再强也没用。举个反面例子。用户问对比A方案和B方案在成本和性能上的取舍。如果规划器偷懒直接把这个原句丢给检索器向量库大概率会召回一堆同时提到A和B的文档但每篇都只讲了一部分拼起来信息是碎的。正确的做法是拆成四个子查询A的成本、A的性能、B的成本、B的性能分别检索后再交叉对比。3.2 规划器的提示词该怎么写规划器的提示词设计有几个要点我逐个说。第一明确输出格式。不要让模型自由发挥强制它输出结构化的子查询列表。我一般要求输出JSON数组每个元素包含query子查询文本和intent这个子查询想获取什么信息两个字段。结构化输出便于后续程序解析也逼着模型想清楚每个查询的目的。第二给出拆解示例。Few-shot示例对规划质量影响巨大。我会在提示词里放2-3个不同类型的拆解范例覆盖单跳、多跳、对比类问题。模型看到示例后拆解风格会明显更稳定。第三限制子查询数量。不设上限的话模型有时会拆出十几个查询成本爆炸。我一般限制在2-5个并在提示词里说明只拆解必要的维度避免冗余。一个我实际在用的规划器提示词骨架大致是这样你是一个查询规划专家。用户会提出一个复杂问题你需要把它拆解成2-5个独立的检索子查询。 拆解原则 1. 每个子查询应该聚焦一个具体的信息维度 2. 子查询之间尽量不重叠 3. 如果问题本身很简单可以只输出1个查询 4. 对于对比类问题分别针对每个对比对象拆解 输出格式严格JSON [ {query: 子查询文本, intent: 想获取的信息} ] 示例 用户问题X系统和Y系统哪个更适合高并发场景 输出 [ {query: X系统 高并发 性能指标, intent: X系统的并发能力}, {query: Y系统 高并发 性能指标, intent: Y系统的并发能力}, {query: X系统 Y系统 高并发 对比, intent: 两者的直接对比} ]这套提示词实测下来拆解准确率比不给示例高出不少。但要注意示例不能太多超过5个反而会让模型僵化遇到示例没覆盖的问题类型就懵了。3.3 什么时候该跳过规划不是所有问题都值得规划。如果用户问的是公司地址在哪这种单跳事实问题硬拆成多个子查询纯属浪费。所以我在规划器前面加了一个轻量的复杂度判断用一个便宜的小模型或者干脆用规则关键词先判断问题复杂度简单问题直接走传统RAG单次检索复杂问题才进Agentic流程。这个判断逻辑我一般这么设计问题里出现对比区别为什么如何哪些因素这类词或者包含多个实体、多个时间点就判定为复杂。规则虽然土但胜在快且可控比让模型判断更省钱。提示复杂度判断这一步千万别省。我见过有团队所有请求都走完整Agentic流程结果简单问题也要跑十几秒用户直接骂街。分流是刚需。4. 检索执行器与评估器把噪声挡在生成之前4.1 混合检索为什么比纯向量更稳向量检索擅长语义匹配但对精确的关键词、数字、专有名词不敏感。比如用户问2023年Q3的营收数据向量检索可能召回一堆讲营收的文档但年份季度对不上。这时候BM25这类关键词检索就派上用场了。我的做法是双路召回融合排序。向量路召回Top-10BM25路召回Top-10然后用RRFReciprocal Rank Fusion倒数排名融合算法合并。RRF的核心思想很简单一篇文档如果在两路里都排得靠前那它大概率真的相关。公式是给每篇文档算一个1/(krank)的分数再相加k一般取60。def rrf_fusion(vector_results, bm25_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(bm25_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)这段代码不复杂但效果提升很明显。实测下来混合检索的召回率比单走向量高出15%-25%尤其是涉及数字和专有名词的查询。4.2 评估器宁可错杀不可放过评估器的任务是对每篇召回文档打相关性分通常用0-1的连续值或相关/不相关的二分类。我的经验是评估标准要偏严格。因为把一篇不相关的文档放进上下文比少放一篇相关文档的危害大得多——前者会直接误导模型生成错误答案后者只是信息不全。评估器的提示词我一般这么写让模型判断这篇文档是否包含回答该问题所需的信息而不是这篇文档是否和问题主题相关。这两个标准差别很大。一篇讲推荐系统整体介绍的文档和问题主题相关但不包含冷启动提升数据这个具体信息按后一个标准就该被过滤。评估的粒度也有讲究。我试过文档级评估和段落级评估最后选了段落级。因为一篇长文档里可能只有一段是相关的整篇保留会引入大量噪声。段落级评估虽然调用次数多但上下文质量高得多。为了控制成本我会先用文档级粗筛再对通过的文档做段落级精筛。4.3 评估不通过时的补救策略评估器把所有文档都判为不相关这种情况一定会遇到。这时候不能直接告诉用户没找到那体验太差。我的处理策略是分层的第一层放宽阈值重试。把相关性阈值从0.7降到0.5再筛一遍看能不能捞回一些边缘相关的。第二层改写查询重试。让规划器基于当前查询没找到有效信息这个反馈换一种表述重新生成子查询。比如把冷启动效果提升改成新用户推荐准确率变化。第三层降级回答。如果重试两次还是不行就基于现有信息生成一个部分回答并明确告诉用户关于XX部分当前知识库中没有找到确切信息。诚实比胡编强一万倍。这个分层策略是我踩了无数坑之后总结的。早期我图省事评估不过就直接返回空结果用户投诉率很高。加上重试和降级之后有效回答率提升了将近30%。5. 答案合成与引用让每一句话都有据可查5.1 合成器的上下文组织方式合成器拿到的是一堆经过筛选的段落怎么组织进提示词直接影响生成质量。我试过几种方式最后固定用带编号的上下文块请基于以下资料回答问题。每处引用资料的地方用[数字]标注来源。 [1] 来源文档A第3段 推荐系统V2版本于2023年Q2上线采用双塔模型... [2] 来源文档B第1段 相比协同过滤双塔模型在冷启动场景下CTR提升约12%... 问题推荐系统V2相比老版本在冷启动场景下效果提升了多少这种编号方式有两个好处一是模型引用时不容易搞混来源二是方便后续做引用溯源。我要求模型在每句话末尾标注[1]这样的引用如果某句话没有引用支撑那它大概率是模型自己编的需要警惕。5.2 处理资料冲突的情况实际业务里经常遇到不同文档说法不一致的情况。比如文档A说提升12%文档B说提升15%。这时候合成器不能随便选一个而应该把冲突明确呈现出来根据文档A的数据提升约12%文档B则记录为15%两者存在差异可能源于统计口径不同。这种处理方式看起来不够干净但它是诚实的。我宁愿要一个承认不确定性的答案也不要一个自信满满但可能错误的答案。在提示词里我会明确要求如果资料之间存在矛盾请如实指出不要自行取舍。5.3 引用溯源的工程实现引用标注不能只是给用户看的装饰它应该是可点击、可验证的。我的做法是在合成器输出后用正则把[数字]提取出来映射回原始文档的ID和位置前端渲染成可点击的链接。用户点一下就能看到原文出处。这个功能对建立信任极其重要。尤其是企业内部的 knowledge base 场景用户看到答案能追溯到具体文档才会真正敢用。我做过一个小范围调研加了引用溯源之后用户对答案的信任度评分从3.2提升到4.55分制。6. 实操中踩过的坑与调优经验6.1 死循环Agentic RAG的头号杀手前面提过让模型自主决定检索次数最大的风险就是死循环。我遇到过模型检索了8次还在说信息不足需要继续检索的情况直接把请求拖到超时。解决方案是硬性限制软性引导双管齐下。硬性限制就是设一个最大迭代次数比如3次到了就强制进入合成阶段。软性引导是在提示词里明确告诉模型你最多有3次检索机会请合理规划。另外我还会记录每次检索的查询如果新查询和之前的查询相似度超过0.9就判定为重复检索直接跳过。6.2 成本失控评估器是烧钱大户评估器要对每篇文档每个段落打分调用次数是检索次数的好几倍。我算过一笔账一次完整Agentic请求评估器可能被调用20-30次。如果全用大模型成本根本扛不住。我的优化方案是分级评估。第一级用轻量模型比如7B级别做粗筛把明显不相关的快速过滤掉第二级才用强模型对剩下的做精细打分。实测下来成本能降60%以上而评估准确率只下降不到5%。这个取舍非常划算。6.3 延迟优化并行化能省一半时间Agentic RAG的延迟天然比传统RAG高但很多延迟是可以优化的。最大的优化点是并行化规划器拆出的多个子查询检索可以并行发起评估器对多篇文档的打分也可以并行。我用异步IO把这两步并行化之后端到端延迟从平均12秒降到了6秒左右。另一个优化点是流式输出。合成器生成答案时用流式返回用户能很快看到第一个字感知延迟大幅降低。虽然总时间没变但体验好很多。6.4 一个容易被忽略的细节文档切分粒度这个坑和Agentic本身关系不大但影响巨大。文档切分太粗检索精度差切分太细上下文碎片化。我试过256、512、1024三种token的切分粒度最后发现**512左右配合一定的重叠overlap 50-100 token**效果最均衡。重叠是为了避免关键信息正好被切在边界上。另外我强烈建议在切分时保留文档的层级结构信息比如这段属于哪个章节、哪个小节。检索时可以把章节标题也纳入向量化提升召回质量。这个细节很多教程不讲但实测有效。7. 什么场景该上Agentic RAG什么场景别碰聊了这么多技术细节最后回到一个更根本的问题你到底该不该用Agentic RAG我的判断标准很简单看三个维度。第一问题复杂度。如果用户的问题大多是单跳事实查询传统RAG足够别折腾。第二错误成本。如果答错一个问题的代价很高比如医疗、法律、金融场景那多花点成本换准确率是值得的。第三知识库规模与结构。知识库越大、越异构单次检索越难覆盖全Agentic的多轮检索优势越明显。反过来如果你的场景是高频简单问答、对延迟极度敏感、预算有限那Agentic RAG就是过度设计。我见过有团队为了技术先进硬上Agentic结果QPS掉了一半成本翻了三倍用户体验反而变差。技术选型要服务于业务不是反过来。从工程落地角度我的建议是渐进式演进先跑通传统RAG把检索质量、文档切分、提示词这些基础打牢等基础扎实了再逐步引入查询规划、结果评估这些Agentic组件。一步到位容易翻车因为出问题时你根本不知道是哪一层的问题。这套架构我前后迭代了大概两个月从最初的一个循环走天下到现在的四角色分工中间推翻重来了好几次。最大的体会是Agentic RAG的难点不在某个单点技术而在于如何让多个组件协同工作且不失控。规划器、检索器、评估器、合成器每个都要调每个都要设边界最后还要保证整体流程不跑偏。这活儿确实比传统RAG复杂但当你看到它能答对那些以前根本答不了的多跳问题时那种成就感也是实打实的。