Machine Learning (SysML). https://mlsys.org/Conferences/2019/doc/2019/167.pdf . 2019.
読み手のコンテキスト
現職で機械学習予測モデルをプロダクトに投入する様になって3年程経った。そうもなると開発時に想定していた訓練データの分布と現状の分布が乖離して、予測の動作不良を引き起すケースがしばしば見られる様になった。明らかな予測の不具合として目立っていなくとも性能が落ちている部分はもっとあるはずで、これに早く気づいて対応したいモチベーションがある。かつ運用専任メンバーはいないので、できるだけ運用は手を抜きたい。
概要
著者らはData Validationシステムを開発した。これはGoogleで稼動中のMLプラットフォーム(TFX)にデプロイされており数百のプロダクトで毎日利用されている。論文の構成はData Validationシステムを構成する3つのコンポーネントであるSingle-batch validation・Inter-batch validation・Model testingと、それぞれが解決できるデータの異常パターンと実装した提案手法の解説。最後にGoogleにおける利用状況と実際のサービスにおける検出例 (ケーススタディ) の紹介。
新規性および貢献
MLコンテキストに適用できるData Validationの手法について提案した。
Data Validationはおなじみの概念 (例えば Databaseの分野では) であるが、ML Pipelineの文脈で既存の手法をそのまま適用する事ができない。例えばデータの生成元とMLパイプラインが分離されているので、流れてくるデータを元にschemaを決める事になる。Databaseの世界では先にschemaを決めるので順序が逆。またカイ二乗検定 (chi-square test)の様な手法はMLパイプラインが扱うスケールのデータでは敏感すぎる。よって既存のData Validationを見直してMLコンテキストにマッチする手法を開発した。
Data ValidationはTFXの設定に基づいて開発されたが、別のシステムでも利用可能な様に提案手法をOSSライブラリとして実装もした。
Single-Batch Validation
一度の訓練に利用される訓練データのvalidation。人々は訓練データに対してstableであり続ける何らかの特性を期待している。そのためexpert domain knowledgeによって与えられるデータの特性からの乖離を異常とみなす。これを検出するためにスキーマ定義によるvalidationを開発した。
例えばあるフィールドの出現しうるカテゴリ値を定義できたりする。
ただしMLモデルは数千の素性を利用するため、人がスキーマ定義をゼロから作るのは現実的ではない。この問題を緩和するのに、スキーマの初期バージョンをデータから作成する機能を用意した。バリデーションエラーとなるデータが見つかった時にはスキーマの変更差分も自動で生成する。
Inter-Batch Validation
Concept-Driftの様な一回分の訓練データだけで判断できないタイプのエラーを検出する仕組み。エラーの例として次のパターンを挙げている。
- Feature Skew
- 例えば訓練時の前処理と推論時の前処理の差から生まれる。訓練時の前処理と推論時の前処理では求められる性能特性が異なるので、別のコードが使われる。そのため、片方だけ修正してしまうといった事が発生する。
- Distribution Skew
- 時間経過による分布の変化
- Scoring/Serving Skew
- 多く配信された広告データはサンプルが多いが、少なく配信された広告はデータ少ない
- MLシステム自身によって発生させたバイアス
これらのエラーを検知するには各バッチ毎に訓練データセット同士の分布の距離をみれば良い。これは分布間の距離を定量的に求めるメトリクスに依存する。統計的検定やKL-Divergenceは最初の一歩となる、しかし値の解釈や閾値の設定が難しかったりする。統計的検定はサンプルサイズが大きいとsensitiveになりすぎる。よって実際に使っているのは分布pとqの距離を次の式で定義したものである。
i は "each value i" とあるから各カテゴリだろうか (自分の理解があやしい)。カテゴリ値ごとの出現率の差なので非常に理解しやすく調整が容易。
Model Unit Testing
例えば前処理で対数変換をしている時、その前処理コードは暗黙的に訓練・予測データに正の値を期待している事になる。よってこの暗黙的な期待が満たされない時にコードはクラッシュしてしまう。推論時にクラッシュしたらサービスに影響が出てしまう。
このエラーに気づける仕組みとして前述のスキーマ定義を用いた fuzz testing アプローチを採用した。Single-Batch Validationで作成したスキーマ定義を基にデータを生成して学習コードを実行する。こうする事でスキーマ定義に現われていない暗黙の期待を洗い出す事ができる。(クラッシュしたらわかる)
Empirical Validation
デプロイしたValidationの利用状況。表1がわかりやすかった。
感想
正に自分が直面している課題を解決する内容だったので先人に感謝。
データエラーの例が生々しくて良かった。思いあたるフシがありすぎて「推論時と訓練時の前処理が別のコードで動いていて片方だけ直してしまうだと……うっ頭が」という状態で読んだ。しかし他の会社でも同じ事が起きているんだなと若干ほっとした。
次はOSS実装版のTensorflow Data Validationを触ってみようと思います。
