超強指南！推薦算法架構——重排

導語 | 重排技術細節非常多，一定要清楚技術架構大圖，從而將細節串聯起來。實際上主要是爲了解決三大方面的問題：用戶體驗、算法效率、流量調控。

在上篇_《_圖文解讀：推薦算法架構——精排！_》_中我們結合算法架構精排進行解讀分析，本篇將深入重排這部分進行闡述。

一、總體架構

精排打分完成後，就到了重排階段，之後可能還會有混排。召回、精排、重排三個模塊中，重排離最終的用戶展現最近，所以也十分關鍵。重排的技術點也十分多，總結下來，個人認爲重排主要是爲了解決三大方面的問題：用戶體驗、算法效率、流量調控。下圖是重排總體架構：

二、用戶體驗

重排模塊是推薦系統最後一個模塊（可能還會有混排），離用戶最近。作爲最後一層兜底，用戶體驗十分重要。主要包括打散、多樣性等內容。曝光過濾有時候也會放在重排中，但本質上完全可以在召回鏈路，對已充分曝光的短視頻，或者剛剛已經購買過的商品，進行過濾，從而防止用戶牴觸。

（一）打散

對同類目、同作者、相似封面圖的 item 進行打散，可以有效防止用戶疲勞和系統過度個性化，同時有利於探索和捕捉用戶的潛在興趣，對用戶體驗和長期目標都很關鍵。

打散問題一般可以定義爲，輸入一個 item 有序序列，每個 item 有幾個需要隔離開的屬性，輸出一個相似屬性分離開的 item 序列。打散可以基於規則，也可以基於 embedding。基於規則比較簡單可控，但由於 item 屬性枚舉值較多，可能需要頻繁更新，擴展性不強。基於 embedding 的打散，泛化能力強，但容易出現 bad case。目前主流方法仍然是基於規則的打散。

基於規則的打散主要有如下幾種：

• 分桶打散法：將不同屬性的 item 放入不同的桶中，依次從各桶中取出 item 即可。這種方法實現簡單，打散效果好。但末尾容易扎堆。對原始序列改變較大，可能帶來指標的下降。多屬性疊加困難，擴展性也較差。

• 權重分配法：對每個 item 定義一個分數，計算公式如下：

其中 W 爲每個屬性的權重，代表屬性打散需求的優先級。Count 爲同屬性 item 已經出現的次數。f(x) 即爲打散加權分數，按照它從低到高對 item 進行排序，即可完成打散。這種方法實現也比較容易，而且可以充分考慮多種屬性的疊加，擴展性也很強。但仍然容易出現末尾扎堆。

2. 滑動窗口法：在一個長度可控的滑動窗口（session）內，同屬性 item 超過一定次數後，就交換出 session。這種方法只用考慮局部，不需要全局計算，因此計算量較低。同時對原序的破壞也比較低，最大限度保留相關性。但也會出現末尾扎堆的現象。

（二）多樣性

多樣性是一個很大的話題，後面我們會作爲專項來梳理。多樣性會對用戶體驗、長期目標有比較關鍵的影響。召回、精排、重排全鏈路都要考慮多樣性問題，但確實一般重排中考慮比較多一些，我們這兒也一起分析下。

• 評價指標

多樣性評價可以使用兩種方法：

• 數據指標分析：可以從 user 和 item 兩個角度評估，比如平均每個用戶的曝光一二級類目數，曝光 item 同屬一個類目的概率等。可以從類目、作者、標籤等多個維度進行數據分析和評價。

• 人工評估：抽樣進行人工體驗，評估多樣性。

兩種方法各有所長，一般還是需要結合一起使用。特別是人工體驗評估，千萬不可忽略。算法工程師也要經常去體驗和對比自己的實際業務場景。

• 發展進程

個人認爲多樣性算法經歷了三個階段：

• 規則約束：基本都是基於規則，沒有結合相關性來考慮多樣性問題。主要有三種：

• 硬規則約束：比如類目打散、作者打散、同圖打散等。一般業務初期都會採用這種方法，開發簡單快速，沒有實現配置化，所以擴展性不高。新的打散需求一般要重新開發和部署。

• 規則引擎：規則抽象化和配置化，上線速度快，新增需求只需要新增一個規則即可。

• 個性化約束：不同類目、不同時段、不同活躍度用戶配置不同。比如手機和抽紙，他們的打散窗口可能會不同。不同活躍度人羣，其耐受度也會不一樣。

• 啓發式方法：多樣性和相關性相結合的方法，充分保留相關性。主要有：

• MMR：最大邊緣相關模型。1998 年發表，比較老。參見 The Use of MMR, Diversity-Based Reranking for Reordering Documents and Producing Summaries

• DPP：點行列式矩陣。NIPS2018。參見 Fast Greedy MAP Inference for Determinantal Point Process to Improve Recommendation Diversity

• Deep-DPP：結合深度神經網絡的 DPP，CIKM2018，youtube。參見 Practical Diversified Recommendations on YouTube with Determinantal Point Processes

• 深度模型：主要是加入了上下文感知，從而可以結合規則引擎實現多樣性。這部分在與下一章節的上下文感知模塊比較類似，放在那邊統一梳理。

三、算法效率

重排對於提升算法準確率和效率，從而提升業務指標也十分關鍵。重排提升算法效率，主要分爲三個方向：

• 多任務融合。精排輸出的多個任務的分數，在重排階段進行融合。可以基於人工調權、grid search、LTR 或者強化學習。

• 上下文感知。精排由於計算性能因素，目前是基於 point-wise 的單點打分，沒有考慮上下文因素。但其實序列中 item 的前後其他 item，都對最終是否點擊和轉化有很大影響。context-aware 的實現方式有 pairwise、listwise、generative 等多種方式。

• 實時性提升。重排比精排模型輕量化很多，也可以只對精排的 topK 重排，因此較容易實現在線學習（目前有一些團隊甚至實現了精排在線學習）。實時性提升對於快速捕捉用戶實時興趣十分重要，能大大提升模型準確率和用戶體驗。通過 ODL 在線學習，實現重排模型實時更新，可以提升整體鏈路實時性。另外在端上部署模型，實現端上重排，也可以實現推薦的實時響應和特徵的實時捕獲。

（一）多任務融合

當前大多數業務場景需要優化多個任務，算法模型也已經實現了多任務學習，比如 MMOE 和 PLE 等。那模型輸出的多個任務分數怎麼融合呢？我們可以在精排階段融合，也可以在重排階段融合。由於重排模型相對精排要輕量級一些，容易實現在線學習，所以有不少場景放在重排階段進行多任務融合。

目前多任務融合主要有以下幾種方式：

• 人工調權：通過專家先驗知識，設置多任務融合的超參數。這種方式比較簡單，業務發展初期通常採用。缺點也比較明顯：

• 超參組合的選擇依賴專家經驗，準確率有限，有一定的效率浪費。

• 固定的超參不能快速自動適應業務和模型迭代，對整體鏈路算法效率有比較大的影響，甚至負向。

• Grid search：將各參數可能的取值進行排列組合，窮舉搜索所有的可能，再逐步輸入系統中進行評估，選擇效果最好的參數組合。相比人工調權，grid search 顯然更有可能找到最優的參數組合。但它缺點同樣明顯：

• 超參排列組合多，搜索空間大，十分耗時。超過 4 個超參後，計算量就要爆炸了。

• 難以進行在線 AB，不能準確拿到用戶反饋。這也是超參搜索空間大導致的。

• 同樣不能自動適應業務和模型迭代，會成爲整個鏈路的優化瓶頸。

• 模型法：將精排各任務的打分結果，採用線性模型或者比較輕量級的深度模型，構建監督學習。一般也可以將其他比較重要的特徵，比如商品價格、銷量、近期 CTR、近期 CVR，一起融合在重排模型中。由於精排的打分結果已經相當置信了，重排模型可以儘量輕量級一些，所以比較容易實現在線學習，實時更新特徵和模型，提高重排模型的實時能力。模型法優點很多，在目前各業務場景中廣泛使用。其缺點主要有：

• 仍然是基於 point-wise 的，沒有上下文感知能力。

• 業務場景最終指標必須單一。重排模型做多任務融合，其監督目標必須是一個單一的任務，否則誰來融合重排呢？比如電商場景下訂單量指標，一般會在精排構建 CTR（曝光到點擊）和 CVR（點擊到轉化）兩個任務，重排則統一成 CTCVR（曝光到轉化）即可。但如果還想把用戶互動指標（比如收藏、分享、評論）也加入進來，則較難建模了。

• 強化學習：根據用戶在不同狀態下的行爲，利用強化學習建模狀態轉移過程，從而提升業務核心目標。state 爲用戶特徵，比如用戶靜態特徵、統計特徵等。Action 爲當前各任務的融合參數。reward 可以根據業務場景定義，比如內容推薦場景中，一般爲用戶打開 APP 到退出的總時長。可以採用 DQN、DDPG、A3C 等方法。

（二）上下文感知

由於精排模型一般比較複雜，基於系統時延考慮，一般採用 point-wise 方式，並行對每個 item 進行打分。這就使得打分時缺少了上下文感知能力。用戶最終是否會點擊購買一個商品，除了和它自身有關外，和它周圍其他的 item 也息息相關。重排一般比較輕量，可以加入上下文感知能力，提升推薦整體算法效率。

context-wise 建模的方法主要有：pairwise 和 listwise 兩大類。

• Pairwise

通過對比兩個商品之間相對關係來構建，有一定的上下文感知能力，但仍然忽略了全局信息，而且造成了極大的計算和性能開銷。這種方法有 RankSVM、GBRank、RankNet、LambdaRank 等經典的 pairwise LTR 方法。

• Listwise

建模 item 序列整體信息，通過 listwise 損失函數來對比商品之間序列關係。可以通過 DNN、RNN、self-attention 等多種方式建模和提取 item 序列信息，再通過 beam-search 等貪婪搜索方法得到最終的序列。主要有五種建模方法：

• 樹模型：LambdaMart 等。

• RNN：DLCM、seq2slate 等，分別利用 RNN+attention，和 pointer-network 來構建 seq2seq 模型。

• 兩段式：PRS 等，構建 PMatch 和 PRank 兩個鏈路，通過兩段式結構得到最終輸出。

• self-attention：PRM、SetRank 等，和 RNN 模型比較像，將 RNN 替換成了 self-attention，客服長程建模梯度彌散問題，以及串行計算耗時過大等。

• 強化學習：LIRD、GRN 等。

這兒簡單介紹下 PRM，它構建了 input layer、encoding layer、output layer 三層，通過 self-attention 使得序列內 item 充分交互，提取序列信息，通過貪婪搜索得到最終序列：

• input layer 輸入層：得到排序階段輸出的有序序列，輸入包括三部分：

1. 每個 item 對應一個特徵向量 E。

2. user 和 item 之間計算一個個性化向量 PV，通過預訓練模型得到。

3. item 的位置編碼 PE。

• encoding layer 編碼層：通過 self-attention 建模，每個位置輸出一個編碼後的向量

• output layer 輸出層：編碼層輸出的每個位置的向量，通過一層線性層和 softmax 後，得到每個 item 的概率。通過 beam-search 等貪婪搜索方法，得到最終的序列。

整個過程和機器翻譯等 NLP 場景任務很像，同樣可以結合 pointer-network 來優化。paper 地址：（https://arxiv.org/pdf/1904.06813.pdf）

（三）實時性提升

推薦系統的實時性也是一個比較大的話題。實時性對於提升用戶體驗，優化算法效率，都十分重要。實時性主要包括 3 方面：

• 系統響應實時性：考慮到推薦系統 QPS 壓力，用戶一次請求會下發多個 item，瀏覽完後重新請求才會觸發系統新的響應。系統響應實時性，對於用戶實時行爲捕捉十分關鍵。基於端上重排的系統，可以實現響應的實時性。

• 特徵實時性：用戶行爲特徵實時性、item 統計特徵實時性等。相對來說特徵實時性是最容易做到的，也是對推薦效果影響最大的。特徵實時性要考慮系統鏈路數據回收延遲，和用戶本身行爲延遲反饋問題。

• 模型實時性：在線學習，實時更新模型等。重排模型比較輕量，容易做到實時更新。精排相對來說困難一些，但也有一些團隊實現了精排的在線深度學習 ODL。

重排階段提升實時性主要方法有，在線學習 ODL 和端上重排，下面詳細講解。

• 在線學習 ODL

深度模型由於需要的訓練數據和時間都比較大，資源消耗也比較多，故一般以離線訓練爲主。小時級或者天級更新。對於用戶的實時行爲 pattern，或者冷啓 item 都不是特別友好。特別在大促期間和秒殺場景，用戶興趣和需求轉瞬即逝，商品也隨時可能會被售空。我們這兒就不談數據鏈路和推薦工程方面的工作了，算法方面主要的問題有：

• 延遲反饋：用戶點擊完商品後，可能大數據系統中需要幾分鐘甚至數小時後才收集到他的購買行爲。延遲反饋顯然對於 label 置信度是個很大的挑戰。主要原因有數據鏈路延遲和用戶行爲延遲。flink 收集數據有一定的鏈路 delay，用戶也可能猶豫幾小時後才真正購買。延遲反饋需要平衡樣本置信度和模型新鮮度。優化方法有：

  負例校正法：先標記爲負樣本，等真正轉化後再重新插入正樣本。這種方法可以保證模型新鮮度，但假負例會對模型有一定的副作用。（https://dl.acm.org/doi/abs/10.1145/3298689.3347002）

  等待法：一定時間內等待真實的成交轉化，如果沒等到，不管後續有沒有，都不校正了。這種方法 label 置信度有一定提升，但模型新鮮度會有折損。

  （https://arxiv.org/pdf/2002.02068.pdf）

  糾偏法，例如 ES-DFM，對觀測轉化分佈和真實轉化分佈之間的關係建模，降低假負例的權重和增加真正例的權重，來糾正樣本不置信問題。

  （https://arxiv.org/pdf/2012.03245.pdf）

• 數據穩定性：數據隨時間波動大，比如電商 CVR。很多用戶習慣白天瀏覽點擊，晚上真正下單。所以 CVR 在晚上明顯比白天高。這時候需要做一定的修正。也可以在線學習和離線增量學習相結合。每天固定一個時間點，對模型做一次天級離線增量更新。從而修正在線學習中積累的誤差。

• 邊緣計算與端上重排

邊緣計算和端上重排這兩年一直都很火，它可以有效降低雲端負載，保證數據安全隱私性。同時也可以提升算法效率，算法側的優點主要有：

• 推薦響應實時性：不用請求下一頁，實現即時更新。

• 行爲特徵實時性：端上即時計算，不用回傳雲端。

• 行爲特徵豐富度：負反饋、滾動速度、曝光時長等多種用戶行爲都可以在模型中使用，基於雲端的方式受限於數據傳輸和存儲，一般只會選擇點擊等關鍵的用戶行爲。

端上重排需要將一個輕量級的模型，部署在端側，實現端上推理。

四、流量調控

流量調控在推薦系統中也十分重要，重排在最後一環，責無旁貸。流量調控要兼顧實時性和準確性，二者之間需要達到平衡。流量調控的作用和方式主要有：

• 保量類：通過流量扶持，刺激生態建設。比如對冷啓 item，新熱 item，大 V 的新發布 item，均可以給予一定的保量流量，讓他們能夠順利透出和正循環。保量的實時性也十分重要，作者能第一時間看到自己 item 得到的點贊、評論等，有利於刺激他們持續創作。保量常見的方法有：

  規則引擎：制訂一定的策略規則，實現保量。這種方法簡單易行，item 也肯定能獲得一定流量。但準確度較低，也較難實現個性化。流量容易不夠或者超發。

  探索和利用：通過 e-greedy、Thompson sampling、UCB 等 EE 類的方法，可以有效探索冷啓 item，同時利用已有 item，保障效率折損最低。

• 調權類：一般是業務運營需求，需要快速實時干預。比如三八婦女節需要臨時對美妝類 item 做加權，增加其流量。過了這一天可能效果就會大打折扣了。常見方法有：

  規則引擎：直接在重排結果上，對於命中屬性規則的 item，加入一定的分數，使得最後可以透出，增加其流量。這種方法簡單易行，實時性好。但調權準確率低，也較難個性化，可能造成較大的流量浪費和效率折損。適合某些時效要求高的場景。比如大促期間加權等。

  樣本加權：對於命中調權規則的樣本，增加其在 loss 中的權重，迫使模型偏向於對它們精準預估。這種方法可以實現個性化，對效率折損較低。但由於需要訓練模型並重新上線，故實時性不高。適合某些長期性的調權場景。比如對大店、大 V 的加權等。

** 作者簡介**

謝楊易

騰訊應用算法研究員

騰訊應用算法研究員，畢業於中國科學院，目前在騰訊負責視頻推薦算法工作，有豐富的自然語言處理和搜索推薦算法經驗。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/wXb5uQJBCzSEq6IITP7VCQ