【51CTO.com原創稿件】 推薦系統的核心排序算法已經從傳統的 LR、GBDT 等模型進化到了 Deep&Wide、DeepFM、PNN 等若干深度模型和傳統模型相結合的階段。

如何結合各個業務數據的特點，設計合適的深度推薦算法，同時設計合理的架構保證深度學習算法的穩定運行，成為企業在推動基于深度學習的推薦系統落地的難點。

2018 年 11 月 30 日-12 月 1 日，由 51CTO 主辦的 WOT 全球人工智能技術峰會在北京粵財 JW 萬豪酒店隆重舉行。

本次峰會以人工智能為主題，360 人工智能研究院的技術經理張康在推薦搜索專場與來賓分享"基于深度學習的推薦系統在 360 的應用"的主題演講，為大家詳細闡述在 360 的各種場景下，基于深度學習的推薦系統的各種應用。

本次分享分為如下兩大部分：

• 推薦系統相關算法***研究進展
• 深度推薦系統在 360 的應用實踐

推薦系統相關算法***研究進展

在介紹應用系統之前，首先讓我們從抽象的層次上理解一下，在圖像領域的相關概念。

上圖是我們對推薦系統的一個分層與抽象。在頂層，我們可以理解為是一個函數。

其中 U 代表用戶、I 代表需要推薦的商品、C 代表上下文、Y 則是我們需要優化的目標。

當然，不同的應用場景，Y 的取值會有一定的差異。如果我們的目標是點擊率的話，那么 Y 的取值就是 0 和 1。

而如果我們要預估某個時長的話，那么 Y 的取值就變成了實數，它對應的就是某個回歸問題。可見，根據不同的場景，定義好 Y 是至關重要的。

如果是從算法人員的角度出發，他們會認為定義 Y、和對 F 求解的優化是非常重要的。

而在業務方的那些做產品的人看來，U 的反饋則更為重要，如果出現用戶投訴的話，那么該算法也就失敗了。

另外，他們也會關注 I。由于 I 的背后實際上關聯的是商家，那么同樣要避免出現用戶對于 I 的抱怨。可見，不同角色對于此公式的關注點是不相同的。

在上面抽象圖的中間，我們一般會把頂層簡單的數學公式拆分成三個不同的算法模塊：

• 召回（Recall）
• 排序（Rank）
• 策略（或稱重排序 Rerank）

目前市面上的一些工業領域和學術界的論文，大部分會重點研究和討論 Rank，畢竟 Rank 是非常重要的。

而對于那些針對 Recall 和 Rerank 的技術而言，由于它們并不適合被抽象成為一個統一的理論架構，因此相關的論文也不多。后面我們會重點討論有關召回部分的內容。

經歷了上面兩個抽象層次，圖中的底層就需要讓推薦系統服務于“線上”了。

它由五大關鍵部分所組成：

• ETL 對數據的清洗。不同于那些已經準備好了數據集的傳統競賽，我們面臨的是在真實的線上場景中所產生的日志數據，它們不但“臟”，而且體量非常大。

因此，我們需要有一個對應的數據清洗場景，以緩解系統的處置壓力。

• Server 模塊。針對各種排序和召回的模型場景，我們需要提供實時的服務。

因此服務端不但需要具有高性能的計算能力，同時也需要我們的架構能夠應對大規模的深度學習與計算。如有必要，還可能會用到 GPU 等硬件。

• Platform。這里主要是指深度學習或者機器學習的訓練平臺。在各種算法上線之后，隨著在線學習的推進，其模型不可能一成不變。

有的它們需要被“日更”，甚至是以分鐘為單位進行更新。因此我們需要有一個良好的深度學習平臺提供支持。

• 測試。推薦系統在上線之后，需要被不斷的迭代與優化，因此我們需要通過測試來查看效果。

在系統的起步階段，用戶數量迅速上升，而實驗的整體數量則不多，因此我們很容易通過對***用戶的切分，來開展與流量相關的實驗。

但是隨著業務的發展，用戶數量不再呈爆發式增長，而我們每天又需要進行成百上千次實驗，所以我們需要選用 A/B 測試的實驗平臺，以方便算法人員加速迭代的進程。

• 報表。之前在與業務方合作時，我們發現：他們幾乎每個人都在通過自行編寫簡單腳本的方式獲取所需的報表，因此其工作的重復度相當高。

然而，由于許多報表的計算都是簡單算子的累加，如果我們擁有一個簡單且統一的平臺，就能夠幫助大家獲取常用的指標，進而加速整個系統的迭代。

從深度推薦系統的發展來看，最早出現的是傳統 LR（線性回歸）的機器學習。

之后，隨著特征交叉需求的增多，出現了非線性回歸和使用 FM 來實現二階特征交叉。

近年來，隨著深度學習在圖像領域的廣泛應用，如今大家也將它們引入到了推薦系統之中。

不過，相對于圖像領域動輒一兩百層的神經網絡深度而言，推薦系統的深度只有四到六層。

如今各家“大廠”都能夠提供諸如 FNN、DFM、以及 Google Wide&Deep 之類的算法，我們很難斷言哪種模型更好。

因此大家在進行模型選取的時候，應當注意自己的系統偏好，保持與業務的強關聯性。

上圖借用的是阿里的 DIEN（Deep Interest Evolution Network），他們和我們現在的工作有著相似之處，特別是圖中虛線框里的兩個創新點。我會在后面進行著重分析。

平時，我們在閱讀各種論文時，很容易產生一種錯覺：那些作者為了突出自己的貢獻，經常會著重描寫模型上的創意，體現并抽象其核心的思想，讓大家認為該部分的占比能達到 80%。

而實驗部分都只是一些標準的數據集，經常一筆帶過。實際上，他們在模型側的工作量一般只有 20%，其他的 80% 則花在了做實驗上。

具體說來，我們可以開展如下各種實驗：

• 在拿到原始的線上日志數據之后，我們需要對它們做分析、統計和處理，以方便我們后期進行模型訓練。
• 特征設計、交叉和服務，包括：是否要將特征值離散化，是否要放大時間窗口等。
• 模型選擇，我們需要全面考慮計算的開銷，甚至要考慮自己的平臺上是否有 GPU，倘若沒有，則不應選擇過于復雜的模型。同時，我們也要根據核心算法，制定召回和仲裁策略。
• ***是真正傳統意義上的實驗，包括離線評測、線上 A/B 和實驗分析等，這些都會與前面的四項有所關聯。

深度推薦系統在 360 的應用實踐

下面，我們來討論一下深度推薦系統在 360 中幾個場景應用的落地。如圖的三款應用在技術上呈由淺入深、由簡單到復雜的遞進關系。

場景一：App 推薦

360 手機助手，類似于應用市場。圖中紅框里顯示的都是系統推薦的內容，包括：“今日熱點”和“大家都在玩”等，這些都是與用戶的個性化喜好相關的。我們直接從用戶的下載和轉化率，來判定系統推薦的效果。

套用前面提到的三個層次：

• 抽象定義層。由于我們做的是一個離線系統，因此我們對 C 考慮并不多，主要將重點放在了 U 和 I 上。該場景下的 U 屬于億級，而 I 只有萬級，畢竟我們只需要在萬級的 App 庫里做推薦。
• 算法策略層。由于 I 的量級比較小，我們當時就“簡單粗暴”地直接在這個萬級用戶庫里做了用戶匹配和推薦，而并沒有執行召回策略。我們首先通過簡單的算法做出了一個初版模型。

為了查看效果，我們通過迭代、優化和序列預測，來預測用戶下一次會安裝哪一種 App。而 Rank 和 Rerank 部分的邏輯，由于主要涉及到各種線上的業務邏輯，因此是由業務方來完成的。

• 架構層。它對應的是我們的天級離線中心，在特征上并不復雜，僅通過 Embedding 特征的運用就完成了。

上圖是我們對于模型的邏輯進化路徑。上圖的左側與 Google Wide&Deep 的思路是很相似的，只不過我們用的特征非常少。

上方藍色部分是用戶 App 序列的 ID 列表，我們使每個 App 都有一個特征向量，然后做若干層的 MLP，***做分類，從而預測某個用戶下一步可能安裝的 App。

后來，隨著與業務人員的交流，我們在模型中加入了用戶的瀏覽歷史、搜索歷史、關鍵詞特征、和 App 特征等元素，不過其本質上也都是行為的序列。

考慮到簡單的 MLP 已不太適合，因此我們就嘗試采用了 RNN 的方法進行數據建模，于是就有了如下圖進化后的網絡：

雖然該圖的上層分類與前面類似，但是下面的 browse 卻值得大家注意：當你把用戶的搜索行為加到自己的特征里時，請注意調整時間序列，不然很容易會導致該搜索詞變成了一個搜索系統。

即：你的本意是通過用戶的搜索詞，來反應他的興趣，并預測他要下載的 App。

但是，如果不做處理的話，就可能導致你的系統只是在模擬某個線上的搜索。

上面這張圖是將兩個模型的不同結果進行了比較。它們分別對每個 App 的 Embedding 向量進行了可視化。我們將 App 的 Embedding 向量取出，并投影到二維圖上。

我們根據 App 原來所隸屬的大類，來判斷經過模型學習后，如果能將大類拉得比較散的話，那么效果就會更好些。

可見，在左邊 MLP 的中間，各種類型的交疊比較嚴重。而在我們換成了 RNN 模型之后，它們就顯得分散了許多。我們籍此來直觀地認為改進后的模型更好。

根據上面將 RNN 的效果與 MLP 的效果所進行的數據比較，我們可以看出：在 Top1 上的差異并不太大，僅提升了 1 個點。

當然，這可能對于線上系統的提升會反應得顯著一些，但是對于我們的離線系統，提升反應就沒那么明顯了。這便是我們整個團隊在推薦領域的***次試水。

場景二：360 搜索和導航

有了前面 App 推薦的經驗積累，我們嘗試的第二個項目是“常搜詞”。即：360 頁面有自己的搜索和導航，而在搜索框的下方，我們會放置六到七個用戶經常搜索、或者是時常用到的關鍵詞。

如此，用戶在打開導航時就能看到自己想看的東西，這不但減少了他們在操作上的復雜度，還提升了用戶在使用上的滿意度。

在該場景下，由于我們的導航每天都有好幾億次的 PV（Page View），因此使用該功能的用戶有著***的體量，即 U 為***。

同時，為了定義“常搜詞”，我們對 query（查詢）進行了清洗，過濾掉了一些非常“長尾”的 query，只留下一些有實體字的、較為明確的 query。因此，此處的 I 就根據 query 的數量被設定為了***。

由于該業務本身已存在了較長時間，因此在算法策略上也已實現一些較為完善的召回（Recall），例如：

• 搜索詞：是根據用戶的搜索行為，召回一些新的關鍵詞。
• URL：是根據用戶瀏覽器里面的瀏覽記錄，再輸入一些關鍵詞。
• 廣告：是通過滿足用戶的興趣匹配，精準地投放商業化的廣告詞。
• 百科：是判斷用戶可能感興趣的知識，投放相應的百科詞匯。

另外在 Rank 方面，我們著手將線上系統從以前簡單的 LR+FTRL，升級并優化成為了 DNN 模型。

在架構上，由于該導航系統的特點是用戶使用頻次不高，而我們的推薦可能每天只會被早晚各用一次，因此我們的目標是天級離線更新。

其對應的特征部分，則主要是基于用戶的搜索日志和瀏覽日志，來進行的一些統計特征的設定。

讓我們來看看其中幾個權重比較正向的特征，例如：

• week_freq_num 特征，描述了用戶常搜詞匯的概率分布，即：如果某個用戶在過去一段時間窗口內成均勻的訪問趨勢，則說明這是經常性的需求。該特征比較重要。
• global_query_uv 特征，此類全網特征能夠在一定程度上反映商品的質量。我們籍此在原有特征的基礎上擴展到成千上萬個。

在我們將模型調整成為 DNN 之后，系統的 AUC 從 7 提到 8。之后我們還增加了一些其他能夠提升 AUC 的特征。

為了細粒度地分析 DNN 模型的召回策略在上線之后所產生的影響，我們拿它與傳統的 LR+FTRL 模型進行了對比。

途中兩處 CTR 較高，它們都與用戶的搜索和瀏覽行為相關，并且能夠真正反映他們的需求。

由于此類搜索、瀏覽和 MLP 的點擊率本身就比較高，因此我們需要在此基礎上有一個量的提升。

另外在上圖中，雖然與個性化相關的廣告部分略有提升，但是 ys_mid_hist 是有所下跌的。

通過分析，我們發現該模型當時在排序時，傾向于把策略后排，其導致的結果是：用戶在界面上默認只能看到六個推薦詞，而實際上其旁邊有一個往下點的箭頭，在被點擊之后才會出現很多的詞匯。

因此，如果某些推薦詞匯被排到了第六名之后的話，那么它們被點擊的可能性就非常小。這也說明了默認六個詞的重要性。

同時，這也提示了我們：在做數據時，需要重點關注那些用戶通過點擊下拉按鈕去訪問的詞匯，那些數據才更能夠說明用戶對某些詞匯的強烈需要。總的說來，我們協助業務側將 2017 年 Q1 的收入提升了 5%。

場景三：快視頻

基于前面兩個項目所積累的經驗，我們全情地投入了第三個項目—快視頻。其主要的業務形式是個性化的消息推送，與大家手機上的通知欄推送相類似。

但是，略有不同的是：我們并非每日都定時推送，而是會根據用戶的反饋偏好，去調整推薦的數量、頻率和時間。

同時，這對于將一些尚未養成每日到我們的 App 里觀看視頻的用戶來說，能夠起到一定“拉活”的作用。

在此，我們仍然套用前面的三個層次。在頂層，由于該 App 上線之后，視頻庫的規模和用戶的數量都增長得非常迅速，因此 U 和 I 都具有***。

在召回策略上，圖中列出了五種重要的召回。前三項分別是：語義、視覺和行為召回。我們統一地對它們進行了重點優化。

而在距離用戶更近的 Rank 部分，我們通過收斂，采用了 LSTM + Attention 的模型。

前面介紹過的兩個項目都僅僅是以天為單位進行更新，因此對算法人員的壓力并不大，只需采用定時任務便可。

而在這個場景中，由于它是一個對用戶進行實時在線推薦的系統，如果采用“天級更新”頻率的話，會給用戶帶來較差的體驗。

因此無論是對召回的數據流、模型的更新、還是在線的服務，我們都認真進行了架構設計。

我們來看看剛才提到的三個召回策略：行為、語義和視覺。在此，我們將它們統一到了 Embedding 框架之中，以便從視頻的不同角度進行描述和特征表示，而不必關心后續有關設計域值、隊列長度等問題。

通過執行統一的流程，我們能夠更直觀的體現出各種視頻在特征領域下召回的根據。

例如圖中黑體字是某個視頻的 title（標題），明顯，它是有關傳授烹飪知識的召回：

• 就行為模型而言，它通過對用戶行為序列的協同與分割，為每個視頻分配各種特征向量。

其特點是：會產生一定的擴散效果。即，你會在上圖中發現，該召回的前兩個結果已經不再關注烹飪，而是擴散到了其他領域。只有第三個召回才是真正有關于烹飪的。

• 語義模型，重點關注的是視頻標題的語義表示，通過語法和語義的相似性，此類召回能夠抓住標題中關鍵性的動詞與名詞，然后進行相應的交叉和擴散等操作。
• 視覺模型，是通過抽取視頻的特征，來實現召回。它與標題的語義關聯性不強，就算標題與烹飪無關，只要在視頻中大量出現食物的圖像，便可以表示并召回。

由上可見，我們通過不同的 Embedding，就可以實現多樣的召回策略。

下面我們重點介紹語義模型。我們所得到的輸入數據是公司過往生成的查詢、與搜索數據，或是其他的業務線積累的標簽數據，例如由網頁標題所抽象出來的簡單標簽。

這些標簽既有自動生成的，也有通過人工修正和 rebind（重新連接）產生的。它們都具有一定的實際價值。

為了給每個 title 產生相應的表征，我們構建了一項任務：首先是對每個句子進行分詞，以得到相應的字/詞向量，然后通過 CNN 網絡進行處理，***對目標予以多分類、多標簽，從而預測該標簽準確性。

對于上述任務，我們除了嘗試過 CNN 模型之外，還在不改變 task 的情況下試用了雙向的 LSTM，即 bi-LSTM。接著，我們需要對該語義模型進行評測。

在此業務場景下，我們人工標出了幾千個具有良好多樣性的數據，并將其作為離線評測的指標，以此來檢查通過語義模型召回標注數據的結果相關性。上圖左側的表格就是我們測試的結果。

我們在此比較了幾種常見的語義建模的模型、及其對應的優化。表格的中間列是 Title2Tags，即通過標題來預測對應的標簽。

至于右邊列：Title2UnionTags，我們對應地發現到：如果只有單個標題，則語義往往會被遺漏。

如上圖右側的例子所示：無論是人工寫的標題，還是自動生成的，如果我們將多個標簽放到一塊兒，句子中的語義則會更準確地被覆蓋到。

另外我們后續對數據的清洗，也能夠提升原句子的標簽數量，進而大幅提升模型的整體效果。

上圖是我們開篇引用過的阿里 DIEN，在其虛線框中有兩個創新點，分別是 AUGRU（即 Attention 與 GRU 的合并）和輔助的 loss。

雖然 loss 對模型的提升效果非常明顯，可惜我們在模型設計時，過于關注 Attention 的 layer 和下沉到用戶序列上的特征，因此我們將來尚有改進的空間。

上圖便是我們當時對不同排序模型的評測結果。

可見我們在系統架構的設計上，既有諸如到臺服務、日志搜集、和報表等離線部分，又有實時的在線更新。

同時，我們也與業務方的在線系統保持著實時性的交互，以便他們按需獲取推送的數據。另外在最上層，我們為業務方也提供了多種安全策略和分桶策略。

上圖便是我們從 2017 年 11 月 1 日到 2018 年 1 月 31 日的 CTR 曲線。

雖然有某些“坑點”所導致的曲線波動，但是整體趨勢還是向上的，特別是在我們更換了 Attention 模型之后，提升的幅度能夠達到 10%，進而有效地幫助業務方實現了“拉活”和保持更多的活躍用戶。

綜上所述，我們基于深度學習的推薦系統就是根據上述三個層次，一步一步地通過迭代和優化發展起來的。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】