はじめに
皆さんこんにちは! ソーシャル経済メディア「NewsPicks」プロダクトエンジニアの森田です:) 私は2024年4月に株式会社ユーザベースに新卒入社し、現在は主にNewsPicksにおける推薦機能の開発改善に携わっています。
NewsPicksでは、ユーザに価値のある経済情報を届けるための施策の一つとして記事推薦機能を導入しています。 本ブログでは、NewsPicks記事推薦機能にて基盤改善がモデル改善につながってCTR（Click Through Rate）を改善できた事例をもとに、私たちが認識した「推薦システムを本番導入する上で一番優先すべきだったこと」を共有します。
また先日行われた「実応用 × 推薦システム」をテーマとしたイベント Recommendation Industry Talks にて、本ブログの内容に関して発表させていただきました！参加者の皆様とカジュアルかつ熱心に情報交換でき、非常に楽しく有意義な時間を過ごすことができました！貴重な登壇機会をいただきありがとうございました:)
登壇資料は以下に公開していますので、もし興味がある方は合わせて見ていただけると幸いです:)
前置き: 推薦モデルを変更し、「あなたへのおすすめ」のCTRを1.2倍に改善できました!
さて本題に入る前に、NewsPicksアプリ内の記事推薦機能「あなたへのおすすめ」のCTR（Click Through Rate）を1.2倍に改善できました、という話があります。
「あなたへのおすすめ」というのは、NewsPicksアプリのトップ画面を下の方にスクロールすると表示される枠で、各ユーザの興味・関心を元にパーソナライズしニュース記事を表示しています。
ニュース推薦モデルのどこを変えた??
「あなたへのおすすめ」のCTRが改善された直接的な理由は、推薦モデルを変更したことです。
（以降、本ブログでは「推薦結果を作るロジック」のことを「推薦モデル」と呼んでいます。「推薦アルゴリズム」や「機械学習モデル」などと言い換えても問題ないかと思います…!）
推薦モデルのどこをどう変更したのかが分かるように、まず一般的なニュース推薦モデルのアーキテクチャを紹介します。以下の図は、参考文献にて紹介されているニュース推薦の一般的なフレームワークです。
上記の図を見ると、ニュース推薦モデルは以下の3つのコンポーネントで構成されていることがわかります。
- ニュース記事の特徴を抽出する News Encoder
- ユーザの特徴を抽出する User Encoder
- 特徴を元に推薦結果を作成する Click Prediction Module
- （まあ予測対象がクリックなのか否かは、ケースバイケースだと思いますが）
開発組織に応じて各コンポーネントの名称は異なるかもしれませんが、論文でも「common framework」として紹介されている通り、大きく上記の3つの役割を持つのが一般的なのかなと思います。NewsPicksのニュース推薦モデルも、おおよそ同様の構成です。今回、「あなたへのおすすめ」の改善にあたり変更したのは、3つのコンポーネントのうちの News Encoder と User Encoder になります。なので平たく言うと、ニュース記事 & ユーザの特徴を表すベクトルの作り方を変えた、ということですね。
ニュース記事 & ユーザベクトルの作り方の改善: CF中心の推薦からCB中心の推薦へ
推薦システムには、代表的なアプローチとして協調フィルタリングと内容ベースフィルタリングの2つがあります。
参考文献によると、両アプローチの概要は以下のように紹介されています。
- 協調フィルタリング（Collaborative Filtering、以降はCFと表記）
- サービス内の他のユーザの過去の行動などにより得られる好みの傾向を利用することで推薦を行う
- 内容ベースフィルタリング（Content-based Filtering、以降はCBと表記）
- アイテムの属性情報を元に、ユーザがどの内容のアイテムを好みかという情報を利用することで推薦を行う
引用元: 「推薦システム実践入門」より
前者のCF推薦は、例えば、サービス内の過去の行動履歴からユーザ1とユーザ2が同じようなニュース記事に興味を持つことがわかっている場合に、ユーザ2が既に読んでいるがユーザ1がまだ読んでいないニュース記事をユーザ1に推薦する、といったアプローチです。
一方で後者のCB推薦は、例えば、「ユーザ1は半導体分野に関する内容のニュース記事に興味がある」という情報と「ニュース記事Aは半導体分野に関連する内容を持つ」という情報をもとに、ユーザ1にニュース記事Aを推薦する、といったアプローチですね。
今回の改善では、私たちは推薦方法をCF中心のアプローチからCB中心のアプローチに変更しました。
新旧推薦モデルに対してA/Bテストを実施した結果、「あなたへのおすすめ」のCTRが日次平均で約1.2倍に向上しました。また、全体適用後も傾向が変わらなかったことから、本A/Bテストによる意思決定は偽陽性ではない、と判断しました。 このように推薦方法を大きく変更したことで、各ユーザの興味により合致した記事をおすすめできるようになりました。
主題: なぜもっと早く推薦モデルを改善できなかったのか??
さて、「CF推薦からCB推薦に推薦モデルを変更してCTRを改善できました！」という話が本ブログの主題ではありません。
なぜもっと早く推薦モデルを改善できなかったのか？？
こちらが本ブログの主題になります。
もっと早くCB推薦を採用する意思決定ができたのでは??
CF推薦は推薦システムの分野で最も一般的です。
しかしニュース推薦の領域では、CB、もしくはCFとCBのハイブリッドアプローチが主流です。あるサーベイ論文によれば、ニュース推薦モデルを提案する論文 112件のうち、CFのアプローチは19件、CBのアプローチは59件、CF&CBのハイブリッドアプローチは45件でした（”News Recommender Systems - Survey and Roads Ahead”, Karimi et al., 2018）。
ちなみに、ニュース推薦タスクにおいてCBが採用されやすい主な理由としては、例えば以下が挙げられます。
- 記事タイトルや本文のテキストを属性情報として使用しやすい
- 多くの場合、ニュース記事は価値を発揮する寿命が短いことから、コールドスタートアイテムの問題に陥りやすく、純粋なCF推薦では対応しづらい
そして私たち開発者も、CB推薦という選択肢はおそらく最初にNewsPicksに推薦システムを導入した当初から認識していました。
CB推薦の存在は認識済み。ではなぜ改善に時間がかかった??
私たちの場合は、主に以下の2点が理由として挙げられます。
- 理由1: オフライン評価の確度が低かった
- 理由2: 推薦システム基盤がA/Bテストしづらかった
以下、順に説明していきます。
理由1: オフライン評価の確度が低かった
まず、推薦システムや機械学習における二種類の評価アプローチ「オフライン評価」と「オンライン評価」について少し紹介させてください。
参考文献によると、両アプローチの概要は以下のように紹介されています。
- オフライン評価
- 実際のサービス上での閲覧や購買などのユーザの行動履歴から得られた過去のログ（サービスログ）を用いて推薦モデルの予測精度などを評価すること
- オンライン評価
- 新しいテスト対象の推薦モデルや新しいUIを一部のユーザへ実際に提出する事を通して評価を行うこと
引用元: 「推薦システム実践入門」より
前者は、実際にプロダクト上で推薦モデルを動かすのではなく、ユーザ体験に影響を与えないオフライン環境で過去のデータを使ってモデルの良し悪しを評価する、ということですね。例えば、Kaggleなどで開催されている機械学習コンペティションの評価方法は、その多くがオフライン評価だと思います。一方、後者のオンライン評価では実際にプロダクト上で推薦モデルを動かして良し悪しを判断します。最も一般的な手法の一つにA/Bテストがあります。
結果が得られるまである程度時間がかかるオンライン評価に対して、オフライン評価は、短時間でモデルに対するフィードバックが得られること、また、ユーザ体験を損なうリスクがない、などの特徴があります。
その特徴から、オフライン評価は、特にオンライン評価を実施するに値するモデル候補を選別するために用いられることが多い印象です。
このことから、推薦モデルの改善フローとして、以下の様な「オフライン評価で良さげな推薦モデルをオンライン評価する」という流れが一般的です。
そして、私たちが長らくCB推薦を採用できなかった理由の1つは、このオフライン評価の確度が低かったことにあります。
具体的には、私たちが過去のログデータを元にオフライン評価した結果、「CB推薦モデルは、現在稼働中のCF推薦モデルよりも性能が低い」と評価されていました。 実際にA/Bテストを実施してみると、CB推薦モデルの方がCTRが1.2倍くらい高かった、のにも関わらずです。 この誤ったオフライン評価結果により「あ、CB推薦はCF推薦よりも性能が低いんだな」と誤解し、A/Bテストを用いたオンライン評価に進む意思決定ができなかったわけです。
私たちは、いわゆる「オフライン-オンライン評価が相関しない」問題に遭遇していたんです。
この問題は、以前からたびたび話題にあがっている話かなと思います。
例えば、Booking.comさんのMLアプリケーション開発運用の教訓に関する論文で、以下の「相関がなかった」という相関図が有名です。
上の図では、オフライン環境でのモデル性能の推定値（横軸）とA/Bテストで観察されたビジネス指標（縦軸）の間に相関がなかったんだ、というBooking.comさんの過去の経験が示されています。論文内では、機械学習アプリケーションの開発運用経験から得られた教訓の1つとして「Modeling: Offline Model Performance Is Just A Health Check（オフラインでのモデルのパフォーマンスは健康診断に過ぎない）」が主張されています。
また、ニュース推薦システムに関するサーベイ論文内でも、オフライン評価の確度の問題は述べられています。論文内では、「オフライン実験においてCB推薦系の手法はprecisionやrecallなどの精度指標では正確に評価しづらい。一方で、CF推薦などのid-onlyな手法や人気アイテム推薦は過大評価されやすい傾向がある」と主張されていました（”News Recommender Systems - Survey and Roads Ahead”, Karimi et al., 2018）。この主張は、今回私たちが遭遇した事例と整合する内容だと思いました。
ちなみに一方で、この「オフライン-オンライン評価が相関しない」問題に対して、モデルのオンライン性能をより確度高く推定できるようなオフライン評価方法を探求する研究分野（OPE: Off-Policy Evaluation）も、数年前からホットなトピックになっているのかなと思っています。 2024年に出版された書籍『反実仮想機械学習』内ではまさにこのトピックに関する内容が多く記述されており、個人的には、このトピックが今後一気に日本のデータサイエンス界隈に普及していくのかな〜とワクワクしています。（この書籍が出てくるまではOPE関連の情報を収集するために各手法の論文を順番に読む必要があったと思いますが、この書籍は日本語で体系的に丁寧にまとめてくださっててめちゃめちゃありがたかったです…!!）
理由2: 推薦システム基盤がA/Bテストしづらかった
推薦モデルを改善できなかったもう一つの理由として、推薦システム基盤がA/Bテストしづらかったことが挙げられます。
と言うのも、2023年の夏頃まで、NewsPicksの推薦システムは現在とは別の旧基盤で稼働しており、この旧基盤がA/Bテストしづらいシステムになっていたんですね。
A/Bテストしづらかった主な理由として、以下が挙げられます。
- 機械学習のパイプラインとA/Bテスト機構が密結合で、新モデルと現行モデルの実行を独立させにくかった
- 毎日数時間かかるバッチ学習。もし新モデルの追加が原因で現行モデルのバッチ学習が失敗したら? 手動でまた処理を復旧させるのも大変。怖い...!
- リリース手順が煩雑。
上記の理由から、私たちはA/Bテスト実施に対して慎重にならざるを得ず、「オフライン評価でよっぽど筋が良いと判断されたモデルだけをA/Bテストに回そう」という方針を取っていました。 その結果、各モデルの性能の良し悪しの判断を、前述した通り、確度が低いオフライン評価により依存する形になっていたのです。
解決策: 推薦モデルを改善可能な状態にするための試み
推薦モデルを改善可能な状態にするために、以下の2つの試みを実行しました。
- 試み1: A/Bテストしやすい新推薦システム基盤へ
- 試み2: 定量的なオフライン評価を(一旦!)諦めて定性評価へ
順に紹介していきます。
試み1: A/Bテストしやすい新推薦システム基盤へ
1年以上かけて基盤改善の取り組みを行い、2023年夏頃に、推薦システム基盤を新しいものに完全に置き換えました。
以下の図は、「あなたへのおすすめ」を作る新しい推薦システム基盤の全体像を示しています。
旧基盤と比較した新基盤の大きな変更点は、ニュース推薦システムの各コンポーネントが独立したシンプルなパイプラインとして稼働している事です。 これにより、A/Bテスト時には独立したパイプラインを新規追加するだけで済むようになり、各推薦モデルは独立して稼働し何も影響は与えません。
また旧基盤では機械学習パイプラインと密結合していたA/Bテスト機構を、新基盤ではNewsPicksの共通バックエンドサーバに集約し分離しています。
各パイプラインや推論サーバは、共通の永続化ストレージ（データウェアハウス）を介して入力データや成果物を共有します。 各パイプラインはモジュラーで責務はより明確になり独立して操作可能、いわゆるFTI(Feature/Training/Inference) Pipelines Architectureっぽいシステムになり（Feature Storeは未採用なので厳密には違うかもですが）、結果として以前よりも推薦モデルのA/Bテストが簡単になりました。
試み2: 定量的なオフライン評価を(一旦!)諦めて定性評価へ
また私たちは、定量的なオフライン評価を一旦諦める判断をしました。
その理由は「まだ現段階では、オフライン評価方法をより確度が高くなるように改善することは困難である」と考えたからです。 オフライン評価の問題設定を「推薦モデルのオンライン環境での性能を、過去の観測データを使ってオフライン環境で推定すること」だと定義するならば、A/Bテストで得られたデータこそが、そのオフライン評価の正解データになるはずです。 つまり、そもそも、推薦モデルのA/Bテストを何度か実施し、正解データを十分に集めた状態になるまでは、オフライン評価方法の精度やその改善方法を適切に判断することはできないと考えたわけです。
しかし一方で、定量的なオフライン評価を諦めるからと言って、いきなり新しい推薦モデルをA/Bテストに出してしまうと、ユーザ体験を毀損させてしまうリスクがあります。なので、A/Bテスト前の推薦モデルの事前チェックはやはり一定必要…。
そこで私たちは今回、開発者自身 & PJメンバーによる定性評価を採用することにしました。 具体的には、サンプルユーザに対する推薦結果を開発者自身 & PJメンバーが目視で確認し、ユーザ体験を毀損しないか、開発者の想定通りに推薦モデルが機能しているか、などを踏まえてA/Bテストに移って問題ないかを定性的に評価・意思決定します。
一般的な機械学習モデルの精度指標(ex. nDCG@k, MAP@k, accuracy, etc.)に基づく定量的なオフライン評価と比較して、この定性評価は主観的で工芸的ですが、あくまで健康診断的な役割としてですが一定の有効性があるのではと考えています。
気づき: 推薦システムを本番導入する上で一番優先すべきだったこと
これらの経験を経て、私たちが認識した「推薦システムを本番導入する上で一番優先すべきだったこと」は、推薦モデルの良し悪しをより高い確度で評価できる実験を、より簡単に実行できる状態を作ることでした。
平たく言えば「いかにA/Bテストしやすい推薦システムを設計するか」が最も重要だった訳です。
ちなみに…A/Bテストしやすいシステムになった後の次の課題!
今回、A/Bテストしやすい推薦システム基盤に置き換えることができ、推薦モデルの改善に成功しました。
ただ、まだまだ課題というか、伸び代があると感じている部分はたくさんあるんです。
以下、今後取り組んでいきたい課題をいくつか挙げてみます。
- より確度の高いオフライン評価方法の構築
- より高速に開発・実験できる推薦システム基盤へ
今後の課題1: より確度の高いオフライン評価方法の構築
今回、私たちは定量的なオフライン評価を一旦諦めました。しかし、A/Bテストなどのオンライン評価に比べてオフライン評価は、短期間かつ低コストで推薦モデルのフィードバックを得ることができ、ユーザ体験を毀損させるリスクもありません。そのため、オフライン評価をより確度高く行えることは非常に有益です。
特に、A/Bテストの基盤が整った今、そこで収集したログデータを活用し、オフライン評価方法を改善するチャンスが生まれていると思っています。例えば、A/Bテストで推薦モデル A、Bで収集した2種類のログデータを使い、A自身が収集したデータを使って推定したAの性能（i.e. オンライン評価の値）と、Bが収集したデータを使って推定したAの性能（i.e. オフライン評価の値）を算出します。前者により近い値となる後者を算出できるオフライン評価方法が、より正確なオフライン評価方法と判断できるはずです。
従って、A/Bテストを積極的に実施して実験に適したログデータを収集することができれば、自社のユースケースに対して有効なオフライン評価方法を探すことができるのではと考えています。
また、探索的な推薦モデルの活用なども視野に入れており、よりオフライン評価や学習に適したログデータを収集しやすくなるのではと期待しています。
今後は、こうしたアプローチを積極的に試みることでより確度の高いオフライン評価を実現し、推薦システム全体の改善サイクルを向上させていきたいと考えています。
今後の課題2: より高速に開発・実験できる推薦システム基盤へ
今回の基盤改善により、以前よりも簡単にA/Bテストを実施できるようになりました。
しかし、新しいアイデアを思いついてから実験可能な状態に持っていくまでに、まだ必要以上に開発工数がかかっていると感じています。
今現在、NewsPickサービス内で推薦や機械学習の新しいユースケースが多々存在している中で、アイデアを形にして検証するまでのスピードの向上は非常に重要だと考えています。
有名なMLシステムの技術的負債論文の中でも、機械学習システムの健全性を評価する上で有効な質問として以下が紹介されています。
「How easily can an entirely new algorithmic approach be tested at full scale?（全く新しいアルゴリズムのアプローチを、どの程度簡単にfull scaleでテストできるか?）」
引用元: Hidden Technical Debt in Machine Learning Systems, Sculley et al., 2015
他社事例なども参考にしつつ、より高速により簡単に新しいアイデアをプロダクトに乗せて実験できるように基盤改善を進めていきたいと考えています。
終わりに
本ブログでは、NewsPicks記事推薦機能「あなたへのおすすめ」にてCTRを改善できた事例をもとに、私たちが認識した「推薦システムを本番導入する上で一番優先すべきだったこと」を共有しました。
結論としては「いかにA/Bテストしやすい推薦システムを設計するか」が最も重要だった、という話でした!
かつてのNewsPicksの推薦システムは、オフライン評価の結果がオンライン評価と相関しない問題に遭遇し、かつA/Bテストしづらい旧推薦システム基盤のために、推薦モデルを適切な方向に改善するのが難しい状態に陥っていました。 一方で現在では、A/Bテストしやすくなった新推薦システム基盤と、定量的なオフライン評価を一時的に諦めて定性評価を取り入れることで、推薦モデルの良し悪し、ひいては推薦機能が提供するユーザ体験の良し悪しをより高い確度で評価できる状態になっています。
NewsPicksはまさに、これから推薦システムやっていくぞ！状態なんです:)
今後も、NewsPicks内の多様な経済情報や良質なコンテンツ達が、その情報＆コンテンツに価値を感じるユーザと出会えるように、推薦システムの開発改善に取り組んでいきます…!
最後までお読みいただき、ありがとうございました！
もし気になる点やご意見・ご感想などありましたら、ぜひカジュアルにコメント頂けたら嬉しいです:)
