起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識數據中臺：從0到1打造一個離線推薦系統
編輯導語：如今電商平臺發展的十分迅速，很多用戶都會選擇在各種電商平臺進行消費，并且現在的電商平臺對于推薦算法的機制更加精確；本文作者分享了關于如何從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 協議
- 目前還沒評論，等你發揮！
