一、研究背景与核心问题当前神经信息检索IR系统发展迅速主流基准测试如MS MARCO、XOR-TyDi的排行榜完全基于准确率指标如MRR10进行排名。然而这种单维度评估存在严重缺陷系统追求更高准确率往往以牺牲效率为代价实际生产环境中的IR系统必须在延迟、硬件成本、内存占用等严格约束下运行现有排行榜无法反映这些关键的成本-质量权衡导致进步具有欺骗性核心观点IR基准测试应采用多维排行榜同时评估准确率、查询延迟和硬件成本以反映真实部署场景中的复杂权衡。二、研究内容与方法2.1 事后排行榜分析第2节作者从已发表论文中构建了MS MARCO的事后排行榜揭示以下问题发现具体表现硬件配置差异巨大不同论文使用的硬件环境各不相同甚至同一模型如SPLADEv2报告延迟相差3倍220ms vs 691ms硬件过度配置普遍研究者常使用远超需求的硬件表2显示表1中的配置多为过度配置效率指标严重缺失多数论文如RocketQAv2、coCondenser、CoT-MAE仅报告准确率完全无法评估效率相同准确率下效率悬殊CoT-MAE和PLAID ColBERTv2准确率相同39.4但效率信息缺失无法比较2.2 系统性实验比较第3节作者选取四类代表性模型进行受控实验固定硬件平台并测量多维度性能模型类型代表模型特点词汇模型BM25低延迟、低成本、低准确率密集单向量模型DPR传统神经检索方法稀疏神经模型BT-SPLADE-L平衡质量与效率后期交互模型PLAID ColBERTv2 (S/M/L三档)最高准确率、计算密集实验数据集MS MARCO域内 XOR-TyDi零样本跨语言域外关键实验发现准确率最高ColBERTv2系列在MS MARCO上全面领先XOR-TyDi上ColBERTv2-L表现最佳性价比最优BT-SPLADE-L在适度牺牲准确率下提供更快更便宜的选择反直觉现象选择更贵的实例如c7g.4xlarge可能因4倍速度提升而降低总成本GPU价值有限大多数配置下为ColBERTv2使用GPU并不经济合理三、提出的解决方案多维排行榜框架第4节3.1 评估平台建议强制使用公共云实例要求提交者绑定到可复现的AWS/Azure/GCP实例类型以美元成本统一量化将CPU数、GPU数、内存、存储等资源消耗转化为可比较的货币成本动态定价策略随云服务价格变化更新排行榜排名可能因此动态变化3.2 评分与排名策略作者提出三种评分方式策略描述固定效率阈值设定延迟/成本上限按准确率排名固定准确率阈值设定准确率下限按效率排名Dynascore加权聚合最灵活可分配权重给各维度形成单一排名3.3 Dynascore机制Dynascore是一种效用理论驱动的聚合评分方法允许排行榜创建者为准确率、成本、延迟分配任意权重不同权重反映不同应用场景的价值观如移动端vs数据中心作者系统探索了不同权重下的排名变化图2关键结论若准确率权重 ≥ 0.5ColBERTv2系列统治排行榜若成本/延迟权重大幅提高BT-SPLADE-L超越ColBERTv2BM25仅在准确率权重接近零时才有竞争力不同权重产生完全不同的最佳系统证明了多维评估的必要性3.4 推荐评估指标指标作者立场延迟核心指标应允许多线程/GPU以反映真实优化潜力美元成本最推荐的核心指标直接映射到部署开销吞吐量补充指标需明确定义测量方式串行/批量FLOPs不推荐IR系统多为带宽瓶颈而非计算瓶颈内存/索引大小重要补充信息已通过成本间接量化四、主要贡献揭示问题通过实证数据证明现有IR排行榜因忽略效率维度而具有误导性系统间的真实权衡被完全隐藏建立方法论提出并演示了完整的多维IR评估框架——包括数据收集、实验设计、指标选择和评分机制量化权衡通过系统实验量化了BM25、DPR、SPLADE、ColBERTv2四类模型在准确率-延迟-成本三维空间中的真实位置和权衡关系可操作建议为未来IR基准测试提供了具体的设计指南使用公共云实例、统一成本度量、采用Dynascore加权排名价值观透明化强调排行榜权重设置本身就是一种价值观声明不同应用场景应有不同排行榜而非一个唯一正确的排名五、局限性声明模型覆盖不全未包含重排序模型rerankers其成本-质量权衡更为复杂指标范围有限仅聚焦准确率、延迟、成本三维度其他维度如吞吐量、内存峰值讨论较少实验配置选择不同模型配置如SPLADE的32GB内存设定可能影响结论非穷尽比较未涵盖所有现有系统不同选择可能得到不同结果当前IR基准测试的准确率进步部分是虚幻的——它掩盖了系统为追求准确率而付出的大量效率代价。未来的IR排行榜必须转变为多维评估平台让研究人员和从业者能根据自身资源约束和应用场景在准确率、延迟和成本之间做出明智的权衡选择。这里是自己的论文阅读记录感兴趣的话可以参考一下如果需要阅读原文的话可以看这里如下所示摘要近年来神经信息检索IR系统发展迅速这在很大程度上归功于公开可用的基准测试任务的发布。不幸的是这种进展的某些方面是虚幻的目前主流的信息检索基准测试大多只关注下游任务的准确率从而掩盖了系统为了效率而牺牲质量所带来的成本。延迟、硬件成本和其他效率考量对于信息检索系统在面向用户的场景中部署至关重要。我们建议信息检索基准测试应将其评估方法结构化不仅要包含准确率指标还要包含效率考量例如查询延迟以及可复现硬件设置下的相应成本预算。针对流行的信息检索基准测试 MS MARCO 和 XOR-TyDi我们展示了最佳信息检索系统的选择如何根据这些效率考量的选择和权重而变化。我们希望未来的基准测试能够采纳这些指导方针以实现更全面的信息检索评估。1 引言基准数据集有助于推动神经信息检索IR的快速发展。当 MS MARCO (Nguyen et al., 2016) 段落排序排行榜于 2018 年启动时表现最佳的系统的 MRR10 分数约为 0.20最新的提交结果已将其准确率提升至 0.44 以上。同样XOR-TyDi 多语言问答QA数据集 (Asai et al., 2020) 于 2021 年发布其召回率分数已从 0.45 提高到远超 0.70。这些数据集的排行榜由一套特定的基于准确率的指标定义在这些指标上的进展很容易在人们心目中等同于整体的进步。然而部署在生产环境中的信息检索和问答系统不仅必须提供高准确率还必须在严格的资源要求内运行包括对每查询延迟的严格限制、对磁盘和内存容量的约束以及固定的硬件成本预算。在这些约束的边界内针对下游任务的最优解决方案可能不再是仅仅达到最高任务准确率的系统。图 1 展示了这些权衡可能有多么显著。该图追踪了选定的 MS MARCO 段落排序提交结果x 轴表示成本y 轴表示准确率MRR10。在一个极端BM25 模型每百万次查询仅需 0.04 美元但其准确率远低于其他模型。在成本与 BM25 非常接近的情况下可以使用 BT-SPLADE-S 并获得更好的性能。另一方面SPLADE-v2-distil 模型的性能比 BT-SPLADE-S 高出约 1 个点但成本却要高得多。不幸的是这些权衡不会反映在 MS MARCO 排行榜上。同样截至 2022 年 10 月XOR-TyDi 排行榜上排名前两位的系统在 Recall5000 tokens 上仅相差 0.1 分但这两种方法在资源效率上的差距完全不清楚。图 1选定的 MS MARCO 段落排序提交结果在成本与准确率上的评估帕累托前沿以虚线标出。此处显而易见的权衡在现实世界的信息检索技术应用中很常见。这些提交结果并不代表每种方法的“最优”实现而是反映了文献中报告的实现和硬件配置。在排行榜中加入成本和其他效率考量将有助于更全面地探索可能的系统设计从而带来更有意义的进展。在这项工作中我们为倡导多维排行榜以反映不同价值观和目标的文献做出了贡献 (Coleman et al., 2017; Mattson et al., 2020a,b; Baidu Research, 2016; Ma et al., 2021; Liu et al., 2021a; Liang et al., 2022)。我们的建议是研究人员除了报告基于准确率的指标外还应报告正交的性能维度如查询延迟和总体成本。我们的论点主要有两部分。在第一部分第 2 节我们从已发表的论文中创建了一个事后的 MS MARCO 排行榜表 1。这揭示出具有相似准确率的系统通常在其他维度上差异显著并且目前改进延迟、减少内存和硬件成本的技术仅得到零星探索。然而少数贡献 (Santhanam et al., 2022a; Lassance and Clinchant, 2022; Engels et al., 2022; Li et al., 2022) 体现了我们所倡导的对准确率和效率进行深入调查的典范我们相信改进后的多维排行榜能够激发这些领域的进一步创新。在第二部分第 3 节我们系统地探索了四个代表性系统BM25、Dense Passage Retriever (DPR; Karpukhin et al. 2020)、BT-SPLADE-L (Formal et al., 2021; Lassance and Clinchant, 2022) 和 PLAID ColBERTv2 (Khattab and Zaharia, 2020; Santhanam et al., 2022a,b)。这些实验开始提供这些系统整体性能的更全面图景。最后我们讨论了与该领域所需的多维排行榜相关的实际考量。在此我们认为 Ma 等人 (2021) 开发的 Dynascore 指标是一个有前景的基础用于构建旨在 (1) 在多维度上衡量系统并 (2) 提供系统单一完整排名的排行榜。Dynascore 允许排行榜创建者为不同的评估维度分配权重例如使成本比延迟更重要。这些权重透明地反映了一组特定的价值观我们表明它们所产生的排行榜可能比当前的排行榜更能激励不同的研究问题和系统开发选择。2 一个事后的排行榜虽然现有的信息检索基准测试促进了准确率指标的进步但缺乏统一的测量延迟、内存使用和硬件成本的方法论使得理解系统间的权衡变得困难。为了说明这一挑战我们为 MS MARCO 段落排序基准测试构建了一个事后排行榜表 1。我们纳入了先前工作中报告的 MRR10 值并在可能的情况下从相应论文中复制了平均每查询延迟、索引大小和硬件配置。我们强调以下关键要点。表 1使用相应论文中报告的结果对 MS MARCO v1 开发集性能进行的事后排行榜。对于硬件规格我们显示了论文中作为运行环境给出的确切资源即使并非所有资源都可供模型使用或资源对于特定任务而言是过度配置的。表 2 提供了我们对此类系统中一部分的最低硬件要求的估计。请注意列出的第一个 PLAID ColBERTv2 结果是在包含 4 个 GPU 的服务器上运行的但实际上测量时并未使用 GPU因此导致延迟比第二个测量 GPU 执行的结果更大。表 1使用相应论文中报告的结果对 MS MARCO v1 开发集性能进行的事后排行榜。对于硬件规格我们显示了论文中作为运行环境给出的确切资源即使并非所有资源都可供模型使用或资源对于特定任务而言是过度配置的。表 2 提供了我们对此类系统中一部分的最低硬件要求的估计。请注意列出的第一个 PLAID ColBERTv2 结果是在包含 4 个 GPU 的服务器上运行的但实际上测量时并未使用 GPU因此导致延迟比第二个测量 GPU 执行的结果更大。2.1 硬件配置表 1 中的硬件配置是相应论文中列出的具体计算环境而非达到报告延迟所需的最低可行硬件。在表 2 中我们试图明确运行每个系统所需的最低配置。这可能导致对延迟的评估过于乐观见第 3 节。表 1 和表 2 之间的硬件差异揭示出研究人员经常为其实验使用过度配置的硬件。我们提出的排行榜将产生一种压力促使在报告效率指标时更审慎地考虑所用硬件的成本。表 2运行每个模型所需的最低可行 AWS 实例类型估计。RAM 单位为 GiB成本为每百万次查询。2.2 方法论的差异表 1 显示不同模型的评估质量指标和所用硬件差异很大。许多论文仅报告准确率这使得无法定量理解效率影响 (Ren et al., 2021; Gao and Callan, 2021; Wu et al., 2022)。对于那些确实报告了效率导向指标的论文评估环境和 methodology 也常常不同例如Mackenzie 等人 2021 和 Lassance 与 Clinchant 2022 的结果是在单个 CPU 线程上测量的而 Khattab 与 Zaharia 2020 和 Santhanam 等人 2022a 则利用多个 CPU 线程进行查询内并行甚至在特定设置中使用 GPU。我们还观察到即使对于同一模型性能也存在变异性Mackenzie 等人 2021 (220 毫秒) 和 Lassance 与 Clinchant 2022 (691 毫秒) 报告的 SPLADEv2 延迟数字相差 3 倍。同样这些论文报告的 BM25 延迟也相差 2 倍。2.3 多维评估标准MS MARCO 的最优模型选择在很大程度上取决于我们如何权衡不同的评估指标。纯粹基于准确率CoT-MAE 和 PLAID ColBERTv2 是表 1 中的佼佼者两者的 MRR10 分数均为 39.4。然而我们缺乏在其他维度上比较它们所需的所有信息。另一方面BM25 是最快的模型根据 Lassance 和 Clinchant (2022) 的测量每查询延迟仅为 4 毫秒并且其空间占用也很小。其代价是该队列中准确率最低。与 BM25 相比高度优化的 BT-SPLADE 模型之一可能是更好的选择。图 1 开始展示我们如何思考这些常常相互矛盾的压力。3 代表性检索器的实验如表 1 所示现有文献缺乏对模型的系统性、多维比较。在本节中我们报告了使我们能够进行这些比较的实验。我们关注四个模型BM25(Robertson et al., 1995) 一种基于稀疏项的 IR 模型。BM25 在许多 IR 场景中仍然是一个强大的基线以其低延迟和低成本著称。我们评估一个基础实现。表 3实验结果。延迟为平均每查询延迟毫秒成本为每百万次查询。DPR(Karpukhin et al., 2020) 一种密集检索模型它使用双编码器架构将查询和段落映射到共享的向量空间。BT-SPLADE-L(Formal et al., 2021; Lassance and Clinchant, 2022) 一种稀疏神经检索模型它学习词汇表上的稀疏向量表示。PLAID ColBERTv2(Khattab and Zaharia, 2020; Santhanam et al., 2022a,b) 一种后期交互模型它在查询和段落 token 之间进行细粒度交互。我们评估其三种配置分别对应不同的近似度 k 值k10, 100, 1000称为 ColBERTv2-S、ColBERTv2-M 和 ColBERTv2-L。我们选择这些模型作为关键 IR 模型类型的代表词汇模型 (BM25)、密集单向量模型 (DPR)、稀疏神经模型 (SPLADE) 和后期交互模型 (ColBERT)。这三种 ColBERT 变体提供了一个了解模型配置选择如何与我们评估指标相互作用的窗口。我们使用两个检索数据集MS MARCO (Nguyen et al., 2016) 和 XOR-TyDi (Asai et al., 2020)。我们分析中的所有神经模型都在 MS MARCO 数据上进行了训练。我们在 XOR-TyDi 上直接评估不进行进一步的微调以测试域外评估详见附录 A。我们的目标是理解这些模型的相对性能如何随可用资源和评估标准变化。我们的方法与第 2 节中详细描述的事后排行榜在两个关键方面有所不同(1) 我们固定所有模型的基础硬件平台(2) 我们在广泛的硬件配置AWS 实例类型上评估每个模型确保覆盖广泛的计算环境。此外除了质量我们还报告平均每查询延迟以及在给定延迟和实例类型选择下运行 100 万次查询的相应成本。因此这种方法能够实现模型之间更原则性和全面性的比较。我们使用开源的 PrimeQA 框架它提供了 BM25、DPR 和 PLAID ColBERTv2 实现的统一接口。对于 SPLADE我们使用论文作者维护的开源实现。对于每个模型我们检索前 10 个最相关的段落。我们报告在 5 次试验中对每个数据集的固定 1000 个查询样本运行的平均延迟。关于评估环境和模型配置的更多详情请参见附录 A。表 3 总结了我们的实验。表 3a 和 3b 报告了效率数据成本估算依据与表 2 相同的硬件定价。表 3c 给出了准确率结果MRR10 和 Success10。总体而言BM25 是选择最小可行实例类型时成本最低的模型只有 BM25 能够使用 4 GB 内存运行。然而其准确率之低足以使其基本失去竞争力。在这两个数据集上我们发现 BT-SPLADE-L 和 PLAID ColBERTv2 变体在准确率上遥遥领先。在 MS MARCO 上所有 ColBERTv2 变体在 MRR10 和 Success10 上均优于 BT-SPLADE-L而对于允许适度质量损失的应用BT-SPLADE-L 提供了比 ColBERTv2 更快和更便宜的场景。在域外 XOR-TyDi 评估中BT-SPLADE-L 优于设置 k10计算强度最低的配置的 ColBERTv2-S 变体。我们假设这种质量损失是默认配置采用的近似方法的产物。因此我们也测试了上述计算密集度更高的配置ColBERTv2-M (k100) 和 ColBERTv2-L (k1000)。这些测试显示ColBERTv2-L 在 MRR10 和 Success10 上显著优于 BT-SPLADE-L同时允许 BT-SPLADE-L 扩大其在延迟和成本上的优势。有趣的是尽管某些实例的单价更高但选择更昂贵的实例实际上可以降低模型的总体成本。例如c7g.4xlarge 实例比 x2gd.large 贵 3.5 倍但 ColBERTv2-S 使用 16 个 CPU 线程运行速度快 4 倍因此在 c7g.4xlarge 上执行更便宜。这些发现进一步揭示了模型配置、效率和准确率之间丰富的权衡空间。4 讨论与建议在本节中我们强调了未来 IR 排行榜的几个考虑因素并为关键设计决策提供建议。4.1 评估平台IR 排行榜的一个关键设计目标应是鼓励透明、可复现的提交。然而如表 1 所示许多现有的提交是使用定制且可能私有的硬件配置执行的因此难以复制。相反我们强烈建议所有提交都与特定的公共云实例类型绑定。特别是排行榜应要求与每个提交相关联的特定评估环境在推理时易于复现。这鼓励提交者找到现实且透明的方式来使用公共云资源在满足自身延迟和质量目标的前提下最大限度地降低其提交的实际成本。我们注意到我们纳入的“成本”涵盖了系统可能考虑的许多个体权衡例如索引和模型所需的内存或原则上存储量或 CPU、GPU 或 TPU 的数量。原则上排行榜可以报告组成资源而不是报告特定的可复现硬件平台。例如排行榜可以简单地报告每次提交的 CPU 线程数和 GPU 数。这样做的好处是将提交内容与公共云提供商提供的产品解耦。然而这种方法无法考虑到不断增长的硬件资源空间或其可变且不断变化的定价。例如期望排行榜构建者量化 V100 与更新的 A100 GPU——或更新一代如 H100更不用说 FPGA 或其他异构选择——之间的成本差异可能是不现实的。我们认为允许提交者选择自己的公共云实例包括其功能和定价反映了一种现实的、市场驱动的、最新的美元成本估算策略。在实践中排行榜创建者需要制定应对价格随时间变化的政策。例如他们可以选择始终使用最新的定价。这可能导致排行榜排名随时间发生变化反映出成本与其他评估维度之间不断变化的权衡。4.2 评分效率感知的 IR 排行榜在评分和排名提交结果方面有几种选择。我们在此列举三种策略固定延迟或成本阈值例如并按准确率对合格系统进行排名。可以选择不同的阈值以促进不同资源环境如手机 vs 数据中心下的竞争。固定准确率阈值并按延迟或成本或其他方面对合格系统进行排名。准确率阈值可以设定为前几年的最先进结果。对不同评估维度进行加权并将其提炼为单一分数可能在对系统进行基于准确率、延迟和/或成本阈值的过滤之后进行。在这些方法中第三种最灵活并且是唯一能提供系统完整排名的方法。Ma 等人 (2021) 的 Dynascore 似乎特别适合 IR 排行榜因为它允许排行榜创建者为评估中包含的每个维度分配权重反映分配给每个维度的相对重要性。Dynascore 本身是一种效用理论聚合所有测量结果的方法并产生对所考虑系统的排名。在表 4 中我们展示了如果采用这种 Dynascore 加权方案MS MARCO 和 XOR-TyDi 排行榜会是什么样子。在两个排行榜中ColBERTv2 变体都是获胜系统。这在 XOR-TyDi 上非常决定性。对于 MS MARCOColBERTv2 和 SPLADE 总体非常接近。表 4默认加权方案 {准确率: 0.5, 成本: 0.25, 延迟: 0.25} 下的 Dynascores。然而这种加权方案并非唯一合理的选择。附录 B 展示了一系列不同的排行榜反映了不同的相对价值。在此我们提及几个亮点。首先如果准确率非常重要例如MRR10: 0.9那么所有 ColBERTv2 系统都主导其他系统。其次如果我们对成本非常敏感我们可以使用权重 {MRR10: 0.4, Cost: 0.4, Latency: 0.2}。在这种情况下对于 MS MARCOColBERTv2-S 升至排行榜榜首BT-SPLADE-L 也更具竞争力。第三另一方面如果资金不是问题我们可以使用权重 {MRR10: 0.75, Cost: 0.01, Latency: 0.24}。这种设置证明了为 ColBERTv2 使用 GPU 是合理的而大多数其他设置则无法证明为该系统使用 GPU 是合理的。相比之下为 BT-SPLADE-L 使用 GPU 从来都不是合理的。为了全面了解不同权重如何影响这些排行榜我们对不同的权重向量进行了系统探索。图 2a 总结了这些发现显示了每种设置下的获胜系统。图中 x 轴为延迟y 轴为准确率。三个权重之和始终为 1Dynascores 已归一化因此 Cost 值由其他两个确定即 1.0 - 准确率 - 延迟。整体情况很清晰。对于 MS MARCO假设准确率是最重要的价值ColBERTv2-M 或 ColBERTv2-S 系统通常是最佳选择而 ColBERTv2-L 从未获胜。相比之下当成本和延迟比准确率重要得多时BT-SPLADE-L 系统通常是最佳选择。DPR 仅在准确率相对不重要时获胜而 BM25 仅在准确率被赋予零重要性时获胜。对于域外 XOR-TyDi 测试情况有所不同现在 ColBERTv2-L 是主导系统其次是 BT-SPLADE-L。图 2Dynascore 加权方案的探索。标记大小与成本权重成比例大点代表对成本更敏感的加权方案因此最昂贵的系统位于对角线附近。4.3 指标在此我们简要探讨各种指标及其在排行榜设计中的潜在作用从我们在实验中关注的两个开始延迟延迟衡量执行单个查询并将结果返回给用户的时间。一些现有工作在单个 CPU 线程上测量延迟以将系统性能与潜在噪音隔离开来 (Mackenzie et al., 2021; Lassance and Clinchant, 2022)。虽然这种方法确保了不同系统的公平竞争环境但它未能奖励那些确实受益于加速计算例如在 GPU 上或查询内并行如 DPR 和 PLAID ColBERTv2的系统。因此对于将原始延迟作为主要目标的排行榜我们建议在评估硬件方面允许灵活性以实现尽可能快的提交。这种灵活性随后体现在下面的美元成本中。美元成本衡量部署 IR 系统的财务开销对于生产环境至关重要。衡量成本的一种方法是选择特定的公共云实例类型并将实例租赁费率乘以执行固定数量查询的时间如表 2 所示。吞吐量吞吐量衡量在固定时间段内可以执行的总查询数。最大化吞吐量可能需要以牺牲平均每查询延迟为代价以支持同时完成更大容量的查询。重要的是排行榜应明确定义在实践中测量延迟和/或吞吐量的方法论例如以一次完成一个查询的平均时间或以完成一批 16 个查询的平均时间。FLOPs特定模型执行的浮点运算次数FLOPs提供了一个与硬件无关的指标来评估计算复杂度。虽然这个指标在计算密集型操作如语言建模 (Liu et al., 2021b)的背景下有意义但 IR 系统通常由异构管道组成其中瓶颈操作可能是带宽受限的 (Santhanam et al., 2022a)。因此我们不鼓励将 FLOPs 作为 IR 排行榜的竞争指标。内存使用IR 系统通常预先计算大型索引并将其加载到内存中 (Johnson et al., 2019; Khattab and Zaharia, 2020)这意味着内存使用是确定运行给定系统所需最低硬件的重要考虑因素。特别是我们建议排行榜提交者至少报告索引大小并在可能的情况下报告动态峰值内存使用。报告每个系统的美元成本即考虑了为每个系统提供的总 RAM使我们能够在实践中量化此维度的影响。5 结论我们认为当前的信息检索基准测试应采用多维排行榜根据延迟、成本以及标准的准确率风格指标来评估系统。这样的排行榜可能会产生刺激创新的效果并导致文献中更彻底的实验和更详细的结果报告。作为概念验证我们对四个代表性 IR 系统进行了实验测量了延迟、成本和准确率并表明这揭示了这些系统之间重要的差异而如果仅报告准确率这些差异是被隐藏的。最后我们初步提出 Dynascoring 作为在该领域创建多维排行榜的一种简单、灵活的方法。6 局限性我们指出了我们工作的两个局限性来源我们所考虑的指标范围以及我们在实验中所探索的模型范围。我们的论文倡导多维排行榜。为了简洁起见我们关注成本、延迟以及系统质量。这些选择反映了开发检索模型时的一套特定价值观。在第 4.3 节中我们简要考虑了更广泛的指标范围并强调它们所编码的一些价值观。然而即使是这个列表也并非详尽无遗。总的来说我们希望我们的工作能够引发更多关于该领域排行榜应包含的价值观的讨论因此我们不打算用我们的选择来限制探索。对于我们的事后排行榜表 1我们调查了文献以寻找代表性系统。我们不能声称已经详尽列出了所有系统任何遗漏都应视为我们工作的局限性。特别是我们注意到我们没有考虑任何重排序模型这些模型会消耗我们测试的任何检索器产生的 top-k 结果并生成重新排列的列表。此类模型只会增加我们关于多样化的成本-质量权衡论点的分量因为重排序系统必须确定使用哪个检索器进行重排序每个查询重排序多少段落即设置 k以及为重排序模型使用何种硬件这些模型通常尤其依赖加速器即需要 GPU 或 TPU。对于我们的实验比较我们选择了我们认为代表该领域广泛方法的四种模型。然而从所有可能性空间中做出不同的选择可能会导致不同的结论。此外我们的实验方案可能与我们的模型选择产生重要的相互作用。例如关于 SPLADE 的文献表明它可能能够将索引放入 8 GB 或 16 GB 内存的机器上但我们的实验使用了 32 GB 内存。我们的希望仅仅是我们的结果有助于鼓励开发能够提供来自科学界众多成员的大量细粒度比较的排行榜并且这些排行榜能够反映对系统进行评分和排名的不同价值观。