在做 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 系统才能真正从一个玩具变成不可替代的生产力工具。