Elasticsearch 不愿免费的秘密武器—RRF（TorchV 版）

# Elasticsearch 不愿免费的秘密武器—RRF（TorchV 版）

[官网直达链接](https://www.torchv.com/)

随着 **AI 搜索技术**的飞速发展，以 **RAG（检索增强生成）** 为代表的检索技术日益成熟。从基础的 SimpleRAG 到进阶的 AdvanceRAG，乃至灵活的 ModularRAG，优化策略层出不穷。在这股浪潮中，我们不难发现**混合检索**、**多路召回**、**问题扩展**等技术已成为业界的普遍共识。

然而，这些看似花样繁多的技术，却有一个共同的“痛点”：它们都需要进行多次召回，并妥善处理**多次召回结果的融合**。

以混合检索为例：

想象一下，你的 AI 知识库系统同时运行着强大的向量检索（理解语义）和精准的关键词检索（匹配字词）。理想情况下，它们应该珠联璧合，召回最相关的结果。但现实是，**如何让这两个“语言不通”的伙伴达成共识，排出最终的最优列表？** 这，正是多路召回（Multi-Retrieval Path）策略面临的核心挑战：如何平衡多种检索器召回结果之间的差异？

在 TorchV 团队的实践中，我们发现了一种被广泛低估但极为有效的算法——**倒数排名融合（Reciprocal Rank Fusion, RRF）**。

### 一、 检索分数，一个棘手的问题

在混合检索场景下，不同检索器所生成的相关性分数往往是**“不可通约”**的。接下来，我们以 Elasticsearch 的实现为例，深入探讨这个问题。

例如，基于余弦相似度的向量检索分数通常介于0到1之间，且其分布可能较为集中；


*如图中多个位次的得分均为0.8左右*

而基于 BM25 算法的关键词检索分数则可能是一个范围极大的正数，其量级与分布特性与向量相似度截然不同。


*如图中第一位次的数据得分17.95*

这种内在的**分数尺度差异**，使得融合成为一大挑战。

在早期的 ES 检索中，我们会使用boost参数用于混合两个子查询的权重。Boost 值是一个**相对权重**，它增加了对应查询部分在相关性评分中的**影响力**，但该分值并不是绝对的 ：

​ 新分数 ≈ 旧分数 * boost

在 BM25 分数极大的情况下，即使设置了 `boost`，依然难以限制关键词搜索的分数**大幅超过**向量检索。更何况，BM25 召回结果既不存在固定区间，也非线性分布，这就导致难以找到一个合适的 `boost` 值来混合两者，达到理想的权重平衡。

因此简单地采用线性归一化或加权平均等方法进行融合，极易导致某一检索器的分数权重被不恰当地放大或缩小，从而无法实现有效的融合。

### 二、RRF：化“分”为“秩”的巧妙之道

因此我们引入了 RRF 进行优化, RRF 的分数计算方式为


别担心，让我们一步步来理解这个公式。首先，假设只有一个检索器，此时检索结果如下：


这里我们假设平滑因子 k=60。

```

DOC1 的分数 = 1/ （平滑因子+所排位次） = 1 /61 = 0.0164DOC2，DOC3的分数也以此类推。

```

------

现在我们引入第二个检索器


我们分别对某一个 DOC 在 A、B 两个检索器中的得分求和：

```

DOC1 的分数 = 1/ （平滑因子+ A 所排位次）+ 1/ （平滑因子+ B所排位次）= 1/61 + 1/63 = 0.0323DOC2 的分数 = 1/62 + 1/61 = 0.0325

```

那么最终的排序就会是 **DOC2 -> DOC1 -> DOC4 -> DOC3**

------

最后我们在此基础上为不同的检索器加上权重(Weight)


此时的计算结果

```

DOC1 的分数 = 0.9 * （1/ （平滑因子+ A所排位次））+ 0.1 * （1/ （平滑因子+ B所排位次））= 0.9 * 1/61 + 0.1 * 1/63 = 0.0163DOC2 的分数 = 0.0162

```

此时就由于 A 检索器的权重较高，最终排序 **DOC1 -> DOC2 -> DOC3 -> DOC4**

此时也能总结出这个公式（只是比数学表示略逊一筹）


**RRF 的精妙之处在于其对原始分数的规避。** 它不依赖于检索器输出的**具体相关性分数**，而是专注于文档在每个检索结果列表中的**相对“排名”**。通过将排名转换为倒数形式并进行加权求和，RRF 能够有效地融合来自不同检索器的结果，即使这些检索器的评分机制存在显著差异，也能基于统一的排名维度公平地衡量文档的综合相关性，从而避免了复杂且易出错的分数归一化问题。

但在实践的过程中，我们也留意到 ES 对于 RRF 具有**许可证限制**，一般的开源社区版无法使用 RRF 进行重排序：


*ES 内置 RRF 的许可证限制*

在 TorchV 当前版本的召回链路中，我们通过程序内归一化的实现手段巧妙地规避了这个问题。但持续关注行业前沿动向时我们也欣喜地发现，在 Elasticsearch 8.16+ 的较高版本中，新增了**检索器（retrievers）**功能，并在其中支持了 RRF 的使用。这无疑为开发者们在未来的检索中提供了更多的选择，值得期待！


*https://www.elastic.co/docs/reference/elasticsearch/rest-apis/retrievers*

### 三、RRF 的更多“隐藏”用途

RRF 虽然设计之初主要用于混合多个检索器的结果，但在 RAG 场景中，它仍有大量可施展拳脚的地方。例如在**问题分解**的场景下：

用户查询：“公司贷款政策和申请流程是什么？”

分解为：

- 子问题 1：“公司贷款政策有哪些？”

- 子问题 2：“公司贷款申请流程是什么？”

对多个子问题并行检索的结果，我们就可以**使用 RRF 进行融合**，从而更全面地回答用户的复杂查询。

### 四、实际应用效果评估

在我们的测试评估中，集成 RRF 算法的召回链路带来了显著的效果提升。

目前 TorchV 的极高召回率中，RRF 就贡献了**约 10% 的提升**，这份战绩不可谓不大。

当然，尽管 RRF 看起来是一把“能斩断乱麻的快刀”，但也存在其本身的局限性，其只关注于位次排序的特点也注定其无法对**召回结果本身的分数**给予考虑。这使得微调和优化变得颇具挑战性。

在检索结果融合上，我们也看到了 Linear、MinMax、Sigmod 等等更多的方式，其各有优劣，在不同的组件中发挥作用。

**TorchV 作为专业为企业打造的 AI 知识引擎，可以开箱即用！它在底层架构上原生支持 BM25 词法索引与 HNSW 向量索引，将复杂的系统维护与数据同步问题封装在平台内部。对于企业而言，这意味着无需投入庞大的工程团队去搭建和维护割裂的检索组件，而是能够通过一个稳定、可靠、安全的平台，快速构建起能够精准理解内部知识、赋能员工、提升决策效率的 AI 知识库。开发者只需通过一次简洁的 API 调用，即可同时完成关键词检索、向量检索以及 RRF 融合，将原本复杂的工程任务，抽象成了一个极其清晰的意图声明，从而将精力聚焦于上层业务逻辑的创新。**

有更多需求的朋友也可以进一步探索分享！