推薦系統架構（轉）

1、推薦系統目標和推薦方式

　　推薦系統目標主要包括： 

• 用戶滿意性：首當其衝的，推薦系統主要就是爲了知足用戶的需求，所以準確率是評判一個推薦系統好壞的最關鍵指標。
• 多樣性：雖然推薦系統最主要仍是知足用戶的興趣，可是也要兼顧內容的多樣性，對於權重不一樣的興趣都要作到兼顧。
• 新穎性：用戶看到的內容是那些他們以前沒有據說過的物品。簡單的作法就是在推薦列表去掉用戶以前有過行爲的那些內容。
• 驚喜度：和新穎性相似，但新穎性只是用戶沒看到過的可是確實是和他行爲是相關的，而驚喜度是用戶既沒有看過和他以前的行爲也不相關，但用戶看到後的確是喜歡的。
• 實時性：推薦系統要根據用戶的上下文來實時更新推薦內容，用戶的興趣也是隨着時間而改變的，須要實時更新。
• 推薦透明度：對於用戶看到的最終結果，要讓用戶知道推薦此內容的緣由。好比，「買過這本書的人同時也買過」、」你購買過的xx和此商品相似」。
• 覆蓋率：挖掘長尾內容也是推薦系統很重要的目標。所以，推薦的內容覆蓋到的內容越多越好。

　　基於這些目標，推薦系統包括四種推薦方式：

• 熱門推薦：就是熱門排行榜的概念。這種推薦方式不只僅在IT系統，在日常的生活中也是到處存在的。這應該是效果最好的一種推薦方式，畢竟熱門推薦的物品都是位於曝光量比較高的位置的。
• 人工推薦：人工干預的推薦內容。相比於依賴熱門和算法來進行推薦。一些熱點時事如世界盃、nba總決賽等就須要人工加入推薦列表。另外一方面，熱點新聞帶來的推薦效果也是很高的。
• 相關推薦：相關推薦有點相似於關聯規則的個性化推薦，就是在你閱讀一個內容的時候，會提示你閱讀與此相關的內容。
• 個性化推薦：基於用戶的歷史行爲作出的內容推薦。也是本文主要講述的內容。

　　其中，前三者是和機器學習沒有任何關係的，但倒是推薦效果最好的三種方式。通常說來，這部份內容應該佔到總的推薦內容的80%左右，另外20%則是對長尾內容的個性化推薦。

2、推薦系統架構

　　　　　　　  

 

online部分架構

　　　 　　

　　核心模塊

• 業務網關，推薦服務的入口，負責推薦請求的合法性檢查，組裝請求響應的結果。

• 推薦引擎，推薦系統核心，包括online邏輯，召回、過濾、特徵計算、排序、 多樣化等處理過程。

　　數據路徑

　　一、請求的刷新從gateway，通過流量分配模塊，傳到業務gateway，業務gateway支持http，tcp（使用thirtf協議或者protobuf 協議）等多種類型接口；

　　二、用戶行爲數據，從gateway到Flume agent，而後到kafka，爲後面online，realtime userprofile部分的提供實時數據，也爲offline部分的數據存儲系統提供數據。

　　流量分配

　　這部分包括流量分配和ABTest兩個模塊，流量分配模塊主要是根據需求來動態進行流量的分配，須要作到線上實時修改實時響應；ABTest是爲Web和App的頁面或流程設計兩個版本（A/B）或多個版本（A/B/n），同時隨機的分別讓必定比例的客戶訪問，而後經過統計學方法進行分析，比較各版本對於給定目標的轉化效果。大家可能以爲這兩個模塊功能有些冗餘，其實並不是如此，有一些單純營運的需求是不須要進ABTest的。以視頻推薦爲例解釋一下 這個問題，假設營運有這樣的需求：「他們根據數據發現，iOS用戶觀看視頻更喜歡購買會員進行免除廣告，Andriod用戶更傾向於觀看網劇」（固然這只是一種假設），因此iOS在進行流量分配的時候會把付費視頻比例提升，而Andriod會把原創網劇比例提升。而後新的一種算法或者UI但願知道是否會表現更好，這種狀況就須要進行ABTest了，對照組和實驗組裏面iOS和Android都是包含的。

　　推薦引擎

　　推薦引擎主要就包括，gateway，recall（match），ranking，其中reall主要offline經過各類算法，最經典的就是基於用戶行爲的矩陣分解，包括itemCF、userCF、ALS，還有基於深度學習的wise&&deep等方法，後面講offline的時候會着重說各類算法如何使用和適合的場景。

　　如今咱們就默認爲，各類算法已經訓練完畢，而後會生成一些二進制文件，以下圖，這些就是offline算法收斂後的權重向量結果

　　　　　　

　　文件格式都是二進制，打開咱們也看不懂，這裏就不打開了，若是有人好奇能夠私信我。這些產生後，如何到線上使用呢？用最土的辦法，經過腳本天天定時cp到線上的server。也能夠經過sql或者nosql數據庫等方法，可是這個文件通常比較大，圖裏展現的只是我其中一個實驗，日活大約百萬級用戶的訓練結果數據，若是後面用戶更多，item更豐富這個文件也就越大，使用數據庫是否是好方式有待商榷。

gateway

　　這個模塊只要負責用戶請求的處理，主要功能包括請求參數檢查，參數解析，結果組裝返回。gateway業務比較輕量級，其中只有一個問題就是「假曝光」，假曝光是相對真曝光而言的，真曝光是指推送給用戶的內容且用戶看到了，假曝光就是指，推送給用戶，可是未向用戶展現的內容。推薦系統爲了不重複推薦，因此基於UUID存儲推薦歷史，存儲時間是幾小時，或者1天，再或幾天，這個須要根據各自的業務狀況，也要考慮資源庫的大小。假曝光的處理能夠在gateway中，把推送的message_id在gateway寫入到nosql中，而後根據真曝光數據在離線pipeline中能夠獲取到，在離線pipeline定時運行時把假曝光的message_id的數據歸還到recall隊列中。

recall

　　用戶請求到recall引擎後，會根據用戶行爲和相關配置，啓動不一樣的召回器，下發召回任務，用戶行爲只要是看是否爲新用戶進冷啓動，相關配置可能就是地區，國家等差別。用戶的userprofile若是少於幾個行爲，通常建議爲5-10個點擊行爲，少於這個標準屬於冷啓動用戶，那麼在recall manager的隊列裏只有冷啓動召回器和熱門召回器。熱門召回器是爲了保證推薦內容的熱門度，而冷啓動召回器是保證推薦結果的新鮮度。recall引擎還要負責任務分配，根據推薦場景，按召回源進行任務拆分，關鍵是讓分佈式任務到達負載均衡。

　　在各個召回器返回後recall manager收集返回結果，也就是各個召回器的返回的message_id的倒排隊列，而後再進行一次總體的ranking。

　　　　　　　　

　　下面再展開介紹一下召回器內部框架

 　　　　　　　　

• 召回階段，獲取候選集，通常從基於用戶畫像、用戶偏好、熱門label等維度進行召回，若是是用戶畫像中點擊少於10個會使用冷啓動服務進行召回；

• 過濾階段，基於人工規則，和政策規則，避免涉黃，避免政治明感等內容，例如最近的未成年孕婦等進行過濾，總之計算保留合法的，合乎運營須要的結果；

• 特徵計算階段，結合用戶實時行爲、用戶畫像、知識圖譜，計算出召回的候選集的特徵向量；

• 排序階段，使用算法模型對召回候選集進行粗排序，由於通常用戶請求10條數據，召回樣本大概在200-400個因此在召回器的排序內會進行序列從新調整，而後整體ranking時會選取粗排序的前100或前200結果，並不是召回結果都是用，避免沒必要要的計算，增長響應時間。

　　在召回、排序階段都是基於message_id，並無包含文章內容或是視頻信息，這些內容會在ranking後，在detial服務中對推薦的返回結果的進行拼裝，detail服務後還會有一層對總體結果的調整服務即tuner。

　　offline部分架構

　　本文從大框架上介紹推薦系統架構，在許多公司面試中會給你一個推薦或者數據挖掘的問題，好比讓你簡單設計一個feed流推薦系統，因此須要對推薦系統的總體框架要了解。下面是一個推薦系統的主要部分

 　　        

　　從框架的角度看，推薦系統基本能夠分爲數據層、召回層、排序層。

　　數據層包括數據生成和數據存儲，主要是利用各類數據處理工具對原始日誌進行清洗，處理成格式化的數據，落地到不一樣類型的存儲系統中，供下游的算法和模型使用。

• sessionlog：對原始數據進行清洗合併，sessionlog通常就是清洗合併後的數據，後續的算法和統計都是根據sessionlog進行再加工。
• userprofile：對用戶屬性和行爲等信息進行採集和統計，爲後續算法提供特徵支持。
• itemDoc：對視頻、商品等屬性、曝光、點擊等字段進行統計， 爲後續算法提供特徵支持。

　　召回層主要是從用戶的歷史行爲、實時行爲等角度利用各類觸發策略產生推薦的候選集，對不一樣的策略和算法產生的候選集進行融合並按照產品規則進行過濾，通常融合和過濾後的候選集仍是比較多的，一次線上請求過來以後線上系統沒法對那麼多的候選集進行排序，因此在召回層通常還會有粗排序，對融合的候選集進行一次粗排序，過濾掉粗排分數較低的候選集。

　　排序層主要是利用機器學習的模型對召回層篩選出來的候選集進行精排序。

數據特徵

　　數據決定了特徵，特徵決定了效果的上限，模型決定了接近效果上限的程度。

行爲類別	行爲表現
用戶主動行爲	點擊、分享、評分
用戶畫像	用戶屬性（性別、年齡、收入）、視頻分類興趣分佈、地域、時間
負反饋	負評

1. 用戶主動行爲數據記錄了用戶在平臺的的各類行爲，這些行爲一方面用於候選集觸發算法中的離線計算（主要是瀏覽、下單），另一方面，這些行爲表明的意圖的強弱不一樣，所以在訓練重排序模型時能夠針對不一樣的行爲設定不一樣的迴歸目標值，以更細地刻畫用戶的行爲強弱程度。此外，用戶對deal的這些行爲還能夠做爲重排序模型的交叉特徵，用於模型的離線訓練和在線預測。
2. 負反饋數據反映了當前的結果可能在某些方面不能知足用戶的需求，所以在後續的候選集觸發過程當中須要考慮對特定的因素進行過濾或者降權，下降負面因素再次出現的概率，提升用戶體驗；同時在重排序的模型訓練中，負反饋數據能夠做爲不可多得的負例參與模型訓練，這些負例要比那些展現後未點擊、未下單的樣本顯著的多。
3. 用戶畫像是刻畫用戶屬性的基礎數據，其中有些是直接獲取的原始數據，有些是通過挖掘的二次加工數據，好比用戶的聚類和向量化，這些屬性一方面能夠用於候選集觸發過程當中對deal進行加權或降權，另一方面能夠做爲重排序模型中的用戶維度特徵。

召回層（ReCall）

協同過濾

　　協同過濾（Collaborative Filtering）可說是推薦系統裏資歷最老最經典的一種算法了，如 userCF、itemCF。原理是基於用戶對內容的行爲協同，爲某一用戶沒有看過的某條內容做出點擊預測。實現方法有不少種，如傳統的 Memory-based 方法、基於矩陣分解的方法（LFM/SVD/SDV++）、基於 DNN 的方法。

　　Memory-based 方法很簡單，是基於統計的一種算法。以 item-based CF 舉例：

　　　　　　　　 

　　根據用戶點擊行爲，咱們能夠統計出 item-item 的共現矩陣（矩陣單元內爲 item i 與 item j 共同被用戶點擊的次數），再依此經過Jaccard類似度/餘弦類似度/歐氏距離得出 item 類似度矩陣，最後根據用戶的點擊記錄檢索出 topK 類似的內容推薦給用戶。在計算過程當中須要考慮一些因素，好比熱門物品對類似度計算的影響、不一樣傾向的用戶的影響等等。

　　然而 Memory-based 方法不能解決的問題是，當咱們的矩陣很稀疏時，大多數 item 和 item 之間是沒有關聯的（類似度爲0），這也就形成最後咱們召回的內容覆蓋率很低，也許大多集中在頭部內容。因而基於矩陣分解的方法誕生了。

MF（Matrix Factorization）的原理是將一個高維稀疏矩陣分解成兩個低秩矩陣，其中 k 被稱爲隱向量維度。在原始的稀疏矩陣 R 中，大部分二階特徵的關係係數是缺失的。而經過訓練模型最小化 R 和預測矩陣 R‘ 的損失（如最小二乘），能夠求出任意 Ri,j 的值。

　　　　

　　MF 可說是大部分推薦系統裏協同過濾的標杆方法了，但仍然存在一些問題。好比過於稀疏的矩陣對於最後評分的預測依然有很大影響，而且當用戶特徵或者內容特徵缺失（即冷啓動）時，沒法進行合理的預測。此時，基於深度學習的一些嘗試開始了。如基於DNN實現，能夠很輕易地將內容的一些語義特徵，以及用戶的固有屬性與行爲特徵拼接在一塊兒做爲神經網絡輸入來訓練，能夠在以前行爲協同的前提下加入對內容特徵的學習，從而解決冷啓動問題。

基於內容的召回

　　主要是以以前 NLP 獲得的內容畫像爲基礎，以item 對應分類/主題/關鍵詞的權重創建召回，依據用戶畫像的相應權重和內容畫像的距離排序召回。

　　基於用戶羣

　　首先咱們須要對用戶分羣，聚類的方案有不少，

　　　　一、對item進行向量化（w2v）而後對item進行聚類，用戶對item的行爲就能夠把item的簇賦值到user身上。

　　　　二、直接對用戶進行向量化，好比降維。

　　總之最終的目的就是將用戶embedding成一個向量，而後在對用戶向量進行聚類，通常k-means就能夠勝任大部分的場景。

倒排鏈

　　tag-itemList，對每一個用戶的tag進行遍歷，而後經過倒排鏈快速找到含有該tag的itemList而後topN抽取。

子策略融合

　　爲告終合不一樣觸發算法的優勢，同時提升候選集的多樣性和覆蓋率，須要將不一樣的觸發算法融合在一塊兒。常見的融合的方法有如下幾種：

• • 加權型：最簡單的融合方法就是根據經驗值對不一樣算法賦給不一樣的權重，對各個算法產生的候選集按照給定的權重進行加權，而後再按照權重排序。
  • 分級型：優先採用效果好的算法，當產生的候選集大小不足以知足目標值時，再使用效果次好的算法，依此類推。
  • 調製型：不一樣的算法按照不一樣的比例產生必定量的候選集，而後疊加產生最終總的候選集。
  • 過濾型：當前的算法對前一級算法產生的候選集進行過濾，依此類推，候選集被逐級過濾，最終產生一個小而精的候選集合。

　　目前咱們使用的方法集成了調製和分級兩種融合方法，不一樣的算法根據歷史效果表現給定不一樣的候選集構成比例，同時優先採用效果好的算法觸發，若是候選集不夠大，再採用效果次之的算法觸發，依此類推。

模型排序（Ranking）

       如上所述，對於不一樣算法觸發出來的候選集，只是根據算法的歷史效果決定算法產生的item的位置顯得有些簡單粗暴，同時，在每一個算法的內部，不一樣item的順序也只是簡單的由一個或者幾個因素決定，這些排序的方法只能用於第一步的初選過程，最終的排序結果須要藉助機器學習的方法，使用相關的排序模型，綜合多方面的因素來肯定。

一、模型選擇和比較　　

　　非線性模型能較好的捕捉特徵中的非線性關係，但訓練和預測的代價相對線性模型要高一些，這也致使了非線性模型的更新週期相對要長。反之，線性模型對特徵的處理要求比較高，須要憑藉領域知識和經驗人工對特徵作一些先期處理，但由於線性模型簡單，在訓練和預測時效率較高。所以在更新週期上也能夠作的更短，還能夠結合業務作一些在線學習的嘗試。在咱們的實踐中，非線性模型和線性模型都有應用。

非線性模型　　

       目前咱們主要採用了非線性的樹模型gbdt，相對於線性模型，非線性模型能夠更好的處理特徵中的非線性關係，沒必要像線性模型那樣在特徵處理和特徵組合上花費比較大的精力。gbdt是一個加性模型，由不少個樹組成，後面的樹不斷擬合前一顆樹的殘差，並且每個樹帶入的都是全訓練集，由此能夠減少過擬合的影響。

　　　　　　

線性模型

　　目前應用比較多的線性模型非Logistic Regression莫屬了。爲了能實時捕捉數據分佈的變化，咱們引入了online learning，接入實時數據流，使用google提出的FTRL[5]方法對模型進行在線更新。後續也會單獨寫一篇FTRL的應用、特徵、落地、面試問點等細節。

　　　　　　

主要的步驟以下：

• 在線寫特徵向量到HBase
• Storm解析實時點擊和曝光日誌流，改寫HBase中對應特徵向量的label
• 經過FTRL更新模型權重
• 將新的模型參數應用於線上

2. 數據

• 採樣：對於點擊率預估而言，正負樣本嚴重不均衡，因此須要對負例作一些採樣。 
• 負例：正例通常是用戶產生點擊、下載、分享等轉換行爲的樣本，可是用戶沒有轉換行爲的樣本是否就必定是負例呢？其實否則，不少展示其實用戶根本沒有看到，因此把這樣樣本視爲負例是不合理的，也會影響模型的效果。比較經常使用的方法是skip-above，即用戶點擊的item位置以上的展示纔可能視做負例。固然，上面的負例都是隱式的負反饋數據，除此以外，咱們還有用戶主動刪除的顯示負反饋數據，這些數據是高質量的負例。
• 去噪：對於數據中混雜的刷單等類做弊行爲的數據，要將其排除出訓練數據，不然會直接影響模型的效果。

3. 特徵

　　在目前的重排序模型中，大概分爲如下幾類特徵：

• item維度的特徵：主要是item自己的一些屬性，包括category、pv、ctr、sub-category、tag等
• user維度的特徵：包括用戶等級、用戶的人口屬性、用戶的客戶端類型等
• user、deal的交叉特徵：包括用戶對item的category的點擊、收藏等

　　對於非線性模型，上述特徵能夠直接使用；而對於線性模型，則須要對特徵值作一些分桶、歸一化等處理，使特徵值成爲0~1之間的連續值或01二值。