AutoMLを学ぶ (Japanese Edition)

第5部 事例 研究

第1章では、かつて私のチームが数ヶ月かけて完了させていた機械学習プロジェクトが、自動化によって今では数日、あるいは数時間で完了できるようになったことを紹介した。第2章では、AutoMLが学術的なプロトタイプからエンタープライズ対応プラットフォームへと進化する過程をたどり、AutoGluonやVertex AIといったツールが可能性をどのように変革したかを検証した。第3章では、その背後にある洗練されたパイプラインアーキテクチャ――この高速化を可能にする自動特徴量エンジニアリング、ハイパーパラメータ最適化、アンサンブル手法――を明らかにした。

しかし、AutoMLの仕組みを理解することと、本番環境でそれを成功裏にデプロイすることの間には隔たりがある。それは私が身をもって学んだ隔たりだ。

3年前、私は大手金融機関の不正検知プロジェクトの救済に呼ばれた。データサイエンスチームはJupyterノートブック上で見事なモデルを構築していた――精度98.7％、洗練されたアンサンブルアーキテクチャ、印象的な交差検証スコア。誰もが期待に胸を膨らませていた。そして、彼らはそれを本番環境にデプロイした。

48時間以内に、システムは4万7000件の正当なトランザクションを不正としてフラグを立てた。カスタマーサービスは対応に追われた。不正対策チームは誤検知の処理に溺れていた。そして、モデルの実際の不正検知率は？惨憺たる73％で、置き換えるはずだったルールベースのシステムをはるかに下回っていた。プロジェクトは、打ち切りまであと数日というところだった。

何が間違っていたのか？

モデルは時系列順のデータではなく、ランダムにシャッフルされたデータで学習されていたため、データリークが作成され、オフラインでの性能が過大評価されていたのだ。バッチ処理では見事に機能した特徴量も、リアルタイムの意思決定に必要な100ミリ秒の時間ウィンドウ内では計算できなかった。 不正率が0.08%である以上、98.7%という精度メトリックは無意味だった。彼らは精度ではなく、PR-AUCを最適化すべきだったのだ。そして、モデルのドリフトや自動化による再学習を計画していた者は誰もいなかった。

「Jupyter上では動く」と「本番環境で動く」との間のギャップが、またしても犠牲者を出したのだ。

本番環境におけるAutoMLの現実

本書を通じて、AutoMLが約束するもの――機械学習の民主化、開発の加速、そして煩雑なタスクの自動化――について論じてきた。これらはすべて事実だ。しかし、本番環境には教科書ではめったに言及されない制約が加わる。

妥協の許されない時間的制約

その不正検知システムは、100ミリ秒以内に予測結果を返さなければならない。150ミリ秒でも200ミリ秒でもダメだ。この期限を逃せば、トランザクションはタイムアウトとなる。顧客体験が損なわれる。AutoMLの自動ハイパーパラメータ調整は素晴らしいが、その結果得られたアンサンブルが本番システムでは遅すぎるようでは意味がない。

チュートリアルには決して登場しないデータ品質の問題

練習に用いるUCIデータセットは、クリーンで完全、かつ一貫性がある。実稼働データはどうだろうか？顧客がフィンガープリンティングをブロックしているため、デバイスIDの15%が欠落している。47のタイムゾーンにまたがるタイムスタンプが含まれており、夏時間の扱いが非一貫性がある。調査が急がれることもあるため、正確性がわずか60%しかない不正ラベルも含まれている。 ...