简介：一份系统讲解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 RAG
3.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 token，overlap 设为 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 设置为 10，Rerank 之后取前 5 个片段进上下文。
3.3 参数计算和成本评估
这里给出一个具体估算案例：假设知识库有 10 万份文档，平均每份 5000 token，全部切分成 512 token 的 chunk，大约产生 1000 万块数据。Embedding 成本按当前主流 API 价格估算，整体向量化费用会是一笔不小的开销；如果换成开源的 bge-m3 本地部署，成本可以压缩到 GPU 电费和硬件折旧以内。Agentic RAG 和传统 RAG 的 token 成本差异也要心里有数：同一问题，传统 RAG 可能消耗 1500 token，Agentic RAG 因为多轮调用和中间推理，可能消耗 4000-6000 token。这是智能体架构的默认代价，只能通过控制迭代次数和压缩中间输出来优化。
3.4 一个核心查询的跑通全过程
用实际案例走一遍流程。用户提问：“基于去年的销售数据，我们退货率最高的产品类别是哪个，主要原因可能是什么？”
- 感知层输出：intent=db_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 评测本身会消耗 token，100 条样本跑一轮大约需要 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 应用从“回答问题”走向“解决问题”，检索就必须从一次性的“提词器”变成可计划、可执行、可纠错的任务模块。如果你正在做知识库问答或智能体应用，我的建议是从一个具体的业务场景出发，先搭一套最小闭环，把评测集建立起来，再逐步把复杂度加上去——这条路径走起来不会太顺，但每一步都能看到清晰回报。
本文还有配套的精品资源，点击获取
