为什么 RAG 中常用 BM25 + 向量检索的混合召回？
这道题考的是两种检索方式的互补机制，本质是搞清楚：什么时候该用关键词，什么时候该用语义。
两种检索各自的短板
先说 BM25。它是基于词频的经典算法，擅长精确匹配。你查个订单号 "2026012345"，BM25 一找一个准。但如果用户问 "怎么优化查询性能"，BM25 就蒙了——它不懂 "优化" 和 "提升性能" 是一个意思。
向量检索呢？它把文本转成向量，靠余弦相似度找意思相近的内容。问 "如何提升系统性能"，它能给你一堆语义相关的答案。但你要是问 "RAG 架构怎么搭"，向量检索可能更倾向于返回包含 "RAG" 这个词的文档，而不是真正讲架构的文档。
简单说：BM25 认识字但不懂意思，向量检索懂意思但对关键词不敏感。
混合召回怎么互补
两种方式并行跑，各查各的。BM25 负责把包含用户原词的文档捞出来，向量检索负责把意思相近的文档捞出来。
打个比方：你想找一首歌，BM25 像是在点歌机输入歌名，向量检索像是哼两句让系统猜。歌名输对了，BM25 直接命中；哼得准，向量检索帮你找到你都不知道名字的歌。
两个结果合并去重，形成更完整的候选集。这就是混合召回的核心思路：不把鸡蛋放一个篮子里。
RRF 融合算法怎么合并结果
两路检索出来的文档分数体系完全不一样：BM25 的分数和向量相似度的分数不能直接加。
RRF（Reciprocal Rank Fusion）解决这个问题的思路很聪明：不看分数，只看排名。
公式长这样：
RRF(d) = Σ 1/(k + rank(d))k 是个常数（通常取 60），rank 是文档在某一路检索中的排名。比如文档 A 在 BM25 里排第 3，在向量检索里排第 5，它最终的 RRF 分数就是 1/(60+3) + 1/(60+5)。
不管两路分数的绝对值差多少，只要排名靠前，分数贡献就大。这个设计让融合结果对两路都很公平。
实战场景怎么配置
不同场景对两种检索的依赖程度不一样：
- 技术文档检索：术语多、专业词汇多，BM25 比重要大一些
- 客服问答系统：用户说话口语化、同义词多，向量检索比重大一些
调参一般用权重 α 控制：α 越小越偏 BM25，α 越大越偏向量检索。这个值没有标准答案，要看你的数据特点和用户 query 的类型。
有个更进阶的玩法：两层过滤。第一层双路混合召回，第二层用 Cross-Encoder 做精排。Cross-Encoder 把候选文档和 query 一起过一遍模型，打出更准的相关性分数。
另外要注意 BGE-M3 这类新进展，它把稀疏检索、稠密向量、多向量表示整合到一起，一个模型搞定多种检索方式，是未来的趋势。
面试怎么答
基础版（直接背）：
单一检索各有局限。BM25 基于词频匹配，精确查询没问题，但不懂同义词和语义关联；向量检索靠语义理解吃饭，但对关键词不敏感，容易漏掉精确匹配的文档。混合召回让两路并行，BM25 抓关键词命中，向量检索抓语义相似，结果取并集。融合时用 RRF 算法按排名融合，不依赖原始分数的绝对值，比直接归一化后相加更稳定。
加分版（加这些细节）：
补充几点：RRF 里 k=60 是经验值，起到平滑作用，避免排名波动影响太大。实战中常用两层架构：第一层双路召回，第二层 Cross-Encoder 精排。权重 α 要根据场景调——技术文档偏小，客服系统偏大。另外可以提一下 BGE-M3 等新进展，它把稀疏和稠密检索统一到一个模型里，是未来的方向。
一句话总结
BM25 和向量检索各有所长，混合召回让精确匹配和语义理解互补，RRF 算法负责公平融合两种不同体系的分数。