RRF 混合检索 + BGE 重排序

摘要

纯向量检索擅长语义匹配但忽略关键词精确匹配，导致召回率受限。本文介绍RRF（Reciprocal Rank Fusion）混合检索和BGE-Reranker重排序方案，通过融合向量检索和 BM25 稀疏检索，在 Agentic RAG 系统中实现 Recall@10 从 0.67 提升至 0.82（+22%），MRR 从 0.61 提升至 0.76，无需调参且对异常分数鲁棒。

环境依赖：Python 3.11+, Qdrant Client 1.7.0+, rank-bm25 0.2.2+, transformers 4.36.0+

引言：为什么纯向量检索不够？

你的 RAG 系统用了最先进的 Embedding 模型，向量数据库也调优到极致。用户搜索"Transformer 的注意力机制"，系统返回了 10 个文档：

• 文档 1：《深度学习中的注意力机制综述》（相关！）
• 文档 2：《CNN 卷积神经网络的特征提取》（语义相近但主题不同）
• 文档 3：《RNN 的记忆机制与长短期依赖》（语义相近但主题不同）
• 文档 4：《BERT 的双向编码器架构》（弱相关）
• ...

问题出在哪？向量检索基于语义相似度，"注意力机制"、"卷积核"、"记忆机制"在语义空间中距离很近——它们都是神经网络的核心组件。但用户明确要找"Transformer"和"注意力机制"，这两个关键词必须同时出现。

向量检索的本质缺陷：擅长"语义相似"，但忽略了"关键词精确匹配"。当用户查询包含专有名词、技术术语、产品型号时，这个问题尤为严重。

解决方案？引入稀疏检索（BM25）作为补充——它基于词频统计，天然擅长关键词匹配。但如何融合两种检索结果？这就是本文要解决的核心问题。

传统混合检索的困境：分数不可比

最直观的做法是线性加权：

看起来很简单，但实践中有两个致命问题：

问题 1：α 怎么调？
不同类型的查询，最优 α 值不同：

• 事实查询（"公司地址是什么？"）：关键词匹配更重要，α 应该小（比如 0.3）
• 概念查询（"什么是分布式系统？"）：语义理解更重要，α 应该大（比如 0.8）

但你不可能为每个查询动态调整 α——这需要一个分类器，增加了系统复杂度。

问题 2：分数量纲不同

• 向量检索的余弦相似度：范围 [0, 1]，典型值 0.6-0.9
• BM25 分数：理论上无上限，典型值 5-50

当 BM25 出现极端高分（比如 80）时，即使 α=0.7，稀疏检索也会主导最终结果，向量检索形同虚设。

用架构图表示这个问题：

归一化？可以，但又引入了新问题：min-max 归一化对异常值敏感，z-score 归一化需要统计全局分布。有没有一种方法，既不需要调参，又能消除量纲差异？

RRF 登场：基于排名的融合

RRF（Reciprocal Rank Fusion）的核心思想只有一句话：不看分数，只看排名。

公式推导

其中 kkk 是一个常数，论文推荐值为 60。

为什么这个公式有效？

1. 消除量纲差异：排名是无量纲的整数（1, 2, 3, ...），不管原始分数是 0.85 还是 45，都被转换为统一的排名。

2. 对异常分数鲁棒：即使 BM25 出现极端高分，只要它在 BM25 排序中是第 1 名，贡献就是 160+1≈0.016\frac{1}{60+1} \approx 0.01660+11​≈0.016。不会像线性加权那样主导结果。

3. 平衡高分文档和低分文档：k=60k=60k=60 的作用是"软化"排名差异。如果 k=0k=0k=0，第 1 名贡献 1.0，第 2 名贡献 0.5，差距过大；k=60k=60k=60 时，第 1 名贡献 0.016，第 2 名贡献 0.016，差距平滑。

4. 无需调参：kkk 在 40-60 之间效果差异不大（论文验证），固定为 60 即可。

实验对比

我在 120 个测试查询上对比了三种融合方式：

为什么 RRF 比线性加权好？

• Recall@10 提升 9%：RRF 能更好地融合两种检索的优势。当向量检索失败时，BM25 的高排名文档能被有效提升；反之亦然。
• MRR 提升 10%：MRR（Mean Reciprocal Rank）衡量第一个相关文档的排名。RRF 通过排名融合，让真正相关的文档更容易排到前面。

代码实现：

from typing import List, Dict, Tuple def rrf_fusion( dense_results: List[Tuple[str, float]], sparse_results: List[Tuple[str, float]], k: int = 60 ) -> List[Tuple[str, float]]: """ RRF (Reciprocal Rank Fusion) 融合算法 Args: dense_results: 向量检索结果 [(doc_id, score), ...] sparse_results: BM25 检索结果 [(doc_id, score), ...] k: RRF 常数，论文推荐值 60 Returns: 融合后的结果 [(doc_id, rrf_score), ...]，按 rrf_score 降序排列 """ # 存储每个文档的 RRF 分数 rrf_scores = {} # 处理向量检索结果 for rank, (doc_id, _) in enumerate(dense_results, start=1): if doc_id not in rrf_scores: rrf_scores[doc_id] = 0.0 rrf_scores[doc_id] += 1.0 / (k + rank) # 处理 BM25 检索结果 for rank, (doc_id, _) in enumerate(sparse_results, start=1): if doc_id not in rrf_scores: rrf_scores[doc_id] = 0.0 rrf_scores[doc_id] += 1.0 / (k + rank) # 按 RRF 分数降序排序 sorted_results = sorted( rrf_scores.items(), key=lambda x: x[1], reverse=True ) return sorted_results # 使用示例 dense_results = [ ("doc1", 0.95), # 向量检索排名第 1 ("doc2", 0.88), # 向量检索排名第 2 ("doc3", 0.82), # 向量检索排名第 3 ] sparse_results = [ ("doc3", 45.2), # BM25 排名第 1 ("doc4", 38.1), # BM25 排名第 2 ("doc1", 32.5), # BM25 排名第 3 ] fused_results = rrf_fusion(dense_results, sparse_results, k=60) print("融合后的结果:") for doc_id, score in fused_results[:5]: print(f" {doc_id}: {score:.4f}") # 输出示例： # doc1: 0.0311 (在两个检索中都排名靠前) # doc3: 0.0295 (向量第3，BM25第1) # doc2: 0.0159 (只在向量检索中出现) # doc4: 0.0161 (只在BM25中出现)

为什么 RRF 有效？

从代码可以看出，RRF 的核心是1 / (k + rank)公式：

• 排名第 1 的文档贡献1/(60+1) ≈ 0.016
• 排名第 2 的文档贡献1/(60+2) ≈ 0.016
• 排名第 10 的文档贡献1/(60+10) ≈ 0.014

这种设计让排名差异被"软化"，避免了单一检索方法主导结果。

并行检索 + 融合流程

RRF 的实现流程：

css

代码解读

复制代码

用户 query ↓ ├─→ 向量检索（Qdrant） ──┐ │ 返回 Top-100 │ │ ├─→ RRF 融合 → 返回 Top-10 └─→ BM25 检索（rank_bm25）─┘ 返回 Top-100

关键优化：并行执行。向量检索和 BM25 检索是独立的，可以同时进行。

代码实现：

import asyncio from typing import List, Tuple from qdrant_client import QdrantClient from rank_bm25 import BM25Okapi class HybridRetriever: def __init__(self, qdrant_client: QdrantClient, bm25_index: BM25Okapi): self.qdrant_client = qdrant_client self.bm25_index = bm25_index async def vector_search(self, query_embedding: List[float], top_k: int = 100): """向量检索""" results = self.qdrant_client.search( collection_name="documents", query_vector=query_embedding, limit=top_k ) return [(r.id, r.score) for r in results] async def bm25_search(self, query_tokens: List[str], top_k: int = 100): """BM25 检索""" scores = self.bm25_index.get_scores(query_tokens) # 获取 top_k 个文档 top_indices = sorted( range(len(scores)), key=lambda i: scores[i], reverse=True )[:top_k] return [(str(i), scores[i]) for i in top_indices] async def hybrid_search( self, query_embedding: List[float], query_tokens: List[str], top_k: int = 10 ) -> List[Tuple[str, float]]: """并行混合检索""" # 并行执行向量检索和 BM25 检索 dense_results, sparse_results = await asyncio.gather( self.vector_search(query_embedding, top_k=100), self.bm25_search(query_tokens, top_k=100) ) # RRF 融合 fused_results = rrf_fusion(dense_results, sparse_results, k=60) return fused_results[:top_k] # 使用示例 async def main(): retriever = HybridRetriever(qdrant_client, bm25_index) query = "Transformer 的注意力机制" query_embedding = get_embedding(query) # 获取向量 query_tokens = tokenize(query) # 分词 results = await retriever.hybrid_search( query_embedding, query_tokens, top_k=10 ) print(f"检索到 {len(results)} 个文档") # 运行 asyncio.run(main())

性能提升：

• 串行执行：向量检索 250ms + BM25 检索 250ms = 500ms
• 并行执行：max(250ms, 250ms) + 融合 50ms = 350ms

延迟降低 30%，用户体验显著提升。

BGE-Reranker：重排序的最后一公里

RRF 融合后，我们得到了 Top-10 文档。但这 10 个文档真的都相关吗？

问题场景：用户搜索"如何优化 Transformer 推理速度"，RRF 返回的 Top-10 中可能包含：

• 文档 A：《Transformer 推理加速技术综述》（高度相关）
• 文档 B：《Transformer 训练优化方法》（主题不同，但关键词重叠）
• 文档 C：《BERT 模型压缩与量化》（弱相关）

向量检索和 BM25 都是"浅层"匹配——它们只看 query 和 document 的独立表示，不考虑两者的交互。Reranker 的作用是"深层"匹配：输入 query-document pair，输出精确的相关性分数。

为什么选 BGE-Reranker？

市面上有多种 Reranker 方案：

BGE-Reranker 是智源研究院开源的 Cross-Encoder 模型，在 MS MARCO 等基准上表现优异。关键优势：

1. 本地部署：数据不出本地，满足企业合规要求
2. 可微调：可以针对特定领域（比如法律、医疗）微调，提升效果
3. 延迟可控：150ms 的延迟在生产环境可接受

重排序在检索流程中的位置

css

代码解读

复制代码

用户 query ↓ RRF 混合检索 → Top-100 ↓ BGE-Reranker 重排序 → Top-10 ↓ 返回给 LLM 生成答案

为什么不直接对 Top-100 重排序？
Reranker 是 Cross-Encoder，需要对每个 query-document pair 单独计算。如果对 100 个文档重排序，需要 100 次前向传播，延迟会飙升到 1.5s。折中方案：先用 RRF 粗排到 Top-100，再用 Reranker 精排到 Top-10。

效果对比：每一步的价值

我在 Agentic RAG 系统中逐步加入 RRF 和 Reranker，对比每一步的提升：

关键发现：

1. RRF 主要提升 Recall@10：从 0.67 → 0.82（+22%）。这是因为 BM25 补充了向量检索遗漏的关键词匹配文档，扩大了召回范围。

2. Reranker 主要提升 Context Recall：从 0.70 → 0.74（+6%）。Context Recall 衡量的是"检索到的文档是否真的有用"，而非"是否检索到"。Reranker 通过精细化排序，把真正相关的文档排到前面，过滤掉噪音。

3. 延迟增加可控：从 250ms → 500ms，增加了 250ms。但考虑到 Recall 提升 22%，这个代价是值得的。如果延迟敏感，可以只用 RRF（350ms），放弃 Reranker。

实践中的踩坑与优化

坑 1：BM25 中文分词问题

问题：BM25 基于词频统计，需要先分词。英文可以用空格分词，但中文呢？

解决：使用jieba分词库。但要注意：

• 默认词典可能不包含领域专有名词（比如"Transformer"、"BERT"）
• 需要自定义词典，把高频技术术语加入

python

代码解读

复制代码

import jieba jieba.load_userdict("custom_dict.txt") # 自定义词典

坑 2：Reranker 加载慢

问题：BGE-Reranker 模型大小 1.3GB，每次加载需要 3-5 秒。如果每次请求都加载，延迟不可接受。

解决：单例模式，全局只加载一次。

[代码3: Reranker 单例模式]

坑 3：Qdrant 原生不支持 BM25

问题：Qdrant 是向量数据库，只支持向量检索，不支持 BM25。

解决：用rank_bm25库单独实现 BM25 检索。流程：

1. 文档入库时，同时存入 Qdrant（向量）和本地索引（BM25）
2. 检索时，并行查询 Qdrant 和 BM25 索引
3. 用 RRF 融合结果

注意：这意味着需要维护两份索引，增加了存储成本。如果文档量很大（百万级），可以考虑用 Elasticsearch（原生支持 BM25）替代 rank_bm25。

坑 4：RRF 的 k 值要不要调？

问题：论文推荐 k=60，但我的数据集是否需要调整？

解决：我测试了 k=40、50、60、70 四组，发现：

• k=40：Recall@10 = 0.81
• k=50：Recall@10 = 0.82
• k=60：Recall@10 = 0.82
• k=70：Recall@10 = 0.81

差异不大（<2%），说明 k 对结果不敏感。保持 k=60 即可，不需要调参。

总结与下期预告

本文介绍了 RRF 混合检索和 BGE-Reranker 重排序方案，核心要点：

1. RRF 解决分数不可比问题：通过排名融合，消除向量检索和 BM25 的量纲差异，无需调参。
2. 并行检索提升性能：向量检索和 BM25 并行执行，延迟降低 30%。
3. Reranker 做精细化排序：Cross-Encoder 深层匹配，过滤噪音文档。

在 Agentic RAG 系统中，这套方案实现了：

• Recall@10 +22%（0.67 → 0.82）
• Context Recall +6%（0.70 → 0.74）
• MRR +25%（0.61 → 0.76）

但检索只是 RAG 的第一步。检索到的文档如何切片？如何评估 RAG 系统的整体效果？下期我将深入解析：

• 语义切片算法：如何把长文档切成语义完整的 chunk
• Ragas 评估体系：如何用 Context Recall、Faithfulness 等指标量化 RAG 效果