在做 RAG（检索增强生成）系统时，很多新手最喜欢干的事就是天天调 LLM 的 Prompt：“你是一个资深专家……”、“请仔细阅读……” 调了半天，发现一旦问点偏门的问题，大模型还是在胡说八道。

为什么？因为你搞错了发力点。

你要弄明白一件事：检索召回的内容，就是整个 RAG 系统的天花板。 生成层做得再花哨，如果检索没把包含正确答案的文本（Chunk）找回来，大模型就是巧妇难为无米之炊。优化生成层只是锦上添花，而优化检索层，才是能从根本上提升系统智商、投入产出比最高的操作。

工业界是怎么做检索优化的？剥开各种高大上的论文，其实就是四个层次的递进：索引（存）、查询（转）、召回（找）、重排序（排）。

你可以把它想象成去仓库找东西：索引层决定「仓库货架怎么摆」，查询层决定「拿什么关键字去搜」，召回层决定「派几拨人从哪几扇门进去找」，重排层决定「把找出来的东西谁优谁劣理个排序」。

咱们一层一层往下扒。

---

第一层：索引优化（Indexing）—— 怎么“存”

如果知识存的姿势就不对，后面再怎么优化搜索都是白搭。在这一层，最大的工程痛点是“检索粒度与阅读粒度的天然矛盾”。

• 为了检索准，切块要小： 把一整页纸压成一个向量，语义太杂，一搜就容易丢。所以检索需要“小块（Small Chunk）”。

• 为了大模型能懂，切块要大： 你只给大模型一句没头没尾的话，它根本看不懂上下文。所以大模型阅读需要“大块（Large Chunk）”。

怎么破？核心黑魔法就四个字：小块检索，大块使用（Small-to-Big）。

1. 父子块分层（Parent-Child Chunking）

把文档切成两种尺寸。入库时，只给细粒度的“子块”建向量索引；检索时，用子块去精准匹配；命中之后，通过 ID 顺藤摸瓜把包含它的“父块（一整段或一整页）”拿出来喂给大模型。

类比： 就像查字典，你通过“拼音”（子块）极其精准地定位到了字，但最后拿给大模型看的是包含解释和例句的“整页纸”（父块）。

2. 摘要索引（Summary Index）

文档原文明明写了答案，但表述太啰嗦，导致向量距离很远。

做法： 离线建库时，先花点钱让 LLM 把这一大段话总结成一个精简的“摘要”。用摘要去建向量、做检索，命中后同样返回原始文档。摘要的语义高度聚焦，命中率奇高。

---

第二层：查询优化（Querying）—— 怎么“转”

索引建得再完美，C 端用户的提问往往是灾难级的。用户口语问“苹果手机咋截图”，知识库里正式的书面语是“iPhone 截图操作方法”，这俩的向量距离可能比你想象的要远得多。

所以，绝不能让用户的原始 Query 直接裸奔进数据库，必须在半路拦截，给它做个“整形手术”。

1. Query 改写与扩展（Rewrite & Multi-Query）

• 改写： 用一个小模型，结合上下文，把指代不明的“它为什么这么贵？”改写成“iPhone 15 Pro Max 定价偏高的原因是什么？”

• 多路扩展（撒网捕鱼）： 用户的提问角度可能跟文档对不上。让 LLM 把一个问题发散成 3~5 个不同角度的问法同时去搜。只要有一根鱼线钓到了正确答案，就算赢！

2. HyDE（假设性文档嵌入）—— “无中生有”的黑科技

这是极其惊艳的一招。问题和答案天然是两种文体，距离本来就远。

做法： 先让 LLM 凭着常识“瞎编”一段假设性答案，然后用这段【假设答案的向量】去库里搜。

类比： 就像抓嫌疑犯，直接拿一句描述去搜很难，但如果让画师先画一张“模拟画像”再去比对，准确率就爆表了。

3. Step-back Prompting（后退提问）

用户问得太细（比如“为什么 Transformer 的 Attention 要除以根号 d_k”），库里只有宏观知识，直接搜绝对搜不到。

做法： 让模型先往后退一步，生成一个高维问题（“Attention 机制的数学原理是什么”），把高维背景知识捞回来，再结合背景去答细节题。

---

第三层：召回优化（Retrieving）—— 从哪“找”

哪怕 Query 改写得再好，如果你只死磕“向量检索”这一条路，依然会死得很惨。

向量检索的致命盲区是：它懂语义，但瞎了眼不认识精准的型号词。

比如你搜“M4 Pro 芯片跑分”，向量模型可能会觉得“苹果最新处理器跑分”意思更近，反而把包含“M4 Pro”精准字符的记录给漏了。而传统的 BM25 关键词检索，偏偏最擅长找这种精确字符。

工程解法：多路召回（Multi-way Recall）

两条腿走路，一路跑向量检索（找意思相近的），一路跑 BM25（找字面重合的）。

⚠️ 带着泥土气息的坑：

两路找出来的东西，分数根本没法放一起比！向量分数是 0~1 的余弦值，BM25 是 TF-IDF 算出来的大几十的分数。怎么融合？

工业界标配解法：RRF（倒数排名融合）

别看分数，看排名！

公式很简单：$Score = \frac{1}{k + Rank}$。

你在向量排第 1，得一分；在 BM25 排第 2，再得一分。把各路算出来的排名分加起来重新排。这招不仅不需要训练，工程成本极低，而且能稳稳地把真正核心的知识顶到最前面。

---

第四层：重排序（Reranking）—— 谁“最配”

经过前面三层的狂轰滥炸，咱们可能捞回来了 20~30 个 Chunk。这时候绝不能全塞给 LLM！一是 Token 会把公司搞破产，二是会导致“中间迷失（Lost in the middle）”，模型会被满屏的废话搞晕。

必须引入一位极其严苛的 CTO——Rerank 模型（Cross-encoder 交叉编码器）。

为什么要再排一次？它和普通的向量检索有啥区别？

• 普通向量检索（Bi-encoder）： 问题算一个向量，文档算一个向量，比一下距离。就像 HR 扫一眼简历，只要带有“Java”关键词，全给你筛出来。速度极快，但不够细。

• Rerank 精排（Cross-encoder）： 它是把“问题+文档”一字不落地拼在一起，丢进深层神经网络里做逐字级的注意力比对。就像把候选人和技术主管关在同一个会议室里面试。极度精准，但极其耗时！

所以它的正确用法是：用前面飞快的召回层筛出 Top-30，然后让慢吞吞但准得可怕的 Rerank 模型给这 30 个重新打分，最后只掐尖留下最精准的 Top-3 喂给 LLM。

---

总结：你的 RAG 到底需要哪几层？

这四层优化，并不是非要全部堆在一起。在实际落地的企业项目中，你可以对照自己的痛点来抓药：

层次	解决的痛点	工业界落地建议
索引层 (存)	搜出来的东西要么太碎，要么太杂	墙裂推荐：把 Parent-Child 分层切块做成建库的标配。
查询层 (转)	用户的提问口语化、词不达意	视场景定：如果是 C 端客服，必加 Query 改写。
召回层 (找)	搜不到具体的专有名词、货号、人名	低投入高产出：BM25 + 向量双路召回 + RRF 融合，性价比无敌。
重排层 (排)	喂给大模型的废话太多，导致幻觉	绝对刚需：挂一个 BGE-Reranker 节点，是提升精度最立竿见影的手段。

大模型的智商再高，也怕没有好资料。不要总想着在大模型本身上“大力出奇迹”，把这 4 层防线（存得细、转得准、找得全、排得精）死死守住，你的 RAG 系统才能真正从一个玩具，变成不可替代的生产力工具。