Wide&Deep模型_推薦系統_原理
Wide&Deep for recommendation 這篇論文，主要是Google於2016年提出的推薦系統，並且當時應用於app推薦。
接下來會以三個大項來介紹這篇文章，分別為Introduction、Model、Experiment。
# Introduction: 包含推薦系統的介紹、Wide Model定義、Deep Model定義
# Model: 介紹Wide & Deep Model
# Experiment: 敘述Google 在app 所做的AB test並驗證結果
#Introduction
在這篇文章中，作者認為其實推薦系統可以說是一個檢索+排序系統，透過對推薦系統進行檢索，並找到分數(Ex: CTR or 點擊量)較高的物品推薦給使用者。而這個檢索+排序系統的input就是使用者的profile(Ex: 男女 or 年齡)，以及上下文資訊(物品特徵，Ex: 冒險動作)，並將這些資訊透過某些準則(Ex: CTR or 點擊量)進行排序，並將物品清單輸出。
這是一個Recommendation system的overview，當我們進入Google play ，頁面上會有推薦app清單，而這個清單就來自對推薦系統進行檢索。當對系統檢索時，會丟入用戶特徵、上下文等資訊進行檢索，並從DB中選出100個app透過wide and deep model進行預測CTR。預測完的CTR會排序丟給使用者，而這個過程必須於10ms完成。針對使用者是否有點擊或者profile、上下文資訊等，都會被記錄下來，並回丟給Model繼續學習。
首先，他模型發展的目標主要是希望解決檢索排序問題，並達到Memorization以及Generalization。
而Memorization主要的定義其實就是透過歷史資料進行學習，透過歷史曾經發生的關係，達到精準預測(將歷史資料發揮淋漓盡致)。Generalization主要的定義是希望透過這個模型找到新的特徵組合，而過去很少發生，因此此模型主要是增加預測結果的diversity。
此篇的寬模型，主要是使用GLM中的LR(經典的CTR預測模型)。優點是模型簡單、Scalable(Spark MLlib已經有開源，可直接call api)、可解釋性等優點。所以工程師可以專注於處理特徵，打造特徵海(寬的原因)。常使用One -hot encoding作為feature、且可使用一些無直接相關的特徵(Ex: 安裝app類別)。
此篇的深模型，主要是使用DNN，而他使用的方式先將大量高維度的矩陣先映射到Embedding layer，希望透過這個方式能找到一些隱藏特徵。這樣的模型有一個很大的優點就是減少工程師花在特徵工程的時間。缺點的部分就是因為將高維度映射到一個較低維度的Embedding layer，也就是說透過32維度來表示可能原來1萬維度的是否安裝什麼樣的app這個維度。致使一些資訊合併，讓某些item 或者niche item無法被預測。而這樣的Model常使用一些Cross product feature於推薦系統。
#Model
Wide Model主要是使用Logistic Regression，一般來說就是權重X特徵＋偏差，並丟入sigmoid function，最後就是預測是否的機率。在文章中，主要是使用cross product feature(Ex: 是否安裝app以及接下來點擊什麼樣的app)，與前面wide model的任務呼應，就是希望找出新的產品組合，此外就是增加一些非線性。
其中LR的optimizer跟過去不一樣，過去都是使用SGD，而在Wide Model他是使用2013 Google在KDD上發表的文章(FTRL更早就有被發表)，FTRL主要是對gradient進行微調，在Wt+1 step中，對第一步跟當下算出來的weight進行minnium，也就是說希望新的解跟當下算出來的解不要差太遠，讓gradient步伐小一點。此外他也要加入L1 regularization，讓找出的解稀疏一點。
Deep Neural Network，跟過去的類神經很相似，只是將其中的hidden layer不斷疊深。feature的部分，此篇主要使用numeric or one-hot encoding的feature。
過去DNN使用的activation function，主要為sigmoid function ，而sigmoid function最大的問題就是會有gradient vanishing，因為當我們的gradient算出來例如：10000，但放入sigmoid function，他會被壓縮，最大值頂多就是1，許多gradient vanishing。因此，當我每進一次sigmoid function，gradient就會衰減一次。很可能最後訓練出來的結果會在local min就停下來，因為gradient太小趨近於0。
文章中，DNN使用的optimizer是adagrad，他主要概念為所有權重應該要有不同的learning rate。從公式可知，在graident大的時候走慢一點(變化很大)，gradient小的時候走快一點(變化不大)。
此篇最重要的概念之一就是他的權重是同時更新，而不是像是ensemble一樣各自學習，然後投票出最後的結果。
在整個app recommendation pipeline，它分為三大項，Data Generate, Model train 以及 Model serving。Data Generate的部分主要是做資料前處理，像是one — hot encoding , 字串轉換以及離散化。Model train的部分就是他會做online learning，只要有新的資料進來，他就會將過去的權重拿出來，繼續學習微調權重。Model serving的部分是希望能在10ms去做response，因此他們使用multithreading 以及batch設定進行加速。
#Experiment
最後Google有在google play上實做測試，並使用A/B test進行模型驗證。可發現offline 的auc測出來結果並沒有太大差異。但在線上的收益卻是有較大的成長。而他們認為線上測試，可以隨時有新的資料組合產生，進而去學習。
因此，對於推薦系統的測試，其實應該不只是AUC的測試，更應該納入更多的考量項目(Ex: 營收 or 新使用者增加的數量)
Google有將他們的模型release到 Tensorflow並變成api，供大家使用
Ref:
