霸榜MS MARCO！基于Transformer的混合列表感知排序模型

科技

2022-07-19 19:07

©PaperWeekly 原创 · 作者 | Maple小七

单位 | 北京邮电大学

研究方向 | 自然语言处理

本文是当前 MS-MARCO Passage Ranking 排行榜 Top1 模型的刷榜策略之一，该模型由阿里达摩院于今年 3 月提交，目前已霸榜 3 个月。

论文题目：

HLATR: Enhance Multi-stage Text Retrieval with Hybrid List Aware Transformer Reranking

论文链接：

https://arxiv.org/abs/2205.10569

代码链接：

https://github.com/Alibaba-NLP/HLATR

Introduction

由于数据规模和计算资源的限制，当前最先进的文本检索系统通常遵循召回-排序范式 (retrieve-then-reranking)，在预训练语言模型的背景下，召回和精排模型通常被实例化为下图所示的表征式模型 (representation-focused) 和交互式模型 (interaction-focused)。

虽然在检索系统中，召回和排序模型是紧密关联的，但是目前已发表的工作大多仅致力于优化整个检索系统的单个模块。也就是说，面向召回模型的优化工作大多不会考虑排序模型的性能，反之亦然。虽然最近也出现了一些联合优化召回模型和排序模型的工作，比如百度的 RocketQAv2、ERNIE-Search 和微软的 AR2，但是这些工作的出发点都是利用表达能力更强的排序模型来提升召回模型的性能。

那么，除了采用知识蒸馏、对抗训练等方式来联合优化召回模型和排序模型，还有没有其他有效的方式让召回和排序这两个模块得到充分的交互呢？

直观上来说，虽然召回模型和排序模型的优化目标本质上都是估计 query 和 document 的语义相关性，但是由于训练过程中负样本规模和特征的差异，召回模型更偏向于学习粗粒度相关性，而排序模型更偏向于学习细粒度相关性。这里需要注意的一点是，细粒度相关性和粗粒度相关性并无优劣之分，它们的关系实际上有点像模型鲁棒性和模型泛化性的关系。对于单模型来说，从千万级的文档库中直接找到最相关的文档是一项非常困难的任务，因此我们需要将这个困难的任务分解成两个更简单的子任务：召回、排序，从而实现细粒度相关性建模任务和粗粒度相关性建模任务的解耦。

基于上述分析，我们可以猜想召回和排序的特征实际上是有一定的互补性的，如果我们可以有效地融合召回和排序的特征并用来对候选文档集合做进一步的重排序，是不是能够进一步提升整个系统的排序性能呢？

基于此，本文作者在传统的召回-排序两阶段检索系统的基础上，提出了第三个重排阶段，该阶段融合了粗粒度召回特征和细粒度排序特征，进一步改善 query 和候选 document 的相关性打分，从而提升整个系统的检索性能。本文作者将该三阶段重排序的模型命名为混合列表感知排序模型 (Hybrid List Aware Transformer Ranker, HLATR) ，如下图所示。

HLATR

HLATR 采用 Transformer Encoder 作为特征融合结构，我们知道原始 Transformer 的输入包含编码字词信息的 token embedding 和编码位置信息的 position embedding，但这并不代表 Transformer 只能编码文本序列。在 HLATR 中，作者将排序模型顶层输出的文档表示向量作为 HLATR 输入的 token embedding：

将召回模型输出的排序序号 (ranking order) 作为对应文档的 position embedding：

其中和均为参数矩阵。在训练过程中，Transformer Encoder 的底层输入为：

其中为候选文档集合的大小。HLATR 的训练目标是优化输入文档的打分排序，因此每个位置的输出为和的打分：

得到打分之后，作者采用 listwise 的对比损失优化模型：

综上，HLATR 模块的整体结构如下图所示：

从训练目标来看，HLATR 实际上也是一种排序模型，因为它和第二阶段的排序模块一样，输入为 query 和 document list，输出 query 和每个 document 的相关性打分。但与第二阶段的排序不同，HLATR 排序阶段有如下的三大特点：

1. HLATR 的输入并不是纯文本，而是召回模型输出和排序模型输出的融合特征，因此比起第二阶段排序的 token 级输入，HLATR 的输入是高度语义化的。另外值得注意的是，HLATR 引入召回特征的方式是和召回模型本身无关的，我们可以随意地将召回模型替换为 BM25 这种非神经网络的字面匹配模型。

2. 得益于 Transformer 的特征交互能力，HLATR 输入的文档特征之间从底层开始就进行了充分的特征交互。因此 HLATR 做的是 listwise 级别的相关性建模，而第二阶段排序的相关性建模大多只能做到对输出的相关性打分进行 pointwise 或 pairwise 建模。

3. 得益于高度语义化的文档表示，HLATR 有着更大的负样本规模。HLATR 输入的每个位置都表示着一个文档，由于 Transformer 支持长序列输入，在训练过程中我们可以考虑输入召回模型返回的整个文档集合，而不是像第二阶段排序那样还需要随机抽样负样本来构造训练集。

Experiments

3.1 Setup

作者在 MS-MARCO 的 Passage Ranking 数据集和 Document Ranking 数据集上进行了对比实验。为了验证 HLATR 的有效性和鲁棒性，作者选择了不同的召回模型和排序模型进行实验，其中召回模型包括了稀疏检索模型 BM25 和稠密检索模型 coCondenser 以及 ANCE，排序模型包括了 BERT-base/large 和 RoBERTa-base/large。实验参数如下表所示，可以发现比起召回和排序，HLATR 本身的参数量并不大。

另外，为了验证上述思考和猜想的正确性，作者也为 HLATR 设置了一个简单的基线策略：将召回打分和排序打分做一个线性加权融合，该策略被命名为 WCR (Weighted Combination of two-stage Ranking)：

3.2 Results

作者的实验结果如下表所示，我们可以发现在不同的实验设置下，HLATR 的性能均超越了两阶段排序结构和 WCR 策略，说明 HLATR 带来的性能提升对模型类型和模型大小来说均是鲁棒的。另外，WCR 策略实际上也能够带来小幅度的稳定提升，这也说明我们之前做出的猜想是正确的。

3.3 Analysis

3.3.1 Multi-stage Feature Coupling

为了进一步分析召回特征和排序特征的重要性，作者对 HLATR 的两部分特征输入进行了消融实验。如下表所示，w/o retrieval 表示去掉了召回模型提供的排序特征，w/o ranker 表示将排序模型提供的特征替换为了召回模型输出的 query 表示和 document 表示的 Hadamard 乘积。从结果上可以看到，去掉任何特征都会影响 HLATR 的性能，其中去掉排序特征的影响更大。

3.3.2 Architecture analysis of HLATR

作者也对 HLATR 的模型结构和训练目标进行了对比实验，如下表所示，HLATR-linear 表示将 transformer 结构替换成了一个简单的 ReLU 激活的两层 MLP，HLATR-bce 表示将对比损失替换为了如下的二元交叉熵损失：

可以发现，将模型结构替换为了简单的 MLP，模型性能仅仅掉了 0.2pp，说明 HLATR 的收益并不主要依赖于引入的额外参数以及模型结构的改进。将训练目标替换为二元交叉熵损失后，模型性能有近 1pp 的跌幅，这说明比起分类损失，对比损失更适合用于排序任务，因为排序任务本质上其实是一个类别极度不平衡的分类任务。

3.3.3 Computational Cost of HLATR

使用 HLATR 进行重排序的一个可能的担忧是它可能会带来额外的时间开销，因此作者也测试了加入 HLATR 的检索系统不同模块的计算开销。如下图所示，HLATR 的时间开销实际上远低于召回和排序的时间开销，因为 HLATR 的参数量少且高度并行化，所以 HLATR 增加的推理时间是可以忽略不计的。

3.3.4 Hyper-parameters of Transformer

最后，作者对 HLATR 所使用的 Transformer 的参数量进行了消融实验。如下表所示，作者对比了不同层数和不同维度的模型表现，可以发现增加层数并没有取得更优的表现，而增加维度反而会有负面作用，这说明 HLATR 并不需要很大的参数量，较小的层数和较小的维度就可以取得很好的表现，这也许是因为 HLATR 输入的特征已经高度语义化的缘故。

总结

总体来说，HLATR 最大的收益点主要就在于文档间充分的 listwise 建模，这更接近于排序任务的真实目标。不可否认的是，HLATR 的有效性和实用性都相当不错，但不知道作者是否受到了 SIGIR 2020 的 SetRank 的启发。因为 HLATR 的设计和 SetRank 非常相似，甚至可以说是 SetRank 在预训练时代下的简化版，HLATR 中以位置编码的形式引入召回特征的设计，以及文档特征矩阵的计算方式与 SetRank 几乎是完全一样的，只是编码器和损失函数不同而已，然而 HLATR 并没有引用 SetRank 原文。

更多阅读