推薦システムを本番導入する上 で一番優先すべきだったこと ~NewsPicks記事推薦機能の改善事例を元に~ 株式会社ユーザベース 森田大登 2024/07/24 Recommendation Industry Talks

まず自己紹介です! 2 森田 大登 ● 所属: 株式会社ユーザベース ● 経歴 ○ 博士課程在学中に推薦システム分野と出会い、約 1年間のイン ターンを経て2024年4月にユーザベースに新卒入社。 ○ 経済情報プラットフォーム NewsPicksにおける推薦システムの 開発改善に携わり中 ● X（旧Twitter） ○ @moritama7431 ● 悩み: ○ 「n週連続推薦システム系論文読んだシリーズ」というブログ連載 が、社会人になって以降更新できていない ...! ● 興味あること ○ 推薦システム周り、MLOps周り (プロダクトに継続的に価値提供 していける、持続可能なMLシステムってどうやったら実現できるん だろう...!)

はじめに：NewsPicksと推薦システム 前置き: 推薦モデルを変更し、「あなたへのおすすめ」のCTR を1.2倍に改善できました! 主題: なぜもっと早く推薦モデルを改善できなかったのか?? 解決策: 推薦モデルを改善可能な状態にするための試み 気づき: 推薦システムを本番導入する上で一番優先すべきだっ たこと おわりに 01 02 03 04 05 06 3

4 はじめに： NewsPicksと推薦システム | 01 |

NewsPicksについて 5

NewsPicksの3つの価値と推薦システムの関係 6 推薦システムは、キュレーション（編成）を強化し、限られた出面の中で良質なコンテンツや 多様なコメントを各ユーザに届けるためにも重要 ...!

「あなたへのおすすめ」って? 記事推薦機能「あなたへのおすすめ」について紹介 ● NewsPicksアプリのトップ画面を下にスク ロールすると表示される ● 各ユーザの興味・関心を元にパーソナラ イズしてニュース記事を表示 以前よりもCTRが改善し、ユーザにとって価値 のあるニュース記事を選べるようになったの で、NewsPicksのユーザの方々にはぜひチェッ クしていただきたい機能の1つです:) 7 図: ある日の私の「あなたへのおすすめ」の表示内容。

前置き: 推薦モデルを変更し、 「あなたへのおすすめ」のCTR を1.2倍に改善できました! | 02 | 8

ニュース推薦モデルのどこを変えた?? ● 右図は一般的なニュース推薦モデルのアーキテク チャ例（NewsPicksも大体こんな感じです!） ● ざっくり3つのコンポーネントで構成されてる ○ News Encoder: ニュースの特徴を抽出 ○ User Encoder: ユーザの特徴を抽出 ○ Prediction Module: 特徴から推薦結果を作成 ● 「あなたへのおすすめ」の改善にあたり変更したの は、前2つ: News Encoder と User Encoder ○ →　要するにニュース & ユーザのベクトルの 作り方を変えた！ 9 図: ニュース推薦の一般的なフレームワーク。Microsoftさんのニュース推 薦モデルを提案する論文 Wu et al. 2021から引用。

CF中心の推薦からCB中心の推薦へ ニュース&ユーザベクトルの作り方の改善 協調フィルタリング (Collaborative Filtering, CF) サービス内の他のユーザの過去の行動などに より得られる好みの傾向を利用することで推 薦を行う 10 内容ベースフィルタリング (Content-based Filtering, CB） アイテムの属性情報を元に、ユーザがどの内 容のアイテムを好みかという情報を利用する ことで推薦を行う A/Bテストを実施し、新推薦モデルで 「あなたへのおすすめ」の CTRが日 次平均で約 1.2倍に! 全体適用後も傾向変わらず ! (偽陽性じゃなさそう)

主題: なぜもっと早く推薦モデ ルを改善できなかったのか?? | 03 | 11

もっと早くCB推薦を採用する意思決定ができたのでは?? 12 ● CFは推薦システムの分野で最も一般的。しかしニュース推薦の領域では、CB、もしくはCFと CBのハイブリッドアプローチが主流 (ニュース推薦のサーベイ論文 Karimi et al. 2018) ○ ニュース推薦モデルを提案する論文 112件のうち、CF=19件、CB=59件、CF&CB=45件 ● CBが採用されやすい主な理由 ○ 記事タイトルや本文のテキストを属性情報として使用しやすい ○ 多くの場合、ニュースは価値を発揮する寿命が短い→コールドスタートアイテムの問題 →純粋なCF推薦では対応しづらい 私たち開発者も、CB推薦という選択肢はおそらく最初にNewsPicksに推薦システムを導入した当初か ら認識していたと思います。 というのも...

我々の場合は、主に以下の2点が理由として挙げられます: ● 理由1: オフライン評価の確度が低かった ● 理由2: 推薦システム基盤がA/Bテストしづらかった CB推薦の存在は認識済み。 じゃあなぜ改善に時間がかかった?? 13

まずオフライン評価とは?? 理由1: オフライン評価の確度が低かった 14 オフライン評価 - 実際のサービス上での閲覧や購買などのユーザ の行動履歴から得られた過去のログ（サービスロ グ）を用いて推薦モデルの予測精度などを評価す ること。 - Kaggle等のコンペの評価方法はこちらが多い。 オンライン評価 - 新しいテスト対象の推薦モデルや新しいUIを 一部のユーザへ実際に提出する事を通して評価を 行うこと。 - 一般的なオンライン評価にA/Bテストがある。 ● オンライン評価に対して、オフライン評価は、短時間でモデルに対するフィードバックが得られるこ と、また、ユーザ体験を損なうリスクがない、などの特徴がある ● そのため、オフライン評価は、特にオンライン評価を実施するに値するモデル候補を選別するための ステップとして用いられることが多い

オフライン-オンライン評価が相関しない問題! 理由1: オフライン評価の確度が低かった ● オフライン評価で良さげなモデルをオンライン評価す る、という一般的な流れ (右上図) ● しかし我々の場合はオフライン評価の確度が低かった ○ 過去のログデータ&一般的な精度指標(ex. nDCG) ○ CB推薦のモデルは、現在稼働中のCF推薦のモデ ルよりも性能が低いと評価された ○ → A/Bテストを用いたオンライン評価に進む意思 決定ができなかった ● 右下図は、「相関がなかった」という有名な相関図 ● 「CF推薦などのid-only手法や人気アイテム推薦は過大 評価されやすい傾向」(ニュース推薦サーベイ論文より) 15 図: 一般的な推薦モデルの改善フロー 図: Booking.comさん論文の有名な図。論文内では、オフライン環境でのモ デル性能の推定値(横軸)と、A/Bテストで観察されたビジネス指標(縦軸)の 間に相関がなかったんだ、オフライン評価は健康診断にしか過ぎなかった んだ、という過去の経験を主張していた。

2023年の夏頃まで、NewsPicksの推薦システムは現在とは別の旧基盤で稼働していた 理由2: 推薦システム基盤がA/Bテストしづらかった 16 ● A/Bテストしづらかった主な理由 ○ 機械学習パイプラインとA/Bテスト機構が密結合で、新モデルと現行モデルの実行を独立させに くかった ○ 毎日数時間かかるバッチ学習。もし新モデルの追加が原因で現行モデルのバッチ学習が失敗した ら? 手動でまた処理を復旧させるのも大変。怖い...! ○ リリース手順が複雑 ● A/Bテスト実施に対して慎重にならざるを得ない状態: 「オフライン評価でよっぽど筋が良いと判断され たモデルだけをA/Bテストに回そう」 ○ →各モデルの性能の良し悪しの判断を、確度が低いオフライン評価に、より依存する形に...

解決策: 推薦モデルを改善可能 な状態にするための試み | 04 | 17

● 試み1: A/Bテストしやすい新推薦システム基盤へ！ ● 試み2: 定量的なオフライン評価を(一旦!)諦めて定性評価へ！ 推薦モデルを改善可能な状態にするために、以下 の2点の試みを実行しました! 18

各パイプラインはモジュラーで、責務はより明確になり、独立して操作可能。 FTI(Feature/Training/Inference) Pipelines Architectureっぽいシステムになり、結果として以前よりも推 薦モデルのA/Bテストが簡単になりました。（Feature Storeは未採用なので厳密には違うかもですが） 1年くらいかけて基盤改善! 試み1: A/Bテストしやすい新推薦システム基盤へ！ ● 各コンポーネントが独立したシ ンプルなパイプラインに! ○ A/Bテスト時は独立した パイプラインを新規追加 するだけ ○ 各モデルは独立して稼働 し何の影響も与えない 19 図: 「あなたへのおすすめ」を作る新推薦システム基盤。

今はまだ、オフライン評価方法の改善は困難 試み2: 定量的なオフライン評価を(一旦!)諦めて定性評価へ！ ● A/Bテストで得られたオンラインの観測結果は、オフ ライン評価の正解データになるはず ○ A/Bテストを何度か実施しないと、オフライン評 価方法の精度を判断できないのでは...! ● じゃあA/Bテスト前のオフライン評価を完全にやめる? ○ →ユーザ体験を毀損させるリスク ● 開発者自身 & PJメンバーによる定性評価を採用！ ○ サンプルユーザの推薦結果を目視で確認 ○ あくまで健康診断的な役割として、A/Bテストに 移って問題ないかを定性的に評価・意思決定 20 図: 定性的なオフライン評価を諦めて、定性評価へ

気づき: 推薦システムを本番導 入する上で一番優先すべきだっ たこと | 05 | 21

平たく言えば、 「いかにA/Bテストしやすい推薦システムを設計するか」 が大事だった...! 推薦モデルの良し悪しをより高い確度で評価 できる実験を、より簡単に実行できる状態を 作ること 22

ちなみに...A/Bテストしやすいシステムになった後の次の課題! 今回、A/Bテストしやすい推薦システム基盤に置き換えることができ、推薦モデルの改善に成功しました。 ただ、まだまだ課題というか、伸び代があると感じている部分はたくさんあるんです! 今後取り組んでいきたい課題は、例えば以下があります: ● より確度の高いオフライン評価方法の構築 ● より高速に開発・実験できる推薦システム基盤へ 23

今後の課題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ができる! オフライン学習もできる!

● 今回の基盤改善により、以前よりも簡単にA/Bテストを実施できるようになった。 ● しかし、新しいアイデアを思いついてから実験可能な状態に持っていくまでに、まだ必要以上に開 発工数がかかっている気がする...! ○ NewsPicksサービス内で推薦や機械学習の新しいusecaseが多々存在する中で、アイデアを形 にして検証するスピードの向上は重要...! ● 有名なMLシステムの技術的負債論文によると... ○ 機械学習システムの健全性を評価する上で有効な質問: 「How easily can an entirely new algorithmic approach be tested at full scale?(全く新しいアル ゴリズムのアプローチを、どの程度簡単にfull scaleでテストできるか?)」 他社事例なども参考にしつつ、より高速により簡単に新しいアイデアをプロダクトに乗せて実験できるよ うに基盤改善を進めていきたい 今後の課題2: より高速に開発・実験できる推薦システム基盤へ 25 さらに早くA/Bテストできるはず...!

おわりに | 06 | 26

おわりに ● NewsPicks記事推薦機能「あなたへのおすすめ」にてCTRを改善できた事例を元に、我々が認識した 「推薦システムを本番導入する上で一番優先すべきだったこと」を共有した ○ →結論「いかにA/Bテストしやすい推薦システムにするか」が大事だった...! NewsPicksの推薦システムは... ● かつては.... ○ オフライン評価がオンライン評価と相関しない問題, A/Bテストしづらい旧推薦システム基盤... ○ →推薦モデルを適切な方向に改善するのが難しい状態だった ● 一方で現在は... ○ A/Bテストしやすくなった新推薦システム基盤! 定量的オフライン評価を(一旦)諦めて定性評価! ○ →推薦モデルの良し悪し、ひいては推薦機能が提供するユーザ体験の良し悪しをより高い確度 で評価できる状態になった! →NewsPicks、これから推薦システムやっていくぞ状態なんです！:) 27

参考文献 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

最後までご清聴ありがとうございました! もし気になる点やご意見・ご感想などあれば、 ぜひカジュアルにコメント頂けたら嬉しいです:) Thank you 29