1 什么是多路召回（Multi-Retrieval）
P1 · rag
🏷 标签：rag, multi-retrieval, fusion, bm25, vector-search
1️⃣ 考察意图
面试官想看的不是“多路召回就是多个检索器一起用”这种定义，而是你能否在工程落地中平衡召回率、延迟、结果冗余这三个矛盾点。考察类型是系统设计 + 工程取舍。刁钻点在于：多数人只会背RRF公式，但说不清为什么RRF比加权求和更鲁棒、在什么场景下必须用学习排序、以及如何避免多路召回变成“多路垃圾”。答好了能展示你对检索系统整条链路的掌控力——从检索策略选型到融合策略调优，再到线上延迟优化。
2️⃣ 标准答
多路召回（Multi-Retrieval）的核心是：用N种不同检索策略并行获取候选文档，再通过融合策略合并结果。目的是覆盖单一检索器的盲区——比如向量检索抓不住精确关键词匹配，BM25理解不了语义同义改写。
1. 检索策略选型（至少选2-3路）
- 向量检索（Dense Retrieval）：用DPR、ColBERT或OpenAI embedding + FAISS/HNSW索引。优势是语义匹配强，能处理“苹果公司”和“库克领导的企业”这种同义查询。坑：embedding质量依赖领域微调，否则在长尾query上Recall@10可能比BM25低20%【通用知识】。
- 关键词检索（Sparse Retrieval）：BM25（默认k1=1.5, b=0.75）或Elasticsearch的match query。优势是精确命中专有名词（如“GPT-4 API文档”），延迟低（<10ms）。坑：对拼写错误零容忍，需要加fuzzy匹配或同义词扩展。
- 结构化检索：知识图谱查询（如Neo4j的Cypher）或SQL过滤。适用于“2024年营收超过10亿的AI公司”这类有明确属性约束的query。坑：需要预定义schema，扩展性差。
2. 融合策略（核心难点）
- 互惠排名融合（RRF）：公式
score(d) = Σ 1/(k + rank_i(d))，k通常取60。为什么选RRF？因为它不依赖分数归一化——向量检索的cosine相似度（01）和BM25的TF-IDF分数（020）量纲不同，直接加权求和会崩。RRF只看排名，鲁棒性极强。工程坑：k值调优——k越小，高排名文档权重越大；k越大，结果越平滑。在MS MARCO上，k=60比k=10的MRR高3-5%【通用知识】。 - 加权合并：
score(d) = w1 * norm(score_vec) + w2 * norm(score_bm25)。需要先做分数归一化（min-max或z-score）。为什么慎用？归一化对异常值敏感——如果某路检索器给所有文档打了接近0分，min-max会放大噪声。只在各检索器分数分布稳定时用（如线上A/B测试验证过）。 - 学习排序（Learning to Rank）：用LambdaRank或LightGBM训练一个排序模型，输入特征包括各检索器分数、文档长度、query-doc共现词数等。什么时候必须用？当query意图高度混合时（如“苹果手机价格和公司财报”），RRF和加权合并都搞不定，需要模型学出不同场景下的权重。代价：需要标注数据（至少10k条query-doc相关性标签），且线上推理延迟增加5-10ms。
3. 实际落地的坑 + 解法
- 坑1：结果冗余。向量检索和BM25可能返回同一篇文档，导致Top-10里5篇重复。解法：在融合后做去重（按doc_id或内容hash），然后按融合分数重排。
- 坑2：延迟爆炸。3路检索并行，最慢的一路（通常是向量检索，20-50ms）拖累整体。解法：给每路设超时（如向量检索30ms超时后降级为BM25结果），或用级联召回——先用BM25快速筛出1000篇，再对这1000篇做向量检索重排，延迟从50ms降到15ms。
- 坑3：融合策略线上漂移。RRF在离线评测上Recall@20=0.85，上线后掉到0.78。原因：线上query分布变了（比如突然涌入大量长尾query）。解法：在线A/B测试 + 动态切换——监控每路检索器的平均排名，如果某路排名持续下降（如BM25平均排名从5掉到15），自动降低其RRF权重或切到加权合并。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从策略选型、融合方法、工程落地三个层面回答。策略上，至少选向量检索+BM25两路，必要时加知识图谱。融合上，首选RRF因为它不依赖分数归一化，鲁棒性最强；如果query意图复杂，再上学习排序。工程上，注意去重、超时降级、在线监控。总结一句：多路召回不是简单堆检索器，而是用融合策略和工程手段把各路的优势拼起来，同时控制延迟和冗余。”
4️⃣ 高频追问 & 应对
追问 1：RRF的k值怎么调？有没有理论依据？
没有严格理论最优值，但经验法则：k=60是MS MARCO和TREC上的常见起点。k越小（如10），高排名文档权重越大，适合精确匹配场景（如FAQ检索）；k越大（如100），结果越平滑，适合语义多样性场景（如开放域问答）。调优方法：在验证集上做grid search，步长10，观察Recall@k和MRR。如果线上query长度分布广，可以动态k——短query（<5词）用k=30，长query（>10词）用k=80。
追问 2：如果向量检索和BM25的结果完全不重叠，怎么办？
这是好事，说明两路互补性强。但需要检查是否有一路检索器失效（比如向量检索的embedding模型没覆盖query中的实体）。解法：先计算两路结果的Jaccard相似度，如果<0.1，说明互补性高，直接RRF融合即可；如果>0.5，说明冗余高，考虑去掉一路或降低其权重。极端情况：如果某路Recall@100=0，说明该路完全无效，需要排查索引或模型问题。
追问 3：多路召回在线上延迟要求<50ms时怎么优化？
核心思路是并行 + 降级。并行：用异步调用（如Python的asyncio或gRPC流）同时发起3路检索，总延迟取最慢一路。降级：给每路设超时（如向量检索30ms，BM25 10ms，知识图谱 20ms），超时后该路结果降级为默认排序或空。更激进的做法：级联召回——先跑BM25（5ms）筛出500篇，再对这500篇做向量检索（10ms），总延迟15ms，但会丢失BM25没召回但向量检索能召回的文档。取舍点：如果业务对召回率要求极高（如法律文档检索），必须并行；如果对延迟敏感（如搜索建议），用级联。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“多路召回就是把所有检索器结果合并，然后按分数排序” → ✅ 正确切入：必须说明融合策略（RRF/加权/学习排序）的选择依据和trade-off，不能只提“合并”二字。
- ❌ 说“RRF的k值固定为60，不需要调” → ✅ 正确切入：k值需要根据query长度、业务场景动态调整，并给出调优方法（grid search或动态k）。
- ❌ 说“多路召回延迟高，所以不适合线上” → ✅ 正确切入：通过并行调用、超时降级、级联召回等工程手段，完全可以把延迟控制在50ms内，并给出具体数字。
6️⃣ 简历呼应
- 如果你有RAG项目：从“我在XX项目中用多路召回解决了长尾query召回率低的问题”切入，具体说用了哪几路检索（如向量+BM25+知识图谱）、融合策略（RRF）、以及Recall@20提升了多少（如从0.72到0.85）。
- 如果你只做过传统NLP：用“多路召回类似于集成学习中的Bagging”类比，强调不同检索器是弱学习器，融合策略是投票机制。然后说你在文本分类中用过类似思路（如多模型投票），迁移到检索场景。
- 如果你是校招无项目：聚焦论文复现——提到你读过《Multi-Retrieval Fusion for Open-Domain QA》（ACL 2023），并自己用FAISS+Elasticsearch实现了一个demo，在Natural Questions数据集上对比了RRF和加权合并的Recall@20差异。
- 《Multi-Retrieval Fusion for Open-Domain QA》（ACL 2023）
- 《Reciprocal Rank Fusion: A Simple and Effective Method for Combining Search Results》（SIGIR 2020）
- FAISS官方文档：HNSW索引参数调优指南
- Elasticsearch BM25参数（k1, b）调优实战博客
- 《Learning to Rank for Information Retrieval》（Tie-Yan Liu, 2009）