大厂RAG检索链路揭秘：混合检索、Rerank与查询改写实战

1. 纯向量检索在真实业务里到底卡在哪

很多人第一次搭 RAG，脑子里默认的链路就是：文档切块、embedding、塞进向量库、用户提问时算相似度、取 Top-K 丢给大模型。跑通 Demo 那一刻确实很爽，问什么都能扯出点相关内容。但只要文档量上到几万块、问题稍微绕一点，你就会发现召回结果开始"飘"——明明库里躺着标准答案，检索出来的却是几段语义相近但答非所问的废话。

这不是你 embedding 模型选得差，而是纯向量检索这套机制本身有天花板。我先把它的几个硬伤摊开讲清楚，后面才知道大厂为什么要费劲去叠别的检索手段。

1.1 语义相似不等于答案相关

向量检索的本质是把文本压成一个高维点，然后比谁离得近。问题在于，"语义相近"和"能回答问题"是两码事。

举个我踩过的例子。库里有这么一段："设备重启的标准流程是先保存配置，再执行关机指令，等待指示灯熄灭后重新上电。"用户问的是"设备重启前要做什么"。向量检索很可能把"设备关机后如何重新上电"这种语义高度重叠的段落排到前面，因为两段话都在讲"重启"这个主题，向量距离很近。但用户真正要的是"保存配置"这个前置动作，检索却给了一段讲上电流程的内容。

纯向量模型学的是"整体语义分布"，它分不清一段话里哪个词是答案锚点。当问题里的关键约束（比如"前""之前""前置"）落在细节上时，向量相似度根本抓不住。

1.2 关键词精确匹配是向量的天然盲区

向量检索对专有名词、编号、型号、代码标识这类东西特别不敏感。

我做过一个内部知识库，里面有大量形如"错误码 E5021""接口 v3.2.1""批次号 B-2024-07"的内容。用户直接搜"E5021 怎么解决"，纯向量检索经常召回一堆讲"常见错误处理"的泛泛段落，就是命不中那个精确的错误码。原因很简单：embedding 模型在训练时见到的"E5021"这种 token 极少，它压根没学会把这个字符串当成一个有区分度的信号，压出来的向量和"错误码""报错"这些通用词挤在一起。

而 BM25 这类基于词频的检索，遇到"E5021"就是精确命中，一个字符都不差。这就是为什么大厂的检索层里，稀疏检索（关键词）和稠密检索（向量）几乎是标配组合，而不是二选一。

1.3 Top-K 的"K"是个玄学

纯向量检索必须定一个 K，取前 K 个块。K 太小，答案可能压根没进候选；K 太大，噪声块涌进来，大模型被带偏。

我实测过一个 5 万块的知识库，同一个问题，K=3 时召回率只有 60% 出头，K=10 时召回率上到 85%，但精确率掉得厉害——10 个块里可能只有 2 个真正相关，剩下 8 个是干扰。大模型拿到这 8 个干扰块，很容易"顺着噪声编"，答案质量反而下降。

问题的根子在于：向量相似度是一个连续的分数，没有一个天然的"相关性断崖"。你没法说 0.82 就一定相关、0.79 就一定不相关。而真实业务里，相关和不相关之间往往就是差那么零点零几。纯靠一个阈值卡，怎么调都是按下葫芦浮起瓢。

1.4 长文档切块把语义切碎了

RAG 绕不开切块（chunking）。一段完整的论述被切成 512 token 一块，块与块之间的逻辑关系就断了。

用户问"这个方案的风险点有哪些"，而风险点分散在三个相邻的块里，每块单独看都只是半句话。向量检索按块召回，很可能只命中其中一块，另外两块因为缺少上下文、语义不完整，向量表达偏了，没被召回。结果就是大模型只看到三分之一的风险点，答出来的东西残缺不全。

大厂处理长文档时，普遍会做父子块（parent-child chunk）或者句子窗口（sentence window）：检索用小块保证精度，召回后把小块所在的父块或前后窗口一起喂给模型，补回上下文。这套东西纯向量检索原生是不带的，得自己在工程上补。

把这四点串起来看，结论就很清楚了：纯向量检索是一个召回手段，不是一套检索系统。大厂不用它单打独斗，是因为真实业务对召回率和精确率的要求，单靠一个连续相似度分数撑不起来。

2. 混合检索：大厂检索层的第一块拼图

既然纯向量有盲区，最直接的思路就是把另一套互补的检索手段拉进来一起干活。这就是混合检索（Hybrid Retrieval），也是目前大厂 RAG 检索层最普遍的底座。

2.1 稀疏检索补的到底是什么

稀疏检索的代表是 BM25（以及它的各种变体）。它的逻辑和向量完全相反：不看语义，只看词。

BM25 的核心是两件事：词频（TF）和逆文档频率（IDF）。一个词在当前文档里出现得越多、在整个语料里出现得越少，它对这个文档的区分度就越高。所以"E5021"这种罕见词，IDF 极高，一命中就是强信号；而"的""是""如何"这种到处都有的词，IDF 接近零，几乎不贡献分数。

这套机制恰好补上了向量的三个盲区：

• 精确匹配：编号、型号、专有名词，一个字符不差地命中。
• 可解释：为什么召回这段？因为里面有"E5021"。向量检索你很难解释为什么召回某段。
• 零训练成本：不需要 embedding 模型，建个倒排索引就能跑，冷启动极快。

但 BM25 也有它自己的死穴：它不懂同义词和语义泛化。用户问"怎么让设备停下来"，文档里写的是"关机流程"，BM25 一个词都对不上，直接漏召回。这时候就得靠向量来兜。

所以你看，稀疏和稠密是互补的：一个管精确、一个管语义；一个怕同义改写、一个怕专有名词。把它们拼起来，覆盖面才完整。

2.2 两路召回怎么融合：RRF 为什么比加权求和更稳

混合检索的经典做法是：向量检索召回 Top-N，BM25 召回 Top-N，然后融合成一个最终列表。融合策略有两种主流思路。

第一种是加权求和：给两路分数各配一个权重，比如0.7 * 向量分 + 0.3 * BM25分。听起来简单，但坑很深——向量分和 BM25 分的量纲完全不一样。向量相似度通常在 0 到 1 之间，BM25 分数可能是 0 到 30 甚至更高，直接加权等于让 BM25 主导。你得先做归一化，而归一化又会引入新的偏差，调参调到怀疑人生。

第二种是RRF（Reciprocal Rank Fusion，倒数排名融合），这也是我更推荐、大厂更常用的方案。它压根不看分数，只看排名：

RRF_score(d) = Σ 1 / (k + rank_i(d))

其中rank_i(d)是文档 d 在第 i 路检索里的排名，k 是一个平滑常数（通常取 60）。这个公式的妙处在于：它把不同量纲的分数问题，转化成了统一的排名问题。一路排第 1 的文档贡献 1/(60+1)，排第 10 的贡献 1/(60+10)，天然可比，不需要任何归一化。

我实测下来，RRF 在大多数场景下比调好的加权求和还稳，而且几乎不用调参——k 取 60 是论文里的经验值，直接抄就行。唯一要注意的是：两路召回的候选集要足够大（比如各取 50），否则排名信息太少，融合效果打折。

2.3 一个能直接跑的混合检索骨架

下面这段是伪代码级别的骨架，思路清晰，换成任意向量库和任意 BM25 实现都能套：

def hybrid_retrieve(query, top_k=10, recall_n=50): # 第一路：稠密向量召回 dense_hits = vector_store.search( embed(query), top_n=recall_n ) # 第二路：稀疏 BM25 召回 sparse_hits = bm25_index.search( tokenize(query), top_n=recall_n ) # RRF 融合 scores = {} for rank, doc in enumerate(dense_hits): scores[doc.id] = scores.get(doc.id, 0) + 1 / (60 + rank + 1) for rank, doc in enumerate(sparse_hits): scores[doc.id] = scores.get(doc.id, 0) + 1 / (60 + rank + 1) # 按融合分排序取 Top-K fused = sorted(scores.items(), key=lambda x: -x[1]) return [doc_map[id] for id, _ in fused[:top_k]]

这段代码里有两个容易忽略的点。第一，recall_n要明显大于top_k，给融合留出腾挪空间；第二，两路召回最好并行发起，别串行等，否则延迟翻倍。生产环境里这两路通常是两个独立服务，用并发请求拉回来再融合。

2.4 混合检索也不是银弹

得说句实话：混合检索解决了"召回覆盖"的问题，但没解决"排序精度"的问题。它把相关文档捞进了候选池，但候选池里依然混着大量噪声，谁排前面谁排后面，RRF 给的是一个粗糙的融合排名。

用户问一个具体问题，候选池里可能有 30 个块，真正能回答的只有 3 个。混合检索能保证这 3 个大概率在池子里，但没法保证它们排在最前面。这时候就需要第二块拼图：重排序（Rerank）。

3. Rerank：把候选池里的噪声压下去

混合检索负责"广撒网"，Rerank 负责"精挑选"。这是大厂 RAG 检索链路里几乎不会省的一环。

3.1 双塔模型和交叉编码器的本质区别

要理解 Rerank 为什么有效，得先搞清楚它和向量检索用的模型有什么不同。

向量检索用的是双塔模型（Bi-Encoder）：query 和 document 分别独立编码成向量，然后算余弦相似度。因为是独立编码，document 的向量可以离线预计算并建索引，检索时只算 query 向量，速度极快。代价是：query 和 document 在编码阶段没有任何交互，模型不知道这段文档是要来回答这个 query 的，只能各自表达"我大概是什么意思"。

Rerank 用的是交叉编码器（Cross-Encoder）：把 query 和 document拼在一起送进模型，让它们在每一层注意力里充分交互，最后输出一个相关性分数。因为 query 和 document 深度交互了，它对"这段文档到底能不能回答这个问题"的判断精度，远高于双塔。

代价也很直接：没法预计算。每个 query 都得和候选池里每个 document 现算一遍，10 个候选就是 10 次前向推理。所以 Rerank 只能用在小候选集上——通常是混合检索召回 Top 50 到 100，Rerank 后取 Top 5 到 10 喂给大模型。

3.2 为什么 Rerank 能救回被向量漏掉的相关块

回到第 1 节那个"设备重启前要做什么"的例子。向量检索把"上电流程"排前面了，因为语义近。但交叉编码器把 query 和两段文档分别拼起来看：

• query + "重启前保存配置" → 模型看到"前"和"保存配置"的强关联，打高分。
• query + "关机后重新上电" → 模型看到 query 问的是"前"，这段讲的是"后"，打低分。

交叉编码器能捕捉到这种细粒度的逻辑关系，而双塔的向量表达早就把"前""后"这种词淹没在整体语义里了。这就是 Rerank 的价值：它把"语义相近"和"能回答问题"这两件事重新对齐了。

3.3 Rerank 的工程代价与取舍

Rerank 好用，但不是没有成本。我列几个实际部署时必须权衡的点：

实际取舍通常是：混合检索召回 50 到 100 个候选，Rerank 压到 5 到 10 个。候选数太少，Rerank 没东西可挑；太多，延迟扛不住。这个区间是延迟和精度的平衡点，我试过 30 和 200 两个极端，前者召回不够、后者延迟爆炸，50 到 100 最舒服。

还有一个容易被忽略的点：Rerank 模型要选对语言和领域。通用多语言 Rerank 模型在中文技术文档上，效果往往不如一个在中文语料上微调过的小模型。别迷信"参数越大越好"，一个 1 亿参数的中文专用 Rerank，经常打得过 5 亿参数的通用模型。

3.4 没有 GPU 时的降级方案

不是所有团队都有 GPU 资源跑 Rerank。这时候有几个降级思路：

• 用轻量级 Rerank 模型：有些小模型能在 CPU 上跑到可接受的延迟，精度比双塔高，比大模型低，是个折中。
• 用 LLM 做 Rerank：让大模型对候选块逐个打分或排序。精度不错，但延迟和成本都高，只适合低并发场景。
• 规则 + 特征重排：不跑模型，用关键词命中数、块位置、时间新鲜度等特征加权排序。粗糙，但在某些垂直场景（比如 FAQ）够用。

我个人的经验是：如果业务对精度敏感，Rerank 的 GPU 成本该花就花，它带来的答案质量提升，远比省下的那点算力值钱。

4. 查询改写：在检索之前先把问题问对

前面三节讲的都是"检索侧"的优化。但很多时候，召回不准的根子不在检索，而在用户的问题本身就没问好。大厂 RAG 在检索之前，还有一层经常被忽视的功夫：查询改写（Query Rewriting）。

4.1 用户的问题为什么天然不适合直接检索

真实用户的提问，和知识库里的文档，语言风格往往对不上。

用户问："那个新功能咋用啊？"——"那个""新功能""咋用"全是模糊指代，向量和 BM25 都抓不住重点。而文档里写的是"XX 模块的配置步骤"。这两者之间的语义鸿沟，靠检索算法是填不平的。

再比如多轮对话场景。用户第一轮问"这个接口怎么调"，第二轮问"那它的超时呢"。第二轮的"它"指代什么？如果直接把"那它的超时呢"丢进检索，召回的全是无关内容。必须先把"它"还原成"XX 接口"，检索才有意义。

4.2 几种主流的查询改写手法

大厂常用的查询改写有这么几类，我按复杂度从低到高排：

第一类：指代消解和省略补全。把多轮对话里的"它""这个""那个"还原成具体实体，把省略的主语补上。这一步通常用一个轻量 LLM 做，输入是最近几轮对话，输出是一个自包含的完整问题。

第二类：查询扩展（Query Expansion）。给原问题补充同义词、相关词。比如"设备重启"扩展成"设备重启 关机 上电 重启流程"。扩展后的 query 同时喂给向量和 BM25，召回覆盖面更广。但要注意别扩太狠，扩进来的词太多会引入噪声。

第三类：查询分解（Query Decomposition）。复杂问题拆成几个子问题分别检索。比如"对比 A 方案和 B 方案的优缺点"，拆成"A 方案的优缺点"和"B 方案的优缺点"两路检索，再把结果合并。这样每个子问题的检索目标更聚焦，召回更准。

第四类：HyDE（Hypothetical Document Embeddings）。这个思路很巧妙：先让 LLM 根据问题编一个假想的答案文档，然后用这个假想文档的向量去检索。因为假想文档和真实文档在语言风格、用词上更接近，向量距离更近，召回效果往往比直接用问题检索好。代价是多一次 LLM 调用。

4.3 查询改写不是越多越好

这里有个反直觉的经验：查询改写做过头，反而会伤害检索。

我早期做过一个激进的改写策略，每个 query 都扩展出五六个变体，全部并行检索再融合。结果召回率是上去了，但精确率掉得厉害——扩展出来的变体里混进了大量语义漂移的内容，把真正相关的块挤下去了。

后来我收敛到按需改写：简单问题不改写，多轮对话做指代消解，复杂问题做分解，专有名词多的场景做扩展。改写的触发条件用规则判断，而不是无脑全上。这个策略下，检索质量比"全量改写"稳得多。

还有一个坑：改写会引入延迟。每次改写都是一次 LLM 调用，几百毫秒起步。如果检索链路本来就紧，改写会把总延迟推高。所以改写要么异步预生成，要么用极小的模型，别用大模型硬扛。

5. 上下文组装：检索对了，还得喂对

检索链路走完，拿到 Top-K 个块，很多人就直接拼起来丢给大模型了。但怎么拼、拼多少、按什么顺序拼，对最终答案质量影响巨大。这是大厂 RAG 里最容易被低估的一环。

5.1 块的数量和顺序都有讲究

先说数量。不是召回越多越好。大模型的上下文窗口虽然大，但有效注意力是有限的。塞进去 20 个块，模型很可能只认真看了前几个，后面的当背景音。而且噪声块越多，模型被带偏的概率越大。

我实测的经验值是：3 到 8 个高质量块，比 15 个混杂块效果好。宁可少而精，不要多而杂。

再说顺序。有个著名的现象叫"Lost in the Middle"：大模型对上下文开头和结尾的内容记得最牢，中间部分容易被忽略。所以组装时要把最相关的块放在开头和结尾，次要的放中间。这个技巧不需要改模型，纯靠排序就能提升答案质量，性价比极高。

5.2 给每个块加上"身份标签"

裸拼块有个问题：模型不知道每段话从哪来、是什么角色。加上来源和标题，模型能更好地判断这段话的权威性和适用范围。

我常用的格式是这样的：

[来源：设备运维手册 / 第 3 章 重启流程] 设备重启前必须先保存当前配置，否则未落盘的参数会丢失。 [来源：设备运维手册 / 第 5 章 上电流程] 重新上电后，指示灯由红转绿表示自检通过。

这样模型看到"重启前"的问题时，能明确知道第一段来自"重启流程"章节，权威性高，优先采信。而如果只给裸文本，模型得自己猜哪段更相关，容易猜错。

5.3 冲突信息的处理策略

真实知识库里经常有互相矛盾的内容：旧版文档说"按 A 操作"，新版文档说"按 B 操作"。检索把两段都召回了，模型该听谁的？

大厂的常见做法是在组装阶段做冲突消解：给每个块带上时间戳或版本号，组装时优先保留最新版本，或者显式告诉模型"以下内容存在版本差异，请以最新版本为准"。如果做不到自动消解，至少要把版本信息透传给模型，让它自己判断。

我踩过的一个坑：知识库更新后，旧块没删干净，检索同时召回新旧两版，模型各信一半，答出来的操作步骤是两版的缝合怪，根本没法执行。后来加了版本过滤，检索时只保留每个文档的最新版本，问题才解决。

6. 评估：没有度量，优化就是盲人摸象

讲了这么多优化手段，但如果没有一套评估体系，你根本不知道哪一步优化真的有效、哪一步是白费力气。大厂 RAG 和 Demo 的最大区别之一，就是有完整的离线评估 + 在线监控。

6.1 检索质量和生成质量要分开评

很多人评估 RAG 只看最终答案好不好，这是不够的。因为答案差可能是检索没召回，也可能是召回了但模型没用好。得拆开评。

检索侧指标：

• Recall@K：正确答案在 Top-K 里的比例。衡量"有没有捞到"。
• Precision@K：Top-K 里相关块的比例。衡量"捞得准不准"。
• MRR（平均倒数排名）：第一个相关块排在第几位的倒数平均。衡量"相关块排得靠不靠前"。
• NDCG：考虑排序位置权重的综合指标。

生成侧指标：

• 忠实度（Faithfulness）：答案是否完全基于检索到的内容，有没有编造。
• 答案相关性：答案是否切题。
• 上下文利用率：检索到的相关内容，模型用了多少。

这两组指标要分开看。如果 Recall@K 高但忠实度低，说明检索没问题，是生成阶段模型在瞎编；如果 Recall@K 本身就低，那再怎么调生成也没用，得回去优化检索。

6.2 怎么低成本搭一套评估集

搭评估集最费的是人工标注。我的做法是半自动构建：

1. 从真实用户日志里采样一批问题（100 到 200 条就够起步）。
2. 对每个问题，人工标注出知识库里哪些块是"标准答案来源"。
3. 用这套标注跑检索，算 Recall@K 等指标。
4. 生成侧用 LLM 当裁判（LLM-as-Judge），让一个强模型给答案的忠实度和相关性打分，人工抽检校准。

这套流程不需要标注"标准答案文本"，只需要标注"哪些块相关"，工作量小很多。而且 LLM 当裁判虽然不完全准，但相对比较够用——你优化前后跑同一套评估，分数涨了就是涨了，方向不会错。

6.3 在线监控看什么

离线评估管上线前，在线监控管上线后。我重点盯这几个信号：

• 检索命中率：用户问题有没有召回到任何块。如果大量问题零召回，说明知识库覆盖不够或检索策略有问题。
• 答案采纳率：用户有没有对答案点赞、有没有追问。追问率高往往意味着答案没解决问题。
• 延迟分布：P50、P95、P99 延迟。Rerank 和查询改写是延迟大户，要重点盯。
• 零结果率：检索返回空的频率。

这些信号能帮你快速定位问题出在链路的哪一环。比如零结果率高，先查知识库覆盖；延迟 P99 飙高，先查 Rerank 和改写。

7. 一套可落地的大厂级 RAG 检索链路

把前面所有东西串起来，一条完整的、接近大厂实践的 RAG 检索链路长这样：

用户提问 ↓ [查询改写] 指代消解 / 扩展 / 分解（按需触发） ↓ [混合检索] 向量召回 Top-50 + BM25 召回 Top-50 ↓ [RRF 融合] 合并成统一候选列表 ↓ [Rerank] 交叉编码器压到 Top-5~10 ↓ [上下文组装] 加来源标签 + 按相关性排序（首尾放最相关） ↓ [生成] 大模型基于上下文作答 ↓ [评估] 离线指标 + 在线监控

这条链路里，纯向量检索只是其中一路召回，而且是被融合、被重排、被组装层层加工过的。大厂不用纯向量，不是因为它没用，而是因为它只是整套系统里的一个零件。

7.1 不同规模团队的裁剪建议

不是每个团队都需要全套。我按规模给个裁剪建议：

• 个人项目 / 小团队：向量 + BM25 混合检索 + RRF 融合，先跑起来。Rerank 可以后加。
• 中等规模：加上 Rerank，加上基础的查询改写（指代消解）。评估集搭起来。
• 大规模 / 高要求：全套上，查询改写按需触发，Rerank 用领域微调模型，评估和监控体系完整。

关键是别一步到位。我见过太多团队一上来就想搭全套，结果每个环节都没调好，整体效果还不如一个调优的混合检索。先把混合检索 + RRF 跑稳，再逐个加环节，每加一个都用评估集验证有没有正向收益。

7.2 几个我踩过的坑，帮你省时间

最后分享几个实操里踩过的坑，都是文档里不会写的：

坑一：RRF 的 k 值别乱调。k=60 是经验值，我试过 10 和 100，效果都不如 60。这个参数对结果不敏感，别在这上面浪费时间。

坑二：Rerank 的候选数不是越多越好。我试过召回 200 个再 Rerank，延迟翻了三倍，精度只涨了一点点。50 到 100 是甜点区。

坑三：查询改写要防死循环。改写后的 query 如果又触发了改写条件，会无限循环。加个改写次数上限，最多改一次。

坑四：上下文组装别超过模型的有效注意力范围。不同模型的有效范围不一样，得实测。我的经验是，超过 8 个块之后，边际收益急剧下降。

坑五：评估集要定期更新。业务在变，用户问题在变，半年前的评估集可能已经不代表当前分布了。我一般每季度重新采样一批问题补充进去。

这套链路我前后迭代了大半年，从最初的纯向量 Demo，到混合检索，再到 Rerank 和查询改写，每一步都是被真实问题逼出来的。纯向量检索不是不能用，而是它撑不起真实业务对召回率和精确率的要求。把它当成一个零件，放进完整的检索系统里，它才能发挥该有的价值。