モバオクでのリアルタイムレコメンドシステムの紹介

第37回 MLOps 勉強会で発表した、「モバオクでのリアルタイムレコメンドシステムの紹介」の資料
https://mlops.connpass.com/event/302371/

Transcript

1. モバオクでのリアルタイム レコメンドシステムの紹介 玉木竜二 株式会社ディー・エヌ・エー ソリューション事業本部データ統括部データ基盤部 MLエンジニアリングエンタープライズグループ © DeNA Co.,Ltd.
2. 2 自己紹介 玉木 竜二 MLOps Engineer 機械学習プロジェクトにおいて機械学習モデル作り以外の開発運用を担当 ソリューション事業本部データ統括部データ基盤部 MLエンジニアリングエンタープライズグループ @tamaki_730 最近嬉しかったこと: 色違いのメタングGET
3. 3 目次 • 背景・課題 • リアルタイムレコメンドシステムアーキテクチャ • 開発・運用でわかったこと • まとめ
4. 背景・課題
5. 5 モバオクとは 1 出品・入札・落札（購入）ができるインターネットオークション・フリマサイト
6. 6 実現したいシステム 2 • ユーザーの商品閲覧履歴からおすすめの商品を推薦する • サイトのトップページに表示する あなたへのおすすめ（ユーザーベースアイテムレコメンド）
7. 7 モバオクのリアルタイム レコメンドシステムの アーキテクチャの説明の前に...
8. 8 DeNAでよく用いられる レコメンドシステムアーキテクチャ
9. 9 DeNAでよく用いられるレコメンドシステムアーキテクチャ 1
10. 10 他サービスからの通知、もしくはジョブスケジューラによりVertex AI Pipelinesを起動 2 • 日次のデータ移行完了→Pub/Sub • 毎日0時起動 などのケース 現在はscheduler APIから直接Vertex AI Pipelinesを起 動できるため別途ジョブスケジューラは不要
11. 11 前処理から特徴量生成、モデル学習、評価、推論までVertex AI Pipelinesで管理 3
12. 12 BigQueryに格納した推論結果を別サービスのDBに移行 4
13. 13 Web APIでホスティングすることも 5 • オンライン推論が必要 • Web API連携の方が好ましい 上記のケースは社内で開発しているモデ ル推論基盤にデプロイする モデル推論基盤詳細は以下資料参照 機械学習基盤HekatoncheirにおけるWeb APIサービングの取り組み【DeNA TechCon 2022】
14. 14 このアーキテクチャのいいところ 6 • 使い回し、応用が効きやすい。DeNAでも複数のサービスで上記構成のレコメンドが運用中 • 使い回すことで、実装、運用が楽になる ◦ 機械学習モデルを作るデータサイエンティストがワークフローエンジン内の処理を実装するケースも ◦ 監視や障害対応も統一しやすい
15. 15 モバオクの場合
16. 16 先述のバッチでのレコメンドだと以下の問題がある 1 • 課題1: そのときユーザーが興味を持った商品をレコメンドできない • 課題2: 出品されたばかりの商品をレコメンドできない
17. 17 課題1: そのときユーザーが興味を持った商品をレコメンドできない 2 例: 昨日までは服を中心に商品を探していたが、今日はマンガを探している • 1日1回のバッチ処理を用いたレコメンドでは、服を推薦してしまう • 1日24回にバッチ処理を増やしても、次の推薦までにサービスから離れてしまうかもしれない • 直近1時間、30分、数分のデータからそれぞれ特徴量を作りオフライン指標を確認 ◦ 直近のデータがわかるほどオフライン指標は改善する傾向 ❌直近の行動履歴 から推薦できない 前日までの行動履歴で学習、 前日までの出品商品から推薦
18. 18 課題2: 出品されたばかりの商品をレコメンドできない 3 • 出品するユーザー目線だと、出品した商品にすぐに入札されるのがいいUX • 前日までの行動履歴で学習、前日までの出品商品から推薦だと、出品されたばかりの商品 をレコメンドすることができない ◦ モバオクのようなオークション・フリマサービスでは商品が次々入れ替わる 前日までの行動履歴で学習、 前日までの出品商品から推薦 ❌直近出品された 商品を推薦できない
19. 19 先述のバッチでのレコメンドだと以下の問題がある 4 • 課題1: そのときユーザーが興味を持った商品をレコメンドできない • 課題2: 出品されたばかりの商品をレコメンドできない →更新をリアルタイムに近づけたい
20. 20 その他のモバオクの課題と実現したかったこと 5 実は外部のSaaSを用いて、レコメンドシステムは実現できていた しかし、一定のパフォーマンスは出せているものの、チューニングやコスト削減の限界がきていた →コストは抑えつつ、外部SaaSで実現が難しかった、リアルタイムでユーザーが欲しい商品を 多様に提案できるレコメンドを構築し、商品発見から入札までの体験を向上させたい
21. 21 リアルタイムでレコメンドを行う大変さ 6 バッチ(1日1回) リアルタイム レイテンシー 事前にレコメンドするアイテムを計算でき るため低く抑えやすい オンライン推論が必要な場合はバッチに 比べて高くなる 開発・運用 データの連携が楽 ストリーミングで連携が必要な場合、開 発、運用がバッチに比べて難しい 機械学習 モデル 特徴量計算、推論に時間がかかるモデルで も可 モデル学習と推論を同じ環境で実装できる レイテンシー等の制約あり 学習時と推論時の環境を合わせることが 難しく、バッチよりもトレーニング / サービングスキューに気を付ける必要が ある。 コスト 1日1回ワークフローが動いている間だけ課 金される 24時間前処理や推論を走らせる必要があ り、高くなりやすい
22. リアルタイムレコメンド システムアーキテクチャ
23. 23 全体アーキテクチャ 1
24. 24 大きく3つの処理に分かれます 2 バッチパイプライン ストリーミングパイプライン レコメンドAPI
25. 25 推薦にリアルタイム性を持たせる処理 2 ストリーミングパイプライン レコメンドAPI 計算済みの商品ベクトルを取得 直近のユーザー行動履歴からユーザーベクトルを生成 ユーザーベクトルを用いて近似近傍探索より推薦する 商品一覧を取得 直近のユーザーの行動履歴を随時更新
26. 26 バッチパイプライン 3 バッチパイプライン
27. 27 バッチパイプライン 4 1. モバオクからAI基盤に毎時データ連携 (本当はここもストリーミングで連携したいが既存システムの都合でバッチ) 2. 商品のテキスト情報等から学習済みの機械学習モデルで商品ベクトルを生成 3. 商品ベクトル、商品の情報を、ANNインデックス、オンライン特徴量ストアに差分更新
28. 28 ストリーミングパイプライン 5 ストリーミングパイプライン
29. 29 ストリーミングパイプライン 6 1. ユーザーの行動をPub/Sub経由でニアリアルに連携 2. ストリーミング処理エンジンからDWHにデータを保存 3. レコメンドをユーザーに返す際に高速に返せるように、オンライン特徴量ストアにも保存 a. 実際には特徴量というほどでもなく、単にユーザーがどの商品を見たかの履歴のみ
30. 30 レコメンドAPI 7 レコメンドAPI
31. 31 レコメンドAPI 8 1. ユーザーの閲覧履歴とバッチパイプラインで生成した商品のベクトルからユーザーベクトルを生成 a. 商品A, B, Cを見ていたら、商品A, B, Cの商品ベクトルの加重平均を取るなど 2. 生成したユーザーベクトルを用いて、商品ベクトルのインデックスを検索 3. 検索結果をレスポンスとしてモバオクに返す
32. 32 リアルタイムのレコメンドの大変さと今回作ったシステムの説明 9 今回作ったシステム リアルタイム レイテンシー 重いベクトル生成は非同期処理 近似近傍探索だとレイテンシーが低く抑え られ、スケールしやすい オンライン推論が必要な場合はバッチに 比べて高くなる 開発・運用 ストリーミングでの処理は最小限 データロストしても影響は少ない ストリーミングで連携が必要な場合、開 発、運用がバッチに比べて難しい 機械学習 モデル 近似近傍探索を用いているため高速 直近N分のクリック数などの特徴量を用い ていないため、トレーニング / サービン グスキューも起きにくい レイテンシー等の制約あり 学習時と推論時の環境を合わせることが難 しく、バッチよりもトレーニング / サービ ングスキューに気を付ける必要がある。 コスト ストリーミングエンジン、オンライン特徴 量ストア、ANNインデックスは高価 24時間前処理や推論を走らせる必要があ り、高くなりやすい
33. 33 全体アーキテクチャ図に含まれない細かい部分 • 機械学習モデル(embedding生成)学習パイプライン ◦ Vertex AI Pipelinesで実装 ◦ 現在手動実行のみ。定常的に再学習しない ▪ 使っている特徴が自然言語のみのため ▪ 別の期間のデータで再学習しても精度への影響はほぼないことを確認済み • Embedding作成、インデックス作成パイプライン ◦ Vertex AI Pipelinesで実装 ◦ Vector Searchの初回インデックス作成時は、avroやjsonを入力とする必要があるため ◦ 定常的に実行するバッチパイプラインとembeddingに変換する処理は共通 10
34. 34 開発・運用でわかったこと
35. 35 本番デプロイした結果 1 既存の導入済みの外部のレコメンドサービスとの比較 • 入札率、クリック率などの主指標 ◦ 大きく改善🎉 ◦ リアルタイムに更新されるレコメンドが、ユーザーの回遊率に大きく貢献 • レイテンシー ◦ 39%減🎉 ◦ 99%tile 100ms以下 • コスト ◦ 33%減🎉 ◦ 更に削減できる見込み • システムの安定性も増した ◦ エンジニアの運用工数も減🎉
36. 36 リアルタイムレコメンドの副産物 2 • 閲覧している商品に対して、類似の商品を推薦する • 商品の詳細ページに表示する • ユーザーベースレコメンドで用いている商品ベクトルをそのまま使っている 関連する商品（アイテムベースアイテムレコメンド）
37. 37 やってみてわかったこと 3 やってみてわかったこととして、大きく以下3点について紹介します • 近似近傍探索のメリット・デメリット • 近似近傍探索後のリランキング処理の追加（見送り） • その他アーキテクチャの話
38. 38 近似近傍探索のメリットデメリット 4 ◦ メリット ▪ 高速でスケールしやすい ▪ 今回のようにオンライン推論をしてもレイテンシーに問題なし ▪ Vector Searchのようなマネージドサービスを使えば運用も楽 ◦ デメリット ▪ 多様性を出すことが難しい • 似た類似度のアイテムが固まってしまう。これを防ぐには別途処理が必要 →今後の課題 　後処理や別の推論結果との結合など検討 • Vector Searchのcrowding tag機能などもあるが、多様性を出すような tagの設計が必要
39. 39 近似近傍探索後のリランキング処理の追加（見送り） 5 • クリックを教師とするとノイズに左右されやすい ◦ Bot等によるクリックに引っ張られる、あまり推薦したくない商品を推薦してしまうなど • ストリーミングエンジン、推論処理のコストが大きい • ストリーミングエンジンでのストリーミング特徴量生成の工数がバッチ処理に比べて高い ◦ データサイエンティストがBigQueryで作った処理をapache beamの処理に書き直すなど ストリーミング特徴量生成、 ストリーミング推論を追加 推論結果をBigtableに格納
40. 40 その他細かいアーキテクチャの話 6 リランキングをせず、近似近傍探索だけで済む場合 • Dataflowでストリーミング特徴量生成、非同期推論のようなことをしなくてもいいため、Cloud Runなどのより安 価なサービスを用いてユーザーの閲覧履歴を更新できる • リランキングの要件では、短時間に大量の書き込み/読み込みが発生するため、オンライン特徴量ストアに Bigtableを用いたが、近似近傍探索だけでいいのならFirestoreなどより安価なNoSQLでもいいのかも
41. 41 まとめ
42. 42 まとめ 1 モバオクで取り組んだリアルタイムレコメンドシステムの紹介をしました • ユーザーのリアルタイムの行動履歴をストリーミングパイプラインで更新 + 近似近傍探索で推 論することで、主指標を大きく改善できました ◦ 既存のレコメンドシステムと比較し、リアルタイム性が貢献していることもわかりました • 近似近傍探索による推論は比較的実装、運用が容易 ◦ スケールしやすくレイテンシーも低い ◦ 多様性を出すには後処理や別の推論結果との結合などが必要 リアルタイムレコメンドをやりたい場合、今回紹介したようなシンプルな構成を最初に試 してみるといいかもしれません