PaperWeekly - 霸榜MS MARCO！基於Transformer的混合列表感知排序模型－鑽石舞台

©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.2Results

作者的實驗結果如下表所示，我們可以發現在不同的實驗設置下，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.2Architecture analysis of HLATR

作者也對 HLATR 的模型結構和訓練目標進行了對比實驗，如下表所示，HLATR-linear 表示將 transformer 結構替換成了一個簡單的 ReLU 激活的兩層 MLP，HLATR-bce 表示將對比損失替換為了如下的二元交叉熵損失：

可以發現，將模型結構替換為了簡單的 MLP，模型性能僅僅掉了 0.2pp，說明 HLATR 的收益並不主要依賴於引入的額外參數以及模型結構的改進。將訓練目標替換為二元交叉熵損失後，模型性能有近 1pp 的跌幅，這說明比起分類損失，對比損失更適合用於排序任務，因為排序任務本質上其實是一個類別極度不平衡的分類任務。

3.3.3Computational Cost of HLATR

使用 HLATR 進行重排序的一個可能的擔憂是它可能會帶來額外的時間開銷，因此作者也測試了加入 HLATR 的檢索系統不同模塊的計算開銷。如下圖所示，HLATR 的時間開銷實際上遠低於召回和排序的時間開銷，因為 HLATR 的參數量少且高度並行化，所以 HLATR 增加的推理時間是可以忽略不計的。

3.3.4Hyper-parameters of Transformer

最後，作者對 HLATR 所使用的 Transformer 的參數量進行了消融實驗。如下表所示，作者對比了不同層數和不同維度的模型表現，可以發現增加層數並沒有取得更優的表現，而增加維度反而會有負面作用，這說明 HLATR 並不需要很大的參數量，較小的層數和較小的維度就可以取得很好的表現，這也許是因為 HLATR 輸入的特徵已經高度語義化的緣故。

總結

總體來說，HLATR 最大的收益點主要就在於文檔間充分的 listwise 建模，這更接近於排序任務的真實目標。不可否認的是，HLATR 的有效性和實用性都相當不錯，但不知道作者是否受到了 SIGIR 2020 的 SetRank 的啟發。因為 HLATR 的設計和 SetRank 非常相似，甚至可以說是 SetRank 在預訓練時代下的簡化版，HLATR 中以位置編碼的形式引入召回特徵的設計，以及文檔特徵矩陣的計算方式與 SetRank 幾乎是完全一樣的，只是編碼器和損失函數不同而已，然而 HLATR 並沒有引用 SetRank 原文。

更多閱讀