何时值得使用重排序器？
内容提要
在调整重排序器前，需先验证索引状态并建立基线。通过nDCG@10评估候选列表与理想排序的差距，若差距大则值得优化。测试时先用10个候选，对比交叉编码器与调优融合的基线，仅在重排序器胜出时增加候选数。确认模型与语料匹配，并检查吞吐量。若失败，诊断模型窗口或训练域不匹配，或保留融合。生产环境需测量延迟，并考虑其他阶段如多样性或分组。
延伸解读
先测差距再调模型
文章强调，在投入重排序器之前，应先测量当前排序与理想排序的差距。具体做法是：将候选列表按理想顺序排列，计算其nDCG@10，再与当前管道得分对比。差距越大，说明优化排序的潜力越大。文中提到，在200个候选时，五个数据集的差距在0.247到0.487之间，这为判断是否值得优化提供了量化依据。
基线对比要公平
重排序器的效果必须与最强的第一阶段基线对比，而不是默认的RRF。文章指出，默认RRF本身已是可靠基线，但经过调优的融合更强。如果只与默认对比，可能误以为重排序器带来了提升，而实际上调优融合也能达到类似效果。因此，应先调优融合，再让重排序器在保留的标注查询上超越它。
模型选择看匹配度
模型的选择对结果影响最大，但关键在于模型是否与语料匹配。文章发现，两个确认的胜利都来自窗口大小和训练数据与语料匹配的模型。例如，jina-reranker-v2因训练数据包含代码，在CodeSearchNet上表现优异。而其他模型因窗口限制或领域不匹配而失败。因此，选模型时应先读模型卡，确认语言、领域和上下文窗口是否合适。
候选数并非越多越好
增加候选数并不总能提升重排序效果。文章指出，如果相关文档在候选列表中出现的比例已经很高，增加候选数可能反而引入无关文档，将相关文档挤出前十。例如，ArguAna中90%的查询在25个候选内已包含相关文档，增加到200个反而导致效果下降。因此，应选择能捕获大部分增益的最小候选数，并测量相关文档覆盖率的变化。
Q&A
在调整重排序器之前，应该先做什么？
在调整重排序器之前，应该先验证索引状态并建立带标签的基线。具体来说，需要检查候选列表是否包含相关文档，并计算当前排序与理想排序之间的nDCG@10差距，以确定重排序的潜在收益。
如何评估重排序器的潜在收益？
使用nDCG@10指标，将候选列表按理想顺序排序后的得分与当前管道返回的得分进行比较，差距越大，说明重排序的潜在收益越大。
测试重排序器的三个步骤是什么？
第一步，建立基线，即调优后的融合（如果使用混合搜索）或当前排序，并确认相关文档在候选列表中。第二步，用实际要服务的模型对10个候选进行重排序，并与基线比较。第三步，仅当重排序器胜出时，才增加候选数量，并测量吞吐量。
为什么在比较重排序器时要先调优融合？
因为Qdrant默认的RRF已经是一个不错的基线，但调优后的融合更强。如果直接与默认RRF比较，重排序器的提升可能只是调优融合就能实现的，而调优融合在查询时成本更低。因此，先调优融合，再让重排序器与之比较，才能公平评估其价值。
在哪些数据集上重排序器被确认有效？
在CodeSearchNet和DBPedia-entity上，重排序器（jina-reranker-v2）的增益在100%的held-out验证中存活，被确认为有效。而在SciFact、ArguAna和WANDS上，增益未能通过held-out验证。
如果重排序器在10个候选时失败，应该怎么办？
首先诊断失败原因，检查模型窗口是否与查询-文档对长度匹配，以及训练领域是否与语料匹配。如果不匹配，更换合适的模型并重新测试。如果模型匹配但仍失败，则保留调优后的融合，并将精力投入到其他方面。
如何确定最佳候选数量？
从10个候选开始，确认重排序器胜出后再增加。检查相关文档在候选列表中的覆盖率，选择覆盖率仍在上升的候选数量。同时，考虑增益的边际递减，选择能捕获大部分增益的最小候选数。
在生产环境中，如何评估重排序器的性能？
测量查询-候选对每秒处理数和尾延迟，使用目标硬件、代表性文档长度和并发度。例如，在Apple M5 Pro上，MiniLM-L-6每秒处理64-212个文档，对应0.6-2.1个查询（100候选）。同时，考虑模型大小和训练数据匹配。
除了重排序器，还有哪些阶段可以解决不同的问题？
如果结果重复或相似，可以使用最大边际相关性（MMR）增加多样性；如果文档块填满第一页，可以使用分组（grouping）按文档ID分组；如果需要根据时效性或流行度调整顺序，可以使用公式查询（Formula Query）。
