rag hybrid-search bm25 vector-search retrieval

RAG的混合搜索：实际应用中的BM25、向量及互反排名融合方法

RAG的混合搜索：为何仅基于向量的检索会丢失精确ID，互反排名融合如何将BM25与嵌入模型结合，以及混合搜索仍存在的不足之处。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 11 分钟2624 词

来源: Hybrid Search in RAG — BM25, Vectors, and Reciprocal Rank Fusion in Practice

在仅基于向量的检索系统中加入关键词搜索，是RAG技术中提升准确率成本最低的方法之一。Anthropic在其自有语料库上的测试显示：在上下文嵌入的基础上再应用上下文BM25算法，可使前20名检索结果中的错误率降低多达49%，而且无需修改嵌入模型。

让我们探究这个数据背后的原因。当用户输入如GX-V5-5N这样的车辆标识时，纯向量系统只会返回通用的注册指南和服务记录，正确的文档甚至不会出现在前十名结果中。而嵌入模型能够完美捕捉汽车相关的上下文，正因如此它才会忽略那些字面匹配的字符串。问题并不出在嵌入模型强度不足，而是源于系统结构，这种问题会影响到所有仅基于向量构建的RAG系统，也就是大多数默认教程中所介绍的那种系统。

下文将说明：为何结合词汇搜索与向量搜索需要不同于简单计算分数平均值的数学方法，互反排名融合机制的运作原理，这种混合方法何时不再有效，以及在使用该机制前应评估哪些指标。

两分钟了解核心理念

纯向量搜索会系统性地丢失错误代码、产品标识符及专有名词等精确匹配结果。嵌入模型本身并无问题，只是语义相似度与字面匹配属于不同的属性。

源自1990年代的词汇排名函数BM25弥补了向量的不足。它几乎无需额外成本就能捕捉到罕见的特定词汇，但会忽略同义表达与近义词。这两种方法存在相互补充的缺陷，这正是将它们结合起来的结构性原因，而非一时流行的工程手段。

问题在于这些模型的输出无法相加。BM25的得分没有上限且取决于语料库，而余弦相似度的取值范围在-1到1之间。15.3与0.82相加没有任何意义。因此现代搜索引擎不会合并这些得分，而是通过倒数排名融合算法来合并排名位置。

不过混合方法并不总是更优。对于基于精确标识符构建的查询，单独使用BM25就能胜过所有融合方法。关键问题不在于是否采用混合方法，而在于有多少查询确实需要它，而这正是可以通过数据来衡量的。

两个互补的盲点

想象两位弱点截然不同的初级同事。

第一种方式就像直接使用Ctrl+F一样直白。当被询问关于错误代码ERR_CONNECTION_RESET的页面时，它能立刻找到；但当涉及连接问题时，它会忽略那些讨论会话丢失的文档，因为查询词并未出现在其中。

第二种方式则能领会言外之意。它明白连接问题和会话丢失其实描述的是同一回事。不过，当被要求提供具体的错误代码时，它给出的却是关于网络故障的通用说明，因为那个罕见的错误代码已被整句话的泛化含义所掩盖。

单独使用任何一种方式都不够。这就是两段话所表达的全部观点。

BM25的考量因素

BM25既非神奇工具，也非过时技术。它基于倒排索引运行，即为每个单词建立指向包含该单词的文档的列表，因此系统无需扫描整个文档集。其排序机制依赖于三个基本原理：

稀有术语权重更高。标识符GX-V5-5N所传达的信息远多于“vehicle”这个词。
重复会降低效果。某个词出现第十次时带来的影响远小于第二次，因为重复几次后其效应就会趋于平缓。
长度会带来不利影响。长文档不应仅仅因为存在更多可能匹配的内容就占据优势。

向量模型则基于不同的原理运作。文本会被转化为一组编码意义的数字，而排序则是根据这些数字在特定空间中的距离来确定的，无论查询词和文档词是否有重合。一种引擎衡量的是字符覆盖度，另一种则衡量意义覆盖度。

应避免的类别错误

人们很容易将向量搜索视为升级版的全文搜索，认为它更先进、更智能，是理所当然的选择。但这其实是一种分类错误。向量并不能取代词汇搜索，它们解决的是不同的问题，也因此失去了词汇搜索所具备的某种优势。

如果语料库中包含代码、标识符或专有名词，无论模型多优秀，仅靠嵌入表示都无法保留这些信息。其局限性源于向量所能表达的内容范围。正确的思路应是确定不同查询需要多强的权重，但这又会带来如何合并两个以不同单位衡量的结果列表的问题。

为何无法简单地将分数相加

人们自然的工程思维是进行标准化处理、赋予权重后再相加，但这一做法会遇到一个调整参数也无法解决的问题。

BM25没有理论上限。其输出值会随着匹配的查询词数量、这些词在语料库中的稀有程度以及文档长度的增加而上升，因此当新增一万份文件后，同一份文档的得分也会发生变化。余弦相似度通过比较两个向量之间的角度来计算，其值始终介于-1和1之间。

将15.3加到0.82上，就如同直接将千克与磅相加而不进行换算：在数学上可行，但在信息层面毫无意义。虽然可以使用最小-最大归一化或Z分数归一化，但每当语料库、嵌入模型或查询组合发生变化时，这两种评分系统都需要重新校准。每次重新索引后都必须进行的校准工作其实是一种累积的债务。

位置排序的投票机制

互斥排名融合通过忽略分数来避免这一问题。它只考虑每个搜索引擎给文档分配的排名。其计算公式很简单：一个文档的融合分数等于所有搜索引擎对应的“1除以（k加上该文档在该引擎列表中的排名）”之和。若文档未出现在某个列表中，则不会对分数产生任何贡献。

因此，同时出现在两个列表前三名的文档，其表现会优于仅在其中一个列表中排名第一而在另一个列表中不存在的文档。互斥排名融合看重排序的一致性而非绝对准确性，而排名位置则是每个排名系统以相同方式产生的一个数值。

这种方法源自2009年SIGIR会议上Cormack、Clarke和Büttcher的研究，远早于RAG技术的出现。他们的思路是：高排名应具有最大权重，低排名也不应完全被忽略，而常数k则能削弱任何个别异常系统的影响。

在设计评审中出现的一个脚注：60这一标准值源自一次初步测试，并在后续的验证中未被修改。作者们自己也认为这是未经深思熟虑的选择。当k值为60时，排名第一的得分比排名第二的高出约1.6%，而排名六十的得分则约为排名第一的一半。

实际上，k值更像是一个微调旋钮而非控制杠杆。更重要的是每部分贡献的候选数量。如果向量部分提供了五十个候选项，那么处于第五十一位的文档贡献的得分则为零。

混合算法为何成为默认选择

最清晰的数据来自 Anthropic 在其自有数据集上进行的 2024 年上下文检索实验，该实验统计了前二十个结果中缺失正确片段的情况频率。仅使用上下文嵌入就使缺失率降低了 35%。在之上再叠加上下文 BM25 后，缺失率进一步降至 49%，这说明词汇层面已实现了嵌入升级所带来的大部分效果。

需避免一种误解：同一份报告称加入重排功能后缺失率可降低 67%，但重排是另一个阶段，使用的是不同类型的模型。融合处理与重排并非同义词，将二者混放在同一张图表中是常见的演示错误。

各供应商功能的趋同比任何单一基准测试都更具说明意义。Elasticsearch、OpenSearch、Weaviate、Qdrant 以及 Azure AI Search 均原生支持 RRF 功能。混合搜索已从高级选项变为默认设置。

第二个索引的代价

这需要付出一定的成本，而且应在做出决策之前就加以考虑，而非在出现问题之后：

需要更多的磁盘空间，具体数量取决于配置；
融合处理步骤会多花费几毫秒时间；
最重要的是，还可能出现另一个不同步的问题。如果某个文档从向量索引中被移除，但仍然存在于词汇索引中，它就会像幽灵一样不断出现。

已经在使用 Postgres 的团队通常可以通过将 pgvector 与内置的全文搜索功能结合使用来获得词汇索引的优势，整个过程完全基于 SQL，无需新增基础设施。如果现有的 RAG 系统仅依赖向量索引，那么更值得探讨的是为何没有采用 BM25 算法，这其实是技术债务的问题，而非创新不足的表现。

混合方案的优势与劣势

供应商们的一致观点似乎表明混合检索方式总是更优。但实际测试结果更为复杂，一旦按查询类型而非平均值来分析分数，就会出现令人困惑的结果。

在微软2023年的Azure AI Search对比中，混合检索方式在总体表现上优于仅使用向量检索的方式。但从不同类别来看，情况就没那么乐观了：对于纯粹的关键词式查询，单一词汇引擎的评分可能高于混合检索的结果。平均值会掩盖逐项分析所揭示的信息。

第二种引擎并不总能提升性能

无论在何种情况下词汇引擎的判断是正确的，第二种引擎的参与都会削弱这一优势。假设BM25算法将正确文档排在第一位，而向量算法则将其排在第十位，那么混合检索方式会让它的排名低于两种算法都认为第三位的文档。一致性虽比准确性更重要，但这正是设计初衷，同时也会在某些查询类型上带来一定的损失。

第二阶段的性能同样重要。在科学语料库上对第一阶段检索进行的测试表明，基于弱嵌入模型的混合方法的结果仅略高于BM25本身，而使用更强模型的相同配置则明显优于前者。融合并不会创造新事物，它只是将现有证据混合在一起，噪声也会获得与信号同等的权重。

这并不与开篇的观点相矛盾。嵌入质量决定了向量部分能带来多大的提升，但即便是最好的嵌入也无法恢复它所不代表的精确标识符。这是两个独立的维度。

这两个结果都并非反对混合搜索，而是反对在未测量自身查询分布的情况下就使用它。许多团队将混合搜索视为显而易见的默认选项，却从未统计过相关的查询分布。

这种测量方法成本很低。只需将查询日志分为带有精确标识符的查询和纯概念性查询，然后分别为每组计算指标即可。这需要数小时时间，而非短时间内就能完成，而一个汇总数值则会掩盖那些日后会在实际应用中造成问题的性能下降。

共识问题

排名融合存在一个更为微妙的缺陷，它会在各个引擎意见一致时显现出来，而在意见不一致时则看不出来。

以搜索技术文档为例，查询内容是关于如何通过环境变量配置OAuth的。向量检索会返回一份通用的安全指南：在精神上相关，但没有涉及OAuth的具体细节。BM25则会返回一个关于OAuth的精确匹配结果，但那是在三年前的更新日志中。这两种结果都不是最佳答案，而排名融合仍会将两者中较弱的那个排在前面。

这是RRF工作原理的直接结果。那份过时的更新日志被两个引擎都评为中等水平，因此它的两个互反排名之和超过了只有单个引擎认可的新鲜页面的排名。两个一般性的评价胜过一个明确且正确的评价。

融合前的过滤

修复措施位于数学计算之前。在大多数情况下，诸如新鲜度、权限和文档状态之类的严格元数据过滤应在融合之前进行，而非之后。融合过程不应看到那些从一开始就不被允许参与的候选项。有些生产系统在之后进行过滤并获得了良好结果，因此这属于需要根据自身语料库进行测试的架构决策，而非普遍适用的规则。

此处顺序并非出于美观考虑。在融合处理后进行过滤会将过时的页面从结果中剔除，但那些已经失去投票支持且低于阈值的新页面依然会保留。如果在融合处理前就进行过滤，就会改变两种算法最初用于投票的候选页面池。

实际上，应在两个流程的入口同时应用三种过滤条件：用户权限、文档状态以及适合该领域的新鲜度窗口。两个流程必须应用完全相同的过滤条件。否则，一个流程的候选列表中会出现另一个流程从未见过的文档，而融合处理会将这种不对称性转化为排名优势。

对于形态变化丰富的语言而言还有另一点优势。复杂的词形变化会破坏词汇匹配。如果没有良好的词形还原功能，BM25的优势就会大打折扣，因为同一个词的不同词形，比如波兰语中的umowy和umowie，或是德语中的Vertrags和Verträgen，看起来就像是完全不同的词条。这是向量方法能够拯救词汇方法、而非相反的罕见情况。

因此，混合方法虽然能修正一类错误，却会引发新的错误，在不进行验证的情况下，无法默认信任检索流程中的任何环节。

由此可得的启示

检索失败率下降49%，并非因为使用了更大的模型或更强的GPU，而是因为人们意识到，单一的文本表示方式无法满足两种本质上不同的查询类型的需求。

BM25与向量检索在相反方向上表现不佳，这正是将二者结合的结构性原因。
RRF合并的是排名位置而非得分，因为BM25与余弦相似度尺度不兼容，且标准化也无法彻底消除校准成本。
混合检索是基础设施供应商的默认方案，因此跳过第二种检索方式属于技术债务，而非保守做法。
默认方案并不代表普遍更优。在精确标识符查询中，单独使用BM25就能优于融合检索方式，而平均指标会掩盖这一事实。
应在融合检索之前应用元数据过滤器，否则各检索引擎之间的匹配度会导致过时文档优先于新文档被展示。

对于下周，选取最后一千条真实查询，将每条标记为包含精确标识符或纯概念性内容，然后计算两者的比例。接着分别评估这两组数据的准确率，保留两行结果而非混合平均值。这张表格比任何供应商的基准数据都更能说明混合索引是否能提升您的系统性能，还是只会增加另一项需要维护的索引。该结果还能显示您的流量中有多少依赖于精确字符串，而这通常是没人统计过的。