推薦系統系列二：推薦系統的工程實作

下面内容轉自大資料與人工智能微信公衆号，由于網絡上推薦系統的相關學習資料太多太雜，東拼西湊學習很難摸出門道，同時我也在學習推薦系統，是以我将該系列内容摘錄到我的部落格，友善大家直接在部落格中檢視，大家一起學習進步，後面我也會閱讀推薦系統相關的論文，并在本部落格記錄筆記，希望大家一起進步哈。

        在我更新第一篇《推薦系統介紹》之後，過了一兩天這篇介紹的閱讀量就達到了三百多，可見當下存在一個沖突：大家日益增長的對推薦系統好文章的渴求與真正有含金量的推薦系統學習資料間供應存在着巨大的沖突，是以我将加快本系列文章的更新，很感謝大資料與人工智能微信公衆号，大家如果有額外的需求，可以去該公衆号詳詢原作者，由于部落格中不能直接粘貼微信公衆号中的圖檔，本文的圖檔都是我一張一張手動截圖粘貼，整理不易，希望能幫到大家，畢竟好的文章值得我們推廣，不應被埋沒，好了，話不多說，馬上開始。

===================正文開始===================

一：寫在前面

       在上篇文章《推薦系統介紹》中簡單對推薦系統做了一個較全面的介紹，相信大家對推薦系統有了初步的了解。本篇文章作者會結合多年推薦系統開發的實踐經驗粗略介紹推薦系統的工程實作，簡要說明要将推薦系統很好地落地到産品中需要考慮哪些問題及相應的思路、政策和建議,其中有大量關于設計哲學的思考,希望對從事推薦算法工作或準備入行推薦系統的讀者有所幫助。           本篇文章主要從整體上來介紹推薦系統工程實作,以後釋出的系列文章會逐漸介紹工程實作的各個細節實作原理與政策。為了描述友善，本文主要基于視訊推薦來講解,作者這幾年也一直在從事視訊推薦系統開發的工作，其他行業的推薦系統工程實作思路類似。

二：推薦系統與大資料

推薦系統是幫助人們解決資訊擷取問題的有效工具，對網際網路産品而也使用者數和資訊總量通常都是巨大的，每天收集到的使用者在産品上的互動行為也是海量的，這些大量的資料收集處理就涉及到大資料相關技術，是以推薦系統與大資料有天然的聯系，要落地推薦系統往往需要企業具備一套完善的大資料分析平台。

推薦系統與大資料平台的依賴關系如下圖。大資料平台包含資料中心和計算中心兩大抽象，資料中心為推薦系統提供資料存儲，包括訓練推薦模型需要的資料，依賴的其他資料，以及推薦結果，而計算中心提供算力支援，支撐資料預處理、模型訓練、模型推斷(即基于學習到的模型，為每個使用者推薦)等。

大資料與人工智能具有千絲萬縷的關系，網際網路公司一般會建構自己的大資料與人工智能團隊，建構大資料基礎平台，基于大資料平台建構上層業務，包括商業智能(BI),推薦系統及其他人工智能業務，下圖是典型的基于開源技術的視訊網際網路公司大資料與人工智能業務及相關的底層大資料支撐技術。

在産品中整合推薦系統是一個系統工程，怎麼讓推薦系統在産品中産生價值，真正幫助到使用者，提升使用者體驗的同時為平台方提供更大的收益是一件有挑戰的事情，整個推薦系統的業務流可以用下圖來說明，它是一個不斷疊代優化的過程，是一個閉環系統。

有了上面這些介紹，相信讀者對大資料與推薦系統的關系有了一個比較清楚的了解，下面會着重講解推薦系統工程實作相關的知識。

三：推薦系統業務流及其核心子產品

先介紹一下建構一套完善的推薦系統涉及到的主要業務流程及核心子產品，具體流程如下圖，下面分别介紹各個子產品：

（1）資料收集子產品

建構推薦模型需要收集很多資料，包括使用者行為資料，使用者相關資料及推薦“标的物”相關資料。如果将推薦系統比喻為廚師做菜，那麼這些資料是建構推薦算法模型的原材料。巧婦難為無米之炊,要建構好的推薦算法收集到足夠多的有價值的資料是非常關鍵和重要的。

标的物的意思是：電影推薦中标的物就是電影，書的推薦中标的物就是書，今日頭條的标的物就是新聞資訊等。

（2）ETL子產品

收集到的原始資料一般是非結構化的，ETL子產品的主要目的是從收集到的原始資料中提取關鍵字段(拿視訊行業來說，使用者id，時間，播放的節目，播放時長，播放路徑等都是關鍵字段)，将資料轉化為結構化的資料存儲到資料倉庫中。同時根據一定的規則或政策過濾掉髒資料，保證資料品質的高标準。在網際網路公司中，使用者行為資料跟使用者規模呈正比，是以當使用者規模很大時資料量非常大，一般采用HDFS、Hive、HBase等大資料分布式存儲系統來存儲資料。

使用者相關資料及推薦“标的物”相關資料一般是結構化的資料，一般是通過背景管理子產品将資料存儲到MySQL、ProgreSQL等關系型資料庫中。

（3）特征工程子產品

推薦系統采用各種機器學習算法來學習使用者偏好，并基于使用者偏好來為使用者推薦“标的物”,而這些推薦算法用于訓練的資料是可以“被數學所描述”的，一般是向量的形式，其中向量的每一個分量/次元就是一個特征，是以特征工程的目的就是将推薦算法需要的，以及上述ETL後的資料轉換為推薦算法可以學習的特征。

當然，不是所有推薦算法都需要特征工程，比如，如果要做排行榜相關的熱門推薦，隻需要對資料做統計排序處理就可以了。最常用的基于物品的推薦和基于使用者的推薦也隻用到使用者id，标的物id，使用者對标的物的評分三個次元，也談不上特征工程。像logistic回歸等複雜一些的機器學習算法需要做特征工程，一般基于模型的推薦算法都需要特征工程。

特征工程是一個比較複雜的過程，要做好需要很多技巧、智慧、行業知識、經驗等，在這篇文章中作者不作詳細介紹。

（4）推薦算法子產品

推薦算法子產品是整個推薦系統的核心之一，該子產品的核心是根據具體業務及可利用的所有資料設計一套精準、易于工程實作、可以處理大規模資料的(分布式)機器學習算法，進而可以預測使用者的興趣偏好。這裡一般涉及到模型訓練、預測兩個核心操作。下面用一個圖簡單描述這兩個過程，這也是機器學習的通用流程。

好的推薦工程實作，希望盡量将這兩個過程解耦合，做到通用，友善用到各種推薦業務中，後面在推薦系統架構設計一節中會詳細講解具體的設計思路和哲學。

（5）推薦結果存儲子產品

作者在最開始做推薦系統時由于沒有經驗，開始将推薦結果存儲在Mysql中，當時遇到最大的問題是每天更新使用者的推薦時，需要先找到使用者存儲的位置，再做替換，操作複雜，并且當使用者規模大時，高并發讀寫，大資料量存儲，Mysql也扛不住，現在最好的方式是采用CouchBase，Redis等可以橫向擴容的資料庫，可以完全避開MySQL的缺點。

在計算機工程中有“空間換時間”的說法，對于推薦系統來說，就是先計算好每個使用者的推薦，将推薦結果存儲下來，通過預先将推薦結果存下來，可以更快的為使用者提供推薦服務,提升使用者體驗。由于推薦系統會為每個使用者生成推薦結果,并且每天都會(基本全量)更新使用者的推薦結果，一般采用NoSql資料庫來存儲，并且要求資料庫可拓展，高可用，支援大規模并發讀寫。

推薦結果一般不是直接在模型推斷階段直接寫入推薦存儲資料庫，較好的方式是通過一個資料管道(如kafka)來解耦，讓整個系統更加子產品化，易于維護拓展。

（6）Web服務子產品

該子產品是推薦系統直接服務使用者的子產品，該子產品的主要作用是當使用者在UI上觸達推薦系統時，觸發推薦接口，為使用者提供個性化推薦，該子產品的穩定性、響應時長直接影響到使用者體驗。跟上面的推薦存儲子產品類似，Web服務子產品也需要支援高并發通路、水準可拓展、亞秒級(一般200ms之内)響應延遲。

下圖是作者公司相似影片推薦算法的一個簡化版業務流向圖，供大家與上面的子產品對照參考：

四：推薦系統支撐子產品

推薦系統想要很好的穩定的發揮價值，需要一些支撐業務來輔助，這些支撐業務雖然不是推薦系統的核心子產品，但卻是推薦業務穩定運作必不可少的部分，主要包括如下4大支撐子產品，下面分别簡述各個子產品的作用和價值。

（1）評估子產品

推薦評估子產品的主要作用是評估整個推薦系統的品質及價值産出。一般來說可以從兩個次元來評估。

一：離線評估：主要是評估訓練好的推薦模型的“品質”，模型在上線服務之前需要評估該模型的準确度，一般是将訓練資料分為訓練集和測試集，訓練集用于訓練模型，而測試集用來評估模型的預測誤差。

二：線上評估：模型上線提供推薦服務過程中來評估一些真實的轉化名額，比如轉化率、購買率、點選率、播放時長等。線上評估一般會結合AB測試，先放一部分量，如果效果達到期望再逐漸拓展到所有使用者，避免模型線上效果不好嚴重影響使用者體驗和收益名額等。

（2）排程子產品

一個推薦業務要産生價值，所有依賴的任務都要正常運作。推薦業務可以抽象為有向無環圖(第六節推薦系統架構設計會講到将推薦業務抽象為有向無環圖)，是以需要按照該有向圖的依賴關系依次執行每個任務，這些任務的依賴關系就需要借助合适的排程系統(比如Azkaban)來實作，早期我們采用Crontab來排程，當任務量多的時候就不那麼友善了，Crontab也無法很好解決任務依賴關系。

（3）監控子產品

監控子產品解決的是當推薦業務(依賴的)任務由于各種原因排程失敗時可以及時告警，通過郵件或者短信通知運維或者業務的維護者，及時發現問題，或者可以在背景自動拉起服務。同時可以對服務的各種其他狀态做監控，比如檔案大小、狀态變量的值、日期時間等與業務正常執行相關的狀态變量，不正常時及時發現問題。

（4）審查子產品

審查子產品是對推薦系統結果資料格式的正确性、有效性進行檢查，避免錯誤産生，一般的處理政策是根據業務定義一些審查用例(類似測試用例)，在推薦任務執行前或者執行階段對運算過程做check，發現問題及時告警。舉兩個例子，如果你的DAU是100w，每天大約要為這麼多使用者生成個性化推薦結果，但是由于一些開發錯誤，隻計算了20w使用者的個性化推薦，從監控是無法發現問題的，如果增加推薦的使用者數量跟DAU的比例控制在1附近這個審查項，就可以避免出現問題；在推薦結果插入資料庫過程中，開發人員更新了新的算法，不小心将資料格式寫錯(如Json格式不合法)，如果不加審查，會導緻最終插入的資料格式錯誤，導緻接口傳回錯誤或者挂掉，對使用者體驗有極大負面影響。

五：推薦系統範式

推薦系統的目的是為使用者推薦可能喜歡的标的物,這個過程涉及到使用者、标的物兩個重要要素，我們可以根據這兩個要素的不同組合産生不同的推薦形态，即所謂的不同“範式(paradigm)”(數學專業的同學不難了解範式，如果不好了解可以将範式看成具備某種相似性質的對象的集合)，根據我自己建構推薦系統的經驗可以将推薦系統總結為如下5種範式，這5中範式可以應用到産品的各種推薦場景中，後面會拿視訊APP舉例說明具體的應用場景。

【1】範式1：完全個性化範式：為每個使用者提供個性化的内容，每個使用者推薦結果都不同；

常見的猜你喜歡就是這類推薦，可以用于進入首頁的綜合類猜你喜歡推薦，進入各個頻道(如電影)頁的猜你喜歡推薦。下圖是電視貓首頁興趣推薦，就是為每個使用者提供不一樣的個性化推薦；

【2】範式2：群組個性化範式：首先将使用者分組(根據使用者的興趣，将興趣相似的歸為一組)，每組使用者提供一個個性化的推薦清單，同一組的使用者推薦清單一樣，不同組的使用者推薦清單不一樣；

這裡舉一個在作者公司利用範式2做推薦的例子，我們在頻道頁三級清單中，會根據使用者的興趣對清單做個性化重排序，讓與使用者更比對的節目放到前面，提升節目轉化，但是在實作時，為了節省存儲空間，先對使用者聚類，同一類使用者興趣相似，對這一類使用者，清單的排序是一樣的，但是不同類的使用者的清單是完全不一樣的。見下圖的戰争風雲tab，右邊展示的節目集合總量不變，隻是在不同組的使用者看到的排序不一樣，排序是根據與使用者的興趣比對度高低來降序排列的。

【3】範式3：非個性化範式：為所有使用者提供完全一樣的推薦；

比如各類排行榜業務，既可以作為首頁上的一個獨立的推薦子產品，友善使用者發現新熱内容，也可以作為猜你喜歡推薦新使用者冷啟動的預設推薦，下圖是搜尋子產品當使用者未輸入搜尋關鍵詞時給出的熱門内容，也是采用該範式的例子；

【4】範式4：标的物關聯标的物範式：為每個标的物關聯一組标的物，作為使用者在通路标的物詳情頁時的推薦，每個使用者都是相同的标的物；

當使用者浏覽一個電影時，可以通過關聯相似的電影,為使用者提供更多的選擇空間(下圖就是電視貓電影詳情頁關聯的相似影片)；還可以當使用者播放一個節目退出時，推薦使用者可能還喜歡的其他節目；針對短視訊，可以将相似節目做成連播推薦清單，使用者播放目前節目直接連播相似節目，提升節目分發和使用者體驗；

【5】範式5：笛卡爾積範式：每個使用者跟每個标的物的組合産生的推薦都不相同，不同使用者在同一個視訊的詳情頁看到的推薦結果都不一樣；

該範式跟4類似，隻不過不同使用者在同一個節目得到的關聯節目不一樣，會結合使用者的興趣，給出更比對使用者興趣的關聯節目；

由于每個使用者跟每個标的物的組合推薦結果都不一樣,往往使用者數和标的物的數量都是巨大的,沒有足夠的資源事先将所有的組合的推薦結果先計算存儲下來，一般是在使用者觸發推薦時實時計算推薦結果呈現給使用者，計算過程也要盡量簡單，在亞秒級就可以算完，比如利用使用者的播放曆史，過濾掉使用者已經看過的關聯節目；

下面給一個簡單的圖示來說明這5種範式，讓讀者有一個直覺形象的了解。

總之，推薦系統不是孤立存在的對象，它一定是要整合到具體的業務中，在合适的産品互動流程中觸達使用者，通過使用者觸發推薦行為。是以，推薦系統要應用到産品中需要嵌入到使用者使用産品的各個流程(頁面)中。當使用者通路首頁時，可以通過綜合推薦（範式1）來給使用者提供個性化推薦内容，當使用者通路詳情頁，可以通過相似影片（範式4）提供相似标的物推薦，當使用者進入搜尋頁尚未輸入搜尋内容時，可以通過熱門推薦給使用者推送新熱節目(範式3)。這樣處處都有推薦，才會使産品顯得更加智能。所有這些産品形态基本都可以用上面介紹的5種範式來概括。

六：推薦系統架構設計

作者在早期建構推薦系統時由于經驗不足，而業務又比較多，當時的政策是每個算法工程師負責幾個推薦業務(一個推薦業務對應一個推薦産品形态)，由于每個人隻對自己的業務負責，是以開發基本是獨立的，每個人隻關注自己的算法實作，雖然用到的算法是一樣的，但前期在開發過程中沒有将通用的子產品抽象出來，每個開發人員從ETL、算法訓練、預測到插入資料庫都是獨立的，并且每個人在實作過程中整合了自己的一些優化邏輯，一竿子插到底，導緻資源(計算資源，存儲資源，人力資源)使用率不高，開發效率低下。經過幾年的摸索，作者在團隊内部建構了一套通用的算法元件Doraemon架構(就像機器貓的小口袋，有很多工具供大家友善建構推薦業務)，盡量做到資源的節省，大大提升了開發效率。開發過程的蛻變，可以用下面的圖示簡單說明，從中讀者也可以對Doraemon架構落地前後的推薦業務開發變化有個大緻的了解。

作者建構Doraemon架構的初衷是希望建構推薦業務就像搭積木一樣(見下圖)，可以快速建構一套算法體系，快速上線業務。算法或者處理邏輯就像一塊一塊的積木，而算法依賴的資料(及資料結構)就是不同積木之間是否可以銜接的“接口”。

本着上面樸素的思想，下面作者詳細說說建構這套體系的思路和政策。

為了支撐更多類型的推薦業務，減少系統的耦合，便于發現和追蹤問題，節省人力成本，友善算法快速上線和疊代，需要設計比較好的推薦系統架構，而好的推薦系統架構應該具備6大原則：通用性，子產品化，元件化，一緻性，可拓展性，抽象性。下面分别對上述6大原則做簡要說明，闡述清楚它們的目标和意義。

【1】通用性：所謂通用，就是該架構具備包容的能力，業務上的任何推薦産品都可以用這一套架構來涵蓋和實作。

【2】子產品化：子產品化的目的在于将一個業務按照其功能做拆分，分成互相獨立的子產品，以便于每個子產品隻包含與其功能相關的内容，子產品之間通過一緻性的協定調用。将一個大的系統子產品化之後，每個子產品都可以被高度複用。子產品化的目的是為了重用，子產品化後可以友善重複使用和插撥到不同平台，不同推薦業務邏輯中。

【3】元件化：元件化就是基于可重用的目的，将一個大的軟體系統拆分成多個獨立的元件，主要目的就是減少耦合。一個獨立的元件可以是一個軟體包、web服務、web資源或者是封裝了一些函數的子產品。這樣，獨立出來的元件可以單獨維護和更新而不會影響到其他的元件。元件化的目的是為了解耦，把系統拆分成多個元件，分離元件邊界和責任，便于獨立更新和維護，元件可插拔，通過元件的拼接和增減提供更豐富的能力。

元件化和子產品化比較類似，目标分别是為了更好的解耦和重用，就像搭積木一樣建構複雜系統。

【4】一緻性：指子產品的資料輸入輸出采用統一的資料互動協定，做到整個系統一緻。

【5】可拓展性：系統具備支撐大資料量，大并發的能力，并且容易在該系統中增添新的子產品，提供更豐富的能力，讓業務更加完備自治。

【6】抽象性：将相似的操作和流程抽象為統一的操作，主要目的是簡化系統設計，讓系統更加簡潔通用。針對推薦系統采用數學上的概念抽象如下：

操作/算法抽象：我們先對資料處理或者算法做一個抽象，将利用輸入資料通過“操作”得到輸出的的過程抽象為“算子”，按照這個抽象,ETL、機器學習訓練模型、機器學習推斷都是算子。其中輸入輸出可以是資料或者模型。

業務抽象：任何一個推薦業務可以抽象為由資料/模型為節點，算子為邊的“有向無環圖”。下圖是深度學習的算法處理流程，整個算法實作就是一個有向無環圖。

下圖是我們做的一個利用深度學習做電影猜你喜歡的推薦業務流程，整個流程是由各個算子通過依賴關系連結起來的，就像一個有向無環圖。

根據Doraemon系統的設計哲學及上面描述的推薦系統的核心子產品，結合業内，一般将推薦系統分為召回(将使用者可能會喜歡的标的物取出來)和排序(将取出的标的物按照使用者喜好程度降序排列，最喜歡的排在前面)兩個過程，推薦系統可以根據如下方式進行設計。

【1】基礎元件：業務枚舉類型、常量、路徑處理、配置檔案解析等。

【2】資料讀入元件：包括從HDFS、資料倉庫、HBase、Mysql等相關資料庫讀取資料的操作，将這些操作封裝成通用操作，友善所有業務線統一調用；

【3】資料流出元件：類似資料讀入元件，将推薦結果插入最終存儲(如Redis，CouchBase等)的操作封裝成算子，我們一般是将推薦結果流入Kafka，利用Kafka作為資料管道，最終再從Kafka将資料插入推薦存儲伺服器；

【4】算法元件：這個是整個推薦系統的核心。在工程實作過程中，我們将推薦系統中涉及到的算子抽象為3個接口， AlgParameters(算子依賴的參數集合)、 Algorithm/AlgorithmEx (具體的算法實作，如果算法依賴模型，采用AlgorithmEx，比如利用模型做推斷)、Model(算法訓練後的模型，包括模型的導入、導出等接口)。所有的算子實作實作上面3個接口的抽象方法。下圖給出了這3個接口包含的具體方法以及Spark mllib中的矩陣分解基于該抽象的實作。

在我們的業務實踐中，發現上述抽象很合理，基本推薦業務涉及到的所有算子(ETL、模型訓練、模型推薦、排序架構、資料過濾，具體業務邏輯等)都可以采用該方式很好的抽象。

【5】評估元件：主要是包括算法訓練過程的離線評估等；

【6】其他支撐元件：比如AB測試等，都可以整合到Doraemon架構中；

這裡要特别說一下資料(模型)，資料作為算子的輸入輸出，一定要定義嚴格的範式(具備固定的資料結構，比如矩陣分解訓練依賴的資料有三列，一列使用者id，一列物品id，一列使用者對物品的評分)，Spark的DataFrame可以很好的支撐各種資料類型。資料格式定義好後，在算子讀入或者輸出時，可以對類型做校驗，可以很好的避免很多由于業務開發疏忽導緻的問題。這有點類似強類型程式設計語言，在編譯過程(類似算子)可以檢查出類型錯誤。

我們将上面的6類元件封裝成一個Doraemon的lib庫，供具體的推薦業務使用。

基于大資料的資料中心和計算中心的抽象,我們将所有推薦業務中涉及到的資料和算子分别放入資料倉庫和算子倉庫,開發推薦業務時根據推薦算法的業務流程從這兩個倉庫中拿出對應的“積木”來組裝業務,參考下圖。

基于上面的設計原則，推薦業務可以抽象為“資料流”和“算子流”兩個流的互相交織，利用Doraemon架構建構一個完善的推薦業務流程如下圖。

另外，如果公司做産品線的拓展，比如今日頭條拓展新産品抖音、西瓜視訊、火山小視訊等，可以基于上面所提到的“推薦算法的範式”實作很多推薦業務(比如猜你喜歡、相似影片、熱門推薦等)，将這些業務封裝到一個DoraemonBiz.jar的jar包，這樣這些能力可以直接平移到新的産品線，賦能新業務。這種操作就是二次封裝，具有極大的威力，下面給一個形象的圖示來說明這種二次賦能的邏輯，讓大家更好了解這種思想。

從上面的介紹，相信大家已經感受到了Doraemon架構的威力了，有了這套架構，我們可以高效的開發算法了，如果有新的技術突破，我們可以将這些新算法實作并封裝到Doraemon架構中，不斷拓展Doraemon的能力，讓Doraemon成長為具備更多技能(算子)的巨人！

七：推薦系統工程實作的設計哲學

要為推薦系統設計一套好用高效的工程架構并不容易，往往需要踩過很多坑，通過多年經驗的積累才能深刻領悟。前面在“推薦系統架構設計”一節已經說了很多建構Doraemon架構的設計原則，本節試圖從整個推薦業務工程實作的角度給出一些可供參考的設計哲學,以便大家可以更好的将推薦系統落地到業務中。

【1】什麼是好的推薦系統工程實作？

個人認為好的工程實作需要滿足如下幾個原則：

01.别人很容易了解你的邏輯；

02.按照業務流/資料流來組織代碼結構；

03.便于debug；

04.保證資料存儲、代碼子產品、業務邏輯的一緻性；

【2】設計好的推薦系統工程架構的原則？

01.盡量将邏輯拆解為獨立的小單元；

02.代碼單元的輸入輸出定義清晰；

03.設定合适的互動出入口；

04.确定通用一緻的資料互動格式；

05.資料存儲、業務功能點、代碼單元保持一一對應；

【3】怎麼設計好的推薦系統工程架構？

01.确定思考問題的主線：資料流or 業務流；

02.畫出業務流或者資料流的架構圖；

03.确定核心功能子產品；

04.根據核心功能子產品組織代碼目錄結構，資料存儲結構；

05.定義清晰明确的資料格式；

下圖是作者團隊開發的深度學習猜你喜歡推薦系統(基于Tensorflow開發)的業務流程圖,對應的代碼組織結構和對應的資料在本地檔案系統中的存儲結構，基本按照上述設計原則來做，看起來很清晰，友善了解和問題排查。

八：近實時個性化推薦

推薦系統在實際業務實作時一般是T+1推薦(每天更新一次推薦，今天利用昨天之前的資料計算使用者的推薦結果)，随着移動網際網路的深入發展，特别是今日頭條和快手等新聞，短視訊APP的流行，越來越多的公司将T+1和實時政策相結合(比如采用流行的lambda架構，下圖是一個采用lambda架構的推薦架構圖，供參考)将推薦系統做到了近實時推薦,根據使用者的興趣變化實時為使用者提供個性化推薦。像新聞、短視訊這類滿足使用者碎片化時間需求的産品，做到實時個性化可以極大提升使用者體驗，這樣可以更好地滿足使用者需求，提升使用者在産品的停留時間。這裡我們隻是簡單的介紹了一下實時個性化推薦，我在後續的系列文章中會詳細講解實時推薦系統。

九：推薦系統業務落地需要關注的問題

推薦系統要想很好的落地産生價值，除了算法實作、核心子產品和支撐子產品建構外,還有很多方面需要考慮，下面簡單描述一下其他需要考慮的點,這些點都是非常重要的,深入了解這些問題，對真正發揮出推薦系統的價值有非常大的幫助。

【1】二八定律：你的産品可能包含很多推薦子產品，但是在投入精力疊代優化過程中，需要将核心精力放到使用者觸點多的産品(位置好，更容易曝光給使用者的推薦産品)上，因為這些産品形态占整個推薦價值産出的絕大部分。這個道理看起來誰都懂，但在實際工作中一直堅守這個原則，還是很難的；

【2】牛逼的算法與工程可實作性易用性之間的平衡：剛從事推薦算法開發的工程師會覺得算法的價值是巨大的，一個牛逼的算法可以讓産品一飛沖天。殊不知很多在頂級會議上發表的絕大多數“高大上”的算法遇到工業級海量資料大規模的分布式計算難以在工程上落地。好的推薦算法一定要是易于工程實作，跟公司目前的技術架構、人員能力、可用資源是比對的；

【3】推薦系統冷啟動：冷啟動是推薦系統非常重要的一塊，特别是對新産品，這塊設計政策好不好直接影響使用者體驗, 冷啟動有很多實作方案，作者以後會單獨介紹冷啟動的實作政策；

【4】推薦系統的解釋：給使用者提供一個推薦理由有時會達到事半功倍的效果，能夠提升使用者體驗，促進使用者的點選購買。推薦理由又是很難做的，主要是因為現在很多推薦算法(特别是深度學習算法)可解釋性不強，給你做出了推薦可能很精準，但是整個系統無法給你解釋為什麼給你推薦。拿推薦系統給你推薦了電影A來說明，我們可以從其他的途徑來做解釋， 比如“因為你喜歡B”(電影B跟A有一定的相似性)，“今天是國慶節，為你推薦A”，“今天是雨天，為你推薦A”，“跟你興趣相似的人都喜歡A”等等，隻要可以挖掘出使用者的行為，場景(時間，空間，上下文等)，跟推薦的電影的某種聯系，這種聯系都可以作為推薦解釋的理由，不必拘泥于一定要從推薦算法原理中尋找解釋；

【5】推薦系統UI設計和互動邏輯：好的産品UI和互動邏輯有時比好的算法更管用，推薦算法工程師一定要有這種意識，平時在做推薦系統時，也要往這方面多思考，目前的UI及互動是否合理，是否還有更好的方式，多參考或者咨詢一下設計師的思路想法，多體驗一下競品，往往你會有新的收獲。我不是這方面的專家，這裡隻給大家舉一個電視貓産品的例子(見下圖)， 好的UI互動可以極大提升使用者體驗和點選。

【6】推薦系統的價值度量： 讓推薦系統發揮價值, 首先要度量出推薦系統的價值，我們需要将推薦系統的價值量化出來，隻有量化出推薦系統的價值，推薦工程師的價值才能夠被公司認可，老闆才願意在推薦系統上投入資源。這裡我簡單說一下推薦系統的價值産出方式(拿視訊推薦舉例說明)。

（1）推薦系統可以提升使用者體驗和留存，讓使用者更快更便捷找到想看的電影，減少找片時間：可以統計出推薦産生的播放量，總播放時長，人均播放時長，這些數值名額跟大盤的平均名額對比，可以展現推薦系統的優勢，推薦系統的這些名額在大盤的占比也可以衡量推薦系統所占的分量；

（2）推薦系統可以創造收益：通過精準推薦會員節目，使用者通過推薦的會員節目購買會員可以産生會員收益；在推薦的節目上做貼片廣告，使用者播放推薦的節目讓廣告曝光，可以産生廣告收益；這兩塊收益需要量化出來，展現出推薦系統支撐商業變現的能力；

十：推薦系統的技術選型

根據第二節推薦系統與大資料的描述，推薦業務落地依賴大資料技術， 推薦系統的中間過程和結果的存儲需要依賴資料庫，推薦系統接口實作需要依賴web伺服器。這些方面需要的軟體和技術在前面基本都有簡單介紹，也都有開源的軟體供選擇，對創業公司來說，沒有資源和人力去自研相關技術，選擇合适的開源技術是最好最有效的方案。

本節較長的描述一下推薦系統算法開發所依賴的機器學習軟體選型,友善大家在工程實踐中參考選擇。

由于推薦系統落地強依賴于大資料相關技術，而最流行的開源大資料技術基于Hadoop生态系統，是以推薦算法技術選型要圍繞大資料生态系統來發展，可以無縫的将大資料和人工智能結合起來。

基于大資料生态系統有很多機器學習軟體可以用來開發推薦系統，比如Apache旗下的工具SparkMLlib、Flink-ML、Mahout、Storm、SystemML。以及可以運作在Hadoop生态系統上的DeepLearning4J(Java深度學習軟體)，TonY（TensorflowonYARN，LinkedIn開源的），CaffeOnSpark(雅虎開源的)，BigDL(基于Spark上的深度學習，Intel開源的)等。

随着人工智能第三次浪潮的到來，以Tensorflow，Pytorch，MXNet等為代表的深度學習工具得到工業界的大量采用,Tensorflow上有關于推薦系統、排序架構的子產品和源代碼，可供學習參考，通過簡單修改可以直接用于推薦業務中。

另外像xgboost,scikit-learn，H2O，gensim等架構也是非常流行實用的架構，可以用于實際工程項目中。

國内也有很多開源的機器學習架構，騰訊開源的Angel(基于參數伺服器的分布式機器學習平台，可以直接運作在yarn上)，百度開源的PaddlePaddle(深度學架構)，阿裡開源的Euler(圖深度學習架構)，X-DeepLearning(深度學習架構)，也值得大家學習參考。

作者所在公司主要采用SparkMllib，Tensorflow，gensim等架構來實作推薦系統算法的開發。

至于開發語言，Hadoop生态圈基本采用Java/Scala，深度學習生态圈基本采用Python(Tensorflow、Pytorch都采用python作為使用者使用軟體的開發語言，但它們的底層還是用C++開發的)，是以采用Java/Scala，Python作為開發語言有很多開源架構可供選擇，相關的生态系統也很完善。

随着大資料、雲計算、深度學習驅動的人工智能浪潮的發展，越來越多的頂級科技公司開源出很多好用有價值的機器學習軟體工具，可以直接用于工程中，也算是創業公司的福音。

十一：推薦系統的未來發展

随着移動網際網路、物聯網的發展，5G技術的商用，未來推薦系統一定是網際網路公司産品的标配技術和标準解決方案，推薦系統會被越來越多的公司采用，使用者也會越來越依賴推薦系統來做出選擇。

在工程實作上，推薦系統會越來越采用實時推薦技術來更快的響應使用者的興趣(需求)變化，給使用者強感覺，提升使用者體驗，增加公司收益。

個人覺得未來會有專門的開源的推薦引擎出現，并且是提供一站式服務，讓搭建推薦系統成本越來越低。同時随着人工智能的發展，越來越多的雲計算公司會提供推薦系統的PAAS或者SAS服務(現在就有很多創業公司提供推薦服務,隻不過還做的不夠完善)，創業公司可以直接購買推薦系統雲服務，讓搭建推薦系統不再是技術壁壘，到那時推薦系統的價值将會大放異彩！到那時,不是每個創業公司都需要推薦算法開發工程師了，隻要你了解推薦算法原理,知道怎麼将推薦系統引進産品中創造價值,就可以直接采購推薦雲服務。就像李開複博士最新的暢銷書《AI未來》中所說的，很多工作會被AI取代，是以推薦算法工程師也要有危機意識，要不斷培養對業務的敏感度，對業務的了解，短期是無法被機器取代的，到時候說不定可以做一個推薦算法商業政策師。

十二：結語

本文是作者多年推薦系統學習、實踐經驗的總結，希望能夠幫助到即将入行推薦系統開發的讀者或者推薦系統開發人員，讓大家少走彎路。由于作者才疏學淺，雖殚精竭慮，不當之處在所難免，歡迎大家評判指正，以便作者有所提高！

點選這裡進入下篇文章：《推薦系統系列三：推薦系統冷啟動》

————————————————

版權聲明：本文為CSDN部落客「碼不停題Elon」的原創文章，遵循 CC 4.0 BY-SA 版權協定，轉載請附上原文出處連結及本聲明。

原文連結：https://blog.csdn.net/Mr_HHH/article/details/89180059