倒数排名融合（RRF）：为什么合并搜索结果比看起来更难
Redis 官方博客发表文章，由 Jeff Mills 撰写，深入解读倒数排名融合（Reciprocal Rank Fusion，RRF）这一搜索技术。背景：你运行关键词搜索得到带 BM25 分数的排名列表，对同一批文档运行向量搜索得到带余弦相似度的第二份列表，想合并成单一排名以同时保留关键词搜索的精确匹配和向量搜索的语义匹配。把两个分数相加看似显然，但可能以难以察觉的方式破坏排名。许多搜索系统采用的方案是 2009 年提出的一个可以写在餐巾纸上的公式：RRF。本文基于 Redis 官方文章，系统解读 RRF 的原理、为什么不能直接加分数、以及在生产系统中的位置。
什么是倒数排名融合（RRF）
倒数排名融合仅使用每个文档在每个列表中的位置来合并多个排名列表，完全忽略原始分数。
- 2009 年提出
- 融合不同检索系统的输出时，几乎总是优于融合结果中的最佳单系统
- 公式很短：对每个文档 d 出现的每个排名列表，取 1 除以（k 加上 d 在该列表中的排名），跨所有列表求和
- 常数 k 通常设为 60，原始研究者发现这个值表现良好且不特别敏感
k 的作用
k 承担两个任务：
- 软化单个检索器将文档排得异常高的影响
- 让低排名文档不会完全消失
一个具体例子
- 文档被关键词搜索排第 2、向量搜索排第 5：得分约 0.0315
- 文档被关键词搜索排第 1、但不在向量结果中：得分约 0.016
- 两个检索器都同意的文档获胜，即使两者都没把它排第一
- 跨检索器的一致性胜过单一的第一名
RRF 流行的两个性质
- 无监督：不需要标注查询或训练数据
- 通用：接受任何检索器产生的排名列表
为什么不能直接加 BM25 和向量搜索分数
不兼容的标度
- BM25 分数没有固定的通用范围，随实现、查询和语料库变化
- 余弦相似度在固定范围 -1 到 1 之间
- 两者相加时，BM25 通常默认获胜，因为其绝对值往往大一个数量级
归一化的锐边
归一化是通常的补救方法：
- 把两组分数重新缩放到共同范围，标度至少匹配
- 但归一化有尖锐的边缘：
- 单个离群分数会把其他所有分数压缩到窄带
- 关键词和向量的正确混合比例随查询而变化
- 在生产规模下按查询校准权重不现实
漂移问题
- BM25 分数分布随索引增长和词频变化而移动
- 向量分数分布在更换嵌入模型时变化
- 1 月互相校准的两个分数流，到 6 月可能失准
- 失败不总是明显的：排名质量可能逐渐下降，而不显示任何明显损坏
- 更早的基于分数的融合方法遇到同样的墙：输入未归一化时，标度不匹配直接带入合并排名
基于排名的融合如何绕开标度问题
如果原始分数不可靠，修复方法是忽略它们，转而使用两个检索器都同意的信息：每个文档在排名列表中的位置。这一单一改变就是 RRF 的核心优势——位置信息天然可比，不受不同检索器分数标度差异的影响。
RRF 在生产系统中的位置
检索速度比融合步骤本身更重要
文章中强调的一个关键观点：为什么检索速度比融合步骤本身更重要。RRF 的融合计算非常轻量（只做排名位置的倒数求和），真正的瓶颈在于多个检索器本身的检索速度。在生产系统中，先优化各检索通道的延迟，融合步骤的开销几乎可以忽略。
应用场景
- 混合检索（混合搜索）：关键词（BM25）+ 向量（语义）融合
- 多路召回融合：多个检索通道（如不同的嵌入模型、不同的检索算法）的结果合并
- RAG 管线中的检索阶段
实践建议
何时用 RRF
- 需要融合不同标度、不同来源的排名结果时
- 不想维护按查询校准的权重
- 没有标注数据训练学习式融合模型
注意事项
- k 从 60 开始调整
- 融合前先确保各检索通道质量
- 关注检索延迟而非融合计算开销
- 监控排名质量随时间的漂移（换嵌入模型、索引增长时）
总结
RRF 是 2009 年提出的排名融合算法，只用文档在每个排名列表中的位置（1/(k+rank) 求和，k 通常 60），完全忽略原始分数。核心优势：无监督、接受任何检索器输出、跨检索器一致性优于单一第一名。为什么不能直接加 BM25 和余弦分数：两者标度不兼容（BM25 无固定范围且绝对值常大一个数量级）、归一化有锐边（离群值压缩、按查询校准不现实）、漂移问题（索引增长和嵌入模型更换使校准失准且失败不明显）。RRF 绕开问题的方式是忽略分数、只用位置——位置天然可比。生产要点：融合计算本身轻量，检索速度才是瓶颈；适用于混合检索、多路召回和 RAG 检索阶段。对构建搜索和 RAG 系统的团队，RRF 是融合异构检索结果的可靠基线方案，避免了分数归一化和权重校准的运维负担。
来源：https://redis.io/blog/reciprocal-rank-fusion/