撒谎的重排序器

第三章 — 撒谎的重排序器

在RAG技术术语中，有一个关键但不太引人注目的人物：重排序器。想象一下企业搜索就像一个夜总会的入口。向量数据库是门卫：快速扫视人群，让三十个看起来符合你搜索条件的人进入。重排序器是里面的保镖：从这三十个人中挑选出五个——那些LLM真正会用来构建答案的人——并将其他二十五个人拒之门外。这是一个小但巨大的功能：如果他出错，大家都会出错。如果保镖不会识人，夜总会就会充斥着错误的人，没有人会明白为什么这个夜晚会搞砸。

2025年，市场上出现了一些提供重排序器API的云服务。你发送一个问题和一份文档列表，它们会返回分数。方便、可扩展，无需购买GPU，无需下载模型。一家著名的欧洲模型提供商——不点名，但你知道我们回避的是哪些名字——发布了一个名为Qwen的、拥有四十亿参数的、标注为“重排序器”的模型。价格合理，延迟可接受。当时，任何人都会选择它。很多人都选择了它。

除非分数是错误的。不是“轻微”错误，就像任何模型都可能发生的那样：结构性错误。明显相关的文档得到 0.2 分，与主题无关的文档得到 0.8 分。一如既往，最初的怀疑指向了通常的嫌疑人：嵌入模型、分块、查询公式、文档预处理。数周的调查都走上了错误的道路。只有通过系统地将云 reranker 的响应与本地参考 reranker 的响应进行比较——相同的输入、相同的文件、分数并排显示在 Excel 表格中——才揭示了令人不安的事实：通过 API 公开的模型已损坏。也许是部署错误，也许是不小心上传了错误的版本，也许是分数序列化中的错误。提供商从未正式承认这一点。然而，这个问题在一次无声更新后，在没有任何更新说明的情况下，只是消失了。

这个故事的重点不是“云服务会出错”——所有服务都会出错，即使是本地模型也会出错。 重点更为微妙：在严肃的 RAG（检索增强生成）系统中，reranker（重排序器）是一个你必须能够深入了解的部分。 如果它是一个付费的黑盒，并且它的输出是即使是随机的也能看起来合理的数据——而且reranker的分数总是看起来合理，因为它们是带有小数的 0 到 1 之间的数字——你没有任何方法来理解你的系统出了什么问题。 由于reranker位于pipeline的“末端”，它的错误会污染上游的每一个评估：搜索似乎很慢，查询有误，embedding质量差。 实际上，是门口的保安不识人，而你却在质疑门玻璃的质量。

在过去几个月里，一些团队做出的逆流而上的选择——不是转向更多云服务，而是回归本地——是将reranker带回“内部”。这是一个来自BGE家族的开源模型，规模不算巨大，在本地GPU上运行（包括Apple Silicon，但需谨慎对待驱动程序）。这确实需要更多管理工作。但它提供了进行受控实验、了解错误发生的原因、比较版本以及保留历史记录的可能性。而且——最后一点——不必为每个用户搜索向API支付一分钱。将这个微不足道的金额乘以每月数万次查询，它很快就不再是微不足道，而是变成了一笔重要的预算支出。

当一个组件如此关键，以至于它的故障会破坏你衡量一切的能力时，将其委托给一个黑盒子不是效率。那是一种信仰行为。而生产环境中的信仰行为，会以复利的形式付出代价。