巨經典論文！推薦系統經典模型Wide & Deep

今天咱們剖析的也是推薦領域的經典論文，叫作Wide & Deep Learning for Recommender Systems。它發表於2016年，做者是Google App Store的推薦團隊。這年恰好是深度學習興起的時間。這篇文章討論的就是如何利用深度學習模型來進行推薦系統的CTR預測，能夠說是在推薦系統領域一次深度學習的成功嘗試。

著名的推薦模型Wide & deep就是出自這篇論文，這個模型由於實現簡單，效果不俗而在各大公司普遍應用。所以它一樣也能夠認爲是推薦領域的必讀文章之一。

摘要

在大規模特徵的場景當中，咱們一般（2016年以前）是使用將非線性特徵應用在線性模型上的作法來實現的，使用這種方式，咱們的輸入會是一個很是稀疏的向量。雖然咱們要實現這樣的非線性特徵，經過一些特徵轉化以及特徵交叉的方法是能夠實現的，可是這會須要消耗大量的人力物力。

這個問題其實咱們以前在介紹FM模型的時候也曾經提到過，對於FM模型來講，其實解決的也是一樣的問題。只是解決的方法不一樣，FM模型的方法是引入一個n x k的參數矩陣V來計算全部特徵兩兩交叉的權重，來下降參數的數量以及提高預測和訓練的效率。而在本篇paper當中，討論的是使用神經網絡來解決這個問題。

解決問題的核心在於embedding，embedding直譯過來是嵌入，可是這樣並不容易理解。通常來講咱們能夠理解成某些特徵的向量表示。好比Word2Vec當中，咱們作的就是把一個單詞用一個向量來表示。這些向量就稱爲word embedding。embedding有一個特色就是長度是固定的，可是值通常是經過神經網絡來學習獲得的。

咱們能夠利用一樣訓練embedding的方式來在神經網絡當中訓練一些特徵的embedding，這樣咱們須要的特徵工程的工做量就大大地減小。可是僅僅使用embedding也是不行的，在一些場景當中可能會引發過擬合，因此咱們須要把線性特徵以及稀疏特徵結合起來，這樣就可讓模型既不會陷入過擬合，又能夠有足夠的能力能夠學到更好的效果。

簡介

正如咱們以前文章所分享的同樣，推薦系統也能夠當作是搜索的排序系統。它的輸入是一個用戶信息以及用戶瀏覽的上下文信息，返回的結果是一個排好序的序列。

正由於如此，對於推薦系統來講，也會面臨一個和搜索排序系統一個相似的挑戰——記憶性和泛化性的權衡。記憶性能夠簡單地理解成對商品或者是特徵之間成對出現的一種學習，因爲用戶的歷史行爲特徵是很是強的特徵，記憶性所以能夠帶來更好的效果。可是與之同時也會有問題產生，最典型的問題就是模型的泛化能力不夠。

對於泛化能力來講，它的主要來源是特徵之間的相關性以及傳遞性。有可能特徵A和B直接和label相關，也可能特徵A與特徵B相關，特徵B與label相關，這種就稱爲傳遞性。利用特徵之間的傳遞性， 咱們就能夠探索一些歷史數據當中不多出現的特徵組合，從而得到很強的泛化能力。

在大規模的在線推薦以及排序系統當中，好比像是LR這樣的線性模型被普遍應用，由於這些模型很是簡單、拓展性好、性能很強，而且可解釋性也很好。這些模型常常用one-hot這樣的二進制數據來訓練，舉個例子，好比若是用戶安裝了netflix，那麼user_installed_app=netflix這個特徵就是1，不然就是0。所以呢，一些二階特徵的可解釋性就很強。

好比用戶若是還瀏覽過了Pandora，那麼user_installed_app=netflix,impression_app=pandora這個聯合特徵就是1，聯合特徵的權重其實就是這二者的相關性。可是這樣的特徵須要大量的人工操做，而且因爲樣本的稀疏性，對於一些沒有在訓練數據當中出現過的組合，模型就沒法學習到它們的權重了。

可是這個問題能夠被基於embedding的模型解決，好比以前介紹過的FM模型，或者是深度神經網絡。它能夠經過訓練出低維度下的embedding，用embedding向量去計算獲得交叉特徵的權重。然而若是特徵很是稀疏的話，咱們也很難保證生成的embedding的效果。好比用戶的偏比如較明顯，或者是商品比較小衆，在這樣的狀況下會使得大部分的query-item的pair對沒有行爲，然而由embedding算出來的權重可能大於0，所以而致使過擬合，使得推薦結果不許。對於這種特殊的狀況，線性模型的擬合、泛化能力反而更好。

在這篇paper當中，咱們將會介紹Wide & Deep模型，它在一個模型當中兼容了記憶性以及泛化性。它能夠同時訓練線性模型以及神經網絡兩個部分，從而達到更好的效果。

論文的主要內容有如下幾點：

1. Wide & Deep模型，包含前饋神經網絡embedding部分以及以及線性模型特徵轉換，在廣義推薦系統當中的應用
2. Wide & Deep模型在Google Play場景下的實現與評估，Google Play是一個擁有超過10億日活和100w App的移動App商店

推薦系統概述

這是一張經典的推薦系統的架構圖：

當用戶訪問app store的時候會生成一個請求，這個請求當中會包含用戶以及上下文的特徵。推薦系統會返回一系列的app，這些app都是模型篩選出來用戶可能會點擊或者是購買的app。當用戶看到這些信息以後，會產生一些行爲，好比瀏覽（沒有行爲）、點擊、購買，產生行爲以後，這些數據會被記錄在Logs當中，成爲訓練數據。

咱們看下上面部分，也就是從DataBase到Retrieval的部分。因爲Database當中的數據量過大，足足有上百萬。因此咱們想要在規定時間內（10毫秒）給全部的app都調用模型打一個分，而後進行排序是不可能的。因此咱們須要對請求進行Retrieval，也就是召回。Retrieval系統會對用戶的請求進行召回，召回的方法有不少，能夠利用機器學習模型，也能夠進行規則。通常來講都是先基於規則快速篩選，再進行機器學習模型過濾。

進行篩選和檢索結束以後，最後再調用Wide & Deep模型進行CTR預估，根據預測出來的CTR對這些APP進行排序。在這篇paper當中咱們一樣忽略其餘技術細節，只關注與Wide & Deep模型的實現。

Wide & Deep原理

首先咱們來看下業內的經常使用的模型的結構圖：

這張圖源於論文，從左到右分別展現了Wide模型，Wide & Deep模型以及Deep模型。從圖上咱們也看得出來所謂的Wide模型呢其實就是線性模型，Deep模型是深度神經網絡模型。下面結合這張圖對這兩個部分作一個詳細一點的介紹。

Wide部分

Wide部分其實就是一個泛化的形如 的線性模型，就如上圖左邊部分所展現的同樣。y是咱們要預測的結果，x是特徵，它是一個d維的向量 。這裏的d是特徵的數量。一樣w也是一個d維的權重向量 ，b呢則是偏移量。這些咱們在以前線性迴歸的模型當中曾經都介紹過，你們應該也都不陌生。

特徵包含兩個部分，一種是原始數據直接拿過來的數據，另一種是咱們通過特徵轉化以後獲得的特徵。最重要的一種特徵轉化方式就是交叉組合，交叉組合能夠定義成以下形式：

這裏的 是一個bool型的變量，表示的是第i個特徵的第k種轉化函數 的結果。因爲使用的是乘積的形式，只有全部項都爲真，最終的結果纔是1，不然是0。好比"AND(gender=female,language=en)"這就是一個交叉特徵，只有當用戶的性別爲女，而且使用的語言爲英文同時成立，這個特徵的結果纔會是1。經過這種方式咱們能夠捕捉到特徵之間的交互，以及爲線性模型加入非線性的特徵。

Deep部分

Deep部分是一個前饋神經網絡，也就是上圖當中的右側部分。

咱們觀察一下這張圖會發現不少細節，好比它的輸入是一個sparse的feature，能夠簡單理解成multihot的數組。這個輸入會在神經網絡的第一層轉化成一個低維度的embedding，而後神經網絡訓練的是這個embedding。這個模塊主要是被設計用來處理一些類別特徵，好比說item的類目，用戶的性別等等。

和傳統意義上的one-hot方法相比，embedding的方式用一個向量來表示一個離散型的變量，它的表達能力更強，而且這個向量的值是讓模型本身學習的，所以泛化能力也大大提高。這也是深度神經網絡當中常見的作法。

Wide & Deep合併

Wide部分和Deep部分都有了以後，經過加權的方式合併在一塊兒。這也就是上圖當中的中間部分。

最上層輸出以前實際上是一個sigmoid層或者是一個linear層，就是一個簡單的線性累加。英文叫作joint，paper當中還列舉了joint和ensemble的區別，對於ensemble模型來講，它的每個部分是獨立訓練的。而joint模型當中的不一樣部分是聯合訓練的。ensemble模型當中的每個部分的參數是互不影響的，可是對於joint模型而言，它當中的參數是同時訓練的。

這樣帶來的結果是，因爲訓練對於每一個部分是分開的，因此每個子模型的參數空間都很大，這樣才能得到比較好的效果。而joint訓練的方式則沒有這個問題，咱們把線性部分和深度學習的部分分開，能夠互補它們之間的缺陷，從而達到更好的效果，而且也不用人爲地擴大訓練參數的數量。

系統實現

app推薦的數據流包含了三個部分：數據生產、模型訓練以及模型服務。用一張圖來展現大概是這樣的：

數據生產

在數據生產的階段，咱們使用app在用戶面前曝光一段時間做爲一個樣本，若是這個app被用戶點擊安裝，那麼這個樣本被標記爲1，不然標記爲0。這也是絕大多數推薦場景下的作法。

在這個階段，系統會去查表，把一些字符串類別的特徵轉化成int型的id。好比娛樂類的對應1，攝影類的對應2，好比收費的對應0，免費的對應1等等。同時會把數字類型的特徵作標準化處理，縮放到[0, 1]的範圍內。

模型訓練

paper當中提供了一張模型的結構圖：

從上圖當中咱們能夠看到，左邊是一些連續性的特徵，好比年齡，安裝的app數量等等，右邊是一些離散型的特徵，好比設備信息，安裝過的app等等。這些離散型的特徵都會被轉化成embedding，以後和右邊的連續性特徵一塊兒進入神經網絡進行學習。paper當中使用的是32維的embedding。

模型每次訓練會使用超過500 billion的樣本數量進行訓練，每次蒐集到了新的訓練數據都會訓練模型。可是若是每一次訓練咱們都從頭開始的話，顯然會很是緩慢，而且會浪費大量的計算資源。所以paper當中選擇了一種增量更新的模式，也就是說在模型更新的時候，會加載舊模型的參數，再使用最新的數據進行更新訓練。在新模型更新上線以前，會先驗證模型的效果，確認效果沒有問題以後再進行更新。

模型服務

當模型被訓練好被加載進來以後，對於每個請求，服務器都會從recall系統當中獲取一系列候選的app，以及用戶的特徵。接着調用模型對每個app進行打分，獲取了分數以後，服務器會對候選的app按照分數從高到低進行排序。

爲了保證服務器的響應能力，可以在10ms時間內返回結果，paper採起了多線程併發執行的方法。老實講，我以爲這份數據有點虛。由於如今的模型沒有不使用併發執行的，但即便是併發執行，使用深度學習進行預測也很難保證效率可以到達這種程度。也許是還採用了其餘的一些優化，可是paper裏沒有全寫出來。

模型結果

爲了驗證Wide & Deep模型的效果，paper在真實的場景當中從兩個角度進行了大量的測試。包括app的獲取量以及服務的表現。

App 獲取量

在線上環境進行了爲期3周的A/B測試，1個桶做爲對照桶，使用以前版本的線性模型。1個桶使用Wide & Deep模型，另一個桶只使用Deep模型，去除了linear的部分。這三個桶各自佔據了1%的流量，最後獲得的結果以下：

Wide & Deep模型不只AUC更高，而且線上APP的獲取量也提高了3.9%。

服務性能

對於推薦系統來講，服務端的性能一直是一個很大的問題，由於既須要承載大量的流量，也須要保證延遲很是短。而使用機器學習或者是深度學習模型來進行CTR的預測，自己的複雜度是很是高的。根據paper當中的說法，高峯時期，他們的服務器會承載1千萬的qps。

若是使用單線程來處理一個batch的數據須要31毫秒，爲了提高速度，他們開發了多線程打分的機制，而且將一個batch拆分紅了幾個部分進行併發計算。經過這樣的方式，將客戶端的延遲下降到了14毫秒。

代碼實現

光說不練假把式，Wide & Deep在推薦領域一度表現不俗，而且模型的實現也不復雜。我曾經使用Pytorch實現過一個簡易版本，貼出來拋磚引玉給你們作一個參考。

import torch 
from torch import nn

class WideAndDeep(nn.Module):
    def __init__(self, dense_dim=13, site_category_dim=24, app_category_dim=32):
        super(WideAndDeep, self).__init__()
        # 線性部分
        self.logistic = nn.Linear(19, 1, bias=True)
        # embedding部分
        self.site_emb = nn.Embedding(site_category_dim, 6)
        self.app_emb = nn.Embedding(app_category_dim, 6)
        # 融合部分
        self.fusion_layer = nn.Linear(12, 6)
    
    def forward(self, x):
        site = self.site_emb(x[:, -2].long())
        app = self.app_emb(x[:, -1].long())
        emb = self.fusion_layer(torch.cat((site, app), dim=1))
        return torch.sigmoid(self.logistic(torch.cat((emb, x[:, :-2]), dim=1)))

因爲我當時的應用場景比較簡單，因此網絡結構只有三層，可是原理是同樣的，若是要應用在複雜的場景當中，只須要增長特徵以及網絡層次便可。

今天的文章就到這裏，衷心祝願你們天天都有所收穫。若是還喜歡今天的內容的話，請來一個三連支持吧~（點贊、關注、轉發）

原文連接，求個關注

{{uploading-image-891321.png(uploading...)}}