導讀：個性化推薦系統，簡單來說就是根據每個人的偏好推薦他喜歡的物品。互聯網發展到現在，推薦系統已經無處不在，在各行各業都得到普遍都應用。亞馬遜號稱 40% 的收入是來自個性化推薦系統的，淘寶的個性化推薦系統也帶來非常大的收益，新聞媒體的個性化推薦系統典型的是今日頭條，直播平臺給用戶推薦喜歡的主播，金融網站給用戶推薦需要的理財產品，社交網絡給用戶推薦大 V 或者其他朋友……越來越多的公司將推薦系統作爲產品的標配。
大家接觸推薦系統的概率會越來越大。作爲程序員，瞭解推薦系統也越來越必要，甚至可以主動選擇“推薦系統算法工程師”的相關職位。那大家一定會關心推薦算法工程師需要哪些知識儲備，以及作爲一個推薦算法工程師，未來的發展道路怎樣？
本文是作者計劃的一系列文章中的一篇。作者在上篇文章《推薦系統介紹》中簡單對推薦系統做了一個較全面的介紹，相信大家對推薦系統有了初步的瞭解。本篇文章作者會結合多年推薦系統開發的實踐經驗粗略介紹推薦系統的工程實現，簡要說明要將推薦系統很好地落地到產品中需要考慮哪些問題及相應的思路、策略和建議，其中有大量關於設計哲學的思考，希望對從事推薦算法工作或準備入行推薦系統的讀者有所幫助。爲了描述方便，本文主要基於視頻推薦來講解，作者這幾年也一直在從事視頻推薦系統開發的工作，其他行業的推薦系統工程實現思路類似。本篇文章主要從整體上來介紹推薦系統工程實現，以後發佈的系列文章會逐步介紹工程實現的各個細節實現原理與策略。
推薦系統與大數據
推薦系統是幫助人們解決信息獲取問題的有效工具，對互聯網產品而也用戶數和信息總量通常都是巨大的，每天收集到的用戶在產品上的交互行爲也是海量的，這些大量的數據收集處理就涉及到大數據相關技術，所以推薦系統與大數據有天然的聯繫，要落地推薦系統往往需要企業具備一套完善的大數據分析平臺。
推薦系統與大數據平臺的依賴關係如下圖。大數據平臺包含數據中心和計算中心兩大抽象，數據中心爲推薦系統提供數據存儲，包括訓練推薦模型需要的數據，依賴的其他數據，以及推薦結果，而計算中心提供算力支持，支撐數據預處理、模型訓練、模型推斷(即基於學習到的模型，爲每個用戶推薦)等。
大數據與人工智能具有千絲萬縷的關係，互聯網公司一般會構建自己的大數據與人工智能團隊，構建大數據基礎平臺，基於大數據平臺構建上層業務，包括商業智能(BI),推薦系統及其他人工智能業務，下圖是典型的基於開源技術的視頻互聯網公司大數據與人工智能業務及相關的底層大數據支撐技術。
在產品中整合推薦系統是一個系統工程，怎麼讓推薦系統在產品中產生價值，真正幫助到用戶，提升用戶體驗的同時爲平臺方提供更大的收益是一件有挑戰的事情，整個推薦系統的業務流可以用下圖來說明，它是一個不斷迭代優化的過程，是一個閉環系統。
有了上面這些介紹，相信讀者對大數據與推薦系統的關係有了一個比較清楚的瞭解，下面會着重講解推薦系統工程實現相關的知識。
推薦系統業務流及核心模塊
先介紹一下構建一套完善的推薦系統涉及到的主要業務流程及核心模塊，具體流程如下圖，下面分別介紹各個模塊：
- 數據收集模塊
構建推薦模型需要收集很多數據，包括用戶行爲數據，用戶相關數據及推薦“標的物”相關數據。如果將推薦系統比喻爲廚師做菜，那麼這些數據是構建推薦算法模型的原材料。巧婦難爲無米之炊,要構建好的推薦算法收集到足夠多的有價值的數據是非常關鍵和重要的。
- ETL模塊
收集到的原始數據一般是非結構化的，ETL模塊的主要目的是從收集到的原始數據中提取關鍵字段(拿視頻行業來說，用戶id，時間，播放的節目，播放時長，播放路徑等都是關鍵字段)，將數據轉化爲結構化的數據存儲到數據倉庫中。同時根據一定的規則或策略過濾掉髒數據，保證數據質量的高標準。在互聯網公司中，用戶行爲數據跟用戶規模呈正比，所以當用戶規模很大時數據量非常大，一般採用HDFS、Hive、HBase等大數據分佈式存儲系統來存儲數據。
用戶相關數據及推薦“標的物”相關數據一般是結構化的數據，一般是通過後臺管理模塊將數據存儲到MySQL、ProgreSQL等關係型數據庫中。
- 特徵工程模塊
推薦系統採用各種機器學習算法來學習用戶偏好，並基於用戶偏好來爲用戶推薦“標的物”,而這些推薦算法用於訓練的數據是可以“被數學所描述”的，一般是向量的形式，其中向量的每一個分量/維度就是一個特徵，所以特徵工程的目的就是將推薦算法需要的，以及上述ETL後的數據轉換爲推薦算法可以學習的特徵。
當然，不是所有推薦算法都需要特徵工程，比如，如果要做排行榜相關的熱門推薦，只需要對數據做統計排序處理就可以了。最常用的基於物品的推薦和基於用戶的推薦也只用到用戶id，標的物id，用戶對標的物的評分三個維度，也談不上特徵工程。像logistic迴歸等複雜一些的機器學習算法需要做特徵工程，一般基於模型的推薦算法都需要特徵工程。
特徵工程是一個比較複雜的過程，要做好需要很多技巧、智慧、行業知識、經驗等，在這篇文章中作者不作詳細介紹。
- 推薦算法模塊
推薦算法模塊是整個推薦系統的核心之一，該模塊的核心是根據具體業務及可利用的所有數據設計一套精準、易於工程實現、可以處理大規模數據的(分佈式)機器學習算法，進而可以預測用戶的興趣偏好。這裏一般涉及到模型訓練、預測兩個核心操作。下面用一個圖簡單描述這兩個過程，這也是機器學習的通用流程。
好的推薦工程實現，希望儘量將這兩個過程解耦合，做到通用，方便用到各種推薦業務中，後面在推薦系統架構設計一節中會詳細講解具體的設計思路和哲學。
- 推薦結果存儲模塊
作者在最開始做推薦系統時由於沒有經驗，開始將推薦結果存儲在Mysql中，當時遇到最大的問題是每天更新用戶的推薦時，需要先找到用戶存儲的位置，再做替換，操作複雜，並且當用戶規模大時，高併發讀寫，大數據量存儲，Mysql也扛不住，現在最好的方式是採用CouchBase，Redis等可以橫向擴容的數據庫，可以完全避開MySQL的缺點。
在計算機工程中有“空間換時間”的說法，對於推薦系統來說，就是先計算好每個用戶的推薦，將推薦結果存儲下來，通過預先將推薦結果存下來，可以更快的爲用戶提供推薦服務,提升用戶體驗。由於推薦系統會爲每個用戶生成推薦結果,並且每天都會(基本全量)更新用戶的推薦結果，一般採用NoSql數據庫來存儲，並且要求數據庫可拓展，高可用，支持大規模併發讀寫。
推薦結果一般不是直接在模型推斷階段直接寫入推薦存儲數據庫，較好的方式是通過一個數據管道(如kafka)來解耦，讓整個系統更加模塊化，易於維護拓展。
- Web服務模塊
該模塊是推薦系統直接服務用戶的模塊，該模塊的主要作用是當用戶在UI上觸達推薦系統時，觸發推薦接口，爲用戶提供個性化推薦，該模塊的穩定性、響應時長直接影響到用戶體驗。跟上面的推薦存儲模塊類似，Web服務模塊也需要支持高併發訪問、水平可拓展、亞秒級(一般200ms之內)響應延遲。
下圖是作者公司相似影片推薦算法的一個簡化版業務流向圖，供大家與上面的模塊對照參考：
推薦系統支撐模塊
推薦系統想要很好的穩定的發揮價值，需要一些支撐業務來輔助，這些支撐業務雖然不是推薦系統的核心模塊，但卻是推薦業務穩定運行必不可少的部分，主要包括如下4大支撐模塊，下面分別簡述各個模塊的作用和價值。
- 評估模塊
推薦評估模塊的主要作用是評估整個推薦系統的質量及價值產出。一般來說可以從兩個維度來評估。
-
離線評估：主要是評估訓練好的推薦模型的“質量”，模型在上線服務之前需要評估該模型的準確度，一般是將訓練數據分爲訓練集和測試集，訓練集用於訓練模型，而測試集用來評估模型的預測誤差。
-
在線評估：模型上線提供推薦服務過程中來評估一些真實的轉化指標，比如轉化率、購買率、點擊率、播放時長等。線上評估一般會結合AB測試，先放一部分量，如果效果達到期望再逐步拓展到所有用戶，避免模型線上效果不好嚴重影響用戶體驗和收益指標等。
- 調度模塊
一個推薦業務要產生價值，所有依賴的任務都要正常運行。推薦業務可以抽象爲有向無環圖(第六節推薦系統架構設計會講到將推薦業務抽象爲有向無環圖)，因此需要按照該有向圖的依賴關係依次執行每個任務，這些任務的依賴關係就需要藉助合適的調度系統(比如Azkaban)來實現，早期我們採用Crontab來調度，當任務量多的時候就不那麼方便了，Crontab也無法很好解決任務依賴關係。
- 監控模塊
監控模塊解決的是當推薦業務(依賴的)任務由於各種原因調度失敗時可以及時告警，通過郵件或者短信通知運維或者業務的維護者，及時發現問題，或者可以在後臺自動拉起服務。同時可以對服務的各種其他狀態做監控，比如文件大小、狀態變量的值、日期時間等與業務正常執行相關的狀態變量，不正常時及時發現問題。
- 審查模塊
審查模塊是對推薦系統結果數據格式的正確性、有效性進行檢查，避免錯誤產生，一般的處理策略是根據業務定義一些審查用例(類似測試用例)，在推薦任務執行前或者執行階段對運算過程做check，發現問題及時告警。舉兩個例子，如果你的DAU是100w，每天大約要爲這麼多用戶生成個性化推薦結果，但是由於一些開發錯誤，只計算了20w用戶的個性化推薦，從監控是無法發現問題的，如果增加推薦的用戶數量跟DAU的比例控制在1附近這個審查項，就可以避免出現問題；在推薦結果插入數據庫過程中，開發人員升級了新的算法，不小心將數據格式寫錯(如Json格式不合法)，如果不加審查，會導致最終插入的數據格式錯誤，導致接口返回錯誤或者掛掉，對用戶體驗有極大負面影響。
推薦系統範式
推薦系統的目的是爲用戶推薦可能喜歡的標的物,這個過程涉及到用戶、標的物兩個重要要素，我們可以根據這兩個要素的不同組合產生不同的推薦形態，即所謂的不同“範式(paradigm)”(數學專業的同學不難理解範式，如果不好理解可以將範式看成具備某種相似性質的對象的集合)，根據我自己構建推薦系統的經驗可以將推薦系統總結爲如下5種範式，這5中範式可以應用到產品的各種推薦場景中，後面會拿視頻APP舉例說明具體的應用場景。
- 範式1：完全個性化範式：爲每個用戶提供個性化的內容，每個用戶推薦結果都不同；
常見的猜你喜歡就是這類推薦，可以用於進入首頁的綜合類猜你喜歡推薦，進入各個頻道(如電影)頁的猜你喜歡推薦。下圖是電視貓首頁興趣推薦，就是爲每個用戶提供不一樣的個性化推薦；
- 範式2：羣組個性化範式：首先將用戶分組(根據用戶的興趣，將興趣相似的歸爲一組)，每組用戶提供一個個性化的推薦列表，同一組的用戶推薦列表一樣，不同組的用戶推薦列表不一樣；
這裏舉一個在作者公司利用範式2做推薦的例子，我們在頻道頁三級列表中，會根據用戶的興趣對列表做個性化重排序，讓與用戶更匹配的節目放到前面，提升節目轉化，但是在實現時，爲了節省存儲空間，先對用戶聚類，同一類用戶興趣相似，對這一類用戶，列表的排序是一樣的，但是不同類的用戶的列表是完全不一樣的。見下圖的戰爭風雲tab，右邊展示的節目集合總量不變，只是在不同組的用戶看到的排序不一樣，排序是根據與用戶的興趣匹配度高低來降序排列的。
- 範式3：非個性化範式：爲所有用戶提供完全一樣的推薦；
比如各類排行榜業務，既可以作爲首頁上的一個獨立的推薦模塊，方便用戶發現新熱內容，也可以作爲猜你喜歡推薦新用戶冷啓動的默認推薦，下圖是搜索模塊當用戶未輸入搜索關鍵詞時給出的熱門內容，也是採用該範式的例子；
- 範式4：標的物關聯標的物範式：爲每個標的物關聯一組標的物，作爲用戶在訪問標的物詳情頁時的推薦，每個用戶都是相同的標的物；
當用戶瀏覽一個電影時，可以通過關聯相似的電影,爲用戶提供更多的選擇空間(下圖就是電視貓電影詳情頁關聯的相似影片)；還可以當用戶播放一個節目退出時，推薦用戶可能還喜歡的其他節目；針對短視頻，可以將相似節目做成連播推薦列表，用戶播放當前節目直接連播相似節目，提升節目分發和用戶體驗；
- 範式5：笛卡爾積範式：每個用戶跟每個標的物的組合產生的推薦都不相同，不同用戶在同一個視頻的詳情頁看到的推薦結果都不一樣；
該範式跟4類似，只不過不同用戶在同一個節目得到的關聯節目不一樣，會結合用戶的興趣，給出更匹配用戶興趣的關聯節目；
由於每個用戶跟每個標的物的組合推薦結果都不一樣,往往用戶數和標的物的數量都是巨大的,沒有足夠的資源事先將所有的組合的推薦結果先計算存儲下來，一般是在用戶觸發推薦時實時計算推薦結果呈現給用戶，計算過程也要儘量簡單，在亞秒級就可以算完，比如利用用戶的播放歷史，過濾掉用戶已經看過的關聯節目；
下面給一個簡單的圖示來說明這5種範式，讓讀者有一個直觀形象的理解。
總之，推薦系統不是孤立存在的對象，它一定是要整合到具體的業務中，在合適的產品交互流程中觸達用戶，通過用戶觸發推薦行爲。所以，推薦系統要應用到產品中需要嵌入到用戶使用產品的各個流程(頁面)中。當用戶訪問首頁時，可以通過綜合推薦（範式1）來給用戶提供個性化推薦內容，當用戶訪問詳情頁，可以通過相似影片（範式4）提供相似標的物推薦，當用戶進入搜索頁尚未輸入搜索內容時，可以通過熱門推薦給用戶推送新熱節目(範式3)。這樣處處都有推薦，纔會使產品顯得更加智能。所有這些產品形態基本都可以用上面介紹的5種範式來概括。
推薦系統架構設計
作者在早期構建推薦系統時由於經驗不足，而業務又比較多，當時的策略是每個算法工程師負責幾個推薦業務(一個推薦業務對應一個推薦產品形態)，由於每個人只對自己的業務負責，所以開發基本是獨立的，每個人只關注自己的算法實現，雖然用到的算法是一樣的，但前期在開發過程中沒有將通用的模塊抽象出來，每個開發人員從ETL、算法訓練、預測到插入數據庫都是獨立的，並且每個人在實現過程中整合了自己的一些優化邏輯，一竿子插到底，導致資源(計算資源，存儲資源，人力資源)利用率不高，開發效率低下。經過幾年的摸索，作者在團隊內部構建了一套通用的算法組件Doraemon框架(就像機器貓的小口袋，有很多工具供大家方便構建推薦業務)，儘量做到資源的節省，大大提升了開發效率。開發過程的蛻變，可以用下面的圖示簡單說明，從中讀者也可以對Doraemon架構落地前後的推薦業務開發變化有個大致的瞭解。
作者構建Doraemon框架的初衷是希望構建推薦業務就像搭積木一樣(見下圖)，可以快速構建一套算法體系，快速上線業務。算法或者處理邏輯就像一塊一塊的積木，而算法依賴的數據(及數據結構)就是不同積木之間是否可以銜接的“接口”。
本着上面樸素的思想，下面作者詳細說說構建這套體系的思路和策略。
爲了支撐更多類型的推薦業務，減少系統的耦合，便於發現和追蹤問題，節省人力成本，方便算法快速上線和迭代，需要設計比較好的推薦系統架構，而好的推薦系統架構應該具備6大原則：通用性，模塊化，組件化，一致性，可拓展性，抽象性。下面分別對上述6大原則做簡要說明，闡述清楚它們的目標和意義。
-
通用性：所謂通用，就是該架構具備包容的能力，業務上的任何推薦產品都可以用這一套架構來涵蓋和實現。
-
模塊化：模塊化的目的在於將一個業務按照其功能做拆分，分成相互獨立的模塊，以便於每個模塊只包含與其功能相關的內容，模塊之間通過一致性的協議調用。將一個大的系統模塊化之後，每個模塊都可以被高度複用。模塊化的目的是爲了重用，模塊化後可以方便重複使用和插撥到不同平臺，不同推薦業務邏輯中。
-
組件化：組件化就是基於可重用的目的，將一個大的軟件系統拆分成多個獨立的組件，主要目的就是減少耦合。一個獨立的組件可以是一個軟件包、web服務、web資源或者是封裝了一些函數的模塊。這樣，獨立出來的組件可以單獨維護和升級而不會影響到其他的組件。組件化的目的是爲了解耦，把系統拆分成多個組件，分離組件邊界和責任，便於獨立升級和維護，組件可插拔，通過組件的拼接和增減提供更豐富的能力。
組件化和模塊化比較類似，目標分別是爲了更好的解耦和重用，就像搭積木一樣構建複雜系統。
-
一致性：指模塊的數據輸入輸出採用統一的數據交互協議，做到整個系統一致。
-
可拓展性：系統具備支撐大數據量，大併發的能力，並且容易在該系統中增添新的模塊，提供更豐富的能力，讓業務更加完備自治。
-
抽象性：將相似的操作和流程抽象爲統一的操作，主要目的是簡化系統設計，讓系統更加簡潔通用。針對推薦系統採用數學上的概念抽象如下：
操作/算法抽象：我們先對數據處理或者算法做一個抽象，將利用輸入數據通過“操作”得到輸出的的過程抽象爲“算子”，按照這個抽象,ETL、機器學習訓練模型、機器學習推斷都是算子。其中輸入輸出可以是數據或者模型。
業務抽象：任何一個推薦業務可以抽象爲由數據/模型爲節點，算子爲邊的“有向無環圖”。下圖是深度學習的算法處理流程，整個算法實現就是一個有向無環圖。
下圖是我們做的一個利用深度學習做電影猜你喜歡的推薦業務流程，整個流程是由各個算子通過依賴關係鏈接起來的，就像一個有向無環圖。
根據Doraemon系統的設計哲學及上面描述的推薦系統的核心模塊，結合業內，一般將推薦系統分爲召回(將用戶可能會喜歡的標的物取出來)和排序(將取出的標的物按照用戶喜好程度降序排列，最喜歡的排在前面)兩個過程，推薦系統可以根據如下方式進行設計。
-
基礎組件：業務枚舉類型、常量、路徑處理、配置文件解析等。
-
數據讀入組件：包括從HDFS、數據倉庫、HBase、Mysql等相關數據庫讀取數據的操作，將這些操作封裝成通用操作，方便所有業務線統一調用；
-
數據流出組件：類似數據讀入組件，將推薦結果插入最終存儲(如Redis，CouchBase等)的操作封裝成算子，我們一般是將推薦結果流入Kafka，利用Kafka作爲數據管道，最終再從Kafka將數據插入推薦存儲服務器；
-
算法組件：這個是整個推薦系統的核心。在工程實現過程中，我們將推薦系統中涉及到的算子抽象爲3個接口， AlgParameters(算子依賴的參數集合)、 Algorithm/AlgorithmEx (具體的算法實現，如果算法依賴模型，採用AlgorithmEx，比如利用模型做推斷)、Model(算法訓練後的模型，包括模型的導入、導出等接口)。所有的算子實現實現上面3個接口的抽象方法。下圖給出了這3個接口包含的具體方法以及Spark mllib中的矩陣分解基於該抽象的實現。
在我們的業務實踐中，發現上述抽象很合理，基本推薦業務涉及到的所有算子(ETL、模型訓練、模型推薦、排序框架、數據過濾，具體業務邏輯等)都可以採用該方式很好的抽象。
-
評估組件：主要是包括算法訓練過程的離線評估等；
-
其他支撐組件：比如AB測試等，都可以整合到Doraemon框架中；
這裏要特別說一下數據(模型)，數據作爲算子的輸入輸出，一定要定義嚴格的範式(具備固定的數據結構，比如矩陣分解訓練依賴的數據有三列，一列用戶id，一列物品id，一列用戶對物品的評分)，Spark的DataFrame可以很好的支撐各種數據類型。數據格式定義好後，在算子讀入或者輸出時，可以對類型做校驗，可以很好的避免很多由於業務開發疏忽導致的問題。這有點類似強類型編程語言，在編譯過程(類似算子)可以檢查出類型錯誤。
我們將上面的6類組件封裝成一個Doraemon的lib庫，供具體的推薦業務使用。
基於大數據的數據中心和計算中心的抽象,我們將所有推薦業務中涉及到的數據和算子分別放入數據倉庫和算子倉庫,開發推薦業務時根據推薦算法的業務流程從這兩個倉庫中拿出對應的“積木”來組裝業務,參考下圖。
基於上面的設計原則，推薦業務可以抽象爲“數據流”和“算子流”兩個流的相互交織，利用Doraemon框架構建一個完善的推薦業務流程如下圖。
另外，如果公司做產品線的拓展，比如今日頭條拓展新產品抖音、西瓜視頻、火山小視頻等，可以基於上面所提到的“推薦算法的範式”實現很多推薦業務(比如猜你喜歡、相似影片、熱門推薦等)，將這些業務封裝到一個DoraemonBiz.jar的jar包，這樣這些能力可以直接平移到新的產品線，賦能新業務。這種操作就是二次封裝，具有極大的威力，下面給一個形象的圖示來說明這種二次賦能的邏輯，讓大家更好理解這種思想。
從上面的介紹，相信大家已經感受到了Doraemon框架的威力了，有了這套框架，我們可以高效的開發算法了，如果有新的技術突破，我們可以將這些新算法實現並封裝到Doraemon框架中，不斷拓展Doraemon的能力，讓Doraemon成長爲具備更多技能(算子)的巨人！
推薦系統工程實現的設計哲學
要爲推薦系統設計一套好用高效的工程框架並不容易，往往需要踩過很多坑，通過多年經驗的積累才能深刻領悟。前面在“推薦系統架構設計”一節已經說了很多構建Doraemon框架的設計原則，本節試圖從整個推薦業務工程實現的角度給出一些可供參考的設計哲學,以便大家可以更好的將推薦系統落地到業務中。
- 什麼是好的推薦系統工程實現？
個人認爲好的工程實現需要滿足如下幾個原則：
-
別人很容易理解你的邏輯；
-
按照業務流/數據流來組織代碼結構；
-
便於debug；
-
保證數據存儲、代碼模塊、業務邏輯的一致性；
- 設計好的推薦系統工程架構的原則？
-
儘量將邏輯拆解爲獨立的小單元；
-
代碼單元的輸入輸出定義清晰；
-
設置合適的交互出入口；
-
確定通用一致的數據交互格式；
-
數據存儲、業務功能點、代碼單元保持一一對應；
- 怎麼設計好的推薦系統工程架構？
-
確定思考問題的主線：數據流or 業務流；
-
畫出業務流或者數據流的架構圖；
-
確定核心功能模塊；
-
根據核心功能模塊組織代碼目錄結構，數據存儲結構；
-
定義清晰明確的數據格式；
下圖是作者團隊開發的深度學習猜你喜歡推薦系統(基於Tensorflow開發)的業務流程圖,對應的代碼組織結構和對應的數據在本地文件系統中的存儲結構，基本按照上述設計原則來做，看起來很清晰，方便理解和問題排查。
近實時個性化推薦
推薦系統在實際業務實現時一般是T+1推薦(每天更新一次推薦，今天利用昨天之前的數據計算用戶的推薦結果)，隨着移動互聯網的深入發展，特別是今日頭條和快手等新聞，短視頻APP的流行，越來越多的公司將T+1和實時策略相結合(比如採用流行的lambda架構，下圖是一個採用lambda架構的推薦架構圖，供參考)將推薦系統做到了近實時推薦,根據用戶的興趣變化實時爲用戶提供個性化推薦。像新聞、短視頻這類滿足用戶碎片化時間需求的產品，做到實時個性化可以極大提升用戶體驗，這樣可以更好地滿足用戶需求，提升用戶在產品的停留時間。這裏我們只是簡單的介紹了一下實時個性化推薦，我在後續的系列文章中會詳細講解實時推薦系統。
推薦系統業務落地需要關注的問題
推薦系統要想很好的落地產生價值，除了算法實現、核心模塊和支撐模塊構建外,還有很多方面需要考慮，下面簡單描述一下其他需要考慮的點,這些點都是非常重要的,深入理解這些問題，對真正發揮出推薦系統的價值有非常大的幫助。
-
二八定律：你的產品可能包含很多推薦模塊，但是在投入精力迭代優化過程中，需要將核心精力放到用戶觸點多的產品(位置好，更容易曝光給用戶的推薦產品)上，因爲這些產品形態佔整個推薦價值產出的絕大部分。這個道理看起來誰都懂，但在實際工作中一直堅守這個原則，還是很難的；
-
牛逼的算法與工程可實現性易用性之間的平衡：剛從事推薦算法開發的工程師會覺得算法的價值是巨大的，一個牛逼的算法可以讓產品一飛沖天。殊不知很多在頂級會議上發表的絕大多數“高大上”的算法遇到工業級海量數據大規模的分佈式計算難以在工程上落地。好的推薦算法一定要是易於工程實現，跟公司當前的技術架構、人員能力、可用資源是匹配的；
-
推薦系統冷啓動：冷啓動是推薦系統非常重要的一塊，特別是對新產品，這塊設計策略好不好直接影響用戶體驗, 冷啓動有很多實現方案，作者以後會單獨介紹冷啓動的實現策略；
-
推薦系統的解釋：給用戶提供一個推薦理由有時會達到事半功倍的效果，能夠提升用戶體驗，促進用戶的點擊購買。推薦理由又是很難做的，主要是因爲現在很多推薦算法(特別是深度學習算法)可解釋性不強，給你做出了推薦可能很精準，但是整個系統無法給你解釋爲什麼給你推薦。拿推薦系統給你推薦了電影A來說明，我們可以從其他的途徑來做解釋， 比如“因爲你喜歡B”(電影B跟A有一定的相似性)，“今天是國慶節，爲你推薦A”，“今天是雨天，爲你推薦A”，“跟你興趣相似的人都喜歡A”等等，只要可以挖掘出用戶的行爲，場景(時間，空間，上下文等)，跟推薦的電影的某種聯繫，這種聯繫都可以作爲推薦解釋的理由，不必拘泥於一定要從推薦算法原理中尋找解釋；
-
推薦系統UI設計和交互邏輯：好的產品UI和交互邏輯有時比好的算法更管用，推薦算法工程師一定要有這種意識，平時在做推薦系統時，也要往這方面多思考，當前的UI及交互是否合理，是否還有更好的方式，多參考或者諮詢一下設計師的思路想法，多體驗一下競品，往往你會有新的收穫。我不是這方面的專家，這裏只給大家舉一個電視貓產品的例子(見下圖)， 好的UI交互可以極大提升用戶體驗和點擊。
- 推薦系統的價值度量：讓推薦系統發揮價值，首先要度量出推薦系統的價值，我們需要將推薦系統的價值量化出來，只有量化出推薦系統的價值，推薦工程師的價值才能夠被公司認可，老闆才願意在推薦系統上投入資源。這裏我簡單說一下推薦系統的價值產出方式(拿視頻推薦舉例說明)。
（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取代，所以推薦算法工程師也要有危機意識，要不斷培養對業務的敏感度，對業務的理解，短期是無法被機器取代的，到時候說不定可以做一個推薦算法商業策略師。
小結
本文是作者多年推薦系統學習、實踐經驗的總結，希望能夠幫助到即將入行推薦系統開發的讀者或者推薦系統開發人員，讓大家少走彎路。由於作者才疏學淺，雖殫精竭慮，不當之處在所難免，歡迎大家評判指正，以便作者有所提高！
作者介紹：gongyouliu，有近10年大數據與ai相關項目經驗，有9年推薦系統研究及實踐經驗，目前負責電視貓大數據與人工智能團隊。喜歡讀書，暴走，寫作。業餘維護“大數據與人工智能”公衆號，ID：ai-big-data，持續輸出推薦系統相關文章。個人微信：liuq4360