推薦系統介紹
首先和大家介紹一些推薦系統的基本知識。
1. 推薦系統是什麼
現代移動互聯網娛樂充斥着各種各樣的信息，如新聞，短視頻，直播等等，經常使用戶迷失在海量的內容中，而無法找到真正感興趣的內容。平臺搭建推薦系統則是幫助用戶發現內容，克服信息過載的重要工具。它通過分析用戶行爲，對用戶興趣建模。通俗來講就是通過用戶過去的喜好來分析現在的喜好，從而預測用戶的興趣並給用戶做推薦。
早期的花椒推薦系統是基於熱度推薦的，即根據觀看人數、送禮人數、互動人數等因素來進行加權得到相應的分數代表熱度，然後根據熱度進行推薦。這樣做的好處是熱度高的直播質量有保證。但是壞處也很明顯，流量全部集中在頭部主播，小主播難以得到有效曝光，這樣對於平臺的利益也是一種損害。對於用戶來說，也難以做到“千人千面”的個性化推薦效果。
因此現代的推薦系統應運而生，一般分爲以下幾個階段：
首先從百萬級別的內容中，根據歷史行爲，運用協同過濾等算法召回千百級別的內容， 再經過feature-based精排模型排序，選取百十級別內容推薦給客戶。召回階段會用些成本低、易實現、速度快的模型 ( 如協同過濾 ) 進行初步篩選。排序階段則用更全面的數據、更精細的特徵、更復雜的模型進行精挑細選。
2. 召回算法介紹
① 基於領域的協同過濾
以電影推薦爲例，我們知道用戶對於歷史觀看過的電影的評分，將原始數據格式轉化爲評分矩陣，如下所示：
用戶只看過少部分電影，我們想要知道對於未看過的電影，用戶可能對其的喜愛程度 ( 打分 ) 是多高。建模的過程就是填充空白項的過程，這樣就得到了所有用戶對所有電影的評分 ( 喜好程度 )，然後就可據此進行個性化推薦。
這種協同過濾方法基於場景一般採用user-based 或者item-based model。花椒直播用的是item ( 主播 ) based model，即基於主播的協同過濾算法。主要基於以下原因：
- 主播數量遠小於用戶數量，相似度矩陣維度小，計算少、易存儲 (𝑂(𝑛2)）
- 根據用戶的歷史行爲推薦，可以讓用戶比較信服 ( 可解釋性強 )
- 新用戶只要看過一個主播，就可以很快得到其他相似主播的推薦。計算方法如下所示：
但是這種方法存在一些缺點：
- 這是一種基於統計的方法，不是優化學習的方法，沒有學習過程和設立指標進行優化得到最優模型的過程
- 沒有用到全局數據，只用了局部數據計算相似度、進行推薦
- 當用戶或物品維度很大時，會佔用很大的內存
基於這些原因，後面出現了基於隱向量的協同過濾方法進行推薦。
② 基於隱向量的協同過濾
隱向量的生成方式一般分爲兩類：
- 基於矩陣分解生成隱向量。
- 基於深度學習生成隱向量。
和基於鄰域的方法一樣，基於矩陣分解方法建模的目的也是補全缺失值。在介紹矩陣分解之前，我們先來看看推薦系統的兩種反饋方式：
顯式反饋一般採用評分矩陣來提取隱向量， 方法如下所示：
這種方法就是標準的MF，通過評分矩陣分解出代表用戶的隱向量矩陣和代表物品的隱向量矩陣。但是缺點也很明顯，在實際的應用場景中， 不可能用戶每使用一次物品就要求用戶打分。所以在實際場景中，隱式反饋使用的更多，在直播場景裏，用戶對於視頻的喜好表現爲觀看時長和點擊次數等等。
以觀看時長作爲用戶對於商品的偏好爲例，在觀看時長大於某個程度作爲喜好的標準，設定評分爲1，否則爲0。同時設置偏好的可信度作爲損失函數的權重，理解爲偏好越大，權重越大。則隱向量計算方法如下所示:
線上的部署很簡單，X中每行爲一個用戶的隱向量，Y中每列爲一個物品的隱向量。離線訓練好將X，Y兩個矩陣存起來，線上用時直接取對應向量做內積即可得到任一用戶對任一物品的得分 ( 即喜好程度 )。
矩陣分解的思想很簡單，優點也很明顯：
- 模型簡單易實現。
- 線上速度快：可以離線訓練，線上只需要做點積。
- 存儲少 ( 高維評分矩陣映射爲兩個低維隱向量矩陣 )。同樣的，傳統的矩陣分解也存在着可解釋性較差，未用到其他特徵，綜合性較差的缺點。
總結一下基於領域的協同過濾和基於矩陣分解的協同過濾的異同點：
有些示例表明，學到用戶/物品的隱向量後，直接用內積描述用戶-物品交互關係 ( matching function ) 有一定的侷限性，即內積函數 ( inner product function ) 限制了 MF的表現力。
隨着深度學習的興起，有學者提出了新的模型：即借鑑深度學習中的方 法，使用深度神經網絡 ( DNN ) 從數據中自動學習用戶/物品隱向量的交互函數，在增強表現力的同時也可以引入一定的泛化能力。
以NCF爲例，通過對user_id和item_id的one-hot編碼，經過嵌入形成隱向量，用DNN取代內積，輸出目標預測值，通過損失函數求梯度進行反向傳播訓練模型。如下圖所示：
NeuMF則提出了GMF層來提取用戶、物品潛在特徵之間的相互作用 ( MF的特性 )，同時採用了MLP進行非線性的特徵融合，具體如下所示：
但是僅僅運用到id類特徵並沒有充分使用用戶和物品的屬性特徵，因此隨時技術進步，越來越多平臺開始把屬性特這個加入到深度學習中來提取隱向量。以下是youtube的召回模型結構：
隨着業界對於深度學習的不斷探索，目前召回模型也越來越複雜和精妙， 如：
雙塔模型 ( Sampling-Bias-Corrected Neural Modeling for Large Corpus Item Recommendations )
知識圖譜模型 ( RippleNet: Propagating User Preferences on the Knowledge Graph for Recommender Systems )
圖神經網絡等 ( GraphSAGE: Inductive Representation Learning on Large Graphs )。
3. 精排 ( Ranking ) 算法介紹
① 特徵工程
特徵的選擇和建造對於模型的效果起着至關重要的作用，在直播領域，考慮的特徵一般包括如下幾個方面：
在訓練數據的生成上，我們根據當天的用戶與主播的交互程度形成征服樣本，根據之前的歷史數據組成用戶畫像和行爲特徵。在生成數據的時候，要注意不能有數據穿透，基本流程如下圖所示：
選擇14日組成整體訓練集，這樣既可以保證數據量的要求，又可以保證用戶和主播覆蓋度的要求。
② 排序模型
早期的排序模型採用的是傳統的機器學習模型，如LR/FM/GBDT+LR。
LR一般代指邏輯迴歸模型，是廣義線性模型，一般用於解決二分類問題，模型如下：
優點就是模型簡單，訓練速度快，消耗資源少。缺點也很明顯，缺少非線性的特徵交叉，泛化性較低。
爲了將特徵交叉考慮進去，FM模型被廣泛使用，模型如下：
FM模型在LR模型的基礎上增加了自動二階特徵交叉的部分。不同於CF類模型，只有用戶、物品ID兩類特徵 ( 即MF )，FM可以添加任意多的特徵。隱向量的引入也使得模型可以泛化到未曾出現過的特徵組合中，兼顧了模型的記憶性和泛化性。但是FM只能學習二階交叉項，遇到高階交叉項，則會出現緯度爆炸的情況。
因此爲了尋找不同特徵之間的組合，人們選擇了用GBDT進行特徵組合，自上而下每條路徑代表一種高階特徵交叉，然後葉子節點編號作爲LR的輸入，具體結構如下所示：
但是這種方法的缺點是可能導致過擬合高維稀疏數據，GBDT不能將數據batch輸入，無法並行，因此速度慢、泛化性差。
隨着深度學習的深入，人們將高階特徵交叉的工作中心轉移到了DNN網絡。首先最直觀的改進就是通過DNN處理特徵交叉，LR處理線性部分。
大名鼎鼎的W&D就是由此而來，其結構如下：
這種深淺雙塔結構的提出極大的促進了後續模型的發展。如後續的DeepFM就是將FM與DNN結合起來，更加提高了交叉特徵的提取能力。
又如較新的DIN模型，引入了attention的機制，通過attention network來組合embeddings，而不是類似之前的concatenate的方式。
4. 多目標優化
推薦系統的多目標優化，是目前業界的主流之一，也是很多公司的研發現狀。以我 們花椒直播爲例，可以優化的目標有點擊、觀看、送禮、評論、關注、轉發等等。
多任務模型旨在平衡不同目標的相互影響，儘量能夠做到所有指標同步上漲，即使 不能，也要儘量做到在某個優化目標上漲的情況下，不拉低或者將盡量少拉低其它 指標，力求達到全局最優的效果。
傳統的CVR任務，只考慮從impression到conversion的過程，即：
阿里的ESMM模型還考慮了點擊的過程，並引入了瀏覽轉化率 ( pCTCVR ) 的概念，即爲在瀏覽的條件下既點擊又轉化的概率，即：
不同於CTR預估問題，CVR預估面臨兩個關鍵問題：
問題1. Sample Selection Bias ( SSB ) 轉化是在點擊之後才“有可能”發生的動作，傳統CVR模型通常以點擊數據爲訓練集，其中點擊未轉化爲負例，點擊並轉化爲正例。但是訓練好的模型實際使用時，則是對整個空間的樣本進行預估，而非只對點擊樣本進行預估。即是說，訓練數據與實際要預測的數據來自不同分佈，這個偏差對模型的泛化能力構成了很大挑戰。
問題2. Data Sparsity ( DS ) 作爲CVR訓練數據的點擊樣本遠小於CTR預估訓練使用的曝光樣本。
模型結構如下：
仔細觀察上圖，留意以下幾點：
- 共享Embedding CVR-task和CTR-task使用相同的特徵和特徵embedding，即兩者從Concatenate之後才學習各自部分獨享的參數；
- 隱式學習pCVR 啥意思呢？這裏pCVR ( 粉色節點 ) 僅是網絡中的一個variable，沒有顯示的監督信號。
更進一步，MMoE模型爲我們提供了多任務模型更加直接的思路，關於共享隱層方面，MMoE和一般多任務學習模型的區別：
一般多任務學習模型：接近輸入層的隱層作爲一個整體被共享
MMoE：將共享的底層表示層分爲多個expert，同時設置了gate，使得不同的任務可以多樣化的使用共享層。如圖：
a. 是最原始的多任務學習模型，也就是base
b. 是加入單門 ( one gate ) 的MoE layer的多任務學習模型
c. 是文章提出的模型。可以看出，c本質上是將base的shared bottom換成了MoE layer，並對每個任務都加gate
智能推薦遇上花椒直播
直播中的推薦和商品推薦等場景有所不同，是“活的”而不是“死的”，因爲直播是長時間連續性的，並 且內容是實時在變的，比如用戶喜歡看跳舞直播，那麼當主播不跳的時候用戶可能也不想看了。因此 我們需要把直播最核心、最精彩的部分挖掘出來推薦給用戶。
這就需要對多模態內容進行理解、融合，包括但不限於:
- 文本：如直播間標題、彈幕等
- 圖片：如主播頭像、封面等
- 視頻：如可以識別主播是否在跳舞、遊戲、掛機等
- 音頻：如可以識別主播是否在唱歌，在唱什麼類型的歌等
除了上面所說需要對直播的多模態內容進行理解，一些實時的數據也是非常重要的，它們一定程度 上可以反映當前直播的火熱程度和受歡迎程度，放到模型中作爲特徵可以加強推薦系統的準確性和實時性。包括但不限於：實時看播人數、打賞人數/金額、彈幕數、點贊數、分享數、新增粉絲 數、是否正在唱歌/跳舞/連麥PK、是否正在掛機、遊戲精彩瞬間 ( 如吃雞剩餘人數、王者榮耀KDA ) 等。
花椒直播模型的結構十分明確，原始數據包括用戶特徵，上下文特徵，過去歷史特徵，當前需要預測的物品特徵等。對於特徵進行嵌入操作，在特徵交互層可以使用上文提到的很多結構，如W&D，FM，attention。隨後加入DNN結構進行特徵融合，最後輸出多目標預測結果。等結構如下：
模型訓練和更新的邏輯如下，將模型數據整理好，全量樣本存入HDFS中，以周或者天爲單位進行模型更新，增量樣本flink流處理，進行離線訓練和更新，以滿足實時性的要求。模型驗證通過線下指標對模型進行監控，訓練好之後採用tensorflow serving這種框架提供服務。推薦引擎使用golang來處理用戶請求，以及將請求轉化爲特徵傳入tensorflow serving中。
總結
本次分享總結了花椒直播沿着業內的發展路線從0到1搭建個性化推薦系統的過程，先後嘗試了許多模 型，每個模型除了其典型的結構外，還有許多非常珍貴的細節，比如公式推導，參數的選擇，工程上的trick等等，這些大家可以查閱相關模型論文。
要注意的是，沒有“最好的模型”，只有“最適合的模型”，並不是說模型越fancy越複雜，線上效果就會越好。比如阿里提出了DIN模型，是因爲工程師們首先發現了數據中“多峯分佈”、“部分激活”的現象，而在直播場景中這個特點就不是很明顯，因此上線了DIN模型後的提升也不是很大。
但直播場景也有其自身的特點，如多模態、實時性和熱點效應等。只有深入理解了場景，並基於用戶行爲和數據提取出能表現這個場景的特徵，再對應地開發適用於這個場景的模型，才能取得最佳的效果。
本次分享就到這裏，謝謝大家。
本文來自 DataFunTalk
原文鏈接：