考察点
「多路召回是什么」是 2026 面经 RAG 部分的原题，也是区分做过和背过的分水岭。面试官想看你知不知道向量检索的固有短板（专有名词、编号、精确匹配），以及召回和排序两阶段的架构意识。追问常往「各路怎么融合」「权重怎么定」走。
参考答案
纯向量检索的三个盲区
Embedding 捕捉的是语义相似性，这既是它的能力也是它的盲区：
- 专有名词和编号：用户问「SKU 8848 的保修政策」，向量模型眼里「8848」和「8849」差不多，但业务上天差地别。型号、订单号、法规条文号这类精确 token，向量天然不敏感。
- 短 query：三五个词的 query 语义信息量太少，向量里全是噪声。
- 领域黑话：未微调过的通用模型不知道「七天无理由」=「退货」，语义匹配直接失效。
而关键词检索（BM25）正好互补：精确匹配强、对生僻词稳，但完全没有语义泛化能力。两个各有 60-80 分的方案融合后能到 90 分，这就是混合召回的价值。
典型的多路召回架构
生产级 RAG 常见四路：
- 向量召回：query 编码后 ANN 搜索，Top 20-50，语义兜底。
- BM25 召回：ES 或向量库内置的稀疏检索，解决精确匹配。分词质量是命门——中文用 jieba 自定义词典或 IK，把领域词灌进词典，否则「RAG」被切成单字就废了。
- 实体/结构化召回：从 query 里抽出实体（商品名、政策名），直接走 MySQL/ES 精确查。电商场景这路是主力。
- FAQ 直查：历史高频问答对单独建索引，命中相似 FAQ 直接返回标准答案，绕过生成，质量和延迟都最优。
每路独立返回候选集，然后进入融合层。
融合：RRF 是最稳的选择
各路得分量纲完全不同（向量是余弦 0-1，BM25 是十几到几十的分），直接加权需要先归一化，归一化又对分数分布敏感。工程上最稳的是 RRF（Reciprocal Rank Fusion，倒数排名融合），只看排名不看分：
score(d) = Σ 1 / (k + rank_i(d))
k 通常取 60。一个文档在任一路排第 1，就能拿到 1/61 的贡献，多路都靠前的文档自然胜出。RRF 不需要调权重、对异常分不敏感，是混合检索的默认起点。
融合后一般还有一道 Rerank（交叉编码器精排），把 50-100 个候选压到 3-5 个进 Prompt。多路召回解决「找得到」，Rerank 解决「排得对」，两者是接力不是替代。
效果验证
混合召回值不值，用评测集说话：分别跑纯向量、纯 BM25、混合三组，看 Recall@10 和答案准确率。我的项目里混合比纯向量 Recall@10 提升了 15 个点左右，其中大部分收益来自编号类 query。注意 BM25 路也会引入噪声（字面匹配但语义无关的文档），这正是后面要有 Rerank 的原因。
可能的追问
Q：各路权重怎么调？ 先用 RRF 免调参上线，积累 Bad Case 后再分析：如果错误集中在某路引入的噪声，可以给 RRF 加路权重，或干脆让该路只召回不直通（必须被其他路佐证才保留）。
Q：BM25 和向量能不能在一个系统里做？ 可以。ES 8.x、OpenSearch、Qdrant（稀疏向量）、bge-m3 都支持一体混合。一套系统省事，但 sparse 和 dense 的调优互相牵扯，量级大了还是分开灵活。
Q：多路召回会不会拖慢延迟？ 各路并行发起，总延迟取决于最慢一路。向量 ANN 几毫秒，BM25 十几毫秒，实体查询毫秒级，并行后整体 P99 可控在 50ms 内。真正的延迟大户是后面的 Rerank 和 LLM 生成。