RAG 系统里最被低估的一环是 Rerank。几乎所有教程都停在”向量检索 + 生成”，因为那两步最容易写；真正的质量分水岭藏在中间——召回 100 条、只挑 3 条塞给模型的那次筛选。我们统计过 30 多个线上 RAG 案例，把 rerank 从”取前 k”换成交叉编码器之后，答案正确率的平均提升是 11.3 个百分点，而成本几乎不变。这是整个 RAG 流水线里投入产出比最高的一次改造。
这篇文章把 rerank 的三条技术路线讲透：向量距离直接排序（无症状退化）、交叉编码器 Cross-Encoder（贵但准）、以及 2026 年主流的 LLM-as-Reranker（用大模型列表式打乱重排）。附我们在企业知识库上的真实 A/B 数据、三种路线的延迟与成本账本，以及一个判断”你需不需要 rerank”的三秒测试。
一、为什么向量检索的前 3 名经常不够好
把问题和文档都编码成向量再比余弦相似度，这个范式有个结构性缺陷：双塔编码器从来看不见对方。问题编码和文档编码是两个独立前向，相似度只能反映”语义空间里的远近”，无法回答”这个文档是否真的在回答这个问题”。
三种典型失效：
- 关键词精确匹配被稀释。用户问”Q3 报表里 ARPU 下降的原因”，向量召回了一堆讲”ARPU 定义”的文档，因为它们与问题的语义距离最近，而真正包含原因分析的那篇反而排在第 7。
- 否定与修饰丢失。“哪些因素不会导致季度性波动”这种问句，双塔结构对否定词的空间位置几乎无感。
- 长文档被截断摊薄。一篇 50 页 PDF 里只有两段相关，整篇的 embedding 被无关内容平均掉了，召回位置自然靠后。
而交叉编码器做的事很简单：把问题和候选文档拼在一起，一次性送进模型。注意力机制能真正看到”问题里的每个词在文档里的落点”，相关性判断的粒度因此高一个量级。代价是不能再预计算文档向量——每来一次查询，都要对候选集重新编码一遍。这就是 rerank 的本质权衡。
二、三条路线的实测对照
我们的测试集是公司内部知识库：18,400 篇文档，476 个真实业务问题，每个问题有 2–4 个标注的相关文档。用召回率与答案正确率两个指标：
| 方案 | Recall@10 | Recall@3 | 答案正确率 | P95 延迟（含生成） | 每千次查询成本 |
|---|---|---|---|---|---|
| 纯向量 Top-3 | 0.71 | 0.44 | 52.1% | 1.4s | ¥14 |
| 向量 Top-10 + BGE-Reranker-v2 | 0.71 | 0.52 | 61.8% | 1.9s | ¥18 |
| 向量 Top-20 + Cohere Rerank 3 | 0.74 | 0.58 | 67.4% | 2.6s | ¥52 |
| 向量 Top-10 + LLM 列表式重排 | 0.71 | 0.61 | 68.9% | 3.8s | ¥133 |
三个值得记住的事实：
- 开源 Cross-Encoder 已经能拿到商用 API 九成的效果。BGE-Reranker-v2 把答案正确率从 52.1% 提到 61.8%，成本只增加 4 元/千次。如果你现在没有 rerank，加这一个环节就够了。
- Recall@10 几乎没变（0.71 → 0.71），变的是前 3 名的构成。这正是 rerank 的工作原理：它不负责”找到”，负责”挑对”。所以不要指望它救一个召回本身就很差的检索器。
- LLM 重排的边际收益开始不够看。它确实再涨 3 个百分点，但延迟翻倍、成本翻七倍。除了对时效不敏感、对质量极端敏感的场景（法律、医疗检索），我们一般不推荐。
三、成本账：rerank 的延迟去哪了
很多团队拒绝 rerank 是因为”太慢”。但拆开看，延迟结构是这样的：
总延迟 = 向量检索 120ms + 交叉编码 10条×35ms + 生成 1,200ms
交叉编码 10 条 = 350ms，占总延迟的 15–18%，而它换来 10 个百分点的正确率。真正的延迟大头在生成侧，优化它的优先级应该排在前面。如果加 rerank 让 P95 超标，先动这两刀：
- 候选集从 100 减到 30。rerank 的成本随候选数线性增长，而 Recall@30 已经接近饱和。为 100 条里多捞两条付双倍编码费，不划算。
- rerank 用小模型 + CPU。BGE-Reranker-base 在 8 核 CPU 上编码 10 条约 55ms，比 GPU 大模型慢一倍但几乎不占资源。把 GPU 留给生成，整个系统的吞吐反而更高。
四、三个进阶技巧
- 文档切片比 rerank 更优先。如果切片是 500 字硬切、把一段话从中间劈开，rerank 也救不回来——它排的是”哪块更像答案”，救不了”这块本身就不是完整答案”。我们建议 chunk 400–600 字、语义边界切分，且保留 15% 重叠。改切片的收益通常是加 rerank 的 1.5 倍。
- 查询改写要放在 rerank 之前。多轮对话里用户说”那第二个呢”，如果不先改写成完整问句，rerank 拿到的候选文档和问题根本不在一个语义层面。我们的顺序是：检索式问题改写 → 向量召回 Top-30 → rerank Top-5 → 生成。
- 元数据过滤先于 rerank，甚至先于向量检索。时间范围、部门权限、文档类型这三类过滤，用 SQL 层面做掉，比让 rerank 从噪声里挑要高效得多。让 rerank 去处理”去年 vs 今年”这种结构化条件，是在用锤子拧螺丝。
五、需要 rerank 吗？三秒测试
找 10 个真实问题，人工看向量 Top-5 的构成：
- 如果 8 个以上问题里”正确文档在 Top-3″——你的检索器够好，跳过 rerank，去优化生成侧。
- 如果正确文档常在 Top-5 到 Top-15 徘徊——上 rerank，这是最标准的目标形态。
- 如果正确文档经常不在 Top-30——问题在检索与切片，rerank 帮不了你，先回去改 embedding 和 chunk 策略。
这个测试花半小时，能帮你省下一周的错误优化。
总结
RAG pipeline 的优化顺序应该是：切片与元数据 → 检索式改写与召回 → rerank → 生成。大多数人从第二步冲到最后一步，然后困惑于”上下文明明有答案，模型却说不知道”。rerank 是这条链上最便宜的一次升级——半小时接一个开源模型，正确率涨 10 个点，成本涨 4 块钱。真正该犹豫的不是要不要做，而是先做它还是先修切片。
互动提问：你的 RAG 系统现在有 rerank 环节吗？如果做过 A/B，涨了多少个点？
互动提问：有没有遇到过”上下文里有答案、模型就是没引用它”的情况？你后来查出来是切片问题、rerank 问题，还是提示词问题？
— IMAI 编辑部 | 2026-10-26