RAG优化

核心洞察

这篇文章最有意思的点，是它把 RAG 优化从“加工具”换成了“做诊断”。没有让你把 Rerank、混合检索、查询改写全堆上去，而是先问一句：你哪一环真的弱？对新手来说，这个判断顺序比收藏一堆技巧更值钱。

核心结论

1. RAG 优化没有通用方案，必须先判断问题出在查询侧、检索侧还是上下文/生成侧，再决定采用对应的优化手段，而不是盲目堆砌 Rerank、混合检索等技巧。

2. 混合检索（向量检索 + BM25）配合倒数排名融合（RRF），是目前工程上最成熟的检索优化组合；它只增加一个 BM25 索引，成本低、覆盖面广，性价比最高，适合优先实施。

3. 重排（交叉编码器）只在“前 K 条召回率已足够、相关内容已捞回但答案仍不准”时才有价值；若前 K 条召回率本身很低，加重排也无法改善结果。

4. 父子块检索用小子块做索引、命中后把对应的大子块喂给模型，可以有效兼顾检索精度与上下文完整性，解决分块大小与信息完整度之间的矛盾。

5. 初学者优化应遵循“先建基线、先解决找不找得到、再解决找得对不对、一次只改一个变量”的理性顺序，以便量化效果并正确归因。

一、优化要对症下药

先得有个共识：RAG 优化没有灵丹妙药。“加个 Rerank 就好了”“换个更强的模型”这类话，听着省事，很多时候只是拿着锤子找钉子。

正确做法是先判断问题出在哪一环，再决定动哪里。优化手段按作用位置分三类：

• 查询侧：在用户问题进入检索之前做处理，让问题更容易被检索到。
• 检索侧：改善召回质量，让该被捞出来的内容别漏掉。
• 上下文/生成侧：改善最终喂给大模型的上下文，让模型更好地利用检索结果。

三类手段在链路里的位置大概就是上面这张图。具体机制有什么区别，一个个看。

二、查询侧优化

查询改写

用户的原始问法常常口语化，一个意思能有十种表达，直接拿去向量检索，效果碰运气。查询改写是在检索前让大模型先处理一遍：扩同义词、改表述、补上没说的条件，让改完的查询贴近知识库里的用词习惯。

比如用户问“这个合同能退吗”，改写成“合同解除条款、退款政策、合同撤销条件”，然后从这几个角度分别检索，覆盖面会明显好一点。

多角度查询

一个问题能拆成多个侧面时，就生成几个不同版本的查询，各自检索，合并去重。

“我们产品的服务等级协议是多少”可以展开成：

• 服务等级协议内容
• 故障响应时间
• 可用性承诺
• 赔偿条款

每路单独召回，最后合成一份候选列表。单路的漏检，可能被另一路补上。

三、检索侧优化

混合检索

向量检索擅长理解语义，但在人名、型号、法规编号这类精确匹配上，常常不如关键词搜索可靠。混合检索就是把两条腿都用上：向量检索和 BM25 同时跑，再用融合算法合并排序。最常用的是倒数排名融合。

倒数排名融合的思路不复杂。一个文档在两路结果里都排得靠前，融合分数就高；只靠一路撑着的，分数会打折。

元数据过滤

在向量相似度检索的同时，加上结构化条件。比如只看 2024 年之后的文档，只在合同类文档里搜，或者限定研发部门的内部规范。

这不改检索算法，但搜索范围变小了。精度提上去，计算量也能下来。

四、精排优化：重排

重排是 RAG 优化里被提得最多的手段，但它有自己特定的位置：向量检索召回了前 K 条候选之后，用一个交叉编码器对每个“查询和片段”配对重新打分，排序，只把真正相关的前 N 条拿给大模型。

向量检索编码查询和文档是分开算的，没法完整看到两者之间的交互。交叉编码器能直接看完整配对，打分自然更准。

混合检索加重排，是目前工程上最成熟的检索优化组合。两边各召回一批候选，用倒数排名融合进候选池，再经过交叉编码器精排，最后只有三到五条高质量片段进入上下文。

重排什么时候加：如果前 K 条召回率已经够好，相关内容确实被捞回来了，但最终答案还是偏，多半是重排缺失。相关内容在，但没有筛出最核心的部分。

重排不急着加：如果前 K 条召回率本身很低，该回来的根本没回来，加重排也没用。先把召回问题解决掉。

五、上下文侧优化

父子块检索

分块里有对经典矛盾：小片段向量更聚焦，匹配更准，但喂给模型时上下文不够完整；大片段上下文够了，检索精度又变差。

父子块拆成两级索引。用小子块去检索，命中之后，把包含这个小子块的大子块拿给大模型。检索精度和上下文完整性都顾到。

比如一篇两千字的文章按段落切成五个四百字的子块，拿子块做索引；一旦某个子块被命中，传给模型的是整篇文章，或者其中一个更完整的段落。

上下文压缩

召回来的片段里，经常混着一堆和当前问题无关的内容。可以用大模型先压缩一遍：让它读片段，把和查询高度相关的句子摘出来，丢掉无关信息，再把摘出来的内容拼成最终上下文。

噪声能少不少，但代价是多一次大模型调用的延迟和成本。场景对准确性要求极高、对延迟不那么敏感的时候，值得用。

六、初学者应该如何选择优化方向？

新手最容易犯的错是“什么都想加”。查询改写、混合检索、重排、父子块全上，系统延迟上去了，问题变复杂了，最后哪个环节帮了忙也说不清。

更理性的顺序是：

1. 先有基线，再做评估。 动手之前，先拿前 K 条召回率和答案质量指标（大模型打分或者人工评估都行）跑出一组可量化的基线。没有基线，优化效果无从判断。
2. 先解决找不找得到，再解决找得对不对。 前五条召回率很低的时候，先优化召回：换嵌入模型、调切分策略、加混合检索。这时候加重排是白费。
3. 一次只改一个变量。 切分大小、嵌入模型、重排，同时改两三样，出了问题根本没法归因。
4. 按成本收益排优先级。 混合检索只是多一个 BM25 索引，成本低、覆盖面广，性价比最高，适合先做。查询改写和重排会带来额外延迟和成本，得看业务能不能接受。

七、面试可能怎么问

问：你们 RAG 系统做了哪些优化？

按查询侧、检索侧、重排、上下文侧这个框架来答。说清楚每个优化在解决什么问题、改之前和改之后差多少、为什么做这个而不是那个。比如：“我们原先前五条召回率在百分之六十左右，先加了混合检索，升到百分之七十八；后面再加了重排，答案准确率提升了大约百分之十五。”有数字、有逻辑，比背概念强。

问：混合检索怎么实现？两路结果怎么融合？

向量检索用嵌入模型加向量数据库，关键词检索用 BM25，工程上可以用 Elasticsearch 或者向量数据库自带的关键词搜索。融合用倒数排名融合：把每个文档在两边结果里的名次取倒数相加，得到一个融合分，再按这个分数排序。倒数排名融合对超参数不敏感，实现简单，效果也稳定，工程上基本首选。

八、结语

RAG 优化是逐个组合、不断迭代的过程，不是一次性把所有手段堆齐。搞清楚每种手段解决的具体问题，先建评估体系，再优先动最卡脖子的环节。这样一路改下去，心里会有数。

常见问题（FAQ）

RAG优化从哪开始？

先别急着加工具，得先诊断问题出在哪一环。建一套基线评估，看前K条召回率和答案质量。如果召回率低，先优化检索侧，比如加混合检索；如果召回没问题但答案不准，再考虑重排或上下文优化。

RAG优化一定要加Rerank重排吗？

不一定。重排只解决‘相关内容召回但混着噪声’的问题。如果前K条召回率本身就低，该回来的没回来，加重排是白费。先看召回，再看精排。只有召回够了，重排才值得加。

混合检索和Rerank重排有什么区别？

混合检索是检索侧优化，用向量和BM25同时召回，再用倒数排名融合，解决漏召回问题。重排是精排优化，用交叉编码器对召回结果重新打分排序，解决召回内容不精准问题。两者侧重点不同，可组合使用。