仕事で始める機械学習をまとめた

第一部（1章~8章）では機械学習プロジェクトをどのような流れで進めるかについて整理してある。さらに、機械学習の初歩のおさらいと、機械学習を含むコンピューターシステム特有の難しさについて説明してある。
第二部（9章~11章）では、実施された（される可能性のある）プロジェクトをベースに、具体的な手法や考え方をトレースすることで、機械学習を使ったプロジェクトの進め方の解像度を深めることができる

本書では以下の流れで説明されている。

1章　機械学習プロジェクトの始め方
2章　機械学習で何ができる？
3章　学習結果を評価するには
4章　システムに機械学習を組み込む
- 4.1 システム設計
- 4.2 教師データを取得するためのログ設計
  - 4.2.1 特徴量や教師データに使いうる情報
  - [4.2.2 ログを保持する場所)
- 4.3 この章のまとめ
5章　学習のためのリソースを収集する
6章　継続的トレーニングをするための機械学習基盤
7章効果検証：機械学習に基づいた施策の成果を判断する
8章機械学習モデルを解釈する
- 8.1 線形回帰の係数から原因を読み解く
- [8.2 ランダムフォレストのFeature Importanceの可視化](#82-ランダムフォレストのFeature Importanceの可視化)
- 8.3 SHAPによる寄与の可視化
- 8.4 この章のまとめ
[10章 Uplift Modelingによるマーケティング資源の効率化](#10-Uplift Modelingによるマーケティング資源の効率化)
- [10.1 Uplift Modelingの概要](#101-Uplift Modelingの概要)
- [10.2 Uplift Modelingのスコアと評価方法](#102-Uplift Modelingのスコアと評価方法)
- [10.3 Uplift Modelingを本番投入するには](#103-Uplift Modelingを本番投入するには)
11章バンディッドアルゴリズムによる強化学習入門

1 機械学習プロジェクトの始め方

1.1 機械学習プロジェクトの流れ

実際の機械学習を含めたプロジェクトを開始する際は以下の流れに沿って実施する

ビジネス課題を機械学習の課題に定式化する
類似の課題を論文を中心にサーベイする
機械学習をしないで良い方法を考える
システム設計（要件）を考える
特徴量、教師データとログの設計をする
実データの収集と前処理をする
探索的データ分析とアルゴリズムを選定する
学習、パラメータをチューニングする
システムに組み込む
予測精度、ビジネス指標をモニタリングする

「解きたい課題を機械学習で解ける問題設定に落とし込む」（1~3）、「解くための道具選びと前処理」（4~6）、「モデルの作成」（7~8）、「サービスへの組み込み」（9~10）と整理できる。
データサイエンティストとして、引き出しを増やすために、「機械学習を使って課題を解決した」という話を見たら、「どのようなアルゴリズムを使って、どのようなデータ（特徴量）を使って、機械学習部分を全体のプロセスにどのように取り組んでいるか」を意識すると良い

1.1.1 ビジネス課題を機械学習の課題に定式化する

要求定義をしっかりすることが大切

As Is To Beなどを用いて表面的な課題を深掘り、機械学習を使って解決する課題を導きだす
KPIまで設定するようにする

1.2.2 類似の課題を論文を中心にサーベイする

この分野では産業界から論文を出版するケースも多いため、論文はビジネス課題の解消を目的とした場合であっても、有益なソースとなりうる

1.1.3 機械学習をしないで良い方法を考える

機械学習には以下の問題点がある

定期的なメンテナンスが必要（入力・出力対象のトレンドの変化）
乱数を用いた確率的な処理であるため、予期しない挙動が発生する場合がある

機械学習の利用に適したビジネス課題の特徴

大量のデータに対して、高速に安定した判断を求める必要がある（人間のように疲れて判断が鈍ることはなく、一定の判断基準を担保できる）
予測結果には、一定の間違いが含まれることが許容できる（予測の精度が100%になることはまずあり得ない）

まずは、MVP（Minimum Viable Product：最低限実行可能なもの）を作る

簡単なルールベースを使ったレコメンドや既存モジュールの機能を組み合わせたもの
MVPを作ることで、自分が立てた仮説の筋の良し悪しを判断できる
MVPで十分に要求を満たせたといった場合も多い
最初の課題設定まで手戻りする可能性もある（機械学習プロジェクトは通常の開発案件より、手戻りが多いと理解しておく）

1.1.4 システム設計（要件）を考える

設計の上で重要なポイントは2つある。

予測結果をどういう形で利用するのか
予測誤りをどこで吸収するのか

予測結果をユーザーやクライアントに提供するシステム要件を設計する。
予測が100％当たることはないので、どのようにリスクを低減するか考える必要がある。人手のチェックを導入するなら、どこでどのように。

また、ここで「2ヶ月で90％の予測性能を達成する」といった、目標性能と撤退ラインを設定しておく。以降のモデル構築作業に入ってしまうと、「あと少し改善できる」と思い、案件の中止に対してサンクコストが発生してしまう可能性が高い。

1.1.5 特徴量、教師データとログの設計をする

古典的な機械学習モデルにおいては、特徴量が肝となるので、ビジネスドメイン知識が豊富な人と話し合うなどして、予測に必要な特徴量を取得するようにする。
しかし、深層学習ではどの特徴量を使うかよりも、どういったネットワーク構造を使うかの方が重要。近年では、深層学習を使ったEmbeddingを利用して複雑な特徴量を作り、それを古典的な機械学習アルゴリズムに用いる手法もとられている。
正解データとして、Webアプリケーションのログを使用することもあるので、その際はログの設計が必要。

1.1.6 実データの収集と前処理をする

データの正規化や欠損値の処理などの前処理は、「データ分析の8割は前処理」と呼ばれるほど重要で時間のかかる作業である。いくら優れたアルゴリズムを使っても、データを適切に整形・加工することに優るものはない。

1.1.7 探索的データ分析とアルゴリズムを選定する

特徴量の重要度や散布図を確認し、先行事例からアルゴリズムを選定する。

1.1.8 学習, パラメータをチューニングする

人工的に作成した正解データやルールベースなどを用いたベースラインモデルを作成し、それを超えるようにパラメータをチューニングする。予測性能が99%のような場合は、過学習やデータリークなど何かしらの問題がある可能性が極めて高いので注意する。

1.1.9 システムに組み込む&予測精度、ビジネス指標をモニタリングする

システムに組み込む際、一緒に予測性能とそれに伴うビジネスインパクト（KPI）のモニタリング設計も実施する。プロジェクトの目的は、性能の良い予測モデルを作ることではなく、その先にあるビジネスインパクトを達成すること。そのため、KPIの推移をモニタリングし、モデルが当初の目的を達成できているかモニタリングする必要がある。また、予測モデルの性能は時間と共に悪くなっていくので、アラートを飛ばすなど適切なダッシュボードを作成し、必要な時は5~7に立ち戻ってモデル改善に取り組むなどの仕組みづくりも大切である。

1.2 実システムにおける機械学習の問題点への対処方法

1.1で記載していない問題点と対処方法に関して記述する。

予測モデルをモジュール化してアルゴリズムのA/Bテストができるようにする
- モデル性能が落ちた際に、旧モデルと新モデルを比較する必要などが出てくる
- リリースに際しては部分的にリリースをするカナリアリリースがよく使われる
モデルのバージョン管理をして、いつでも切り戻し可能にする
- 予測性能が劣化した際に、モデルが原因であるか切り分けて考えるためにも、過去モデルと利用したデータはバージョニングしておく
データ処理のパイプラインごとに保存する
- 前処理から予測モデルの構築まで含めたパイプライン全体を保存することが重要とされている
- これにより、「学習フェーズに行なっていた前処理を予測フェーズでは実施してなかった」といったミスが避けられる

1.3 機械学習を含めたシステムを成功させるためには

機械学習を含めたプロジェクトでは、何ヶ月もかけたが意味のあるアウトプットが得られないといったギャンブル的な要素がある。機械学習を含めたプロジェクトをビジネスとして成功させるには、以下の４つの役割を持った人を確保することが重要だと筆者は考えている。

プロダクトに関するドメイン知識を持った人
- 解くべき課題の決定やプロダクトのどこに機械学習を使うかを決定する
統計や機械学習に明るい人
- 実装と問題設定をするために他メンバーとのコミュニケーションも求められる
データや分析基盤を作れるエンジニアリング能力のある人
失敗しても構わないとリスクをとってくれる責任者

1.4 １章のまとめ

解くべき問題の仮説を立て、MVPを作りコンセプトの検証を最優先する
機械学習をしないことを恐れない
機械学習に適している問題設定かを見極める
予測性能とKPIの両方をモニタリングし、継続してモデル改善を続ける

2 機械学習で何ができる？

2.1 どのアルゴリズムを選ぶべきか

基本（分類・回帰・クラスタリング・次元削減）
応用（推薦・異常検知・頻出パターンマイニング・強化学習）

以降、分類・回帰・クラスタリング・次元削減について具体的な手法のみ軽く触れる。本書を読んでいる目的は、あくまで機械学習を使ったビジネスを成功させる方法であり、機械学習アルゴリズムの学習が目的ではないため。

2.2 分類

教師あり学習で、予測対象はカテゴリなどの離散的な値（クラス）を予測する。

線形モデル系

パーセプトロン
最も基本的なニューラルネットワークの一種。入力の線形結合に閾値を設けて分類を行う。線形分離可能な問題に強い
ロジスティック回帰
線形モデルをベースに、出力をシグモイド関数で0〜1に変換して確率的に分類する。二値分類でよく使われる
ニューラルネットワーク
多層のパーセプトロンを組み合わせたモデル。非線形関数を学習可能で、画像認識や自然言語処理など幅広く利用される

マージン最大化系

SVM（サポートベクターマシン）
クラスを分ける「マージン（境界の余白）」を最大化するように分類する。カーネルを使えば非線形分類も可能

インスタンス学習系

k-NN（k近傍法)
新しいデータに対して、近くのk個のデータを見て多数決でクラスを決める。シンプルだが計算コストが大きくなりやすい

決定木系

決定木
特徴量を分割していくことで分類や回帰を行うアルゴリズム。直感的で解釈しやすい
ランダムフォレスト
複数の決定木をランダムに作り、それらの結果を多数決や平均でまとめるアンサンブル学習。過学習に強く精度が安定しやすい
GBDT（Gradient Boosted Decision Tree）
決定木を逐次的に学習し、誤りを補うように改善していく手法。XGBoostやLightGBMなどの実装が有名で、実務でよく使われる

確率・生成モデル系

ナイーブベイズ
特徴量を「独立」と仮定した上で確率計算を行うシンプルな分類手法。特にテキスト分類（スパム判定など）でよく使われる
HMM（Hidden Markov Model：隠れマルコフモデル）
観測できない「隠れた状態」がマルコフ連鎖に従うと仮定する確率モデル。音声認識や自然言語処理、時系列解析で利用される

2.3 回帰

回帰は連続値の予測（例：売上予測、家賃予測、気温予測など）に使われます。

線形モデル系

線形回帰（Linear Regression）
入力特徴量と目的変数の間に「直線的な関係」があると仮定する最も基本的な回帰手法。シンプルで解釈しやすい
多項式回帰（Polynomial Regression）
線形回帰を多項式に拡張し、曲線的な関係を捉えられるようにしたもの。非線形なデータに有効

正則化付き回帰

Ridge回帰
線形回帰にL2正則化（重みの2乗項）を加えたもの。重みの大きさを抑えて過学習を防ぐ
Lasso回帰
線形回帰にL1正則化（重みの絶対値項）を加えたもの。不要な特徴量の重みをゼロにし、特徴選択の効果もある
Elastic Net
L1正則化（Lasso）とL2正則化（Ridge）の両方を組み合わせた回帰。LassoとRidgeのバランスを調整できる

木ベースの手法

回帰木（Decision Tree Regressor）
データを条件分岐で分割しながら予測値を出す回帰モデル。非線形な関係を捉えるのが得意だが、過学習しやすい

マージン最大化系

SVR（Support Vector Regression）
SVMを回帰に応用した手法。ある「誤差の許容幅（ε）」の中にできるだけ多くのデータを収めるように学習する。非線形回帰も可能

2.4 クラスタリング・次元削減

2.4.1 クラスタリング

教師なし学習の1つで、データの傾向を掴むために用いる。
似ている組み合わせを順番にまとめていく階層的クラスタリングや、距離の近い者同士をk個のグループに分割するk-meansなどがある。

2.4.2 次元削減

できるだけ情報を保った状態で、高次元のデータを低次元のデータに変換すること。主成分分析（PCA）が有名だが、近年はPCAよりも可視化が分かりやすいといった理由でt-SNEも人気である。

2.5 その他

2.5.1 推薦

ユーザーが好みそうなアイテムや閲覧しているアイテムに類似しているアイテムを提示すること。ユーザーの行動履歴やアイテムの閲覧傾向をもとに、似たユーザー同士や似たアイテム同士を利用する。

2.5.2 異常検知

クレジットカードの不正利用やDoS攻撃による不正検知など、以上を検出するためのデータマイニング手法。外れ値検知（Outlier Detection）ともいう。異常のデータは少ないため通常の分類問題として解くと、ほとんどが正常値として扱われるため、専用の手法が使われる。

2.5.3 頻出パターンマイニング

データ中に高頻度で出現するパターンを抽出する手法。俗にいう「ビールと紙おむつがよく買われる」という例え話のように、購買情報から頻出するパターンを抽出する。

2.5.4 強化学習

経験をもとに試行錯誤し、ある目的のためにこの場合こうすれば良いといったような最適な行動の方針を獲得する方法。

2.6 この章のまとめ

機械学習でできることをまとめた。どのアルゴリズムを選ぶかは、機械学習をする上で1つの腕の見せ所。データの傾向を見ながらできるだけ色々なアルゴリズムを試してみることが、遠回りに見えて実は一番の近道。

3章　学習結果を評価するには

本章では、機械学習の結果を評価する方法について解説する。

3.1 分類の評価

スパム分類の例を考えながら、正解率（Accuracy）・適合率（Precision）・再現率（Recall）・F値について考えていく

3.1.1 正解率を使えば良いのか？

$$
\text{正解率} = \frac{\text{正解した数}}{\text{予測した全データ数}}
$$
分類問題では一般にランダムで出力した結果が性能の最低水準と考える（2値分類なら50%、3クラス分類なら33%）ことが多いが、実際にはクラスの偏りがある場合が多く、単純な正解率だけでは評価指標として不十分であることが多い。

3.1.2 データの偏りを考慮する適合率と再現率

適合率は、精度とも呼ばれ、出力した結果がどの程度正解していたのかを表す指標。再現率は、出力した結果が実際の正解全体のうち、どのくらいの割合をカバーしていたかを表す指標。
スパム分類の例で言うと、スパムと予測したメールのうち、本当にスパムだったメールの割合が適合率である。再現率は、全データに含まれるスパムの数のうち、スパムであると予測した正解がいくつ含まれているかの割合である。

適合率と再現率はトレードオフの関係になっており、問題設定によってどちらを重視するかは異なる。見逃しが多くてもより良い正確な予測をしたい場合には、適合率を重視します。つまり、重要なメールをスパムと判定したくないので、たまにスパムメールがフィルターをすり抜けても良いという考え。

一方で、誤りが多少多くても抜け漏れをなくしたいと言う場合には、再現率を重視します。例えば、発生する件数の少ない病気の検診で、病気であると誤判定するケースが多少あっても、再検査をすればそれで良いという考え方。

3.1.3 F値でバランスの良い性能を見る

こうしたトレードオフがあることを踏まえた上で、実際に分類器の評価に使われるのがF値と呼ばれる、適合率と再現率の調和平均である。

$$
F_1 = \frac{2}{\frac{1}{\text{適合率}} + \frac{1}{\text{再現率}}}
$$

再現率と適合率のバランスが良いほど、F値は大きくなる。つまり、F値が高いとは、2つの指標のバランスが良いことを意味している。

3.1.4 多クラス分類の平均の取り方：マイクロ平均、マクロ平均

他クラス分類の場合は、クラス全体の平均を取る方法が2種類ある。1つ目のマイクロ平均は全てのクラスの結果をフラットに評価できる。例えば、適合率のマイクロ平均は以下の式で計算できる。
$$
\text{マイクロ平均-適合率} = \frac{\sum_{i=1}^{3} TP_i}{\sum_{i=1}^{3} (TP_i + FP_i)}
$$

これに対して、もう1つのマクロ平均は、クラスごとに適合率を計算し、適合率の合計をクラス数で割ると言う方法で算出する。

$$
\text{マクロ平均-適合率} = \frac{1}{3} \sum_{i=1}^{3} \frac{TP_i}{TP_i + FP_i}
$$

マイクロ平均はクラスを跨いだ全体のパフォーマンスの概要を知るのに向いており、クラスごとにデータの数に偏りがある場合は、マクロ平均を用いた方が偏りの影響を考慮した評価ができる。

3.1.5 分類モデルを比較する

分類モデル同士の性能を比較をする場合、多くの場合でデータの偏りがあることを想定し、F値を基準に比較する。しかし、実問題を解くときには適合率と再現率のどちらを重視するか決定してから、チューニングする方法が望ましい。
誤りが許されない場合、「適合率が0.9以上にならないモデルは採用しない」という最低ラインを決めた上で、F値が高くなるようにパラメータチューニングをし、モデルを決定する方法が良い。
学習モデルの性能が高いことと、ビジネスゴールを満たすことは別の問題なので、性能のチューニングにどっぷりハマってしまわないように注意する。

3.2 回帰の評価

回帰分析で全データの平均値を出力する予測モデルを考えたとき、その平均2乗誤差は標準偏差となる。そのため、予測モデルの性能を評価するための最低限のベースラインとして、標準偏差と比較することで、モデルが平均出力以上の予測力があるかを調べることができる。

3.3 機械学習を組み込んだシステムのA/Bテスト

A/Bテストのメリットは以下である。

一定のユーザーにパターンを出し分けることで、同一期間に比較ができるため、季節性の影響を無視できる
実際にコンバージョンに至ったどうかといった、ビジネス的なKPIを追いかけられる
オフラインの評価では考慮できていない傾向を見つけることができる可能性がある

3.4 この章のまとめ

機械学習の評価の良し悪しと、ビジネス上のゴールとしてのKPIの良し悪しは別物である。この性質からA/Bテストを行える環境を用意しておくことは、重要である。

4章　システムに機械学習を組み込む

4.1 システム設計

ここでは、教師あり学習をシステムに組み込む場合の構成について解説する。

4.1.1 混乱しやすい「バッチ処理」と「バッチ学習」

混同しやすい内容なので、一旦ワードを整理する。

機械学習の文脈で「バッチ」というと一般的には、「バッチ学習」のことを指す
バッチ処理：一括で何かを処理すること
リアルタイム処理：刻々と流れてくるセンターデータやログデータに対して逐次処理をすること
本記事では、バッチ学習を一括学習、オンライン学習を逐次学習と呼ぶ

一括学習では、全データを使用して重みの最適化を行うため、モデル学習時に全ての教師データが必要。一方、逐次学習では教師データを1つ与えて、その都度重みを計算する。例えば平均を求める際、メモリーに保持されるデータはその時のデータと、計算された平均のみになる。
さらに、一括学習と逐次学習を組み合わせたミニバッチ学習と呼ばれる手法もある。

「バッチ処理で一括学習」と「リアルタイム処理で逐次学習」に加えて、まとまったデータは一括処理するけれど、最適化方針は逐次学習をする「バッチ処理で逐次学習」という手法も取ることができる。
以降は、バッチ処理とリアルタイム処理のパターンについて構成を見ていく。

4.1.2 バッチ処理で学習、予測、予測結果をDB経由でサービングする

Webアプリケーションで使い勝手が良いのはこのパターン。教師あり学習のモデルを一括学習し、そのモデルを使った予測値をバッチ処理で行い、その予測結果をDBに格納する方法。
このパターンの特徴は以下。

予測に必要な情報は予測バッチ実行時に存在する
イベント(eg ユーザーのWebページ訪問）をトリガーとして即時に予測結果を返す必要がない
- 予測頻度が1日1回以上程度で問題のない対象の予測に向いている
  - ユーザーの閲覧履歴からどのユーザークラスターに所属するか判定し、メルマガの配信内容を決定するなど

4.1.3 バッチ処理で学習、リアルタイム処理で予測、予測結果をAPI経由でサービングする

Webアプリケーションとは別に予測処理を薄くラップしたAPIサーバーを用意するのがこのパターン。このパタンでは、Webアプリケーションなどのクライアントから予測結果を利用する場合には、API経由のリアルタイム処理で予測を行います。
このパターンの特徴として、Webアプリケーションなどのクライアント側のイベントに対してリアルタイム処理で予測できるということが挙げられる。APIサーバーの開発、運用などのシステム開発の規模が大きく難易度が上がるため、リアルタイム処理での予測が重要でない場合には選択を避けたい構成。

4.1.4 バッチ処理で学習、エッジのリアルタイム処理で予測する

サーバサイドにてバッチ処理にて学習したモデルを使い、iOSやAndroidなどのスマホ上や、ブラウザのJavaScript、組み込み機器などのエッジ環境で予測を行うのがこのパターン。このパターンでは、学習をする環境と予測をする環境が大きく異なり、予測を実行する環境の制約が強いことが特徴である。
このパターンの特徴は以下である。

学習したモデルをクライアントで利用できるサイズまで最適化をし、変換する
クライアントで完結して予測を行えるので、予測時に通信のレイテンシーを省ける

4.2 教師データを取得するためのログ設計

機械学習、特に教師あり学習を行う場合、Webサーバーのアプリケーションログや、どこをどうクリックしたかなどのユーザーの行動ログなどを集めて、そこから特徴量を抽出するのが一般的である。
ログには、スキーマがない、記録していないデータを後から改めて取得するのが困難、といった特徴があり、システムに組み込むにあたって、さまざまなコツがある。

4.2.1 特徴量や教師データに使いうる情報

特徴量や教師データに使えそうな情報としては、大きく以下の3つがある。

ユーザー情報
コンテンツ情報
ユーザー行動ログ（コンバージョンにつながる情報を持つことが多く、特に重要な教師データになりうるので、適切に収集できるようにする）

4.2.2 ログを保持する場所

以下のようなデータの保持方法が考えられるが、いづれの方法をとってもSQLでデータにアクセスできるようにしておくべき。

分散RDBMS、データウエアハウス（DWH）に格納する
- Big QueryやAmazon Redshiftを利用する
分散処理基盤HadopクラスターのHDFDに格納する
- オンプレミスの制約が強い場合は、Apache Hadoopを用いた分散ファイルシステムHDFSを利用
クラウドのオブジェクトストレージに格納する
- AWS GlueやGoogle CloudのDataprocなどを使う

4.2.3 ログを設計する上での注意点

機械学習ではモデルの構築の段階に入るまで、有用な特徴量は分からない。そのため、ログの設計段階では必要そうな情報に当たりをつけて、あらかじめ設定しておく必要がある。KPIの設計時にはできるだけ少ない指標が良いとされているが、機械学習に使える情報は多い方が好ましい。後から、情報を減らしたり次元削減することは可能ですが、後から保存していない情報を増やすことは困難であるから。
また、現在取得しているログで教師データが作れるかといった視点も大事である。「広告をクリックしたログ」は取得してあっても「広告が表示したログ」は取得していないという事態になると、「広告が表示されたが、クリックしなった」という重要な情報が欠けてしまい、クリック予測ができない。

もう1つ気をつけるべきことは、サービスの機能追加や仕様の変更により、ログの形式や所得できる情報が変化すること。この場合、以下のような対策が考えられる。

データ量を多く使いたいので、古い特徴量のモデルを使い続ける
できる限り過去の特徴量を計算するバックファイルを行い、新しい特徴量のモデルを利用する
1と2でそれぞれ学習したモデルをアンサンブルする

4.3 この章のまとめ

機械学習を組み込んだシステム設計のパターンを整理し、ログの設計についても学んだ。これらの設計をする際には、できるだけ手戻りの無いようにする。

5章　学習のためのリソースを収集する

回帰や分類などの教師あり学習を行うには、正解データを用意する必要がある。この章では、教師データを収集する方法について書いてある。

5.1 公開されたデータセットやモデルを活用する

既に世の中に存在する学習済みモデルや、コンペティション用に用意されたデータセットを使ってベースラインを学習し、それを転用していく方法。この方法においては、以下の点に注意する必要がある。

モデルやデータセットは商用利用可能なライセンスか？
- 大学が科研費などを使って作成したものだと、研究目的に限定されていることがある
学習済みモデルやデータセットを自分のドメイン（運用するシステムやサービス）に適用できるか？
- 半教師あり学習（Semi-Supervised Learning）、転移学習（Transfer Learning）、ファインチューニング（Fine Tuning）などを実施する
- 特に画像の物体認識タスクでは、転移学習により少ない追加コストで目的の画像を認識するモデルを学習できることが知られている

5.2 開発者自身が教師データを作る

解きたい問題が分類か回帰かを考え、データ収集を始める。データを作成していく段階で、ラベルの付与定義を修正する作業が入る可能性もある。また、作業中に予測に効きそうな特徴量に当たりをつけられるなど、ドメイン知識の獲得も期待できる。一人でやるとデータ量の限界や思い込みによる偏りが発生してしまうリスクがある。

5.3 同僚や友人などにデータを入力してもらう

複数人で作業を行う際は、付与された正解データが作業者間でどれくらい一致しているか確認する必要もある。この比較により簡単に作業の難易度を理解することができる。また、人間同士でも正解ラベルが5割一致しないタスクは、そのデータを使って機械学習をしても解けない可能性が非常に高い。また、偶然に一致する可能性を考慮した基準であるカッパ係数を使って課題の難易度を判断する方法もある。

5.4 その他の方法

Yahooクラウドソーシングのように、一般の人にデータの作成を依頼する方法や、クラウドソーシングを利用する方法、サービスに組み込んでユーザーに入力してもらう方法がある。

6章　継続的トレーニングをするための機械学習基盤

6.1 機械学習システム特有の難しさ

大きな機械学習システムには従来のソフトウエアシステムではあまり問題視されることがなかった課題がある。

6.1.1 データサイエンティストVSソフトウエアエンジニア

機械学習プロジェクトでは、データサイエンティスト（DS）とエンジニアとの協働が必要になる。ここで問題になるのが、DSの多くは研究職やアナリストのバックグラウンドを持つ人が多く、エンジニアの知識が少ないという点である。これは日本だけでなく、海外でも同様の傾向が見られる。DSは速いイテレーションで試行錯誤をすることを好む一方で、メンテナンス性や再利用性の高いコードを書くことの優先順位を低くする傾向にある。そのため、エンジニアはシステムを安全に運用することや、プラットフォーム上で動く予測モデルの挙動を、人が確認してモニタリングしやすいようにするなどの工夫がされた設計をすることが求められる。

このように、それぞれが指向する領域が異なる専門家同士のチームを作り、まとめていくことが機械学習システムを実現する上で難しいポイントの一つ。

6.1.2 同一の予測結果を得る難しさ

機械学習システムでは、ある1つの実験結果を決定的に再現し続けるのは難しい。機械学習システムは、何かを少しでも変えると、システム全体の振る舞いが変わってしまうため。この特性は、CACE（Change Anything Change Everything）の原則と呼ばれる。

6.1.3 継続的トレーニングとサービングの必要性

学習済みのモデルを使い続けるということは、暗黙のうちに以下の仮定を置いているということでもある。

入力データの分布は学習時と予測時で大きく変わらない
入力データの使える特徴量も学習時と予測時で一致し、しかも十分にある

長期的に利用するシステムでは、これらの過程が満たされないことも珍しくないため、定期的に新しいデータを用いて予測モデルを更新する必要がある。
ブラックフライデーが日本でも意識されるようになったり、COVID-19により人々の生活様式が大きく変わった場合は、それまでに学習した予測モデルが変化に追従できず、予測が役に立たなくなってしまったなど、このような話は枚挙にいとまがない。予測モデルの更新にあたっては、データが大規模の場合にスクラッチで再学習を実施すると、時間がかかってしまうので、長期的にシステムを維持するためには、自動的にモデルが再学習するなどの継続的トレーニング(Continuous Training)
が重要である。

6.2 継続的トレーニングとMLOps

継続的トレーニングを実現させるには、それを支える機械学習基盤が必要になってくる

6.2.1 MLOps：機械学習基盤におけるCI/CD/CTを目指す取り組み

DSにとって、本番環境に学習済みモデルを容易にデプロイでき、高速に試行錯誤する実験のサイクルに、本番環境でのリリースのサイクルを近づけることが重要である。
DevOpsという開発（Dev）と運用（Ops）を融合していく取り組みになぞらえて、MLOpsという単語が生まれた。MLOpsは、MLシステムの開発（Dev）とMLシステム運用（Ops）の統合を目的とするMLエンジニアリングの文化と手法。MLOpsを実行すると、統合、テスト、リリース、デプロイ、インフラ管理など、MLシステム構築のすべてのステップで自動化とモニタリングを推進できる。
つまり、MLOpsは以下を行うための取り組みと言える。CI/CDに関しては、こちらを参照

ソース管理、単体テスト、統合テストの継続的インテグレーション（CI）
ソフトウエアモジュールまたはパッケージの継続的デリバリー（CD）
モデルの継続的トレーニング（CT）

6.3 機械学習のステップ

Google CloudのMLOpsのレベル別の構成を参考に、シンプルにしたバージョンを以下にまとめる。

6.3.1 共通の実験環境

試行錯誤のアジリティを上げて生産性を向上させるために重要なのが、共通の実験環境の整備である。これは大規模データ処理基盤があれば良いという話ではない。なぜなら、機械学習プロジェクトはドメイン知識、コーディングスキルの違いで属人性が高く、人が入れ替わった際の引き継ぎが通常のソフトウエア開発よりも難しいから。学習時のデータやPythonのバージョンなどが不明で、実験環境が再現できず、引き継ぎができないという事態を回避するために、以下のようなプラクティスが求められる。

共通の実験用のDockerなどのイメージを作成し、バージョニングして実験環境を再現しやすくする
共通のJupyterLabやクラウドサービスがホストするJupyterを使用して、実験の内容を共有、再実行による確認やレビューをしやすくする
MLflowなどの実験管理のためのツールを活用して、同じモデルを学習するための情報や実験結果を共有しやすくする

6.3.2 予測結果のサービング

予測結果のサービングは、学習した予測モデルを本番環境にデプロイし、予測APIサーバーで結果を返す取り組みのこと。多くのDSにとっては本番環境へのデプロイと予測APIサーバーを実装する部分がボトルネックになり得る。簡単な方法としては、Flaskなどで簡単なWebアプリケーションを書くことで実現ができる。アドホック的に予測サーバーをその都度書くのではなく、簡単に予測結果をサービングする仕組みを作るべきである。クラウドサービスの利用なら、Google Cloud AI Platform PredictionやAmazon SageMaker、OSSを使い自前で用意するならTensorFlow ServingやBentoMLなどがある。また、このタイミングでモデルのバージョン管理をすることもお勧めする。

6.3.3 学習、予測共通の処理のパイプライン化

手元でシンプルな開発を行う場合は、前処理のタスクと学習の処理を1タスクとして実行する方法がよく用いられる。しかし、この方法では学習と予測時で前処理の方法が異なるミスが発生したり、前処理に時間がかかるような処理だと、学習をやり直すたびに0から実行する必要が発生し多くの時間がかかってしまうことがある。このような問題に対してのアプローチの1つとして、前処理などの共通の処理を分割し、ワークフローエンジンを活用して処理をする方法がある。

6.3.4 モデルの継続的学習・デプロイ

通常のwebアプリケーションと同様に、モデルと予測システムの開発でも、開発環境、ステージング環境、本番環境のように複数のステップを経て開発をすることになる。次の環境へデプロイを進める際に、できる限り手動でのオペレーションを避けることはCI/CDを行う上で重要になってくる。Pull Requestの承認や特定ブランチへのマージを承認すれば次の環境へのデプロイを自動的に行えるようにするなど、処理の自動化を適切に組み合わせることが必要。

6.4 予測結果のサービングを継続し続けるために

通常のWebアプリケーションのようにシステムがダウンする、というような観測しやすい障害だけに限らないのが機械学習システムの難しいところ。

6.4.1 監視・モニタリング

機械学習サービングにおけるモニタリングで重要になってくるのが、モデルの予測のパフォーマンスに関するメトリックス。具体的には以下をメトリックスとして追いかけるのが良い。

予測結果のサービング時のメトリックス
- メモリ、CPUなどのハードウェアリソースの使用量
- 予測のレスポンスタイム（予測のための精度を高めた結果、レイテンシーが下がるとコンバージョン率が下がる可能性があるので、予測のレイテンシーには注意する）
- 予測値のあるwindowでの統計値や分布
- 入力値の統計値、特に欠損値やNanの頻度
学習時のメトリックス
- モデルの学習時からの日数（鮮度）
- 学習時の予測精度や学習時間（学習時間が長いと、モデルの更新のコストが大きいことを示唆している）

6.4.2 定期的なテスト

リアルタイム性の高いメトリックスの監視では対応できないものに対しては、日次などの定期的な自動テストを行うことで健全な予測ができているかを確認する。自動テストできるものとしては大きく以下の2つがある。

本番環境での予測結果に対する最新正解データでの予測精度の検証
- 遅れて手に入った正解データと共に過去の予測結果に対する精度を評価する。人間がアノテーションや正解ラベルの付与で関わることをHuman in the Loopと呼ぶ
データの品質の検証
- 正解データの取得にコストがかかる場合が多いため、予測結果のサービング時の入力データの質や健全性をテストすることで、モデルの有効性を評価する
- 機械学習モデルは、学習時にあるものや分布を前提として予測する（学習データに偏りがある場合は、予測結果にも同じような偏りが発生する）
- 学習時のデータと異なる分布や範囲のデータに対して、モデルは適切な予測を行うことはできないため、学習時のデータとの「違い」を検出することにより、データの質を検証する

では、どのようにデータの違いを検証すれば良いのか。実際に予測結果を計算した入力データに対して大きく以下の2点を検証する。

入力データの「スキーマ」の検証
入力データの偏りや変化（drift）の検証

入力データの「スキーマ」とは、特徴量がどのような特性を持っているかあらかじめ「スキーマ」として学習データから定義し、それに外れた値が入力されている場合アラートを上げるといった使い方をする。具体的には、以下のような点をチェックする仕組みをあらかじめ用意しておく。

データが想定された範囲か
既知のカテゴリ値か
Nan/Inf値が生成されないか
特徴量の多次元配列の要素数は同じか
特定の入力がなくなっていないか

データの分布の変化の検出としては、カテゴリ値の場合にチェビッフ距離、数値にJensen-Shannon divergenceで閾値を設けて、学習時の分布と異なる分布になっていることを検出する。

7章　効果検証：機械学習に基づいた施策の成果を判断する

「新機能をリリースしたら先週と比較して売り上げが20%上昇しました、プロジェクトは成功です」。果たして本当にこのようにいうことができるのか？機械学習プロジェクトの成否は、機械学習を利用した結果、ビジネスにどれだけの影響を与えたかで判断できるため、オフライン、オンラインでの効果検証の方法を説明する。

7.1 効果検証の概要

効果検証とは、ある施策によってもたらされた効果を推定すること。言い換えると、「事象YがXによってどれだけ影響を受けたか」を明らかにする行為。

7.1.1 ビジネス指標を用いた施策の評価

機械学習の多くのユースケースでは、予測を元に何らかの意思決定を行うため、モデルの精度自体の評価指標（Accuracy, MAPEなど）ではなく、実際のビジネスインパクトを評価したい。特に事業部所属のDSには、利益貢献が求められるため、ビジネス指標を使ったコミュニケーションが行えると良い。DS内では「この機能のリリースにより予測精度が向上する」で通じるが、チーム外に報告する場合は、予測精度が上がると何が嬉しいかを言語化すべき。

また、機械学習では実験段階で求めた予測精度から、ビジネスに与える影響度が予測しずらい面がある。予測精度の向上が利益に繋がらないこともあるので、モデルの継続学習や改善のためのコストを払うことが、利益の向上に繋がるのか慎重に判断する必要がある。

7.1.2 オフライン検証とオンライン検証

検証の方法は主にオフラインとオンラインに分かれる。オフライン検証では、過去のデータを使ったシミュレーションを行う。オンライン検証は、実際にプロダクトに適用して実験を行います。特に、Webサービスでは機能の切り戻しやランダム適用が容易なため後述するA/Bテストがよく用いられる。ただし、A/Bテストは実施コストが高いため、オフライン検証でプロダクトに実装するかの判定をし、プロダクトに組み込んだ後に、オンライン検証を行う形式がよく取られる。

7.1.3 指標の選定

顧客の生涯価値（Life Time Value）のようにプロダクトの長期的なゴールに近い指標が良いですが、通常このような指標は検証に時間がかかる。そこで、代わりに代替指標を用いる。代替指標はゴールとなる指標を達成するためのマイルストーンとなる先行指標のうち、ゴール指標と比例関係にあるのが理想。

7.2 因果効果の推定

7.2.1 相関関係と因果関係の区別

相関関係と因果関係は別物である。例えば、アイスクリームの売上と海難事故件数の間には相関関係があるが、これは両者に因果関係があるのではなく、気候という因子が両者に影響を与えているにすぎない。このように2つの事象に影響を与える因子を交絡因子と呼ぶ。

7.2.2 ルービンの因果モデル

インターネット広告の例を使って、因果推論に関して説明する。因果推論では広告を見せることを介入、購買行動を結果変数、介入した標本を介入群、もしくは実験群、介入していない標本を対照群、もしくは統制群と呼ぶ。本来、Aさんが広告を見た時と見なかった時の購買の違いを観測したいが、これは直接観測することはできない。そこで、購買した結果を$Y_1$、購買しなかった結果を$Y_0$として、母集団への効果を平均処置効果（Average Treatment Effect: ATE）として考えると、以下のように考えられる。

$$
ATE = E(Y_1 - Y_0) = E(Y_1) - E(Y_0)
$$

しかし実際には、この差は以下のようになっている。ここには、そもそも広告によって介入する群は購入が期待できそうなユーザー群を事前に狙っている場合が多いので、セレクションバイアスの問題も発生している。

$$
E(Y_1|介入あり) - E(Y_0|介入なし)
$$

セレクションバイアスを解決する方法として、ランダム化比較実験（RCT）がある。標本に対してランダムに介入有無を決定することで、性質の等しい2群の片方に介入した状態を作る。社会実験や臨床試験でRCTを実施するにはコストが膨大だが、Webサービスの効果検証においては容易に適用できるため、A/Bテストのベースとなっている。

7.2.3 過去との比較で判断するのは難しい

「あるプロダクトで売上向上施策をリリースした直後に、ユーザー1人あたりの売り上げが向上した」。このような場合でも、売上の向上が施策によるものだと断定できません。インフルエンサーに紹介された、新しいCMが打ち出されたなど、別の要因がある可能性があるからです。このような状況では過去との比較による因果効果の推定は非常に困難ですが、A/Bテストを実施すると簡単に施策による介入効果以外の要因を揃えることが可能になるため、施策の因果関係を分析できる。RCTを行わない方法として、時系列モデルを構築して生成した反事実ケースの予測値と実績の比較を行うCausal Impactという手法も存在するが、これは未来予測が可能なモデルを作れることが前提となる上に、結果の信頼度はこのモデルの精度に依存する。

7.3 仮設検定の枠組み

A/Bテストの解釈のベースとして仮説検定、標本を使って母集団に対する判断を行う方法がある。これにより、限られたサンプルによりオンライン検証でも、より大きな母集団に施策を実行した時の効果を検証することができるようになる。仮説検証において最も注意しないければならない点は、p値ハックである。サンプル数を大きくしたり、検証に使うデータを変更することで、たまたま有意な結果が出た時の結果を使用するといった方法が問題になります。

7.4 A/Bテストの設計と実施

A/Bテストを実施する際の流れは、次のように書ける。

指標の選定
2群の抽出
A/Aテスト
片方に介入
結果の確認
テスト終了

7.4.1 2群の抽出と標本サイズ

「既存のユーザーから2群を抽出し、介入後に1人あたりの売り上げの平均に違いが出るか検証する」ようなパターンでは、標本サイズが足りない場合、テストのやり直しになるため、標本サイズの見積もりは事前に必要になる。このパータンでは、以下の点に注意して標本を決定する必要がある。

テストサイズを大きくすると、影響を受けるユーザーも増えるため、施策がイマイチのときは事業に与える影響が大きくなりうる
全ユーザーを半々にして2群を作ると、別のオンライン検証が行えなくなる
前のテストの介入群・対照群を使い回すと、前のテストの影響を引き継いでしまう

7.4.2 継続的なA/Bテストと終了判定

逐次的に観測データが得られ、標本サイズが大きくなっていくのがオンラインテストの特徴。この設定は認知のタイミングで判断が行えるため従来の仮説検定との違いを強調してSequential A/B Testingと呼ぶこともある。サンプル数が増えることによるp値ハックに気をつける必要はあるが、時間をかけると標本が増え、結果は収束に向かっていくため判断が容易になるという特性を持つ。さらに事後分布を考慮したベイズ統計の考え方との親和性も高い。

新たなデータが逐次得られるテストの終了タイミングは自明でないが、結果変数の時系列プロットに信頼区間を重ねることで視覚的に判断できる。信頼区間が分離したら差があると判断でき、信頼区間がなかなか分離しない場合は、差がないかあっても小さく効果は見込めないと判断できる。施策が良い場合も悪い場合も、A/Bテストの中止の判断を早く行うことは良いことである。なぜなら、良い施策を早く全部のユーザーに実施でき、悪い施策は早く捨てることができるから。

7.4.3 A/Aテストによる均質さの確認

ランダム抽出により差がない2群が得られたとき、それらを介入群と対照群に分けることで、RCTの実施が可能になる。このランダム抽出による均質な2群が得られているかを確認するのが、A/Aテスト。2群の過去データに差がないことや、抽出後に時間を置いて差が確認できなければ、片方に介入を実施する。

7.4.4 A/Bテストの仕組み作り

A/Bテストを実施するにはプロダクトがA/Bテストに対応している必要がある。特に機械学習においては、学習データの分離に注意する必要がある。推薦システムはユーザーの行動ログを学習データとしているが、このログデータは稼働中の推薦システムの影響を受けたものである。そのため、複数の予測器をA/Bテストで比較していると、学習データ経由でお互いに影響を与えてしまうといった事態に陥るリスクがある。

7.5 オフライン検証

オンライン検証の設備が整っている場合でも、A/Bテストの実施コストは大きいためオフライン検証が重要。

予測モデルの精度がビジネスに与える影響の評価を正確に判断するのは難しいが、予測を元に起こりうる結果を言語化（見込み客を予測するモデルなら、当たった場合の売り上げと、外した場合の損失）することで、把握することができる。言語化した上で、利益・損失の数値化ができれば、予測モデルを使った時の期待収益を求めることができる。

効果検証で興味があるのは、予測の出力そのものではなく、予測を利用して何らかの行動をとるシステムとしての性能。この行動決定ポリシーの評価を、過去の別のポリシーによって生成されたログから評価することをOff Policy Evaluationと呼ぶ。オフライン検証では、過去のポリシーと異なる行動を取りうる場合の評価をどうするかが問題になるが、行動が離散である場合に適用できるポリシー性能評価は一般的になりつつある。

7.6 A/Bテストができないとき

A/Bテストの仕組みがなかったり、そもそも介入のランダム割り当てが不可能な場合には、後になって当時のデータを元に効果検証をすることがデータ分析の現場ではよくある。RCTにより得られた実験データに対して、自然に得られたデータは観測データと呼ばれる。
観察データでは、交絡因子やセレクションバイアスに対処することが難しい。しかし、計量経済学や因果推論の分野では、観察データから因果関係を特定するための様々な手法が開発されている。その1つがマーケティングの分野などでよく使われる差の差法（Difference in Differences）である。これは、介入群のAに対して限りなく性質が似ている群Bを見つけだし、Bから介入がなかった時のA群の推定値を求めることで、A群における介入の効果を測る手法。

7.7 絶対に成功するA/Bテスト、A/Bテスト母集団ハック

以下のような点が懸念される場合、正しくA/Bテストが行われていない可能性があるので、注意する必要がある。

母集団が絶対にゼロの値を取るセグメントを使っていないか
- 非アクティブユーザー群の売上は0円だから、いかなる施策をうっても現状（0円）より悪くなり得ない
複数の施策が1つの群の中に混ぜ込まれていないか（以下の場合は不適）
- A群：いつも通りのメール配信
- B群：機械学習によるクーポンの配布を実施した（機械学習施策とクーポン施策の2つが混ざっている）
ベースライン施策が正しく設計されているか（上の施策なら以下のように、A/Bテストを実施し、C群がベースラインとなる）
- A群：いつも通りのメール配信
- B群：機械学習によるおすすめの割引クーポン付きメール群
- C群：顧客が最後に閲覧した商品カテゴリに対するクーポンコード付きメール群

8章　機械学習モデルを解釈する

機械学習で得たモデルのパラメータを調べることによって、どのような特徴量が目的変数にどのように寄与したかを調べられる。それによりなぜこのような予測になったのか、その予測にはどのような特徴量が寄与していたのか、どの特徴量とどの特徴量を組み合わせるとよく予測できるのかを説明できるようになり、予測の根拠と人間の直感が合致しているか判断され、予測モデルの妥当性が評価される。
さらに、機械学習は予測介入のためだけでなく、何が目的変数に寄与しているのかといった現状の分析にも使用することができる。

8.1 線形回帰の係数から原因を読み解く

線形回帰の係数から、特徴量の予測に対する寄与具合を比較する際、スケールが小さい特徴量（カテゴリ変数など）の方が係数が大きくなるため、正規化をしてからモデルの学習を実施する必要がある。
次に、正規化して発散してしまった場合には、多重共線性が疑われる。よくあるケースとしては、One-Hot Encodingの際に、n個のカテゴリからn個のダミー変数を作成してしまうなどが原因で発生する。

8.2 ランダムフォレストのFeature Importanceの可視化

ランダムフォレストやGBDTなど複数の決定木を利用した学習器では、Feature Importanceというパラメータを求めることで、分類や回帰に寄与した特徴量を把握できる。この際、特徴量に多重共線性があるとFeature Importanceの値が分散してしまい低めに出てしまうので、注意する必要がある。ランダムフォレストは決定木ベースのアルゴリズムだが、決定木の構造をプロットして解釈するのは不適切。なぜなら、ランダムフォレストは、利用する特徴量をランダムに選択することで、多様性のある決定木を生成する仕組みになっているため、特定の決定木の構造からでは寄与する特徴量を把握することはできないから。

8.3 SHAPによる寄与の可視化

決定木による可視化には、一度に多くの変数を見ることができないという問題があり、ランダムフォレストのFeature Importanceは、特徴量が変化するとどのように分類結果が変化するか分かりずらいという問題がある。これらの問題を解決した可視化ライブラリとしてにSHAPがある。

8.4 この章のまとめ

機械学習は完全はブラックボックスではないが、「人間には容易に理解できない」ものという意味でしばしば「機械学習はブラックボックス」だと言われる。様々なツールを使うことで、機械学習の結果を人間が説明できる可能性もあるが、機械学習はあくまで「予測」を行うためにパラメータの最適化を行なっているのであって、「説明」するためのものではない。そのため、人間の直感に反するような結果が生まれることがあることを理解しておく必要がある。

10章 Uplift Modelingによるマーケティング資源の効率化

10.1 Uplift Modelingの概要

Uplift Modelingでは、A/Bテストの結果を拡張したものと考えられる。たとえば、広告の効果を測るためにA/Bテストを実施し、Bの方がCV率が高い場合を考える。この時、通常のA/Bテストなら、Bの広告で決定となる。しかし、Uplift Modelingでは、個々の顧客が持つ特徴量を利用し、個人ごとにどの広告を使用するのが良いのかを特定でsきる。

似た手法として、Causal Impactがあるが、Uplift Modelは「誰に施策を打つと効果があるか」を個人レベルで推定する手法、Causal Impactは「施策全体がどれくらい効果を持ったか」を時系列データで評価する手法である。

原始的なUplift Modelingでは、実験群と統制群のそれぞれに対して予測モデルを作成する。CVレートを目的変数としている例において、実験群に対しては、もし介入行為を行なわなかった場合、CVレートがどうなるか。統制群に関しては、もし介入行為を行った場合のCVレートを予測します。この両者を用いることで、介入行為によるCVレートの変化を予測できる。

10.2 Uplift Modelingのスコアと評価方法

Uplift Modelingでは、統制群と実験群のそれぞれで予測モデルを作成するため、この2つの予測値が得られます。これを統合して1次元の値に統合する際、以下の条件を満たすようにして、Uplif Modelingのスコアを作成します。

統制群の予測値が低く、実験群の予測値が高い時、説得可能な顧客なので、高いスコアになる
統制群の予測値が高く、実験群の予測値が低い時、天邪鬼な顧客（説得すると逆効果）なので、低いスコアになる

$$
\text{Uplift Modelingのスコア} = \frac{実験群の予測値}{統制群の予測値}
$$

Uplift Modelingの評価には、Area Under the Uplift Curve（AUUC）という指標を用い、この値が大きいほどUplift Modelingの性能が高いとする。あるスコア以上の顧客に介入し、あるスコア未満の顧客には介入行為を行わなかった場合、介入行為を行わなかった場合と比較して、どれくらいCV件数が増えたかを表す指標をliftと呼ぶ。liftとランダムに介入を行った場合のCV件数の増加を算出したベースライン指標を比較して、liftとベースラインに囲まれた面積を算出し、正規化したものをAUCCとする。

最終的に、横軸にUplift Modelingのスコア、縦軸にCVレートをプロットしたグラフを作成し、グラフから、スコアがいくつ以上の顧客に介入するようにするといった方法で、意思決定を実施する。

10.3 Uplift Modelingを本番投入するには

実験したい介入行為を設計し、実験群と統制群で何を行うかを決める
顧客の一部に対して、ランダム化比較実験を実施する
ランダム化比較結果を学習データとテストデータに分ける
学習データからUplift Modelingの予測器を作成する
テストデータからUplift Modelingのスコアの予測結果のグラフを描き、挙動を確かめる
Uplift Modelingのスコアのグラフから、スコアがいくつ以上の顧客に対して、介入行為を実施するのかを決める
残りの顧客に対して、Uplift Modelingのスコアを予測する
予測されたスコアから、介入行為を実施しない対照群とし、残りを介入群とする
介入群に介入行為を行う
介入群と対照群のコンバージョンレートの比較を行い、介入行為の効果を計測する

以上の本番投入までの流れを図示したものが以下。

11章バンディッドアルゴリズムによる強化学習入門

十分なデータがなかったり、データを集めるのに費用がかかるような場合に、教師データを収集しながら学習を行なっていく強化学習が用いられる。強化学習とはある不完全な状態のおかれたエージェントが、不完全な情報を元に行動を選択し、情報を蓄積していく。そして、その行動の結果報酬を得て、最終的に報酬の総和が最大となるようにする手法です。バンディッドアルゴリズムは、非常に簡単な強化学習手法の一つであるため、ここでは2つのコインのどちらを使う方が、表が出る回数が多くなるかをバンディッドアルゴリズムを用いて考え、、強化学習の基本的な概念を学ぶ。

バンディッドアルゴリズムでは、試行回数を増やして母平均の不確実性を減らし、選択肢の母平均を比較し最善の選択を取るようにするアルゴリズムである。試行回数が違う2つのコインのどちらがより表が出やすいかを評価する方法として、95％信頼区間の上限の値を用いるBaysian-UCB（Upper Confidence Bound）や数学的に期待値を計算するUCB1（Upper Confidence Bound version 1）がある。

しかし、これらの方法は即座に報酬が返ってくることを前提とした決定的で逐次的なアルゴリズムです。そのため、バッチ処理や並列化に向かないという欠点があります。
そこで、報酬を得るのに時間がかかる環境や、バッチ処理、並列化に適合した非決定的なアーム選択のロジックとして、Softmax法とThompson Samplingがある。

Softmax法
Softmax法は、標本平均の高い選択肢の選択確率を増大させ、標本平均の低い選択肢の選択確率を低くすることで、探索と活用のバランスを取る手法。Softmax法では、以下の指揮に従って、選択肢の選択確率を決定する。

$$
\text{ある選択肢の選択確率} = \frac{exp(ある選択肢の標本平均/温度)}{\sum{exp(各選択肢の標本平均/温度)}}
$$

温度パラメータによって、探索と活用の度合いを調整することができるため、温度を徐々に小さい値にすることで、探索から活用の度合いを高めることができます。この方法は、アニーリング（annealing）と呼ばれ、以下のようにkの値をコントロールすることで、温度が下がっていく速度を調整できる。分母に2があるのは、負の値や0での除算を防ぐため。

$$
\text{温度パラメータ} = \frac{初期温度}{ln(k * 全ての選択肢を選択した回数+2)}
$$
アニーリングを使用したSoftmax法は、対象とする問題に合わせて最適なパラメータを事前に探っておく必要がある。

Thompson Sampling法
Thompson Sampling法は、調整するパラメータがほとんどないにも関わらず、比較的上手く作動するアルゴリズムとして知られている。この方法では、ある選択肢の評価値をその選択肢の事後分布から引いてきた乱数として評価する。

A/BテストとUplift Modelingは実はバンディッドアルゴリズムのサブセットと考えられる。A/Bテストは100%ランダムに配信してから、事後分布が収束したら標本平均の最も高い選択肢を選択して配信するバンディッドアルゴリズムと考えられる。Uplift Modelingも同様に、最初は100%ランダムに配信し、選択肢と特徴量と報酬を得て、ある時点からはある特徴量における評価値が最大の選択肢を選択するバンディッドアルゴリズムと考えられる。A/BテストやUplift Modelingで難しいのは、どこで実験を打ち切る意思決定をするか。バンディッドアルゴリズムを採用することで、そのような人間の意思決定のコストを削減できるため、バンディッドアルゴリズムをシステムに組込み、システムに意思決定させることも可能。一方で、バンディッドアルゴリズムは、報酬が選択の直後に帰ってくるのを前提としているため、中長期的な効果を検証したい場合は、A/Bテストの方が適切であることも多い。