在这一系列博客的最后一部分,我们详细探讨了各种高质量重排器(re-ranker)的特性,包括我们自己开发的Elastic Rerank模型。特别是,我们关注检索质量随重排深度变化的定性和定量评估。我们提供了一些关于如何选择重排深度的高层次指南,并推荐了我们测试过的不同模型的合理默认值。我们使用BM25作为第一阶段的检索器,采用“检索-重排”管道,专注于英文文本搜索,并使用BEIR来基准测试我们的端到端准确性。
下面展示了端到端相关性随重排深度变化的三个主要模式:
在我们测试的重排器和数据集中,模式1占72.6%,模式2占20.2%,模式3占7.1%。不出所料,整体上最强的重排器,如Elastic Rerank,在重排深度上的改进最为一致。
我们提出了一个简单的模型来解释我们观察到的曲线,并展示了它在所有数据集和重排器中的惊人适用性。这表明,在检索结果中找到正面文档的概率遵循帕累托分布。此外,我们可以认为不同的模式是由重排器能检测到的相关(或正面)文档的比例以及它错误识别为相关的无关(或负面)文档的比例驱动的。
我们还研究了选择重排深度和进行模型选择的有效性与效率之间的机制。在没有硬性效率约束的情况下,我们以达到最大效果的90%的深度为经验法则。这比最大化效果计算成本提高了3倍,因此我们认为这是一个良好的效率权衡。对我们的基准测试来说,90%的规则建议平均从BM25中重排约100对文档,尽管更强大的模型在更深的重排中受益更多。我们还观察到重要的第一阶段检索效果。在某些数据集中,我们研究的检索器召回在较低深度时就饱和。在这些情况下,我们看到显著较浅的最大和90%的效果深度。
在实际场景中存在效率约束,例如允许的最大查询延迟或计算成本。我们提出了一种方案,在效率约束下同时选择模型和重排深度。我们发现,当效率至关重要时,小模型的深度重排往往比大模型的浅重排效果更好。随着效率约束的放宽,这一模式会逆转。我们还发现Elastic Rerank在几乎所有我们测试的约束中都提供了最先进的效果与效率。对于我们的基准测试,当计算成本重要时,选择BM25中的前30个结果进行重排是一个不错的选择。
在本次研究中,我们评估了一系列不同规模和能力的重排器,具体如下:
在下图中,我们包括了一个“oracle”的性能,该oracle可以访问每个数据集的相关性判断(qrels
),因此可以按其相关性得分降序对文档进行排序。这将任何相关文档放在任何无关文档之前,并将高相关性的文档放在低相关性文档之前。这些数据点代表理想重排器的性能(假设完美标记)并量化重排模型的改进空间。它还捕捉了端到端准确性对第一阶段检索器的依赖,因为重排器只能看到检索器返回的项目。
我们使用nDCG@10作为评估指标,这是BEIR基准中的标准,并绘制这些分数随重排深度的变化曲线。重排深度是BM25检索的候选文档数量,随后发送给重排器。由于我们使用nDCG@10,该分数仅在重排器将检索列表中较低位置的文档放入前10名时受到影响。在这种情况下,如果文档相关,它可以增加nDCG@10;如果它将相关文档移除,则会减少nDCG@10。
这占我们看到的大多数情况。它可以分为三个阶段:
下图显示了DBpedia
和HotpotQA
的运行情况,其中黑色虚线水平线描绘了BM25的nDCG@10分数。
图1:DBpedia上的nDCG@10随重排深度的变化
图2:HotpotQA上的nDCG@10随重排深度的变化
单调递增的曲线有一个简单的解释:随着重排深度的增加,第一阶段检索器提供了一个更大的候选池,下一阶段的重排器模型可以识别更多的相关文档并将其高置于结果列表中。
根据这些曲线的形状,我们假设我们发现正面文档的速率随深度变化遵循幂律。特别是,如果我们假设重排器将每个正面文档移入前10名列表,则nDCG@10将与检索器在给定深度返回的正面文档数量有关。因此,如果我们的假设正确,其功能形式将与幂律的累积分布函数(CDF)有关。下图中,我们将广义帕累托CDF的缩放版本拟合到nDCG@10曲线以测试这一假设。
下图显示了一些拟合曲线应用于不同数据集(FiQA
、Natural Questions
、DBpedia
和HotpotQA
)使用不同重排器的示例。
图3:使用广义帕累托CDF拟合的nDCG曲线
从视觉上看,广义帕累托CDF很好地拟合了观察到的曲线,这支持了我们的假设。
由于我们未能达到oracle的性能,整体行为与模型具有一些假阴性(FN)比例,但假阳性(FP)比例非常低一致:添加更多示例偶尔会将额外的正面文档排到顶部,但不会将负面文档排在已经发现的正面文档之上。
这种图表家族具有以下阶段:
下图显示了这种模式的两个示例:一个是将MiniLM-L12-v2
模型应用于TREC-COVID
数据集,另一个是将mxbai-rerank-base-v1
模型应用于FEVER
数据集。在这两种情况下,黑色虚线表示BM25基线的性能。
图4:两种“单峰”模式的情况
这种曲线可以通过相同的帕累托发现额外相关文档的速率来解释。然而,似乎存在一些小的非零FP比例。由于发现额外相关文档的速率单调下降,在某个深度,发现相关文档的速率乘以真正阳性(TP)比例将等于发现无关文档的速率乘以FP比例,nDCG@10将有一个唯一的最大值。此后,它将下降,因为在总体上重排将相关文档推到前10名之外。
一些可能导致存在非零FP比例的原因:
然而,我们注意到,这种模式在整体较弱的重排模型中更为常见。
正如我们在之前的博客中讨论的,在零样本设置中,确保我们呈现足够多样化的负样本以覆盖广泛的可能混淆特征可能是训练问题的潜在解决方案。换句话说,可能是表现出这些问题的模型没有挖掘足够多的深负样本进行训练,因此更深的检索结果实际上是“域外”的。
注意,有些边缘情况很难区分“帕累托”和“单峰”模式。当性能的峰值较早达到最大深度但性能下降较小的情况下发生。根据目前使用的术语,这将被归类为“单峰”情况。为了解决这个问题,我们引入了一个额外的规则:如果曲线的nDCG增益在最大深度达到最大nDCG增益的≥95%,我们将其标记为“帕累托”;否则,我们将其标记为“单峰”。
这类包括所有重排器在任何深度下都没有带来比BM25更好的性能,相反,我们观察到随着重排更多文档,性能持续下降。
例如,我们可以看一下ArguAna
,这是BEIR中一个特别具有挑战性的任务,因为它涉及检索输入的最佳反驳。这不是一个典型的信息检索场景,一些研究甚至考虑不报告结果。我们尝试了不同的重排器(即使有些未进入最终列表),并观察到许多重排器(Cohere-v3
、bge-reranker-v2-gemma
和Elastic Rerank
是唯一的例外)表现出相同的模式。下图显示了monot5-large
的结果。
图5:一个“不适合”的示例
我们提出两种可能的解释:
总体而言,不同场景下模式(P
→ “帕累托”曲线,U
→ “单峰”曲线,B
→ “不适合”)的分布如下:
图6:所有场景下的模式分布
关于最常见的“帕累托”模式,我们注意到一些相关工作的观察。首先,Naver Labs的这篇论文展示的结果与我们的发现一致。在那里,作者使用3种不同的(SPLADE
)检索器和两种不同的交叉编码器,在TREC-DL 19、20和BEIR上测试管道。他们尝试了三种不同的重排深度值(50、100和200),结果显示在大多数情况下,性能在较小深度(即50)快速增加,然后几乎饱和。类似的结果也在Vespa的这篇博客中展示,作者使用BM25和ColBERT在MLDR数据集上采用“检索-重排”管道,发现通过重新排序前十个文档可以显著提高nDCG指标。最后,在Meng等人的这篇论文中,我们观察到类似的结果,当两个检索系统(BM25和RepLLaMA)后跟一个RankLLaMA重排器时。作者在TREC DL19和20数据集上进行了实验,调查了8种排名列表截断(RLT)方法,其中一种与我们的设置一致。在这些工作中,作者并未明确指出任何能够解释观察到的nDCG曲线的底层过程。由于我们发现这种行为在不同数据集和重排器中一致,因此我们认为这需要进一步研究。
一些其他检索任务的特征也可能解释其中的一些结果:
ArguAna
和Touche-2020
,这两个论点检索数据集,对我们考虑的模型来说是最具挑战性的任务。一个有趣的相关分析可以在Thakur等人的这篇论文中找到,作者讨论了神经检索模型在Touche-2020
中的较低效果,尤其是与BM25相比。尽管这篇论文只考虑了一个检索步骤,但我们认为一些结论可能也适用于“检索-重排”管道。更具体地说,作者揭示了神经模型对更短段落(< 350字)的固有偏好,而BM25检索更长的文档(>600字),更好地模拟了oracle分布。在他们的研究中,即使在通过删除短文档(少于20字)和添加事后相关性判断来解决小标记率问题后,BM25仍然优于所有他们测试的检索模型。Scifact
和FEVER
是两个事实验证任务数据集,其中两个“较小”模型遵循“单峰”模式。这两项任务需要对声明进行知识和多文档推理。在Scifact上,检索器能够访问科学背景知识并理解专业统计语言以支持或反驳声明是非常重要的。从这个角度来看,内部“世界”知识较少的较小模型可能处于不利地位。TREC-COVID
有很高的标记率,即>90%的检索文档有相关性判断(无论是正面还是负面)。因此,这是唯一一个不完全标记不太可能成为问题的数据集。Quora
上提供了非常好的排名,这是一个“重复问题”识别任务。在这个特定数据集中,查询和文档都非常简短——90%的文档(查询)少于19(14)个字——并且查询及其相关对应物之间的Jaccard相似性相当高,略高于43%。这可以解释为什么某些纯语义重排器无法增加价值。到目前为止,我们将重排模型视为分类器,并讨论了其性能在FN和FP率方面的表现。显然,这是一个简化,因为它输出一个分数,捕捉到每个文档对查询的相关性估计。我们将在即将发布的博客文章中回到为模型创建可解释分数的过程,这被称为校准。然而,在此处,我们希望了解分数随深度变化的一般趋势,因为这提供了关于nDCG@10如何演变的进一步见解。
在下图中,我们按判断标签拆分文档,并绘制正面和负面文档的平均分数随深度的变化。我们还显示了一个标准偏差的置信区间,以了解分数分布的重叠程度。
对于“帕累托”模式,我们看到正面和负面分数随深度变化的曲线非常相似。(负面曲线更平滑,因为在任何给定深度都有更多的负面)。它们起初较高,这对应于优秀的匹配和非常困难的负面,然后在很大程度上达到平台期。整个过程中,分数分布保持良好分离,这与基本为零的FP比例一致。对于“单峰”模式,分数随深度的变化相似,但我们也看到分数分布明显更多的重叠。这与小但非零的FP比例一致。最后,对于“不适合”模式,我们看到分数没有分离。随着深度的增加,正面和负面分数没有显著下降。这与重排器不适合特定检索任务一致,因为它似乎无法可靠地区分任何深度采样的正面和负面。
图7:HotpotQA上的Elastic Rerank正负分数随重排深度的变化。条形对应于±1标准差间隔
图8:FEVER上的mxbai-rerank-base-v1正负分数随重排深度的变化。条形对应于±1标准差间隔
图9:ArguAna上的monot5-large正负分数随重排深度的变化。条形对应于±1标准差间隔
最后,注意对于“单峰”模式,分数曲线表明可以找到一个截断分数,该分数导致更高的FN比例但基本为零的FP比例。如果可以找到这样的阈值,它将允许我们在重排深度下保持相关性不下降,同时仍然能够保留检索器表面的一部分额外相关文档。我们将在即将发布的博客文章中探讨模型校准时回到这一观察。
在本节中,我们关注效率与效果之间的权衡,并提供一些选择最佳重排深度的指导。从高层次来看,效果是指随着我们检索和重排更多候选者所获得的整体相关性提升,而效率则侧重于最小化相关的成本。
效率可以通过不同的维度来表达,其中一些常见的选择是:
我们注意到,效率还涉及其他考虑因素,例如以较低精度运行模型的能力、使用更高效内核的能力等等,这些我们不会进一步研究。
在这里,我们采用简化的设置,专注于延迟维度。显然,在实际场景中可以轻松通过增加CPU/GPU数量并并行化推理来实现更低的延迟,但在接下来的分析中我们假设基础设施是固定的。
Cohere v3由于是基于API的服务,被排除在这次实验之外。
我们首先考虑每个(模型,数据集)对,忽略延迟维度。我们感兴趣的是nDCG增益的演变(深度k处的nDCG分数减去BM25的nDCG分数),并选择两个数据点进行进一步分析:
我们在选择的数据集中计算这两个数量。
数据集 | DBPedia | - | HotpotQA | - | FiQA | - | Quora | - | TREC-COVID | - | Climate-FEVER | - |
---|---|---|---|---|---|---|---|---|---|---|---|---|
模型 | 最大 | 90% | 最大 | 90% | 最大 | 90% | 最大 | 90% | 最大 | 90% | 最大 | 90% |
bge-reranker-v2-gemma | 300 | 150 | 400 | 180 | 390 | 140 | 350 | 40 | 110 | 50 | 290 | 130 |
monot5-large | 350 | 100 | 400 | 100 | 400 | 130 | 80 | 20 | 110 | 60 | 280 | 60 |
MiniLM-L12-v2 | 340 | 160 | 400 | 120 | 400 | 80 | 20 | 20 | 50 | 50 | 280 | 50 |
mxbai-rerank-base-v1 | 290 | 140 | 90 | 30 | 400 | 70 | 0* | 0* | 110 | 50 | 290 | 120 |
Elastic Rerank | 350 | 140 | 400 | 160 | 400 | 130 | 180 | 30 | 220 | 50 | 400 | 170 |
Cohere v3 | 300 | 100 | 400 | 130 | 400 | 130 | 30 | 20 | 270 | 50 | 290 | 70 |
表1: 不同模型和数据集的最大增益和90%-增益深度。对于Quora
上的mxbai-rerank-base-v1
,条目“0* - 0*”表示模型在BM25上没有任何增益。
如果我们按重排器模型类型分组并取平均值,得到表2。我们省略了(Quora
,mxbai-rerank-base-v1
)对,因为它对应于不适合的情况。
模型 | 平均最大增益深度 | 平均90%-到最大增益深度 |
---|---|---|
bge-reranker-v2-gemma | 306.7 | 115 |
monot5-large | 270 | 78.3 |
MiniLM-L12-v2 | 248.3 | 80 |
mxbai-rerank-base-v1 | 236 | 82 |
Elastic Rerank | 325 | 113.3 |
Cohere v3 | 281.7 | 83.3 |
表2: 每个模型的最大增益深度和90%最大增益深度的平均值。
我们观察到:
Elastic Rerank
和bge-reranker-v2-gemma
在更深的深度达到峰值,利用了更多的可用正面文档,而较不有效的模型“饱和”得更快。另外,如果我们按数据集分组并取平均值,得到表3。
数据集 | 平均最大增益深度 | 平均90%-到最大增益深度 |
---|---|---|
DBPedia | 321.7 | 131.7 |
HotpotQA | 348.3 | 120 |
FiQA | 398.3 | 113.3 |
Quora | 132 | 26 |
TREC-COVID | 145 | 51.7 |
Climate-FEVER | 305 | 100 |
表3: 每个数据集的平均值。
有两个主要群体:
DBpedia
、HotpotQA
、FiQA
和Climate-FEVER
。Quora
和TREC-COVID
。我们认为这种行为可以归因于第一阶段检索的性能,在这种情况下是BM25。为了支持这一结论,我们绘制了“oracle”的nDCG曲线。众所周知,nDCG指标受a)相关文档的召回率和b)它们在结果列表中的位置影响。由于“oracle”对检索文档的相关性有完美的信息,其nDCG分数可以视为第一阶段检索器召回率的代理。
图10:不同数据集的“oracle”nDCG@10曲线
在这个图中,我们看到对于Quora
和TREC-COVID
,nDCG分数快速上升到最大值(即1.0),而在其余数据集中,收敛速度要慢得多。换句话说,当检索器在较浅深度下就能很好地表面所有相关项目时,使用较大重排深度没有任何好处。
在本节中,我们展示如何在延迟约束下进行同时的模型和深度选择。为了收集我们的统计数据,我们使用了一个配备2个NVIDIA T4 GPU的虚拟机。对于每个数据集,我们测量总重排时间并将其除以查询数量,以得出一个表示重新评分10个(查询,文档)对的平均时间的单一数量。
我们假设成本与深度成线性比例,即重新评分10个文档需要s秒,重新评分20个文档需要2×s秒,以此类推。
下表显示了HotpotQA
和Climate-FEVER
的示例,每个条目表示重新评分10个(查询,文档)对所需的秒数。
模型 | MiniLM-L12-v2 | mxbai-rerank-base-v1 | Elastic Rerank | monot5-large | bge-reranker-v2-gemma |
---|---|---|---|---|---|
HotpotQA | 0.02417 | 0.07949 | 0.0869 | 0.21315 | 0.25214 |
Climate-FEVER | 0.06890 | 0.23571 | 0.23307 | 0.63652 | 0.42287 |
表4: HotpotQA & Climate-FEVER上重新评分10个(查询,文档)对的平均时间
一些注意事项:
mxbai-rerank-base-v1
和Elastic Rerank
具有非常相似的运行时间,因为它们使用相同的“骨干”模型,DeBERTamonot5-large
和bge-reranker-v2-gemma
的运行时间相似,即使monot5-large
只有1/3的参数数量。有两个可能的贡献因素:bge-reranker-v2-gemma
,我们使用了bfloat16,而monot5-large
保持浮点精度,和不同数据集的运行时间可能会有很大差异,因为查询和文档遵循不同的长度分布。为了建立一个共同的框架,我们采用“T恤”方法如下:
MiniLM-L-12-v2
)达到其最大增益的90%所需的时间,类似于我们在上一节中的建议,模型和深度选择过程最好通过图形方式理解。我们创建图表如下:
对于每个“T恤尺寸”,我们简单地选择在相应阈值线与最高截距的模型和深度。最佳深度可以通过插值确定。
图11:Climate-FEVER的nDCG@10随延迟变化的图
图12:DBPedia的nDCG@10随延迟变化的图
图13:FiQA的nDCG@10随延迟变化的图
图14:HotpotQA的nDCG@10随延迟变化的图
一些观察:
bge-reranker-v2-gemma
和monot5-large
在Climate-FEVER
上的情况。MiniLM-L-12-v2
提供了一个很好的示例,展示了一个较小的模型如何利用其效率在低延迟约束下“填补差距”。例如,在FiQA
上,在“小”阈值下,它实现的得分比bge-reranker-v2-gemma
和mxbai-rerank-base-v1
更好,即使这两个模型最终更有效。这是因为MiniLM-L-12-v2
在相同成本下可以处理更多文档(分别是80 vs 10,20)。Climate-FEVER
上,在“中”预算下,bge-reranker-v2-gemma
模型可以达到最大深度20,这足以使其位居第二,超过MiniLM-L-12-v2
和mxbai-rerank-base-v1
。Elastic Rerank
模型在考虑较大延迟值时提供了效率与效果的最佳平衡。下表展示了在5个数据集上应用三种延迟约束下的Elastic Rerank
模型的最大允许深度和相关nDCG分数(相对于BM25的百分比增加)。
T恤尺寸 | 小 | 中 | 大 | |||
---|---|---|---|---|---|---|
数据集 | 深度 | nDCG增加 (%) | 深度 | nDCG增加 (%) | 深度 | nDCG增加 (%) |
DBPedia | 70 | 37.6 | 210 | 42.43 | 400 | 45.7 |
Climate-FEVER | 10 | 31.82 | 40 | 66.72 | 80 | 77.25 |
FiQA | 20 | 44.42 | 70 | 73.13 | 140 | 80.49 |
HotpotQA | 30 | 21.31 | 100 | 28.28 | 200 | 31.41 |
Natural Questions | 30 | 70.03 | 80 | 88.25 | 180 | 95.34 |
平均值 | 32 | 41.04 | 100 | 59.76 | 200 | 66.04 |
表5: 不同场景下Elastic Rerank
模型的最大允许深度和相关的nDCG增加
我们可以看到,较紧的预算(“小”尺寸场景)只允许重排几十个文档,但这足以在nDCG分数上提供显著提升(>40%)。
在这最后一节中,我们总结了主要发现,并提供了一些如何选择给定检索任务的最佳重排深度的指导。
选择适当的重排深度可以对端到端系统的性能产生很大影响。在这里,我们考虑了一些可以指导这一过程的关键维度。我们感兴趣的是在所有查询上应用固定阈值的方法,即没有基于每个查询的可变长度候选生成,例如在这项工作中。
对于我们测试的重排器,我们发现大多数增益是在浅重排中获得的。特别是,平均我们可以通过重排结果的1/3数量实现最大可能nDCG@10增益的90%。对于我们的基准测试,这意味着在使用BM25作为检索器时,平均重排前100个文档。然而,这里有一些细微差别:第一阶段检索器越好,重排的候选者越少,相反,重排器越强,重排越深受益。还有一些失败模式:我们看到某些模型和检索任务的效果在达到最大值后会减少,甚至在任何重排情况下都会减少。在这种情况下,我们发现更有效的模型在某个深度后显著减少“误行为”的可能性。其他研究也报告了类似的行为。
我们探讨了计算预算对重排深度选择的影响。特别是,我们定义了一个在成本约束下选择最佳重排模型和深度的过程。在这种情况下,我们发现新的Elastic Rerank
模型在我们的基准测试中提供了出色的效果。基于这些实验,我们建议在计算成本至关重要时使用Elastic Rerank
模型对BM25的前30个结果进行重排。通过这种选择,我们在基准测试的QA部分实现了约40%的nDCG@10提升。
我们还提出了一些定性观察:
MiniLM-L12-v2
在预算有限的情况下始终是一个强有力的竞争者,DBpedia
和HotpotQA
,Elastic Rerank
在50深度时的性能优于或持平于MiniLM-L12-v2
在400深度时的性能。理想情况下,模型和深度选择应基于您自己语料库的相关性判断。评估数据集的存在使您能够绘制检索指标(如nDCG或召回率)的演变,从而使您能够根据所需的计算成本约束做出明智的决策。
这些数据集通常由领域专家的手工标注构建,或者基于过去观察的代理指标,如历史搜索结果的点击率(CTR)。在我们之前的博客中,我们还展示了如何使用LLM生成自动相关性判断列表,这些列表与自然语言问题的人类标注高度相关。
在没有评估数据集的情况下,无论您的预算是多少,我们建议从较小的重排深度开始,因为对于我们评估的所有模型和任务组合,这都实现了大多数增益,并且避免了一些质量开始下降的病理情况。在这种情况下,您还可以使用我们基准测试中得出的通用指南,因为它涵盖了广泛的检索任务。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号:粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
Copyright © 2013 - 2025 Tencent Cloud.
All Rights Reserved. 腾讯云 版权所有