前提

ここでは web システムで使われている機械学習のモデルやアルゴリズムを改善するための online の A/B テストを考える。
具体的に述べると web 広告における CTR 予測や EC サイトのレコメンデーション等が対象である。
よくあるやつ。

web システムにおいて online の A/B テストは KPI 改善の根幹でありとても重要だ。
それが重くなるとつらい、という話。
ここで「重い」と言っているのは計算資源のことではなく、A/B テストを実施する担当者の運用コストについて。

A/B テストの運用が重い場合のデメリット

デメリット 1. KPI 改善が遅くなる

デメリットと言えばこれが一番大きい。
単純に A/B テストを1回まわすのに時間がかかってしまうし、それがゆえに online の A/B テストに入るまでの offline のテストが厚くなりここでも時間がかかってしまう。
KPI 改善に時間がかかるというのはつまり売上や利益を大きくするのに時間がかかってしまうということである。

デメリット 2. KPI 改善における offline テストの比重が大きくなる

前述のとおりだが online の A/B テストが重いとそこで失敗できなくなり、結果としてその前段の offline のテストを厚くするということになる。
offline のテストが厚いことの何が問題だろうか。

ここで前提としている CTR 予測やレコメンデーションのようなタスクの場合、offline のデータは既存のモデルやアルゴリズムの影響を受けることになる。
例えばレコメンデーションの場合を考えると、新しいモデルを offline で評価するための実験データの正例 (コンテンツの閲覧等) は既存モデルによって生み出される。
既存モデルが「このコンテンツがいいよ」といってユーザに出したリスト、その中からコンテンツの閲覧が行われ正例となるからだ。
このような状況下での offline テストにおいては既存モデルと近い好みを持ったモデルのスコアが高くなる傾向がある。

もしかしたら既存モデルの影響を受けないようなデータをあえて用意しているような場合もあるかもしれないが、レアケースだろう。
既存モデルの影響を受けないということは恩恵を受けないということなのでトレードオフでもある。

デメリット 3. 新モデル／アルゴリズムを却下しにくくなる

A/B テストの運用が重いと何度も繰り返すことができない。
なので一発の A/B テストで既存モデル／アルゴリズムを置き換える成果を出さなければならないという圧が強くかかってしまう。
既存モデル／アルゴリズムが勝って新しいものが負けてしまったときの埋没費用が大きいからだ。

そうなると次のような事が起こる。

  • 「新モデルをチューニングしてみよう！」
    • 数ヶ月前のデータでチューニングされていない既存モデル vs. 直近のデータでチューニングされた新モデル
  • 「新モデルが KPI で勝っている間に意思決定しよう！」
    • 勝ったり負けたりする中で…

つまりフェアなテストではなくなってしまう。

なぜ A/B テスト運用が重くなるのか

理由 1. リリース作業のコスト

A/B テストの運用が重くなる理由の1として、A/B テストを始めるときのオペレーション、つまり新しいモデル／アルゴリズムをリリースする際の作業コストが重いことが挙げられる。

これにはモデル／アルゴリズムが web のシステムに対してどのような形でデプロイされているかが影響する。
mercari が次のような資料を公開しているので参考にしたい。

例えば Synchronous pattern のように web サーバと推論をする場所が分離している場合に比べて Web single pattern のように一体化している場合は新しいモデル／アルゴリズムのリリースに繊細にならざるを得ないのではないだろうか。
コードベースもそうだし、マシンリソースの管理も後者の方が難しい。
特にリリース担当者がデータサイエンティスト的な人だった場合、リリースの心理的障壁が上がる。

理由 2. はっきりしない指標

A/B テストするときはテストの指標として何らかの KPI を置く。
この KPI が複数ある場合がある。
例えば web 広告における CTR 予測モデルであれば CTR と impression 等。
現実のビジネスは複雑なので複数の KPI があるのは珍しくないと思われる。

一方で KPI が複数になると評価が難しくなる。
「KPI A は5上がったけど B は3下がった、この場合はどうなの？」ということになり “マネージャの肌感” みたいなものが必要になってしまう。
当然機械的に判定することによる自動化なども行えない。
A/B テストの経過における現状の良し悪しの判断にコストがかかってしまうことになる。
また判断基準が複雑なことによりおとり効果のようなことも発生しうるだろう。

これについての1つの解として OEC: Overall Evaluation Criterion という考え方がある。

複数の KPI を重みをつけて組み合わせてただ1つの値として評価できるようにする、というものらしい。
逆に考えると OEC を定義せずに複数の KPI で A/B テストをするということは KPI 間のバランスの合意なしで走ってしまっているということになる。

理由 3. 煩雑な流量オペレーション

これは実際に見たことだが、A/B テストの運用に際して組織の一部の人間しか理解していない煩雑なオペレーションを伴うことがある。

最初は control group を 0.1% だけ流して、1日経って問題がなければ 1% に上げて、その次は5%で…などのような操作を求められるのである。
担当者にすればまあまあのストレスだし、時間がかかってしまう。

まとめ

ソフトウェア開発の分野でも大きな変更をえいやーでリリースするのはキツイということで git-flow であったり GitHub Flow であったりが導入されてきたはず。
A/B テストが重いということはそれの逆をいっている状態となる。つらい。