向量检索解决了“语义相关”的问题，但在处理精确匹配、专有名词、缩写等场景时，容易显得“过于模糊”。单独依赖关键词检索（如 BM25）又无法理解同义词、问法变化。真实业务中的知识库往往两者都需要：既要语义泛化能力，也要精确命中能力。混合检索正是为此而生。
8.3.1 为什么需要混合检索
先看两个典型问题：
- 问题 A：“怎么开通 XX 服务？”
知识库中有一篇文档标题就叫《XX 服务开通指南》，正文里反复出现“开通 XX 服务”。关键词 BM25 可以直接命中标题和正文的精确词，但向量检索可能因为语义泛化把其他“开通流程”也召回来，不一定排在最前。
- 问题 B：“客户申请退款后多久到账？”
实际文档里可能写的是“退款到账时效”“退款处理周期”。纯关键词“多久到账”匹配不到“时效”，可能漏掉最佳答案；而向量检索可以理解它们是同义表达，得分反而更高。
混合检索的思路就是同时跑两条检索管线，一者负责精确词匹配，另一者负责语义理解，最后将两边的结果融合排序，互补不足。
8.3.2 常见融合策略
最简单的融合方式是结果集合并后重新打分，但关键在于如何统一不同量纲的分数。实践中常用以下几种：
1. 线性加权融合
最终得分 = α × 向量相似度分 + (1 - α) × BM25 分- 向量相似度分需要归一化到 [0, 1] 区间（如余弦相似度本身就在 0~1，或做 min-max 归一化）。
- BM25 分通常用该片段在所有检索结果中的相对得分做归一化（如除以该次查询的最高 BM25 分）。
- α 是权重，控制偏向语义还是偏向精确匹配。α=0.7 表示更信任语义结果。
2. 倒数排名融合（RRF, Reciprocal Rank Fusion）
不依赖原始分数，只用排序位置：
RRF_score(d) = Σ ( 1 / (k + rank_i(d)) )其中 rank_i(d) 是文档 d 在第 i 个检索列表中的排名，k 是常数（通常取 60）。RRF 对各个检索器的分数尺度完全不敏感，实现简单，鲁棒性强，是混合检索的常用开局方法。
3. 分层策略
- 先用关键词检索快速锁定一批候选；
- 再用向量检索在这些候选内进行精排，或反过来。
这种方式适合候选集较大的场景，能兼顾性能与效果。
8.3.3 权重调优：怎么定 α？
线性加权中的 α 值直接决定了检索结果的倾向。没有一成不变的最优值，需要结合具体业务数据来调整。实用的调优流程如下：
- 构建测试问答对
准备 50~100 个典型问题，每个问题标注好知识库中的最佳匹配片段（或至少 2~3 个相关片段）。
- 离线评测不同 α 值
对每个问题，分别用 α=0（纯关键词）、0.3、0.5、0.7、1.0（纯向量）跑检索，统计命中率（如 Recall@5、MRR 等指标）。通常会发现某个 α 值在整体上表现最好。
- 分场景设定 α（高级做法）
若问题类型差异大，可以为不同意图分配不同权重。例如：
- 查询政策编号、表单代码 → α=0.2（偏向关键词）
- 咨询操作步骤、解释说明 → α=0.7（偏向语义）
这需要在检索前做轻量级的意图分类或基于规则判断。
- 监测线上效果
上线后通过用户点击、反馈（有帮助/无帮助）来间接观察，必要时微调。但要注意，频繁改动 α 可能导致排序剧烈变化，建议在评测集验证后再上线。
8.3.4 实现上的实用建议
- 归一化务必仔细：向量相似度和 BM25 的原始数值分布完全不同，直接相加容易一方主导。可使用 min-max 归一化或排名融合规避。
- 保留元数据便于调试：混合检索日志里同时记录向量排名和 BM25 排名，便于分析为什么某条结果最终排到了前面。
- 谨慎引入太多检索器：不是越多越好，向量+BM25 已经能覆盖绝大多数场景。过多检索源会让融合逻辑复杂且难以调优，收益却往往递减。
- 向量数据库的原生支持：不少现代向量数据库（如 Elasticsearch、Weaviate、Pinecone）已内置混合检索和融合接口，优先使用这些功能可以减少自己实现和运维的复杂度。
8.3.5 一个真实调整案例
某企业知识库初期只使用向量检索，员工反馈“搜‘合同模板编号’出来的经常不是那个编号的合同，而是其他合同”。分析发现，编号“HT-2024-039”这种精确词在向量空间里和其他编号很相似，容易混淆。
引入 BM25 混合检索后，α 设为 0.3（偏向关键词），编号查询准确率从 60% 提升到 95% 以上，同时“合同怎么续签”这类语义问题仍保持高召回。最终线上采用 α=0.35，兼顾了两类需求。
混合检索不是要取代向量或关键词，而是让它们在各自擅长的领域发挥作用。把融合和权重调优固化为一套可评测、可调整的流程，检索质量就有了持续优化的抓手。