Reranking
为什么重要
深度解析
重排之所以存在，是因为快速检索和准确检索根本是两个问题。RAG 或语义搜索流水线的第一阶段，要在几毫秒内筛过数百万个块，因此只能依靠近似方法：双编码器嵌入模型分别把查询和每份文档转成向量，或者由 BM25 在完全不理解语义的情况下给关键词重合度打分。这些方法通常能把正确文档塞进前 50 名的某个位置，但 50 项内部的顺序很嘈杂。重排器接过候选集，再应用一个若对整个语料库运行就会慢得不可接受的模型——通常是把查询与一份文档放在一起阅读的交叉编码器——重新排序，让真正相关的块浮到最上面。最后的 top-k 通常只剩 3–10 个块，它们才会被组装进提示词。
双编码器与交叉编码器
两个阶段之间的性能差距来自架构。双编码器为每段文本分别产出一个向量：查询嵌入一次，每份文档也各自嵌入一次，通常提前离线完成，相关性只是两个点之间的余弦相似度。配合近似最近邻索引，这快得惊人；但模型从未把查询与文档放在一起看，因此无法建模一边的具体词语如何与另一边的具体词语互动。交叉编码器正好相反：查询和单份候选文档先拼接成一个输入，再一起穿过 Transformer，由模型直接输出相关性分数。两段文本中的每个 token 都能注意到另一段的每个 token，因此它能捕捉否定、精确限制、多跳措辞等微妙之处，而嵌入相似度经常会漏掉这些。
代价在于计算。给 50 个候选打分，就要做 50 次独立前向传播；查询只有在请求到来时才知道，所以这些配对无法预先计算。这正是交叉编码器从不跑遍数百万文档的完整语料库、也是双阶段拆分存在的原因：双编码器负责召回率，把正确文档放进候选集；交叉编码器负责精确率，把它们排到正确位置。
实践中的重排器
添加重排器通常有两条路。Cohere Rerank、Voyage AI 的 rerank 端点等托管 API，可以在一次请求中接收查询和一列文档，再返回分数——不用运行基础设施，代价是多一次网络调用和按请求计费。开放权重模型则以 BAAI 的 bge-reranker 家族和 Jina AI 的重排器为代表，都可以从 Hugging Face 获取，在单张 GPU 上运行；候选集较小时，甚至 CPU 也够用，既能把数据留在内部，成本也更可预测。
无论选哪条路，集成模式都一样：先取回一组宽裕的候选，通常是 top 20–100，来源往往是向量数据库与 BM25 结合的混合搜索；然后重排，只留下 top 3–10，其他全部丢掉。有些团队干脆跳过专用模型，直接提示一个大型语言模型以零样本方式排序候选；这确实可行，列表式 LLM 重排器也可能很强，但专门训练的交叉编码器通常每次查询便宜一到两个数量级。
它救不了糟糕的检索
一个常见误解是，加上重排器就能救活薄弱的搜索流水线。做不到，因为重排只会重新排列第一阶段已经返回的东西：相关块若从未进入候选集，重排器根本看不见，再准确的打分也拉不回来。第一阶段为所有下游环节设下了硬性的召回率天花板。这对调试有一个实际后果：端到端检索质量差时，要把各阶段拆开测。先检查正确块有没有出现在前 50 名的任何位置；如果没有，就是检索问题，要修嵌入、切块，或加入混合搜索；如果出现了，只是排名太低，才是重排问题。跳过这层区别的团队，常常花几周调重排器，最后才发现收益从一开始就被第一阶段封死了。
延迟预算
重排是一笔交易：用额外延迟和成本换取更好的顺序。自托管交叉编码器为 50 个查询–文档配对打分，通常会多花几十到几百毫秒，具体取决于模型大小和文档长度；托管 API 还要在此之上再加一次网络往返。旋钮都很直白：少重排一些候选，用 top 20 而不是 top 100；评分前截断文档；改用小模型；或者缓存重复查询的分数。
这笔交易值不值，取决于应用。面向用户的助手本来就要用几秒生成答案，额外 100–300 毫秒通常完全看不出来，而相关性提升会直接减少题外上下文引起的幻觉。对于自动补全式搜索或高 QPS 内部服务，团队往往只重排看起来困难的查询——长、模糊，或第一阶段置信度低——简单查询直接放行。生产检索系统的务实默认值是：始终重排，除非你能证明自己付不起。