Coggle数据科学 | JointRank：基于重叠分块与PageRank进行单次并行重排序

本文来源公众号“Coggle数据科学”，仅用于学术分享，侵权删，干货满满。

原文链接：JointRank：基于重叠分块与PageRank进行单次并行重排序

在当今的信息检索系统中，无论是网络搜索、推荐系统还是检索增强生成（RAG），从海量候选池中高效筛选出相关项都是一个核心挑战。

传统的列表式重排序器虽然能够通过同时考虑多个候选项目来提高相关性，但在处理大型数据集时常常受限于模型输入大小或导致质量下降。

JointRank: Rank Large Set with Single Pass

https://arxiv.org/pdf/2506.22262

为了解决这一难题，来自 JetBrains 的研究员 Evgeny Dedov 提出了一种名为 JointRank 的新型模型无关方法，旨在以单次通过（single pass）的方式实现对大型数据集的高效重排序。

传统重排序器的局限性

现有方法在处理大量候选项目时主要面临以下挑战：

• 模型输入大小限制： 大多数列表式重排序模型都有输入长度限制，难以一次性处理成百上千的候选项目。

• 计算成本与延迟： 即便模型支持较长的上下文，处理超长序列也会带来巨大的计算成本，导致显著的推理延迟。

• 多步迭代的低效性： 诸如滑动窗口排序、集合式堆排序等迭代方法虽然减少了单次模型调用的负担，但仍需多次顺序调用重排序模型，这在实时应用中会累积产生高延迟，影响用户体验。

排序问题的定义与模型分类

尽管列表式和集合式模型能提供更准确的排序，但它们在处理大规模数据集时面临严重的可伸缩性问题和效率瓶颈。

LLM 排序与大型文档集处理策略

论文回顾了当前利用大型语言模型（LLM）进行排序的趋势，并详细分析了现有处理大型文档集的几种方法。

LLM 排序

LLMs 在信息检索等任务中表现出色，但其计算和时间成本高昂。研究人员探索了多种零样本（zero-shot）排序方法：

• Pointwise： 二进制分类或细粒度评分。

• Pairwise： 通过提示词进行两两比较。

• Listwise： 列表式排序技术。

• 此外，也有针对 LLM 排序的微调（fine-tuning）方法。

处理大型文档集的方法

• Calibration（校准）：

  • 思路： 通过微调列表式模型，使其输出的分数在不同批次间可比较，从而可以独立处理批次并聚合排名。

  • 局限性： 这种方法需要模型微调，不适用于 JointRank 所追求的零样本、模型无关的重排序。

• Sorting（排序）：

  • 思路： 传统排序算法（如快速排序、归并排序）理论上有效，但依赖大量的顺序调用排序模型（ Nlog2N次），导致计算成本过高。

  • 并行化尝试： 虽然排序可以高度并行化（如 PRP-AllPair 同步比较所有可能对），但对于大型候选集，这可能因资源限制而不可行。

  • Top-k 关注： 排名并非纯粹的排序问题，通常更关注识别 Top-k 项而非对整个集合排序。

  • 优化方法： [8] 提出了结合列表式/集合式重排序器和动态剪枝的优化排序方法，但仍然涉及重复的重排序器推理。JointRank 将主要与 Setwise.heapsort 进行比较。

• Tournament Approaches（锦标赛方法）：

  • 思路： 将元素分成组，组内排序，然后选出 Top-m 元素进入下一阶段，重复此过程。多个锦标赛可并行运行，聚合分数。

  • 局限性： 顺序调用的次数和跨度时间取决于选择阶段的数量，仍存在多次顺序调用的问题。

• Sliding-window Listwise Ranking（滑动窗口列表式排序）：

JointRank并行中实现高效排序

在信息检索的实时应用中，如大型语言模型助手中的 RAG、代码补全工具或交互式问答系统，延迟（Latency）是决定用户体验和系统可用性的关键因素。传统上，基于 LLM 的重排序方法往往需要多次顺序调用模型，这导致累积延迟过高，难以满足实时需求。

JointRank 的核心思想可以概括为以下几个步骤（如图 1 所示）：

1. 分块构建： JointRank 精心设计了文档批次，称之为“块（blocks）”。这些块被设计成充分重叠。这意味着一个文档可能会出现在多个块中。

2. 并行排序： 每个构建好的块都足够小，可以被一个列表式排序模型（如 LLM）高效处理。最关键的是，所有这些块的排序任务都是并行执行的。这意味着只需要一次大规模的并行推理，而不是多次顺序调用。

3. 隐式两两比较： 从每个并行处理的块内部排序结果中，JointRank 能够生成大量的隐式两两比较。例如，如果文档 A 在某个块中排在文档 B 之前，则可以推断 A 优于 B。

4. 构建竞技图： 块之间的故意重叠是至关重要的，它确保了所有文档之间的全局连通性。这些隐式比较构成了竞技图（tournament graph），反映了文档之间的相对优劣关系。

5. 全局排名重建： 最后，利用成熟的排名聚合算法（如 Elo Rating、PageRank、Winrate、Rank Centrality 等），从这个竞技图中重建出一个完整的全局排名。

JointRank 在块构建中借鉴了实验设计（experimental design） 的原理，特别是“分块（blocking）”的核心思想——将初始集合分离成多个子集。同时，它还融入了随机化（随机元素和随机顺序）、复制（每个项目出现在多个块中）和平衡（恒定块大小 k、每对项目在块中出现次数lambda 、每个项目复制次数r ）等原则。 对于排序问题，设计必须是连通的，以允许估计至少部分顺序。尽管连通性本身可能不足以保证恢复完整的线性顺序，但它比覆盖设计所需的块要少得多。考虑到 ML 系统预测的两两比较可能不完全一致（即不具备完美的传递性和反对称性），最终得到的图应被视为竞技图而非简单的比较图。

理想情况下，为了最小化排序估计误差，设计应是覆盖的、平衡的、随机的且冗余的。然而，考虑到 ML 系统排序的计算成本，论文建议放宽这些要求，推荐使用连通的等复制设计（EBD）或连通的 PBIBD。在研究中，作者对比了随机设计、EBD、PBIBD 和滑动窗口设计。

JointRank 实验评估

为了全面验证 JointRank 的有效性，研究团队进行了两个阶段的评估：首先是合成数据实验，旨在优化超参数并深入理解算法性能；随后是真实信息检索数据集上的评估，以衡量其在实际场景中的表现。

• 设定： 创建一个包含 v 个元素的列表，并赋予指数级相关性值（从 21 到 2v）。然后将列表随机打乱，目标是使用一个“神谕（Oracle）”列表式重排序器来恢复其正确的全局顺序。

• 聚合算法： 采用包括 PageRank、Elo Rating、Winrate、Rank Centrality 等在内的多种竞技图聚合算法进行全局排名重建。

实验首先评估了不同块设计（Triangular PBIBD, Latin-Square PBIBD, Equi-Replicate, Sliding Window, Random）和排名聚合算法的组合性能。

• 块设计的选择至关重要： 表 2 和表 4 显示，PBIBD（尤其是 Triangular 和 Latin-Square）在两种设置下都取得了最佳的 nDCG@10 表现，紧随其后的是 **Equi-Replicate Block Design (EBD)**，其性能与 PBIBD 相当接近。相比之下，朴素滑动窗口和随机方法表现明显较差。

• 聚合方法的选择也很重要： 表 3 和表 5 强调了排名聚合方法的重要性。PageRank 在设计均衡的块上表现最佳。然而，对于滑动窗口和随机块设计等不平衡的块，简单的平均胜率（Average Winrate）方法反而表现更优。

• 推荐策略： 综合来看，PBIBD 表现最佳。但由于其构建上的复杂性和参数限制，当无法构建 PBIBD 时，Equi-Replicate Block Design (EBD) 是一个极佳的替代方案，性能仅略微下降。

论文进一步的实验探索了块数量和块大小对最终排名质量的影响：

• 块数量： 增加块数量能提升排名质量，但在使用良好构建的块设计时，即使是简单的平均胜率方法也能取得接近 PageRank 的结果（图 2），这表明块设计的良好性可以弥补聚合方法的简单性。

• 块大小： 实验结果（图 3 和图 4）揭示，块大小对排名准确性的影响显著强于块数量。这是因为每个块贡献的比较次数与块大小的平方成正比 (k(k−1)/2)，而与块数量成线性关系。因此，要用较小块大小对长序列进行有效重排序，需要非常大量的块，甚至可能超过候选池本身的大小。

论文还通过多种统计数据（直接比较覆盖率、二阶比较覆盖率、平均/最小/最大节点度、共现率和连通率）评估了不同设计的覆盖能力（表 6 和表 7）。

在合成实验验证了算法原理和优化了超参数之后，JointRank 在真实的 TREC DL-2019 数据集上进行了严格评估，并与一系列现有 SOTA 方法进行了对比。

• 设置： 使用 BM25 检索初始 Top-100 列表，然后应用包括 JointRank 在内的多种重排序方法。对比算法包括：FullContextListwise（单次 LLM 调用处理所有候选）、SlidingWindow (RankGPT)、Setwise.heapsort、TDPart 和 TourRank。

• 公平对比： 所有 LLM 推理的最大处理候选数（窗口大小）统一为 20。JointRank 使用 Equi-Replicate Block Design 和 PageRank 聚合。

• 评估指标： nDCG@10，以及非功能指标（推理次数、输入/生成 token 数、延迟）。还引入了“Oracle reranker”作为理论性能上限。

• 模型： Mistral-7Bv0.3 和 Mistral-24B-2501。

JointRank 取得了最佳的延迟表现，与 FullContextListwise 相当，但质量显著提升。例如，使用 Mistral-24B-2501，JointRank 的 nDCG@10 为 69.10，而 FullContextListwise 仅为 61.76，延迟均为 2 秒。

为了进一步评估大上下文模型在处理无序、大量输入时的能力，实验将 BM25 检索到的 Top-1000 文档随机打乱，然后传递给重排序算法。这次允许除了 FullContextListwise 外的所有算法一次处理 100 个项目。模型选用 gpt-4.1-mini。

THE END !

文章结束，感谢阅读。您的点赞，收藏，评论是我继续更新的动力。大家有推荐的公众号可以评论区留言，共同学习，一起进步。