• 資料科學協會
2024 領航計畫已開放報名,請點擊後查看報名資訊
前往 Medium 閱讀好讀版

Brickmaster: scenario-wise recommendation system engine & Validation

Dan Chen | Data Scientist @LINE Taiwan EC Dev

活動主辦單位:Taiwan Data Science Meetup 台灣資料科學社群

摘要

本次講座邀請了在 LINE Taiwan EC Dev擔任 Data Scientist 的 Dan Chen 來分享 LINE Shopping 的推薦系統情境以及對應的推薦系統設計,講座內容主要分成 5 段:

  • Part 1 — 電商推薦系統中的情境和常見問題
  • Part 2 — 推薦系統的基礎建設與資料流架構
  • Part 3 — 推薦系統的驗證策略
  • Part 4 — Feature Engineering, Candidate Generation, Ranking, pipeline monitoring and the goal of recommendation.
  • Part 5 — QA 精選

講者介紹

Dan Chen 目前在 LINE Taiwan EC Dev 擔任 Data Scientist,專案經歷涵蓋多方領域,包含電信、金融、工廠及廣告等,並曾擔任過新創資料顧問,並著有《 Towards Tensorflow 2.0 — 無痛打造 AI 模型 》一書,本次主要介紹 LINE Shopping 的情境式推薦系統。

Part 1 — 電商推薦系統中的情境

瀏覽行為本身就帶有情境,點擊到不同的頁面也可能意味著不同的情境,如

  • LINE Charts — 熱銷金榜類
  • LINE Point — 點數回饋類推薦
  • Search Keyword — 熱搜關鍵字相關商品推薦
  • Shop — 品牌類、電商類商品推薦

LINE Shopping 推薦場景分類— 講者投影片 [1]

電商的常見問題

Q1 : 很多商品都有容易過期的特性,電商的商品特性也不例外,新上架的商品會很熱門,而熱門期過了之後也會很快的失去熱度,然後一般推薦系統所著重的互動資料,可能還會推薦已經過熱門期的商品。

電商常見問題 1 — 講者投影片 [2]

Q2 : 難以得知使用者當前意圖,例如知道使用者喜歡 iPhone,新款 Iphone 上架了,使用者究竟是喜歡最新的 iPhone 還是上一代價格大跳水的 iPhone?

電商常見問題 2— 講者投影片 [3]

Q3 : 如何讓 Stakeholder (Planner / PM),得知目前推薦系統的成效? 如何將 Stakeholder 想要優化的指標與推薦系統做掛鉤?

由於商業場景的特性關係,LINE Shopping 使用者旅程 ( User Journey ) 中,資料顯示使用者對於 LINE SHOPPING App 有更多的互動行為( Search, View, Click ),並不等價形成轉換 (下單 / 加入購物車)。透過資料探索發現往往一搜尋就買、一 點擊就買,這對於推薦系統形成了一個挑戰。

電商常見問題 3— 講者投影片 [4]

Part 2 — 推薦系統的基礎建設與資料流架構

LINE EC Dev 內部有一套稱為 Brickmaster 的推薦系統,就是設計來解決上述 3 個問題,整體的技術架構是兩階段的模型。

LINE EC Dev 所設計的推薦系統解決方案— 講者投影片 [5]

基礎建設可拆成五個模組,Tech stack 按照計算框架 / 資料儲存 / 服務提供 / 排程管理 / ML 實驗管理,有使用到的工具如下:

  • 計算框架 — Pyspark — 主要用於 ETL 拉取資料,模型訓練主要使用 PyTorch family。
  • 資料儲存 — HDFS / Hive — 主要用於原始資料以及 ETL 後的中繼資料儲存, Serving 資料集則使用 Redis。
  • 服務提供 — 主要使用 FastAPI 做串接, Dash 則作為 demo site 使用。
  • 排程管理 — Airflow 是相當常見的排程管理工具。
  • ML 實驗管理 — 主要透過 mlflow 來觀察有沒有 train 壞掉,或是其他需要處理的 issue。

LINE EC DEV Tech Stack— 講者投影片 [6]

資料流架構能拆成以下五個階段:

  1. 使用者會在頁面留下互動資料 — Web / App Log,原始資料又能被分為三個大類:
  2. User Profile — 使用者特徵 — 如性別、年齡。
  3. Item Profile — 商品標題 (例如什麼樣的衣服)、商品標籤 (服飾)、商品描述 (極保暖)。
  4. Feature Generation — 按照原始資料做 ETL,並儲存在 Hive / HDFS ,這一層的運算量是最大的,也是主要使用到 Spark 的部分。
  5. Candidates Generation — 從加工資料中計算出每人的商品候選清單 (例如每人 1000 品、 2000品、5000品),會根據推薦場景來決定。
  6. Ranking — 按照不同情境設計不同的指標進行精確排序,(例如從每人 1000品 → 每人 10品 每人100 品)。
  7. Serving — 從 UI 上可以看到每個人的推薦列表,從而進入曝光、點擊、特徵收集的推薦循環。

LINE EC DEV Tech Stack — 講者投影片 [6]

不同算法模組的目標也不同,如 Candidate Generation 是第一階段粗篩,所以目標會是 Recall,而非 Precision,但 Ranking 階段已經進入精確排序,就必須著重在 Precision。

根據推薦情境不同,也需要能夠針對推薦情境決定 Candidates Generation 需要粗排序的數量,例如 1000品 or 5000品,另一方面,不同的推薦情境也有不同的優化指標。

LINE EC DEV 資料流架構與側重指標— 講者投影片 [7]

Part 3 — 推薦系統的驗證策略

離線驗證

透過 mlflow 來做實驗管理,Evaluation Report 有分成以下三個 Metrics,如果發現相關指標大幅下降,就會請相關職能的人員協助:

Model metrics — Top-N metrics (e.g. MAP, NDCG):

  • Data Engineer / Machine Learning Engineer / Data Scientist

Business metrics — CTR, CVR, GMV:

  • Data Scientist

Overview metrics — Diversity / Coverage:

  • Data Scientist

LINE EC DEV 推薦系統離線驗證流程— 講者投影片 [8]

線上驗證

A/B Testing — 雖然市面上有很多的服務,但基於公司內部的政策,由 LINE EC Dev 團隊自己搭建的,目前都還需要人工設定,還沒有進行完整自動化。

LINE EC DEV 推薦系統線上驗證流程 — 講者投影片 [9]

Part 4 — Feature Engineering, Candidate Generation, Ranking, pipeline monitoring and the goal of recommendation.

Feature Engineering

  • 特徵工程中有許多特殊的方法,也有許多細緻的分類,以 Product Profile舉例,商品描述需要審慎思考哪些字詞是有用的,哪些沒有。
  • 節慶特徵則是講者認為相當有趣的經驗,送禮上很容易跟節慶結合,也試過農曆年的特徵。
  • 情境特徵包含如上次點擊時間、廣告觀看時間等。

電商推薦系統特徵與原始資料分類表— 講者投影片 [10]

另一方面,文字特徵需要特別做處理,多半聚焦在商品名稱和商品描述:

  • 商品名稱 — 由於 Token 直接做 one hot encoding 維度會爆炸,因此採用 embedding 的做法。
  • 性別指向性商品 — 有的商品具有性別指向性,如買女性內衣的顧客有很高的機會 (但並非 100%) 會是女性,因此性別指向性商品能夠反推購買者的可能性別。

電商推薦系統特徵與產品名稱處理流程— 講者投影片 [11]

Candidate Generation

LINE Shopping 的點擊和其實和廣告很像, CTR 偏低,因此在資料預處理上也需要一些手段來增強訓練成果 (如 negative sampling),在目前的實驗中,類 YouTube 的 DNN 有比較好的表現。

在推論階段,由於計算複雜度的關係,資料量大的情況下會採用 Locality Sensitive Hashing 的技巧將 User Embedding 和 Item Embedding 做媒合,產生 Candidates。

電商推薦系統 — Candidate Generation — 講者投影片 [12]

Ranking

排序階段主要會將排序目標和 Stakeholder (Planner, PM) 的專案目標對齊,並設計適合的特徵,例如有的場景更關心使用者點擊量,那麼須將優化目標調整成最小化下次點擊時間,有的場景希望使用者 和 App 互動更多,則最大化使用者的 Session Duration。

電商推薦系統 — Ranking— 講者投影片 [13]

Monitoring

穩定性除了會監看 DAG 的執行狀態,也會看缺失值、outlier 是否過多,超過一定的標準就會發出 slack alert。

電商推薦系統 — 資料品質檢測— 講者投影片 [14]

Goal of the recommendation system

總結來說,在 Candidates Generations 時,主要關注的是使用者興趣,系統是否能找出使用者會有興趣的商品,而在 Ranking 階段,不同的場景會有不同的優化目標,就能進針對不同目標進行排序。

演算法架構和商業目標對應表— 講者投影片 [15]

設計推薦系統時也期望媒合到商業目標,如希望點擊量提升,可設計成最小化下一次的點擊時間差,如果是希望增強使用者互動,則會最大化 Session Duration。

將商業指標轉換為推薦系統問題對應表— 講者投影片 [16]

Part 5 — QA 精選

Q1. 想請問電商場景中,使用者興趣變化非常大,模型訓練的頻率?

  • Ranking — 每天 re-train
  • Sourcing — 每週 re-train
  • 主要的考量是資料量和計算資源的考量

Q2. 是否有特殊的特徵萃取工程,以及 User, Item 如何做選取,來避免維度爆炸?

  • 會採用過去 N 天內活躍的 User, Item,來避免 User, Item 過多,也會搭配 embedding 來做使用。

Q3. 根據你們的架構,是否有使用到 realtime 的推薦呢? 還是主要是先算好推薦結果,再進行 Serving?

  • 目前的架構設計,是先算好再進行 Serving, Candidates Generation 是 Weekly Retrain, Ranking 則是 Daily Retrain, realtime 也是我們很想嘗試的一塊。

Q4. 如何衡量 diversity / coverage?

  • Diversity — 以 product category 作為 dimension ,測量 entropy,entropy 可測量推薦分佈在 category 的分布是集中或是分散。
  • Diversity 對於離線驗證相當有幫助, planner 在離線驗證時,如果覺得常常推薦出來的內容都很像,會反映在該指標上。
  • Diversity / Coverage 比較沒有一個精確值,都是看長期分布比較多,或說一個新的模型不要真的 diversity 過低即可。
  • 如果擔心預測的類別都很類似,例如都很熱門,或者都是 iPhone 14,那麼就針對該類別設計分層,例如熱門度分層,iPhone 品類分層等,一樣可以用 entropy。

Q5. 如果提升了 CTR,但整體使用者體驗下降 (如購買金額、或者商品頁閱讀完成度),會怎麼處理?

  • 跟 Planner 討論,如果 Planner 覺得 CTR 很重要,但購買金額下降,是否可行,中間是否一些需要討論的空間,講者認為,這段溝通也是 Data Scientist 的一項重要工作以及能夠體現 Data Scientist 的價值之一。

筆手 : Joe Tsai

校稿:Ting Yu, Dan Chen
👉 歡迎加入台灣資料科學社群,有豐富的新知分享以及最新活動資訊喔!

社團法人
資料科學協會

立案證書字號

1090070264

Copyright 2020-2024 資料科學協會 All Rights Reserved.

本網站由 資料科學協會 維護