07. 什么是 Hybrid Search？什么时候需要混合检索？
整理 什么是 Hybrid Search？什么时候需要混合检索？ 的核心概念、工程要点与面试回答。
简单回答
Hybrid Search（混合检索）是指同时使用向量检索（语义匹配）和关键词检索（如 BM25，词法匹配）两路召回，然后合并结果。之所以需要混合，是因为向量检索擅长理解语义但可能漏掉精确关键词匹配，BM25 擅长精确匹配但无法理解同义词和语义关联。两者互补，混合后的效果通常优于单用任何一种。
详细解释
向量检索和关键词检索各自的短板
向量检索的核心优势是语义理解。用户问"怎么退钱"，知识库里写的是"退款流程说明"——两者用词完全不同，但语义相近，向量检索可以匹配到。但向量检索有个明显弱点：对精确关键词不敏感。比如用户搜"错误码 E40012 的解决方案"，向量检索可能会匹配到一些和"错误码""解决方案"语义相近但完全不是 E40012 的文档。因为 Embedding 模型把文本压缩成一个固定维度的向量，具体的字符序列信息（如型号、编号）在这个过程中容易丢失。
BM25 是基于词频的检索方法，它的优势恰恰在精确匹配。搜"E40012"，只要文档里出现了"E40012"这个词，就能被召回。但 BM25 完全不理解语义——"退钱"和"退款"，BM25 可能就匹配不上（除非做了同义词扩展）。
实际业务中，用户的查询千差万别。有些查询偏语义理解（"系统跑得很慢怎么办"），有些查询偏精确匹配（"API 返回 403 怎么处理"），大多数查询两者兼有（"MacBook Pro M3 电池续航怎么样"——既有精确型号又有语义化的问题）。所以混合检索通常效果最好。
怎么做混合检索
混合检索的实现有两个关键问题：两路召回怎么各自执行，结果怎么融合。
执行层面，需要同时维护两套索引：一套向量索引（存在向量数据库或 ES 的 字段），一套倒排索引（ES 的标准文本索引，或者 BM25 引擎如 Anserini）。用户查询来了，同时发两路检索请求，拿到各自的 Top-N 结果。
融合策略是关键。最常用的有两种：
Reciprocal Rank Fusion（RRF）是最简单也最常用的融合方法。它不看具体的分数，只看排名。每个文档在每路结果中的排名越高，融合后的分数越高。公式是：
其中 是所有参与融合的结果列表， 是文档 在第 路结果中的排名， 是一个常数（通常取 60）。RRF 的好处是不需要对不同来源的分数做归一化（向量相似度和 BM25 分数量纲完全不同），只用排名信息就能融合。Elasticsearch 8.x 原生支持 RRF。
加权分数融合是另一种方式，把两路的分数分别归一化到 0~1，然后加权求和。比如 。 的选择需要在业务数据上调优。这种方式比 RRF 更灵活，但需要处理分数归一化的问题，不同场景下最优的 也不同。
什么时候需要混合检索
几乎所有严肃的 RAG 系统都建议用混合检索，除非你的场景非常单一。具体来说：
当知识库中包含大量专有名词、代码、编号、型号等精确匹配内容时，纯向量检索一定会漏；当用户查询方式多样化，既有口语化的描述又有精确的关键词引用时；当你发现纯向量检索的 Recall 始终上不去，加了 BM25 通常会有明显改善。
反过来，如果你的场景是纯语义检索（比如"找和这段文本语义最相似的文档"），或者知识库非常小（几百条），混合检索的边际收益可能不大。
工程上的考量
混合检索的额外成本主要在维护两套索引。如果用 Elasticsearch，这个成本最低——一个 ES 集群同时维护倒排索引和向量索引。如果向量库和全文检索是两个独立服务（比如 Milvus + ES），就需要处理两路请求的并发、结果合并、以及两套索引的数据一致性。
面试时可以这样答
Hybrid Search 就是同时用向量检索和 BM25 关键词检索做召回，然后融合两路结果。核心原因是两者互补——向量检索理解语义但容易漏掉精确关键词，BM25 精确匹配强但不懂语义。
融合策略上，最常用的是 RRF，不看具体分数只看排名，避免了不同来源分数归一化的问题。也可以用加权分数融合，但需要在业务数据上调权重。
实际项目中几乎都建议用混合检索。特别是知识库里有很多专有名词、型号、编号的场景，纯向量检索 Recall 很难打满。如果团队已经有 ES，混合检索的实现成本很低，ES 8.x 原生支持 RRF 融合。
常见追问
- RRF 中的常数 k 取不同值会有什么影响？
- 除了向量和 BM25，还有什么可以作为第三路召回？
- 混合检索一定比单路检索好吗？有没有混合后效果反而下降的情况？