Skip to content

10.3.3 什么时候值得加 Reranker? ​

先给结论:当你的问题主要不是“完全没召回”,而是“召回到了但排得不稳、噪声太多、关键结果进不去最终上下文”时,Reranker 往往最值得加。它的核心价值不是补所有问题,而是把候选池里的结果排得更适合最终问答。

很多团队第一次接触 Reranker 时,会把它理解成:

  • 一个默认应该加上的增强器

这种理解并不稳。因为 Reranker 并不擅长解决所有问题,它最擅长的是:

  • 改善候选集排序质量

所以你是否该加它,关键取决于当前主问题是不是排序问题。

什么情况下 Reranker 的价值通常最大 ​

下面这些情况,往往都很适合优先考虑 Reranker:

  • 正确结果其实已经在候选集中
  • 但位置经常不稳定
  • 噪声结果排得太靠前
  • 多文档问题里,真正关键的结果经常被边缘相关结果压住

这些问题的共同点是:

  • 候选池已经有“可用材料”
  • 只是最终保留顺序不理想

这正是 Reranker 最擅长发挥作用的地方。

什么情况下先别急着上 Reranker ​

如果你当前的主问题更像下面这些情况,通常不该先把 Reranker 当第一优先级:

  • 正确文档根本没召回
  • metadata filter 经常出错
  • chunk 策略明显不合理
  • 最终上下文过长、组织混乱

这些问题更像:

  • 候选池本身质量不足
  • 或者后面上下文构造出了问题

Reranker 无法把不存在于候选集里的证据凭空排出来,也无法替代数据和检索基础设计。

为什么很多真实系统加了 Reranker 会更稳 ​

因为初次召回阶段通常更偏:

  • 宽覆盖

它的目标是:

  • 别漏

但最终送给模型的上下文更需要:

  • 更高质量的排序
  • 更少噪声
  • 更强相关性

这两种目标本来就不同。所以很多系统会选择:

  • 初排尽量把东西捞全
  • 再用 Reranker 提高最终保留质量

判断是否值得加 Reranker 的几个实用信号 ​

你可以先看下面这些信号:

  • 正确结果经常在 Top 20,但进不了最终前几位
  • 增大 TopK 后 recall 提升了,但最终回答没明显变好
  • 候选集里有很多重复或边缘相关结果
  • 多文档综合题经常差最后一两个关键证据

这些现象都很像:

  • 召回已经够宽
  • 但排序还不够稳

加了 Reranker 后应该看什么 ​

不要只看“加了之后感觉更好”。更稳的观察方式通常是:

  • 正确证据进入最终上下文的比例是否提高
  • 候选前排的噪声是否下降
  • 多文档和复杂题是否更稳定
  • 延迟和成本增加是否可接受

如果只是总分略有变化,但:

  • 延迟大幅上升
  • 候选质量没有明显改善

那 Reranker 可能不是当前阶段最划算的投资。

一个很典型的误区 ​

有些团队在候选池质量本来就很差时,也急着加 Reranker。结果会出现:

  • 排序确实更好了
  • 但候选池里本来也没有多少真正关键证据

这时收益通常会比较有限。因为 Reranker 更像在:

  • 优化已有候选

而不是:

  • 创造候选

一个最小判断示意 ​

python
def should_add_reranker(case):
    if not case["gold_evidence_in_candidates"]:
        return False
    if case["gold_evidence_ranked_low"] or case["candidate_noise_high"]:
        return True
    return False

这个示意的重点是:

  • 先确认候选池里有东西可排
  • 再判断排得值不值得优化

一句话总结 ​

什么时候值得加 Reranker,关键不在于它是不是“高级配置”,而在于你的主问题是不是候选排序问题。候选集里已经有对的东西,但顺序不稳、噪声太多时,它通常最有价值。