百分點億級個性化推薦系統的發展歷程和實踐架構

百分點個性化系統開始于2009年，是百分點公司的第一個產品，也是一直延續至今的產品。個性化系統以電商推薦為切入點，涵蓋電商、媒體、閱讀、應用市場等領域，以第三方技術服務的形式為企業提供個性化推薦服務。

個性化系統的幾個重要特性

百分點個性化系統致力于解決電商個性化的問題。我們先來看一下“個性化”問題的定義：

對于如何定義個性化收益函數，一般有以下幾方面的考慮：

以KPI為導向：對于推薦效果考察的具體指標是什么？是點擊率還是轉化率，還是用戶客單價，等等這些指標可以確定我們推薦優化的目標。

根據業務需求定義：在實際推薦運營中，還會需要考慮商家的業務目標，比如追求高毛利，比如清庫存，這時就要提高高毛利商品和庫存商品的曝光率。

根據業務效果修正：推薦是一個長期運營的活，對于推薦產生的效果需要能及時反饋到推薦系統中，形成動態反饋和修正的機制。

連接現實業務和技術實現：推薦始終是服務于業務的，脫離了業務的推薦毫無意義，個性化系統就是要將業務需求轉化為技術實現，最大程度自動化和智能化。

在個性化系統中，還會面臨以下技術和業務的挑戰：

數據稀疏是推薦系統中常見的問題，我們采用引入一些新的召回機制如文本相似性等非行為相關的召回制補充用戶行為的不足。

冷啟動的問題，百分點本身可以匯集所有客戶的上的用戶行，一家新的客戶接進來后，一般有30%-40%的用戶是和百分點本身的用戶庫是重合的，對于全新的用戶，可以在第一次著陸到首頁采用一些大眾化的推薦，當用戶有進一步的行為便可以根據行為進行新的推薦了。我們大部分的算法都是實時處理的，所以真正冷啟動的比例很小。

大數據處理與增量計算，百分點大概有5000萬的日活，1.5億的pv，每天的推薦次數近2億次，每天約1T的數據增量，對于所有組件必須能處理大量的數據，所以整體的架構以分布式和實時增量計算為主。

多樣性與精確性，推薦除了要考慮準確的召回，同時也要兼顧用戶體驗，避免推薦結果的單一化，也需要增加一些多樣性的考慮。

用戶行為模式的挖掘和利用，用本質上說，推薦就是在做用戶行為模工挖掘，找出用戶的行為特征，給出相應的預測，這里面涉及到大量的算法和工程問題。

多維數據的交叉利用，除了線上數據，不少客戶有自己其他渠道的數據，這些數據也可以引入推薦系統，提升推薦的效果。

效果評估，一套完整的推薦系統，必須一套完整的評估體系，百分點對每個推薦欄位都有詳細的效果評估，除了推薦欄維度的點擊率、轉化率，還有商品維度和用戶維度的相關評估指標。

百分點的商業模式是做線上的電商導購員，媒體網站的導航員，提供個性化的用戶體驗，以百分點為數據中心，形成全網的用戶行為偏好，利用大數據獲得更精準的推薦。

百分點如何實現個性化推薦系統？

一個推薦系統的實施，大概要經歷以下步驟：

數據采集：我們主要會采集客戶兩方案的數據，Item的信息和User的行為，Item盡量覆蓋多的屬性維度，User行為盡量覆蓋客戶的所有業務流程。

數據處理：數據采集上來后，經過不同算法的處理形成不同的結果數據，及時更新到內存數據庫。

推薦反饋：對于用戶的每一次推薦請求，推薦服務會整合不同的算法和規則，在毫秒返回結果列表。

在數據采集上，主要有兩方面的技術：

用戶標識技術：除了cookie技術，還有硬件標識技術，精確的用戶拉通和模糊的用戶拉通技術，來支持跨瀏覽器到跨設備用戶識別，其中基于GBDT的模糊拉通技術已經達到95%的準確度。

數據獲取技術：包括js埋點、sdk埋點、抓取、接口傳輸等，其中sdk的動態埋點技術可以實現app無升級的埋點更新，抓取系統的模版化也可以快速適應不同網站和網站改版情況下的抓取需求。

在數據處理上，百分點也經歷了從單機到主從再到全面分布式的架構變化，目前以kafka/storm/IMDB/hadoop實現主要的計算和數據處理。

在推薦算法：主要用到的用協同過濾、關聯規則、統計等，在自然語言處理上，使用了分詞、索引、主題詞和輿情相關的算法、同時還有基于時間序列的預測，使用了GBDT+LR的排序框架。

在推薦服務上，我們經歷了固定算法->動態參數->規則引擎的三個階段。

在最初的推薦系統中我們直接將算法的結果做為推薦的結果返回，形成如看過還看過，買過還買過，經常一起購買等算法；在實際業務中，發現僅僅是推薦算法是不夠的，算法的結果少怎么辦，業務的條件限制怎么辦，逐漸增加了動態參數來控制結果的返回；但這仍然不能很好的解決業務問題，如同一頁面新老用戶使用不同的算法，業務需要不能推薦贈品，需要考慮相同品類或不同品類優先的策略，業務的需求逐漸催生了規則引擎的誕生。

規則引擎

這里要重點介紹一下規則引擎，前面說了那邊多算法和業務，規則引擎的出現才真正解決業務的問題：

在實際使用中我們在一個推薦欄位中會用到類似于下面的規則：

在百分點的規則庫中有將過100個規則模塊，這些模塊像搭積木一樣進行不同的組合拼裝，滿足業務需求的同時解決個性化的問題。我們現在也對這個規則語言做了可視化，業務人員可以像畫流程圖一樣進行拖拽來完成規則的編寫。

百分點推薦系統實踐架構

至此，百分點推薦引擎的核心架構圖如下：

推薦引擎主要由場景、規則、算法和展示這四部分組成。場景引擎就像是偵察兵，探察用戶處理什么狀態，是無目的閑逛還是有購物目標，有什么樣的偏好；規則引擎就像是司令部，根據用戶的狀態制定相應的規則；算法引擎是后勤部隊，為系統提供各種不同的算法結果；展示引擎是先頭部隊，以最能打動客戶的形式將結果展現在用戶面前。

個性化系統的架構

介紹完推薦引擎的核心，我們再來看整個個性化系統的架構。

整個系統以nginx前端集群對外提供服務，通過數據采集服務進入系統，分布式的消息隊列連接后后端的實時處理和離線處理框架，底層存儲方式使用了多種存儲技術支持不同的應用場景。整個系統以zookeeper作為配置客理的中心，配以集群運行狀態的監控保障整個系統的穩定運行。

整個實時推薦的架構以分布式、高可用、高性通、高泛化為目標，以大規模、實時性、內存計算為解決方案，構建快速響應的推薦架構。

在實踐過程中，百分點也正在經歷由SaaS到PaaS的發展歷程，推薦引擎提供云端的數據服務，而實際上Everything is DataFlow! 一切皆數據流!  Bigdata time comes。在大數據時代，推薦引擎也只是大數據平臺的一個應用。

離線計算平臺

百分點離線計算平臺，基于大數據的應用構建架構，是以Hadoop為基礎的大數據技術生態：

離線計算平臺主要服務于數據分析、離線特征工程、模型訓練等工作。在線上的推薦服務中，百分點實時計算平臺發揮著更大的作用。

實時計算平臺

在實時計算平臺上，我們構建了實時計算應用：proxima計算框架

以協同過濾為例，以結點和關系來抽象，通過結點之間的消息傳遞來實現算法的計算，proxima上實現協同過濾的示意圖如下：

實時計算的另一個應用是實時的推薦效果監測：

搜索平臺

下面介紹一下推薦的好朋友：搜索平臺

百分點的搜索平臺基于solr構建，架構圖如下：

對于不同的客戶域，我們采用了分片的技術，同時使用不同的master和slave的劃分，來實現負載的平衡，利用讀寫分離解決索引更新和查詢的速度問題。

搜索做為推薦算法補充，在很多推薦的場景都發揮了重要作用。

個性化系統行業應用案例

架構介紹到此為止，接下來介紹一下百分點個性化系統在一些行業的應用案例：

Q&A

Q1：用戶及物品冷啟動如何解決？

雷銀：用戶冷企動可以采用基于物品的推薦或者其他推薦方式；物品冷啟動可以使用基于用戶的或其他推薦方式；或者提取部分流量進行探索，探索用戶的興趣。

Q2：GBDT+LR的再排的技術實現方案？

雷銀：請參考2014年非死book相關論文即可。

Q3：在個性化場景中怎么對人進行選品?

雷銀：人是有很多場景，包括人的長期或短期偏好、人的購物性格如沖動型/理智型等，從物品上也有很多場景，比如功能性的物品/享樂型物品等，在此之外又有上下文場景、網頁場景等，我們最終要結合具體情況綜合判斷。

Q4：基于GBDT的模糊拉通技術具體是如何實現的？

雷銀：主要是先通過GBDT訓練產生一個比較大的連通圖，然后使用聚類的方法對于較大的連通圖進行拆分，最終的結果是單個的連通圖可以做為一個ID使用。

Q5：介紹冷啟動中提到，百分點大概率擁有一個新用戶在以往在其他平臺的行為信息，所以可以認為是已有用戶？ 這里不太理解，比如百分點擁有該用戶以往在小說平臺的行為信息，但可以理解該用戶在紅酒電商上的行為嗎？

雷銀：小說和紅酒不太能對應，但是很多情況能對應上已有客戶，同時非同類型客戶也同樣可以抽象性別、年齡、消費習慣等通用用戶標簽，可以基于標簽進行數據整合和推薦。

Q6：規則引擎和場景引擎和算法引擎 是如何解耦的？能不能舉個例子.一般場景引擎產出某種結論作為參數輸入算法模型不是很常見 一般raw特征輸入？

雷銀：場景引擎決定了當前的推薦策略，規則引擎描述執行推薦策略，算法引擎產生推薦的候選結果，規則引擎會組合各個算法的結果滿足推薦策略。場景引擎并不做為算法模型的輸入。

Q7：規則引擎是給業務方能夠理解的規則是嗎？所以是場景+規則 或者純算法？ 規則和算法的關系是？ 規則調用算法嗎？

雷銀：場景是業務方可以理解的當前選取推薦策略的依據，規則是描述執行的策略，規則調用組合算法結果。

Q8：全內存數據庫用的是什么數據庫？數據量多大？數據是什么樣的結構？數據備份什么機制？

雷銀：現在用的是Codis和百分點的Codis C++ Clinet(https://github.com/baifendian/CodisClient)，可以很好的解決動態擴容和高可用的問題。目前有約6T的存儲容量。數據根據業務場景使用k-v, list, hashmap等不同的數據結構，對于k-v使用的是json和protobuf的序列化方式。數據備份使用主從同步（最終一致性）。

 

來自：http://www.dataguru.cn/article-9910-1.html