考察点
这道题表面问「为什么混合」，实际考你能否说清两种检索范式的失效边界：什么 query BM25 必挂、什么 query 向量必挂。只答「两个结合效果更好」是背书，能举出自己遇到过的具体 badcase 才是干过活。追问常往融合算法细节（RRF 原理、分数归一化）、两路权重怎么调走。
参考答案
先看 BM25 在哪里失效
BM25 是词袋模型：文档和 query 要有共词才能召回，靠 TF-IDF 类的统计给词加权。它的失效场景都很典型。同义表达：用户问「怎么退钱」，文档写的是「退款流程」「退货申请」，共词极少，召回为零；这是 BM25 最大的短板，传统解法是维护同义词典，但那是无底洞。口语化问法：「这玩意儿怎么连不上网」对「网络连接故障排查」，词面完全对不上。跨语言：中文 query 检索英文文档，或者反过来。拼写容错、中英文混排的分词问题，也经常让 BM25 丢召回。
再看向量检索在哪里失效
稠密向量把文本压成固定维度的语义表征，这个压缩是有损的。精确标识符会先挂：产品型号、SKU 编码、错误码（比如「E10038」）、URL、版本号，这些字符串的语义信息约等于零，embedding 给不出可靠区分，BM25 却一打一个准。罕见专有名词和新词：训练数据里没见过的公司名、内部项目代号，向量模型只能瞎猜。计数和限定条件：「支持 8 路输入的型号」这种带精确约束的 query，向量召回经常把「4 路」「16 路」的文档也排在前面。还有一个隐蔽问题：向量检索的分数分布很平，top-1 和 top-20 的余弦分数可能只差零点零几，阈值难定，噪声容易混进来。
混合召回的正确姿势
两路并行召回：BM25 一路（ES/OpenSearch），向量一路（向量库），各自取 top-N（常见各取 20-50），然后融合。融合算法两种主流选择：
- RRF（Reciprocal Rank Fusion）：
score = Σ 1/(k + rank_i)，k 是平滑常数，经典取值 60。它只用排名不用原始分数，天然绕开了「BM25 分数 0-30、余弦分数 0-1 分布完全不同没法直接比」的问题，工程上最省心，效果通常不输精心调权的分数融合。 - 加权分数融合：
α · norm(bm25) + (1-α) · norm(vector)，需要先对两路分数分别做归一化（min-max 或 z-score），再调 α。可控性强，但调参成本全在自己身上。
融合之后接 rerank 精排，就是完整的两阶段检索。工程实现上，ES 8.x 之后可以在一个引擎里同时跑 BM25 和 kNN 再做 RRF，运维成本低；两路分开部署则各自伸缩更灵活。
一个真实的权衡
混合不是免费的：两路召回意味着两倍的检索延迟（可并行，主要是长尾延迟）和两套索引的维护成本。判断值不值的办法还是评测集：分别统计 BM25-only、vector-only、hybrid 三组的召回命中率。我的经验是，知识库问答场景下 BM25-only 和 vector-only 的命中率经常各有 10%-20% 的 query 是对方救不回来的，hybrid 能把这部分重叠之外各自的盲区补上，这个收益在面向真实用户长尾 query 的系统里是实打实的。
可能的追问
- RRF 为什么不用归一化分数？答：它输入只有排名，不同检索器的分数分布差异、异常值全被排名抹平了，这也是它对各召回路质量差异鲁棒的原因；代价是丢失了「第一名比第二名强多少」的信息，极端场景不如分数融合敏感。
- 向量召回反而拉低效果的情况有吗？答：有。query 全是精确编号、日志检索这类场景，向量路带进来的都是噪声，融合后 top-K 被稀释。解法是按 query 类型路由，识别为精确匹配意图就走纯 BM25。
- 两路权重怎么定？答：在评测集上扫 α（或 RRF 的 k），以召回命中率或 nDCG 为准；不要凭感觉，分数分布随数据集会漂，调整后要回归。