一路打怪升級，360推薦系統架構演進
【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】