RAG 检索调优：嵌入、混合检索与重排的取舍

2026-07-28

数据截至 2026-07，价格与限额以各官网为准。

RAG 答不好，绝大多数情况不是模型不够聪明，而是喂进去的那几段文本压根不对。检索段的调优顺序应该是：先补召回（让正确答案至少出现在候选里），再补排序（让它排到前面），最后才轮到换更大的嵌入模型或者更贵的生成模型——顺序反了，钱花出去了，指标却不动。

一个很常见的误解是”换个更强的嵌入模型，检索质量就上去了”。嵌入确实是旋钮之一，但它管的是”语义相近”这件事，而线上真实的用户提问里，往往带着具体的型号、编号、人名、缩写——这些恰恰是纯向量检索最容易糊掉的部分。把预算全押在嵌入上，往往换来一个”看起来更高级、实际召回率没变”的系统。

如果你还没搞清 RAG 的整体流程，可以先看 RAG 是什么？一文讲清给大模型外挂知识库的原理，这篇默认你已经把最简单的一条链路跑通了，只谈检索段怎么调。

一、先把检索拆成能分别调的四段

调优之前必须能定位。把检索链路拆开，一共是这四段：

查询处理：用户输入的原始问题怎么变成检索用的查询。包括改写、拆成子问题、抽取关键实体、补充上下文。
召回：从库里捞出一批候选。可以是向量召回、关键词召回，或者两者一起上。
重排：对候选重新打分排序，把真正相关的顶到前面。
组装：决定最终塞进提示词的是哪几段、按什么顺序放、要不要带上原文出处。

这四段的失败症状不一样，别混着治：

正确答案根本没出现在候选里 → 召回段的问题，换重排模型没有任何用，重排只能对已有候选重新排序，捞不回没捞上来的东西。
正确答案在候选里，但排在很后面被截断了 → 排序段的问题，这时候上重排才有意义。
候选和排序都对，但模型答歪了 → 组装或提示词的问题，跟检索无关。

所以第一件该做的事不是调参，是抽二三十条真实问题，人工标出”正确答案在哪个文档块里”，然后分别统计”候选里有没有”和”排第几”。这两个数字一出来，该修哪段就不用猜了。

二、嵌入模型：管语义相近，管不了精确匹配

嵌入的作用是把文本压成向量，让”公司年假怎么休”和”休假制度”在向量空间里靠近。它擅长的是同义改写、口语化提问、跨语言表达。

选嵌入模型时，值得关注的几点分别是：

是否支持中文。很多热门嵌入模型的中文表现和英文差距不小，务必用自己的语料实测，别看榜单结论。
向量维度。维度越高信息越细，但存储和检索开销同步上涨，规模大了这笔账很实在。
能否私有部署。语料敏感就只能选可本地跑的，这一条往往直接砍掉一半候选。
最大输入长度。它决定了你的分块上限，块切太长会被截断，等于后半段白存。

具体有哪些型号、各自维度多少，变动很快，以各项目官方文档当前版本为准，这里不列清单——列了大概率过几个月就是错的。

比嵌入模型本身更值得先调的，其实是分块策略。同一个嵌入模型，按固定字数硬切和按文档结构切，检索效果能差出一大截。原因很直白：硬切会把一个完整的规则切成两半，前半句在 A 块、后半句在 B 块，谁都答不完整。按标题层级、段落边界切，再让相邻块之间留一点重叠，这个改动成本极低，收益通常高于换模型。

三、混合检索：把关键词那一路补回来

纯向量检索的短板很具体：用户查”XT-200 的额定电流”，向量模型可能觉得”XT-100”和”XT-300”也差不多近。型号、工单号、法条编号、人名、英文缩写，这类”字面必须对上”的查询，传统关键词检索（BM25 这类稀疏检索）反而更稳。

混合检索就是两路一起召回再合并。实操上有几个点要注意：

合并方式。常见做法是按排名倒数加权融合，好处是不用把两路分数拉到同一量纲上；也可以直接给两路分数加权求和，但那样每换一次嵌入模型就得重新调权重，维护成本高。
两路的召回条数要放宽。召回阶段取的候选数应当明显大于最终喂给模型的条数，给后面的重排留出腾挪空间。召回就取三五条、还指望重排救回来，是本末倒置。
权重不是全局最优的。技术文档、法规条文这类术语密集的语料，关键词那一路该给更高权重；客服问答、口语化的用户提问，向量那一路更重要。同一套系统里如果两类语料都有，考虑分库分别配置。

还有一个常被忽略的旋钮是元数据过滤。很多”检索不准”其实是范围没框住——用户问的是今年的报销标准，库里三年的版本都躺着。在召回前先按部门、年份、文档类型过滤一道，效果往往比调半天参数还立竿见影。这也是选向量库时要看的能力之一：Qdrant 支持过滤、payload 索引与量化，第三方资料称其在 100 万以上向量规模下可做到 50 毫秒以内的检索（这是第三方基准口径，不是官方指标，具体性能以你自己的硬件和数据实测为准），部署上可以作为独立二进制运行，也可以跑在 Docker 容器里。向量库之间的取舍可以参考向量数据库怎么选？Qdrant/Milvus/Supabase 对比。

四、重排：最见效的一段，也是最贵的一段

重排模型（cross-encoder 这一类）和嵌入模型的工作方式不同：嵌入是把问题和文档分别编码再算距离，重排是把问题和候选文档拼在一起送进模型算相关度分。信息交互更充分，排序质量通常明显更好。

代价也很直接：

算不了预计算。嵌入可以离线批量算好存起来，重排必须在查询时对每个候选实时跑一遍，候选越多越慢。
它是链路上的额外一跳。用 API 版重排就多一次网络往返，自己部署就多一份 GPU 或 CPU 开销。
救不了召回。前面说过，重排只能对已有候选重新排序。召回段漏掉的内容，重排一样看不见。

所以重排的正确用法是”召回放宽、重排收紧”：召回阶段多捞一些，宁可混进噪声；重排阶段再把真正相关的挑出来，只留少数几条进提示词。如果你的延迟预算紧张，可以只对高价值场景开重排，或者做一个短路逻辑——当召回首条的分数已经明显高于第二条时跳过重排，这类小优化在实际业务里很实用。

诚实地说，重排是这几个旋钮里投入产出比通常最高的一个，但也不是万灵药。语料本身写得含糊、同一个问题在库里有三份互相矛盾的旧文档，重排排得再准也解决不了内容治理的问题。

五、调优顺序：靠评估集推进，不靠感觉

没有评估集的调优就是碰运气——今天觉得变好了，明天换个问题又崩了。推荐的推进顺序是这样：

建评估集。几十条真实问题加上人工标注的正确出处，这是最枯燥但收益最高的一步。别用模型自己造的问题，那些问题往往过于”标准”，测不出线上的脏输入。
修分块。按结构切、留重叠，看召回率有没有动。
上混合检索。补上字面匹配那一路，看那些带型号、编号的问题是不是好了。
加元数据过滤。把范围框准。
上重排。这时候召回率已经稳了，重排能实打实提升命中位置。
最后才考虑换嵌入模型或换生成模型。这两项成本最高、迁移代价最大，放在最后。

评估这一环可以在你已有的框架上加挂 RAGAS 这类评估工具，不需要为了评估另换一套框架。要提醒的是，自动化指标只能告诉你”哪一版更好”，判断”够不够上线”仍然要靠人工抽检。

六、框架能帮到哪一步

如果瓶颈明确在检索这一段——也就是要反复折腾嵌入、混合检索、重排——那么 LangChain、Haystack、Cognita 这一类可调的旋钮最多，适合当调优平台。这里有个第三方基准提到的取舍值得知道：LangChain 的 LCEL 语法能做复杂的查询重写，但相比 LlamaIndex 的直接检索会多出约 15% 到 20% 的延迟开销（第三方基准口径，非官方数据，实际以你的部署环境为准）。换句话说，灵活性是有成本的，做复杂查询改写值不值这个延迟，取决于你的场景对首字延迟有多敏感。

LlamaIndex 的取向不同，它的 RAG 专用原语更贴身，抽象层更薄，数据密集型的索引场景走它更顺手。两者的定位差异见 LangChain 和 LlamaIndex 的分工：一个广一个深。

顺带说一件容易被误判的事：如果你的检索怎么调都上不去，先回头看看文档到底解析对了没有。扫描版 PDF、财报、版式复杂的法律文书这类语料，传统文本解析器提取出来的文字本身就是乱的，后面调什么都是在垃圾上排序。这种情况该换的是解析环节——RAGFlow 强在深度文档理解，分块尊重文档结构，带版面感知解析，具体见 RAGFlow 强在哪？扫描件与复杂版式的文档理解；LlamaIndex 一侧的 LlamaParse 也是常见入手点。另外，如果你的语料是有链接关系的结构化内容，实体之间的跳转关系比文本相似度更重要，那走图检索（比如 RAGFlow 的 GraphRAG）会比在向量检索上死磕更对路。框架的整体选型逻辑可以看 RAG 框架怎么选？按瓶颈选，别按 star 数选。

七、说清局限

有几件事，检索调优是解决不了的，提前知道能省很多力气：

语料本身不全。库里就没有这条信息，检索再准也变不出来。这时候该做的是补内容，或者让系统老实回答”没查到”。
需要跨多篇文档做推理和汇总的问题。比如”对比这三个季度的变化趋势”，单纯提高检索质量帮助有限，通常要在查询处理段拆成多个子问题分别检索再汇总。
答案在表格或图里。这属于解析段的能力，跟检索无关。
同一问题在库里存在多个互相矛盾的版本。检索只会把它们都捞上来，怎么判断哪份有效是内容治理的活。

最后一句实在话：本文提到的延迟比例、检索耗时这类数字，来源都是第三方对比与基准，不同测试环境结论差异不小。它们适合用来建立方向感，不适合直接抄进技术方案当承诺，具体能力以各项目官方文档当前版本为准。

小结

检索调优的核心是先定位再动手：分不清是召回漏了还是排序歪了，任何调参都是碰运气。顺序上先修分块、再上混合检索补齐字面匹配、加元数据过滤框住范围、然后上重排，最后才考虑换嵌入模型。评估集是整个流程的地基，没有它就没法判断哪一版真的更好。框架层面，检索旋钮多的走 LangChain、Haystack、Cognita 这条线，但要接受灵活性带来的延迟代价；解析烂就回头修解析，别在向量检索上硬扛。承认边界同样重要——语料缺失、跨文档推理、内容矛盾，这几类问题得靠内容侧解决，检索段使不上劲。