Tweet
Tweet

Slide 1

Slide 1 text

モバオクでのリアルタイム レコメンドシステムの紹介 玉木竜二 株式会社ディー・エヌ・エー ソリューション事業本部データ統括部データ基盤部 MLエンジニアリングエンタープライズグループ © DeNA Co.,Ltd.

Slide 2

Slide 2 text

2 自己紹介 玉木 竜二 MLOps Engineer 機械学習プロジェクトにおいて機械学習モデル作り以外の開発運用を担当 ソリューション事業本部データ統括部データ基盤部 MLエンジニアリングエンタープライズグループ @tamaki_730 最近嬉しかったこと: 色違いのメタングGET

Slide 3

Slide 3 text

3 目次 ● 背景・課題 ● リアルタイムレコメンドシステムアーキテクチャ ● 開発・運用でわかったこと ● まとめ

Slide 4

Slide 4 text

背景・課題

Slide 5

Slide 5 text

5 モバオクとは 1 出品・入札・落札（購入）ができるインターネットオークション・フリマサイト

Slide 6

Slide 6 text

6 実現したいシステム 2 ● ユーザーの商品閲覧履歴からおすすめの商品を推薦する ● サイトのトップページに表示する あなたへのおすすめ（ユーザーベースアイテムレコメンド）

Slide 7

Slide 7 text

7 モバオクのリアルタイム レコメンドシステムの アーキテクチャの説明の前に...

Slide 8

Slide 8 text

8 DeNAでよく用いられる レコメンドシステムアーキテクチャ

Slide 9

Slide 9 text

9 DeNAでよく用いられるレコメンドシステムアーキテクチャ 1

Slide 10

Slide 10 text

10 他サービスからの通知、もしくはジョブスケジューラによりVertex AI Pipelinesを起動 2 ● 日次のデータ移行完了→Pub/Sub ● 毎日0時起動 などのケース 現在はscheduler APIから直接Vertex AI Pipelinesを起 動できるため別途ジョブスケジューラは不要

Slide 11

Slide 11 text

11 前処理から特徴量生成、モデル学習、評価、推論までVertex AI Pipelinesで管理 3

Slide 12

Slide 12 text

12 BigQueryに格納した推論結果を別サービスのDBに移行 4

Slide 13

Slide 13 text

13 Web APIでホスティングすることも 5 ● オンライン推論が必要 ● Web API連携の方が好ましい 上記のケースは社内で開発しているモデ ル推論基盤にデプロイする モデル推論基盤詳細は以下資料参照 機械学習基盤HekatoncheirにおけるWeb APIサービングの取り組み【DeNA TechCon 2022】

Slide 14

Slide 14 text

14 このアーキテクチャのいいところ 6 ● 使い回し、応用が効きやすい。DeNAでも複数のサービスで上記構成のレコメンドが運用中 ● 使い回すことで、実装、運用が楽になる ○ 機械学習モデルを作るデータサイエンティストがワークフローエンジン内の処理を実装するケースも ○ 監視や障害対応も統一しやすい

Slide 15

Slide 15 text

15 モバオクの場合

Slide 16

Slide 16 text

16 先述のバッチでのレコメンドだと以下の問題がある 1 ● 課題1: そのときユーザーが興味を持った商品をレコメンドできない ● 課題2: 出品されたばかりの商品をレコメンドできない

Slide 17

Slide 17 text

17 課題1: そのときユーザーが興味を持った商品をレコメンドできない 2 例: 昨日までは服を中心に商品を探していたが、今日はマンガを探している ● 1日1回のバッチ処理を用いたレコメンドでは、服を推薦してしまう ● 1日24回にバッチ処理を増やしても、次の推薦までにサービスから離れてしまうかもしれない ● 直近1時間、30分、数分のデータからそれぞれ特徴量を作りオフライン指標を確認 ○ 直近のデータがわかるほどオフライン指標は改善する傾向 ❌直近の行動履歴 から推薦できない 前日までの行動履歴で学習、 前日までの出品商品から推薦

Slide 18

Slide 18 text

18 課題2: 出品されたばかりの商品をレコメンドできない 3 ● 出品するユーザー目線だと、出品した商品にすぐに入札されるのがいいUX ● 前日までの行動履歴で学習、前日までの出品商品から推薦だと、出品されたばかりの商品 をレコメンドすることができない ○ モバオクのようなオークション・フリマサービスでは商品が次々入れ替わる 前日までの行動履歴で学習、 前日までの出品商品から推薦 ❌直近出品された 商品を推薦できない

Slide 19

Slide 19 text

19 先述のバッチでのレコメンドだと以下の問題がある 4 ● 課題1: そのときユーザーが興味を持った商品をレコメンドできない ● 課題2: 出品されたばかりの商品をレコメンドできない →更新をリアルタイムに近づけたい

Slide 20

Slide 20 text

20 その他のモバオクの課題と実現したかったこと 5 実は外部のSaaSを用いて、レコメンドシステムは実現できていた しかし、一定のパフォーマンスは出せているものの、チューニングやコスト削減の限界がきていた →コストは抑えつつ、外部SaaSで実現が難しかった、リアルタイムでユーザーが欲しい商品を 多様に提案できるレコメンドを構築し、商品発見から入札までの体験を向上させたい

Slide 21

Slide 21 text

21 リアルタイムでレコメンドを行う大変さ 6 バッチ(1日1回) リアルタイム レイテンシー 事前にレコメンドするアイテムを計算でき るため低く抑えやすい オンライン推論が必要な場合はバッチに 比べて高くなる 開発・運用 データの連携が楽 ストリーミングで連携が必要な場合、開 発、運用がバッチに比べて難しい 機械学習 モデル 特徴量計算、推論に時間がかかるモデルで も可 モデル学習と推論を同じ環境で実装できる レイテンシー等の制約あり 学習時と推論時の環境を合わせることが 難しく、バッチよりもトレーニング / サービングスキューに気を付ける必要が ある。 コスト 1日1回ワークフローが動いている間だけ課 金される 24時間前処理や推論を走らせる必要があ り、高くなりやすい

Slide 22

Slide 22 text

リアルタイムレコメンド システムアーキテクチャ

Slide 23

Slide 23 text

23 全体アーキテクチャ 1

Slide 24

Slide 24 text

24 大きく3つの処理に分かれます 2 バッチパイプライン ストリーミングパイプライン レコメンドAPI

Slide 25

Slide 25 text

25 推薦にリアルタイム性を持たせる処理 2 ストリーミングパイプライン レコメンドAPI 計算済みの商品ベクトルを取得 直近のユーザー行動履歴からユーザーベクトルを生成 ユーザーベクトルを用いて近似近傍探索より推薦する 商品一覧を取得 直近のユーザーの行動履歴を随時更新

Slide 26

Slide 26 text

26 バッチパイプライン 3 バッチパイプライン

Slide 27

Slide 27 text

27 バッチパイプライン 4 1. モバオクからAI基盤に毎時データ連携 (本当はここもストリーミングで連携したいが既存システムの都合でバッチ) 2. 商品のテキスト情報等から学習済みの機械学習モデルで商品ベクトルを生成 3. 商品ベクトル、商品の情報を、ANNインデックス、オンライン特徴量ストアに差分更新

Slide 28

Slide 28 text

28 ストリーミングパイプライン 5 ストリーミングパイプライン

Slide 29

Slide 29 text

29 ストリーミングパイプライン 6 1. ユーザーの行動をPub/Sub経由でニアリアルに連携 2. ストリーミング処理エンジンからDWHにデータを保存 3. レコメンドをユーザーに返す際に高速に返せるように、オンライン特徴量ストアにも保存 a. 実際には特徴量というほどでもなく、単にユーザーがどの商品を見たかの履歴のみ

Slide 30

Slide 30 text

30 レコメンドAPI 7 レコメンドAPI

Slide 31

Slide 31 text

31 レコメンドAPI 8 1. ユーザーの閲覧履歴とバッチパイプラインで生成した商品のベクトルからユーザーベクトルを生成 a. 商品A, B, Cを見ていたら、商品A, B, Cの商品ベクトルの加重平均を取るなど 2. 生成したユーザーベクトルを用いて、商品ベクトルのインデックスを検索 3. 検索結果をレスポンスとしてモバオクに返す

Slide 32

Slide 32 text

32 リアルタイムのレコメンドの大変さと今回作ったシステムの説明 9 今回作ったシステム リアルタイム レイテンシー 重いベクトル生成は非同期処理 近似近傍探索だとレイテンシーが低く抑え られ、スケールしやすい オンライン推論が必要な場合はバッチに 比べて高くなる 開発・運用 ストリーミングでの処理は最小限 データロストしても影響は少ない ストリーミングで連携が必要な場合、開 発、運用がバッチに比べて難しい 機械学習 モデル 近似近傍探索を用いているため高速 直近N分のクリック数などの特徴量を用い ていないため、トレーニング / サービン グスキューも起きにくい レイテンシー等の制約あり 学習時と推論時の環境を合わせることが難 しく、バッチよりもトレーニング / サービ ングスキューに気を付ける必要がある。 コスト ストリーミングエンジン、オンライン特徴 量ストア、ANNインデックスは高価 24時間前処理や推論を走らせる必要があ り、高くなりやすい

Slide 33

Slide 33 text

33 全体アーキテクチャ図に含まれない細かい部分 ● 機械学習モデル(embedding生成)学習パイプライン ○ Vertex AI Pipelinesで実装 ○ 現在手動実行のみ。定常的に再学習しない ■ 使っている特徴が自然言語のみのため ■ 別の期間のデータで再学習しても精度への影響はほぼないことを確認済み ● Embedding作成、インデックス作成パイプライン ○ Vertex AI Pipelinesで実装 ○ Vector Searchの初回インデックス作成時は、avroやjsonを入力とする必要があるため ○ 定常的に実行するバッチパイプラインとembeddingに変換する処理は共通 10

Slide 34

Slide 34 text

34 開発・運用でわかったこと

Slide 35

Slide 35 text

35 本番デプロイした結果 1 既存の導入済みの外部のレコメンドサービスとの比較 ● 入札率、クリック率などの主指標 ○ 大きく改善🎉 ○ リアルタイムに更新されるレコメンドが、ユーザーの回遊率に大きく貢献 ● レイテンシー ○ 39%減🎉 ○ 99%tile 100ms以下 ● コスト ○ 33%減🎉 ○ 更に削減できる見込み ● システムの安定性も増した ○ エンジニアの運用工数も減🎉

Slide 36

Slide 36 text

36 リアルタイムレコメンドの副産物 2 ● 閲覧している商品に対して、類似の商品を推薦する ● 商品の詳細ページに表示する ● ユーザーベースレコメンドで用いている商品ベクトルをそのまま使っている 関連する商品（アイテムベースアイテムレコメンド）

Slide 37

Slide 37 text

37 やってみてわかったこと 3 やってみてわかったこととして、大きく以下3点について紹介します ● 近似近傍探索のメリット・デメリット ● 近似近傍探索後のリランキング処理の追加（見送り） ● その他アーキテクチャの話

Slide 38

Slide 38 text

38 近似近傍探索のメリットデメリット 4 ○ メリット ■ 高速でスケールしやすい ■ 今回のようにオンライン推論をしてもレイテンシーに問題なし ■ Vector Searchのようなマネージドサービスを使えば運用も楽 ○ デメリット ■ 多様性を出すことが難しい ● 似た類似度のアイテムが固まってしまう。これを防ぐには別途処理が必要 →今後の課題 　後処理や別の推論結果との結合など検討 ● Vector Searchのcrowding tag機能などもあるが、多様性を出すような tagの設計が必要

Slide 39

Slide 39 text

39 近似近傍探索後のリランキング処理の追加（見送り） 5 ● クリックを教師とするとノイズに左右されやすい ○ Bot等によるクリックに引っ張られる、あまり推薦したくない商品を推薦してしまうなど ● ストリーミングエンジン、推論処理のコストが大きい ● ストリーミングエンジンでのストリーミング特徴量生成の工数がバッチ処理に比べて高い ○ データサイエンティストがBigQueryで作った処理をapache beamの処理に書き直すなど ストリーミング特徴量生成、 ストリーミング推論を追加 推論結果をBigtableに格納

Slide 40

Slide 40 text

40 その他細かいアーキテクチャの話 6 リランキングをせず、近似近傍探索だけで済む場合 ● Dataflowでストリーミング特徴量生成、非同期推論のようなことをしなくてもいいため、Cloud Runなどのより安 価なサービスを用いてユーザーの閲覧履歴を更新できる ● リランキングの要件では、短時間に大量の書き込み/読み込みが発生するため、オンライン特徴量ストアに Bigtableを用いたが、近似近傍探索だけでいいのならFirestoreなどより安価なNoSQLでもいいのかも

Slide 41

Slide 41 text

41 まとめ

Slide 42

Slide 42 text

42 まとめ 1 モバオクで取り組んだリアルタイムレコメンドシステムの紹介をしました ● ユーザーのリアルタイムの行動履歴をストリーミングパイプラインで更新 + 近似近傍探索で推 論することで、主指標を大きく改善できました ○ 既存のレコメンドシステムと比較し、リアルタイム性が貢献していることもわかりました ● 近似近傍探索による推論は比較的実装、運用が容易 ○ スケールしやすくレイテンシーも低い ○ 多様性を出すには後処理や別の推論結果との結合などが必要 リアルタイムレコメンドをやりたい場合、今回紹介したようなシンプルな構成を最初に試 してみるといいかもしれません