KDD19で発表されて一時期話題になっていたBernardi et al. (2019) 150 Successful Machine Learning Models: 6 Lessons Learned at Booking.comを読みました。
これは宿泊施設を検索して予約できるウェブサイト「Booking.com」における機械学習の活用事例と、その過程で得たノウハウについての論文です。
機械学習のビジネス活用に焦点を当てていて良い論文でした。
以下にざっくり内容をまとめてメモしていきます。
機械学習はビジネスに貢献する
まず、機械学習の活用事例について。
Booking.comでは多数の機械学習モデルを利用しているのですが、例えば、
- お客様の旅行のcontextを予測して、子供がいたらその情報も検索欄に入れるようにリマインドする（Figure 1 (a)）
- 各宿泊施設についてのレビューを要約する（Figure 1 (b)）
- 特定の都市の価格のトレンドなど有益な情報を提示する（Figure (c)）
みたいなことをしているそうです。
また、Booking.comにおいては機械学習モデルはRCTによってビジネス指標で評価しているらしいのですが、機械学習は十分なビジネス貢献をしていることを述べていました。
Figure 2のBenchmark以外の各バーは機械学習の活用の各カテゴリ（model family）で、Content Curation以外はBenchmark（これらの機械学習の活用以外のプロジェクト）を上回っています。
Offline Metricsはビジネス指標とは相関しない
モデルのOffline EvaluationにおけるMetric（ROC-AUCとか）の改善がビジネス貢献につながるとは限らない、という発見について。
Figure 4は機械学習モデルの改善を行った23個のペア（46モデル）についての図です。横軸がOffline EvaluationのMetrics（classifierについてはROC-AUCでrankerについてはMean Reciprocal Rank）の相対差で、縦軸がOnline EvaluationにおけるConversion Rateの相対差になります。
これについての著者らの考察は次のようなものでした：
- パフォーマンスの増加によるビジネス価値の増加は逓減する
- 不気味の谷現象：ユーザーの行動をピッタリ予測しすぎて気味悪がられる
- 中間的な指標への過度な最適化：例えばクリック率を最適化するようにモデルを作っていった結果、コンバージョンにつながらない「単にクリックさせるだけ」のモデルになっていった
Booking.com内では他の領域の実験でも一貫して同様の結果が得られたそうです。
Latencyの増加がビジネスに悪影響を与える
latency（待ち時間）が増えるとビジネス指標を下げるし、逆にlatencyを下げる努力をすることでビジネスを改善できたという報告。
Figure 6は横軸がlatencyの処置群と対照群の相対差で、縦軸がConversion Rateの相対差です。図の右下の象限は程度の異なる人工的なlatencyを処置した実験のもので、左上の象限は独立した4つの実験の結果です。
機械学習は計算コストが多いためlatencyとも関わってきます。Booking.comでは計算量を下げるために、様々な工夫をしているそうで、個人的に印象的だったのは次のものでした：
- 自社開発した線形予測エンジン: 予測時間を最小化するように徹底して調整した線形予測を自社で開発した。これはナイーブベイズ、一般化線形モデル、k-NN、Matrix Factorization modelなどの全てのモデルを内積に緩和することができる。
- Precomputation and caching: 特徴空間が小さい時、すべての予測値を単純にkey-value storeに分散することができる。特徴空間が大きすぎるときもよくあるリクエストはメモリにキャッシュすることができる。
線形予測エンジンについてはどうやって計算量を下げているんだろう…という感じですが、論文中では詳しくは書かれていませんでした。precomputationは言われてみれば確かに当たり前なんですが徹底してるなーと感じました。
予測値のみでモデルの品質を監視する
デプロイして稼働させている機械学習モデルが変な値を予測していないかは気になるところだと思います。
しかし少なくともデプロイしてすぐには正解データ（教師ラベル）がない状態なので、予測値が正しいかどうかがわからないという問題があります。
Booking.comではこうした「単純に予測値だけを見てモデルの品質についての情報を得たい」という問題に取り組み、二値分類に関してはResponse Distribution Analysisという方法を考案して使用しているそうです。
この方法は単純に分類器の出力（{0, 1}の値ではなく、スコアのほう）のヒストグラムを作り、
- 理想的な二値分類器は0付近と1付近にピークを持つ二峰の分布になるはず（Good discriminator）
- 二値分類なのに単峰の分布になっていたら、全然分類できていない（High Bayes error）
といった感じに診断していくというものです。
実験設計の重要性
例えば、「別の目的地をレコメンドする」という処置は、Booking.com上では「この人は目的地についてレコメンドしても邪魔にならない」と判断されたユーザーに対してしか行うことができません。そのため実験もそのようなユーザーにしか行うことができません。
このようにモデルに依存して処置が利用可能かどうかが決まる場合、処置群の一部の個体しか処置されないため、標準的なRCTの枠組みをそのまま適用すると、検出される効果を薄めてしまいます。
そこでBooking.comではTriggered Analysis（Deng & Hu, 2015）という改良版のRCTを利用しているそうです。これは処置群と対照群に割り振られた個体のうち、モデルの出力に照らして処置が利用可能だった個体のみを使用して実験を行うという枠組みです（Figure 8）。
さらに、3グループに分けて実験を行うことで、モデル導入時の効果を「latencyの増加による影響」と「モデル自体の純粋な効果」に分解できます。
2つに分けた処置群の両方ともモデルを動かすものの、結果を使うのはTreatment group 1にすることで、
- ControlとTreatment 1の比較＝モデル導入の全体的な効果
- ControlとTreatment 2の比較＝モデル導入のlatency増加による効果
- Treatment 1とTreatment 2の比較＝モデル自体の純粋な効果
という風に分解できるようになります。
新旧モデルの比較時も3群で実験を行い、両モデルで結果が異なった（Models Disagree）個体だけを分析に使うようにしているそうです。
まとめ
ざっくりいうと
- 機械学習の活用はビジネス上の価値をもたらした
- offline evaluationのmetricsの改善はビジネス上の利益とあまり相関しなかった
- latency（待ち時間）が多いとビジネスに損害をもたらす。逆にlatencyを削減することで利益を増加させることができた。
- 標準的なRCTが合わない状況もある。実験設計をしっかり行うことで「機械学習の導入の効果」から「導入によるlatency増加による負の効果」と「機械学習自体の純粋な効果」に分離することができた
- 機械学習モデルの品質の監視のためのResponse Distribution Analysisという方法を考案し、活用した
という感じでした。
Online Evaluationの重要性と、その際の実験設計（latencyの効果とモデルの効果との分離など）の重要性がわかるよい論文でした。
参考
Deng, A., & Hu, V. (2015, February). Diluted treatment effect estimation for trigger analysis in online controlled experiments. In Proceedings of the Eighth ACM International Conference on Web Search and Data Mining (pp. 349-358). https://dl.acm.org/doi/abs/10.1145/2684822.2685307
