RAG（检索增强生成）入门的体验大概是这样的：
一个下午，你就能搭出一套能跑的原型：文档切片 → 调 Embedding API → 扔进向量库 → 接上 LLM，齐活。你会觉得"这不挺简单的吗？"
然后你开始真正用它。搜出来的东西牛头不对马嘴，明明库里有的内容就是找不到，用户问一句它答三句废话，问得稍微抽象一点就开始编。
这不是你的问题。 RAG 的入门门槛确实很低，但"能跑"和"能用"之间，隔着一整套优化管线。
RAG 的本质，不是"让 AI 更聪明"，而是让正确的信息在对的时机出现在对的位置。要做到这一点，靠的不是某一个环节的精彩，而是整条链路的配合。
这篇整理了我梳理的 20 种 RAG 优化方案，按一个请求的完整生命周期来拆，从数据怎么入库，到最终怎么把答案吐给用户。
先看一眼全流程
一个完整的 RAG 管线长这样：
优化不是说某一个环节做好了就行，它是整条链路上的事。每一个阶段的改进，都在给下一个阶段"减负"。
下面按五个阶段一个个拆。
一、数据入库：检索的"底座"，地基打不好后面全白费
这个阶段的目标一句话就能说清楚：让对的文档在对的时候能被找到。 入库时切得乱七八糟，后面检索再强也救不回来。
1. 语义分块：别再按字符数切了
很多入门教程教你"每 500 字切一块"。这就像把一本书每 10 页拆下来订成一册，刚好把完整论证拦腰截断。语义分块的做法是按句子、段落或 Markdown 标题来切，保证每一块是一个完整的逻辑单元。
一个完整的句子和一句被腰斩的话，检索效果天差地别。
2. 小块检索，大块喂给 LLM：一个很聪明的折中
把文档切成很小的片段做向量检索（小块精度高），但命中后把它所在的"整段大哥"调出来喂给 LLM。就像一个图书索引：你用关键词查到页码（小块），但真正读的是那一整页的内容（大块）。检索精度和上下文完整性，一个都不丢。
3. 元数据过滤：先粗筛，再细搜
存文档时顺手存上时间、作者、类型这些元数据。检索时先 WHERE 一下（"只要 2024 年以后的""只要 Python 相关的"），再做语义匹配。一个简单的条件过滤，就能把搜索范围从百万级缩到千级。省算力，还更准。
4. 摘要索引：让宏观问题先找到大方向
长文档被切碎后，用户问"这本书讲了什么"时，任何一个片段都答不上来。
解决方案：入库前先让 LLM 给每个长文档生成一个全局摘要，单独向量化。宏观问题命中摘要，再通过摘要和详细章节的关联顺藤摸瓜找到细节。先给方向，再给细节。
5. 图增强 RAG（Graph RAG）：不只搜"内容"，还搜"关系"
把文档里的实体和关系抽取出来存进知识图谱。比如"函数 A 调用了函数 B""类 C 继承自类 D"。
检索时同时查向量库和图数据库。这是目前解决"跨文档逻辑关联"最火的方案。你想知道的不只是"这段话讲了什么"，还有"它跟别的东西是什么关系"。
6. 文档反向提问：提前帮文档"写考题"
入库前让 LLM 看着每一段文本，生成 5 个"如果有人要查这段内容，可能会怎么问"。把这些问题和原文绑在一起存入向量库。
相当于提前把所有可能的问法都做好了索引。 用户不管怎么换着花样问，命中率都会大幅提升。
二、检索前：用户的提问，不是最优的查询词
用户提的问题往往是口语化的、简略的、甚至歧义的。直接拿去搜，等于让一个口语问题去碰书面语文档，语义对不上是大概率事件。
7. 查询重写：帮用户把话"翻译"成检索语言
多了一步 LLM 调用，但省去了后续大量的试错。性价比极高。
8. 多路查询：一个问题，五个角度
把用户的问题扩展成 3-5 个不同角度的提问，分别检索，最后合并去重。
一个问法没命中的，另一个问法可能就命中了。用广度换精度。
9. HyDE：先"闭卷"写个假答案，再拿假答案去找真文档
这是我觉得最有意思的方法，没有之一。
不做"问题 → 答案"的检索。而是让 LLM 先凭空写一个假答案，然后把假答案向量化，去搜真正的文档。为什么这么做？因为"答案和答案"在向量空间里的距离，往往比"问题和答案"更近。 假答案内容虽然不对，但它的语义结构已经和真答案非常接近了。
用"假的"去找"真的"，这个思路本身就很有启发。
10. 查询路由：不是所有问题都该走向量检索
设计一个路由器，根据意图分发：
"今年第二季度的销售额是多少？" → SQL 数据库 "这段代码为什么报这个错？" → 向量库 "你好，今天天气怎么样？" → 直接给 LLM
把不适合的问题强行塞给 RAG，反而会出更多问题。先分类，再处理。
三、检索阶段：语义和关键词，各有各的盲区
这是你实际接触最多的阶段。核心矛盾很简单：语义搜索和关键词搜索，短板刚好互补。
11. 稠密检索：懂语义，不懂术语
基于 Embedding 的语义搜索。你搜"轿车"，它能找到"小汽车""私家车"。但遇到专业术语、缩写、代码函数名，它就懵了。
12. 稀疏检索：懂术语，不懂语义
基于 BM25 的关键词匹配。搜"OOM Killer"绝对不会把"内存不足导致进程被杀"漏掉。但它搜不到，是你表达方式不同导致的，而不是它不认识这个词。
13. 混合检索 + RRF：两条腿走路
把稠密和稀疏的结果用 RRF（倒数排名融合） 算法合并。两种方法的盲区刚好互补：
语义和关键词，一个都不能少。
14. 微调嵌入模型：让你领域的话不再"听不懂"
通用 Embedding 模型对你的私有领域理解不好？用自己的数据微调一次。比如你拿内部代码文档去训 BGE，它就能理解你项目中那些特有的函数名和术语。
四、检索后：最容易被忽视，但提升空间最大
很多人觉得检索完了就完了，直接把 top_k 结果塞给 LLM。但检索出来的东西往往有噪声、有重复、有废话。不处理就直接喂，等于让 LLM 在垃圾堆里找宝贝。
15. 重排（Reranking）：关键时刻的"双保险"
这是整个管线里性价比最高的一项优化。
向量检索为了快，用的是"双塔模型"：查询算一个向量，文档算一个向量，然后比夹角。很快，但精度有限。
重排模型用的是 Cross-Encoder，把查询和文档拼在一起逐字比对，精度高很多，但慢。所以实践中只对初筛出来的 top 20 做重排就够了：
召回对不代表排序对。重排就是那个帮你把真正有用的东西排到第一位的"二次把关"。
16. 上下文压缩：帮 LLM 划重点
检索出来的文档段落可能很长，里面混着大量无关内容。用 LLMLingua 之类的工具把废话剔除，留核心信息。
既省 Token，又降低 LLM"分心"的概率。
17. MMR：搜出来的东西别全是同一句话
检索出 5 段文本，结果 4 段说的是同一回事，上下文窗口被白白浪费。
MMR（最大边际相关性）保证结果既相关又多样。同一件事，一句说清楚就够了，剩下的位置留给不同的角度。
五、生成阶段：有了好材料，还要学会"好好说话"
材料对了，最后一步就是让 LLM 不乱说。
18. Prompt 工程：给 LLM 戴上紧箍咒
在 System Prompt 里加一句话，效果立竿见影：
"请严格基于提供的 Context 回答。如果 Context 中没有相关信息，请直接说'根据现有资料无法回答'，不要编造。"
一句话能挡住大量幻觉。 成本几乎为零，效果显著，这是所有优化里性价比最高的一项。
19. 自我反思：答完之后回头看一眼
让 LLM 生成答案后再多跑一步：检查一下自己说的内容是否确实来自给定的上下文。如果没有，打回重写。
在关键业务场景下，这个额外的验证步骤尤其值得。 宁可多花几秒，也别让一个幻觉毁掉用户的信任。
20. 引用溯源：企业级 RAG 的标配
让模型在回答里标注来源，像论文一样 [1][2]。
这不只是为了让用户能验证。更重要的是，当模型知道自己的每句话都要"对得上账"时，它会回答得更谨慎。
按场景选方案，别贪多
没有人会一次性把 20 种全用上。根据场景选 3-5 种组合，效果通常就够好了：
通用知识问答
语义分块 → 混合检索 → 重排
企业私有文档
元数据过滤 → Graph RAG → 引用溯源
代码库问答
查询重写 → 稀疏检索 → 重排
长文档分析
摘要索引 → MMR → 上下文压缩
写在最后
正如开头所说：
RAG 的本质不是"让 AI 更聪明"，而是"让正确的信息在对的时机出现在对的位置"。
这让我想到一个类比：RAG 像一个好的图书馆管理员。不是把全馆的书堆在读者面前说"你自己翻"，而是在读者开口之前就理解他的意图，从百万藏书中精准抽出那三页最相关的内容，放在他面前，并标好出处。
另一个感受是：很多看起来"高级"的方案，解决的其实是同一个问题：语义鸿沟。 用户表达的是一个意思，文档里写的是另一个说法，向量模型理解的是第三种语义。HyDE 用假答案搭桥，混合检索用关键词兜底，重排用双保险验证。手段不同，目标一致。
所以优化 RAG 不需要追求"把所有方案都用上"，而是理解你的场景里语义鸿沟最大的一环在哪里，对症下药。
记住这五条就够了：
入库打好地基：语义分块比字符切分好一百倍；小块检索 + 大块投喂是黄金组合 检索前帮用户"翻译"：查询重写 + HyDE 假答案搭桥，是缩小语义鸿沟的关键 检索时两条腿走路：稠密 + 稀疏混合检索，语义和关键词一个都不能少 检索后别偷懒：重排是性价比最高的优化，初筛 Top 20 → 精排 Top 5 生成时设好护栏：Prompt 加一句"不知道就说不知道"，比什么花哨方案都管用
不是所有场景都需要 20 种全上。理解你的语义鸿沟最大在哪一环，选 3-5 种对症的组合，就足够让一个"能跑"的 RAG 变成一个"能用"的 RAG。
