RAG 重排序详解
RAG 重排序详解：Rerank、RRF 与效果评估
一、为什么需要重排序？
检索阶段（无论关键词还是向量检索）的目标是召回——尽可能把相关内容找出来，宁可多召回也不能漏。
但召回的结果往往有噪音：
用户问："Python 列表和元组有什么区别？"
向量检索 Top-5 召回：
#1 "列表和元组的区别：列表可变，元组不可变..." ← 完美相关 ✅
#2 "Python 数据结构概览：列表、元组、字典..." ← 相关 ✅
#3 "元组的使用场景和性能优势..." ← 相关 ✅
#4 "Python 列表推导式详解..." ← 有点相关，但不是重点 ⚠️
#5 "如何遍历 Python 列表..." ← 关系不大 ❌如果直接把这 5 块都塞给 LLM，第 4、5 块是噪音，会干扰生成质量，而且浪费 token。
重排序（Reranking）的作用：对召回结果再做一次精细打分，过滤噪音，把最相关的排到最前面。
二、Rerank 是什么？
原理
Rerank 是一个专门训练的交叉编码器模型（Cross-Encoder），它把”查询”和”每个候选文档”拼在一起输入模型，让模型直接给出一个相关性分数。
Cross-Encoder 输入方式：
["查询: Python列表和元组区别 文档: 列表可变，元组不可变..."] → 相关性分数 0.97
["查询: Python列表和元组区别 文档: Python列表推导式详解..."] → 相关性分数 0.31
["查询: Python列表和元组区别 文档: 如何遍历Python列表..."] → 相关性分数 0.18模型同时”看到”查询和文档，能做深度语义交互，打分比向量检索准确得多。
和 Embedding 检索的对比（双塔 vs 交叉）
这是 Rerank 和向量检索在模型结构上的本质区别：
向量检索（双塔模型 Bi-Encoder）：
查询 → Encoder → 查询向量
→ 计算余弦相似度（简单点积）
文档 → Encoder → 文档向量
优点：文档向量可以离线预计算，查询时极快
缺点：查询和文档各自独立编码，无法深度交互，精度有上限
Rerank（交叉编码器 Cross-Encoder）：
[查询 + 文档] → Encoder → 相关性分数
优点：查询和文档一起编码，深度交互，精度高
缺点：每次查询都要重新计算，无法预计算，速度慢正因为 Cross-Encoder 速度慢，所以不能用于初始检索（几万个文档每个都跑一遍，太慢），只用于对已经召回的少量候选（如 Top-20）做精排。
Rerank 的完整流程
用户提问
↓
初始检索（向量/混合）：快速从百万文档中召回 Top-20
↓
Reranker 精排：对这 20 个文档逐一深度打分
↓
取 Top-3 或 Top-5 送给 LLM
↓
生成回答常用 Rerank 模型
| 模型 | 提供方 | 特点 |
|---|---|---|
rerank-english-v3.0 | Cohere | 英文效果强，API 调用 |
bge-reranker-v2-m3 | 北京智源 | 中英文，可本地部署，免费 |
bge-reranker-large | 北京智源 | 中文效果优秀 |
jina-reranker-v2 | Jina AI | 多语言，开源 |
ms-marco-MiniLM | 微软 | 轻量，速度快 |
三、RRF 是什么？
RRF（Reciprocal Rank Fusion）是一种结果融合算法，不是模型，不需要训练。
它解决的问题是：把多路检索结果合并成一个统一排名。
公式：RRF(d) = Σ 1 / (k + rank_i(d))
k = 60（常数，防止第1名权重过大）
rank_i(d) = 文档 d 在第 i 路检索中的排名RRF 只关心排名位置，不关心具体得分数值，因此不需要对不同来源的分数做归一化。
四、Rerank 和 RRF 的区别与联系
这是很多人容易混淆的地方，它们解决的是不同阶段的问题：
| RRF | Rerank | |
|---|---|---|
| 本质 | 排名融合算法 | 精排模型 |
| 作用阶段 | 多路召回结果合并 | 单路或合并后的精排 |
| 是否需要模型 | 不需要，纯数学公式 | 需要，Cross-Encoder 模型 |
| 是否理解语义 | 不理解，只看排名位置 | 深度理解查询和文档的语义关系 |
| 速度 | 极快（毫秒级） | 慢（每个候选都要跑模型推理） |
| 成本 | 零成本 | 有计算成本（GPU 或 API 费用） |
| 精度 | 中等（融合多路，互补短板） | 高（深度语义交互） |
在 RAG 流水线中的位置
用户提问
│
├──────────────────────┐
↓ ↓
关键词检索 Top-20 向量检索 Top-20
│ │
└──────────┬────────────┘
↓
RRF 融合排名 ← RRF 的位置：合并两路结果
↓
合并后 Top-30
↓
Reranker 精排 ← Rerank 的位置：对合并结果做语义精排
↓
最终 Top-5
↓
构造 Prompt → LLM一句话区分
- RRF = 数学公式，解决”多路结果怎么合成一个列表”的问题，不理解内容
- Rerank = AI 模型，解决”这些候选里哪个真正最相关”的问题，深度理解内容
两者经常配合使用：先 RRF 合并多路召回，再 Rerank 精排。
五、怎么知道重排序的结果是对的？
这是 RAG 工程中最难的问题之一：没有标准答案的情况下，怎么评估检索质量？
方法一：构建评估数据集（黄金标准）
手动标注一批”问题 → 正确文档”的对，作为评估基准：
评估集示例：
问题： "Python 列表和元组的区别？"
正确文档块ID： ["chunk_042", "chunk_156"] ← 人工标注
然后跑检索，看 Top-K 里有没有包含正确文档块：
召回了 chunk_042 ✅
没召回 chunk_156 ❌核心指标：
Hit Rate（命中率）：
Top-K 结果中包含至少一个正确文档的比例
例：100 个问题，85 个问题在 Top-5 里找到了正确答案 → Hit Rate = 85%
MRR（平均倒数排名，Mean Reciprocal Rank）：
正确文档排在第几位？越靠前越好
第1位 → 得分 1/1 = 1.0
第2位 → 得分 1/2 = 0.5
第3位 → 得分 1/3 = 0.33
未召回 → 得分 0
所有问题取平均 = MRR
NDCG（归一化折损累积增益）：
综合考虑召回数量和排名位置的评估指标，适合多文档相关的场景方法二：用 LLM 自动生成评估集
人工标注成本高，可以用 LLM 自动生成问答对：
流程：
1. 取每个文档块
2. 让 LLM 根据这段内容生成 2-3 个相关问题
3. 形成"问题 → 来源文档块"的评估集
4. 用这个评估集跑检索，计算 Hit Rate / MRR
Prompt 示例：
"根据以下文档内容，生成3个用户可能会问的问题，
要求问题的答案必须能在文档中找到：
[文档内容]"优点：低成本，覆盖面广 缺点：LLM 生成的问题可能和真实用户提问方式有差距
方法三：端到端评估（RAGAS 框架）
不单独评估检索，而是整体评估 RAG 系统的输出质量。
RAGAS 是目前最流行的 RAG 评估框架，核心指标：
| 指标 | 评估什么 | 计算方式 |
|---|---|---|
| Context Precision | 召回的文档是否都相关（精确率） | 召回文档中相关的比例 |
| Context Recall | 相关文档是否都被召回（召回率） | 相关文档被找到的比例 |
| Faithfulness | 生成的回答是否忠实于检索内容 | 回答中的陈述能否在检索文档中找到依据 |
| Answer Relevance | 生成的回答是否回答了问题 | 回答和问题的相关程度 |
Context Precision 和 Recall 的取舍：
精确率高 精确率低
召回率高 ✅ 最好 ⚠️ 有噪音但不漏
召回率低 ⚠️ 结果准但不全 ❌ 最差
实践中：先保证召回率（宁可多召），再用 Rerank 提升精确率方法四：A/B 对比评估
对同一批问题，分别用”有 Rerank”和”无 Rerank”两套配置跑，让 LLM 或人工判断哪个回答更好：
问题： "苹果 M4 芯片的性能怎么样？"
无 Rerank 的回答：[召回了3块相关+2块噪音，回答有点跑偏]
有 Rerank 的回答：[召回了5块高相关，回答准确详细]
→ 胜率统计：Rerank 版本在 78% 的问题上回答更好方法五：业务指标监控（上线后）
上线后通过用户行为来间接评估：
直接指标：
✅ 用户采纳率（用户对回答是否满意）
✅ 用户追问率（追问说明上次没回答好）
✅ 显式好评/差评收集
间接指标：
✅ 回答引用了正确来源的比例
✅ 回答中"我不知道"的比例（太高说明召回不行）
✅ 回答中出现幻觉/错误信息的比例六、实践建议
评估优先级：
1. 先快速跑通（无评估）
↓
2. 用 LLM 自动生成评估集，建立基准指标（Hit Rate / MRR）
↓
3. 用 RAGAS 做端到端评估，确认 Rerank 有没有带来提升
↓
4. 上线后持续收集用户反馈，迭代优化关键原则：
- Rerank 不是万能的：如果初始召回就没把正确文档找回来，Rerank 也救不了（它只能对已召回的结果重排，不能凭空召回新内容）
- 先保证召回率，再用 Rerank 提精确率
- 没有绝对正确的重排序，只有在你的数据集上更好的重排序
七、一句话总结
- Rerank = AI 精读每个候选文档，打出精准的相关性分数，解决”哪个最好”
- RRF = 数学公式，把多路检索结果的排名融合成一个，解决”多路怎么合并”
- 评估重排序效果 = 构建评估集 → 计算 Hit Rate/MRR → 用 RAGAS 端到端评估 → 上线后监控业务指标
我做的
BGE 系列一般指 BAAI / 智源开源的语义向量与重排序模型系列，全称常理解为 BAAI General Embedding。
它不是一个单独模型，而是一整套用于 RAG 检索链路的模型家族，常见两类：
-
Embedding 模型 用来把 query / 文档片段转成向量，做相似度检索。
例子：
bge-small-zhbge-base-zhbge-large-zhbge-m3
-
Rerank 模型 用来对初步召回的候选文档重新打分排序。
例子：
bge-reranker-basebge-reranker-largebge-reranker-v2-m3
放到 RAG 流程里就是：
用户问题
↓
Embedding 模型：把问题变成向量
↓
向量库召回 Top-K 文档
↓
BGE Reranker：重新判断哪些文档最相关
↓
把最相关内容交给大模型生成回答所以你图里对方说“都是 bge 系列”，大概率意思是：
- embedding 用 BGE embedding 模型
- rerank 用 BGE reranker 模型
但这句话还不够精确。真正写到文档或简历里，最好问清楚具体型号，比如：
embedding 用的是
bge-large-zh还是bge-m3？
rerank 用的是bge-reranker-large还是bge-reranker-v2-m3？
一句话总结：BGE 是国产开源 RAG 检索模型家族，主要负责“把文本变成向量”和“对召回结果重新排序”。