機器學習在360手機助手的應用實踐
奇技指南
推薦作為解決信息過載以及挖掘用戶潛在需求的技術，目前已成為互聯網產品的標配。本文主要概述360手機助手推薦涉及的方面，包括業務場景的理解，推薦系統架構，以及系統架構中比較核心的推薦流程、數據倉庫建設以及線上分析監控。本文轉載自奇卓社。
引言
推薦作為解決信息過載以及挖掘用戶潛在需求的技術，目前已成為互聯網產品的標配。工業界最開始由亞馬遜使用協同過濾，包括常見的基於內容的推薦和基於用戶的推薦；接下來出現矩陣分解，將用戶行為矩陣分解為用戶矩陣和物品矩陣，根據用戶矩陣查找出最相關的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.
更多文章請關注360技術公眾號~機器學習在360手機助手的應用實踐
推薦閱讀：
