从RAG到Agentic RAG：知识检索管道原理与实战优化

1. 为什么 Agent 的知识不能只靠记性记忆体系与 RAG 的定位AI Agent 系列写到第四篇前面几篇我们一步步把 Agent 的骨架搭了起来让它有了目标拆解的能力、调用工具的能力也让它知道怎么跟外部系统打交道。但我发现一个很现实的问题很多人在本地跑通了一个 Agent问它通用知识它头头是道一问你自己公司的业务细节它就立刻卡壳了。比如你问我们内部 OA 系统的加班审批流程是什么它要么胡编一通要么直接告诉你它不知道。这个问题的本质在于 Agent 的知识来源。我们今天要聊的知识获取管道——RAG解决的就是这个事。RAGRetrieval-Augmented Generation检索增强生成。名字听起来学术其实理解起来很简单它就是在模型回答之前先帮模型查资料然后把查到的资料和用户的问题一起交给模型让模型基于资料作答。这让模型不再是凭空硬答而是有一个随身知识库可以随时翻阅。这篇文章适合两类人一类是刚学完 Agent 基础、准备给 Agent 接私有数据的开发者另一类是已经在做 RAG 但经常遇到检索结果不对回答幻觉明显这些问题想系统梳理一遍原理和排查思路的工程师。在展开之前先想清楚一个前提Agent 到底需要几种记忆我把 Agent 的记忆体系分成四个层次理解了这个你就能明白 RAG 在整个架构里的位置。记忆层次载体特点典型问题参数记忆模型权重训练时固化通用知识有截止日期无法更新上下文记忆对话窗口当前会话内的信息长度有限会话结束即失外部知识库向量数据库动态更新可追溯需要检索有召回失败风险外部工具数据API / 数据库实时查询结构化依赖接口需要工具调用能力这里的第三层——外部知识库就是 RAG 的用武之地。为什么不能只靠第一层和第二层原因很简单参数记忆是模型在训练时灌进去的它有明确的截止时间而且永远学不会只有你公司才有的私有文档上下文记忆虽然灵活但受限于窗口长度你不可能把一个几千页的运维手册全塞进对话框里。RAG 的定位就是给 Agent 接一条通往任意规模知识库的标准化管道。它有三个其他方案替代不了的价值知识实时可更新你改了文档它就跟着变回答有据可循可以回溯到原文片段私有数据不出内网敏感信息不必送进模型训练。这三条恰好是企业在实际落地 Agent 时最先提出的三个硬性要求。2. 三段式管道拆解索引、检索、生成各自负责什么RAG 被称为管道是因为它的数据流是固定方向的每一段都有明确的输入输出。整条管道分三段索引、检索、生成。我在刚接触这个概念时总觉得它玄乎后来用一个生活化的类比就串起来了这就像一个刚入职的实习生你不可能让他直接回答老板的问题之前就把公司所有文档背下来。更靠谱的做法是先请一个图书管理员把所有文档整理好放进档案馆老板问问题的时候管理员去档案馆把最相关的几页文件挑出来实习生再基于这几页文件写答复。这个类比里的整理归档就是索引挑文件就是检索写答复就是生成。下面一段一段拆开看。2.1 索引把杂乱文档变成可检索的向量数据库索引阶段做的是从原始文档到向量库的加工。流程固定在四步清洗、切分、向量化、入库。清洗是很多人最容易跳过的一步但恰恰是最影响最终效果的一步。PDF 转出来的文本经常带页眉页脚、目录跳转、乱码Word 文档里可能有批注和修订痕迹网页抓下来的内容带着 HTML 标签和导航链接。这些噪声如果不清掉后面切出来的 chunk 里就会混着大量废话检索出来的片段质量自然上不去。我的习惯是先用工具把文档转成纯文本再写一个清洗脚本做三件事去空白字符、去重复的页眉页脚、把全角符号统一成半角。这一步花的时间通常决定了整个 RAG 的天花板。切分是把长文档切成一个个适合检索和生成的小块。为什么要切两个原因。第一向量检索的单元是小块而不是整篇文档如果拿整篇文档去比对相似度命中精度会非常差第二模型生成时能接收的上下文有限你不可能把一本手册全塞进去只能挑最相关的几块。向量化就是把每个切好的文本块用 Embedding 模型转成向量。这里的核心原理是模型把一段文字映射到高维空间里的一个点语义相近的文字在高维空间里距离也近。比如加班审批流程和如何提交加班申请意思接近它们的向量在空间里就挨得很近而加班审批流程和附近的外卖推荐就离得很远。这一步产出的向量要存进向量数据库常见的有 Chroma、Milvus、Qdrant、pgvector还有国内用的比较多的 Elasticsearch 的向量检索能力。入库阶段有个经常被忽略的点入库时不只要存向量和文本还要把元数据一同写进去。文档来源、文档名称、章节路径、更新时间这些字段在后续的过滤检索和回答溯源里会派上大用场。我在做知识库时一定会带上这些元数据宁可多存几个字段也不要等到排查问题时发现无从溯源。2.2 检索把用户问题变成查询从向量库里捞出相关内容检索阶段做的事情是把用户的问题走一遍同样的向量化流程然后用相似度算法把知识库里最相关的若干文本块捞出来。计算相似度最常用的算法是余弦相似度。两个向量的夹角越小余弦值越接近 1表示语义越接近。实际应用时向量数据库底层会做近似最近邻搜索ANN不会真的拿你的查询向量和库里所有向量逐个算一遍那样大数据量下性能扛不住。ANN 算法比如 HNSW、IVF通过建立索引结构把搜索范围大幅缩小在牺牲很小精度的前提下把速度提上去。检索结果的排序依据是相似度分数但我们通常不是只看排名第一的那一条而是取 Top-K 条一起返回。K 的值一般取 3 到 10 之间具体要根据 chunk 的大小和模型上下文长度来调。这里有一个常见的认知误区不是 K 越大越好。K 太大会把一堆相关性一般的片段塞进上下文反而稀释了真正有用的信息甚至导致模型看花了眼生成质量下降。K 太小又可能漏掉关键内容。我在实际项目中通常先把 K 设成 5然后根据测试集的命中率来调整。2.3 生成让模型拿着资料回答问题生成阶段是把检索到的文本块和用户原始问题拼装成一个带指令的 Prompt交给大模型生成最终回答。这一步的关键不是模型本身而是你如何设计这个 Prompt。一个合格的 RAG 生成 Prompt 至少要有三部分系统角色约束、检索到的上下文、用户问题。系统角色约束里必须写明一句话——请仅依据下面提供的上下文内容回答用户问题如果上下文中没有相关内容请直接回答未在资料中找到相关信息不要编造。这句话看着简单却直接决定了回答的忠实度不加这句话模型八成会自己脑补。我在实际工作中还会加两个额外要求一是回答中涉及的事实点要尽量标注出来自哪段上下文二是如果有多段上下文互相矛盾要如实说明资料中存在不一致的描述。这两条能极大缓解 RAG 系统的幻觉问题。到这里三段式管道的主干就清楚了。但具体落地时你会发现每一段都有大量可以优化的细节而其中最影响最终体验的是中间那段检索的质量。下一章专门来聊这件事。3. 检索质量才是真天花板chunk、Embedding 与混合检索的取舍很多刚上手 RAG 的人会有一种错觉只要把文档切一切、塞进向量库然后调接口检索系统就能工作。实测下来系统确实能工作——但回答质量经常让人血压升高。问题几乎都出在检索环节。检索环节决定了模型能看到什么而模型只能基于看到的东西作答。所以把检索质量打磨好是整个 RAG 系统投入产出比最高的事情。这一节我把检索质量相关的三个核心决策点逐一展开chunk 怎么切、Embedding 怎么选、怎么组合检索策略。3.1 chunk 切分文本块的粒度决定召回精度chunk 切分在工程上是最容易被随手糊弄过去的一环但它的影响极其深远。切得太小每个块语义不完整检索容易碎片化切得太大块里信息太杂相似度计算被大量无关内容干扰关键信息反而被淹没。我实测过的切分策略有四种按推荐程度排序固定长度切分最基础按 token 数或字符数硬切比如每 512 个 token 切一块相邻块之间保留 50 个 token 的重叠。优点是实现简单缺点是容易在句子中间切断最常见的就是把一个完整的表格数据从中间劈开。递归字符切分推荐先按段落分隔符切如果切出来的块还是太大再按句子边界切最后按单词/字切。这种策略能在尽量保持语义完整的前提下控制块的大小是多数项目里性价比最高的方案。结构化切分进阶针对 Markdown、HTML、代码这类有明确层级结构的文本按照标题层级来切分。比如先按一级标题分章节再按二级标题分子节。这样切出来的每个块都有清晰的上下文检索结果天生就带着章节归属。语义切分最重用模型来判断句子间的语义边界在语义断裂处切分。效果最好但计算成本高适合预算充足、对精度要求极高的场景。chunk 大小怎么定我的建议是先按语言来粗定。中文场景下每块 300500 个汉字是一个不错的起点英文场景下按 200400 个 token 来。然后根据实际检索效果回调不要一开始就在参数上纠结先把管道跑通再拿真实问题去测。3.2 Embedding 选型没有最好的模型只有最合适的场景Embedding 模型直接决定了语义相近这件事在你这套系统里成立不成立。选错模型后面所有的检索优化都事倍功半。我列一个当前我用过的几类方案对比方案维度适合场景部署方式我的评价OpenAI text-embedding-3-large3072可降维通用英文效果极佳多语种可用API 调用效果好但数据要出网不适合私有化场景开源 BGE 系列如 bge-large-zh1024中文效果好支持多语言本地部署私有化首选国产硬件上也跑得动text2vec-large-chinese1024中文语义匹配老牌选手本地部署中文效果扎实迭代相对慢M3E 系列1024中文场景训练数据覆盖多种中文任务本地部署轻量适合快速验证选型时除了看模型效果还要看三个工程因素向量维度会影响存储成本和检索速度维度不是越高越好推理速度决定你的索引和检索的吞吐许可证和部署环境决定能不能落地。我的经验是一开始别急着上最强模型先用一个开源部署难度低的模型把整套管道跑通等业务验证了 RAG 确实有用再回来评估要不要换更好的模型。3.3 混合检索向量检索不是万能的如果说前面两小节是地基那这一小节是真正的分水岭——很多人做到向量检索就觉得 RAG 完工了直到遇到一个尴尬场景用户问KB-2041 型号的说明书有没有向量检索召回的结果乱七八糟。为什么因为向量检索擅长语义匹配但不擅长精确匹配。像产品型号、工单编号、设备序列号这种编号类文本语义相近但字面完全不同的句子检索出来的是两回事。这时候传统的关键词检索反而更可靠——关键词检索就是你在搜索框里输入KB-2041系统按字面匹配去搜编号这种特征能精确命中。解决方案就是混合检索同时跑关键词检索和向量检索再把两路结果融合排序。关键词检索我用 BM25 算法它基于词频和文档长度做加权打分向量检索走余弦相似度。融合的方式最简单的有加权求和比如向量分数占 0.7、BM25 分数占 0.3也可以先各取前 20 条再做交叉重排。实测下来混合检索比纯向量检索的命中率有明显提升尤其是在知识库里混着大量编号、代码、人名、地名这类实体信息时。加了关键词检索之后还有一个额外的好处用户可以靠记不全但记得片段的词找回内容体验比纯向量检索亲切得多。3.4 重排把分数可信度拉回来的最后一道闸混合检索拿到的是一个候选集合通常有几十条。直接把这几十条全塞给模型显然不行上下文会被撑爆。这时候需要重排Rerank——用一个更精细的模型把候选结果按相关性精排只保留最前面的几条。重排模型的典型实现是 Cross-Encoder 结构它不是把问题和文档分别编码成向量算相似度而是把问题 文档拼接成一句完整文本和模型一起编码直接输出一个相关性分数。这个过程的精度比向量相似度更高但计算量大所以把它放在第一道粗筛之后、精排候选集规模只有几十条时这个开销完全可以接受。用重排模型之前我建议先调 beam 数量第一道检索尽量多召回比如 Top 50让重排模型在足够大的候选池里挑然后再取重排后的前 3 到 5 条进上下文。我见过不少人直接把 Top 5 丢给模型遇到长尾问题答不好加了一道重排后效果立竿见影。4. 从单次查资料到带规划地查资料Agentic RAG 的方向前面讲的三段式管道是 RAG 的经典形态。它在多数问答场景里足够好用但当你把 RAG 接入 AI Agent 之后会发现一个更况味的问题用户的问题常常是复杂的、多跳的一轮查资料—回答根本搞不定。举一个我真实遇到过的例子。用户问我们二季度的售后工单为什么比一季度高这么多主要是什么产品引起的这个问题要回答至少需要三步先检索二季度售后工单统计再检索主要产品销量对比还可能得检索具体产品已知的售后问题记录。一辆经典的 RAG 管道拿着这个 query 去检索大概率只能返回其中最相关的某个片段的答案而凑不齐完整的因果链。这时候RAG 就需要升级成 Agentic RAG——让 RAG 管道具备规划—执行—再规划的能力。说白了就是把检索本身当成 Agent 可以调用的工具让 Agent 自己决定什么时候查、查什么、查几次而不再是从头到尾只做一次固定检索。我在实际项目中梳理出了 Agentic RAG 的四个实用方向检索路由让 Agent 先判断用户这个问题到底需不需要走知识库。有些问题靠模型自身知识就能回答比如什么是递归算法有些问题必须走知识库比如我们公司的报销标准是什么。路由可以是一个轻量分类器也可以由 Agent 根据 query 与知识库摘要的描述来决定。这一步能省掉大量无效检索直接提升系统速度。多跳查询拆解把用户的复杂问题拆成多个子查询逐个子查询走检索然后再把多轮的检索结果汇总起来生成最终答案。刚才提到的售后工单例子就是典型的拆解场景。拆解工作可以由 Agent 自主完成也可以预设几个固定的子问题模板我在项目里更推荐后者可控性高得多。动态改写查询第一轮检索结果不满意时Agent 分析哪些关键词没命中改写 query 重新检索形成一个检索—评估—再检索的循环。这比前端强制要求用户把问题问清楚要聪明得多。多路知识源配合知识库不止向量库一个来源还可以挂关系型数据库、API 接口、Wiki、图谱。Agent 可以根据问题的性质决定从哪个管道获取知识。比如查结构化财务数据就查数据库查病历就查内部 Wiki查产品关联关系就查知识图谱。最后一个方向里我想多说一句知识图谱和 Ontology本体的应用。纯向量检索很难回答哪些产品跟哪些业务线有关系这类关系型问题因为关系是显式的、结构化的。把知识库里的实体和关系抽取出来建成本体Agent 就能完成在知识之间跳跃的推理这也正是最近一段时间 GraphRAG、Ontology RAG 这类方案逐渐被讨论的原因。它不是取代向量 RAG而是在向量 RAG 之上补一层关系推理能力两者是配合关系不是替代关系。做 Agentic RAG 时有一个工程上容易失控的点循环检索的次数如果没有上限single query 会在多个子查询之间来回跳响应时间成倍拉长。我的做法是给 Agent 的检索工具加两个约束单次任务最多执行 N 次检索N 通常设为 35每次检索必须携带目标说明字段Agent 在日志里能看清每次检索是为了回答问题的哪一部分。加了这两个约束整个链路的可观测性会强很多排查问题也快得多。5. 我踩过的坑检索不到、答非所问、幻觉的排查链路这一篇最后我想把实践中最容易踩的坑汇总一下附带完整的排查思路。这些坑不一定都能从教科书里看到但只要你做 RAG大概率会碰到其中一两个。5.1 坑一调了检索接口结果永远是相似度最高的那几段但答案就是不对这个坑的典型表现你问加班审批的流程系统返回的片段确实聊到了加班但内容其实是加班补贴的发放标准答非所问。排查链路从数据源头开始第一步把命中的 chunk 打印出来看文本片段本身是否的确包含了问题的答案。如果原文里这块内容本身就答不对题问题出在检索召回阶段是 chunk 粒度和切分方式不合适。如果原文里包含答案但向量检索没召回那就是切分时关键句被拆到了两个块里或者 embedding 模型没能理解同义改写。我踩过之后学到的经验是不要只调 Top-K要先去啃切分策略。把加班审批流程相关的内容手工标出来检查它在库里被切成了几块、每块是否完整、能否被检索回来。切分问题不解决后面的重排和调参都是白费。5.2 坑二检索返回了一堆内容但答案里还是出现原文没有的信息这比检索不到更危险——模型开始脑补了。这种情况十有八九是生成 Prompt 里的约束不够硬。我见过很多项目的 Prompt 写的是请参考以下资料回答问题这个参考字眼太软了模型会把它当成可用可不用的提示。排查思路第一步检查 Prompt 里的系统指令是否明确写死了只能基于给定上下文作答第二步看上下文里是否混入了历史对话残留导致模型分不清哪个是资料、哪个是闲聊第三步检查检索结果里是否有矛盾片段模型被冲突信息逼急了会自己编一个合理答案。我自己的对策是在生成阶段做指导性约束 检查钩子双重保险。约束就是那几句强指令检查钩子是要求模型回答完以后输出它右侧引用的资料的索引编号。然后我用一个小脚本比对回答里出现的引文编号是否全部都存在于本次上下文里。不在那就是模型编了直接拦截。5.3 坑三知识库数据很干净但总有一些问题怎么检索都召回失败这种情况我称之为长尾撞脸最常见于用户用一种模糊的、口语化的方式提问而知识库里用的是严谨的书面术语。比如用户问打印机老卡纸怎么办知识库里写的是设备进纸路径堵塞故障处理。排查链路第一步把用户的 query 和库里的文档做同义改写比对确认是术语不匹配第二步检查是否需要引入同义词扩展在检索前先把 query 里口语化词汇替换成知识库里的书面语第三步检查是否需要给知识库里的核心文档提前打标签或者用混合检索的 BM25 部分补充精确匹配。这里有一条实打实的捷径把历史问题日志里被判定为未命中的 query 收集起来定期用它们回放测试检索效果并针对高频未命中 query 手工补标签或者补几条标准 QA 进库。这是 RAG 系统上线后最实用的一种迭代方式比反复调 embedding 模型参数见效快得多。5.4 坑四本地部署文档几万篇之后检索越来越慢这个坑很多人是等上线后才发现的文档量一上来向量检索延迟从 100ms 涨到 2000ms用户体验直线下降。排查链路从数据库的索引类型看起第一步确认向量索引用的是 HNSW 还是 IVF普通暴力扫描肯定扛不住第二步检查向量维度是否有必要用那么高有时候从 3072 维降到 1024 维速度快五倍精度损失却很小第三步看看是不是可以把知识库按业务域拆分出多个 collection在做检索时先按业务域路由一次再进小库检索。在这个问题上我的实测结论是几万篇文档级别本地部署的 Milvus 配合 HNSW 索引完全能支撑 500ms 内的检索如果远慢于这个值优先排查索引参数和查询调用的重复向量化。另外一个容易被忽略的小优化知识库更新时只对新文档做增量向量化不要每次全量重跑。5.5 怎么系统性地评估一套 RAG 效果hit rate 和 MRR排查坑的前提是你得先有一种客观手段衡量 RAG 的好坏。我强烈建议每个 RAG 项目上线前建立一套小规模的评测集。不用很多50 到 100 条真实问题和对应的标准答案片段就够。评测指标最核心的有两个Hit Rate命中率和 MRRMean Reciprocal Rank。Hit Rate 很简单就是所有问题里正确答案出现在检索结果 Top-K 中的比例。MRR 会进一步惩罚答案排在越后面的情况——如果标准答案排在第一位贡献 1 分排在第二位贡献 1/2排在第三位贡献 1/3取所有问题的平均值。这两个指标能帮你快速判断改动切分策略后检索质量到底是提升还是退步了。我实际操作时有个习惯化的流程在这里分享给各位每次调完参数固定评测集跑一遍记录 Hit Rate 和 MRR 两个数同时把答错的案例单独摘出来看——分析每个答错案例属于上面哪一类坑然后按比例排优先级处理。不基于评测指标去调参就是在碰运气不带案例分析的评测调参容易调出自欺欺人的结果。这两句话是我做了几个 RAG 项目之后总结出来的最核心心得。最后再分享一个小技巧如果你要用 RAG 做知识库问答还得记住知识获取管道之外的一条铁律——永远保留查不到就直说的出口。给模型在 Prompt 里写清楚未找到相关内容时如何应对让系统敢于承认不知道比强行给答案要更得人心。把这一步做扎实了再谈 RAG 的进阶玩法地基才算真正稳了。