今天給大家帶來CIKM2022應用研究方向最佳論文-來自于快手團隊的《Real-time Short Video Recommendation on Mobile Devices》，主要研究在移動端如何做到更好的短視頻實時推薦，是一篇不錯的落地經驗分享的論文，一起來看一下。

1、背景

近幾年來短視頻平臺逐漸發展，像快手、抖音等平臺吸引了大批用戶的使用。下圖為典型的短視頻應用的頁面截圖。由于短視頻時長較短，內容主題豐富多樣，用戶通常會在很短時間內觀看許多不同主題的短視頻，同時用戶的實時興趣可能會不斷發生變化。因此，對于短視頻應用來說，其推薦系統如何針對用戶的實時反饋做出更敏感準確的推薦，是十分重要的。

傳統的推薦系統通常部署在服務端，并包含多個階段：召回，精排和重排階段。客戶端向推薦系統發送用戶分頁請求，然后推薦系統一次性返回一整個頁面的內容，隨后客戶端將這些結果一個接一個展現給用戶。對于這樣的架構，主要存在兩方面的問題：

1）敏感性：服務端只有在接收客戶端發起的分頁請求時才有機會調整推薦內容，無法基于用戶的實時反饋作出實時的內容決策；
2）準確性：用戶的實時反饋信息無法被及時利用。只有當這些用戶反饋信息可用后，才會回傳給服務端，這會花費數十秒甚至幾分鐘的時間，這對特征的實效性影響很大。同時，客戶端特有的特征（用戶的網絡情況等），在服務端是無法獲取到的，但對于實時用戶興趣預測來講，這些特征也十分重要。

隨著算力和存儲能力發展，使得在一些移動端的的設備如手機、平板部署甚至訓練簡單的DNN模型變為可能。通過在移動端部署輕量級的模型，提供實時的推薦排序能力，來解決上述兩方面的問題，為用戶提供更為實時準確的推薦結果。

本文重點針對短視頻場景下的端上實時推薦，重點分享兩方面的經驗：一方面如何有效利用端上的用戶實時反饋特征進行模型預估；另一方面是如何通過自適應確定搜索步數的 beam search 來對短視頻進行重排，生成整體效果更好的排序。接下來，對快手整個端上推薦系統的架構以及上述兩方面的經驗進行重點介紹。

2、系統架構概覽

整個快手短視頻推薦系統架構如下圖所示，主要分為三個部分：服務端推薦系統；客戶端推薦系統和模型訓練系統。

2.1 服務端推薦系統

傳統的推薦系統通常部署在服務端，包含召回、精排和重排多個階段。當用戶發起一次分頁請求，服務器經過多個階段將推薦結果返回給客戶端。在快手的推薦系統中，服務端除返回重排后的m個候選結果外，還會額外n個視頻，來擴展端上推薦系統的候選空間。

2.2 模型訓練系統

第二個模塊是模型訓練系統，這部分首先從收集的數據中生產訓練樣本，然后通過分布式訓練系統對排序模型進行增量更新。模型對應的checkpoint會定期導出，并以TFLite的形式進行部署。

2.3 客戶端推薦系統

客戶端推薦系統又可以進一步分為兩部分：
1）特征收集：這部分收集來自服務端和客戶端的特征，并將其發送給推薦模型。
2）上下文感知的重排模型：當用戶滑動觀看下一個視頻或者點擊喜歡/分享視頻時，會觸發端上模型對候選視頻進行重排序，并按照重排序的結果填充下一個給用戶展示的內容。

接下來，對端上推薦系統的內容進行重點介紹。

3、端上排序模型

3.1 設計理念

由于模型部署在移動端，出于存儲能力、計算能力和電量消耗等方面的限制，模型必須極度輕量且高效。當設計模型結構時，有兩種主要的選擇：
1）一種是端云協作模式，模型中主要的embedding 參數保存在服務端，客戶端只保留DNN部分的參數。當在線推理時，服務端查找對應的embedding并將其傳輸給客戶端用于后續的計算。
2）另一種是為客戶端設計輕量的小模型。這樣的設計不僅可以減少計算延遲，同時無需考慮客戶端和服務端之間模型的一致性問題

這里快手選擇的是第二種方式，即為移動設備設計一個小型但獨立的模型。該模型是服務端模型的補充，主要是利用客戶端用戶的實時反饋信息來提高預測精度。服務端的排序模型已經將大部分信息壓縮為最終的預測分數，因此可以將其作為輸入以避免冗余計算，并使模型足夠小。離線實驗也驗證了將復雜的ID類特征作為輸入，并沒有比直接使用預測值作為輸入帶來明顯的改進。

3.2 輸入特征

這一部分主要介紹下端上模型的輸入特征。主要包含三種類型的特征：
1）服務端模型的預測值：服務端模型無論是在模型結構還是輸入特征上都十分復雜，其給出的預測值是對輸入信息的高度壓縮，能夠很好的表示用戶對于視頻的喜好程度，同時可以利用客戶端的實時特性作為補充，更好地預測用戶的實時興趣；
2）視頻屬性特征：視頻屬性特征如視頻ID、類別、持續時長、標簽、背景音樂等等，由于模型容量的限制，只能選擇其中一小部分特征。這里，只選擇了視頻的類型以及持續時長特征；
3）客戶端特征：客戶端同樣會收集許多重要的特征，如用戶最近的觀看列表，列表中的每個視頻又包括用戶的反饋信息，視頻的觀看時長，視頻的觀看時間戳等特征。除此之外，還會收集客戶端相較服務端獨有的特征，如候選視頻將被展示的位置、用戶的網絡情況等等。不同的網絡情況下為了保證用戶體驗，能夠去展示的視頻也是有所不同的。

模型所用到的輸入特征匯總如下：

3.3 特征工程

為了進一步提升推薦效果，模型中進一步增加如下的交叉特征作為輸入：

1）pXTR diff：候選視頻精排 pXTR 和觀看歷史視頻 pXTR 的差值，這里相較原文內容中的解釋，文章https://m.thepaper.cn/baijiahao_20394383給出的解釋更容易理解和接受：

不同用戶天然存在的 bias 會導致用戶間的 pXTR 并不直接可比，比如有些用戶 pXTR 會整體偏高或偏低，由于端上重排模型中沒有用到 uid 等特征，直接用 pXTR 的原始分值作為特征會干擾模型學習。通過 pXTR 之差可以消除這種 bias，并且以最近看過的視頻 pXTR 為錨點，可以感知用戶的實時興趣偏好。

2）視頻曝光時間之差：用戶觀看歷史中每個視頻曝光時間與上一次曝光時間的差值，通常來說離當前時間越近的視頻影響越大。
3）視頻曝光位置之差：用戶觀看歷史中每個視頻曝光位置與當前位置的位置間隔，如果用戶觀看視頻的速度很快，那么曝光位置之差比曝光時間之差會更加穩定。

3.4 模型結構

介紹完了輸入特征和特征工程，接下來看看模型的具體結構，如下圖所示：

輸入可以分為四部分：
1）實時觀看歷史：端上保存的用戶實時觀看歷史
2）有序的候選視頻列表：這里主要是為重排所考慮，建模已決策視頻（即上文）對目標視頻的影響。
3）目標視頻
4）其他特征：主要包括一些上下文特征如當前的網絡狀況等。

具體的網絡結構圖上比較清晰，這里不再贅述。

3.5 模型訓練和部署

整個模型需要考慮的建模目標有很多，這里主要選擇了三個最為重要的目標：是否下刷、是否為有效觀看（觀看時長大于設定的閾值，如5s）、用戶是否喜歡當前視頻。三者均為二分類損失，通過MMoE結構得到三部分的預估值，并計算損失和模型訓練：

4、上下文感知的重排序

上一節中介紹了模型部分的主要內容，當模型對候選視頻給出相應的預測得分之后，如何決定視頻給用戶展現的順序呢？最常用的方法是point-wise的方法，即使用統一的排序公式對所有的視頻進行單點排序，決定展現順序。但單點排序的方法無法考慮候選視頻之間的相互影響，非全局最優。

另一種方法是list-wise的方法，直接找到一個能夠使得list-reward最大的排列。但直接尋找最優的排列所需要的計算量是巨大的，因此Beam-Search是一種常用的近似優化策略（但這種策略只能考慮上文對下文的影響，無法考慮下文對上文的影響，仍非全局最優策略）。

為了進一步減少尋找最優排列的耗時，論文對Beam-Search方法做出了一定的改進，提出了自適應步長的Beam-Search方法。在Beam-Search的每一步，計算reward最差的序列和最優的序列的獎勵比值，如果該比值大于一定的閾值，則說明再往后的每一步，序列間的reward也不會相差太多，無需進一步的搜索。

那么List的Reward如何定義呢，公式如下：

整體的獎勵為單個視頻獎勵的求和。對每個視頻來說，包含兩部分：第一部分是視頻曝光的概率（前面所有視頻下刷的概率乘積），第二部分是對應每個視頻有效觀看以及被用戶喜歡概率的加權求和。這兩部分的乘積作為單個視頻的獎勵。

5、實驗結果

最后來看一下實驗結果部分：

5.1 離線實驗

5.2 線上A/B測試

好了，論文就介紹到這里，從特征設計、特征工程、模型結構設計、重排方法設計，論文都有不錯的借鑒意義，值得閱讀～