RAG 检索中为什么要混合 BM25 和向量召回，融合权重或比例如何设置和评估？｜高频面试题解析

60 秒回答模板

我会先说明 BM25 和向量召回各自解决的盲区。向量召回适合处理语义近似，比如用户问法和文档措辞不同；但它对专有名词、缩写、数字、代码符号、错误码、日期和很短的 query 不稳定，也容易召回语义相似但事实不能回答的片段。BM25 基于词项匹配和词频逆文档频率，对精确关键词、标题、接口名、配置项和实体命中更可靠，但对同义改写、长自然语言问题和语义泛化不足。所以生产 RAG 通常会做混合召回：并行取向量 topK、BM25 topK，有时再加标题字段、实体字段或规则召回，然后用 RRF、归一化加权、分桶融合或学习排序把候选合并。比例设置不能只说五五开。冷启动可以先用 RRF 或经验权重，例如语义问答更偏向向量，错误码、产品名、接口路径、短词查询更偏向 BM25；随后用标注集评估 Recall@K、Precision@K、nDCG、MRR、答案忠实度和引用准确率，再结合线上点击、采纳、人工反馈和 badcase 调整。更进一步可以做 query classifier 或 learned ranker，让不同查询类型采用不同融合权重。最终目标是让 BM25 提供精确锚点，让向量提供语义覆盖，再由 rerank 判断哪些证据真正能回答问题。

考点 BM25 的价值

难度 真实面经题

回答目标让候选人能把 BM25 与向量混合召回讲成一套可评估的 sparse+dense 融合方案，覆盖互补动机、融合算法、权重校准、query 自适应、rerank、离线线上评估和成本控制。

深入解析

BM25 弥补精确匹配盲区

RAG 查询里经常出现错误码、接口名、字段名、产品名、英文缩写、版本号、日期、日志片段和人名。这些 token 的语义空间未必稳定，向量距离可能把相似上下文召回来，却漏掉精确字符串。BM25 能利用词项出现、稀有词权重和字段权重，保证这类精确锚点不会被语义泛化淹没。

向量召回弥补语义表达盲区

BM25 依赖字面匹配，用户换一种说法、使用同义词、口语化提问或描述现象不写术语时，它可能召不回文档。向量召回把 query 和 chunk 映射到语义空间，能处理概念相近但词不同的情况，适合 FAQ、知识库解释、故障现象描述和自然语言长问句。

混合召回通常先并行再融合

常见在线流程是 query 解析后并行走向量索引和 BM25 索引，各取 topK；再做候选合并、去重、权限过滤和初步融合。并行比串行更能保留互补性，避免某一路先过滤掉另一路能找到的证据。复杂场景还可以增加标题召回、实体召回、结构化过滤和历史反馈召回。

RRF 适合冷启动融合

Reciprocal Rank Fusion 的好处是不用强行比较向量相似度和 BM25 分数的绝对值，只看候选在各路结果里的名次。它对分数尺度不一致比较稳健，适合冷启动和多路召回。缺点是无法精细表达某一路分数置信度，也不容易利用业务特征。

加权融合要先做分数归一

如果用 alpha 乘向量分数加 beta 乘 BM25 分数，必须先处理分数尺度、方向和分布差异。向量相似度、距离、BM25 原始分和字段加权分不能直接相加。常见做法包括 min-max、z-score、分位数归一、按 query 分桶校准或学习一个融合模型，否则所谓比例只是数学上看起来合理。

比例应随 query 类型变化

固定比例很难覆盖所有查询。短 query、含错误码、含接口路径、含配置 key、含人名或版本号时，可以提高 BM25 或精确字段召回权重；长自然语言问题、同义改写、概念解释类问题，可以提高向量权重。可以用规则、query classifier、LLM query analysis 或学习排序实现自适应。

融合后还需要 rerank

混合召回只是扩大候选和提高互补覆盖，不能替代重排。BM25 命中字面词但段落不回答问题，向量召回语义相近但事实不相关，都需要 reranker 进一步判断 query 与证据的细粒度匹配。重排阶段还要考虑证据完整性、时效、来源质量、重复度和上下文预算。

离线评估要看互补贡献

调比例时不能只看单一路径的 Recall@K。要比较 BM25-only、vector-only、hybrid 的 Recall@K、Precision@K、MRR、nDCG、引用准确率和最终答案忠实度，还要统计哪些 query 只被 BM25 召回、哪些只被向量召回。互补集合越清晰，比例和路由策略越有依据。

线上要同时看质量和成本

混合召回会增加索引维护、在线查询、候选合并和重排成本。线上调参要看用户点击、采纳、人工反馈、无答案率、延迟、召回超时、重排成本和 token 成本。一个比例离线指标略好但让延迟明显变差，未必适合生产默认策略。

易错点

把混合召回答成简单五五开，没有说明 BM25 和向量各自解决什么失败模式。
直接把 BM25 原始分和向量相似度相加，忽略分数尺度和分布不一致。
只讲向量召回先进，否定 BM25，导致错误码、字段名、版本号和短 query 命中差。
只讲 BM25 精确，忽略同义改写和自然语言问题下的语义召回需求。
固定一个比例用于所有 query，不区分专名型、短词型、概念型和现象描述型查询。
融合后不做去重，多个召回路返回同一文档片段，浪费上下文预算。
把混合召回当成最终排序，缺少 rerank 对证据可回答性的判断。
调参只看召回条数，不看 Recall@K、nDCG、引用准确率、答案忠实度、延迟和成本。

面试官追问

冷启动没有标注集时比例怎么设？

优先用 RRF 这类对分数尺度不敏感的方法，或采用保守经验：向量和 BM25 各取一批候选，再让 rerank 统一排序。随后从真实问题日志中抽样标注，逐步替换成离线评估驱动的权重。

什么查询更应该偏 BM25？

包含错误码、接口路径、字段名、配置 key、版本号、数字、人名、产品名、代码符号和非常短的关键词查询时，BM25 或字段精确召回通常更重要。因为这些信息的字面匹配价值高，向量模型可能把相近概念混在一起。

什么查询更应该偏向向量召回？

用户用自然语言描述现象、问概念解释、没有明确术语、使用同义改写或跨语言表达时，向量召回更有价值。它能找到字面词不同但语义相关的文档，再由 rerank 判断证据是否足够。

RRF 和加权融合怎么选？

没有可靠分数校准或标注数据时，RRF 更稳健；如果已有标注集、分数分布稳定并且希望表达不同召回路的置信度，加权融合或学习排序更灵活。实际也可以先 RRF，再在 rerank 阶段引入更多特征。

混合召回 topK 应该怎么分配？

可以先给每路足够候选，例如向量 topK 和 BM25 topK 各取一批，再合并去重后交给 rerank。随着数据积累，再按 query 类型和一路独有命中率调整每路 K，避免某一路候选过多挤掉另一种证据。

如何证明 BM25 的引入不是多余的？

看 BM25-only 命中而 vector-only 漏掉的 query 集合，尤其是专名、错误码、接口路径和短 query；再比较 hybrid 后的 Recall@K、引用准确率、答案忠实度和线上采纳率。如果这些场景显著改善，BM25 就有明确贡献。