布吉岛 Agent

Appearance

7.2.3 什么时候值得加 Reranker？ ​

先给结论：当你的系统已经能大致召回到正确候选，但候选顺序不稳、噪声较多、模型经常抓不到最关键证据时，就很值得考虑加 Reranker。

换句话说，Reranker 最适合解决的是：

  • “找到了，但排得还不够好”

最值得加 Reranker 的典型信号 ​

下面这些现象，通常都说明引入 Reranker 可能很有价值：

1. 正确内容经常在前 10 或前 20，但不在前 3 ​

这几乎是最典型的信号。

说明问题更像：

  • 候选优先级没排好

而不是：

  • 根本没召回来

2. 候选里噪声和边缘相关结果较多 ​

如果初次召回已经能大致找到范围，但候选里常常混进：

  • 模板块
  • 概述块
  • 表面相似块
  • 旧版本块

那么 Reranker 通常能帮助系统把更关键结果往前拉。

3. 混合检索之后，候选池变大但顺序不稳 ​

很多系统在加了 BM25 + 向量混合检索后，确实能提升覆盖。

但随之而来的问题常常是：

  • 候选更多了
  • 但谁该排前更难判断了

这正是 Reranker 很自然的上场时机。

4. 问题复杂，相关性不能只靠初次分数判断 ​

有些问题里，真正关键的不是简单语义相似，而是：

  • 哪条证据更直接回答当前问题
  • 哪条只是相关背景

这类问题通常更适合让 Reranker 再做一轮更细判断。

什么情况下先别急着加 ​

下面这些情况，通常不该第一反应就上 Reranker：

1. 正确内容根本没被召回 ​

如果候选池里没有正确内容，加 Reranker 没法救。

这时更该先回头看：

  • chunk
  • metadata
  • embedding / BM25
  • filtering / routing

2. 数据量很小、问题很简单 ​

如果你的知识库很小、问题类型很单一，初次召回已经很稳，Reranker 的边际收益可能不大。

3. 当前主要问题是边界错，不是顺序错 ​

比如：

  • 版本混了
  • 租户串了
  • 权限没控住

这类问题更像 filter 和治理问题，不该优先指望 Reranker。

一个更实际的判断方法 ​

如果你想判断“该不该加 Reranker”，可以先检查这三件事：

  1. 正确内容是否经常已经在候选池里
  2. 问题是否主要表现为顺序不稳而不是根本漏召回
  3. 加入更多候选后，系统是否变得更乱而不是更稳

如果这三条里有两条成立，Reranker 往往就值得认真考虑。

一个最小示意 ​

python
initial_results = hybrid_retrieve(user_query, top_k=30)

if relevant_result_is_often_present_but_low_ranked():
    final_results = rerank(user_query, initial_results)[:5]
else:
    final_results = initial_results[:5]

这段代码想说明的是：

  • Reranker 最适合用在“候选池已经有料，但顺序不稳”的阶段

一个常见误区 ​

很多人会把 Reranker 当成：

  • 质量上不去时的默认增强件

这不够稳。

更好的顺序通常是：

  1. 先确认是不是召回问题
  2. 再确认是不是排序问题
  3. 确定属于排序问题后，再引入 Reranker

否则很容易把本来该修召回的系统，误修成一个更慢但仍然不准的系统。

一句话总结 ​

当系统已经能大致召回到正确候选，但顺序不稳、噪声较多、模型常抓不到关键证据时，就很值得加 Reranker。它最适合解决“找到了但没排好”，不适合替代“根本没找到”的问题。