推薦系統(tǒng)經(jīng)典模型Wide & Deep
今天我們剖析的也是推薦領(lǐng)域的經(jīng)典論文，叫做Wide & Deep Learning for Recommender Systems。它發(fā)表于2016年，作者是Google App Store的推薦團(tuán)隊。這年剛好是深度學(xué)習(xí)興起的時間。這篇文章討論的就是如何利用深度學(xué)習(xí)模型來進(jìn)行推薦系統(tǒng)的CTR預(yù)測，可以說是在推薦系統(tǒng)領(lǐng)域一次深度學(xué)習(xí)的成功嘗試。
著名的推薦模型Wide & deep就是出自這篇論文，這個模型因為實現(xiàn)簡單，效果不俗而在各大公司廣泛應(yīng)用。因此它同樣也可以認(rèn)為是推薦領(lǐng)域的必讀文章之一。
長文預(yù)警，建議先馬后看。
摘要
在大規(guī)模特征的場景當(dāng)中，我們通常(2016年之前)是使用將非線性特征應(yīng)用在線性模型上的做法來實現(xiàn)的，使用這種方式，我們的輸入會是一個非常稀疏的向量。雖然我們要實現(xiàn)這樣的非線性特征，通過一些特征轉(zhuǎn)化以及特征交叉的方法是可以實現(xiàn)的，但是這會需要消耗大量的人力物力。
這個問題其實我們之前在介紹FM模型的時候也曾經(jīng)提到過，對于FM模型來說，其實解決的也是同樣的問題。只是解決的方法不同，F(xiàn)M模型的方法是引入一個n x k的參數(shù)矩陣V來計算所有特征兩兩交叉的權(quán)重，來降低參數(shù)的數(shù)量以及提升預(yù)測和訓(xùn)練的效率。而在本篇paper當(dāng)中，討論的是使用神經(jīng)網(wǎng)絡(luò)來解決這個問題。
解決問題的核心在于embedding，embedding直譯過來是嵌入，但是這樣并不容易理解。一般來說我們可以理解成某些特征的向量表示。比如Word2Vec當(dāng)中，我們做的就是把一個單詞用一個向量來表示。這些向量就稱為word embedding。embedding有一個特點就是長度是固定的，但是值一般是通過神經(jīng)網(wǎng)絡(luò)來學(xué)習(xí)得到的。
我們可以利用同樣訓(xùn)練embedding的方式來在神經(jīng)網(wǎng)絡(luò)當(dāng)中訓(xùn)練一些特征的embedding，這樣我們需要的特征工程的工作量就大大地減少。但是僅僅使用embedding也是不行的，在一些場景當(dāng)中可能會引起過擬合，所以我們需要把線性特征以及稀疏特征結(jié)合起來，這樣就可以讓模型既不會陷入過擬合，又可以有足夠的能力可以學(xué)到更好的效果。
簡介
正如我們之前文章所分享的一樣，推薦系統(tǒng)也可以看成是搜索的排序系統(tǒng)。它的輸入是一個用戶信息以及用戶瀏覽的上下文信息，返回的結(jié)果是一個排好序的序列。
正因為如此，對于推薦系統(tǒng)來說，也會面臨一個和搜索排序系統(tǒng)一個類似的挑戰(zhàn)——記憶性和泛化性的權(quán)衡。記憶性可以簡單地理解成對商品或者是特征之間成對出現(xiàn)的一種學(xué)習(xí)，由于用戶的歷史行為特征是非常強(qiáng)的特征，記憶性因此可以帶來更好的效果。但是與之同時也會有問題產(chǎn)生，最典型的問題就是模型的泛化能力不夠。
對于泛化能力來說，它的主要來源是特征之間的相關(guān)性以及傳遞性。有可能特征A和B直接和label相關(guān)，也可能特征A與特征B相關(guān)，特征B與label相關(guān)，這種就稱為傳遞性。利用特征之間的傳遞性， 我們就可以探索一些歷史數(shù)據(jù)當(dāng)中很少出現(xiàn)的特征組合，從而獲得很強(qiáng)的泛化能力。
在大規(guī)模的在線推薦以及排序系統(tǒng)當(dāng)中，比如像是LR這樣的線性模型被廣泛應(yīng)用，因為這些模型非常簡單、拓展性好、性能很強(qiáng)，并且可解釋性也很好。這些模型經(jīng)常用one-hot這樣的二進(jìn)制數(shù)據(jù)來訓(xùn)練，舉個例子，比如如果用戶安裝了netflix，那么user_installed_app=netflix這個特征就是1，否則就是0。因此呢，一些二階特征的可解釋性就很強(qiáng)。
比如用戶如果還瀏覽過了Pandora，那么user_installed_app=netflix,impression_app=pandora這個聯(lián)合特征就是1，聯(lián)合特征的權(quán)重其實就是這兩者的相關(guān)性。但是這樣的特征需要大量的人工操作，并且由于樣本的稀疏性，對于一些沒有在訓(xùn)練數(shù)據(jù)當(dāng)中出現(xiàn)過的組合，模型就無法學(xué)習(xí)到它們的權(quán)重了。
但是這個問題可以被基于embedding的模型解決，比如之前介紹過的FM模型，或者是深度神經(jīng)網(wǎng)絡(luò)。它可以通過訓(xùn)練出低維度下的embedding，用embedding向量去計算得到交叉特征的權(quán)重。然而如果特征非常稀疏的話，我們也很難保證生成的embedding的效果。比如用戶的偏好比較明顯，或者是商品比較小眾，在這樣的情況下會使得大部分的query-item的pair對沒有行為，然而由embedding算出來的權(quán)重可能大于0，因此而導(dǎo)致過擬合，使得推薦結(jié)果不準(zhǔn)。對于這種特殊的情況，線性模型的擬合、泛化能力反而更好。
在這篇paper當(dāng)中，我們將會介紹Wide & Deep模型，它在一個模型當(dāng)中兼容了記憶性以及泛化性。它可以同時訓(xùn)練線性模型以及神經(jīng)網(wǎng)絡(luò)兩個部分，從而達(dá)到更好的效果。
論文的主要內(nèi)容有以下幾點：
Wide & Deep模型，包含前饋神經(jīng)網(wǎng)絡(luò)embedding部分以及以及線性模型特征轉(zhuǎn)換，在廣義推薦系統(tǒng)當(dāng)中的應(yīng)用
Wide & Deep模型在Google Play場景下的實現(xiàn)與評估，Google Play是一個擁有超過10億日活和100w App的移動App商店
推薦系統(tǒng)概述
這是一張經(jīng)典的推薦系統(tǒng)的架構(gòu)圖：
當(dāng)用戶訪問app store的時候會生成一個請求，這個請求當(dāng)中會包含用戶以及上下文的特征。推薦系統(tǒng)會返回一系列的app，這些app都是模型篩選出來用戶可能會點擊或者是購買的app。當(dāng)用戶看到這些信息之后，會產(chǎn)生一些行為，比如瀏覽(沒有行為)、點擊、購買，產(chǎn)生行為之后，這些數(shù)據(jù)會被記錄在Logs當(dāng)中，成為訓(xùn)練數(shù)據(jù)。
我們看下上面部分，也就是從DataBase到Retrieval的部分。由于Database當(dāng)中的數(shù)據(jù)量過大，足足有上百萬。所以我們想要在規(guī)定時間內(nèi)(10毫秒)給所有的app都調(diào)用模型打一個分，然后進(jìn)行排序是不可能的。所以我們需要對請求進(jìn)行Retrieval，也就是召回。Retrieval系統(tǒng)會對用戶的請求進(jìn)行召回，召回的方法有很多，可以利用機(jī)器學(xué)習(xí)模型，也可以進(jìn)行規(guī)則。一般來說都是先基于規(guī)則快速篩選，再進(jìn)行機(jī)器學(xué)習(xí)模型過濾。
進(jìn)行篩選和檢索結(jié)束之后，最后再調(diào)用Wide & Deep模型進(jìn)行CTR預(yù)估，根據(jù)預(yù)測出來的CTR對這些APP進(jìn)行排序。在這篇paper當(dāng)中我們同樣忽略其他技術(shù)細(xì)節(jié)，只關(guān)注與Wide & Deep模型的實現(xiàn)。
Wide & Deep原理
首先我們來看下業(yè)內(nèi)的常用的模型的結(jié)構(gòu)圖：
這張圖源于論文，從左到右分別展示了Wide模型，Wide & Deep模型以及Deep模型。從圖上我們也看得出來所謂的Wide模型呢其實就是線性模型，Deep模型是深度神經(jīng)網(wǎng)絡(luò)模型。下面結(jié)合這張圖對這兩個部分做一個詳細(xì)一點的介紹。
Wide部分
Wide部分其實就是一個泛化的形如
的線性模型，就如上圖左邊部分所展示的一樣。y是我們要預(yù)測的結(jié)果，x是特征，它是一個d維的向量
。這里的d是特征的數(shù)量。同樣w也是一個d維的權(quán)重向量
，b呢則是偏移量。這些我們在之前線性回歸的模型當(dāng)中曾經(jīng)都介紹過，大家應(yīng)該也都不陌生。
特征包含兩個部分，一種是原始數(shù)據(jù)直接拿過來的數(shù)據(jù)，另外一種是我們經(jīng)過特征轉(zhuǎn)化之后得到的特征。最重要的一種特征轉(zhuǎn)化方式就是交叉組合，交叉組合可以定義成如下形式：
這里的是一個bool型的變量，表示的是第i個特征的第k種轉(zhuǎn)化函數(shù)的結(jié)果。由于使用的是乘積的形式，只有所有項都為真，最終的結(jié)果才是1，否則是0。比如"AND(gender=female,language=en)"這就是一個交叉特征，只有當(dāng)用戶的性別為女，并且使用的語言為英文同時成立，這個特征的結(jié)果才會是1。通過這種方式我們可以捕捉到特征之間的交互，以及為線性模型加入非線性的特征。
Deep部分
Deep部分是一個前饋神經(jīng)網(wǎng)絡(luò)，也就是上圖當(dāng)中的右側(cè)部分。
我們觀察一下這張圖會發(fā)現(xiàn)很多細(xì)節(jié)，比如它的輸入是一個sparse的feature，可以簡單理解成multihot的數(shù)組。這個輸入會在神經(jīng)網(wǎng)絡(luò)的第一層轉(zhuǎn)化成一個低維度的embedding，然后神經(jīng)網(wǎng)絡(luò)訓(xùn)練的是這個embedding。這個模塊主要是被設(shè)計用來處理一些類別特征，比如說item的類目，用戶的性別等等。
和傳統(tǒng)意義上的one-hot方法相比，embedding的方式用一個向量來表示一個離散型的變量，它的表達(dá)能力更強(qiáng)，并且這個向量的值是讓模型自己學(xué)習(xí)的，因此泛化能力也大大提升。這也是深度神經(jīng)網(wǎng)絡(luò)當(dāng)中常見的做法。
Wide & Deep合并
Wide部分和Deep部分都有了之后，通過加權(quán)的方式合并在一起。這也就是上圖當(dāng)中的中間部分。
最上層輸出之前其實是一個sigmoid層或者是一個linear層，就是一個簡單的線性累加。英文叫做joint，paper當(dāng)中還列舉了joint和ensemble的區(qū)別，對于ensemble模型來說，它的每一個部分是獨立訓(xùn)練的。而joint模型當(dāng)中的不同部分是聯(lián)合訓(xùn)練的。ensemble模型當(dāng)中的每一個部分的參數(shù)是互不影響的，但是對于joint模型而言，它當(dāng)中的參數(shù)是同時訓(xùn)練的。
這樣帶來的結(jié)果是，由于訓(xùn)練對于每個部分是分開的，所以每一個子模型的參數(shù)空間都很大，這樣才能獲得比較好的效果。而joint訓(xùn)練的方式則沒有這個問題，我們把線性部分和深度學(xué)習(xí)的部分分開，可以互補(bǔ)它們之間的缺陷，從而達(dá)到更好的效果，并且也不用人為地擴(kuò)大訓(xùn)練參數(shù)的數(shù)量。
系統(tǒng)實現(xiàn)
app推薦的數(shù)據(jù)流包含了三個部分：數(shù)據(jù)生產(chǎn)、模型訓(xùn)練以及模型服務(wù)。用一張圖來展示大概是這樣的：
數(shù)據(jù)生產(chǎn)
在數(shù)據(jù)生產(chǎn)的階段，我們使用app在用戶面前曝光一段時間作為一個樣本，如果這個app被用戶點擊安裝，那么這個樣本被標(biāo)記為1，否則標(biāo)記為0。這也是絕大多數(shù)推薦場景下的做法。
在這個階段，系統(tǒng)會去查表，把一些字符串類別的特征轉(zhuǎn)化成int型的id。比如娛樂類的對應(yīng)1，攝影類的對應(yīng)2，比如收費的對應(yīng)0，免費的對應(yīng)1等等。同時會把數(shù)字類型的特征做標(biāo)準(zhǔn)化處理，縮放到[0, 1]的范圍內(nèi)。
模型訓(xùn)練
paper當(dāng)中提供了一張模型的結(jié)構(gòu)圖：
從上圖當(dāng)中我們可以看到，左邊是一些連續(xù)性的特征，比如年齡，安裝的app數(shù)量等等，右邊是一些離散型的特征，比如設(shè)備信息，安裝過的app等等。這些離散型的特征都會被轉(zhuǎn)化成embedding，之后和右邊的連續(xù)性特征一起進(jìn)入神經(jīng)網(wǎng)絡(luò)進(jìn)行學(xué)習(xí)。paper當(dāng)中使用的是32維的embedding。
模型每次訓(xùn)練會使用超過500 billion的樣本數(shù)量進(jìn)行訓(xùn)練，每次搜集到了新的訓(xùn)練數(shù)據(jù)都會訓(xùn)練模型。但是如果每一次訓(xùn)練我們都從頭開始的話，顯然會非常緩慢，并且會浪費大量的計算資源。因此paper當(dāng)中選擇了一種增量更新的模式，也就是說在模型更新的時候，會加載舊模型的參數(shù)，再使用最新的數(shù)據(jù)進(jìn)行更新訓(xùn)練。在新模型更新上線之前，會先驗證模型的效果，確認(rèn)效果沒有問題之后再進(jìn)行更新。
模型服務(wù)
當(dāng)模型被訓(xùn)練好被加載進(jìn)來之后，對于每一個請求，服務(wù)器都會從recall系統(tǒng)當(dāng)中獲取一系列候選的app，以及用戶的特征。接著調(diào)用模型對每一個app進(jìn)行打分，獲取了分?jǐn)?shù)之后，服務(wù)器會對候選的app按照分?jǐn)?shù)從高到低進(jìn)行排序。
為了保證服務(wù)器的響應(yīng)能力，能夠在10ms時間內(nèi)返回結(jié)果，paper采取了多線程并發(fā)執(zhí)行的方法。老實講，我覺得這份數(shù)據(jù)有點虛。因為現(xiàn)在的模型沒有不使用并發(fā)執(zhí)行的，但即使是并發(fā)執(zhí)行，使用深度學(xué)習(xí)進(jìn)行預(yù)測也很難保證效率能夠到達(dá)這種程度。也許是還采用了其他的一些優(yōu)化，但是paper里沒有全寫出來。
模型結(jié)果
為了驗證Wide & Deep模型的效果，paper在真實的場景當(dāng)中從兩個角度進(jìn)行了大量的測試。包括app的獲取量以及服務(wù)的表現(xiàn)。
App 獲取量
在線上環(huán)境進(jìn)行了為期3周的A/B測試，1個桶作為對照桶，使用之前版本的線性模型。1個桶使用Wide & Deep模型，另外一個桶只使用Deep模型，去除了linear的部分。這三個桶各自占據(jù)了1%的流量，最后得到的結(jié)果如下：
Wide & Deep模型不僅AUC更高，并且線上APP的獲取量也提升了3.9%。
服務(wù)性能
對于推薦系統(tǒng)來說，服務(wù)端的性能一直是一個很大的問題，因為既需要承載大量的流量，也需要保證延遲非常短。而使用機(jī)器學(xué)習(xí)或者是深度學(xué)習(xí)模型來進(jìn)行CTR的預(yù)測，本身的復(fù)雜度是非常高的。根據(jù)paper當(dāng)中的說法，高峰時期，他們的服務(wù)器會承載1千萬的qps。
如果使用單線程來處理一個batch的數(shù)據(jù)需要31毫秒，為了提升速度，他們開發(fā)了多線程打分的機(jī)制，并且將一個batch拆分成了幾個部分進(jìn)行并發(fā)計算。通過這樣的方式，將客戶端的延遲降低到了14毫秒。
代碼實現(xiàn)
光說不練假把式，Wide & Deep在推薦領(lǐng)域一度表現(xiàn)不俗，并且模型的實現(xiàn)也不復(fù)雜。我曾經(jīng)使用Pytorch實現(xiàn)過一個簡易版本，貼出來拋磚引玉給大家做一個參考。
- 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)))
由于我當(dāng)時的應(yīng)用場景比較簡單，所以網(wǎng)絡(luò)結(jié)構(gòu)只有三層，但是原理是一樣的，如果要應(yīng)用在復(fù)雜的場景當(dāng)中，只需要增加特征以及網(wǎng)絡(luò)層次即可。
本文轉(zhuǎn)載自微信公眾號「TechFlow」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系TechFlow公眾號。
