NewsPicksの推薦システムで 機械学習の成果をスケールさせるために~経験から学んだ観点~

本スライドは、#さくらのAI Meetup vol.8「MLOpsを学ぼう」の登壇資料です。
https://sakura-tokyo.connpass.com/event/345101/

Transcript

1. NewsPicksの推薦システムで 機械学習の成果をスケールさせるために 経験から学んだ観点 2025/03/06 さくらのAI Meetup vol.8「MLOpsを学ぼう」 株式会社ユーザベース 森田大登
2. まず自己紹介です! 2 森田 大登 • 所属: 株式会社ユーザベース • 経歴 ◦ 博士課程在学中に推薦システム分野と出会い、約 1年間のイン ターンを経て2024年4月にユーザベースに新卒入社。 ◦ 経済情報プラットフォーム NewsPicksにおける推薦システムの 開発改善に携わり中 • X（旧Twitter） ◦ @moritama7431 • 興味あること ◦ 推薦システム周り、MLOps周り (プロダクトに継続的に価値提供 していける、持続可能なMLシステムってどうやったら実現できるん だろう...!) ◦ 検索システム周りも最近携わり始めました ! 難しい...!!
3. 本発表におけるMLOpsの定義 & 今回喋りたいこと 3 • MLOps = 「機械学習の成果をスケールさせるためのさまざまな取り組み 」(書籍「事 例でわかるMLOps 機械学習の成果をスケールさせる処方箋」より引用 ) • 機械学習のビジネスやプロダクトへの主要な活用先の一つに、推薦システムなどの 意思決定最適化タスク がある。 • 本発表では、NewsPicksの推薦システムでMLの成果をスケールさせるために、実 際にどんな経験を経て、どんな観点を重視するようになったか。関連してどんな取 り組みをしているか を共有する。 ◦ 具体的には、経験したこと & それを経て重視するようになった視点 & 関連する 取り組み、を2つ共有します (時間の都合で1つだけにしました...!!🙏)
4. はじめに：NewsPicksと推薦システム 前提共有: NewsPicksのニュース推薦ってこんな感じの雰囲気 経験: 長らく推薦モデルの性能を改善できてなかった過去 経験から学んだ推薦システムのMLOpsで重要な観点 経験を踏まえた最近の取り組み おわりに 01 02 03 04 05 06 4
5. はじめに： NewsPicksと推薦システム | 01 | 5
6. NewsPicksについて 6
7. NewsPicksの3つの価値と推薦システムの関係 7 推薦システムは、キュレーション（編成）を強化し、限られた出面の中で良質なコンテンツや 多様なコメントを各ユーザに届けるためにも重要 ...!
8. 「あなたへのおすすめ」って? 記事推薦機能「あなたへのおすすめ」について紹介 • NewsPicksアプリのトップ画面を下にスク ロールすると表示される • 各ユーザの興味・関心を元にパーソナラ イズしてニュース記事を表示 以前よりもCTRが改善し、ユーザにとってより 価値のあるニュース記事を選べるようになった ので、NewsPicksのユーザの方々にはぜひ チェックしていただきたい機能の1つです:) この他にも、NewsPicksでは複数の機能で推薦 システムが活用されています！ 8 図: ある日の発表者の「あなたへのおすすめ」の表示内容。
9. 前提共有: NewsPicksのニュース 推薦システムの概要 | 03 | 9
10. NewsPicksのニュース推薦ってざっくりどんなタスク?? 10 • 推薦システムで解きたいのは、意思決定の最適化タスク ◦ 文脈xにて報酬rを最大化するような行動aを選ぶ、文脈付き多腕バンディット問題 とも言える • 実装上は、推薦モデルによって(ユーザ, 記事)ペアの関連度的なスコアを予測 し、ス コアを元にユーザにどんな記事を推薦するかの意思決定を行う。 • また、NewsPicksは経済ニュースプラットフォームのサービスなので... ◦ 新しい経済ニュースの追加に伴い、推薦候補のアイテムが日々入れ替わる ◦ 推薦対象のユーザ集合は、新規ユーザが日々増えていく ◦ → コールドスタートアイテム & ユーザの問題 に対応できる必要がある。
11. ざっくりどんな感じのモデルを使ってる? 11 引用元: Empowering News Recommendation with Pre-trained Language Models, Wu et al., 2021 • 右図が、一般的なニュース推薦モデルの アーキテクチャ例。 現在のNewsPicksもほぼ同様の構成。 ◦ 推薦システムの実務で人気な、いわゆ るTwo-Towerモデルっぽい構造。 • 主に3つのコンポーネントで構成される ◦ 記事埋め込みを作るNews Encoder ◦ ユーザ埋め込みを作るUser Encoder ◦ 埋め込みを元に関連度スコアを 計算するClick Prediction Module （ちなみに予測対象がクリックなのか否かは、報酬設計や 学習の戦略次第だと思います ...!!)
12. 推薦モデルをざっくりどのように本番稼働させている?? 12 図: ニュース推薦モデルを本番システムでどのように稼働させているか 前述の3種のコンポーネントが、独立したデータパイプラインとして稼働する • News Encoder & User Encoderで埋め込みを事前計算しておけるので、 Click Prediction Moduleで推 薦結果を作る際の計算コストが小さく済む、という利点がある。 • Click Prediction Moduleは、リアルタイム推論とバッチ推論のケースがそれぞれ存在する。
13. 経験: 長らく推薦モデルの性能を 改善できてなかった過去 | 04 | 13
14. 時間の都合上、本発表ではある程度抽象化 & 省略して共有するので、興味を持ってくださった方はぜひこ ちらを読んでいただけたら嬉しいです...!! ちなみに、今回の「経験」の詳細を知りたい場合はこちら! 14 link: https://tech.uzabase.com/entry/2024/08/29/161828 link: https://speakerdeck.com/morinota/tui-jian-sisutemuwoben-fan-dao-ru-surushang-de-fan-you-xian-subekidatutakoto-n ewspicksji-shi-tui-jian-ji-neng-nogai-shan-shi-li-woyuan-ni
15. 昨年、NewsPicksの「あなたへのおすすめ」機能に て、推薦モデルを変更してCTRを従来の1.2倍に改善 できました！ しかしその背景には、長らく推薦モデルの性能を改 善できていなかった過去がありました。 その原因として、主に以下の2点がありました: • 原因1: オフライン評価の確度が低かった • 原因2: 推薦システム基盤がA/Bテストしづらかった 15
16. まずオフライン評価とは?? 原因1: オフライン評価の確度が低かった 16 オフライン評価 - 実際のサービス上での閲覧や購買などのユーザ の行動履歴から得られた過去のログ（サービスロ グ）を用いて推薦モデルの予測精度などを評価す ること。 - Kaggle等のコンペの評価方法はこちらが多い。 オンライン評価 - 新しいテスト対象の推薦モデルや新しいUIを 一部のユーザへ実際に提出する事を通して評価を 行うこと。 - 一般的なオンライン評価にA/Bテストがある。 • オンライン評価に対して、オフライン評価は、短時間でモデルに対するフィードバックが得られるこ と、また、ユーザ体験を損なうリスクがない、などの特徴がある • そのため、オフライン評価は、特にオンライン評価を実施するに値するモデル候補を選別するための ステップとして用いられることが多い
17. オフライン-オンライン評価が相関しない問題! 原因1: オフライン評価の確度が低かった • オフライン評価で良さげなモデルをオンライン評価す る、という一般的な流れ (右上図) • しかし我々の場合はオフライン評価の確度が低かった ◦ CTR1.2倍改善できた新しいモデルは、現在稼働中 のモデルよりも性能が低いと評価されていた ◦ → A/Bテストを用いたオンライン評価に進む意思 決定ができなかった • 右下図は、「相関がなかった」という有名な相関図。 • ニュース推薦のサーベイ論文でも「特定の種類のモデ ルが過大評価されやすい傾向」が主張されていた。 17 図: 一般的な推薦モデルの改善フロー 図: Booking.comさん論文の有名な図。論文内では、オフライン環境でのモ デル性能の推定値(横軸)と、A/Bテストで観察されたビジネス指標(縦軸)の 間に相関がなかったんだ、オフライン評価は健康診断にしか過ぎなかった んだ、という過去の経験を主張していた。
18. 2023年の夏頃まで、NewsPicksの推薦システムは現在とは別の旧基盤で稼働していた 原因2: 推薦システム基盤がA/Bテストしづらかった 18 • A/Bテストしづらかった主な理由 ◦ 機械学習パイプラインとA/Bテスト機構が密結合で、新モデルと現行モデルの実行を 独立させにくかった ◦ 毎日数時間かかるバッチ学習。もし新モデルの追加が原因で現行モデルのバッチ学習 が失敗したら? 手動でまた処理を復旧させるのも大変。怖い...! ◦ リリース手順が複雑 • 結果として、A/Bテスト実施に対して慎重にならざるを得ない状態: 「オフライン評価で よっぽど筋が良いと判断されたモデルだけをA/Bテストに回そう」 ◦ →各モデルの性能の良し悪しの判断を、確度が低いオフライン評価により依存する形 に...
19. • 試み1: A/Bテストしやすい新推薦システム基盤へ！ • 試み2: 定量的なオフライン評価を(一旦!)諦めて定性評価へ！ (これらの試みの結果として、冒頭のCTR 1.2倍改善を実現できた訳 です...！) 前述の2つの原因に対して、 推薦モデルを改善可能な状態にするために、 以下の2点の試みを実行しました! 19
20. 改善の試み1: A/Bテストしやすい新推薦システム基盤へ 20 各パイプラインはモジュラーで、責務はより明確になり、独立して操作可能。 FTI(Feature/Training/Inference) Pipelines Architectureっぽいシステムになり、結果として以前よりも推 薦モデルのA/Bテストが安全になりました! （Feature Storeは未採用なので厳密には違うかもですが） 1年くらいかけて基盤改善! • 各コンポーネントが独立したシ ンプルなパイプラインに! ◦ A/Bテスト時は、新しい モデル用のパイプライン を新規追加するだけ ◦ 各モデルは独立して稼働 し何の影響も与えない 図: 「あなたへのおすすめ」を作る新推薦システム基盤 (2024年夏時点)
21. 改善の試み2: 定量的オフライン評価を一旦諦めて定性評価へ 21 今はまだ、オフライン評価方法の改善は困難 • A/Bテストで得られたオンラインの観測結果は、オフ ライン評価の正解データになるはず ◦ そもそもA/Bテストを何度か実施しないと、オフ ライン評価方法の精度を判断できないのでは...! • じゃあA/Bテスト前のオフライン評価を完全にやめる? ◦ →ユーザ体験を毀損させるリスク • 開発者自身 & PJメンバーによる定性評価を採用！ ◦ サンプルユーザの推薦結果を目視で確認 ◦ あくまで健康診断的な役割として、A/Bテストに 移って問題ないかを定性的に評価・意思決定 図: 定量的なオフライン評価を諦めて、定性評価へ
22. 経験から学んだ推薦システムの MLOpsで重要な観点 | 05 | 22
23. 推薦モデルの良し悪しをより高い確度で評価で きる実験を、より簡単に安全に実行できる状態 を作ること、 平たくいうと「A/Bテストしやすいシステムで あること」が、推薦システムを継続的に改善し 成果をスケールさせるための必須観点である。 この経験以降、「A/Bテストしやすいシステムであるか」は、推 薦システム基盤の開発・改善の際に常に意識すべき重要事項であ るとして、チーム内で共通認識を持つようになった! 23
24. 経験を踏まえた最近の取り組み | 05 | 24
25. もっとA/Bテストしやすい推薦システム基盤へ 25 前述の経験を通して得た重要観点「A/Bテストしやすいシステム」を要素分解してみると... 現在のNewsPicksの推薦システム基盤は、新しい推薦モデルをA/Bテストできる状態に至るま でに、安全ではあるが学習コスト & 手間がかかるような実装になっていた。 安全性は維持しつつ、全く新しい推薦モデルをもっと速く簡単にA/Bテストできる世界を目 指さねば...!! 安全性 新モデルの追加が、現行モデルの稼働 に悪影響を与えないこと。 (こちらは改善済み!) 開発・運用の容易さ 新しい推薦モデルを最小の工数で 本番稼働させられること。 学習コストが低いこと。
26. 改善①Sagemakerのマネージドな機能の利用を最小限に！ 26 • NewsPicksの推薦システム基盤では、MLパイプライン用の計算リソースとして Sagemaker TrainingJobというAWSのマネージドなバッチ処理サービスを採用。 ◦ (ちなみに、学習だけでなく特徴量生成とバッチ推論でも使い倒している) ◦ そのためSagemakerの学習コストが発生。 Sagemakerのお作法を一定知ってる人 じゃないと、推薦モデルを本番環境で開発しづらい状況だった。 • 改善: Sagemaker TrainingJobのマネージドな機能の利用を最小限に! ◦ TrainingJobをコンテナ実行環境の役割のみに! (指定したコンテナイメージを、指定 したEC2インスタンスタイプで、指定したエントリーポイントで実行するだけ!) • 結果: Sagemakerの学習コストをほぼ０にできた！ ◦ Sagemakerの仕様を全く気にせずに推薦モデルの本番用コードを書ける。 ◦ 必要に応じて、他の計算リソースへの切り替えも容易。
27. 改善の試み②MLパイプライン達のコンテナイメージを共通化! 27 • 各パイプラインごとに異なるコンテナイメージを作る運用。 • その結果、パイプライン間でコードの共通化がしづらく、追 加する度にcdk周りの修正も必要。管理すべきリソースも本番 コードも、毎回必要以上に増えていた感。 • 改善: 全パイプラインのコンテナイメージを共通化。コンテナ の起動時にエントリーポイントを切り替える運用に! • 結果: 新モデル(i.e.新パイプライン)追加の手間を減らせた! ◦ コードの共通化しやすさ。cdkの修正不要。 ◦ 管理するECR & コンテナイメージの数が1つに！ • 異なる推薦モデル間にコンテナイメージの結合が発生する が、全てのアーキテクチャはトレードオフ。許容する判断。 before after
28. おわりに 28
29. まとめ 29 • NewsPicksの推薦システムでのMLOps (=機械学習の成果をスケールさせるための様々な取り 組み) として、実際にどんな経験をして、どんな観点を重視するようになったかを共有した。 ◦ システム基盤の刷新を経てようやく推薦モデルを改善できた経験を通じて、 「A/Bテストしやすいシステムであるか」を推薦システムのMLOpsにおける必須観点と して重視するようになった。 ◦ 関連する取り組みとして、全く新しい推薦モデルをA/Bテスト可能な状態にするまでの 開発サイクルを2倍簡単 & 2倍高速にするための基盤改善を行った。 • 今後取り組んでいくこと ◦ ストリーミングパイプライン(i.e. ストリーミング特徴量)の導入の検討 ◦ A/Bテストしやすさだけではきっと不十分! オフライン評価&オフライン学習の精度改善 NewsPicks、これからも推薦システムの成果をスケールさせられるようにやっていくぞー！
30. 参考文献 1. 書籍「推薦システム実践入門」 2. 書籍「反実仮想機械学習」 3. 書籍「事例でわかるMLOps~機械学習の成果をスケールさせる処方箋~」 4. 書籍「機械学習システムデザイン」 5. Booking.comさんの論文: 150 Successful Machine Learning Models: 6 Lessons Learned at Booking com 6. ニュース推薦のサーベイ論文: News Recommender Systems - Survey and Roads Ahead 7. MLシステムの技術的負債の論文: Hidden Technical Debt in Machine Learning Systems 8. FTI Pipelines Architectureが提案されていたブログ: From MLOps to ML Systems with Feature/Training/Inference Pipelines The Mental Map for MLOps to align your Data-ML-Product Teams 9. Microsoftニュース推薦の論文: Empowering News Recommendation with Pre-trained Language Models 10. TrainingJobの説明がわかりやすかった@kazuneetさんのブログ: エンジニア目線で始める Amazon SageMaker Training ①機械学習 を使わないはじめての Training Job 11. TrainingJobを学習以外に使ってる事例1: Amazon SageMakerを活用した推論パイプライン運用　ディー・エヌ・エーのエンジニ アが語る構成とツール検討の試行錯誤 12. TrainingJobを学習以外に使ってる事例2: 【覚書】SageMakerトレーニングジョブで推論回す本 30
31. 最後までご清聴ありがとうございました! もし気になる点やご意見・ご感想などあれば、 ぜひカジュアルにコメント頂けたら嬉しいです:) Thank you 31 （引用: 映像研には手を出すな！、大童澄瞳/小学館）