最早做 RAG 的时候，我把它想得太简单了。流程看起来很直接，把文档切块、向量化、存起来，用户提问的时候检索相关片段，拼到 prompt 里让 LLM 回答。十行代码的 demo 跑起来，效果还行，觉得这事儿就成了。
上线之后被现实打脸。用户问「怎么配置支付回调」，检索回来一堆和「支付」沾边但无关的文档，LLM 基于这些垃圾上下文一本正经地胡说。问「上周的运营数据」，检索到的是过期的旧文档。换个问法「回调失败了怎么办」，召回率又完全不同。
这些问题的根子是，demo 级 RAG 只有一级（直接检索），生产级 RAG 需要四级管线，每一级都在解决一类问题。这篇把这四级拆开讲。
第一级，查询改写，被低估的高杠杆点
图：查询改写将口语化、模糊的原始问题转化为适合检索的形式，召回率可从 40% 提升到 70%，是 RAG 最高杠杆的优化点。
很多团队直接拿用户的原话去做向量检索，效果差就怪模型不行或者向量算法差。其实问题往往出在最前面，用户的问法和文档的写法对不上。
用户口语化地问「回调挂了咋办」，文档里写的是「异步通知处理异常的重试机制」。语义上是一回事，但在向量空间里，这两句话不一定足够接近，召回就会漏掉关键文档。查询改写要做的，就是把用户的原始问题，改写成更适合检索的形式。
具体手段有几种。把口语改成书面语，把模糊的指代补全，把一个复合问题拆成多个子问题分别检索，再合并结果。更进一步的，是用 LLM 基于对话历史补全上下文，比如用户上一句在聊支付，这一句说「那个失败了怎么办」，改写时要把「那个」还原成「支付」。
查询改写是 RAG 效果优化的最高杠杆点。同样是检索引擎，改写前召回率可能只有 40%，改写后能到 70%。花的成本是一次额外的 LLM 调用，换来的收益是检索质量的质变。但很多团队跳过了这一步，直接在检索算法上死磕，方向就错了。
第二级，检索，召回率和相关率的平衡
检索这一级，目标是把可能相关的文档找出来。关键词是「可能相关」，因为这一级宁多勿少，漏掉了就彻底没机会了，多检索到的可以靠后面重排过滤。
向量检索是主流方案。把查询和文档都转成向量，算相似度，取最相似的 top K。这里有几个关键选择。
Embedding 模型决定效果上限。模型不理解你的领域术语，检索就差。通用模型（OpenAI 的 embedding、BGE 系列）对常见领域够用，专业领域（医疗、法律、内部黑话）可能要微调或换更好的模型。选 Embedding 模型之前，一定要在自己的数据上测召回率，别只看榜单。
切块（chunking）策略影响巨大。切太大，一个 chunk 里混了多个主题，检索精度下降。切太小，上下文不完整，LLM 理解不了。一般 200 到 500 字一块，有重叠窗口避免切断语义。文档的结构也要考虑，按段落、按标题层级切，比机械地按字数切好得多。
混合检索往往比纯向量检索好。向量检索擅长语义匹配，关键词检索（BM25）擅长精确匹配。把它们的结果融合（RRF 算法），能兼顾「意思相近」和「字面命中」，召回质量明显提升。
第三级，重排，从可能相关到真正相关
图：RAG 四级管线全景——查询改写、检索（RRF 融合）、重排（BGE-Reranker）、生成（强约束），每一级解决一类问题，重排可降级跳过。
检索回来 top 20 个 chunk，里面可能只有 5 个真正相关，其余是噪音。把全部 20 个塞给 LLM，噪音会干扰回答质量，还会浪费 token。重排这一级，就是从「可能相关」里筛出「真正相关」。
重排用的是更重的模型（比如 BGE-Reranker、Cohere Rerank），它对 query 和每个 chunk 做交叉编码，给出更准确的相关性分数。比 Embedding 的双塔相似度准得多，代价是慢且贵，所以只对检索回来的少量候选做，不对全库做。
重排的价值在「精准」。一个常见的配置是，向量检索召回 top 50，重排取 top 5 喂给 LLM。这比直接检索 top 5 效果好很多，因为重排模型的判断更准。
重排服务要么自托管（BGE-Reranker），要么调 API（要花钱）。资源紧张时可以先不上，靠 RRF 融合的检索结果也能用，只是精度差一截。等业务对答案质量有更高要求了，再加重排，投入产出比很高。重排是从「能用」到「好用」的关键一跳，但不是从零到一的必需品。
第四级，生成，约束 LLM 基于检索内容回答
图：生成级的 Prompt 结构——系统提示词定义约束、检索上下文明确标注、用户问题放在最后，三部分让 LLM 基于文档老实回答。
最后一级是把检索到的文档喂给 LLM 生成回答。这一级看似简单，其实有几个关键的工程问题。
最核心的是约束。必须明确告诉 LLM，「只能基于提供的上下文回答，上下文里没有的就说不知道」。不加这个约束，LLM 会混合自己的参数知识，可能答对，也可能幻觉出检索结果里没有的内容。加了这个约束，它至少不会无中生有。
Prompt 的结构要清晰。系统提示词定义角色和约束，检索到的上下文明确标出，用户的问题放在最后。让 LLM 知道哪部分是参考资料、哪部分是要回答的问题。
引用和溯源。生产级 RAG 应该让 LLM 在回答里标注信息来源，比如「根据文档 X，答案是 Y」。这有两个好处，一是让用户能验证，二是逼 LLM 老实，因为要标注来源，它就不太敢瞎编。
一个真实的四级管线长什么样
我自己落地的 RAG 系统，走的就是这套四级管线。查询进来先过改写（LLM 基于历史补全指代），然后向量检索（pgvector，768 维，RRF 融合向量加关键词），再过重排（BGE-Reranker，资源紧张时降级跳过），最后生成（带强约束的 prompt）。
几个落地的真实取舍。向量维度锁死 768，因为 Embedding 模型（gemini-embedding-001）输出 768 维，换模型等于全库重算，所以维度要在选型时就定死。重排做成可选，配置了就用，没配置就降级到 RRF，保证功能不挂。健康探测把 PG 和向量检索都纳进去，挂了能第一时间发现。
这些细节 demo 里都不会遇到，但生产环境里每一个都是坑。RAG 的难度不在第一级，在把四级串起来、处理好每级的降级和边界、让整个管线稳定跑起来。把每一级都做扎实，RAG 才从「能演示」变成「能用」。
