简介一份系统讲解Agentic RAG智能体检索增强生成的PPT适合大模型应用开发、RAG研究与技术决策者用于理解从传统RAG到智能体化演进的完整路径。内容围绕“提问—检索—判断—生成—反馈”的循环展开重点剖析借助反思标记Retrieve、IsRel、IsSup、IsUse动态决定是否检索以及通过检索器与重排器对齐、表征分解等方式缓解大模型幻觉问题。同时以詹姆斯NBA总冠军次数为案例对比单步与多步检索流程的区别并介绍自适应RAG、自我反思RAG、探针引导控制RAG等前沿改进方向。包体为1个pptx文件约14.93MB适合作为技术分享或内部培训材料。已有186人学习下载内容兼具概念框架与落地策略可帮助读者系统建立Agentic RAG的认知并指导实际问答系统设计。 直接说结论RAG 还没凉但它正在换一种更聪明的活法。过去大家聊 RAG默认是“检索 生成”一条直线走完现在你随便打开一份大模型项目的方案文档没出现 Agent 这个词反而奇怪。我最近在复盘一个企业知识库问答项目的过程中把 RAG 从“向量检索 Prompt 拼接”升级到了 Agentic RAG 的架构整个过程踩了不少坑也对所谓“智能体时代”有了更具体的体感。这篇博文就把我从 PPT 标题里拆出来的技术路线、架构设计、实测经验和避坑清单一次性讲清楚。我对这个主题的判断是Agentic RAG 不是 RAG 的替代品而是把 RAG 从“一个函数”变成了“一个系统”。传统 RAG 像自动售货机——投币、选货、出货Agentic RAG 更像一个便利店店员——你告诉他“我周末要招待一群不吃辣的朋友”他会先确认需求、再去货架比对、拿不定主意时还会回头问你。这套逻辑落到工程上不是加几个 Tool 那么简单而是要把规划、记忆、工具调用、自我纠错全部揉进检索生成链路里。1. 从传统 RAG 到 Agentic RAG到底“超越”了什么1.1 传统 RAG 的经典链路和隐藏天花板先回顾一下传统 RAG 的标准流程因为这决定了后面所有改进的基准把文档切片 → embedding 向量化 → 存入向量库用户提问时query 也转成向量在库里做相似度检索取回 Top-K 相关片段最后把这些片段连同原始问题一起拼进 Prompt 送给大模型生成答案。这套流程在“事实型单跳问答”上表现确实不错比如“公司年假制度是什么”“产品保修期多久”。但一旦问题升级它的问题就暴露得很明显。我常用三个案例来说明多跳问题用户问“我们去年在华东区销售额最高的产品它的退货率是多少”——需要先找到“销售额最高的产品”再拿这个结果去查“退货率”标准的 RAG 一次检索做不了这件事。指令型问题“帮我对比 A 和 B 两个套餐的差异并基于公司政策给出推荐”——这不是查一个片段就能回答的需要分别检索多个文档再做推理。信息缺失识别用户问的问题知识库里根本没有传统 RAG 也会硬凑一段看起来合理的回答因为生成阶段不会主动判断“我有没有足够的依据”。这三个案例指向同一个本质传统 RAG 是“一次成型”的没有中间过程也就没有中途纠错的机会。你既不知道检索结果是否真的覆盖了问题所需的全部信息也没法让模型在生成前做一轮“证据是否充分”的检查。这导致它在复杂场景下的精度和可控性都存在明显天花板。1.2 Agentic RAG 的三种典型模式业界对 Agentic RAG 的定义还在快速演化中我从实现的复杂度角度整理了三种常见的落地形态第一种Router路由模式一个 Agent 作为总入口先判断用户意图属于哪种类型——是闲聊、查知识库、查数据库还是需要多步推理——然后选择对应的处理流程。这是最轻量的形态本质是“分类 分治”。适合意图边界清晰、子任务类型固定的场景。第二种Tool-calling工具调用模式模型具备调用外部工具的能力比如不同的检索工具向量检索、SQL 查询、Web 搜索、API 请求根据问题需要自主决定调用哪些工具、按什么顺序调用、如何组合多次调用的结果。这种模式已经具备“多跳”能力。第三种Plan-and-Execute规划与执行模式进一步把“怎么回答问题”拆成“先规划步骤再逐步执行”Agent 先列出执行计划比如第 1 步查产品销量排名第 2 步按排名结果去查退货数据第 3 步综合判断给出建议然后按计划逐步调用工具并把每步结果带回到下一步的上下文里。这是当前综合效果最稳定、但也最难调的模式因为规划本身就可能出错。从我的实践经验看多数项目从第二种模式起步性价比最高。第一种模式适合预算有限、团队刚接触 Agent 概念的场景第三种模式建议在有足够评测样本之后再用否则规划失误的问题会被放大。1.3 为什么 Agentic RAG 更适合知识库问答我之所以坚定转向 Agentic RAG核心原因只有一个它能处理复杂问题而且失败时可解释性更强。传统 RAG 像黑盒你只知道“检索结果 模型输出”但不知道检索是否错了、模型是怎么用这些证据的。Agentic RAG 则有清晰的中间状态Agent 的每一步思考、每一步工具调用的输入输出都能被记录和追踪。做技术方案时这意味着你能定位到“是规划错了、检索错了、还是生成错了”而不是对着最终答案猜。另外Agentic RAG 的适用范围也明显更宽。知识库问答只是其中一种场景真正的价值在于把 RAG 能力封装成了 Agent 可调用的“工具”模型可以主动决定何时使用知识库、何时使用其他工具。这套模式彻底盘活了“RAG 知识库”在不同业务流程中的复用价值。2. Agentic RAG 核心模块与架构设计2.1 整体分层从“检索→生成”到“感知→规划→行动→反思”我在项目里最终确定的 Agentic RAG 架构分为四层感知层负责理解用户输入。除了基础的意图识别还包含实体抽取、问题改写、指代消解。比如用户问“它支持并发吗”“它”指代什么需要在这一层解决。规划层把复杂问题拆解为子任务决定调用哪些工具、按什么顺序调用。这里我会给 Agent 注入“检索策略知识”让它知道多跳问题应该如何拆解、什么时候需要回到用户确认。行动层执行具体的工具调用。这里包含多种 RAG 检索策略——向量检索、关键词检索、SQL 查询、图数据库查询等——以及各类工具 API 的封装。反思层对模型的输出做质量检查。最常用的是“引用召回检查”生成答案里的每一个关键事实都要能从检索到的片段中找到对应来源找不到就触发重新检索或回答“信息不足”。这四层对应到工程实现上就是一套可控的 Agent 循环Agent 在规划和行动之间循环直到它“觉得”信息足够了才进入最终生成阶段然后由反思层做质量校验。2.2 工具设计检索工具的四种打开方式Agentic RAG 和传统 RAG 最大的区别之一是它身边挂着一排工具。基于 LangChain 和 Dify 的实践经验我把工具分成四类Dense Vector Search稠密向量检索处理语义模糊、同义改写的问题。比如“怎么请假”和“休假申请流程”之间的语义匹配向量检索有明显优势。关键词/全文检索稀疏检索处理专有名词、产品型号、编号类查询。比如查“ABC-2000 型设备参数”关键词匹配通常比向量检索更精确。SQL / 结构化查询工具处理“上个月销量排名前五的产品”这类需要聚合统计的问题。这类问题靠文档检索解决不了必须查数据库。Web/API 工具处理需要实时信息的查询比如价格变动、物流状态。设计工具接口时需要注意一个细节工具的“描述”比工具本身更重要。大模型决定调用哪个工具主要看工具的描述是否和当前任务匹配。所以写工具描述时不要写“查询数据库”要写“查询销售数据库适用于按时间、地区、产品维度获取销量、退货率等指标”。2.3 和 Graph RAG 的取舍两个方案怎么选现在很多技术方案里Graph RAG 和 Agentic RAG 经常一起出现。我个人的理解是Graph RAG 解决的是“实体关系密集型”的检索问题Agentic RAG 解决的是“流程可编排型”的推理和执行问题两者不是竞争关系而是可以互补的。比如检索策略里可以配置一个 Graph RAG 工具当 Agent 判断问题需要多跳实体关系推理时就调用这个工具。我实际测下来在“组织结构问答”“产品关联推荐”这类任务上Graph RAG 检索的准确率明显高于纯向量检索但构建知识图谱的工程成本也确实高一般项目量级不建议一开始就上可以在框架层面预留扩展位。3. 实操过程基于 Dify 和向量库搭建第一版 Agentic RAG3.1 我使用的技术栈和选型理由Agent 编排框架Dify社区版。理由可视化工作流对调试 Agent 循环帮助巨大内置工具调用和数据集管理适合快速验证。向量数据库Qdrant。理由支持过滤索引对复杂 metadata 查询性能好Docker 部署一条命令就能跑起来。Embedding 模型本地的 bge-m3。理由中文效果稳定支持 8192 长度对长文档切片的检索质量有保障。数据安全要求不高的场景可以换用 OpenAI 或国内云厂商的 embedding API。LLM优先用支持 function calling 的模型比如 Qwen、GLM 系列因为 Agent 循环对“按格式输出工具调用参数”的能力要求很高。注意Agentic RAG 对 LLM 的 function calling 能力有硬性要求。如果底模不支持工具调用再好的框架也跑不起来。实测中小参数模型7B 级别在工具调度准确率上确实不如大模型试过就明白差距在哪。3.2 完整落地步骤含关键配置第一步准备数据并做清洗与切分我做的企业知识库包含规章制度、产品手册、运维文档等混合类型。切分参数用的是“分层切分”策略固定 chunk_size 设为 512 tokenoverlap 设为 64 token同时在标题层级上做了保留。这里有一个很重要的经验切片前先做“逻辑块”切分再做 token 级切分。比如一份合同文档先按条款拆成逻辑块每个块内再按 token 限制切分这样同一条款的内容不会被打散到多个 chunk 里。纯靠固定长度切分检索时会大量命中不完整的上下文召回质量明显变差。第二步搭建 Dify 工作流Dify 里我选择了 Chatflow 类型而不是简单的 Agent 节点串联。核心节点配置如下意图识别节点用 LLM 节点做分类输出 JSON 格式{intent: knowledge_qa/chitchat/db_query, rewritten_query: 改写后的问题}Agent 节点工具调用把 Qdrant 检索、SQL 查询封装成工具模型根据意图判断是否调用、调用哪些。多轮检索循环Dify 的 Agent 节点支持最多迭代次数配置我设置为 5 次。这个值不能设太大否则生成时延和 token 成本都会快速上升。反思校验节点用 LLM 检查“每个关键信息是否有来源片段支持”没有则打回重查。它不会直接否掉整个答案而是标识出哪些句子缺少依据触发补充检索。第三步配置检索策略Dify 中检索模式我选的“混合检索”向量 关键词Rerank 模型用的 bge-reranker-base。召回 Top-K 设置为 10Rerank 之后取前 5 个片段进上下文。3.3 参数计算和成本评估这里给出一个具体估算案例假设知识库有 10 万份文档平均每份 5000 token全部切分成 512 token 的 chunk大约产生 1000 万块数据。Embedding 成本按当前主流 API 价格估算整体向量化费用会是一笔不小的开销如果换成开源的 bge-m3 本地部署成本可以压缩到 GPU 电费和硬件折旧以内。Agentic RAG 和传统 RAG 的 token 成本差异也要心里有数同一问题传统 RAG 可能消耗 1500 tokenAgentic RAG 因为多轮调用和中间推理可能消耗 4000-6000 token。这是智能体架构的默认代价只能通过控制迭代次数和压缩中间输出来优化。3.4 一个核心查询的跑通全过程用实际案例走一遍流程。用户提问“基于去年的销售数据我们退货率最高的产品类别是哪个主要原因可能是什么”感知层输出intentdb_query knowledge_qa 混合类型rewritten_query 保持原问题不变。Agent 第一次迭代调用 SQL 工具从销售数据库按“退货率”倒序查产品类别排名得到结果“家居生活类退货率 18.7%”。Agent 第二次迭代带着“家居生活类”这个新上下文调用向量检索工具查找文档中关于该类别退货原因的分析返回若干片段。反思层校验检查生成答案中的两个核心事实——退货率 18.7% 和原因分析——是否都有来源。SQL 结果是结构化证据文档片段是文本证据校验通过。最终输出一段包含数据引用和原因分析的完整回答。整个过程 G 端演示时非常流畅因为用户能看到 Agent 在“做什么”而不是直接甩一个答案——这也是 Agentic RAG 在展示环节比传统 RAG 更有说服力的原因。4. 测评方案设计RAG 指标怎么选测试集怎么做4.1 传统 RAG 指标和 Agentic RAG 的差异传统 RAG 的自动化评测体系已经比较成熟核心指标包括答案忠实度faithfulness、答案相关度answer relevancy、上下文精度context precision、上下文召回context recall。这四个指标在 RAGAS 框架中都有对应实现。到了 Agentic RAG 阶段指标仍然沿用这套框架但多了一个更重要的维度工具调用正确率和规划成功率。也就是说不仅要看最终答案好不好还要看过程对不对。所以我会额外统计意图识别准确率、工具选对率、多跳规划成功率、平均迭代轮数。过程指标和结果指标配合使用才能定位问题出在规划层还是生成层。4.2 测试数据集怎么设计评测数据不要只用自己写的“标准问答对”要配合文档体系分层设计。我给项目设计了三类测试数据单跳事实类占比 40%答案在单个文档片段中能找到。用于验证检索基础链路是否正常。多跳推理类占比 40%答案需要综合多个文档片段或先查数据库再查文档。这是验证 Agentic RAG 价值的核心样本。无答案类占比 20%问题和知识库不相关或信息不充分。用于验证模型的“拒答”能力——这一点传统 RAG 表现普遍较差而 Agentic RAG 应当做得更好。每条测试样本需要标注标准答案、答案来源片段 ID、预期工具调用链路可选。测试集规模建议至少 100 条起步每次调优后跑全量人工抽检 10% 确认自动化指标的可靠性。4.3 我的评估执行流程自动化评测用 RAGAS 跑两个阶段第一阶段只评估生成质量faithfulness/answer relevancy 等如果指标正常问题大概率在检索和规划第二阶段额外评估工具调用正确率如果指标偏低就针对性调整 Agent 提示词和工具描述。人工评估阶段通常每轮抽 20 条案例重点看多跳问题的答案是否真的按正确逻辑组装。注意RAGAS 评测本身会消耗 token100 条样本跑一轮大约需要 5 万 token 的调用量真实评估环境下这个开销要提前预算进去。别等上线前突然发现评测费比训练费还离谱。5. 常见问题与排障实录表格列一下我实际遇到的频率最高的几个问题都是花了真金白银换来的经验问题表象根因分析解决措施多跳问题回答一半就停Agent 在规划时只规划了一步缺少后续步骤在规划提示中强制输出“步骤列表”调大最大迭代次数工具描述写得太笼统模型不调用检索工具模型无法判断“什么时候该查库”在工具描述里补上使用场景和典型问题类型检索结果 Top-5 全是不相关内容切片粒度太粗一个 chunk 混入多个主题改为“语义块切分”同一段落保持完整检索结果准确但答案编造了来源外的内容反思层没有生效在反思提示中强制要求“逐句验证每个事实是否有引用片段对应”每次都让用户补充信息答非所问意图识别把知识问答误判成需要澄清的问题意图识别 Prompt 中增加澄清触发条件知识库问题默认先检索再确认Agent 进入无限循环中间步骤结果格式不合预期模型反复重试给所有工具调用结果增加 schema 校验非法结果直接返回错误信息终止本轮排障最笨但最有用的方法是打开 Dify 工作流的“步骤追踪”面板把每次调用的输入输出完整跑一遍。Agentic RAG 的可观测性比传统 RAG 好得多绝大多数问题只要把日志从感知层到反思层逐层看一遍就能定位到根因。还有两个细节值得单独提醒Embedding 模型要和 Rerank 模型搭配调优。bge-m3 的向量空间和 bge-reranker 是配套的混用其他家的 rerank 模型分数分布可能不一致阈值要重新调。Dify 的 Agent 节点不要直接嵌进业务代码里调用。它的优势在于可视化和调试生产环境建议通过 API 暴露或在代码层用 LangGraph 重写一个精简版循环性能和可控性都会有明显提升。6. 工具与框架选型参考整理几张对比方便快速决策Agent 编排框架对比框架优势适合场景Dify可视化工作流、内置 RAG 链路快速验证、业务人员参与调试LangChain/LangGraph灵活度高、生态全深度定制、生产落地的代码开发Coze上手最快、工具插件丰富轻量应用和演示自研完全可控对安全、性能要求极高的核心业务向量数据库对比数据库特点注意点Qdrant支持 payload 过滤性能稳定需要独立部署资源占用中等Milvus分布式能力强支持超大规模部署运维复杂度偏高Elasticsearch自带全文检索混合检索方便向量性能不如专用库pgvector和 PostgreSQL 天然集成适合已有 PG 体系的团队但超大 Collection 性能是瓶颈对于第一次尝试 Agentic RAG 的团队我建议直接选 Dify Qdrant 起步跑通之后再用 LangGraph 重写核心链路做性能优化——这是当前性价比最高的路径。回到开头那份 PPT 的标题超越 RAG关键不是“抛弃”RAG而是把检索能力从一个静态流程变成智能体可以自由编排的动态能力。现在的 Agentic RAG 还不完美规划依赖大模型的能力上限工具调用也会带来更高延迟和成本但它的价值方向已经被验证了当 AI 应用从“回答问题”走向“解决问题”检索就必须从一次性的“提词器”变成可计划、可执行、可纠错的任务模块。如果你正在做知识库问答或智能体应用我的建议是从一个具体的业务场景出发先搭一套最小闭环把评测集建立起来再逐步把复杂度加上去——这条路径走起来不会太顺但每一步都能看到清晰回报。本文还有配套的精品资源点击获取