資料中臺實戰(十):從0到1搭建推薦平臺

語言: CN / TW / HK

 點選改變世界的產品經理 關注公眾號

回覆 “1” 抽取 簽名書

  1  

什麼是推薦系統

推薦系統的核心是要解決人貨匹配的問題。我們拿電商平臺舉例,作為一個電商平臺,就是為了賣貨,怎麼把我們的貨賣出去並且使用者還比較滿意呢?一定是找到有需求的使用者。當我們平臺有10個使用者,50件單品在賣的時候,如果平臺有一個運營就能搞定所有的事情,運營甚至可以挨個問平臺的10個使用者,他們到底想要那些貨,然後在這50件單品中找到使用者想要的貨人工推薦給平臺的使用者。當用戶發展到一定的規模,比如1萬,5000件單品,運營的做法是給使用者打上各種各樣的標籤,通過標籤形成使用者畫像,再基於使用者畫像做使用者分群,每個群是一類人,那麼高價值的使用者群,一定是特殊對待,傾斜更多的資源,只有針對這些高價值使用者才有精力提供一對一的服務,這樣效率才會最高。可以想一下如果當平臺的使用者已經突破一個億人這麼一個規模,單品突破10萬的規模,我們該怎麼解決人貨匹配的問題呢?

隨著使用者量的增長有一點是不變的,那就是使用者喜歡什麼樣的商品,我們如果瞭解了使用者需要什麼貨,也就能把我們的10萬商品賣出去。推薦就是用數學的方法計算並猜測使用者到底需要什麼商品,通過資料可以計算出使用者到底會喜歡那些商品,只是一個概率,當把這個概率提高到了一定的水平,那麼就可以把這些商品展現給我們的使用者,說不定他就買了我們推薦的商品。

接下來核心問題就比較明顯了。我們應該怎麼計算使用者到底喜歡那些商品呢?答案就是使用者的資料。使用者的資料其實分為隱性資料和顯性資料。隱性資料是什麼?我們的埋點就派上了用場,使用者的每次瀏覽,點選都會記錄這個使用者是誰,什麼時候,在什麼地點,用什麼裝置,來看我們的那個商品,看了多久。這些資料對判斷使用者是否對該件商品感興趣是有價值的,為什麼?比如對於同一個商品來說,一個使用者連續3天都在看,而且停留很久,另外一個使用者到我們網站後壓根就沒看這個商品,那麼相對於第一個使用者來講,我們就可以直接判定這個使用者是對這個商品更感興趣的。第二部分是使用者的顯性資料,比如使用者下單的資料,加購的資料,收藏的資料等業務資料,還有使用者填的一些資料,比如使用者的性別,地區等資料,對一個使用者越瞭解,就可以更加精確的判斷出他會買那些商品。

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

1-1   淘寶推薦猜你喜歡模組

比如你買過了這個手機,那麼可能這個猜你喜歡會給你推薦蘋果手機類似的商品,比如給你推薦一個 ipad,如下圖1-2所示。這時你可能就會有比較大的機率下單。

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

 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。實時的推薦結果和離線的推薦結果通過一定的規則整合起來形成使用者最終的推薦結果。

第五步是推薦結果的展示。當前端發起請求查詢使用者的推薦結果時,比如點選了猜你喜歡模組,產品線通過介面的方式請求推薦系統,由推薦系統返回第四步整合後的推薦結果。

 3  

推薦系統實施流程

推薦系統在是一個比較大的專案,剛開始接觸時可能會覺得無從下手。推薦系統屬於AI系統,需要大量的演算法支撐。AI 系統需要靈活地支援各類 AI 任務,解決各類任務敏捷化過程中的需求與痛點。當前,企業智慧化需求各不相同,導致相應的 AI 任務也種類繁多。我們按照面向業務和非面向業務可以把AI系統的任務分為兩種,如下圖2- 5 所示

圖2-5  AI系統任務劃分

第一種是針對某個業務領域內特定型別資料,提供對此類資料的基礎 AI 學習、預測、分析能力的計算任務,例如計算機視覺、自然語言處理任務等。 這種任務很多時候其本身並不直接解決業務需求,常作為基礎模型對資料進行初步加工,再由一些面向業務的任務來對接需求。這也給演算法實施團隊充足的時間對橫向任務模型進行充分的雕琢,對其敏捷性進行完善。這部分屬於AI系統底層通用能力,不過多展開。

第二種則是面向業務具體需求的、如電商領域的推薦系統以及比較常見的使用者畫像構建、智慧問答等。實施 AI專案的整個流程如下圖2-6 所示:

圖2-6  AI專案實施流程

第一步也是需求的定義比如我們推薦系統要解決人貨匹配的問題,接下來需要準備資料、處理資料,這裡時資料中臺的資料開發工程師承擔,接下來的特徵工程、模型建立及模型的效果評估等演算法相關的模組需要 演算法工程師、標註工程師等角色共同參與完成的。也就是說資料中臺的團隊只需多增加演算法團隊,就可以完成 AI專案的 實施。

那麼資料中臺和 AI系統的關係就比較清晰了, 補充了演算法團隊,推薦系統可以當做資料中臺的一部分。

 4  

幾種經典的推薦演算法

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:1x0.58+2x0.82=2.22

d:0

和基於使用者的協同過濾不同,基於物品的協同過濾首先計算相似物品,然後再根據使用者消費過、或者正在消費的物品為其推薦相似的,基於物品的演算法怎麼就解決了基於使用者協同過濾暴露的那些問題呢?

首先,物品的數量,或者嚴格的說,可以推薦的物品數量往往少於使用者數量;所以一般計算物品之間的相似度就不會成為瓶頸。

其次,物品之間的相似度比較靜態,它們變化的速度沒有使用者的口味變化快;所以完全解耦了使用者興趣遷移這個問題。

最後,物品對應的消費者數量較大,對於計算物品之間的相似度稀疏度是好過計算使用者之間相似度的

 5  

推薦系統的評測指標

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

1.關鍵的資料指標

我們先看下推薦系統的資料指標有哪些。資料指標又分為兩種,一種是商業指標,看推薦系統的最終交易額相關指標。我們做推薦系統的目的是為了代替人工 給使用者推薦商品,提高效率,實現使用者的千人前面,帶來更多的交易額。商業指標有以下幾個:

曝光次數、商品的PV、商品的UV、商品支付人數、支付金額、支付件數。

還有就是點選率、支付轉化率,點選率=商品PV/曝光次數,支付轉化率=商品支付人數/商品UV。

接下來我們看看這些指標該怎麼計算。首先是曝光次數,統計推薦模組曝光量的方式有2種,一種是通過資料埋點,當用戶在推薦模組拉取商品時由前端工程師非同步上傳資料到埋點日誌伺服器,再通過解析埋點日誌的方式統計曝光次數。有一種是通過後端埋點的方式,當用戶呼叫拉取推薦商品的介面時由後端工程師記錄當時的推薦場景、演算法、使用者,商品ID的集合這些關鍵資訊,儲存到日誌檔案,再通過解析日誌檔案的方式統計曝光次數。由於前端埋點有5%的丟失率,計算的指標包括交易額,需要比較準確的資料。採用後端埋點的方式統計曝光量會更加準確一些。

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

涉及到交易額的指標包括支付人數、支付金額、支付件數,也需要通過後端埋點的方式採集,在前文已經講過,因為電商產品的交易流程有一個斷層,使用者一般都是先加購再下單,這個斷層就會增加前端埋點和資料解析的難度。簡單的做法是在訂單中增加下單來源欄位,記錄商品的推薦場景,演算法ID等資訊到購物車,一般來說購物中的資料是存在記憶體資料庫redis裡面,使用者下單時再從redis中取出放入訂單中,這樣就保證了資料能夠整個鏈條的記錄下來,功能如下圖2-12所示。

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

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

舉個例子,比如給使用者推薦了100個商品,其中10個使用者做了點選,那麼準確率就是10%。計算準確率要對推薦的商品列表頁做埋點,使用者每點選一次推薦頁商品就會上傳商品的ID、使用者ID,這樣才能記錄使用者到底點選過那些商品。

第二個是召回率,召回率怎麼定義呢?還是這個例子比如給使用者推薦了100個商品,其中10個使用者做了點選,使用者在我們電商網站一共查看了50個商品,那麼推薦系統召回率就是20%。

第三個指標是覆蓋率,比如我們電商網站一共1萬個SKU,給所有的使用者推薦出來SKU為8000,那麼這個推薦系統的覆蓋率就是80%,覆蓋率為100%的推薦系統可以將每個物品都推薦給至少一個使用者。覆蓋率是供應商會比較關注的指標,供應商關係他們的商品有沒有推薦給使用者。

當推薦系統搭建好之後可以先組織公司內部人員做測試,比如筆者公司電商產品定位是女裝批發平臺,主要客戶是女性,推薦系統上線前,我們就招募了公司一部分女員工做了測試。這些女員工平時在我們的電商平臺也會購買一些女裝,已經積累了一些資料。做灰度測試時,我們的推薦系統最好是能做成準實時,讓使用者有了新的行為如點選、加購等,再次重新整理就能出現新的他們感興趣的商品,這樣也便於我們及時收到反饋。我們可以手工統計一下資料比如單個使用者的準確率和召回率。

可以先不要告訴他們這次活動的目的,給他們5分鐘讓他們逛平臺,唯一讓他們做的就是記錄每次檢視的商品名稱和位置,這樣可以方便我們計算出召回率。接下來可以讓他們關注下推薦模組,讓他們記錄推薦了多少個商品,點選了其中的多少個商品,這樣可以直接算出來準確率。最後再問幾個核心問題,如果我們的推薦系統滿分是10分,他們給幾分,為什麼打這樣的分數,有無其他的一些建議給我們。注意觀察他們的情緒及眼神。當我們經過內部這一輪內部測試會發現一些問題,可以針對問題進行鍼對性的修改,當優化出一個穩定的版本後,可以和運營合作邀請幾個真實的使用者使用者來試一下,測試使用者的分佈要大致保證和真實使用者相同如年齡,活躍度等相關智慧表的分佈。可以設計一套方案,讓他們參與進來,體驗我們的推薦模組,這時可以通過後臺收集埋點資料的方式計算這批使用者的準確率和召回率。

 6  

推薦系統的冷啟動

從上文來看,推薦系統依賴使用者的歷史行為資料,像某貓、某狗這塊大型電商網站,有大量的使用者歷史行為資料可以利用。但是對於一般的推薦系統,特別是剛起步階段,一般是沒有使用者行為資料的, 這個時候該該怎麼辦,這也是推薦系統一個比較核心的問題叫 “冷啟動” 問題。

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

使用者的冷啟動:這個主要解決給新使用者如何推薦商品的問題。當新使用者剛進系統是沒有歷史行為資料的,我們無法通過推薦系統給使用者做個性化推薦。

物品冷啟動:這個主要解決一個新的物品怎麼推薦給他可能感興趣的使用者。

系統的冷啟動:一個新開發的產品,只有少量的商品,還沒有使用者。讓使用者上線時就可以體驗到個性化推薦服務這個問題。

如何解決這些問題呢,在這裡提供一些方案供參考:

1.利用使用者註冊資訊。

使用者註冊都要填一些資訊,比如性別、年齡、第三方登入等資訊。比如我們可以對使用者的註冊資訊做一個分類,針對不同的性別,和不同的年齡段推薦不同的商品。我們還可以通過使用者的第三方登入資訊,在使用者授權的情況下通過社交網路資料拿到使用者好友喜歡的一些商品,再推薦給使用者,因為都是使用者熟悉的朋友,那麼他們朋友喜歡的商品,大概率他們也會喜歡。

2.讓使用者主動選擇自己喜歡的商品。

主要方式就是可以讓使用者選擇喜歡的商品或者品類,基於使用者選擇的結果進行推薦。如 下圖 2-13 所示,可以讓新使用者登入後選擇自己偏愛的品類,當用戶選擇後,他的商品列表就會基於他選擇的結果進行推薦。也可以基於熱銷的商品推薦給使用者,讓使用者選擇,再基於使用者的選擇推薦合適的商品。

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

3.物品的冷啟動也是一個需要解決的問題,電商網站每天會更新大量的商品,如果新的商品得不到推薦,那麼會影響到使用者的體驗,也得不到業務部門的支援。電商網站一般用基於商品的協同過濾,協同過濾的核心是認為物品A和物品B有很大的相似度的原因是因為喜歡物品A的使用者大多數也喜歡物品B,可以看得出物品的協同過濾是很依賴使用者的行為資料的,因為使用者的行為資料決定使用者是否會喜歡這件商品。但是對於新物品是沒有使用者行為資料的,就很難推薦到新物品,就算是有使用者對商品產生了行為,那麼商品之間的相似度也是需要大量的計算,無法做到及時反饋給使用者。那麼怎麼解決這個問題呢?

我們可以利用物品的內容資訊,比如對於一個衣服來講衣服的名字,品類,品牌,價格段都是物品的內容資訊。如果做了商品的價格段標籤那麼可以精準推薦到同品牌、同品類下同價格段的商品那個適合使用者,比如同品牌、同款、同價格段的毛衣。商品的名字也有多的內容資訊。我們可以針對商品名稱,建立分詞庫,基於分詞給商品打上標籤,可以基於標籤給使用者推薦類似標籤的商品。

 7  

從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的小數

計算時間:產生推薦結果的時間,一般儲存近幾次的計算結果

基於推薦結果的資料,後端開發工程師就可以開發對外的服務介面,具體如下表所示:

介面說明

獲取使用者的推薦列表

介面型別:Restful

請求方式:Post

請求url:

請求引數

引數變數

引數名稱

引數資料型別

是否

必須

詳細說明

userId

使用者id

Long

使用者唯一標識

pageNum

頁碼

Integer

預設是1

pageSize

每頁大小

Integer

預設是10

響應引數

引數變數

引數名稱

引數資料型別

是否

必須

詳細說明

result

響應結果編碼

int

SUCCESS:成功;FAIL:失敗;ACCEPT:受理;ERROR:錯誤

errorCode

錯誤編碼

String

錯誤編碼值均為請求處理失敗。

resultMsg

響應結果描述

String

resultMsg為具體的錯誤描述

data

響應結果

RecommendQueryResDto

RecommendQueryResDto

引數變數

引數名稱

引數資料型別

是否

必須

詳細說明

userId

使用者id

Long

跟入參的使用者id一致

rcmList

推薦商品列表資訊

UserRcmDto

UserRcmDto

itemId

商品id

Long

algorithmId

演算法id

Long

xxxxx - 基於使用者的協同過濾演算法;

為了完成推薦系統,只有資料中臺的團隊並不行,還需要產品線的產品經理和運營的配合。首先要在產品的功能介面預留一個位置,類似淘寶、京東的猜你喜歡,這個可以基於自己的產品特性來選擇位置。電商線的產品經理需要協調前後端開發處理推薦位置的前後端開發及埋點開發,前後端開發是呼叫資料中臺的推薦介面,完成推薦功能介面的開發,資料埋點要解決2個問題。第一是要知道每個場景,每個演算法,每天的交易額。當用戶加購時,要把場景ID,演算法ID,同商品一塊加入購物車。當用戶下單時再將場景ID,演算法ID一併加入進貨車。第二我們要統計每天有哪些使用者 訪問我們的推薦場景,點選了那些商品,這個針對前端可以做常規的埋點,埋點的做法可以參考第二章資料採集模組。有了這些埋點資料就可以計算推薦位每天產生的總交易額,總訪問使用者數等相關商業指標,也可以通過檢視每個演算法的準確率,召回率,覆蓋率這三個指標,來找到最合適的演算法。資料中臺主要承擔演算法的開發與推薦介面的開發以及後面推薦系統的資料來源分析。第三步運營需要配協調UI資源,設計推薦位的LOGO,推薦位背景圖等工作。推薦系統的方案設計大概需要一週的時間,另外需要3天的時間評審方案,電商線的產品經理針對前後端和埋點的開發大概需要一週的時間,資料中臺針對演算法的開發大概需要1個月的時間。第一個版本預計整體時間需要2個月的時間,其中大概用半個月定整體方案和細節的部分,其他都是各個角色開發的時間。

7.4 離線推薦系統的測試 

至此推薦系統的整個開發流程就結束了,接下來是推薦系統的測試。為了方便測試可以開發一個快速拿到使用者推薦結果的介面方面產品和測試去檢視資料。主要包含三塊內容:

1. 可以快速查詢每種召回演算法每個使用者的推薦結果

2. 排序演算法每個使用者的最終推薦結果

3. 給使用者展示的最終推薦結果

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

圖2-1 7  使用者推薦列表

首先要針對召回演算法進行測試,召回演算法主要測試演算法的邏輯是否正確。比如基於商品的協同過濾,最核心的原理是買了商品A的人大多數又買了商品B,如果商品B是使用者預測點選率最高的商品,那麼同時買了A和B的人數應該也是最多的。一般來說演算法工程師和測試工程師合作完成測試用例的驗證,演算法工程師按照測試工程師的要求提供資料,測試工程師負責驗證演算法邏輯的準確性。

第二步需要對排序演算法的結果和使用者最終的推薦結果進行測試。因為邏輯比較複雜,這兩個步驟測試起來就很有挑戰性。在這裡推薦一個簡單的方法,專案組可以一起定義幾個典型使用者比如:

1.無使用者行為的使用者

2.有歷史行為資料,但是很久沒來訪問的使用者

3.有歷史行為資料並且最近很活躍的使用者

對於第一種使用者來說,可以驗證一下此類使用者的推薦結是否和冷啟動的策略一致。對於第二類使用者來說雖然有歷史行為,但是歷史行為的資料已經很久,無法再去利用,基於制定的策略需要驗證一下此類使用者的推薦結果是否和我們的策略相符合。第三類使用者可以讓演算法工程師基於他最近的行為輸出他喜歡的商品,然後基於他喜歡的商品核對推薦的商品是否有很大的誤差,比如使用者喜歡50-100的牛仔褲,我們推薦的結果都是500以上的牛仔褲,那麼就有問題了。

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

 8  

從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的得分就是7x0.875=6.125。按照這種方式可以將使用者感興趣的商品D、C、B、A都進行計算,最後就可以得出一個分數有高到低的實時商品推薦列表,可以基於業務需求,比如TOP50做為候選結果集。

第三步是要解決離線的推薦結果和實時的推薦結果如何結合的問題。最理想的方式是通過上文提到的GBDT+LR排序演算法將實時推薦結果和離線推薦結果進行統一排序,但是這套排序演算法也是相對來說比較複雜,不能做到幾秒內出結果。解決方案是我們可以人工定義一下實時推薦和離線推薦的優先順序,推薦結果都是分頁顯示的,有以下幾種方式:

第一種方式是前幾頁顯示實時結果,後面顯示離線結果。這種方式是預設實時推薦結果的優先順序是大於離線結果的,問題是我們耗費了那麼多資源來算使用者的離線結果,但是卻沒有得到曝光,因為如果使用者前幾頁都沒瀏覽,後面的頁面瀏覽的機率就比較小了。

第二種方式可以採用交叉顯示的方式,比如第一頁一共有10個商品,前3個商品顯示實時推薦結果,後面7個顯示離線推薦結果,第二頁同樣如此。這種方式實時的推薦結果和離線的推薦結果都有曝光,資源利用率相對來說比較大。

關注微信公眾號: 改變世界的產品經理,回覆“大資料之路”領取阿里資料中臺實踐《大資料之路》

-End-

覺得有啟發,點個 “在看” ,轉給朋友們

推薦閱讀:

資料中臺實戰(九):如何搭建全渠道自動化的營銷平臺

資料中臺實戰(八): 如何打造可以支撐N條產品線的標籤平臺

資料中臺實戰(七):流量分析

資料中臺實戰(六):交易分析

資料中臺實戰(五): 自助分析平臺(產品設計篇)

資料中臺實戰(四): 商品分析(產品設計篇)

資料中臺實戰(三): 使用者分析(產品設計篇)

資料中臺實戰(二):基於阿里OneData的資料指標管理體系

資料中臺實戰(一):以B2B電商億訂為例談資料埋點(產品經理視角)

資料中臺實戰入門篇: 資料中臺對內、對外合作機制

資料中臺實戰入門篇: 雙中臺戰略

「改變社」 創始人

暢銷書《資料中臺實戰》作者

幹中臺,找華仔

點選下方卡片關注我 ,發現一個有趣的靈魂

後臺回覆 “w” ,可加我個人微信

給你準備了一份大廠資料中臺資料大禮包