做技术咨询这几年，被问到最多的问题几乎都围绕同一个场景：知识库接上大模型之后，为什么还是会一本正经地胡说八道。后来我看过很多团队的实现，发现绝大多数人用的都是最基础的那版RAG，也就是Naive RAG——文档一切、向量一存、检索一拉、上下文一拼就完事。这个方案能跑通Demo，但离生产可用差得远。所以我想把RAG这条演进路线完整梳理一遍：从朴素RAG的文档切分、向量检索、拼接生成，到进阶阶段的查询改写、混合检索、重排序，再讲到现在热度很高的Agent化RAG——什么时候该加路由，什么时候应该让模型自主规划检索路径，什么时候引入工具调用。程序员沿着这条线走，基本就能把RAG从原型一路做到能扛业务压力的状态，这也是这篇博文想给到你的核心价值。
1. 为什么RAG值得你投入精力去学
先聊一个基础的认知问题。大模型本身是“记忆型”选手，训练完成后参数就冻结了，你问它没见过的内部资料、最新文档、私有数据，它要么答不出，要么编一个。RAG（Retrieval-Augmented Generation，检索增强生成）解决的就是这件事：在生成之前，先从外部知识库里检索出和问题最相关的片段，把它们拼进上下文，让模型“开卷考试”。
这套思路看起来简单，但真正落地时会发现，检索质量直接决定生成质量。检索回来的片段不相关，模型再强也白搭；检索回来的片段互相冲突，模型会选择性相信其中一个，幻觉照样发生；检索链条本身太慢，整个交互体验就会变得不可用。我见过很多项目，前期把精力全花在调提示词上，结果瓶颈根本不在生成，而在检索管道那一大堆没人关注的细节里。
RAG技术这几年的演进，本质上就是围绕“怎么让检索结果更准、怎么让模型更会利用检索结果、怎么让整套系统自己做决策”这三个问题展开的。业界大致把它分成三个阶段：朴素RAG（Naive RAG）、进阶RAG（Advanced RAG）和模块化RAG（Modular RAG）。朴素RAG解决“有没有”的问题，进阶RAG解决“准不准”的问题，模块化RAG解决“聪明不聪明”的问题。三个阶段不是割裂的，后面的方案完全兼容前面的基础建设，你可以按自己的业务场景选择停在哪一档。
对程序员来说，RAG还有一个特殊的吸引力：它是少有的、能让你亲手把数据工程、算法工程和人机交互全部串起来的技术方向。你需要处理文档解析、设计切分策略、选嵌入模型、搭建向量检索服务，还要考虑上下文窗口的限制、回答的可信度、系统的延迟和成本。每一个环节都有真实的工程问题，每一个问题都有相对成熟的解法。能力强的人甚至可以在此基础上做出一套带自主规划能力的知识助手系统——这正是从“能用”到“好用”的分水岭。
2. 朴素RAG：最原始的“搜索加抄答案”模式
先别急着上复杂架构，把朴素RAG完整走通一次，你会对整条链路里每一环的职责都有体感。这个阶段踩过的坑，会成为你判断后面所有优化方案有效性的基准线。
2.1 一次完整的朴素RAG跑通链路
朴素RAG的全流程可以拆成六个步骤：文档解析、文本切块、向量化、索引存储、检索召回、拼接生成。
文档解析是把PDF、Word、Markdown、HTML这些杂乱格式转成纯文本，这一步看似简单，实际是后面所有环节质量的地基。PDF里的表格、多栏排版、扫描件，都会产生大量乱序文本；Word里的页眉页脚、批注也是干扰源。我建议在这步就做一次清洗，至少把空行、控制字符、无效换行处理掉，否则切出来的块里会混进大量垃圾信息。
文本切块是把长文档切成适合检索的小段。这一步直接决定了检索的“颗粒度”。切得太粗，一块里面塞了太多主题，检索时命中主题A的问题，却把主题B的内容也带回给模型；切得太细，语义被切断，一条完整的方法论被拆成两半，模型拿到的是残缺信息。
向量化是用嵌入模型（embedding model）把每个文本块变成一个高维向量。这一步的产出是一串浮点数，它在语义空间中表示这段文本的位置。两段文本语义越相近，它们的向量距离就越近，这就是后面检索能用“最近邻”算法的原因。
索引存储是把所有向量连同原始文本、元数据一起放进向量数据库。常见的方案有专门的向量数据库，也有在传统数据库上加向量索引的实现，选择依据是你们的运维能力和数据规模，后面我会展开。
检索召回时，系统把用户问题也转成向量，然后在库里找出和它距离最近的Top-K个文本块。这里有个很容易忽略的点：召回数量的选择。K太小容易漏，K太大容易把不相关的东西塞进上下文，我用的时候通常从4到8起步，再根据效果调整。
拼接生成是把用户原始问题和召回片段按某种模板拼成完整的Prompt，交给大模型生成最终回答。很多人以为这里就是把片段一股脑塞进去，其实模板设计也讲究，比如要加“仅依据以下资料回答，不要使用先验知识”这类约束，还要在片段开头标注来源，方便模型区分多个文档证据。
2.2 文本切分的学问
切分策略是整个朴素RAG里最容易被低估的一环。固定长度切分是最直接的方案，设定一个chunk_size，比如512个字符，然后再设一个chunk_overlap，比如64个字符，让相邻块之间有部分重合。重合的意义在于避免一句话被拦腰截断，保证跨块边界的语义能有一点冗余。
经验上，切分块的大小要和你的知识库文档形态强相关。如果你处理的是技术文档，每个段落本身就是有意义的信息单元，那么按结构切分（比如按标题、按段落）比按固定长度切分效果好得多。如果你处理的是聊天记录、原文书籍这类连贯文本，固定长度加合理的overlap会更稳。
更精细的做法是递归字符切分：先用段落级分隔符切，段落太长再往句子级切，句子还太长再按固定长度补刀。这套逻辑在很多开源文本加载库里都已经封装好了，你只需要调参，但理解它的递归本质很重要，否则出了问题不知道怎么排查。
还有一种语义切分，用嵌入模型计算句子间的相似度，在语义断裂的地方切块。这个方案效果上限高，但计算成本也高，适合对质量要求苛刻、文档结构又不规律的场景。我自己在内部知识库项目里，超过八成场景用“结构优先、定长兜底”的策略就能满足需求，没必要一上来就上重型方案。
切分时还有一个容易被忽略的细节：块与块之间的元数据保留。比如给每个块打上来源文档、章节、页码、更新时间这些标签，后面做引用溯源和过滤会非常省力。没有元数据的RAG系统，就像没有目录的档案柜，检索到内容但说不清它从哪来，这在企业级场景里是不可接受的。
2.3 嵌入模型与向量检索选型参考
嵌入模型的选择直接影响检索的语义理解上限。目前主流的选择分两类：一类是开源的通用嵌入模型，多数按语义相似度训练，用起来免费、可私有化部署；另一类是商业API形式的嵌入模型，效果通常更好，但对数据出境敏感的项目不友好。我的建议是先在你们自有数据集上做一次小范围效果评测再决定，不要只看公开榜单的分数。
向量数据库的选型则要看你们团队的运维能力。如果已经有成熟的数据库运维体系，优先考虑在现有数据库上加向量索引能力，减少一套新组件的运维负担。如果从零开始，专门的向量数据库更容易上手，内置了多种索引类型、过滤能力和监控面板。不管选哪种，核心要关注的参数是索引类型、召回质量和写入性能。
向量检索背后的原理，最常用的是近似最近邻（ANN）算法，其中HNSW（分层小世界图）是默认选择。它把高维向量组织成分层图结构，检索时从顶层快速定位到目标区域，再往下精细搜索。HNSW的索引参数里，M（每个节点的最大连接数）影响内存和召回率，efConstruction影响建索引时间，efSearch是检索时的候选集大小。实际调参时，我通常会先固定M为16或32，然后把efSearch从16往上加，观察召回率不再明显提升就停。
关于相似度度量，余弦相似度是处理文本向量时的默认选项，它只关注方向，不关心向量长度，能有效抵消嵌入模型对文本长度带来的偏差。内积和欧氏距离在部分场景也有用，但如果你不是特别清楚原理，直接用余弦就好。记得在选型时保持查询向量和文档向量使用同一个度量标准，否则检索结果会变得莫名其妙。
2.4 朴素RAG绕不开的三大瓶颈
朴素RAG在真实业务里会暴露三个明显问题，我把它们称为召回不精准、上下文混乱、知识更新僵化。
召回不精准的典型表现是：用户问的问题经过了口语化、省略语、指代等变形，和知识库里文档的写法差距太大。比如用户问“上次那个版本为什么挂了”，而文档里写的全是“某次发布事故分析”，语义上相关，向量距离却很远，导致检索失败。这不是嵌入模型的问题，是“查询端到底是用户的原话还是改写后的表达”这个设计问题没解决。
上下文混乱的典型表现是：召回的多个片段来自不同文档，其中一部分和问题高度相关，另一部分只是字面相似。模型拿到混合信息后，会试图“调和”这些矛盾，结果生成了既不应该出现、又无法溯源的内容。这本质上是因为RAG管道只是“捡回Top-K”，没有做相关性精排和冲突消解。
知识更新僵化则是很多初学者的误区——以为RAG可以完全替代模型的重新训练。实际上，RAG只是把外部知识库接到了生成环节，你更新了库里的文档，索引确实能跟着更新，但如果文档之间的联系、版本之间的差异没有做整理，模型在回答时依然会混淆新旧内容。重构索引快，重构知识的组织方式慢，这一点很多项目都栽过跟头。
3. 进阶RAG：把检索链路每一环打磨到极致
当朴素RAG的瓶颈开始制约业务效果，就进入进阶RAG阶段。这个阶段的总体思路很清晰：在“检索前、检索中、检索后”三个环节分别做精细加工，让每一次检索都更准、更聪明、更有依据。
3.1 查询端改造：改写、扩展与假设性文档
查询端优化的目标是解决“用户表达和文档表达不一致”的问题。最简单的方案是查询改写，让大模型把用户原始问题改写成更适合检索的形式。比如用户问“这个平台的登录流程怎么走”，改写后变成“平台用户登录流程步骤说明”。改写这个动作可以把口语变得书面化，把省略的上下文补全。
更进一步的做法是查询扩展，生成多个不同角度的相关查询，分别去检索，然后把所有结果合并再去重排序。效果上很像搜索引擎里“相关搜索”的思路，能显著提升召回覆盖面。代价是增加了检索次数和延迟，适合对覆盖要求高、对速度要求不极端的场景。
还有一个我经常用且效果不错的方法叫假设性文档嵌入（HyDE）。思路是先让大模型基于用户问题生成一个“假设性回答”，然后拿这个回答的向量去检索，而不是拿问题本身的向量去检索。为什么这样有效？因为假设性回答通常比问题长，包含了更多和文档写法接近的术语和表述，它的向量更容易命中知识库里的相关片段。
查询端的改造要注意一个度：不要过度改写。有次我接一个客户的项目，查询改写模块把“发票怎么开”改写成了“关于企业发票开具流程以及税务合规相关说明”，结果召回的片段全是税法条文，用户真正想要的操作步骤反而没排进前列。改写要以“保持原意不扩大范围”为标准，宁可保守一点。
3.2 检索端升级：混合检索与重排序
检索端的第一个优化方向是混合检索。纯向量检索擅长语义匹配，但对精确词、专有名词、编号这些信息不敏感。比如用户输入“报错编号ERR-2048”，语义相似的文本很多，但真正包含“ERR-2048”这个精确串的文档只有一份，向量检索未必把它排到最前面。
所以把稀疏检索（比如BM25这种基于词频和逆文档频率的经典算法）和稠密向量检索结合起来，是一个很有效的兜底策略。稀疏检索负责精确匹配，向量检索负责语义泛化，最后把两路结果合并。合并时常用的方法是加权归一化组合，我给个参考：准确匹配场景下，BM25的权重可以给到0.3到0.5；语义泛化为主的场景，向量检索权重更高。这个比例没有定式，需要你在验证集上多试。
检索端的第二个优化方向是重排序（Rerank）。向量检索的第一阶段是“粗排”，目标是快速召回足够多的候选，精度上会有妥协。重排序阶段会用一个更强的模型把候选逐一精审，输出更可靠的打分。实现方法上，常用的是交互式深度模型，它会把查询和文档片段拼接成一对输入做模型推理，判断二者的语义相关性，比嵌入模型的双塔匹配方式更精确。
落地时我会把整个检索管道设计成两段式：第一段用向量加BM25快速召回50到100条候选，第二段用重排序模型筛到5到10条。这样既控制了响应延迟，又能把精度提上来。我自己实测，增加Rerank环节后，答案相关性往往会有肉眼可见的提升，这是进阶RAG里性价比最高的一步。
3.3 生成端优化：上下文压缩与精排出路
生成端的第一个优化方向是上下文压缩。重排序帮你筛掉了不相关的片段，但筛出来的片段本身可能很长，里面真正有用的话只有几句，直接全量塞进上下文既费Token又容易干扰模型。上下文压缩的思路，就是让一个轻量模型在把片段交给大模型之前，先压缩掉冗余信息，只保留与查询相关的内容。
压缩手段可以是抽取关键句，也可以是让语言模型重写相关信息。这里要特别提醒一句：压缩不要让原文的语义发生形变。我用过几套压缩方案，有的为了省Token把否定句压缩成肯定句，直接把答案带偏了。在工程上，宁可压缩得保守一点，也要保证信息真实性。
生成端还有一个容易被忽视的环节：提示词模板的细化。很多人直接拿“根据以下内容回答问题”当模板，其实可以做得更细：要求模型优先参考带具体来源标记的片段；多个片段互相矛盾时，要求模型指出矛盾并依据最新来源作答；回答中必须标注引用的片段编号；无法从片段中找到答案时，明确要求回答“知识库中未找到相关信息”，而不是强行编造。
这里就要提一下“上下文精准”的设计思路：把检索片段分割成若干证据块，每个证据块前加上来源标签，让模型明确知道每一段话出自哪个文档、什么章节。模型对这种“标注清楚的段落列表”的利用程度，明显优于一锅乱炖的大文本块。
3.4 进阶RAG的适用时机与落地建议
不要一上来就做进阶RAG，也不要永远停在朴素RAG。判断标准其实很简单：当你发现优化提示词已经不能提升回答质量，且错误主要来源于“检索不到”或“检索不准”时，就该进入进阶阶段了。
落地时我建议按顺序推进，不要三线并进。先用混合检索加Rerank解决“召回精排”，见效快、风险低；再上查询改写解决“表达不一致”，这一步要求你们先垫定了大模型调用的可用性；最后再考虑上下文压缩这类成本较高的优化，因为它的收益在某些场景下并不明显，尤其是上下文窗口充足的商用模型场景。
另外要留意，进阶RAG会引入更多模型调用，成本会上升。一次查询改写、一次HyDE生成、一次Rerank、一次最终生成，这些调用叠加起来，单次问题的处理成本可能是朴素RAG的2到4倍。做技术方案时，要把成本估算放进上线评估里，不要等到账单出来才发现扛不住。
4. 模块化RAG：从被动拼接走向自主决策
朴素和进阶RAG本质上还是一种“被动管道”——用户来一个问题，系统按固定套路检索、拼接、生成，不管问题难易、类型、是否需要多步推理。模块化RAG改变了这件事：把整个流程拆成可编排的模块，通过路由、规划、工具调用等手段，让系统在不同场景下选择不同的处理路径，甚至自主决定还要不要再查一次。这个演进方向，圈内也常把它叫作Agent化RAG。
4.1 路由机制：让系统知道该问谁
所谓路由，就是让系统在进入完整RAG流程之前，先判断当前问题应该走哪条处理路径。常见的路由维度有三个：知识库路由、流程路由和模式路由。
知识库路由解决“多库场景”下的选库问题。比如一个企业内部可能同时有技术文档库、规章制度库、产品手册库，用户提问时如果每次都把查询广播到所有库，除了浪费性能，还会引入大量噪声。路由模块可以先把问题分类，定向分发到最相关的库，甚至同时分发到两个库再合并结果。
流程路由解决“该不该用RAG”的问题。有些问题不需要检索知识库，比如“你好”“谢谢”这类寒暄，又比如大模型本来就会的常识问题；有些问题需要检索；还有些问题需要先检索再推理。路由模块可以基于分类或小模型打分来判断，避免所有请求都傻乎乎地去检索一遍。
实现路由的方式不复杂：最简单的可以用少量正则和关键词规则，稳但覆盖面窄；主流方案是专门让大模型做一次轻量分类，给定候选路径列表，让它输出应该走哪条；更精细的做法是用一个小的分类模型做意图识别，速度快、成本低，适合高频调用场景。我在实际项目里，路由模块通常是先规则后模型的组合：高频的简单问题走规则，长尾的复杂问题走模型分类。
4.2 查询规划与多步检索
路由只是第一步，更复杂的问题需要查询规划。想象一个用户问：“对比一下我们去年和今年的业务报表，主要差异在哪。”这一问题隐含了至少三步：先定位去年的报表文档，再定位今年的报表文档，最后还要把两者放进同一个上下文里做对比。朴素RAG做不好这件事，因为它在时间和空间上只有“一次性检索”。
查询规划的思路是让大模型先把复杂问题拆解成多个子问题，每个子问题独立检索，最后再汇总生成。拆解的动作可以由大模型自主完成，配合一个循环检查机制：先检索第一轮，判断信息够不够，不够就生成下一轮查询再检索。这就是“多步检索”的实现方式，很多框架里都能找到对应的抽象。
多步检索要特别注意两个工程问题：一是防止死循环，一定要给最大步数限制，比如最多检索3轮；二是需要保留每轮的检索结果和状态，方便模型在后续决策时知道“我已经查到哪些信息，还缺哪些信息”。状态管理做不好，系统会在原地打转，而且用户会明显感觉到响应时间暴涨。
我见过一个效果很好的多轮规划实现，它给模型暴露了一个“工具列表”，包括“搜索知识库”“阅读指定文档”“查找相似问题”等。模型每一步自主决定调用哪个工具、传入什么参数，系统把工具返回结果追加进上下文，再让模型决定下一步动作，直到它认为信息足够、开始写最终答案。
4.3 Agent化RAG的核心闭环
Agent化RAG是模块化RAG的高阶形态，也是现在业内讨论最多的方向。它把RAG从“管道”变成了“智能体”：系统不仅会检索，还会根据检索结果自主采取下一步行动，包括写代码、查数据库、调用外部API、做计算，然后带着这些新信息返回生成。
我理解的Agent化RAG核心闭环是这样的：感知（理解用户问题）——推理（拆解并规划路径）——行动（选择并执行工具，包括检索）——观察（解析工具返回结果）——再推理（判断是否完成或继续行动）——最终生成回答。这套闭环在实现上依赖两个基础能力：一是模型本身的规划能力，如果没有基础模型做支撑，多步规划很容易失控；二是外围工具的定义质量，工具描述写得清晰，模型才知道什么时候该用哪个。
当场验证过一段时间的经验是：给模型暴露的工具“贵精不贵多”。一次Agent对话里，工具数量超过六个，模型的选择错误率就会明显上升。宁可把同类能力封装成一个工具，也不要拆成五六个细粒度工具让模型选。另外，工具返回结果要有结构，最好直接给出JSON或表格，模型解析起来比读一大段纯文本轻松得多。
Agent化RAG对抗幻觉的能力比其他阶段强，但也有新的风险：因为模型在做决策时会调用越来越多的工具，如果其中的一个中间结果出错，整个链路都会带偏。所以在关键节点上加上“验证”动作很值得，比如让系统在回答前先自查：“我引用的结果是否都能回溯到某个工具返回中？”这个验证动作看似增加了成本，但能挡住大量低级错误。
4.4 模块化RAG的工程落地要点
模块化RAG在工程上和前面两档最大的区别，是你要开始设计“状态机”。朴素RAG和进阶RAG是线性的，模块化RAG是分支的、有循环的。建议做两件事：一是把所有模块间的输入输出统一成标准结构，比如统一的问题对象、检索结果对象、工具调用对象，这样模块之间可以自由插拔，调试也更方便；二是给每个调用补充完整日志和追踪ID，因为你根本无法靠观察终态判断一次复杂的多步调用里面到底哪一步产生了错误结果。
性能上，模块化RAG的响应时间通常比朴素RAG长，因为多了一步模型推理，甚至可能有多轮工具调用。为了不让用户体验断崖式下降，可以做“流式输出加思考过程可视化”——先把模型正在执行的动作以简短文案流式展示出来，比如“正在检索去年的业务报表”“正在对比两组数据”，用户知道系统没有卡死，体验会好很多。
成本控制上，模块化RAG最怕模型在不必要的时候反复调用工具。我发现一个有效的手段是给每个工具调用都设定“预期收益”约束：模型只有在判断某个工具能带来明确增量信息时才调用，否则直接输出。这本质上是在提示词层面强行压制“为了调用而调用”的行为。
5. 工程化落地：生产级RAG系统的最小清单
从技术验证跨到生产级，很多团队会栽在“重模型、轻工程”上。一个能稳定跑在生产环境里的RAG系统，不只靠好的模型，更靠数据管线、检索服务、评估体系和成本控制这些看得见摸得着的工程能力。
5.1 数据管线设计与更新机制
数据管道是RAG系统最容易“埋雷”的地方。一个生产级的文档加载流程，至少要包含解析、清洗、格式化、切分、向量化、索引、发布这几个步骤，每一步都要有独立的日志和错误处理。
全量重建是最稳妥也是最慢的更新方式，适合数据量小、更新频率低的场景。增量更新更适合知识库频繁变化的场景，但增量更新必须处理好“旧版文档的索引还在”“文档被删除后向量没有清除”这类问题。我见过太多系统因为只加不删，越跑越臃肿，最后检索结果到处是过期内容。
源数据格式规范越早统一越好。建议在入口处做格式约束，比如所有文档必须先转成HTML或Markdown再进入管道，PDF直接作为解析源很容易出问题。还要给每个文档块配上业务元数据，包括所属产品线、适用版本、生效日期、来源部门，这些字段后面做过滤、做权限控制都靠它们。没有元数据支撑的RAG系统，在业务层面基本不具备可审计性，这是企业落地时的硬门槛。
5.2 检索服务的高并发与低延迟设计
在实现层面，检索服务要关注三块：索引隔离、连接池和缓存。多个业务共用一个向量库时，不同业务的文档混在一起，最终检索会被相互污染，所以索引一定要按业务隔离，哪怕物理上共用同一容器，逻辑上也必须分开。
连接池配置在QPS上来之后就会成为瓶颈。向量检索的写入和查询都会占用连接，连接池太小会导致排队，太大又容易拖垮底层存储。建议从压力测试里反推目标值，我通常会在一个固定并发下压测不同连接池大小，找到延迟拐点，再留出1.5倍左右的余量。
缓存是降低检索成本最直接的手段。相似问题在短时间内被反复询问是很常见的，给查询加一层键值缓存，命中时直接把缓存结果返回，能省下大量的模型推理费用。缓存的粒度可以是最终答案，也可以是检索结果。前者省全部链路，但要注意答案的时效性；后者只省检索环节，更稳妥。对更新频繁的知识库，缓存时间要设短一些，比如5到10分钟。
5.3 评估体系：没有量化就没有优化
RAG系统上线后，最怕听到的反馈是“感觉回答变差了”，因为没有量化口径，谁都说不清差在哪。建议尽早搭一套离线评估管道和线上监控看板，把RAG质量量化出来。
离线评估围绕三个核心指标展开：上下文相关性（Context Relevance，判断检索到的片段是否真的与问题相关）、忠实度（Faithfulness，判断生成回答是否忠于检索片段、有没有编造）和答案相关性（Answer Relevance，判断回答是否切中提问原意）。这三个维度分开评测，能帮你快速定位问题在检索侧还是生成侧。
构建评测集时，不要只用文档里的现成问题，那会高估系统能力。建议整理一批用户真实问题，涵盖简单查询、多跳查询、否定查询、模糊查询等类型，并给每类预设预期结果。每次修改系统后，跑一遍回归评测，看三个指标的变化，就知道这次改动到底带来的是进步还退步。
线上监控可以采集用户对回答的点赞点踩、追问率、复制率等隐式反馈，再抽样做人工标注，形成一个持续的反馈闭环。这一步做得好的团队，RAG系统会越用越准，因为优化方向永远有数据支撑。
5.4 成本与延迟的平衡策略
生产系统逃不开成本。RAG的成本大头在三块：向量化、检索推理和生成推理。向量化是固定成本，一次文档更新就要重新嵌入，批量处理可以压价，但没法完全省。生成推理是最大变量，控制它最有效的办法是缩短输入长度，也就是回到前面讲的上下文压缩和精排。
延迟的瓶颈通常也在生成环节。一个简洁回答和一个冗长回答，生成耗时差距可能翻倍。如果业务对延迟敏感，可以在提示词里限制输出长度，或者把回答分两阶段：先让模型输出提纲确认，再生成全文。这里要提醒一句：延迟优化千万别以牺牲忠实度为代价，模型一旦为了省事开始胡写，前面所有检索优化都白费了。
6. 常见问题与排查技巧实录
最后分享一些实际项目和线上系统里经常踩到的问题。我按“检索质量、生成质量、性能稳定”三块整理成速查，每条都是遇到过、排过、解决过的，希望能帮你少走弯路。
6.1 检索质量类问题速查
| 症状 | 可能原因 | 排查建议 |
|---|---|---|
| 检索结果和问题语义完全不相关 | 嵌入模型选型不当，或领域词汇覆盖不足 | 替换更强领域适配的嵌入模型，评估后再决定 |
| 精确编号、型号、代码检索不到 | 纯向量检索对精确串不敏感 | 接入BM25稀疏检索做混合，提升精确匹配权重 |
| 检索结果相关但排在前面的片段很垃圾 | 没有做重排序，粗排结果直接进上下文 | 加Rerank环节，先粗召回再精排 |
| 检索结果总是偏向某个旧版本的文档 | 文档版本元数据没有参与过滤 | 在检索前按生效日期、版本号等元数据过滤 |
| 相似问题第一次检索准确，后续变差 | 缓存命中过期内容 | 缩短缓存有效期，或对过期索引做清理 |
6.2 生成质量类问题速查
生成质量问题里，最头痛的是幻觉。排查思路固定是这样的：先看回答内容能不能在检索片段里找到依据，找不到，就是生成侧的问题；能找到但表述不一致，就是模型理解和改写的问题。
如果回答可以回溯依据但逻辑混乱，大概率是检索片段之间自相矛盾。解决办法是在提示词里要求模型发现矛盾时直接说明，并以“写入时间更新”或“文档版本更高”的片段为准。如果回答可以回溯依据但语气生硬、像在复述原文，可以调整提示词要求“用自己的话回答，但保留所有关键事实”，效果立竿见影。
还有一个很容易被忽视的生成质量问题：回答了一堆正确但没有用的内容。这不是模型的问题，是检索片段没抓住用户真实意图。用户问“怎么申请退款”，你检索回的是“退款政策总则”，里面十条规定，模型全部回答了一遍，但用户只想知道“申请入口在哪”。这类问题要回到查询改写阶段去处理，把用户问题更准确地定位到“操作流程”这个意图上。
6.3 性能与稳定性类问题速查
| 症状 | 可能原因 | 排查建议 |
|---|---|---|
| 响应时间突然变长 | 向量检索并发飙升，或生成环节输入过长 | 增加缓存，检查连接池上限，压缩上下文 |
| 文档更新后检索结果还是旧的 | 增量索引未触发，或旧数据未清理 | 检查索引流水线是否正常执行，做全量校验 |
| 多轮对话中，后轮问题检索不准 | 没有结合历史对话，问题指代无法消解 | 把前几轮问答的摘要加入查询改写输入 |
| 调用成本飙升 | 多步规划里模型频繁做无效工具调用 | 给工具调用加“预期收益”约束，限制最大步数 |
| 偶发返回空结果 | 查询被改写后超出知识库范围 | 改写模块加范围校验，不必要时保持原问题 |
6.4 三个我测试后很抵触的坑
第一个坑：盲目追求大块上下文。有些同学喜欢把能塞的都塞进上下文，觉得模型能自己挑重点。实测下来效果反而差，大量无关文本会稀释模型的注意力，把它带进沟里。检索的终极目标不是“塞满”，而是“精准”。
第二个坑：直接照搬别人的切分参数。很多开源示例里默认的chunk_size未必适合你的文档，不同的领域、不同的文档结构，最优值差别很大。我习惯每拿到一个新知识库，先抽样查看切分结果，再决定参数方向，而不是盲信默认值。
第三个坑：过度依赖“更强的大模型”来兜底。模型能力确实能掩盖一部分检索问题，但掩盖不是解决。换一个更聪明的模型可能会让Demo效果大幅提升，但到了生产规模，检索架构的缺陷依然会在长尾问题里不断暴露。先修检索链，再考虑升级模型，这个顺序别搞反了。
我自己也是从朴素RAG一路踩过来的，最大的体会是：RAG不是靠某一个惊艳组件赢的，而是靠整条链路上的每一个环节都“不掉链子”。把文档解析、切分、向量化、检索、精排、生成、评估每一段都理顺，系统就会稳定地好用。后续如果你想继续深入，可以把评估工具和Agent框架这两块作为扩展方向，它们会让你的RAG系统在“准”之外更加“聪明”。
