実験と A/B テスト

ML の開発では何十、何百という実験をします。記録がないと「先月の一番良かったモデルはどの設定だったか」が分からなくなり、本番のモデルを作り直すこともできません。MLflow や Weights & Biases（W&B）などの実験管理の道具を使い、実験ごとに自動で記録します。

乱数とデータのバージョン：

• 乱数のシード（乱数の出発点）を固定して記録します。Python・NumPy・PyTorch など、使うライブラリごとに設定が必要です。ただし GPU の計算は並列の順番によって結果がわずかに変わることがあり、完全に同じにするには決定的な計算の設定が要り、遅くなることがあります。
• シードを変えるだけで指標がどれくらい動くかも見ておきます。改善の幅がシードによるばらつきより小さければ、それは改善とは言えません。
• データは後から変わります。テーブルの行が追加・修正されると、同じ SQL でも結果が変わります。学習に使ったデータは、スナップショット（その時点のコピー）を保存する、日付で区切った不変のファイルにする、DVC などのデータのバージョン管理を使う、のいずれかで固定します。

A/B テストは、ユーザーをランダムに2つに分け、片方には今のモデル（A）、もう片方には新しいモデル（B）を使って、ビジネスの指標を比べる方法です。オフラインの評価では分からない「実際に使われてどうか」を確かめる、最後の判断材料になります。

ランダムに分ける単位は、基本はユーザーです。リクエストごとに分けると、同じ人が A と B を行き来して体験が混ざります。

サンプルサイズ：差が小さいほど、見分けるのに多くのユーザーが必要です。おおまかに、見つけたい差を半分にすると必要な人数は約4倍になります（必要な人数は、差の大きさの2乗に反比例するため）。始める前に、「どれくらいの差なら意味があるか（最小検出効果）」「基準の値（今の購入率など）」「有意水準（よく 5%）」「検出力（よく 80%）」から必要な人数を計算し、そこから期間を決めます。計算は統計のライブラリや、オンラインの計算機でできます。

オフラインの評価（過去のデータでの AUC など）が上がっても、A/B テストでビジネスの指標が動かないことはよくあります。原因を知っておくと、次に何を直すかが分かります。

多腕バンディットは、試しながら成績の良い案に配分を寄せていく方法です。「まだよく分からない案を試す（探索）」と「今いちばん良い案を使う（活用）」のバランスを、トンプソンサンプリングなどで自動で決めます。テスト中の損（悪い案を見せ続ける分）が小さいのが利点です。