第 06 篇：RAG 混合召回策略：向量检索 + ES 关键词 + Rerank 重排

📚《向量检索与 AI RAG/Agent 落地实战》系列文章总目录

前置说明：本文为系列第 06 篇，不再重复 Embedding、向量检索基础、Chunk 分片等前文内容。聚焦单一向量召回天然缺陷，稠密向量 + 稀疏关键词混合召回架构、多路召回融合算法、Rerank 重排原理与选型、权重调优、工程实现、政务 / 智慧口岸业务场景落地，解决专有名词、编号、专业术语检索失效、语义漂移等 RAG 高频问题。

一、单一向量召回的固有短板

很多 RAG 项目 POC 阶段只使用纯向量检索，Demo 演示效果尚可；一旦接入真实业务知识库，会出现大量 BadCase。不少开发者会误以为是向量库或者 Embedding 模型不够好，其根源在于稠密向量检索本身存在无法规避的能力边界。

稠密向量检索擅长语义相似匹配，当用户提问表达方式和文档原文措辞不一样时，向量可以跨越字面差异找到相关内容。但它有明显短板：

专有名词、编码、编号精准检索能力弱 口岸业务存在大量固定编码：口岸代码、单证编号、审批文号、政策文件编号、设备编号。这类字符串是业务唯一标识，语义相似度很低，向量很容易发生混淆。例如用户检索 "策克口岸 2025 第 12 号通告"，向量检索可能召回主题相近、文号不同的其他通告，出现语义漂移。
长文本、细粒度事实召回不稳定 向量是对整段 Chunk 的整体语义压缩表征，文本内部包含多条独立事实时，向量会丢失细粒度信息。提问针对其中某一条具体条款，向量容易召回主题相关但事实不匹配的分片。
歧义问题 多义词、行业术语，在不同业务上下文含义不同。向量只看整体语义，无法区分术语在不同业务场景下的特定含义。例如 "查验" 一词，在货物通关、设备检测场景含义完全不同，纯向量检索容易跨业务召回无关文档。
冷启动新文档 新入库文档，Embedding 模型对新增专业术语理解不足，向量表征质量下降，短期内召回效果不稳定。

而传统关键词检索（Elasticsearch BM25）刚好反过来：字面关键词匹配极强，但是语义泛化能力差。用户换一种表达方式提问，缺少命中关键词就召回失败。

两者能力互补：稠密向量擅长语义泛化 ；BM25 稀疏关键词擅长字面、专有名词、编码精准命中。混合召回核心思路：多路并行检索，同时拿到向量召回结果与关键词召回结果，合并候选集，再使用 Rerank 重排模型做二次精细排序，过滤虚假相关分片，输出最终 TopN 送入大模型。

完整混合召回链路：用户 Query → Query 预处理（改写、扩展、抽取关键词）→ 并行执行【稠密向量检索】+【ES BM25 关键词检索】→ 多路结果融合（去重、打分合并）→ Rerank 重排模型精细化排序 → 截取 TopK 高质量上下文 → 送入大模型生成答案。

工程要点：多路召回阶段，需要放大召回候选数量。例如最终只需要 Top5 分片，向量检索召回 Top20，ES 检索召回 Top20，合并得到 40 条候选，交给重排模型筛选，保证高相关分片不会提前丢失。

二、两路召回：稠密向量检索与 ES BM25 稀疏检索

2.1 BM25 关键词检索原理简述

BM25 是 ES 默认的相关性打分算法。它基于词频、逆文档频率，计算 Query 关键词和文档分片之间的字面匹配分数。词在文档中出现越多、词在全局知识库越罕见，分数越高。 BM25 非常适合口岸、政务场景下面这些检索需求：

文件编号、文号、口岸名称、单证编码、法规条款号；
特定专有名词、设备名称、岗位名称；
用户直接复制文档原文段落进行检索。

ES 索引构建需要和向量库同步：文档解析分片之后，同一份 Chunk 文本，一份存入向量库生成向量用于稠密检索；一份存入 ES，构建倒排索引用于 BM25 关键词检索。两份存储分片 ID 一一对应，保证多路召回合并时可以关联同一条分片。

重要工程约束：向量库与 ES 的分片粒度必须保持一致。如果向量库按 800 字符分片，ES 按 1200 字符分片，同一个文档在两个系统分片边界不一样，分片 ID 无法对齐，多路召回结果无法合并，这是混合召回最容易踩的低级错误。

2.2 Query 预处理：多路检索的前置优化

同一个用户问题，送入向量检索和送入 ES 关键词检索的处理逻辑不一样。

送入 Embedding 做向量检索：使用完整原始 Query，保留全部语义，一般不做关键词裁剪。
送入 ES BM25 检索：对 Query 做关键词抽取，提取实体、编号、专有名词。例如用户提问：策克口岸 2025 年货物查验时限是多少？抽取关键词：策克口岸、货物查验、时限。可选增强策略：Query 改写、Query 扩展。针对政务场景，可基于同义词库扩展关键词，例如：查验、检验；通关、放行。

注意：Query 扩展不能滥用，扩展过多无关同义词会引入噪声，拉高 ES 召回无关文档数量，加重后续重排压力。

三、多路召回结果融合算法

两路检索分别返回各自候选列表，每条分片带有独立分数：向量相似度分数、BM25 相关性分数。但是两类分数值域、含义完全不同，不能直接对比。向量相似度是高维空间距离归一化结果；BM25 是词频统计分数。需要归一化之后加权融合。行业主流融合方案：

方案 1：分数归一化加权融合（最常用）

分别对向量召回列表、BM25 召回列表分数做 min-max 归一化，映射到 0~1 区间。
设置权重系数 α（向量权重）、β（BM25 权重），α + β = 1。综合得分 = α * 向量归一化分数 + β * BM25 归一化分数
根据综合得分重新排序，剔除重复分片。

权重调优经验（智慧口岸政务知识库）

通用业务问答：α=0.7，β=0.3，偏重语义理解；
编号、文号、单证查询场景：α=0.3，β=0.7，偏重关键词精准匹配；
混合场景：α=0.6，β=0.4，兼顾语义和专有名词。

权重不是固定值，可以做动态权重策略：自动识别 Query 是否包含编号、文件文号、实体编码；如果检测到编码类关键词，自动调高 BM25 权重。这是进阶优化手段。

方案 2： reciprocal rank fusion（RRF 倒数排名融合，推荐生产落地）

RRF 不需要对分数做归一化，只依赖每条分片在两路召回结果中的排名位置，鲁棒性更强。公式：\(RRF(rank) = \frac{1}{k + rank}\) k 一般取固定常数 60。同一条分片如果在向量召回排第 3，在 BM25 召回排第 5，则总分 = \(\frac{1}{60+3}+\frac{1}{60+5}\)。分片在多路结果排名越靠前，总分越高。

✅ RRF 优势：不需要关心向量分数和 BM25 分数量纲差异，调参简单，对不同检索器打分漂移不敏感；政务项目多路召回首选。 ❌ 缺点：完全不使用原始相关性分数，只依赖排名。如果一路召回整体质量差，仅靠排名融合会引入噪声。

方案 3：简单合并去重（仅适合 POC 原型）

向量 Top20 + ES Top20，合并，去掉重复分片，直接送入 Rerank，不做打分融合。实现最简单，但没有利用相关性分数信息，只适合快速验证效果，不建议生产环境。

四、Rerank 重排模型：多路召回之后的精细筛选

多路召回是扩大候选池，保证相关分片不漏掉，但候选集里面依然混杂部分伪相关分片。Rerank（重排模型）的作用：接收多路召回输出的候选分片列表，将用户 Query 和每一条 Chunk 成对输入模型，计算 Query 与 Chunk 之间真实相关性分数，重新排序。

核心区分：Embedding 模型是单文本编码 ，一次性把文本转为向量；Rerank 模型是交叉编码（Cross-Encoder），输入 Query + 分片文本成对，直接判断两者相关性，语义分辨能力显著强于 Embedding。缺点：计算开销更大，不能用于海量库全局检索，只适合对几十条候选集做二次排序。

4.1 Rerank 模型选型

BGE-Rerank 系列：国内最主流开源重排模型，中文效果优秀，支持私有化部署，支持鲲鹏 / 飞腾信创环境，政务、口岸项目首选。不同参数版本：BGE-Rerank-base、large，large 精度更高，算力消耗更大。
Jina-Rerank：海外开源，中文能力弱于 BGE 系列，国内项目较少选用。
商业 API 重排：云厂商 Rerank 接口，内网涉密项目不可使用。

4.2 Rerank 工程落地要点

候选集规模控制：多路召回合并之后，送入 Rerank 的候选数量建议控制在 20~50 条。候选太多，重排推理耗时上涨；候选太少，容易漏掉高相关分片。
截断策略：重排完成后，按相关性分数取 Top3~Top7 分片送入大模型上下文。Token 预算紧张场景减少数量；复杂业务问答场景适当增加。
分数阈值过滤：设置相关性阈值，低于阈值的分片直接丢弃。防止把相关性极低的内容送入大模型，减少幻觉来源。例如阈值设为 0.35，低于该分数直接剔除。
资源部署：Rerank 是推理密集型任务，高并发场景独立部署推理服务，不要和文档解析、向量查询服务共用算力。

4.3 混合召回 + Rerank 完整链路示例（口岸业务场景）

用户提问：策克口岸普通货物查验等待时间要求是什么？

Query 预处理：完整句子送入向量检索；抽取关键词【策克口岸、普通货物、查验、等待时间】送入 ES。
向量检索召回 Top20 语义相似分片；ES BM25 召回 Top20 命中关键词分片。
使用 RRF 融合排名，去重，得到 35 条候选分片。
BGE-Rerank 对 35 条候选做相关性打分排序，过滤分数低于阈值的分片。
选取 Top4 相关性最高分片，组装 Prompt 提交大模型。

对比纯向量方案：可以有效避免召回 "乌力吉口岸危险品查验" 这类语义相近，但实体不匹配的分片。

五、架构选型：Milvus 内置稀疏向量 vs 独立 ES

Milvus 原生支持稀疏向量 BM25 能力，可以在同一个向量库内同时存储稠密向量与稀疏向量，实现单库多路召回；也可以采用独立 ES + 向量库双组件架构。两种方案取舍。

方案 A：Milvus 内置稀疏向量（单库方案）

✅ 优势：系统组件减少，不需要维护独立 ES 集群；分片 ID 天然统一，不用维护两套存储同步逻辑；运维复杂度更低。 ❌ 劣势：BM25 能力弱于专业 ES；复杂关键词语法、同义词、高级过滤能力不足；原有存量 ES 体系无法复用。适用场景：新立项 RAG 项目，知识库不算超大，不需要 ES 支撑其他业务检索。

方案 B：独立 Elasticsearch + 向量库（双存储架构）

✅ 优势：ES 作为成熟搜索引擎，分词、同义词、实体检索、复杂检索语法能力强；ES 可以同时支撑站内检索、日志检索，一套集群复用。 ❌ 劣势：组件变多；需要维护文档分片数据双写同步逻辑；新增 / 修改 / 删除文档时，向量库和 ES 都要更新，存在数据一致性风险，需要增加补偿任务。适用场景：政务大型平台，原有系统已经部署 ES，知识库规模大，关键词检索场景复杂。

工程风险提示：双写同步问题。文档更新时，向量库更新成功但 ES 写入失败，会出现两边数据不一致，多路召回结果错乱。解决方案：引入消息队列保证最终一致性，增加定时校验任务，比对向量库与 ES 分片元数据，自动修复不一致数据。

六、进阶优化策略

6.1 动态召回策略，根据 Query 类型切换召回逻辑

Query 包含编号、文号、单证编码：提高 BM25 权重，放大 ES 召回数量；
开放式自然语言提问：提高稠密向量权重；
简短实体查询：优先关键词检索；长段落复杂业务提问：优先向量检索。可以通过实体识别模型，自动检测 Query 是否包含编码、文号、专有名词，自动切换权重。

6.2 多粒度分片多路召回

第 05 篇提到 Chunk 分片策略，进阶方案：同时维护两套分片。粗粒度大分片（1200 字符）用于向量检索，捕获整体语义；细粒度小分片（400 字符）用于 ES 关键词检索，精准命中局部实体。重排阶段合并两套分片结果。代价：存储量翻倍，复杂度上升，适合对召回精度要求极高的核心知识库。

6.3 过滤前置，减少候选集

在多路召回阶段，提前带入业务元数据过滤条件（口岸站点、文档密级、时间范围），过滤掉无权限、无关业务分片，减少后续融合、重排计算量。对应前文向量库的「先过滤，后检索」能力；ES 同样支持元数据字段过滤。

七、混合召回常见踩坑清单

向量库和 ES 分片不一致，分片边界不同，分片 ID 无法对应，多路召回结果无法合并。

解决：文档解析输出统一 Chunk，同一份 Chunk 同时写入向量库与 ES，分片 ID 全局唯一。

分数直接对比，不做归一化或者不使用 RRF 融合。向量相似度和 BM25 分数值域不一样，直接相加没有任何数学意义。
多路召回候选集过小，例如向量只召回 Top5，ES 召回 Top5，合并之后候选太少，高相关分片在召回阶段就丢失，Rerank 无力回天。

记住：Rerank 只能优化已经召回进来的分片，不能找回在多路召回阶段被丢弃的内容。

重排模型输入过长，超过模型最大文本长度，发生文本截断，相关性打分失真。选型 Rerank 时确认模型上下文窗口，控制单条 Chunk 长度。
忽略双写一致性问题。文档删除，向量库分片删除成功，ES 分片残留，多路召回召回已作废文档。必须增加定时数据对账任务。
权重静态不变，所有查询场景使用同一套 α、β 权重，编号检索场景召回效果差。生产环境建议做动态权重。

八、本章小结

单一稠密向量检索擅长语义泛化，但在专有名词、编号、细粒度事实检索场景存在短板；BM25 关键词检索刚好弥补字面精准匹配能力，但缺少语义理解能力。混合召回架构，采用稠密向量 + BM25 两路并行检索，使用 RRF 或者加权归一化完成多路结果融合，再借助 Cross-Encoder Rerank 模型做精细二次排序，是政务、智慧口岸私有化 RAG 项目提升召回准确率，解决语义漂移的标准工程方案。

架构上有两条路线可选：Milvus 内置稀疏向量，减少中间件；或者独立 ES + 向量库，复用成熟搜索引擎能力。两种方案各有运维成本与能力取舍。同时需要注意分片对齐、双写同步、候选集大小、重排输入长度等工程细节。混合召回不是万能银弹，它建立在高质量文档解析、清洗、Chunk 分片基础之上；如果上游分片质量差，混合召回优化效果会大打折扣。