第 07 课我们搭好了朴素 RAG——把文档切块、向量化、检索出最相关的几段、塞进 prompt 让模型回答。demo 阶段它表现得很好，但一接真实用户就开始翻车：用户换个说法就检索不到，问题稍微复杂一点答案就一本正经地错。问题往往不在模型，而在于那条管道是写死的流水线，从头到尾没有任何环节负责”判断”。
这一课讲 Agentic RAG，白话说就是”智能体驱动的检索增强生成”：在检索环节放进一个会做决策的智能体，让它改写查询、多轮补检、自己评估检回来的资料够不够，再决定下一步怎么办。学完这一课，你能看懂检索层、编排层、生成层的架构分工，能和工程师讨论混合检索方案，也能算清一笔账——延迟和 token 成本成倍增加，换来的效果提升你的产品到底值不值得付。这是《AI 产品经理课》的第八课，专题目录在 AI 产品经理专题。
先把结论放在最前面：Agentic RAG 不是朴素 RAG 的替代品，而是它的升级选项。正确的路线是先把朴素 RAG 调到极限，用评估数据证明它确实到顶了，再谈 agentic 化。这也是本课最后一节要展开的落地建议。
朴素 RAG 的三个天花板
先复习一下朴素 RAG 的样子：用户提问，系统把问题向量化，去向量库里找最相似的 k 段文档（工程上叫 top-k 检索），把这几段和问题一起拼进 prompt，模型照着资料作答。整条链路每一步都是固定的，像一条只会直行的流水线。
它在三个地方会碰到天花板。
天花板一：单轮检索，一锤子买卖
朴素管道只检索一次，检到什么用什么。可复杂问题需要的资料往往分散在多个地方。用户问”A 套餐和 B 套餐的售后政策有什么区别”，理想情况需要 A 的政策、B 的政策各一份，但一次 top-k 检索经常只召回其中一边——因为问题的语义重心偏向了某一侧。结果就是模型拿着半份资料，硬对比出一个看似有理的结论。
人查资料不会这样。没有人只翻一页就写报告：翻一下，发现缺什么，再去翻。朴素 RAG 缺的就是这个”再去翻”的能力。
天花板二：用户的问法和文档的写法对不上
这个问题有个专门的说法叫词汇不匹配：用户说”退钱”，文档写的是”退款流程”；用户说”电脑卡死了”，文档写的是”系统无响应故障排查”。向量检索的卖点就是缓解这种语义鸿沟——意思相近的表达在向量空间里离得近。但它并不万能：行话、产品型号、内部缩写、错误码这类精确词，向量检索反而容易糊掉。真实业务里向量检索的召回质量本身也常被打问号，站内有一篇腾讯云向量库召回效果遭质疑的讨论，值得看看评论区里工程师们的一手体感。
朴素管道里，用户原话直接进检索器，问法刁一点就全盘皆输。没有人负责把”用户的话”翻译成”知识库听得懂的话”。
天花板三：管道不知道”检回来的够不够”
这是最隐蔽也最致命的一条。固定管道没有质检环节：不管检索结果相关不相关，一律塞给模型，模型也一律硬答。检索失败的下游表现就是幻觉——模型拿着不相关的资料，编一个语气笃定的答案。
打个比方：实习生去档案室拿错了档案袋，但汇报的时候照样讲得头头是道。听汇报的人（用户）没看过档案，根本无从分辨。第 07 课说过”检索质量决定上限”，朴素管道的问题是它连”检索质量差”这件事本身都感知不到。
这三个天花板的共同根源只有一个：管道里全是执行，没有判断。每个环节都在做事，没有环节在问”这一步的结果对不对，要不要重来”。
Agentic RAG：把检索的方向盘交给智能体
Agentic RAG 的思路，就是往检索环节里放一个能做决策的智能体。第 04 课给过智能体的最小定义：LLM 加目标加循环。放到检索场景里，目标是”凑齐回答问题所需的证据”，循环是”检索、看结果、决定下一步”。具体拆开，智能体接管了四个动作。
动作一：改写 query
用户的原话往往不适合直接拿去检索。智能体先做一道翻译：把”你们那个会员到期了还能退吗”改写成”会员到期后的退款政策”，把口语换成文档用语；碰到对比类问题，还会拆成多个子查询——”A 套餐售后政策”和”B 套餐售后政策”各查一次。这一步直接命中天花板二：有人负责把用户的话翻译成知识库听得懂的话了。
动作二：多轮检索
第一轮检回来，智能体看一眼结果：A 套餐的资料有了，B 套餐的没有，那就带着”B 套餐售后”再查一轮。多轮检索命中天花板一，本质上是把人类查资料的习惯还给了系统。
动作三：自评——检回来的够不够好
每轮检索之后，智能体自问一句：这些片段能支撑回答吗？能，进入生成；不能，换关键词重试，或者换一种检索策略，再或者——明确告诉用户”知识库里没有这条信息”。
别小看最后这个选项。”承认不知道”是重要的产品能力，比编一个像样的答案诚实得多，也是控幻觉最便宜的手段。朴素管道给不出这个回答，因为它根本没有评估环节；agentic 化之后，这变成一个可以设计、可以验收的产品行为。
动作四：选择检索策略
知识库不止一种查法：向量检索、关键词检索、按元数据过滤（时间、部门、产品线）、直接查结构化表格。智能体可以按问题类型挑工具——问”最新的报销标准”就先按时间过滤，问精确型号就走关键词。站内介绍过一个基于 LLM 与向量检索的简历筛选 Agent 系统，筛选逻辑就是由智能体按岗位要求动态决定的，而不是写死的规则。
用第 06 课的语言总结这场升级：朴素 RAG 是”工作流”，路径写死、行为可预期；Agentic RAG 是往自主性那端挪了一格，把检索路径的规划权交给模型。收益是灵活，代价是不确定——这条光谱上的权衡逻辑，和第 06 课讲的完全一致。想多看几种智能体架构的实践，可以翻翻 AI Agent 专题下的文章。
混合检索：关键词和向量是互补，不是谁淘汰谁
聊 Agentic RAG 绕不开检索工具本身。先用白话把两种主流检索方式说清楚。
向量检索：把文字变成一串数字坐标（向量化），意思相近的文本坐标也相近，检索就是”找语义上的邻居”。它擅长”换个说法也能找到”，比如”退钱”和”退款”。
关键词检索：按字面精确匹配。BM25 是最常用的打分算法，你可以把它理解成”更聪明的搜索引擎打分”；grep 则是最朴素的形态——逐行找包含某个词的文本。它擅长型号、代码、专有名词、错误码这类一个字都不能差的查询。
为什么要混合？因为两者的短板正好互补。向量检索会”糊”：搜”ERR-4032″，返回的可能是一堆语义上都像报错说明的片段，唯独没有那个精确错误码。关键词检索会”死板”：用户说”退钱”，它就真的搜不到”退款”。
有个反直觉的案例值得细品：AI 编程场景里，传统 grep 搜索在代码检索中的表现优于向量数据库。Claude Code 这类编程智能体没有给代码库建向量索引，就靠 grep 反复搜，效果反而更好。原因有两层：一是代码检索里精确匹配的价值极高，函数名、变量名差一个字符就是另一个东西；二是智能体可以多轮尝试不同关键词——第一个词没搜到就换一个，这个”多轮加自评”的循环本身就是 agentic 检索。这个案例给产品经理的启示是：检索工具越简单，编排层的价值越大；反过来说，上了智能体编排，你对单个检索工具的要求可以放低。
工程上的常见做法是两路同时检索、结果合并后重排序（rerank，用一个专门的模型给候选片段按相关性重新打分，留下最好的几段）。你不需要懂打分公式，但要记住一个验收要点：评估的时候，关键词路和向量路的命中率要分开看，混在一起就不知道该修哪边。另外检索层的工具选择远不止”上向量库”一种答案，站内那篇用 SQL join 替代图数据库的 RAG 实现就是个好例子——结构化数据用数据库原生的关联查询，比强行向量化更准也更便宜。
知识库和记忆是两套系统，别混在一起
需求评审会上常见的混淆：”我们的 AI 要有记忆”和”我们的 AI 要接知识库”被当成同一件事。它们经常用同样的底层技术（都可能用到向量检索），但在产品架构上必须分开。
知识库，也就是 RAG 检索的对象，存的是共享事实：产品文档、政策条款、操作手册。全体用户共用同一份，内容来自官方渠道，有人负责维护和审核。它对答案的要求是一致性——谁来问退款政策，都应该得到同一个答案。
记忆存的是个体经验：这个用户偏好什么、上次聊到哪、之前的任务做到什么进度。它因人而异，随交互自动增长，不需要审核。站内有一篇Agent 的记忆：从上下文到向量库把记忆的技术演进讲得很清楚；更工程化的方案可以看融合知识图谱与向量检索的 Hermes 持久化记忆实现，以及从图数据库角度讨论 RAG 瓶颈与 Agent 记忆的这篇。
为什么架构上必须分开？三个理由：
- 权限模型不同。知识库按角色控权限（销售看不到财务文档），记忆必须严格私有（用户 A 的偏好绝不能漏给用户 B）。
- 更新机制不同。知识库走审核发布流程，改一条政策要有人签字；记忆是自动沉淀的，没有人工环节。
- 出错的后果不同。知识库写错了是事故，要能回滚、能追责；记忆记错了顶多是体验变差。
打个比方：公司档案室和员工的个人笔记本都是”存文字的地方”，但没有公司会把它们锁进同一个柜子。用同一种技术，不等于该是同一个系统。
产品经理的操作建议：PRD 里把这两个模块的数据流和权限分开写；评审时对每一条要存的数据问一句”这是共享事实还是个体经验”，归类清楚，能省掉后期大量返工。
架构分层：检索层、编排层、生成层
把前面的内容装进一张架构图。Agentic RAG 系统通常分三层：
用户提问
│
▼
┌───────────────────────────────────┐
│ 编排层（智能体） │
│ 改写 query · 选检索策略 · 自评结果 │
│ 决定继续检索还是进入生成 │
└───────┬───────────────▲───────────┘
│ 检索指令 │ 检索结果
▼ │
┌───────────────────────────────────┐
│ 检索层 │
│ 向量检索 │ 关键词/BM25 │ 元数据过滤 │
└───────────────────────────────────┘
│ 筛选后的证据片段
▼
┌───────────────────────────────────┐
│ 生成层（LLM） │
│ 基于证据作答 · 标注出处 · 承认不知道 │
└───────────────────────────────────┘
│
▼
最终答案
分层的价值不在画图好看，而在排障和验收：每一层有自己典型的失败模式，出了问题能定位到层。
检索层失败：该召回的没召回。表现是后面全白搭——编排和生成再聪明也无米下锅。定位方法很直接：别看最终答案，直接看检索结果列表里有没有正确的那几段。
编排层失败：三种典型症状。死循环，反复检索始终觉得不够，延迟飙到用户放弃；过度检索，明明是一句 FAQ 也认真查五轮，成本白烧；错误终止，证据还没凑齐就开始作答，效果退化回朴素 RAG。表现出来要么是慢，要么是贵，要么是答非所问。
生成层失败：证据都检对了，答案还是错。模型忽略证据自说自话、把 A 文档的数字安到 B 头上、或者把有限定条件的结论过度概括。表现是”有出处但结论错”，最能骗过粗看的验收。
排查顺序沿用第 07 课的原则：从检索层开始。检索不对，上面两层修得再好都是白修。给产品经理的用法：提 bug 时说清楚是哪一层的问题（”检索层没召回”和”生成层没忠实引用”是两张完全不同的工单）；验收指标也按层拆——检索命中率对应检索层，平均检索轮数对应编排层，答案忠实度对应生成层。顺带一提，主流框架都在往生产级 agentic RAG 方向演进，比如主打生产级智能体与 RAG 的 Haystack 与 LangChain 之争，但分层思路是通用的，换框架不用换概念。
成本账：延迟和 token 都会成倍涨
Agentic 化不是免费午餐，这一节把账算清楚——都是定性的量级判断，具体数字以你们自己的压测为准。
朴素 RAG 一次问答的开销：一次检索加一次生成调用。Agentic RAG 呢：改写 query 是一次 LLM 调用；N 轮检索，每轮之后的自评又各是一次 LLM 调用；最后还有一次生成。轮数不固定，延迟从一两秒涨到可能十几秒，token 消耗轻松翻几倍。还有一笔隐性账：多轮检索攒下来的上下文更长，最后那次生成调用本身也变贵了。上下文膨胀已经是业界公认的成本痛点，Kapa 用小模型修剪 RAG 上下文、把成本降了 34% 的实践就是专门冲着这个问题去的——检得多不等于都该塞给模型。
什么产品值得付这个代价？给一组判断标准。
值得：答错代价高的场景，法务咨询、医疗信息、售后承诺，一个错误答案的损失远超几倍 token 钱；问题天然复杂的场景，多文档对比、跨部门查询，朴素管道根本做不对；用户能接受等待的场景，异步生成的调研报告、周报摘要，慢十秒没人在意。
不值得：高频简单查询，FAQ 类问题朴素 RAG 就够，知识量小的话甚至直接把全部资料塞进上下文窗口更省事（第 07 课讲过这个判断）；对延迟敏感的实时对话，用户等不了；客单价撑不起成本的免费产品，token 账单会先于用户增长把你压垮。
实践中最常见的折中是路由：先用一次便宜的小模型调用判断问题复杂度，简单问题走朴素管道，复杂问题才升级到 agentic 链路。大部分流量走便宜通道，少数硬问题享受贵服务——这是很多生产系统的真实形态，也是你在方案评审里最该主动提出的选项。
落地路线：先把朴素 RAG 调到极限
本课最重要的一条建议：别跳过验证直接扩规模。拿着 Agentic RAG 的架构图立项，评审会上很唬人，但如果连朴素管道的检索命中率都没量过，这就是把钱花在看不见收益的地方。推荐的顺序是五步。
第一步，先建评估集。收集五十到一百个真实用户问题，人工标注标准答案和应该命中的文档片段。没有这个基准，后面任何”升级”都无法证明有效——你甚至说不清升级前有多差。站内那篇 RAG 项目实战复盘的核心结论就是：数据与评测比模型调优更重要，绝大多数团队把力气花错了地方。
第二步，把朴素 RAG 榨干。修分块策略、清洗文档、调 top-k、加元数据过滤、上混合检索。这些改动便宜、见效快，而且经验上，多数”RAG 效果差”的项目死在数据质量，而不是架构不够先进。表格切碎了、过期文档没下线、标题层级混乱——这些第 07 课点过名的坑，升级架构一个都解决不了。
第三步，用评估集定位剩余的失败。如果失败样本集中在”问法绕、需要多轮检索”的类型上，才轮到 agentic 化登场。而且别一步到位：先只加最便宜的 query 改写，跑一遍评估集看提升；有效再加自评和多轮，一步一验。
第四步，上线后建反馈闭环。用户的点踩、改写提问、追问，都是免费的标注数据，回流进评估集和知识库运营。NVIDIA 给三万人规模的 RAG 助手装数据飞轮就是这个思路的规模化版本：系统越用越准，靠的不是模型升级而是数据回流。
第五步，需求稳定之后，再考虑更重的方案。垂直场景里已经有不少可参考的产品形态，比如集成 AI Agent 与 RAG 检索的文献管理工具 PaperQuay——agentic 检索先在高价值、低频次的场景落地，是符合成本逻辑的选择。
最后留个钩子：这一课反复出现”智能体选择检索工具”，它在技术上怎么实现？答案是工具调用——模型输出”我想调用哪个工具、参数是什么”，由系统代为执行。这正是第 09 课 Function Calling 的主题。
相关阅读
- RAG 项目实战复盘：为何数据与评测比模型调优更重要
- AI 编程新发现：传统 Grep 搜索在代码检索中竟优于向量数据库
- Kapa 公布新策略：用小模型”修剪”RAG 上下文，成本降低 34%
- 开源教程：基于 Java 的 RAG 全流程实现，接入飞书 WIKI 构建知识库
- 构建 AI Agent 的”外挂大脑”：基于 SQLite 向量化与 MCP 的记忆进化方案
FAQ
我的产品该用朴素 RAG 还是 Agentic RAG？
先看两个指标：问题复杂度和答错代价。FAQ 型简单查询、延迟敏感的实时对话，朴素 RAG 加混合检索就够；多文档对比、跨源查询、答错代价高的场景才值得上 agentic。拿不准就做路由：小模型先判断复杂度，简单问题走便宜管道，复杂问题走 agentic 链路。任何决策都要以你自己的评估集数据为准，而不是架构图的美观程度。
上下文窗口越来越大，直接把资料全塞进去不就行了？
知识量小的时候确实可以，这是最简单也最该优先考虑的方案。但它有三个边界：知识库大到超出窗口就塞不下；每次请求都携带全量资料，token 成本随知识库线性增长；资料太多时模型对中间部分的注意力会下降，反而不如检索后精准投喂。所以长上下文和 RAG 是互补关系——小知识库直接塞，大知识库靠检索。
混合检索一定比纯向量检索好吗？
大概率好，但前提是你分开评估两路的贡献。混合检索多了融合和重排序环节，如果关键词路配置得差（比如没做同义词处理），可能引入噪声。正确姿势是：用评估集分别测纯向量、纯关键词、混合三种配置的命中率，用数据说话。如果你的场景全是精确查询（型号、编号），甚至可能纯关键词就赢了。
Agentic RAG 的自评环节靠谱吗？模型自己评自己会不会放水？
会有这个问题，自评本质上还是一次 LLM 调用，它可能误判”证据已经够了”。工程上的缓解手段包括：用另一个模型做评估（裁判和选手分开）、给自评设硬性规则兜底（比如检索结果相关性分数低于阈值必须重试）、限制最大检索轮数防止死循环。产品层面更重要的是把”承认不知道”设计成正常出口，并在验收指标里单独统计误终止率。
结语
朴素 RAG 缺的是判断力，Agentic RAG 补的正是这一环。但升级的前提是度量：先建评估集，榨干朴素管道，再让智能体接过检索的方向盘。账算清楚了，架构才立得住。
