考察点
这道题出自 OpenAI 大模型应用岗的技术面试，DSPrep 标注 Google/Amazon/OpenAI 三家常考。面试官想验证你是否真的在生产里踩过纯向量检索的坑——型号、SKU、人名、错误码这类精确信息，语义检索就是搜不到。考察重点是：两条检索链路各自为什么失效、融合算法的取舍（RRF vs 加权分数）、以及在 LangChain/Elasticsearch 里怎么落地。追问会往分数归一化、rerank 的位置、稀疏向量（SPLADE）走。
参考答案
为什么单独的向量检索不够用
向量检索把文本压成语义空间里的点，擅长「意思相近」：用户问「怎么退款」，能召回写着「退货流程」的文档。但它的盲区同样稳定——精确字符串几乎失效。订单号 A-20260315-X9、错误码 ORA-01555、小众产品型号、人名地名，这些 token 在 embedding 训练分布里稀疏，向量里几乎不携带可区分的信号。两个只差一位数字的型号，向量距离可能近到无法排序。
BM25 正好反过来：它是基于词频和文档频率的词项匹配，精确字符串一搜一个准，对长尾专有名词极其可靠；但完全没有语义理解，「退款」和「退货」在它眼里是两个词。两者的失效场景几乎正交，这就是混合搜索存在的根本原因——不是锦上添花，是互补短板。
融合怎么做：RRF 是默认答案
两条链路各自返回一个有序列表，融合的核心问题是：向量相似度（0~1 的余弦分）和 BM25 分数（无上界、随语料漂移）根本不可比。直接加权相加前必须先归一化（min-max 或 z-score），而归一化对分数分布极其敏感，换个语料库权重就得重调。
生产里更常用 RRF（Reciprocal Rank Fusion，倒数排名融合），因为它只看名次不看分数，天然免疫量纲问题：
score(d) = Σ 1 / (k + rank_i(d))
每个文档在各路结果里的名次取倒数求和，k 是平滑常数（常用 60）。文档只要在任一路排得靠前就能拿到高分，两路都靠前则稳居榜首。RRF 不需要调权重、对分数分布零假设，Elasticsearch、Qdrant、Weaviate 都内置支持，是工程上的默认选择。加权分数融合只在一种情况下值得用：你明确知道某一路对某类查询更可靠，想做查询级路由——比如检测到查询含 SKU 正则就加大 BM25 权重。
工程落地要点
在 LangChain 里，EnsembleRetriever 就是干这个的：传一个向量 retriever 和一个 BM25Retriever，内部按 RRF 加权融合。中小规模数据（百万文档以内）这条路够用。规模上去之后更常见的形态是把两路都收进一个引擎：Elasticsearch/OpenSearch 8.x 之后同时支持 BM25 和 kNN 向量检索，一个查询里写 knn + match，用 RRF 融合，运维上少一套系统。
几个实战细节：
- 两路召回量要放大。每路各取 top 50-100 再融合，而不是各取 top 5。融合的价值就在重排阶段，候选池太小等于没融。
- 融合后接 rerank 才是完整形态。混合搜索解决召回，精排交给 cross-encoder（bge-reranker、Cohere Rerank 这类）对 top 20-50 逐对打分，最终取 top 3-5 进 prompt。召回靠双路保覆盖、精排靠 rerank 保精度，分工明确。
- 观察指标要分开埋点。统计「最终结果被哪一路贡献的」，如果你业务里 40% 的命中来自 BM25 独有，那混合就是刚需；如果 BM25 贡献率常年低于 5%，说明语料语义化程度高，可以考虑简化掉一路省成本。
一个真实的对照
做过一个制造业知识库，纯向量检索时整体命中率看着有 85%，但客服投诉集中在「搜不到型号」——一查，含具体型号的查询命中率不到 50%。加上 BM25 做 RRF 融合后，型号类查询命中率拉到 90% 以上，整体提升只有几个点，但投诉量直接砍半。这个例子说明混合搜索的价值经常藏在 query 分布的长尾里，只看大盘指标是发现不了的。
可能的追问
1. RRF 里的 k 怎么调？
k 越小头部文档优势越被放大，k 越大各路融合越平滑。默认 60 来自原论文，实践中 20-100 之间差异不大，不值得花太多时间调；真有预算不如把精力放在召回量和 rerank 上。
2. SPLADE 这类稀疏向量和 BM25 什么关系？
SPLADE 用模型学习词项权重和扩展词，相当于「会语义扩展的 BM25」，能部分覆盖传统 BM25 没有语义的问题，且仍可用倒排索引高效检索。它可以看作混合搜索里稀疏路的升级版。
3. 多语言语料下混合搜索要注意什么？
BM25 依赖分词，中文要配 IK/jieba 这类分词器，否则词项匹配退化；向量模型也要选多语言版本（如 bge-m3）。两路的分词和 embedding 都得显式验证，不能假设默认配置对中文友好。