機器學習在 360 手機助手的應用實踐

深度學習 · 發表 2018-09-12 07:38:18

摘要：推薦作為解決資訊過載以及挖掘使用者潛在需求的技術，目前已成為網際網路產品的標配。工業界最開始由亞馬遜使用協同過濾，包括常見的基於內容的推薦和基於使用者的推薦；接下來出現矩陣分解，將使用者行為矩陣分解為使用者矩陣和物品矩陣，根據使用者矩陣查找出最相關的TopK個物品；隨著廣告系統中CTR預估流程...

推薦作為解決資訊過載以及挖掘使用者潛在需求的技術，目前已成為網際網路產品的標配。工業界最開始由亞馬遜使用協同過濾，包括常見的基於內容的推薦和基於使用者的推薦；接下來出現矩陣分解，將使用者行為矩陣分解為使用者矩陣和物品矩陣，根據使用者矩陣查找出最相關的TopK個物品；隨著廣告系統中CTR預估流程的日漸成熟，大部分推薦、搜尋問題也轉化為CTR預估問題，這個時期常見的模型包括LR、FM、GBDT以及一些模型融合的嘗試（例如LR+GBDT[1]），這個時期難點是挖掘特徵，需要做大量的特徵工程；近幾年深度學習憑藉強大的表達能力和靈活的網路結構，在語音、影象上取得突破，在推薦領域也大放光彩，Wide&Deep[2]、DeepFM[3]、DIN[4]等網路結構在CTR預估問題中取得不錯的效果。

在360手機助手產品中，首頁、遊戲頁和軟體頁App推薦以及App相關推薦等多個場景中，使用者下載App中推薦佔有較高的比重。為了提升使用者的黏度，360手機助手在產品中也加入資訊和遊戲視訊，如何更好的將App和內容進行混合，提升使用者的下載轉化和內容點選，也是推薦的一個挑戰。本文主要概述360手機助手推薦涉及的方面，包括業務場景的理解，推薦系統架構，以及系統架構中比較核心的推薦流程、資料倉庫建設以及線上分析監控。

業務場景

作為一個相對低頻的APP，產品設計在應用場景中會盡量多元化，不僅要滿足使用者的找應用需求，也要滿足使用者下載後需求。

業務特點

應用市場的業務場景有如下幾個特點：

APP總量多(百萬級)，但是優質相對較少，且不同APP生命週期不同
使用者使用頻度相對較低，使用者基礎畫像粒度較粗
軟體和遊戲的爆款頻率不同，影響使用者下載的決策因素不同
新手機和舊手機在下載習慣上差異大
推薦場景較多，且優化目標不同

由於上面幾個問題，應用商店的推薦系統在側重點上會有所不同。

由於整個系統的每個部分都需要團隊參與開發和維護，所以在工作的過程中我們儘量利用開源專案，並將部分程式碼模組化可配置化，一方面為了方便管理能夠形成知識沉澱，另一方面為了減少維護上的麻煩並降低隱藏風險。

系統架構

360手機助手推薦整體框架圖如下所示：

資料倉庫層

由於演算法技術部不僅要負責所有演算法相關的工作，也要承擔資料建設，資料分析等多維度的需求，在經歷過各種陣痛之後才明白資料建設的重要性。部門最初的資料建設架構採取單層模式：介面層(或解析層)->應用,這種模式在資料來源型別唯一且介面數量很少的場景下不會有太大問題,唯一的優勢就是對於新業務的資料支援比較快，劣勢很多：

重複開發
口徑不一致
改造維護成本高等等。

隨著業務的發展,資料來源型別增加（sdk形式、http請求、內部系統庫等）、業務需求的變化（需求量、複雜性、重複性、及時性、多樣性）單層模式的劣勢被無限放大，此時資料的建設應該中心化、平臺化(大資料中心)，而資料倉庫恰是大資料中心建設的核心。核心目的在於:

介面層遮蔽資料來源的多樣化;
應用層保障資料質量（完整性、及時性、準確定、唯一性）;
分層理念降低因源系統變化導致的遷移改造成本和維護成本、提高複用率避免重複開發及時響應業務需求;
統一分層模型、命名規範,提供了全域性的資料檢視,使知識體系更便於查詢和理解。

計算層

計算層從整體上可以劃分為離線計算和實時計算兩部分。計算層使用到的平臺主要是360系統部提供的Spark, Hadoop MR, HBox（其中完成了對TensorFlow、MXNet、Caffe、Theano、PyTorch、Keras、XGBoost等常用框架的整合，同時具備良好的擴充套件性和相容性）。

離線計算層的輸出主要包括：

使用者畫像
訓練模型
相關索引
個性化Push列表
榜單
報表，分析報告等

實時計算輸出主要包括：

使用者的實時行為反饋
item的短期特徵
伺服器&業務的實時監控指標等

以APP推薦為例

資料收集：使用者畫像資料，APP的特徵資料會隨著推薦日誌記錄下來，通過scribe對日誌進行實時收集，並與使用者的反饋資料通過uniqID進行關聯存入原始訓練資料中。之後進行資料清洗，格式化之後儲存為csv格式存入資料倉庫DM層。

量化指標：APP推薦的指標比較好定義，可以通過CTR/CVR來衡量推薦效果。但是在視訊（內容類）推薦的場景中量化指標會比較複雜，因為在應用商店場景中內容推薦場景的最終目的是提升使用者下載慾望，但是實驗表明直接優化下載最終的推薦結果並不理想，所以在視訊（內容類）推薦中我們正在嘗試使用遷移學習中MTL的思想，通過改進Wide&deep模型支援多目標訓練，利用Tensorflow來對模型進行改進。

資料清洗取樣：使用者的曝光日誌量非常大，但是使用者的點選行為資料相對來說卻很少。所以資料取樣是必須要做的一步，首先過濾掉沒有真正曝光給使用者的資料，否則這些資料對模型的影響會非常大，模型在訓練時的表現也很不穩定。考慮到業務場景的特殊性，有些使用者雖然有真實曝光，但只是只是短暫的行為同時這部分使用者沒有產生任何的反饋資料，所以這部分資料也會被過濾掉。最後會根據優化目標的調整進行上取樣和下采樣的嘗試。

特徵：基於應用商店的使用場景，我們抽象出如下幾個方面的特徵：

APP特徵：基礎特徵：ID，APP名，簡介，分類資訊，包大小，評論資訊，評級資訊，更新時間等；統計特徵：分時間段的下載、CTR、CVR、收入等
使用者特徵：人口屬性: 性別，年齡，地域等；裝置資訊: 機型，品牌，解析度，作業系統等；行為屬性: 類目偏好，分時活躍，下載，搜尋，瀏覽，其他資料來源畫像等
上下文特徵：時間，地域，應用場景，曝光位置等；近期，長期曝光資料
交叉特徵：cross，瀏覽&ID，性別年齡&ID等等；intersection，性別年齡&ID CTR, 興趣&ID CTR等等

分析：畢竟特徵決定模型的上限，雖然深度學習在語音和影象上的端到端的學習取得了非常不錯的成績，但是在推薦系統上想要完成端到端的學習困難還是非常大的，畢竟資料噪聲比較多，而且使用者日誌相比於影象來說也沒有很好的結構。特徵分析一方面對輸入給模型的資料進行優化，另一方面非常重要就是能夠發現系統中存在的隱藏bug，有些bug在系統中很不容易被發現，但是通過特徵分析能夠及時發現，並避免事情進一步惡化。根據JOIN之後的日誌進行特徵分析，首先通過整體覆蓋度判斷特徵質量。對於數值型特徵從均值，方差，相關係數，卡方等維度進行分析。對於類別類特徵從單特徵CTR，資訊增益，AUC等幾個維度進行分析。

小樣本資料示例continuous

小樣本資料示例category

召回部分實際上應該單獨來寫，但是為了介紹的完整性這裡也簡要做一個介紹。 content-based：基於APP的名稱，簡介，作者，tag等資訊做基於內容的相似性，但是由於APP的簡介通常比較短，且重點不夠突出，單純基於內容做相似召回效果並不理想。

item-based：基於item的協同過濾由於使用者的行為受展示內容影響比較大，且長尾APP的行為非常少，雖然對於相對高頻的APP召回效果比較好，但是完全基於協同過濾會出現長尾APP召回不全或者無法召回的問題。

Embedding-based的方式：最開始我們基於使用者安裝資料利用word2vec思想做了embedding，但是使用者的安裝的各個APP之間的關聯性並不強，並不能像文字類得到比較好的效果。後期我們參考youtube推薦系統的思想，通過做排序模型預測，間接得到APP的embedding向量，再計算各個APP的相似度。

如下圖左側基於協同過濾的結果基本集中在共享單車裡面，右側基於embedding方式能夠發現一些其他共性，但是單獨看每個模型都不太好，所以線上需要多種模型做融合，融合的方式需要一些人為經驗，並通過排查badcase來調整。

基於人群的聚類：主要是針對新使用者或者使用者特徵比較少的使用者，比如根據機型，地域，性別，年齡等屬性做召回，這一部分如果單純考慮各個人群的下載量，安裝量會導致結果沒有區分度，所以需要將群裡之間的差異考慮進去。這裡面TGI是一個比較好的衡量效果，但是完全基於TGI會導致結果不受控制，所以需要對TGI公式加以變形，綜合考慮其他因素作為最終結果

基於使用者投票的召回：這部分結果主要針對榜單應用場景，為使用者提供相對權威的榜單結果，提升使用者的信任度，最終提升使用者下載率。榜單分為總榜，飆升榜，新銳榜，分類榜等等。這部分資料會綜合公司其他業務的資料做統一考慮，在排序計算上考慮了IMDB等演算法。

排序模型：同時我們將程式碼封裝為一個通用專案，通過配置檔案的方式選擇特徵組合和處理的方式，自定義模型選擇，選擇優化器，自定義模型的匯出形式等，對於自定義模型只需要重新定義model_fn就可以了。特徵的離散化，embedding，交叉等操作都整合在model裡面，線上只需要資料原始特徵就可以了。線上引擎與離線訓練使用同一套配置檔案對特徵進行處理，避免線上離線兩部分由於人為偏差造成模型使用異常。程式碼結構化之後其他場景就可以比較快速的完成從離線訓練到上線驗證的過程。

示例：下圖左1支援對特徵列的變換處理，左2模型訓練時的引數，左3完整特徵列定義。

在專案最初期排序規則權重比較高，我們參考Facebook提出的Edge Rank思想，將使用者的不同行為定義為不同的Edge，每個邊的權重不同(比如下載大於瀏覽)，相關度作為Edge下面item的score, 並將所有得分相乘得到最終排序。缺點是各個Edge的權重不好定義，需要頻繁做AB測試，同時處理問題不夠平滑。

之後將規則抽象為特徵快速嘗試LR，因為LR模型簡單解釋性強，對於我們理解線上業務有很大的幫助，但是由於LR對於特徵的質量要求比較嚴格，需要我們做大量的特徵挖掘以及特徵組合的嘗試，從價效比的角度來看不會長期把該模型作為主要優化模型。

正是由於LR對特徵組合需求比較高，我們開始嘗試GBDT，以及GBDT+LR的方式，以此減少對特徵組合的煩惱。樹模型雖然對連續型特徵的劃分能力很強，但是具有對於大規模稀疏ID類特徵樹的深度不好控制等缺點。FM在處理交叉特徵上有比較明顯的優勢。考慮到實現成本，後期我們將重點放在深度學習上DNN，FM等模型考慮利用神經網路的方式實現。

目前主要是基於深度學習的推薦，根據Google Play的論文提出的Wide&Deep模型對線上排序進行了更新。wide&deep能夠同時兼顧記憶性和泛化性，對低階特徵和高階特徵都能夠進行學習，目前wide&deep模型已經全量上線多個場景。但是wide部分還是需要人為介入一些交叉特徵項，所以目前正在利用DeepFM來減少人為交叉部分，挖掘隱藏交叉特徵，以此提升線上效果深度學習框架我們選擇了tensorflow，訓練程式碼部分基於tensorflow高階API Estimator來減少操作底層API帶來的複雜性，並利用feature_column靈活的特徵處理特徵提升我們對特徵嘗試的效率。

主要為了做興趣探測以及新品探測，線上主要使用UCB和湯普森取樣，對於新遊需要儘量提高曝光權重，同時如果有優質資源位需要售賣或者強制品牌曝光則會預留位置給運營配置。

線上

引擎排序部分目前分為兩部分，深度學習排序部分完全基於TF Serving，好處是可以減少二次開發量，同時可以方便快速的驗證模型效果，但由於每次請求都需要將大量的特徵資料傳送給TF Serving，所以會帶來額外的網路開銷。傳統機器學習排序部分直接嵌入引擎中，作為引擎內的一個單元，與TF Serving相比節省了網路開銷。同時當TF Serving服務出現問題時，引擎會自動將排序降級為傳統機器學習排序。

對比效果

其中一個業務場景上線之後CTR的對比資料

業務層

從使用者角度看，業務層指不同的推薦場景，每個場景下的產品設計和使用者需求是不同的。

比如首頁第一屏的位置，雖然是個性化推薦，但是因為位置比較特殊，所以個性化推薦的可推內容需要做嚴格篩選，演算法需要在有限的召回集裡面做排序，這種場景對於排序的要求是比較高的。
比如APP的相似推薦，這種場景更關注的是兩個item之間的相關性，所以這中場景對於召回相似性的要求就比較高。

協調排程層

不同層之間的資料流向需要有一個完整的閉環，這樣整個系統的發展才會是良性的。協調層的工作主要包括實時收集使用者的推薦日誌；item特徵變動後準確更新的引擎，使用者畫像更新後快速完整的更新到使用者畫像系統，模型更新之後快速完整的更新到排序引擎等等。

分析&監控層

分析主要面向運營和產品人員，團隊提供了自助查詢平臺和報表工作，方便非技術人員快速查詢資料，分析結果。監控層主要包括核心指標監控和系統指標監控，系統指標監控通過ELK能夠快速的搭建出視覺化監控平臺，能夠方便快速的發現系統存在的問題並及時改進。

總結和展望

在機器學習的路上我們還有很長的路要走。在業務方面還需要繼續加強對業務場景的理解對各個場景進行持續優化。在系統方面特徵伺服器，去重伺服器等需要進一步拆分優化。在特徵方面，我們會繼續對特徵的挖掘和利用進行深入調研，影象類的特徵目前我們還沒有使用，後續將專門針對影象做一些嘗試。在模型方面，我們將持續進行網路結構的探索，嘗試新的模型特性，並針對場景的特點進行契合。學術界和工業界的成功經驗都很有價值，給我們提供了新的思路和方法，但由於面臨的業務問題和場景積累的資料不同，還是需要進行鍼對場景的適配，以達到業務目標的提升。

參考文獻

[1] He X, Pan J, Jin O, et al. Practical lessons from predicting clicks on adsat facebook[C]. Proceedings of 20th ACM SIGKDD Conference on KnowledgeDiscovery and Data Mining. ACM, 2014: 1-9. [2] H.-T. Cheng, L. Koc, J. Harmsen, T. Shaked, T. Chandra, H. Aradhye, G. Anderson, G. Corrado, W. Chai, M. Ispir, et al. Wide & deep learning for recommender systems. arXiv preprint arXiv:1606.07792, 2016. [3] Guo H, Tang R, Ye Y, et al. DeepFM: A Factorization-Machine based Neural Network for CTR Prediction[J]. 2017:1725-1731. [4] Guorui Zhou, Chengru Song, et al. Deep Interest Network for Click-Through Rate Prediction.arXiv preprint arXiv:1706.06978,2017. [5] Covington P, Adams J, Sargin E. Deep Neural Networks for YouTube Recommendations[C]// ACM Conference on Recommender Systems. ACM, 2016:191-198.