個性化推薦系統，設計的巧妙就可以立竿見影地提升運營效率和使用者轉化率，尤其在內容分發、電商、社交等領域實踐相當出彩（微博、各新聞門戶、頭條、京東、探探等都取得了不錯的成績），個性化推薦已經成為一個產品的基礎建設。

　　本文從整體上介紹一個完整的推薦系統所需的模組（不深入到細枝末節），核心包括內容源、內容處理、使用者挖掘、演算法、推薦搜尋引擎、ABtest系統。本文將逐一介紹推薦架構的各個模組。

一、大量級可推薦內容，即推薦的SKU

　　個性化推薦的本質是提升資訊篩選的效率，如果資訊量級小個性化意義不大（比如一個視訊網站每天只能產生10條新聞，再怎麼個性化也只是在這10條內迴圈，對使用者來說沒有差別），個性化推薦的SKU至少是千級或萬級，而且理論上來說，優質內容越多、類別分佈越廣泛，個性化推薦效果越好。

　　這些內容可以是抓取的無版權內容、UGC、版權合作PGC等多種來源，由於來源不同，樣式和質量可能千差萬別，因此通常需要做內容抓取、清洗、轉碼等以保證樣式統一，還可能需要使用者管理體系、反垃圾等配合搭建內容生態。

　　個性化推薦系統各家可能是相近的，推薦的內容不同就產生了不同的使用者場景和產品壁壘。內容，本質是一種資源。

二、內容的標準化處理

　　第一步內容已備齊，接下來是把內容處理成機器和演算法可理解的特徵（比如分類、標籤、產品庫等）。具體怎麼處理要看業務需求，需要的技術：

　　如果是文章、新聞、微博等，就需要自然語言處理；

　　如果是圖片、視訊，就會涉及到影象識別和處理；

　　如果是歌曲、電影、商品等，機器直接理解內容來打標籤難度比較大，最好能建立一套使用者打標籤的機制，或者通過人工填寫或抓取的方式打標籤。

　　但不管什麼內容，首先都要建立一套自己的標籤體系，這是定義標準的過程，比如要給電影打標籤，先定義一下有多少種電影，通常標籤體系會是一個樹狀或網狀結構；其次可能都要收集大量訓練樣本，比如要實現給圖片打標籤，首先需要人工標註上萬張圖片，供機器學習，標註的樣本還要不斷更新，這裡面涉及到大量重複繁瑣的人力勞動。所以圈內人經常開玩笑說，“人工智慧”重點其實是“人工”。

三、使用者行為日誌收集、傳輸、挖掘、儲存

　　推薦的基礎是資料，前兩步挖掘了內容資料，第三步就是挖掘使用者行為生成使用者畫像。

1、採集：通常採用前端埋點的方式，上報使用者的點選、分享、收藏等等行為。

　　日誌採集是資料探勘非常重要的環節，如果採集有缺失或錯誤（很可能的事），那麼後續不管怎麼做都沒有效果，同時前端的改動也可能影響日誌，如果不有效協同，會對後端有很大影響。

2、傳輸：用於使用者興趣的收集，往往越快越好，這樣使用者的某個操作就能快速反饋到下一步推薦中，所以就需要日誌的穩定傳輸和更新。

　　但由於成本考慮，使用者 profile 不是都能實時更新的，有的可能延時1小時，有的可能1天1更、一週1更，甚至更久。

3、挖掘：這一過程是將使用者資料計算、挖掘處理成我們想要的特徵（俗稱“使用者畫像”，業內通常叫使用者profile）。

　　使用者挖掘通常要與演算法結合，而不能憑空挖特徵，沒有演算法應用再牛逼的使用者畫像也是沒有價值的。

4、儲存：使用者的興趣在一段時間內不會變化太大，因此可以用使用者長期留下的行為來積累使用者畫像，並需要把這些profile存起來。

　　如果使用者量很大，那麼需要的儲存資源也是海量的，那就需要一個能對大量資料進行分散式儲存的資料庫，並且需要可靠和廉價，例如 hdfs（Hadoop Distributed File System），如果想要實時計算使用者興趣，就需要可快速存取的資料庫比如redis，所以購買伺服器也是微博、今日頭條等公司很大的開支。

　　當然使用者的興趣不是一成不變的，因此使用者興趣需要隨時間“衰減”，設定合理的衰減係數，對使用者profile也很重要。

　　除此之外，使用者行為挖掘還有一個歷史性難題——使用者冷啟動，這個話題我們需要單起一篇文章探討。

四、排序演算法

　　前三步有了內容和使用者的資料，第四步可以用演算法對兩者做match了。

　　個性化推薦本質是在做 Top N ranking，通常包括“召回”和“排序”兩個模組。

　　舉個例子，如果我有10萬條資訊，但是使用者每天可能只能看10條，那麼推薦哪10條給使用者呢？我可以把這10萬條從1-10萬排個序，這樣使用者不管想看多少條，我只要從我排的10000個序裡從前往後挑就可以了，這個過程就是“排序”；但這種排法在實時索引中計算量太大，可能會帶來較高延時，那麼我們先用某種相對簡單的方法從這10萬中選相對靠譜的1000，再對這1000排序，10萬選10000的過程就是“召回”。

　　演算法方面門道很多，可以參看公眾號之前推送的文章，詳細介紹目前了推薦系統常用的、最有效的演算法。此外，不管什麼演算法都需要使用內容推薦之後的“動態指標”（比如ctr），但沒推薦之前我們如何獲得這個動態指標呢？這裡涉及到內容的冷啟動問題，也會之後單獨討論。

五、推薦搜尋引擎

　　怎麼還有搜尋引擎？是的，你沒看錯。實際上個性化推薦和搜尋是非常相似的領域，兩者都是資訊篩選方式，也都是在做一種“相關性”rank，目標函式都是很接近的（點選率）。只不過搜尋更注重使用者當下搜尋關鍵詞的相關性，而推薦更注重內容與使用者profile的相關性。

　　使用者每一次瀏覽都是一次實時請求，因此需要實時計算當下最符合使用者興趣的內容，這一步就是線上搜尋引擎承擔的。但由於效能要求，線上索引這步不宜做太耗時的計算，一般是排序演算法計算了初始結果，線上引擎做演算法排程和歸一化排序，此外線上索引還會承擔接收請求、輸出資料、曝光點選排重等服務，通常還會承擔業務和產品需求的二次排序（比如插入廣告、打散同類型內容等）。

六、ABtest 系統

　　ABtest 系統雖不是個性化推薦系統的必需模組，但沒有 ABtest 的推薦系統一定是個假的推薦系統！

　　推薦系統的優化實際上就是一個 y=f(x)，y是目標函式，首先目標函式一定要十分明確，且是可量化的指標；f(x)是選用的演算法、演算法特徵引數、演算法排程等等組成的，其實業界通過有效的演算法一直是那麼幾個，演算法原理也就是那麼幾個，但如何結合自己的產品場景選擇特徵、引數，就成了個性化推薦精準度的關鍵因素。

　　如果有 ABtest 系統，那麼我們可以嘗試帶入多種引數、特徵，ABtest 實驗得出最佳的 y，這樣推薦系統就可以不斷迭代、優化。

　　當然，演算法的優化不是改改引數這麼簡單，做推薦的人需要要對資料十分敏感，並能將複雜問題抽象到可量化的指標上，再結合ABtest實驗快速迭代。

　　我總結的演算法優化的過程是：“資料分析發現問題、合理假設、設計實驗、實現、資料分析、得出結論或新的假設”，不斷迴圈反覆。

　　其中改改引數只是“實現”那一步，也是最簡單的一步，而往往多數人只重視“實現”，卻對分析和假設的過程重視程度太低，這樣優化的效果是沒有保障的，還有些產品、技術人員會陷入盲目 ABtest 的誤區，漫無目的的嘗試，經常做 ABtest 發現 AB 組資料沒有任何差別，甚至產生了 ABtest 效率低的想法。這些分析思路便拉開了演算法工程師之間的差距。

　　總結：有了這 6 部分，一個完整的個性化推薦系統就已經搭建起來了，整個體系裡涉及到演算法工程師、自然語言處理/影象處理工程師、服務端工程師/架構師、資料探勘工程師、資料分析師、產品經理，還需要大量標註稽核人員、內容運營，此外還會涉及到前端、客戶端技術等的支援。因此想做一個好的個性化推薦系統耗費還是比較大的，但有時候我們並不需要一個系統，可能一些簡單的規則就可以實現相對個性化、提升使用者使用效率（比如把使用者最近瀏覽過的商品放在前面），因此提升效率的思維和方法才是最重要的，這也是我們需要長期探討的內容。

作者：末班車
連結：https://www.zhihu.com/question/309754511/answer/800030253