NewsPicksAdvent Calendar 2024

推薦システムのオフライン評価&学習を諦めない! 確率的なデータ収集方策の有効性を実験してみる

Last updated at 2024-12-21Posted at 2024-12-21

皆さんこんにちは! ソーシャル経済メディア「NewsPicks」プロダクトエンジニアの森田( @moritama7431 )です:)
この記事は NewsPicks アドベントカレンダー 2024 の21日目の記事です。
昨日は小林さんによる『Netflixの推薦＆検索システム最前線 - QCon San Francisco 2024現地レポート』でした！

本日の記事は、「本番プロダクト上で機械学習の成果をスケールさせるために、推薦システムのオフライン評価を諦めずに何とかしたいんだ！」という内容の記事になります。昨日に引き続き、二日連続で推薦システム関連の記事で嬉しいですね:)

ちなみに上図のような結果が出るような実験をしました!

TL;DR

推薦システムのオフライン評価と学習の精度を向上させるには、確率的かつ探索的なデータ収集方策が有効であることを合成データによる実験で確認した。
決定的方策や探索的でない確率的方策では、ログデータ数を増やしても精度は改善しない。
データ収集方策と評価方策が大きく異なる場合でも、データ収集方策が探索的であればオフライン評価 & 学習の精度改善が確認できた。
探索の頻度が小さめのデータ収集方策でもオフライン評価 & 学習の精度改善が確認できた。
データ収集方策が確率的かつ探索的であることは、推薦システムの継続的改善やMLOpsの成功において非常に重要なtipsかも。

はじめに: 本記事を書くことの意味付け

オフライン評価&学習ってMLOpsにおいて非常に重要では??

さて前述の通り、我々は「推薦システムのオフライン評価が難しいから一旦諦めて、A/Bテストに全振りする」という判断をしたわけですが、もしオフライン評価を適切に行えるのであればそれはめちゃめちゃ嬉しいわけです。つまり本当は諦めたくないんです。

例えばオフライン評価が確度高くできる場合、次のようなメリットがありそうです。

仮説検証の高速化: A/Bテストなどのオンライン評価の前に有効そうな推薦方策を絞り込む事ができ、仮説検証をより高速に回す事ができる。
失敗リスクを減らす: ユーザ体験やビジネス指標を悪化させ得る推薦方策を、オンライン環境に出す前に検知して回避することができる。

そして、オフライン評価の精度は、MLOpsにおける「継続的な訓練（Continuous Training）」の成功とも大きく関連するのではとも思っています。
「MLOps」とは「機械学習の成果をスケールさせるための様々な取り組み」と定義されています。
また「継続的な訓練(Continuous Training)」は、「自動的かつ継続的にモデルの更新、デプロイを行う取り組み」であり、本番運用中のモデルの性能の劣化を防ぎ、MLシステムを継続的に改善していくための重要な要素です。（共に書籍「事例でわかるMLOps 機械学習の成果をスケールさせる処方箋」より引用）
また同書籍の著者の方の発表資料では、「継続的な訓練」はDevOpsの原則の一つである「継続的な改善(Continuous Improvement)」のMLOpsにおける実装である、とも解釈されていました。それらを踏まえてもMLOpsにおける「継続的な訓練」は、ただ学習を自動化するということではなく、機械学習サービスの価値を継続的に向上させるために非常に重要な要素であると言えそうです
そして、もしオフライン評価で推薦方策の良し悪しを正しく評価できない場合、オフライン学習も難しくなるはずです。したがって「継続的な訓練」によってモデルの更新を行なったとしても、適切ではない方向へ方策を学習・最適化されてしまい「継続的な改善」を果たせない可能性がありそうです。
以上を踏まえると、オフライン評価(&オフライン学習)という技術は、MLOpsにおける「継続的な訓練」を正しく機能させるため、さらに言えば機械学習の成果をスケールさせるために非常に重要な技術なのでは、と私は思い始めているわけです...!

ということで、プロダクト上で機械学習の成果をスケールさせるために「オフライン評価を諦めずに何とかしたいんだ！」というモチベーションで、本記事を書くことにしました。

本記事で書きたいこと

さて前述の経緯でオフライン評価のアプローチを調べていると、推薦方策のオフライン評価・学習を成功させるためには、どうやら決定的方策ではなく確率的方策を導入することが有効っぽいぞ...!という考えに至りました。

ちなみに「決定的方策」と「確率的方策」の定義について簡単に整理してみると、以下のような感じです:

決定的(deterministic)な方策
- ある行動を確率1で選択する方策。
- ex.) ユーザ1に対して、ニュースAを確率1で推薦する。
確率的(stochastic)な方策
- 行動をある確率でランダムに選択する方策。
- ex.) ユーザ1に対して、ニュースAを確率0.5、ニュースBを確率0.3、ニュースCを確率0.2で推薦する。

というわけで本記事の目的は、「推薦方策のオフライン評価・学習を成功させるために、確率的方策を導入すべきなのか??」という問いに対して考えを深めることです。
そのために、まずは前半パートで、理論面での理解をまとめます。続いて後半パートで、Open Bandit Pipelineパッケージを用いた合成データによる実験を通して「どのようなデータ収集方策を使うと、新しい方策のオフライン評価 & 学習が成功しやすいのか？」を検証してみたいと思います。

前半パート: 理論面での理解をまとめる

オフライン評価が難しい理由は、推薦システムが予測(or分類)タスクではないから

まずそもそもなぜ推薦システムのオフライン評価が難しいのか、その理由をざっくり整理してみます。
「機械学習」というと予測や分類タスクをイメージしやすいですが、推薦システムは予測タスクではなく、意思決定の最適化タスクであると言えます。
例えば、ニュース推薦の場合、何らかの方策によって(ユーザ, 記事) ペアの関連度や嗜好度などのスコアを予測することが多いですが、最終的にはユーザにどんな記事を推薦するかの意思決定を行います。
書籍「反実仮想機械学習」にも以下のように記載されています。

予測というよりもむしろデータに基づいた意思決定の最適化問題
(書籍「反実仮想機械学習」より引用)

この意思決定の最適化タスクでは、複数の行動の選択肢の中から、我々が最大化(最小化)したいなんらかの指標が改善することを目指してr、一つの行動を選択します。この場合、選択された行動に対する結果は観測されるのですが、選択されなかった行動に対する結果は観測されません。
このような、起こる可能性があったが実際には起こらなかった状況、すなわち反実仮想的な状況が存在することが、推薦システムのオフライン評価が難しい理由だと言えます。

ちなみに意思決定の最適化タスクでは、データに基づいて導かれる意思決定の規則を**意思決定方策(decision-making policy)**と呼ぶようです。
ただ今回は特に推薦システムの話をしているので、本記事内では、意思決定方策ではなく推薦方策という用語を使用しています

オフライン評価がやっていることを定式化してみる

さて、上で推薦システムの問題を定式化してみましたが、続いてオフライン評価のタスクを数式で表現していきます。

オフライン評価がやっていることは、ある推薦方策を本番稼働させて収集されたログデータを使って、別の新しい推薦方策の性能を推定することです。
ここで、オフライン評価の分野では、前者の推薦方策を「データ収集方策(logging policy, behavior policy)」、後者の推薦方策を「評価方策(target policy)」と呼びます。

ある任意の推薦方策 $\pi$ を本番稼働させて得られたログデータを $D_{\pi} = {(x_i, a_i, r_i)}_{i=1}^{n}$ と表記すると、オフライン評価のタスクは以下のように定式化できます。

オフライン評価のタスクは、データ収集方策 $\pi$ によって得られたログデータ $D_{\pi}$ を使って、評価方策 $\pi_{new}$ の性能 $V(\pi_{new})$ を推定することである

naiveな推定方法では、データ収集方策と評価方策の違いによるバイアスが生まれる

さて、オフライン評価のタスクを定式化できたので、最もシンプルなオフライン評価方法である
「naive推定量」について考えてみます。
naive推定量の考え方は、「データ収集方策と評価方策が同じ意思決定をした時のログデータのみを使って、評価方策の性能を推定しよう！」というものです。
数式で表すと以下のようになります。

\hat{V}_{naive}(\pi_{new};D_{\pi}) = \frac{1}{\sum_{i=1}^{n} \mathbb{I}[\pi_{new}(a_i|x_i) = 1.0]} \sum_{i=1}^{n} \mathbb{I}[\pi_{new}(a_i|x_i) = 1.0] r_i

ここで、$\mathbb{I}[hoge]$ は、中の条件式がTrueの場合に1、Falseの場合に0を返す関数です(一般的に指示関数、indicator functionと言うようです...!)。
なので、$\mathbb{I}[\pi(a_i|x_i) = 1.0]$ は、$i$ 番目のログデータにおいて、評価方策 $\pi_{new}$ がコンテキスト $x_i$ に対してデータ収集方策 $\pi$ と同じ行動 $a_i$ を選択する場合に1、選択しない場合に0を返す関数です。
（ちなみに注意点として、上の式は評価方策が決定的方策であることを前提とした定義になっています。評価方策が確率的方策な場合のnaive推定量の式がパッとわからず...!!）

具体例として、例えばデータ収集方策によって以下のようなログデータが得られた場合を考えてみます。

ログデータidx	コンテキスト	行動(推薦したニュース)	報酬
0	[年齢30歳, エンジニア, ...]	記事A	1
1	[年齢20歳, 学生, ...]	記事B	0
2	[年齢40歳, 経営者, ...]	記事C	1
3	[年齢50歳, 医師, ...]	記事A	0
4	[年齢60歳, 自営業, ...]	記事D	1

このログデータに対して、評価方策 $\pi_{new}$ のnaive推定量を計算する場合、まず「与えられた各コンテキストに対して、評価方策だったらどの行動を選択するか？」の情報を追加します。

ログデータidx	コンテキスト	行動(推薦したニュース)	報酬	評価方策が選ぶ行動
0	[年齢30歳, エンジニア, ...]	記事A	1	記事A
1	[年齢20歳, 学生, ...]	記事B	0	記事A
2	[年齢40歳, 経営者, ...]	記事C	1	記事B
3	[年齢50歳, 医師, ...]	記事A	0	記事C
4	[年齢60歳, 自営業, ...]	記事D	1	記事D

この場合の評価方策 $\pi_{new}$ のnaive推定量は以下のように計算されます。

\hat{V}_{naive}(\pi;D_{\pi_0}) = \frac{1}{(1 + 0 + 0 + 0 + 1)} \times (1 \times 1 + 0 \times 0 + 0 \times 1 + 0 \times 0 + 1 \times 1) = 1.0

データ収集方策と評価方策が同じ行動を選択したのはログデータidx=0とidx=4のみで、その行動に対する報酬の平均値を取ることで、評価方策の性能 $V(\pi_{new})$ のnaive推定量を計算しています。

ただ、このnaive推定量が真の性能を確からしく推定できるかというと、必ずしもそうではありません。このnaive推定量が真の性能に対してバイアスなく推定できるのは、データ収集方策と評価方策が完全に一致してる場合と、データ収集方策が一様ランダムに行動を選択している場合のみです。その他の場合では、データ収集方策が選択しやすかった行動の価値を過大に見積もってしまうようなバイアスが発生することが知られています。

データ収集方策と評価方策が違っていてもなんとかする王道アプローチ! IPS推定量

naive推定量では、データ収集方策と評価方策が異なるほど大きなバイアスを持ってしまう。
ということで、このバイアスを打ち消す最も基本的な戦略が、以下のIPS(Inverse Propensity Score)推定量になります。

\hat{V}_{IPS}(\pi_{new};D_{\pi}) = \frac{1}{n} \sum_{i=1}^{n} \frac{\pi_{new}(a_i|x_i)}{\pi(a_i|x_i)} r_i = \frac{1}{n} \sum_{i=1}^{n} w(x_i, a_i) r_i

なお、$w(x_i, a_i) := \frac{\pi_1(a_i|x_i)}{\pi_0(a_i|x_i)}$ を**重要度重み(importance weight)**と呼び、評価方策 $\pi_{new}$ とデータ収集方策 $\pi$ の行動選択確率の比を表しています。

書籍「反実仮想機械学習」を読んでいてもOPE推定量の多くがIPS推定量の拡張ver.っぽく、最も基本的なオフライン評価の戦略の1つと言ってもよさそうです...!

具体例として、例えばデータ収集方策によって以下のようなログデータが得られた場合を考えてみます。

ログデータidx	コンテキスト	行動(推薦したニュース)	報酬
0	[年齢30歳, エンジニア, ...]	記事A	1
1	[年齢20歳, 学生, ...]	記事B	0
2	[年齢40歳, 経営者, ...]	記事C	1
3	[年齢50歳, 医師, ...]	記事A	0
4	[年齢60歳, 自営業, ...]	記事D	1

IPS推定量を計算するためには、まず各ログデータにおけるデータ収集方策と評価方策の行動選択確率 ($\pi(a_i|x_i)$ と $\pi_{new}(a_i|x_i)$) が必要ですね。
それにより、重要度重み $w(x_i, a_i)$ を計算ができます。

ログデータidx	コンテキスト	行動(推薦したニュース)	報酬	データ収集方策の行動選択確率	評価方策の行動選択確率	重要度重み
0	[年齢30歳, エンジニア, ...]	記事A	1	0.6	0.3	0.5
1	[年齢20歳, 学生, ...]	記事B	0	0.3	0.6	2.0
2	[年齢40歳, 経営者, ...]	記事C	1	0.6	0.4	0.67
3	[年齢50歳, 医師, ...]	記事A	0	0.4	0.6	1.5
4	[年齢60歳, 自営業, ...]	記事D	1	0.2	0.5	2.5

この場合のIPS推定量は以下のように計算されます。

\hat{V}_{IPS}(\pi_{new};D_{\pi_0}) = \frac{1}{5} \times (0.5 \times 1 + 2.0 \times 0 + 0.67 \times 1 + 1.5 \times 0 + 2.5 \times 1) = 0.734

まあこの数値が適切かはさておき、IPS推定量の場合はこのような計算方法になる、ということだけ認識できれば十分です...!
(何せログデータ数が5件なので、いくらIPS推定量が不偏だとしてもバリアンスが高くなるはず)

データ収集方策が確率的方策の方が良さそうな理由

そしてIPS推定量は、以下の共通サポート仮定を満たす場合に真の性能に対して不偏性を持つことが知られています。

\pi_{new}(a|x) > 0 -> \pi(a|x) > 0, \forall a \in A, \forall x \in X

つまり、「評価方策 $\pi_{new}$ がコンテキスト $x$ に対してサポートする(=選択する可能性がある)全ての行動 $a$ を、データ収集方策 $\pi$ もサポートしていてくれ!」という仮定です。

そうです、ここで本記事のタイトルにもある「データ収集方策は確率的方策の方が都合が良いのか??」という話になってくるわけです。
データ収集方策と評価方策がそれぞれ決定的方策/確率的方策であるケースを考えてみます。以下の4通りの組み合わせが考えられます。
（ここでの確率的方策は、すべての推薦候補ニュースを選択する確率が0より大きいという想定です）

1. データ収集方策 = 決定的方策、評価方策 = 決定的方策の場合
- → 共通サポート過程を満たせなさそう。唯一満たせるのは、$\pi = \pi_{new}$ の場合のみなので。
1. データ収集方策 = 決定的方策、評価方策 = 確率的方策の場合
- → 共通サポート過程を満たせなさそう。
1. データ収集方策 = 確率的方策、評価方策 = 決定的方策の場合
- → 共通サポート過程を満たせる!
1. データ収集方策 = 確率的方策、評価方策 = 確率的方策の場合
- → 共通サポート過程を満たせる!

これを踏まえると、データ収集方策が決定的方策の場合、共通サポート仮定をほぼ絶対満たせないじゃん！と思うわけです。
逆に言えば、評価方策がなんだろうと、データ収集方策が確率的方策でさえあれば共通サポート仮定を満たすことができ、IPS推定量によって少なくともバイアスのないオフライン評価が可能になるのではないでしょうか。

抽象的な表現ですが方策の探索の度合いが「データ収集方策 ≧ 評価方策」であれば、共通サポート仮定を満たしやすく、IPS推定量（あるいはその拡張ver.たち）を使ってオフライン評価 & 学習しやすいという認識です...!
（ちなみに、共通サポート仮定を満たしてIPS推定量が真の性能に対して不偏になっただけで、オフライン評価難しい問題が全て解決するとは限りません! バイアスを除去できたとしてもバリアンスの懸念があるからです。特に推薦タスクにおいて推薦アイテム候補の数が多かったり、推薦アイテムリストの長さが長かったりすると、方策が取りうる行動の選択肢が爆発的に増え、今度はIPS推定量のバリアンスが大きくなる問題に直面していくようです）

後半パート: 実験で「データ収集方策は本当に確率的方策の方が都合良いのか??」を検証してみる

さて前半パートにて、自分が事前にオフライン評価周りを調べて「データ収集方策は確率的方策の方が都合が良さそう」という認識を持った経緯をまとめました。
後半パートでは実際にOpen Bandit Pipelineを使って、「データ収集方策が確率的方策の方が都合が良いのか??」を検証してみたいと思います...!

Open Bandit Pipelineパッケージを少し紹介

Open Bandit Pipeline (OBP) は、意思決定の最適化タスクにおけるオフライン評価やオフライン学習を簡単に実験できるPythonパッケージです。
と言いつつ自分も今回初めて使ってみたので詳しくはないのですが、さまざまなオフライン評価 & 学習手法が実装されており非常に便利だなと感じました!
より詳細はこちらのZOZOさんのブログ記事などで丁寧に解説されております。

今回のシミュレーションでは、このOBPパッケージを活用して、推薦システムにおけるデータ収集方策とその影響を分析します。

まず実験の問題設定を考える

今回の実験では、架空のプッシュ通知ニュースの推薦システムを想定しました。この推薦システムの目標は、ユーザごとに4種類の候補ニュースから一つを選んで配信し、通知の開封率を最大化することです。ユーザとニュースごとに以下のような情報が与えられています。

ユーザごとに異なる コンテキスト（例: 年齢、職種、過去の閲覧履歴）。
- 実験では、3次元のコンテキストベクトル $x \in \mathbb{R}^3$ をランダムに生成。
ニュースごとに異なる アイテムコンテキスト（例: 所属カテゴリ、紐づけられたタグ）。
- 実験では、3次元のアイテムコンテキストベクトル $e \in \mathbb{R}^3$ をランダムに生成。

また、プッシュ通知を開封するかどうかを示す 報酬 $r$ をバイナリ変数（1: 開封、0: 未開封）で表します。

各方策 $\pi$ の真の性能 $V(\pi)$ は、その方策を稼働させた場合の開封率の期待値として定義されます。
今回はシミュレーションの都合上、ニュースごとの報酬の期待値は以下のように固定しています。

ニュース $a_0$: 開封率の期待値 $0.4$
- (数式で表すと、$E_{p(r|a=a_0, x)}[r] = E_{p(r|a=a_0)}[r] = 0.4$)
ニュース $a_1$: 開封率の期待値 $0.3$
- (数式で表すと、$E_{p(r|a=a_1, x)}[r] = E_{p(r|a=a_1)}[r] = 0.3$)
ニュース $a_2$: 開封率の期待値 $0.2$
- (数式で表すと、$E_{p(r|a=a_2, x)}[r] = E_{p(r|a=a_2)}[r] = 0.2$)
ニュース $a_3$: 開封率の期待値 $0.1$
- (数式で表すと、$E_{p(r|a=a_3, x)}[r] = E_{p(r|a=a_3)}[r] = 0.1$)

これにより、実環境では知り得ないはずの各方策の真の性能 $V(\pi)$ を直接計算することができます。
（ちなみに、繰り返しになりますが、実環境では各行動 & 各コンテキストで条件付けた報酬の期待値 $E_{p(r|a, x)}[r]$ は一般的に未知なので、各方策の真の性能 $V(\pi)$ も知ることはできません。それゆえにオンライン評価やオフライン評価で推定するわけです）

ちなみに、Open Bandit PipelineパッケージのSyntheticBanditDatasetを元に上記の設定を入力して、合成データを作成しています。

dataset = SyntheticBanditDataset(
        n_actions=4,
        dim_context=3,
        action_context=np.random.random((n_actions, dim_context)),
        reward_type="binary",
        reward_function="E_{p(r|a, x)}[r]を返す関数",
        behavior_policy_function=データ収集方策の振る舞いを定義した関数,
    )
# 設定に基づいて合成データを生成
bandit_feedback = dataset.obtain_batch_bandit_feedback(n_rounds=10000)

実験1: データ収集方策の選択がオフライン評価に与える影響

この実験で検証したい質問は、「どのようなデータ収集方策を使うと、新しい方策の性能をより確度高く推定できるのか??」です。
この実験では、以下の5種類のデータ収集方策を使用しました。それぞれの方策が異なる意思決定の特徴を持っています。

1つ目 $\pi_1$: パーソナライズなしの決定的方策
- 全てのユーザに対し、ニュース $a_3$ を確率1.0で推薦。
2つ目 $\pi_2$: パーソナライズなしの確率的方策。ただし探索的でない。
- 全てのユーザに対し、ニュース $a_2$ を確率0.5、ニュース $a_3$ を確率0.5で推薦。確率的方策だが、全ての候補ニュースを推薦するわけではない。
3つ目 $\pi_3$: パーソナライズなしの確率的かつ探索的な方策。
- 全てのユーザに対し、ニュース $a_0$ を確率0.025、ニュース $a_1$ を確率0.025、ニュース $a_2$ を確率0.025、ニュース $a_3$ を確率0.925で推薦する確率的方策。
- （言い換えると、コンテキスト考慮なしでepsilon=0.1のepsilon-greedy方策）
4つ目 $\pi_4$: パーソナライズありの決定的方策
- ユーザとニュースのコンテキストを考慮し、コンテキストベクトル $x$ とアイテムコンテキストベクトル $e$ の内積が最大となるニュースを確率1.0で推薦。
5つ目 $\pi_5$: パーソナライズありの確率的かつ探索的な方策。
- ユーザとニュースのコンテキストを考慮し、コンテキストベクトル $x$ とアイテムコンテキストベクトル $e$ の内積が最も大きいニュースを確率0.925で推薦し、それ以外のニュースを確率0.025で推薦する確率的方策。
- （言い換えると、コンテキスト考慮ありでepsilon=0.1のepsilon-greedy方策）

これらのデータ収集方策を用いてログデータを収集し、新しい方策 $\pi_6$ を評価します。なお、$\pi_6$ は 「コンテキストベクトル $x$ とアイテムコンテキストベクトル $e$ の内積が最小のニュースを確率1.0で推薦する」方策 であり、$\pi_4$ や $\pi_5$ とは真逆の意思決定を行うような方策です。

なお、評価方策の性能のオフライン評価時にはIPS推定量を使用します（OPEの分野で最も王道なアプローチ、という印象です...!)

実験結果と気付き

図1は、各データ収集方策によって収集されたログデータを使って、新方策 $\pi_6$ の性能をオフライン評価した結果です。ここで、横軸は評価に使用するログデータ数、縦軸は新方策$\pi_6$の真の性能とオフライン評価による推定値の誤差を表しています。

図1: データ収集方策ごと、データ数ごとのオフライン評価の精度の推移

(すいません! $\pi_1$ をデータ収集方策とした場合の結果が抜け落ちてますね! 後で修正しておきます! ちなみに予想がつくと思いますが、コンテキスト考慮なし且つ決定的なデータ収集方策なので、当然、オフライン評価の精度は上がらない結果になります...!)

図1を見ると、以下の結果が得られます。

$\pi_3$ や $\pi_5$ のような確率的方策で収集したログデータを使用すると、ログデータ数を増やすにつれて、新しい方策 $pi_6$ のオフライン評価による推定誤差が0に収束していく。
一方で、$\pi_1$ や $\pi_4$ のような決定的方策、また $\pi_2$ のような確率的方策ではあるが全てのニュースが選ばれうるわけではない方策で収集したログデータを使用すると、ログデータ数を増やしても、推定誤差は0にならず、$pi_6$ の性能を過小に評価し続けた。

この実験結果から得られた気づきは以下の4つです。

パーソナライズ有無によらず、データ収集方策が確率的かつ探索的（i.e. 全ての候補が選ばれる確率がそれぞれ0より大きい）であることが、オフライン評価の精度向上に重要である。
決定的方策、あるいは確率的方策であっても探索的でない場合は、ログデータ数を増やしてもオフライン評価の精度は向上しない。
探索度合いが小さい場合でも (ex. 実験では $\epsilon = 0.1$ のepsilon-greedy戦略。つまり10回中9回は決定的に意思決定する方策) 、ログデータ数が増えるほど、オフライン評価の精度が向上し誤差が0に近づいていく。
評価したい方策がデータ収集方策と大きく異なる意思決定をする場合でも、データ収集方策が確率的かつ探索的であれば、精度の高いオフライン評価が可能である。

実験2: データ収集方策の選択がオフライン学習に与える影響

続いて、オフライン学習の実験を行います。
この実験で検証したい質問は、「どのようなデータ収集方策を使うと、新しい方策をより良く学習させられるのか??」です。
実験には、オフライン評価の実験と同様の、以下の5種類のデータ収集方策を使用しました。
（再掲なので概要のみ記載しています）

1つ目 $\pi_1$: パーソナライズなしの決定的方策
2つ目 $\pi_2$: パーソナライズなしの確率的方策。ただし探索的でない。
3つ目 $\pi_3$: パーソナライズなしの確率的かつ探索的な方策。
4つ目 $\pi_4$: パーソナライズありの決定的方策
5つ目 $\pi_5$: パーソナライズありの確率的かつ探索的な方策。

新モデルの学習にはscikit-learnのLogisticRegression を用い、収集データをIPW（Inverse Probability Weighting）で重み付けした目的関数（ざっくりIPS推定量の目的関数ver...!!）を使用しています。
ちなみに、open bandit pipelineパッケージを使うと以下のような雰囲気で実装できます。

from sklearn.linear_model import LogisticRegression
from obp.policy import IPWLearner

new_policy = IPWLearner(
        n_actions=4,
        base_classifier=LogisticRegression(),
    )
new_policy.fit(
    context=bandit_feedback_train["context"],
    action=bandit_feedback_train["action"],
    reward=bandit_feedback_train["reward"],
    pscore=bandit_feedback_train["pscore"],
)

実験結果と気付き

図2は、各データ収集方策によって収集されたログデータを使って、全く新しい方策をゼロからオフライン学習し、その真の性能の推移を描画したものです。
横軸は学習に使用するログデータ数、縦軸はオフライン学習後の新方策の真の性能を表しています。

図2: データ収集方策ごと、データ数ごとのオフライン学習した新モデルの真の性能の推移
(なお、$\pi_1$ をデータ収集方策とした場合の結果は、scikit-learnのLogisticRegressionクラスにfitさせる際にログデータ内の行動が1種類しかないことでエラーになって計算できなかったため、除外しています)

図2を見ると、以下の結果が得られます。

$\pi_3$ や $\pi_5$ のような確率的方策で収集したログデータを使用すると、学習に使うログデータ数が増えるにつれて、新方策の真の性能が上限値0.4に近づくように学習が進む。すなわち、本設定における最適な方策（全ユーザにニュース $a_0$ を選択する方策）に辿り着く。
一方で、$\pi_1$ や $\pi_4$ のような決定的方策、また $\pi_2$ のような確率的方策ではあるが全てのニュースが選ばれうるわけではない方策で収集したログデータを使用すると、学習に使うログデータ数が増えても、新方策の真の性能が上限値0.4に収束しない。すなわち、本設定における最適な方策に辿り着けなかった。

この実験結果から得られた気づきは以下の通りです。

オフライン評価と同様に、パーソナライズ有無によらず、データ収集方策が確率的かつ探索的（i.e. 全ての候補が選ばれる確率が0ではない）であることが、オフライン学習で方策を最適化するために重要。
決定的方策、あるいは確率的方策でも探索的でない (i.e. 全ての候補が選ばれない) 場合は、オフライン学習で最良のモデルまで辿り着けない。
探索的な度合いが小さくepsilon = 0.1 (i.e. 10回中9回は決定的な意思決定!) でも、オフライン学習で最良のモデルまで辿り着ける。

オフライン評価の実験の気づきとほぼ同じになりました! まあオフライン学習って、まず方策の良し悪しを正しくオフライン評価できた上で、より良くなる方向にパラメータ更新していくイメージなので、似た結論になって当然と言えば当然な気もしますね...!

おわりに

本記事では、推薦システムのオフライン評価と学習を成功させるため（ひいてはプロダクト上で機械学習システムの成果をスケールさせるため）の鍵として「確率的かつ探索的なデータ収集方策」の重要性について、理論的背景と実験結果を基にまとめました。

実験から得られた結論としては以下のとおりです。

決定的方策や探索的でない確率的方策では、ログデータ数を増やしても精度は改善しない。
データ収集方策と評価方策が大きく異なる場合でも、データ収集方策が探索的であればオフライン評価 & 学習の精度改善が期待できる。
探索の頻度が小さめのデータ収集方策でもオフライン評価 & 学習の精度改善が期待できる。
データ収集方策が確率的かつ探索的であることは、推薦システムの継続的改善やMLOpsの成功において非常に重要なtipsなのでは...!

最後までお読みいただき、ありがとうございました...!
もし何か気になる点などあれば、ぜひカジュアルにコメントいただけると嬉しいです..!:good:

今回の記事がおもしろいと思ったら NewsPicks アドベントカレンダーの他の記事もぜひ見てみてください!
明日は @sefwgweo さんが書いてくれます。お楽しみに！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

推薦システムのオフライン評価&学習を諦めない! 確率的なデータ収集方策の有効性を実験してみる

TL;DR

はじめに: 本記事を書くことの意味付け

推薦システムのオフライン評価が難しい

オフライン評価&学習ってMLOpsにおいて非常に重要では??

本記事で書きたいこと

前半パート: 理論面での理解をまとめる

オフライン評価が難しい理由は、推薦システムが予測(or分類)タスクではないから

推薦システムの問題を定式化しておく

オフライン評価がやっていることを定式化してみる

naiveな推定方法では、データ収集方策と評価方策の違いによるバイアスが生まれる

データ収集方策と評価方策が違っていてもなんとかする王道アプローチ! IPS推定量

データ収集方策が確率的方策の方が良さそうな理由

後半パート: 実験で「データ収集方策は本当に確率的方策の方が都合良いのか??」を検証してみる

Open Bandit Pipelineパッケージを少し紹介

まず実験の問題設定を考える

実験1: データ収集方策の選択がオフライン評価に与える影響

実験結果と気付き

実験2: データ収集方策の選択がオフライン学習に与える影響

実験結果と気付き

おわりに