7.2.4 Reranker 更偏向优化召回率还是准确率？

先给结论：通常更偏向优化“前排结果的准确性”和最终上下文质量，而不是直接扩大召回覆盖。更直白一点说，Reranker 更像是在提升排序精度，而不是在提升原始召回范围。

所以如果只用一句话概括：

• Reranker 更偏向改善 precision，而不是直接改善 recall

但这里也要把边界讲清楚。

为什么它通常更偏向 precision

因为 Reranker 的输入前提通常是：

• 初次召回已经给出一批候选

它做的事情是：

• 在这批候选里重新排序

这意味着它最直接改善的是：

• 哪些结果排得更靠前
• 最终被模型看到的前几条是不是更准

也就是说，它更擅长提高的是：

• 前几条结果的相关性
• 上下文命中率
• 候选精选质量

为什么它不能直接解决原始 recall 不足

因为如果正确内容根本没进候选池，Reranker 就没有机会碰到它。

这也是为什么它通常不能直接提升：

• 全局召回覆盖

除非你本来就把较大的候选池召回进来了，而正确结果只是排在很后面。

这时 Reranker 能做的是：

• 把它从后面拉到前面

从最终系统表现看，这会让你感觉：

• “好像召回也变好了”

但严格说，这更像是：

• 候选顺序更合理了

而不是：

• 原始召回池真的变大了

为什么它会间接改善最终效果

虽然它不直接扩大 recall，但它常常会显著改善：

• 最终上下文质量
• 模型拿到的证据密度
• 噪声比例

这会直接反映在用户体验上，比如：

• 答案更稳
• 引用更准
• 冲突更少

所以从最终系统效果看，Reranker 的价值往往非常明显。

只是你要知道，它改善的主要杠杆不在“找更多”，而在“用更准”。

一个更实际的例子

假设初次召回前 20 条里：

• 正确结果排在第 12
• 前 5 条有很多边缘相关块

加入 Reranker 之后：

• 正确结果被提到第 2

这时你会看到最终回答质量明显提升。

但根本原因不是：

• 系统突然召回到了更多结果

而是：

• 系统终于把已有正确结果放到了更该出现的位置

什么情况下它也会“看起来像提升了 recall”

有一种情况确实容易让人觉得 Reranker 在提升 recall：

• 初次召回会先取一个较大的候选池，比如前 30 或前 50
• 正确结果原本就在这个池子里，只是排得很靠后
• Reranker 把它拉到了前面

从最终送给模型的前 5 或前 10 条看，系统确实像是“更容易召回到正确结果了”。

但更准确的说法仍然是：

• 它改善的是候选精选阶段的命中

不是初次全库召回能力本身。

一个常见误区

很多人会把 Reranker 的效果看成：

• 既能补 recall，又能补 precision，所以什么问题都值得先加

这通常不稳。

更准确的理解是：

• 如果问题主要出在顺序，Reranker 会很有价值
• 如果问题主要出在没召回来，Reranker 价值有限

一句话总结

Reranker 通常更偏向优化准确率，尤其是前排结果的相关性和最终上下文质量，而不是直接扩大召回覆盖。它最擅长解决的是“已有候选怎么排得更准”，不是“全库里怎么找得更全”。