數據中台：從0到1打造一個離線推薦系統

之前文章講了《數據中台：2個實戰案例教你搭建自動化營銷平台》；這篇文章我們以一個電商類推薦系統項目為例，介紹從0到1搭建一個離線推薦系統的全流程。

一、離線推薦系統設計思路

對於電商類產品來説，實時的推薦系統已經是標配的功能，因此我們的目標是做一個實時的推薦系統，但如果我們還沒有推薦系統，那麼一步做出實時推薦系統還是有些難度的。

我們可以分兩個階段實施，第一階段先設計一個離線的推薦系統，做到隔天推薦，第二階段再基於這個離線的推薦系統進行改造，做出實時推薦系統。

搭建推薦系統的核心問題是召回算法的選擇，在剛開始搭建推薦系統時可以選擇一些經過驗證的、邏輯清晰、運營穩定的召回算法；基於物品的協同過濾算法、基於商品內容的推薦算法都比較適合電商產品，一些大型的電商巨頭如亞馬遜、淘寶也都在使用。

二、離線推薦系統算法選型

在實際項目中，我們使用的第一個召回算法是基於物品的協同過濾算法。

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

上文曾提到這兩個算法的優缺點，對於電商產品來説，其實更適合使用基於物品的協同過濾算法，該算法的核心原理是：如果大多數人購買商品a的同時又購買了商品b，那麼我們就可以向買了商品a的用户推薦商品b。

在實際項目中，我們使用的第二個召回算法是基於商品分詞的算法。整體思路是：先基於用户的歷史行為數據找出用户可能喜歡的商品，將商品名稱通過ES搜索引擎進行分詞操作，並且給每個分詞進行打分，然後通過分詞搜索商品庫中能夠匹配到的商品，搜索引擎會自動給出匹配的分數。

比如一個用户喜歡的商品的名稱為“秋冬新款韓版破洞寬鬆長袖T恤”，通過分詞處理後就可以得出用户偏好的分詞有秋冬、新款、破洞、寬鬆等，通過這些分詞在商品庫中搜素就能得到可能和“秋冬新款韓版破洞寬鬆長袖T恤”相似的商品；這種推薦方式也屬於內容推薦的一種，實現起來比較容易。

在冷啓動的情況下，我們會用到保底算法。在實際項目中，我們使用的保底算法基於商品的熱度模型。商品的熱度模型定義了商品近60天的銷售指數，商品的瀏覽人數、加購人數、收藏人數等指標被分別賦予不同的權重，用來計算商品的熱度。對於一個新用户，或者一個使用各種召回推薦算法都沒有算出感興趣商品的用户，我們可以在熱銷商品中篩選出基於用户偏好的熱銷商品。如果無法確定用户的偏好，我們可以直接推薦熱銷的商品給用户，這是保底策略。

接下來要選擇排序算法，每個召回算法都會計算出用户感興趣的商品，那麼我們如何從這些召回算法推薦出來的商品中選出一部分推薦給用户呢？

前文已經講過——如果每個地方出來的狀元都彼此不服，那麼我們就再統一進行一次考試，通過考試的成績決定，也就是將這些不同算法推薦出來的商品進行排序；推薦的最終目的是讓用户瀏覽我們的商品，最理想的結果就是讓用户購買我們推薦的商品。我們需要預測用户是否會點擊我們的商品，從而根據預測的點擊率排序。

接下來筆者介紹一下推薦算法中常用的排序算法：“GBDT+LR”算法。

筆者簡單介紹一下“GBDT+LR”算法。GBDT（Gradient Boosting Decision Tree），即梯度提升決策樹；LR（Logistic Regression），即邏輯迴歸。使用“GBDT+LR”算法預測點擊率需要兩個數據：特徵和權重。

特徵比較好理解，比如一個用户的年齡、地址，該用户近期瀏覽過某品類的商品的次數，加購過這個品類的商品次數類似等，都是特徵。

權重是由人工制定並通過數據再不斷優化的參數。比如一個用户如果瀏覽過這個品類，我們覺得用户有40%的可能喜歡該品類；一個用户如果加購過這個品類，我們覺得用户有60%的可能喜歡該品類。這裏面的40%和60%，就是我們設定的權重。

GBDT模型的具體操作可以理解為：不斷對一個用户提問。

• 比如向用户提問：是女性用户嗎？
• 如果答案為“是”，再問：喜歡毛衣嗎？
• 如果答案為“是”，再問：喜歡哪個價格段的毛衣？

這些提問按照層級組織起來。對於不同答案再提出不同的新問題，直到最後得出最終答案：用户對這個商品滿意嗎？這就是GBDT模型。該模型天然可以肩負起組合特徵的任務，第一個問題相當於樹的根節點，最後得到的答案相當於葉子節點，整條提問路徑就是若干個特徵的組合。

GBDT的優點是自動挖掘用户的特徵，得到最佳的特徵組合，省去構建特徵工程的煩瑣工作。

邏輯迴歸（Logistic Regression, LR）又稱為邏輯迴歸分析，是分類和預測算法中的一種，通過歷史數據的表現對未來結果發生的概率進行預測；例如，我們可以將用户喜歡某商品的概率設置為因變量，將用户的特徵屬性，例如性別，年齡，註冊時間、偏好品類等設置為自變量。根據特徵屬性預測用户對某件商品喜歡的的概率。

在實際項目中，我們可以找產品線的產品/運營人員一起討論下推薦方案。他們對業務更瞭解，可能會提出一些好的建議；比如筆者在構建推薦系統過程中，同公司的產品/運營人員就提出了以下建議。

1）筆者所在公司的電商產品定位快時尚女裝，所以幾乎每天都會新品上架，而新品上架7天后就基本沒有貨了，這種情況給推薦算法帶來很大挑戰；而且新款一般不會有太多的交易數據，無論是基於物品的協同過濾算法，還是基於用户的協同過濾算法只會推薦很少新款。

經過與產品/運營人員的討論，我們決定為商品打上“新款”或“舊款”標識。因為每一件商品都放在某個專場內，而專場都有開始時間和結束時間。如果商品所在的專場沒有結束，那麼我們會給商品打上“新款”標識；如果商品所在的專場已經結束，那麼我們會給商品打上“舊款”標識。如此一來，只要提高基於內容的推薦算法中“新款”標籤權重，這樣就能更好地推薦新款商品。

2）為了應對實際的業務場景，需要增加一些過濾條件。比如對於下架的商品、用户若干天內購買過的商品，我們需要在提交給用户的最終推薦結果中將之去除；對於一些退貨率比較高的商品，我們設置了一個閥值，如果商品的退貨率超過該閥值，那麼這些商品也會在推薦列表中被統一去除。

3）需要考慮商品的上架時間和用户訪問高峯期因素。筆者所在公司的電商平台一般都是在早晨10點左右上架一次商品，在下午18點左右也會上架一次商品，而中午12點左右和晚上20點左右是用户訪問的高峯期，也是用户下單的高峯期。

如果離線推薦系統的計算引擎只在晚上計算，那麼在早晨10點左右和下午18點左右上架的商品，大部分都不能被推薦出來，這就需要調整離線推薦系統的計算調度；首先在中午12點左右進行一次計算，保證在上午10點左右上架的新品都能出現在用户的推薦列表中，然後在下午19左右進行一次計算，保證在18點左右上架的新品也能出現在下一次用户訪問高峯期的推薦列表中。

三、離線推薦系統開發過程

接下來，筆者從工程角度講一下應該如何搭建推薦系統。

1）首先需要數據開發工程師根據推薦算法的需要準備幾類數據。

第一類是用户的基礎數據，如表1-1所示，此類數據可以用來挖掘用户的特徵。

第二類是用户行為數據，如表1-2所示，比如用户在什麼時間對商品有瀏覽、加購、下單等行為。此類數據是召回算法的基礎支撐數據。

第三類是商品相關的數據，如表1-3所示，比如商品的品類、是否上/下架等基礎信息。此類數據可以讓算法工程師快速獲得商品的相關信息。

當算法工程師和數據開發工程師按照召回算法和排序算法的規則完成開發後，就會形成最終用户的推薦結果，一般存儲在MySQL等關係型數據庫中，通過接口對外提供服務。

每個用户獲得的最終推薦結果的參數如下：

• 用户ID：用户的唯一標識。
• 商品ID：商品唯一標識。
• 召回算法ID：召回算法的唯一標識，用於統計召回算法的效果。
• 點擊率：用户點擊的概率，一般是取值在0和1之間的小數。
• 計算時間：產生推薦結果的時間，一般存儲近幾次的計算結果。

基於推薦結果的數據，數據中台的後端開發工程師就可以開發對外的服務接口，如表1-4所示；請求參數包括用户ID、頁碼、每頁商品數量。響應參數主要包括用户ID、推薦商品列表，商品列表可以通過JSON的格式存儲。

2）搭建推薦系統還需要其他部門同事的配合，比如產品線的產品/運營人員。

運營人員需要在產品的功能界面中預留一個位置，類似淘寶網的“猜你喜歡”頻道，可以基於自己的產品特性來選擇位置；運營人員還需要協調UI資源，設計推薦位的LOGO、背景圖等。

電商產品線的產品經理需要協調前/後端開發工程師完成推薦位置的前/後端和數據埋點開發的開發工作。前/後端開發工程師負責調用數據中台的推薦接口，完成推薦功能界面的開發。

數據埋點開發要解決2個問題：

一是要知道每個場景、每個算法、每天的交易額，當用户加購時，要把場景ID、算法ID，同商品一起加入購物車中，當用户下單時再將場景ID、算法ID一併加入結算。

二是我們要統計每天有哪些用户訪問我們的推薦位，點擊了哪些商品，就需要針對推薦模塊做一個常規的埋點，埋點方法可以參考第2章“數據採集”部分內容；有了這些埋點數據，我們就可以計算推薦位每天產生的總交易額、總訪問用户數等相關商業指標，也可以通過查看每個算法的準確率、召回率、覆蓋率這三個指標，來找到最合適的算法。

數據中台主要承擔算法的開發、推薦接口的開發、推薦系統的數據分析等工作。推薦系統的方案設計大概需要1周時間，另外需要3天的時間來評審方案，電商產品線的產品經理進行前/後端和埋點的開發工作大概需要1周的時間，數據中台針對算法的開發工作大概需要1個月的時間。

由此可知，打造一個簡單版本的推薦系統預計共需要2個月左右的時間。

四、離線推薦系統測試

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

為了方便測試，我們可以開發一個快速拿到每個用户推薦結果的功能，方便產品經理和測試人員查看推薦數據。這項開發工作需要滿足三方面要求。

• 可以快速查詢每種召回算法帶給每個用户的推薦結果。
• 可以快速查詢通過排序算法生成每個用户的最終推薦結果。
• 可以快速查詢向用户展示的最終推薦結果。

要想開發查詢推薦結果的功能，最好配上商品的圖片，看商品圖片比看商品名稱，更令人印象深刻，如圖11-13所示，可以快速篩選出某個算法在某天為某個用户推薦的結果。

用户推薦界面

測試工作的流程如下：

1）需要對召回算法進行測試

召回算法主要需要測試其算法的邏輯是否正確。一般來説，算法工程師和測試工程師需要合作完成測試用例的驗證。算法工程師按照測試工程師的要求提供數據，測試工程師則負責驗證算法邏輯的準確性。

2）需要對排序算法的結果和用户最終的推薦結果進行測試

因為邏輯比較複雜，這兩個步驟的測試很有挑戰性。在這裏推薦一個簡單的方法，項目組可以一起定義幾類典型用户，比如：無用户行為的用户；有歷史行為數據，但很久沒來訪問的用户；有歷史行為數據並且最近很活躍的用户。

對於第1類用户，可以驗證一下推薦給他們的結果是否符合冷啓動的策略。

對於第2類用户，他們雖然有歷史行為，但是歷史行為的數據陳舊，無法再利用，需要驗證一下推薦給他們結果是否符合我們制定的策略。

對於第三類用户，可以讓算法工程師基於他們最近的行為，推薦給他們可能喜歡的商品，然後對比他們喜歡的商品，檢查推薦的商品是否有很大的誤差；假如某用户喜歡50～100元價格段的牛仔褲，而我們推薦給他的結果都是500元以上的牛仔褲，那麼推薦結果就有問題了。

3）最後還需要對過濾的規則進行測試

比如對“用户近期買過的商品不能出現在推薦列表中”“退貨、缺貨率很高的商品不能出現在推薦列表中”等過濾規則進行測試。

相關閲讀：

《不以用户價值為目的的數據指標設計就是耍流氓》

#專欄作家#

Wilton董超華，微信公眾號：改變世界的產品經理，人人都是產品經理專欄作家。暢銷書《數據中台實戰》作者，曾任職科大訊飛，現任富力環球商品貿易港數據中台產品負責人。主要分享商業、產品、運營、數據中台相關原創文章。

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

題圖來自 Unsplash，基於 CC0 協議