重排序器：被忽视的召回率杀手

「用户问的是退款条款，检索器拉对了合同，对的段落也在索引里——它排在第7位。模型取了前5个，自信满满地从两页前的续约条款里找答案。答案错了，引用格式却完美。」

这是某个团队正在啃的bug。作者说，修复方案很少是更好的嵌入模型。真正该上的是重排序器（reranker）。

向量搜索的本质缺陷

纯向量搜索是一台召回机器，带着精度问题。它能找到街区，但指不出哪栋房子才是你要的。

交叉编码器重排序器（cross-encoder reranker）的做法是：把查询和每个候选文档一起读，基于这对组合的实际相关性打分，超越单纯的嵌入邻近度。

流程变成：快速召回前50个，仔细重排到前5个，再把这5个交给大语言模型。

别急着换模型。先花一个下午建一套可复现的标注数据集。

从你的日志里挑50个真实用户查询。每个查询标注语料库里哪些文档ID能真正回答它。每个查询1到3个正例就够了。

评估指标是recall@5：应该在top 5里的文档，实际有多少真的在。如果某个查询有2个正例，你在第4位召回1个，这个查询的recall@5就是0.5。50个查询取平均。

数据集很小，信号很真。重排序器管用的时候，你会看到10到25个点的波动；不管用的时候，波动在3个点以下。够你做决定了。

漏斗要加宽，不是换管道

检索器保持不变。你只加宽漏斗。大多数设置现在直接从向量库拉top 5。改成拉top 50，再把这些候选送给重排序器。

上重排序器之前先检查两件事。第一，你的正例文档在不在top 50里？不在的话重排序器救不了你，bug在上游：分块策略、嵌入模型，或者查询本身。第二，它在top 50里但不在top 5里的频率有多高？这个缺口就是重排序器的活。

在一个50查询测试集里（示例数字来自1.2万块产品文档，用通用多语言模型嵌入，存在Qdrant里），稠密检索器的表现是：

recall@5约0.42，recall@50约0.78。意味着78%的正例能被捞进前50，但只有42%挤进前5。重排序器要填的就是这个36点的gap。

作者没给具体重排序器型号，但强调了选型逻辑：轻量、延迟可控、在你的数据上有验证。别在没测过的模型上赌生产环境。

为什么这事值得现在做

太多团队把预算砸在换更大的嵌入模型上，或者微调基座模型。但那个排在第7位的正确段落，问题根本不是嵌入质量——是排序阶段没给查询和文档做交叉注意力。

重排序器是架构层面最便宜的杠杆：不碰数据管道，不改嵌入，只加一层推理。50个查询的测试集，一个下午能建完；recall@5的波动，10分钟能算出来。

如果你现在的RAG系统还在用向量搜索直接出top 5，先别急着买更大的GPU。把漏斗加宽，让重排序器做那道精细筛选——这可能是你召回率最划算的修复。