Upgrade to Pro — share decks privately, control downloads, hide ads and more …

推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事...

 推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~

本記事は、Recommendation Industry Talks #3での登壇資料です。

ソーシャル経済メディアNewsPicksでは、ユーザに価値のある経済情報を届けるための施策の一つとして記事推薦機能を導入しています。本発表では、NewsPicks記事推薦機能にて基盤改善がアルゴリズム改善につながってタップ率を改善できた事例をもとに、我々が認識した「推薦システムを本番導入する上で一番優先すべきだったこと」を共有します。

MasatoMasaMasa

July 26, 2024
Tweet

Other Decks in Technology

Transcript

  1. まず自己紹介です! 2 森田 大登 • 所属: 株式会社ユーザベース • 経歴 ◦

    博士課程在学中に推薦システム分野と出会い、約 1年間のイン ターンを経て2024年4月にユーザベースに新卒入社。 ◦ 経済情報プラットフォーム NewsPicksにおける推薦システムの 開発改善に携わり中 • X(旧Twitter) ◦ @moritama7431 • 悩み: ◦ 「n週連続推薦システム系論文読んだシリーズ」というブログ連載 が、社会人になって以降更新できていない ...! • 興味あること ◦ 推薦システム周り、MLOps周り (プロダクトに継続的に価値提供 していける、持続可能なMLシステムってどうやったら実現できるん だろう...!)
  2. ニュース推薦モデルのどこを変えた?? • 右図は一般的なニュース推薦モデルのアーキテク チャ例(NewsPicksも大体こんな感じです!) • ざっくり3つのコンポーネントで構成されてる ◦ News Encoder: ニュースの特徴を抽出

    ◦ User Encoder: ユーザの特徴を抽出 ◦ Prediction Module: 特徴から推薦結果を作成 • 「あなたへのおすすめ」の改善にあたり変更したの は、前2つ: News Encoder と User Encoder ◦ → 要するにニュース & ユーザのベクトルの 作り方を変えた! 9 図: ニュース推薦の一般的なフレームワーク。Microsoftさんのニュース推 薦モデルを提案する論文 Wu et al. 2021から引用。
  3. CF中心の推薦からCB中心の推薦へ ニュース&ユーザベクトルの作り方の改善 協調フィルタリング (Collaborative Filtering, CF) サービス内の他のユーザの過去の行動などに より得られる好みの傾向を利用することで推 薦を行う 10

    内容ベースフィルタリング (Content-based Filtering, CB) アイテムの属性情報を元に、ユーザがどの内 容のアイテムを好みかという情報を利用する ことで推薦を行う A/Bテストを実施し、新推薦モデルで 「あなたへのおすすめ」の CTRが日 次平均で約 1.2倍に! 全体適用後も傾向変わらず ! (偽陽性じゃなさそう)
  4. もっと早くCB推薦を採用する意思決定ができたのでは?? 12 • CFは推薦システムの分野で最も一般的。しかしニュース推薦の領域では、CB、もしくはCFと CBのハイブリッドアプローチが主流 (ニュース推薦のサーベイ論文 Karimi et al. 2018)

    ◦ ニュース推薦モデルを提案する論文 112件のうち、CF=19件、CB=59件、CF&CB=45件 • CBが採用されやすい主な理由 ◦ 記事タイトルや本文のテキストを属性情報として使用しやすい ◦ 多くの場合、ニュースは価値を発揮する寿命が短い→コールドスタートアイテムの問題 →純粋なCF推薦では対応しづらい 私たち開発者も、CB推薦という選択肢はおそらく最初にNewsPicksに推薦システムを導入した当初か ら認識していたと思います。 というのも...
  5. まずオフライン評価とは?? 理由1: オフライン評価の確度が低かった 14 オフライン評価 - 実際のサービス上での閲覧や購買などのユーザ の行動履歴から得られた過去のログ(サービスロ グ)を用いて推薦モデルの予測精度などを評価す ること。

    - Kaggle等のコンペの評価方法はこちらが多い。 オンライン評価 - 新しいテスト対象の推薦モデルや新しいUIを 一部のユーザへ実際に提出する事を通して評価を 行うこと。 - 一般的なオンライン評価にA/Bテストがある。 • オンライン評価に対して、オフライン評価は、短時間でモデルに対するフィードバックが得られるこ と、また、ユーザ体験を損なうリスクがない、などの特徴がある • そのため、オフライン評価は、特にオンライン評価を実施するに値するモデル候補を選別するための ステップとして用いられることが多い
  6. オフライン-オンライン評価が相関しない問題! 理由1: オフライン評価の確度が低かった • オフライン評価で良さげなモデルをオンライン評価す る、という一般的な流れ (右上図) • しかし我々の場合はオフライン評価の確度が低かった ◦

    過去のログデータ&一般的な精度指標(ex. nDCG) ◦ CB推薦のモデルは、現在稼働中のCF推薦のモデ ルよりも性能が低いと評価された ◦ → A/Bテストを用いたオンライン評価に進む意思 決定ができなかった • 右下図は、「相関がなかった」という有名な相関図 • 「CF推薦などのid-only手法や人気アイテム推薦は過大 評価されやすい傾向」(ニュース推薦サーベイ論文より) 15 図: 一般的な推薦モデルの改善フロー 図: Booking.comさん論文の有名な図。論文内では、オフライン環境でのモ デル性能の推定値(横軸)と、A/Bテストで観察されたビジネス指標(縦軸)の 間に相関がなかったんだ、オフライン評価は健康診断にしか過ぎなかった んだ、という過去の経験を主張していた。
  7. 2023年の夏頃まで、NewsPicksの推薦システムは現在とは別の旧基盤で稼働していた 理由2: 推薦システム基盤がA/Bテストしづらかった 16 • A/Bテストしづらかった主な理由 ◦ 機械学習パイプラインとA/Bテスト機構が密結合で、新モデルと現行モデルの実行を独立させに くかった ◦

    毎日数時間かかるバッチ学習。もし新モデルの追加が原因で現行モデルのバッチ学習が失敗した ら? 手動でまた処理を復旧させるのも大変。怖い...! ◦ リリース手順が複雑 • A/Bテスト実施に対して慎重にならざるを得ない状態: 「オフライン評価でよっぽど筋が良いと判断され たモデルだけをA/Bテストに回そう」 ◦ →各モデルの性能の良し悪しの判断を、確度が低いオフライン評価に、より依存する形に...
  8. 各パイプラインはモジュラーで、責務はより明確になり、独立して操作可能。 FTI(Feature/Training/Inference) Pipelines Architectureっぽいシステムになり、結果として以前よりも推 薦モデルのA/Bテストが簡単になりました。(Feature Storeは未採用なので厳密には違うかもですが) 1年くらいかけて基盤改善! 試み1: A/Bテストしやすい新推薦システム基盤へ! •

    各コンポーネントが独立したシ ンプルなパイプラインに! ◦ A/Bテスト時は独立した パイプラインを新規追加 するだけ ◦ 各モデルは独立して稼働 し何の影響も与えない 19 図: 「あなたへのおすすめ」を作る新推薦システム基盤。
  9. 今はまだ、オフライン評価方法の改善は困難 試み2: 定量的なオフライン評価を(一旦!)諦めて定性評価へ! • A/Bテストで得られたオンラインの観測結果は、オフ ライン評価の正解データになるはず ◦ A/Bテストを何度か実施しないと、オフライン評 価方法の精度を判断できないのでは...! •

    じゃあA/Bテスト前のオフライン評価を完全にやめる? ◦ →ユーザ体験を毀損させるリスク • 開発者自身 & PJメンバーによる定性評価を採用! ◦ サンプルユーザの推薦結果を目視で確認 ◦ あくまで健康診断的な役割として、A/Bテストに 移って問題ないかを定性的に評価・意思決定 20 図: 定性的なオフライン評価を諦めて、定性評価へ
  10. 今後の課題1: より確度の高いオフライン評価方法の構築 24 A/Bテストのコストが下がれば、オフライン評価方法も改善ができるはず...! • 一度は定量的なオフライン評価を諦めたが、A/Bテストよりも短期間、低コストで推薦モデルの フィードバックを得られるため、確度の高いオフライン評価ができたらそりゃあ嬉しい! • オフライン評価の問題設定: ◦

    データ収集時の推薦モデル π_0 で収集した過去のログデータ D:=(x,a,r)^N を用いて、(π_0 とは異なる) 評価したい推薦モデル π の性能を推定すること • → 推薦モデル A , B で収集したログデータD_ , D_ さえ用意できれば、Aの真の性能 V(pi_A | D と推定値 \hat{V}(pi_Aを比較することで、オフライン評価の精度を検証できる ◦ A/Bテストしやすい基盤を作り、A/Bテストの実施によってデータセット(D_ , D_ )を収集する ことができれば、自社の環境に適したオフライン評価方法を見つけられるのでは...!! • もし確度の高いオフライン評価方法が実現できれば... Kaggleができる! オフライン学習もできる!
  11. • 今回の基盤改善により、以前よりも簡単にA/Bテストを実施できるようになった。 • しかし、新しいアイデアを思いついてから実験可能な状態に持っていくまでに、まだ必要以上に開 発工数がかかっている気がする...! ◦ NewsPicksサービス内で推薦や機械学習の新しいusecaseが多々存在する中で、アイデアを形 にして検証するスピードの向上は重要...! • 有名なMLシステムの技術的負債論文によると...

    ◦ 機械学習システムの健全性を評価する上で有効な質問: 「How easily can an entirely new algorithmic approach be tested at full scale?(全く新しいアル ゴリズムのアプローチを、どの程度簡単にfull scaleでテストできるか?)」 他社事例なども参考にしつつ、より高速により簡単に新しいアイデアをプロダクトに乗せて実験できるよ うに基盤改善を進めていきたい 今後の課題2: より高速に開発・実験できる推薦システム基盤へ 25 さらに早くA/Bテストできるはず...!
  12. おわりに • NewsPicks記事推薦機能「あなたへのおすすめ」にてCTRを改善できた事例を元に、我々が認識した 「推薦システムを本番導入する上で一番優先すべきだったこと」を共有した ◦ →結論「いかにA/Bテストしやすい推薦システムにするか」が大事だった...! NewsPicksの推薦システムは... • かつては.... ◦

    オフライン評価がオンライン評価と相関しない問題, A/Bテストしづらい旧推薦システム基盤... ◦ →推薦モデルを適切な方向に改善するのが難しい状態だった • 一方で現在は... ◦ A/Bテストしやすくなった新推薦システム基盤! 定量的オフライン評価を(一旦)諦めて定性評価! ◦ →推薦モデルの良し悪し、ひいては推薦機能が提供するユーザ体験の良し悪しをより高い確度 で評価できる状態になった! →NewsPicks、これから推薦システムやっていくぞ状態なんです!:) 27
  13. 参考文献 1. 推薦システム実践入門 2. 反実仮想機械学習 3. Booking.comさんの論文: 150 Successful Machine

    Learning Models: 6 Lessons Learned at Booking com 4. ニュース推薦のサーベイ論文: News Recommender Systems - Survey and Roads Ahead 5. MLシステムの技術的負債の論文: Hidden Technical Debt in Machine Learning Systems 6. 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 7. Microsoftニュース推薦の論文: Empowering News Recommendation with Pre-trained Language Models 28