上一篇數據中臺的實戰文章講了《數據中臺實戰（九）：如何搭建全渠道自動化的平臺》，這次我們基于實戰看一下如何從0到1搭建推薦平臺。

一、什么是推薦系統

推薦系統的核心是要解決人貨匹配的問題。

我們拿電商平臺舉例，作為一個電商平臺，就是為了賣貨，怎么把我們的貨賣出去并且用戶還比較滿意呢？一定是找到有需求的用戶。

當我們平臺有10個用戶，50件單品在賣的時候，如果平臺有一個運營就能搞定所有的事情，運營甚至可以挨個問平臺的10個用戶，他們到底想要那些貨，然后在這50件單品中找到用戶想要的貨人工推薦給平臺的用戶。

當用戶發展到一定的規模，比如1萬，5000件單品，運營的做法是給用戶打上各種各樣的標簽，通過標簽形成用戶畫像，再基于用戶畫像做用戶分群，每個群是一類人，那么高價值的用戶群，一定是特殊對待，傾斜更多的資源，只有針對這些高價值用戶才有精力提供一對一的服務，這樣效率才會最高。

可以想一下如果當平臺的用戶已經突破一個億人這么一個規模，單品突破10萬的規模，我們該怎么解決人貨匹配的問題呢？

隨著用戶量的增長有一點是不變的，那就是用戶喜歡什么樣的商品，我們如果了解了用戶需要什么貨，也就能把我們的10萬商品賣出去。

推薦就是用數學的方法計算并猜測用戶到底需要什么商品，通過數據可以計算出用戶到底會喜歡那些商品，只是一個概率，當把這個概率提高到了一定的水平，那么就可以把這些商品展現給我們的用戶，說不定他就買了我們推薦的商品。

接下來核心問題就比較明顯了：我們應該怎么計算用戶到底喜歡那些商品呢？

答案就是用戶的數據。

用戶的數據其實分為隱性數據和顯性數據。

隱性數據是什么？我們的埋點就派上了用場，用戶的每次瀏覽，點擊都會記錄這個用戶是誰，什么時候，在什么地點，用什么設備，來看我們的那個商品，看了多久。

這些數據對判斷用戶是否對該件商品感興趣是有價值的，為什么？

比如對于同一個商品來說，一個用戶連續3天都在看，而且停留很久，另外一個用戶到我們網站后壓根就沒看這個商品，那么相對于第一個用戶來講，我們就可以直接判定這個用戶是對這個商品更感興趣的。

第二部分是用戶的顯性數據，比如用戶下單的數據，加購的數據，收藏的數據等業務數據，還有用戶填的一些資料，比如用戶的性別，地區等數據，對一個用戶越了解，就可以更加精確的判斷出他會買那些商品。

現在的電商產品推薦基本是標配的，比如你在啊貓，啊狗網站上看了一個最新款的蘋果手機，那么在電商網站的某個猜你喜歡模塊一定能看到這個手機是排在了最上面，如下圖1-1所示。

圖1-1 淘寶推薦猜你喜歡模塊

比如你買過了這個手機，那么可能這個猜你喜歡會給你推薦蘋果手機類似的商品，比如給你推薦一個 iPad，如下圖1-2所示：

這時你可能就會有比較大的幾率下單。

圖1-2淘寶推薦看了又看模塊

二、推薦系統架構

2.1 推薦系統功能架構

如下圖1-3所示是一個典型的推薦系統功能架構圖，一個推薦系統主要分為三塊，分別為召回、過濾、排序。

圖1-3推薦系統功能架構圖

第一步是召回

召回就是上圖中的N個推薦引擎。

召回就是通過一定的方式找到用戶可能感興趣的商品。

召回的方式有3種：

1. 用戶喜歡的物品相似的物品
2. 和用戶有相似興趣的用戶喜歡的物品
3. 基于用戶的標簽（用戶年齡、性別等）推薦物品

這三種方式都可以召回一定數量的商品，形成用戶感興趣的商品的候選集。

最好是能做到每種召回方式都相互獨立，這樣當其中的一種召回方式效果不好時可以快速的切換。

特別是在前期，可以每種召回算法單獨的運行，通過A/B Test找出最好的推薦引擎。

第二步是過濾

把候選集內的商品經過一定的規則，過濾掉有問題的商品。

比如用戶曾經買過的商品、某些質量很差的商品等。

第三步是排序

每種召回算法都會給出一個推薦結果，格式基本上都是某人喜歡某個商品概率是多少。

這里就會產生一個問題，比如召回算法A推薦出商品a，喜歡的概率是0.9，召回算法B推薦出結果b，喜歡的概率也是0.9。

那么我們應該將a、b那個商品推薦給用戶？因為商品a、商品b是在不同的標準推薦出來的，所以沒有可比性，就好比每個省的都有一個高考狀元，這兩個省的高考狀元那個更厲害一點呢？因為用的是不同的試卷，所以沒辦法評估那個更厲害。

所以就需要排序層再進行一個統一的入學考試，那個狀元考的分數高，就說明那個狀元更加厲害。

排序層就是為了解決這個問題，把候選集中所有的商品經過排序算法統一進行一次用戶感興趣程度的排序。

最后有了候選結果集，由后端工程師通過接口的方式推送給產品線，由產品線負責推薦結果的顯示。

2.2 推薦系統技術架構

如圖2-4是一個典型的推薦系統技術架構，包含了實時推薦、非實時推薦的技術實現。

圖2-4推薦系統技術架構

第一步是產品線的用戶產生的數據包括用戶行為數據、用戶產生的業務數據，這些數據都可以作為實時推薦、離線推薦的數據源。

行為數據通過消息隊列傳輸到日志文件或者直接供實時推薦引擎使用。

業務數據存儲在業務數據庫，由數據中臺同步到數據中臺的數據倉庫。

第二步是執行實時層、離線層的計算任務。

實時層采用流式計算框架如Flink等獲取用戶近一段時間或者近幾次行為可能偏好的商品，再通過偏好的商品，從商品庫中計算用戶可能感興趣的商品形成候選結果集。

離線計算任務一般執行一些離線算法，如基于用戶的協同過濾，基于商品的協同過濾，排序算法等，離線任務偏重基于用戶的長期興趣找到用戶剛興趣的商品。

第三步是實時推薦結果和離線推薦結果的整合。

實時推薦的結果一般存儲在內存數據庫中如Redis，離線任務計算好的結果一般存儲在MYSQL。

實時的推薦結果和離線的推薦結果通過一定的規則整合起來形成用戶最終的推薦結果。

第五步是推薦結果的展示。

當前端發起請求查詢用戶的推薦結果時，比如點擊了猜你喜歡模塊，產品線通過接口的方式請求推薦系統，由推薦系統返回第四步整合后的推薦結果。

三、推薦系統實施流程

推薦系統在是一個比較大的項目，剛開始接觸時可能會覺得無從下手。

推薦系統屬于AI系統，需要大量的算法支撐。

AI 系統需要靈活地支持各類 AI 任務，解決各類任務敏捷化過程中的需求與痛點。

當前，企業智能化需求各不相同，導致相應的 AI 任務也種類繁多。

我們按照面向業務和非面向業務可以把AI系統的任務分為兩種，如下圖2-5所示：

圖2-5 AI系統任務劃分

第一種是針對某個業務領域內特定類型數據，提供對此類數據的基礎 AI 學習、預測、分析能力的計算任務，例如計算機視覺、自然語言處理任務等。

這種任務很多時候其本身并不直接解決業務需求，常作為基礎模型對數據進行初步加工，再由一些面向業務的任務來對接需求。

這也給算法實施團隊充足的時間對橫向任務模型進行充分的雕琢，對其敏捷性進行完善。

這部分屬于AI系統底層通用能力，不過多展開。

第二種則是面向業務具體需求的、如電商領域的推薦系統以及比較常見的用戶畫像構建、智能問答等。

實施AI項目的整個流程如下圖2-6所示：

圖2-6 AI項目實施流程

第一步也是需求的定義比如我們推薦系統要解決人貨匹配的問題；接下來需要準備數據、處理數據，這里時數據中臺的數據開發工程師承擔；接下來的特征工程、模型建立及模型的效果評估等算法相關的模塊需要算法工程師、標注工程師等角色共同參與完成的。

也就是說數據中臺的團隊只需多增加算法團隊，就可以完成AI項目的實施。

那么數據中臺和AI系統的關系就比較清晰了，補充了算法團隊，推薦系統可以當做數據中臺的一部分。

四、幾種經典的推薦算法

4.1 用戶協同過濾算法

生活中對于我們個人來說是怎么找到我們喜歡的商品呢？比如你要買一個襯衫，你可能會看一下或者問一下周圍的朋友都穿的什么，在朋友的影響下，如果近期你真的想買衣服，那么有很大概率會偷偷去網上看一下或者去線下的實體店看一下這件衣服。

在推薦系統中，這也是一種給用戶推薦感興趣商品的方法，叫基于用戶的協同過濾。

比如在電商產品中，推薦系統的做法也是同樣的思路，找到和用戶相似度比較的高用戶，然后基于和他相似用戶喜歡的商品推薦給用戶他有可能喜歡的商品。

在互聯網產品中，我們怎么定義那些商品是用戶喜歡的商品呢？可以通過用戶的行為打分的方式，比如用戶瀏覽了某個商品我們打1分，用戶收藏了某個商品我們給3分，用戶加購了某個商品我們給5分，用戶下單了某個商品我們給7分，這樣給所有產生過用戶行為的商品都打分，最高分可以定義為用戶最喜歡的商品，最低分相對來說用戶大概率沒那么喜歡。

基于上面的思路，我們可以看出基于用戶的協同過濾主要分為2個步驟：

1. 找到和目標用戶興趣相似的用戶集合
2. 找到這個集合中用戶最喜歡的，且目標用戶沒有聽說過的物品推薦給目標用戶

我們先看第一步怎么算，通常用Jaccard公式或者余弦相似度計算兩個用戶之間的相似度。

設N(u)為用戶u喜歡的物品集合，N(v)為用戶v喜歡的物品集合，那么u和v的相似度怎么計算呢？

Jaccard 公式：

余弦相似度：

假設目前共有4個用戶：A、B、C、D；共有5個物品：a、b、c、d、e。

用戶與物品的關系（用戶喜歡物品）如下圖2-7所示：

圖2-7用戶與物品的關系

如何一下子計算所有用戶之間的相似度呢？為計算方便，通常首先需要建立“物品—用戶”的倒排表，比如物品a被A、B兩個用戶喜歡，物品b被A、C兩個用戶喜歡等。

具體如下圖2-8所示：

圖2-8用戶與物品的關系

然后對于每個物品，喜歡他的用戶，兩兩之間相同物品加1。

例如喜歡物品 a 的用戶有A和B，那么在矩陣中他們兩兩加1。

如下圖2-9所示：

圖2-9加1操作計算后的矩陣

計算用戶兩兩之間的相似度，上面的矩陣僅僅代表的是公式的分子部分。

以余弦相似度為例，對上圖2-10所示進行進一步計算：

圖2-10經過余弦相似度計算后的矩陣

到此，計算用戶相似度就完成了，可以很直觀的找到與目標用戶興趣較相似的用戶。

接下來我們看一下第二步，首先需要從矩陣中找出與目標用戶u最相似的K個用戶，用集合S(u,K)表示，將S中用戶喜歡的物品全部提取出來，并去除u已經喜歡的物品。

對于每個候選物品i，用戶u對它感興趣的程度用如下公式計算：

其中r_vi表示用戶v對i的喜歡程度，在本例中都是為1，在一些需要用戶給予評分的推薦系統中，則要代入用戶評分。

舉個例子，假設我們要給A推薦物品，選取K=3個相似用戶，相似用戶則是：B、C、D，那么他們喜歡過并且A沒有喜歡過的物品有：c、e，那么分別計算p(A,c)和p(A,e)：

從計算結果來看用戶A對c和e的喜歡程度可能是一樣的，在真實的推薦系統中，只要按得分排序，取前幾個物品就可以了。

基于物品的協同過濾算法有這么幾個問題：

1. 用戶數量往往比較大，計算起來非常吃力，成為瓶頸；
2. 用戶的口味其實變化還是很快的，不是靜態的，所以興趣遷移問題很難反應出來；
3. 數據稀疏，用戶和用戶之間有共同的消費行為實際上是比較少的，而且一般都是一些熱門物品，對發現用戶興趣幫助也不大。

4.2 基于物品的協同過濾算法

如下圖2-11所示，假設有三個用戶和四個物品，分別是橘子、草莓、蘋果和香蕉。

我知道第三個用戶他購買蘋果，接下來，我問你：在其他的三個他沒有購買的物品，橘子，草莓和香蕉里面，第三個用戶可能會最喜歡的哪個？

圖2-11基于物品協同過濾算法案例

我們希望給第三個用戶推薦的物品應該是跟他已經購買的蘋果相似的物品，那什么物品可以和蘋果相似呢？

我們可以這樣思考，什么物品在用戶購買蘋果之后，被同時購買的次數是最多的？

我們先看香蕉，香蕉有沒有跟蘋果同時購買？

有，第一個用戶，他同時購買了橘子、蘋果和香蕉，香蕉我們算它得了一分，因為跟蘋果同時購買了，所以加一分；

那我們再看草莓，草莓沒有任何人買草莓的同時也買過蘋果，草莓得分是0分；

那么再看橘子，第一個用戶，他同時購買了蘋果和橘子，第二人也同時購買了蘋果和橘子，所以說橘子得兩分，它跟蘋果的相似度是2。

這樣我們就發現蘋果跟橘子相似度是2，蘋果和草莓相似度是0，蘋果跟香蕉相似度是1，得出結論：橘子跟蘋果最相似，我們就給第三個用戶推薦橘子，這就是協同過濾的精髓。

這種方法在推薦系統中叫基于物品的協同過濾。

實現的步驟分為三步：

1. 找到目標用戶曾經喜歡的商品
2. 計算物品的相似度
3. 將相似度最高的商品推薦給用戶

接下來我們通過一個簡單的例子，來說明一下這個流程應該怎么實現：

第一步是計算物品之間的相似度。

我們要如何確定物品之間的相似度呢，根據物品歷史被喜歡的情況，假如某兩個物品歷史共同被許多用戶喜歡，則說明這兩個物品是相似的。

假設喜歡物品a的用戶數為N(a)，喜歡物品b的用戶數為N(b)，那么a與b的相似度為：

上述公式可以理解為喜歡A物品的用戶中，有多少比例的用戶也喜歡B，比例越高，說明A與B的相似度越高。

但是這樣的公式有一個問題，如果物品B很熱門，很多人都喜歡，那么相似度就會無限接近1，這樣就會造成所有的物品拿出來，都與B有極高的相似度，這樣就沒有辦法證明物品之間的相似度是可靠的了。

為了避免出現類似的情況，可以通過以下公式進行改進：

第二步是根據物品的相似度和用戶的歷史行為給用戶推薦。

獲得了物品的相似度后，則根據以下公式來計算用戶u對物品b的興趣：

其中，N(u)是用戶喜歡物品的集合，S(b,K)是和物品b最相似的K個物品的集合，Wab是物品a和b的相似度，Rua是用戶u對物品a的興趣。

我們假設：

• 用戶A喜歡：abc，
• 用戶B喜歡：bcd，
• 用戶C喜歡：cd。

那么喜歡一個物品的用戶數為：

• 喜歡a的用戶數：1
• 喜歡b的用戶數：2
• 喜歡c的用戶數：3
• 喜歡d的用戶數：2

那么同時喜歡兩個物品的用戶數為：

• 喜歡ab的用戶數：1
• 喜歡ac的用戶數：1
• 喜歡bc的用戶數：2
• 喜歡dc的用戶數：2

物品相似度為：

ab相似度為：

ac相似度為：

bc相似度為：

cd相似度為：

如果某個用戶對a的興趣度為1，對b的興趣度為2，那么預測他對c，d的興趣度為：

c：1×0.58+2×0.82=2.22

d：0

和基于用戶的協同過濾不同，基于物品的協同過濾首先計算相似物品，然后再根據用戶消費過、或者正在消費的物品為其推薦相似的，基于物品的算法怎么就解決了基于用戶協同過濾暴露的那些問題呢？

• 首先，物品的數量，或者嚴格的說，可以推薦的物品數量往往少于用戶數量；所以一般計算物品之間的相似度就不會成為瓶頸。
• 其次，物品之間的相似度比較靜態，它們變化的速度沒有用戶的口味變化快；所以完全解耦了用戶興趣遷移這個問題。
• 最后，物品對應的消費者數量較大，對于計算物品之間的相似度稀疏度是好過計算用戶之間相似度的

五、推薦系統的評測指標

如何評判一個推薦系統的好壞呢？一般來說分為三種方式：

我們先看下推薦系統的數據指標有哪些：

數據指標又分為兩種，一種是商業指標，看推薦系統的最終交易額相關指標。

我們做推薦系統的目的是為了代替人工給用戶推薦商品，提高效率，實現用戶的千人前面，帶來更多的交易額。

商業指標有以下幾個：曝光次數、商品的PV、商品的UV、商品支付人數、支付金額、支付件數。還有就是點擊率、支付轉化率，點擊率=商品PV/曝光次數，支付轉化率=商品支付人數/商品UV。

接下來我們看看這些指標該怎么計算：

5.1 曝光次數

統計推薦模塊曝光量的方式有2種：

• 一種是通過數據埋點，當用戶在推薦模塊拉取商品時由前端工程師異步上傳數據到埋點日志服務器，再通過解析埋點日志的方式統計曝光次數。
• 有一種是通過后端埋點的方式，當用戶調用拉取推薦商品的接口時由后端工程師記錄當時的推薦場景、算法、用戶，商品ID的集合這些關鍵信息，保存到日志文件，再通過解析日志文件的方式統計曝光次數。

由于前端埋點有5%的丟失率，計算的指標包括交易額，需要比較準確的數據。

采用后端埋點的方式統計曝光量會更加準確一些。

推薦位商品的PV/UV可以通過對推薦位進行常規埋點埋點，由前端工程師開發，當用戶每點擊一次推薦位的商品，就會通過埋點的方式記錄當前的推薦場景，算法ID、商品ID等主要信息。

涉及到交易額的指標包括支付人數、支付金額、支付件數，也需要通過后端埋點的方式采集，在前文已經講過，因為電商產品的交易流程有一個斷層，用戶一般都是先加購再下單，這個斷層就會增加前端埋點和數據解析的難度。

簡單的做法是在訂單中增加下單來源字段，記錄商品的推薦場景，算法ID等信息到購物車，一般來說購物中的數據是存在內存數據庫redis里面，用戶下單時再從redis中取出放入訂單中，這樣就保證了數據能夠整個鏈條的記錄下來，功能如下圖2-12所示。

圖2-12推薦系統監測指標

還有一種指標是來優化推薦算法的，包括準確率、召回率、覆蓋率也是評價推薦系統算法很好的指標，我們先看一下這三個指標是怎么定義的。

舉個例子，比如給用戶推薦了100個商品，其中10個用戶做了點擊，那么準確率就是10%。

計算準確率要對推薦的商品列表頁做埋點，用戶每點擊一次推薦頁商品就會上傳商品的ID、用戶ID，這樣才能記錄用戶到底點擊過那些商品。

5.2 召回率

召回率怎么定義呢？

還是這個例子比如給用戶推薦了100個商品，其中10個用戶做了點擊，用戶在我們電商網站一共查看了50個商品，那么推薦系統召回率就是20%。

5.3 覆蓋率

比如我們電商網站一共1萬個SKU，給所有的用戶推薦出來SKU為8000，那么這個推薦系統的覆蓋率就是80%，覆蓋率為100%的推薦系統可以將每個物品都推薦給至少一個用戶。

覆蓋率是供應商會比較關注的指標，供應商關系他們的商品有沒有推薦給用戶。

當推薦系統搭建好之后可以先組織公司內部人員做測試，比如筆者公司電商產品定位是女裝批發平臺，主要客戶是女性，推薦系統上線前，我們就招募了公司一部分女員工做了測試。

這些女員工平時在我們的電商平臺也會購買一些女裝，已經積累了一些數據。

做灰度測試時，我們的推薦系統最好是能做成準實時，讓用戶有了新的行為如點擊、加購等，再次刷新就能出現新的他們感興趣的商品，這樣也便于我們及時收到反饋。

我們可以手工統計一下數據比如單個用戶的準確率和召回率。

可以先不要告訴他們這次活動的目的，給他們5分鐘讓他們逛平臺，唯一讓他們做的就是記錄每次查看的商品名稱和位置，這樣可以方便我們計算出召回率。

接下來可以讓他們關注下推薦模塊，讓他們記錄推薦了多少個商品，點擊了其中的多少個商品，這樣可以直接算出來準確率。

最后再問幾個核心問題，如果我們的推薦系統滿分是10分，他們給幾分，為什么打這樣的分數，有無其他的一些建議給我們。

注意觀察他們的情緒及眼神。

當我們經過內部這一輪內部測試會發現一些問題，可以針對問題進行針對性的修改，當優化出一個穩定的版本后，可以和運營合作邀請幾個真實的用戶用戶來試一下，測試用戶的分布要大致保證和真實用戶相同如年齡，活躍度等相關智能表的分布。

可以設計一套方案，讓他們參與進來，體驗我們的推薦模塊，這時可以通過后臺收集埋點數據的方式計算這批用戶的準確率和召回率。

六、推薦系統的冷啟動

從上文來看，推薦系統依賴用戶的歷史行為數據，像某貓、某狗這塊大型電商網站，有大量的用戶歷史行為數據可以利用。

但是對于一般的推薦系統，特別是剛起步階段，一般是沒有用戶行為數據的，這個時候該該怎么辦，這也是推薦系統一個比較核心的問題叫“冷啟動”問題。

冷啟動主要分為以下幾種：

• 用戶的冷啟動：這個主要解決給新用戶如何推薦商品的問題。當新用戶剛進系統是沒有歷史行為數據的，我們無法通過推薦系統給用戶做個性化推薦。
• 物品冷啟動：這個主要解決一個新的物品怎么推薦給他可能感興趣的用戶。
• 系統的冷啟動：一個新開發的產品，只有少量的商品，還沒有用戶。讓用戶上線時就可以體驗到個性化推薦服務這個問題。

如何解決這些問題呢，在這里提供一些方案供參考：

6.1 利用用戶注冊信息

用戶注冊都要填一些信息，比如性別、年齡、第三方登錄等信息。

比如我們可以對用戶的注冊信息做一個分類，針對不同的性別，和不同的年齡段推薦不同的商品。

我們還可以通過用戶的第三方登錄信息，在用戶授權的情況下通過社交網絡數據拿到用戶好友喜歡的一些商品，再推薦給用戶，因為都是用戶熟悉的朋友，那么他們朋友喜歡的商品，大概率他們也會喜歡。

6.2 讓用戶主動選擇自己喜歡的商品

主要方式就是可以讓用戶選擇喜歡的商品或者品類，基于用戶選擇的結果進行推薦。

如下圖2-13所示，可以讓新用戶登錄后選擇自己偏愛的品類，當用戶選擇后，他的商品列表就會基于他選擇的結果進行推薦。

也可以基于熱銷的商品推薦給用戶，讓用戶選擇，再基于用戶的選擇推薦合適的商品。

圖2-13讓用戶選擇偏好品類

6.3 利用物品的內容信息

物品的冷啟動也是一個需要解決的問題，電商網站每天會更新大量的商品，如果新的商品得不到推薦，那么會影響到用戶的體驗，也得不到業務部門的支持。

電商網站一般用基于商品的協同過濾，協同過濾的核心是認為物品A和物品B有很大的相似度的原因是因為喜歡物品A的用戶大多數也喜歡物品B，可以看得出物品的協同過濾是很依賴用戶的行為數據的，因為用戶的行為數據決定用戶是否會喜歡這件商品。

但是對于新物品是沒有用戶行為數據的，就很難推薦到新物品，就算是有用戶對商品產生了行為，那么商品之間的相似度也是需要大量的計算，無法做到及時反饋給用戶。

那么怎么解決這個問題呢？

我們可以利用物品的內容信息，比如對于一個衣服來講衣服的名字，品類，品牌，價格段都是物品的內容信息。

如果做了商品的價格段標簽那么可以精準推薦到同品牌、同品類下同價格段的商品那個適合用戶，比如同品牌、同款、同價格段的毛衣。

商品的名字也有多的內容信息。

我們可以針對商品名稱，建立分詞庫，基于分詞給商品打上標簽，可以基于標簽給用戶推薦類似標簽的商品。

七、從0到1打造一個離線推薦系統

7.1 離線推薦系統的設計思路

首先還是要定一個目標，參考所有電商類的產品，實時的推薦系統已經算是一個標配，那么我們的目標就是做一個實時的推薦系統，但目前的情況是我們還沒有推薦系統，一步到位做到實時推薦系統還是有些難度。

那么第一階段目標是設計一個離線的推薦系統，可以做到隔天推薦，第二階段可以基于這個離線的推薦系統進行改造做成實時推薦系統。

推薦系統最核心的地方是召回算法的選擇，在剛開始搭建推薦系統時可以選擇一些經過驗證的、邏輯清晰、運營穩定的找回算法。

筆者所在公司做電商產品，于物品的協同過濾、基于商品內容的推薦算法都比較適合電商產品，一些大型的電商巨頭如亞馬遜、淘寶也都在使用，方向一般不會錯誤。

7.2 離線推薦系統的算法選型

實際項目中用的第一個召回算法是基于物品的協同過濾。

推薦系統系統最基礎的算法是基于用戶的協同過濾和基于物品的協同過濾，這是標配。

上文也講到了這兩個算法的優缺點，電商產品還是比較適合基于物品的協同過濾，基于物品的協同過濾最核心的原理是是如果大多數人買了商品A的同時又買了商品B，那么我們就可以向買了商品A的用戶推薦商品B。

實際項目中用到的第二個召回算法是基于商品分詞的算法。

整體思路是先基于用戶的歷史行為數據找出用戶可能喜歡的商品，將商品名稱通過ES搜索引擎進行分詞操作，并且給每個分詞進行打分，然后通過分詞搜索商品庫中能夠匹配到的商品，搜索引擎會自動給出匹配的分數。

比如一個用戶喜歡的商品名稱為：秋冬新款韓版破洞寬松長袖T恤，分詞后就可以得出用戶偏好的分詞如秋冬、新款、破洞、寬松等，在通過這些分詞在商品庫中搜素就能得到可能和秋冬新款韓版破洞寬松長袖T恤相似的商品。

這種推薦方式也屬于內容推薦的一種，實現較為簡單。

在冷啟動的情況下會用到保底算法，實際項目用到的保底算法是基于商品的熱度的模型。

定義了商品近60天的銷售指數，從商品的瀏覽人數，加購人數，收藏人數分別賦予不同的權重，用來計算商品的熱度。

對于一個新用戶或者各種召回推薦算法并沒有算出用戶感興趣的商品，可以基于用戶的品類偏好在熱銷商品中篩選出基于用戶偏好的熱銷商品。

如果無法確定用戶的偏好，可以直接推薦熱銷的商品給用戶。

接下來是排序算法的選擇。

每個召回算法都會計算出用戶感興趣的商品，那么這些召回算法推薦出來的商品，我們把那些商品推薦給用戶呢？上文已經講到既然每個地方出來的狀元都相互不服，那么我們不如再統一進行一次入學考試，通過考試的成績再統一決定，讓那些商品推薦給用戶。

推薦的最終目的是讓用戶瀏覽我們的商品，最理想的是購買我們的商品，第一步是點擊，我們只需預測出用戶是否會點擊我們的商品即可，這個指標叫CTR點擊率。

常見的排序算法有哪些呢？

1. GBDT（梯度提升決策樹）+LR（邏輯回歸）
2. FM（因子分解機模型）

在這里簡單講一下 GBDT+LR,我們只講算法的大概意思，不講具體實現，具體實現可以參考AI算法相關書籍。

預測CTR需要兩個東西：特征和權重。

特征比較好理解比如一個用戶的年齡，地址，一個用戶近期瀏覽過這個品類的的商品幾次，加購過這個品類的的商品幾次類似等等。

權重就是一個用戶如果瀏覽過這個品類我們覺得用戶40%可能喜歡這種品類，一個用戶如果加購過這個品類我們覺得用戶60%可能喜歡這種品類，那么用戶加購的權重就更大。

GBDT的具體做法可以這樣理解，想象不斷對一個用戶不斷提問：是女用戶嗎？是的話再問：喜歡毛衣嗎？是的話則可以問：喜歡那個價格段的毛衣？

這種不斷提問按照層級組織起來，每次回答答案不同后再提出不同的問題，直到最后得出最終答案：用戶對這個推薦會滿意嗎？這就是GBDT樹模型。

樹模型天然就可以肩負起特征組合的任務，從第一個問題開始，也就是樹的根節點，到最后得到答案，也就是葉子節點，這一條路徑下來就是若干個特征的組合。

GBDT的好處是自動挖掘用戶的特征，得到最佳的特征組合，省去特征工程大量繁瑣的過程。

實際項目中可以找產品線的產品經理和運營一下討論下推薦方案方案，他們對業務更加了解。

這個項目我們產品線的同事也提了幾個比較好的問題：

1. 筆者所在公司的電商產品比較特殊，定位快時尚女裝，幾乎每天都會有上新，上新的產品7天后基本都沒有貨了，這對于推薦算法來說是很大的挑戰。

我們討論后的解決方案是針對商品打上新舊款的標識，怎么打上新舊款的標識呢？因為商品都放在專場內，專場都有開始時間和結束時間。

如果商品所在的專場都是未結束，那么我們會給商品打上新款的標識。

如果商品都在已經結束的專場，那么我們會給商品打上舊款的標識。

因為新款一般不會有太多的交易數據，所以基于物品和用戶的協同過濾都推薦出很少新款，可以提高基于內容的推薦算法的權重，這樣就能找到新款商品。

2. 處于實際的業務場景，需要加一些過濾條件

比如下架的商品，用戶n天內購買過的商品，我們需要在用戶最終的推薦結果中剔除。

還有一些退貨率比較高的商品我們設置了一個閥值，如果退貨率超過n%，那么會將這些商品從用戶的推薦列表統一剔除。

3. 考慮商品的上架時間和用戶訪問高峰期因素

因為筆者所在公司的商品一般都是早晨10點左右上架一次商品，下午18點左右上架一次商品，中午12點左右和晚上20點左右是用戶訪問的高峰期。

如果推薦算法的的計算引擎只在晚上計算，早晨10點和下午18點上架的商品大部分都不能推薦出來。

這時候需要調整我們的計算調度，也就是在中午12點左右進行一次計算，保證上午10點左右的新品都能出現在用戶的推薦列表，在下午19點進行一次計算，保證18點上架的新品也能出現在用戶的推薦列表。

7.3 離線推薦系統開發過程

接下來可以讓數據開發工程師準備推薦算法需要的幾類數據，第一個是用戶的基礎數據如下圖2-14所示，此類數據可以用來挖掘用戶的特征。

圖2-14用戶基礎數據

第二個是用戶行為的數據，如下圖2-15所示，用戶在什么時間對商品有瀏覽，加購、下單等行為，是召回算法的基礎支撐數據。

圖2-15用戶行為數據

第三個是商品相關的數據，如下圖2-16所示，比如商品的品類，是否上下架等商品的基礎信息。

可以讓算法工程師快速拿到商品的相關信息。

圖12-16商品基礎數據

當算法工程師和數據開發工程師按照找回算法和排序算法完成開發后，就會形成最終用戶的推薦結果，一般存儲在MYSQL等關系型數據庫，通過接口對外提供服務。

每個用戶最終的推薦結果格式如下:

• 用戶ID：用戶的唯一標識
• 商品ID：商品唯一標識
• 召回算法ID：召回算法的唯一標識，便于統計召回算法的效果
• 點擊率：用戶點擊的概率，一般是0-1的小數
• 計算時間：產生推薦結果的時間，一般存儲近幾次的計算結果

基于推薦結果的數據，后端開發工程師就可以開發對外的服務接口，具體如下表所示：

為了完成推薦系統，只有數據中臺的團隊并不行，還需要產品線的產品經理和運營的配合。

首先要在產品的功能界面預留一個位置，類似淘寶、京東的猜你喜歡，這個可以基于自己的產品特性來選擇位置。

電商線的產品經理需要協調前后端開發處理推薦位置的前后端開發及埋點開發，前后端開發是調用數據中臺的推薦接口，完成推薦功能界面的開發，數據埋點要解決2個問題。

第一是要知道每個場景，每個算法，每天的交易額。

當用戶加購時，要把場景ID，算法ID，同商品一塊加入購物車。

當用戶下單時再將場景ID，算法ID一并加入進貨車。

第二我們要統計每天有哪些用戶 訪問我們的推薦場景，點擊了那些商品，這個針對前端可以做常規的埋點，埋點的做法可以參考第二章數據采集模塊。

有了這些埋點數據就可以計算推薦位每天產生的總交易額，總訪問用戶數等相關商業指標，也可以通過查看每個算法的準確率，召回率，覆蓋率這三個指標，來找到最合適的算法。

數據中臺主要承擔算法的開發與推薦接口的開發以及后面推薦系統的數據源分析。

第三步運營需要配協調UI資源，設計推薦位的LOGO，推薦位背景圖等工作。

推薦系統的方案設計大概需要一周的時間，另外需要3天的時間評審方案，電商線的產品經理針對前后端和埋點的開發大概需要一周的時間，數據中臺針對算法的開發大概需要1個月的時間。

第一個版本預計整體時間需要2個月的時間，其中大概用半個月定整體方案和細節的部分，其他都是各個角色開發的時間。

7.4 離線推薦系統的測試

至此推薦系統的整個開發流程就結束了，接下來是推薦系統的測試。

為了方便測試可以開發一個快速拿到用戶推薦結果的界面方面產品和測試去查看數據。

主要包含三塊內容：

1. 可以快速查詢每種召回算法每個用戶的推薦結果
2. 排序算法每個用戶的最終推薦結果
3. 給用戶展示的最終推薦結果

查詢推薦結果的功能最好有商品的圖片，這樣會比看商品名稱更加直觀，具體界面如下圖2-17所示，可以快速篩選某個算法，某個用戶在某天的推薦結果。

圖2-17用戶推薦列表

首先要針對召回算法進行測試，召回算法主要測試算法的邏輯是否正確。

比如基于商品的協同過濾，最核心的原理是買了商品A的人大多數又買了商品B，如果商品B是用戶預測點擊率最高的商品，那么同時買了A和B的人數應該也是最多的。

一般來說算法工程師和測試工程師合作完成測試用例的驗證，算法工程師按照測試工程師的要求提供數據，測試工程師負責驗證算法邏輯的準確性。

第二步需要對排序算法的結果和用戶最終的推薦結果進行測試。

因為邏輯比較復雜，這兩個步驟測試起來就很有挑戰性。

在這里推薦一個簡單的方法，項目組可以一起定義幾個典型用戶比如：

1. 無用戶行為的用戶
2. 有歷史行為數據，但是很久沒來訪問的用戶
3. 有歷史行為數據并且最近很活躍的用戶

對于第一種用戶來說，可以驗證一下此類用戶的推薦結是否和冷啟動的策略一致。

對于第二類用戶來說雖然有歷史行為，但是歷史行為的數據已經很久，無法再去利用，基于制定的策略需要驗證一下此類用戶的推薦結果是否和我們的策略相符合。

第三類用戶可以讓算法工程師基于他最近的行為輸出他喜歡的商品，然后基于他喜歡的商品核對推薦的商品是否有很大的誤差，比如用戶喜歡50-100的牛仔褲，我們推薦的結果都是500以上的牛仔褲，那么就有問題了。

最后還需要對過濾的規則進行測試，比如用戶近期買過的商品不能出現在推薦列表，退貨、缺貨率很高的商品不能出現在推薦列表等規則的測試。

八、從0到1打造一個實時推薦系統

本章介紹一下從0到1搭建一個實時推薦系統的全過程。

先看一下什么是實時推薦系統。

實時的推薦系統已經成為大廠電商產品的標配，我們拿淘寶舉個例子，當用戶瀏覽或者加購一個新的商品，過幾秒再刷新推薦模塊，立即就推薦出來好多類似的商品。

還有比如我們在刷抖音，刷今日頭條，刷的內容越多，展示的內容就越來越接近我們的興趣，這些公司是怎么做到以這么快的速度推薦出用戶喜歡的內容的呢？

用戶感興趣的內容有個黃金期的，上文講的離線推薦系統，因為算法計算任務的限制，第二天才能推薦出用戶昨天感興趣的商品，可能第二天用戶看到這個商品，已經失去了興趣，這時我們就要引入一套實時的推薦算法。

如下圖2-18所示是一個比較典型的實時推薦系統的功能架構：

圖12-18實時推薦系統架構

第一步是獲取用戶短時間內的興趣，比如用戶近幾次的行為或者近一段時間內的行為數據如瀏覽、點擊、收藏、加購、下單了某些商品，可以把用戶近幾次會話訪問或者點擊的商品，緩存在客戶端，然后通過實時的消息隊列的方式，如開源的kafka，將用戶近期訪問日志實時的傳到推薦服務器，這樣推薦服務就可以實時的接收到用戶最新的行為數據。

接下來是計算用戶感興趣的商品，通過設定不同的權重找到用戶感興趣的商品列表。

假設我們設置的權重是如果用戶訪問訪問了一個商品，這個商品就得1分、收藏一了一個商品得2分、加購了一個商品5分、下單了一個商品得7分。

假設我們取近5次的用戶行為數據，比如一個用戶近五次行為數據包含：

• 訪問了二次商品A
• 收藏了一次商品B
• 加購了一次商品C
• 下單一次商品D

基于用戶近5次的行為數據并進行歸一化處理后可以得出用戶對A/B/C/D的興趣度分別為：

• 商品A：2分
• 商品B：2分
• 商品C：5分
• 商品D：7分

基于這5次行為內的數據可以看出用戶比較喜歡商品D和商品C。

第二步是通過用戶感興趣的商品列表在庫中找相似的商品

這里就需要一套實時召回算法，能在2秒內計算好召回結果，可以通過流計算處理平臺如Flink實時計算用戶喜歡的商品，由于用戶的興趣數據一直在變化，也需要同時更新召回算法結果集中的商品之間的相似度，從而找到與用戶近幾次訪問或者加購的商品最像似的topN個商品。

在算法層面基于物品的協同過濾和用戶的協同過濾算法不適合用在這個場景，因為復雜度比較高，計算時間比較長。

作為電商產品，商品的描述有大量的信息包括商品的名稱、店鋪、品類、價格段，基于這些信息可以做基于品類價格段的推薦算法。

第一優先級是推薦同店鋪、同品類、同價格段的商品，第二優先級是不同店鋪、同品類、同價格段的商品，第三優先級是同店鋪、同品類、不同價格段的商品，第四優先級是不同店鋪、同品類、不同價格段的商品等，這個算法認為品類是第一優先級，價格段是第二優先級，店鋪是第三優先級。

比如基于用戶的行為數據發現他喜歡一件毛衣，這時可以推薦給他一件同店鋪，價格段差不多的毛衣，如果沒有同店鋪，價格段差不多的毛衣，則推薦給他不同店鋪，價格段差不多的毛衣，就這樣可以按照指標的優先級一直排下去。

比如我們按照以下規則來排序：

1. 同店鋪、同品類 、同價格段的新款 （0.875,1]
2. 不同店鋪、同品類、同價格段的新款 (0.75,0.875]
3. 同店鋪、同品類、不同價格段的新款 (0.625,0.75]
4. 不同店鋪、同品類、不同價格段的新款(0.5,0.625]
5. 同店鋪、同品類 、同價格段的老款 (0.375,0.5]
6. 不同店鋪、同品類、同價格段的老款 (0.25,0.375]
7. 同店鋪、同品類、不同價格段的老款 (0.125,0.25]
8. 不同店鋪、同品類、不同價格段的老款[0,0. 125]

上文已經得出用戶對商品D比較感興趣，假如與商品D同店鋪、同品類 、同價格段的新款有商品E和商品F，可以計算一下商品E和商品F的熱度，如果商品E銷量比較好，那么商品E的的得分就是1分，商品F的得分就是0.875.

最終算出E的得分1分、商品F的得分就是7×0.875=6.125。

按照這種方式可以將用戶感興趣的商品D、C、B、A都進行計算，最后就可以得出一個分數有高到低的實時商品推薦列表，可以基于業務需求，比如TOP50做為候選結果集。

第三步是要解決離線的推薦結果和實時的推薦結果如何結合的問題。

最理想的方式是通過上文提到的GBDT+LR排序算法將實時推薦結果和離線推薦結果進行統一排序，但是這套排序算法也是相對來說比較復雜，不能做到幾秒內出結果。

解決方案是我們可以人工定義一下實時推薦和離線推薦的優先級，推薦結果都是分頁顯示的，有以下幾種方式：

第一種方式是前幾頁顯示實時結果，后面顯示離線結果。

這種方式是默認實時推薦結果的優先級是大于離線結果的，問題是我們耗費了那么多資源來算用戶的離線結果，但是卻沒有得到曝光，因為如果用戶前幾頁都沒瀏覽，后面的頁面瀏覽的幾率就比較小了。

第二種方式可以采用交叉顯示的方式，比如第一頁一共有10個商品，前3個商品顯示實時推薦結果，后面7個顯示離線推薦結果，第二頁同樣如此。

這種方式實時的推薦結果和離線的推薦結果都有曝光，資源利用率相對來說比較大。

#相關閱讀#

《數據中臺實戰（九）：如何搭建全渠道自動化的平臺》

《數據中臺實戰（八）：如何打造可以支撐N條產品線的標簽平臺》

《數據中臺實戰（七）：流量分析》

《數據中臺實戰（六）：交易分析》

《數據中臺實戰（五）：自助分析平臺》

#專欄作家#

Wilton華仔，微信公眾號：改變世界的產品經理，人人都是產品經理專欄作家。

產品經理能力咨詢，教你從0到1搭建數據中臺。

本文原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash， 基于CC0協議。