直接答案
Rerank(重排)在粗召回之后加一道精排:用 Cross-Encoder 模型把"问题+文档"成对打分,对 Top 50 候选重排序,只把最相关的 3-5 块送进大模型。它解决的是召回"找得到但排不对"的问题——相关内容在第 30 名,模型上下文只放前 5 名,等于白召回。加上 Rerank 后,常见项目回答准确率可再提升 10-15 个百分点。
为什么召回之后还需要重排
向量检索用的 Bi-Encoder 架构,问题和文档各自独立编码成向量再算距离,速度快(百万库毫秒级),但两段文本没有"见过面",细粒度相关性判断天然受限。Cross-Encoder 则把问题和文档拼接后一起送进模型,逐对计算精确相关性分数,精度高一个量级,但速度慢两个量级。于是工程上取长补短:Bi-Encoder 从百万库里海选出 50 条,Cross-Encoder 只对这 50 条精排——这就是两阶段检索。
怎么落地
开源方案首选 bge-reranker-v2-m3:多语言、可免费商用、CPU 也能跑。接入位置在混合检索(RRF 融合)之后、拼上下文之前:取融合后的 Top 50,逐对重排,输出 Top 5。云 API 方面,各主流厂商的 rerank 接口可直接调用,按次数计费。注意上下文预算:重排后塞入的块数不是越多越好,5 块左右通常优于 10 块,噪声块会稀释模型注意力。
成本与延迟控制
| 策略 | 做法 | 适用 |
|---|---|---|
| 降候选量 | 重排候选从 100 降到 30-50 | 延迟敏感 |
| 轻量模型 | 用 reranker-base 而非 large | 成本敏感 |
| 级联过滤 | 先用分数阈值砍掉明显不相关候选 | 长尾问题多 |
| 缓存热问 | 高频问题的重排结果缓存复用 | 流量集中 |
小结
RAG 检索链路的成熟形态是:混合检索粗召回 → Rerank 精排 → 截断进上下文。如果目前只有第一段,加 Rerank 是继混合检索之后的第二个高性价比优化点。
常见问题快答
Rerank 模型必须 GPU 吗?
不一定。bge-reranker-base 级别 CPU 可跑,50 条候选的推理延迟在几十毫秒级,中小流量完全够用。
重排多少条候选合适?
30-50 条是性价比区间,超过 100 条延迟明显增加而尾部候选本身相关概率很低。
怎么判断 Rerank 有没有效果?
用评测集对比加前后的 Recall@5 与最终回答准确率,固定其他变量只切换 Rerank 开关。
最后更新于 2026-07-26。本文持续修订,重大更新会标注日期。
