工業界完整推薦系統的設計。結論是： 沒有某種演算法能夠完全解決問題， 多重演算法+互動設計， 才能解決特定場景的需求。下文也對之前的一些博文進行梳理，構成一個完整工業界推薦系統所具有的方方面面（主要以百度關鍵詞搜尋推薦系統為例）

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

在學術界， 一般說到推薦引擎， 我們都是圍繞著某一種單獨的演算法的效果優化進行的， 例如按內容推薦， 協同過濾（包括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. 上下文相關推薦：和傳統推薦相比， 考慮更多上下文因素，LBS， 移動場景下使用比較多（具體參見博文：《context-aware-recommendation》）
3. 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服務中，有些海底撈的店點評評分較低， 但我們也應該往前排；或是在搜尋引擎中，搜國家領導人的名字， 有些最相關的結果可能因為法律因素是需要遮蔽的