實時推薦策略流程

一個完整的工業級的推薦系統會分成兩大部分

1. Online serving
2. Offline data processing

此篇著重在電商推薦系統在 online serving 的算法策略架構

架構概述

Online serving 為當 user request 進來時算法的策略流程，什麼階段該做什麼事。一般來說 online serving 又可大致上分成三個 stages

1. Match： 從百萬級的商品庫中召回數千或數百的商品
   • 此階段大致上, 模糊地召回 user 感興趣的商品
2. Rank：對召回的數千或數百商品進行打分，決定針對 user 個性化排序召回的商品
   • 通常會用模型 ranking，模型會綜合考慮 user 的喜好以及商品本身的特徵進行打分
3. Re rank：根據業務邏輯重新排序 ranking 結果

上面三個 stages 是一個推薦流程的抽象表示，實際上每個 stage 內還會細分出工程和業務考量的模組。

推薦系統相關文章

實時推薦策略流程

下圖是我在我司設計的線上推薦流程，stages 濃縮成 match 和 rank，re-rank 納入 rank stage 內

• 橘色的色塊為 data flow，表商品列表 從生成到排序完成，經歷的所有過程，為邏輯抽象
• 綠色的色塊為 data flow 中的抽象模組/組件，在 java 中為 abstract / interface ，為工程抽象
• 灰色色塊為 operator 是 implement 抽象模組的可實例化組件，在 java 中為 class ，可以說線上推薦所有算法邏輯都是 operator 疊積木般完成的

以上三個色塊構成了實時推薦的策略流程。

Match

User Action Scorer

對 user 歷史交互行為進行打分，user 行為又可分成 normal action 與 extend action

1. normal action: 作用在商品 ID 上的行為
   • EX: 曝光， 點擊，加購，購買，付款 etc..
2. extend action: user 其他行為
   • EX: 廣告點擊，商品目錄點擊 etc…

Key2I Matcher

根據不同的 key 對商品進行召回

• key 可以是： ItemID, categoryID, UserID， 任何可以關聯到商品 ID 的 trigger Key
• key2I matcher 牽涉到兩個 components
  1. Source : key2I 儲存位置，這邊對儲存源作了抽象，對外統一接口，讓推薦算法工程師實現算法策略時不必關心儲存源
  2. Matcher: 執行召回商品 items 的 component
     • 封裝了多路召回，並控制多路召回比例
     • ex: 熱門商品召回，熱門類目召回， item2vec 召回，contentI2I etc..

Rank

Score Estimator

精排階段，對多路召回的商品進行排序

• 封裝各種算法模型與特徵處理方式
  • 模型有 lr, xgboost , wide deep .. etc
  • Feature Manager: 保證特徵處理跟線下生成一致
    • 線下生成大部分是透過 spark 產生，因此在線上 serving 時得注意特徵處理一致性。
    • 這邊有個難點，模型訓練時的特徵是處理過的，線上使用時也得跑一樣的流程，但線下跟線上卻是不同語言寫的，如果能做到 end2end，就能減少開發量和 bug 量。

ReRank

重排序，根據不同業務邏輯重新排序精排結果。

• Rerank 分成數個階段，有一定的前后依賴關係
  1. filter
     • ex: 低評分商品過濾 …etc.
  2. adjust score: 直接調整整個别 item 精排后的分數
     • ex: 多次曝光商品分數 decay
  3. sort: 根據調整後的數 sorting
  4. adjust order: 直接置換商品位置
     • ex: 商品置頂 or 沉底
  5. scatter : 增加商品多樣性，避免用戶疲勞
     • ex: 類目打散