一個完整推薦系統的設計實現-以百度關鍵詞搜索推薦爲例

本文轉自http://semocean.com

在以前一篇博文中， 有同窗在評論中問了個問題： 如何解決因式分解帶來的推薦冷門，熱門關鍵詞的問題。 在回答這個問題的時候， 想到了近幾年在作搜索推薦系統的過程當中， 學術界和工業界的一些區別。 正好最近正在作技術規劃， 因而寫偏文章說下工業界完整推薦系統的設計。結論是： 沒有某種算法可以徹底解決問題， 多重算法+交互設計， 才能解決特定場景的需求。下文也對以前的一些博文進行梳理，構成一個完整工業界推薦系統所具備的方方面面（主要以百度關鍵詞搜索推薦系統爲例）

完整的推薦系統確定不會只用一種推薦算法

在學術界， 通常說到推薦引擎， 咱們都是圍繞着某一種單獨的算法的效果優化進行的， 例如按內容推薦， 協同過濾（包括item-based, user-based, SVD分解等），上下文推薦，Constraint-based推薦，圖關係挖掘等。 不少比較牛的單個算法， 就能在某個指標上取得較好效果， 例如MAE，RMSE。。。不過有本身的優勢， 每種算法也有本身的缺點， 例如按內容推薦主要推薦和用戶歷史結果類似的item，通常的item-based容易推薦熱門item（被更多人投票過）。。。。   因此在工業界，例如各互聯網公司， 都會使用多種算法進行互相配合， 取長補短， 配合產品提高效果。並且在完整的推薦系統中，不只有傳統的Rating推薦， 還須要輔以很是多的挖掘， Ranking來達到預期效果。

推薦系統3大件：User Profile、基礎挖掘推薦、Ranking

在實踐中， 一個完整的推薦系統會主要由3部分組成：

1. User Profile
2. 基礎推薦挖掘算法
3. Ranking

如下爲整個推薦的數據流： 

User Profile

A user profile is a representation of information about an individual user that is essential for the (intelligent) application we are considering user profile主要是用戶（註冊）信息，以及對用戶反饋的信息進行處理，聚合，用於描述用戶的特徵； 是後續推薦和排序的基石。 通常狀況下，user profile會包含如下具體內容：

1. 用戶興趣數據
2. 用戶的基礎註冊信息，背景信息：例如用戶出生地，年齡，性別，星座，職業等。這些信息通常從用戶註冊信息中獲取；例如高德，百度地圖註冊用戶，淘寶註冊用戶等
3. 用戶行爲反饋：包括顯示的反饋(explicit)和隱藏(implicit)的反饋，顯示的反饋包括用戶的評分，點贊等操做，百度關鍵詞搜索推薦工具上的點贊（正向顯示反饋）和垃圾桶（負向顯示反饋），淘寶上的評分；隱式反饋包括用戶的瀏覽行爲，例如在百度關鍵詞搜索推薦上搜過那些詞，淘寶上點擊了那些頁面，在高德上點擊了那些POI等
4. 用戶交互偏好：例如用戶喜歡使用哪些入口，喜歡哪些操做，以及從這些操做中分析出來的偏好，好比在高德地圖上根據用戶行爲反饋分析出來的用戶對美食的偏好：更喜歡火鍋，粵菜，仍是快餐
5. 用戶上下文信息：這些信息有些是分析出來的，例如在LBS中分析出來的用戶的家在哪兒，公司在哪兒，常常活動的商圈，常用的路線等

user profile常常是一份維護好的數據，在使用的時候，會直接使用該數據，或是將該數據存儲在KV系統中，供Online系統實時使用。 在搜索或是推薦的場景下，每次請求通常只會涉及到一次user profile的KV請求，因此online使用的時候，主要的實現困難是存儲，以及快速KV的快速響應。

基礎挖掘推薦算法

基礎挖掘推薦算法， 主要使用傳統推薦算法， 結合分析的item profile和user profile， 創建user和item的關係，此時並不會過多考慮其餘因素，例如是否冷門/熱門，最主要的就是創建user和item的關係。 在各類論文中狹義的推薦，主要就是指該部份內容。 主要圍繞着Rating，以及Top N進行該處的Top N（更像是直接Rating值最高的Top N） 傳統的推薦算法研究主要圍着這塊工做進行，如今已經有不少比較成熟的算法，這些算法相關的研究可參見博文：《推薦系統經典論文文獻及資料》；其中也能找到業界較多成功推薦系統的實踐分享 主要包含如下幾類：

1. Content Based推薦： 按內容推薦，主要的工做是user profile, item profile的提取和維護，而後研究各類類似度度量方法（具體類似度度量參見博文：《推薦系統中的類似度度量》）
2. 協同過濾：至關於應用了用戶的行爲進行推薦（區別於Content based算法），比較經典的算法包括傳統的item-based/user-based算法（參見博文：《協同過濾中item-based與user-based選擇依據》，《collaborative-filtering根據近鄰推薦時須要考慮的3要素》），SVD，SVD++(具體原理及源碼參見博文：《SVD因式分解實現協同過濾-及源碼實現》)
3. 上下文相關推薦：和傳統推薦相比， 考慮更多上下文因素，LBS， 移動場景下使用比較多（具體參見博文：《context-aware-recommendation》）
4. 基於圖的關係挖掘推薦：主要是利用圖論原理，根據item,user之間的數據，反饋關聯關係，挖掘更深層次的關係進行推薦，該類方法通常效果都不錯，固然資源要求也較高。具體參見博文：《級聯二步圖關係挖掘關鍵詞推薦系統》，《頻繁二項集合的hadoop實現》《itemrankrandom-walk-based-scoring-algorithm-for-recommener-system》
5. Constrainted-based推薦：根據限制性條件進行演繹推薦

在實際應用時，咱們常用按內容推薦，item-based尋找從感知的角度比較靠譜的結果，使用SVD,SVD++，圖關係尋找更深層次的聯繫結果。同時在推薦時，會結合不少因素來進行綜合排序，例如關鍵詞， 或是LBS中POI的熱度等。具體可參見下文ranking部分。

算法效果衡量

以上這些算法， 咱們在離線的時候，使用Cross-Validation方式，就能夠分析出其效果，並且離線分析的時候，代價比較小，比較容易操做。固然，對於不一樣的問題會使用對應的指標進行衡量。 對於預測Rating準確性主要是用RMSE，或是MAE；具體可參見博文：《關鍵詞搜索推薦系統中的推薦準確性度量》 若是是排序， 則更多使用NDCG，MAP,  MRR等指標；具體可參見博文：《使用ndcg評估關鍵詞推薦系統的相關性》 在具體應用場景中，對於特定推薦問題，會涉及到選用哪一種算法的問題。推薦不像CTR預估這樣的問題，目標比較單一，常常咱們須要考慮多個指標，並且這些指標可能此消彼長，須要作權衡，例如須要考慮算法的準確性(accuracy)，同時也須要考慮算法的覆蓋(coverage)，置信度（confidence）,新鮮度(novelty)和驚喜度(Serendipity)，同時還須要考慮推薦爲系統帶來的收益和效用(utility)。 這些指標常常須要權衡，並且常常提高某一個的時候會致使其它降低，因此有時候存在必定的主觀性：咱們到底看中哪個指標？  並且這個問題可能隨着系統，平臺所處的階段而不一樣。 例如在創建口碑的時候，咱們可能不太關注coverage，而更關注accuracy，由於要讓用戶創建一種：該系統很準的認知；若是在系統已經比較成熟了，此時可能須要考慮novelty, serendipity的同時，還須要考慮utility：該推薦能爲系統帶來什麼收益，例如對百度的變現有多大收益？ 對淘寶的銷售有多少收益等 具體這些指標的選擇可參見博文：《選擇推薦算法時須要考慮得因素》

Ranking，此部分是成熟的搜索，推薦系統具備的核心邏輯

比較簡單的實現方法， 是直接對各類特徵拍閾值進行線性加權，比較成熟的系統通常會使用機器學習的方式和綜合個維特徵， 學習出模型後進行排序， 例如使用Learning to rank技術。 該部分須要考慮的因素較多較爲複雜。 和傳統的推薦相比， 此處單獨將Ranking拿出來。 基礎推薦挖掘， 和傳統的推薦部分比較相似，主要結合user profile， 挖掘哪些item適合推給哪些user。 但僅根據這些挖掘就直接進行推薦是不夠的。 真實online推薦場景中， 須要考慮更多其餘因素， 例如：相關性，推薦的上下文，CTR預估，以及商業業務規則。

1. 相關性： item與用戶的相關性，這是大多數搜索和推薦任務的基石，例如在搜索中斷定一個query和一個document的相關性，或是一個query 和 另外一個query的相關性，或是在特徵比較多的狀況下， 一個user 和一個item 記錄的相關性；實現方式能夠很簡單，例如傳統的類似度度量方式（參見博文：《推薦系統中的類似度度量》），對於文本，業界使用簡單的TF*IDF，或是BM25； 不過不少時候咱們須要增長更多維度特徵，包括推薦item自己的重要性，例如IDF，Pagerank(具體參見博文：《pagerank的經濟學效用解釋》)，同時使用模型來提高相關性判斷的準確性。使用模型的方式會更加複雜，但效果提高也很是明顯。具體可參見博文：《集成樹類模型及其在搜索推薦系統中的應用》，《分類模型在關鍵詞推薦系統中的應用》，《adaboost》
2. 推薦的上下文：例如推薦產品的入口，交互方式， 不一樣的入口，甚至同一入口的不一樣交互方式， 推薦的結果有可能都須要不同； 在LBS生活服務中， 請求發生的時間， 地點也是推薦須要重點考慮的上下文因素，例如飯點對餐飲item的提權； 異地狀況下對酒店等結果的加權等
3. CTR預估：成熟的商業系統都會使用模型來完成CTR預估，或是轉化預估
4. 以及商業業務規則：例如黑白名單，或者強制調權。例如在百度關鍵詞搜索推薦中，某些有比較高變現潛力的詞， 就應該加權往前排； 好比在高德LBS服務中，有些海底撈的店點評評分較低， 但咱們也應該往前排；或是在搜索引擎中，搜國家領導人的名字， 有些最相關的結果可能由於法律因素是須要屏蔽的

算法評估

很直接，離線調研的時候看就看算法的評估指標，參見博文：《關鍵詞搜索推薦系統中的推薦準確性度量》，《使用ndcg評估關鍵詞推薦系統的相關性》 上線的時候，進行圈用戶（圈定某兩個user集合做爲實驗/對照用戶組）實驗， 或者圈請求實驗（例如隨機圈定5%流量進行實驗），以後根據系統效果監控中的指標值判斷實驗效果。如下爲一個典型的效果監控截圖： 實驗若是證實成功，達到預期效果，通常以後推廣到全流量；反之，若是實驗未達到預期效果，則須要分析什麼地方有問題，如何改進，以後繼續調整算法繼續實驗。當實驗較多時，還會涉及較多工程問題，例如分層實驗框架等。

系統效果監控

對於整個系統，須要創建晚上的效果監控平臺進行效果的實時監控，以便發現用戶的行爲模型，系統的不足，分析後續的發力點等。通常這樣的監控平臺會使用Dashboard來完成，基本的框架是前段UI + 後端數據庫。不少時候，離線統計策略在hadoop上處理統計日誌計算指標，並將計算出來的指標存入數據庫，前端UI訪問數據庫，拉出指定時間段內某些指標的值，並進行簡單分析。 具體的監控指標，及指標體系的創建，可參見博文：《搜索引擎變現策略指標體系》

交互設計

完整的產品包括便捷的交互和背後牛叉的算法。不少時候，要提高推薦的效果，須要算法和交互配合，才能達到理想的效果： 交互須要有健壯的算法產出結果；而算法也須要有配套的交互，才能達到預期效果，不然再牛叉的算法，對結果的影響也可能沒那麼明顯。

一些交互的例子參見博文：

《關鍵詞推薦工具中的用戶引導機制之一：總述》

《關鍵詞推薦工具中的用戶引導機制之二：suggestion架構》

《關鍵詞推薦工具中的用戶引導機制之三：相關搜索query技術》

《關鍵詞推薦工具中的用戶引導機制之四：種子query推薦》

 

說了那麼多，中心就是想說明， 一個完整的推薦系統，遠遠不止是一兩個rating算法可以覆蓋的，並且此處還未涉及工程部分。

 

更多內容，也可直接訪問： http://semocean.com