機械学習システムの信頼性を数値化する論文What’s your ML test score A rubric for ML production systems で紹介した論文の続編があったので読んでみました。
- 注意)この翻訳記事は原著論文の著者陣からレビューはされていません
- Shunya Ueta, are providing a translation and abridgment, which has not been reviewed by the authors.
Change log
- 2021/02/03 - ML Test Score を簡単に計算できるGoogle Spread Sheets を公開
- 2020/06/24 - 著者の Eric Breck さんに連絡をし、抄訳の公開を快諾していただきました。ありがとうございます。 - 完全な citation 情報を追記しました。 - この翻訳記事が著者のレビューを受けていないことを追記しました。
Citation
Eric Breck, Shanqing Cai, Michael Salib,
. The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. In 2017 IEEE International Conference on Big Data (Big Data) (pp. 1123-1132). IEEE.
概要
大規模なオフラインの機械学習実験は注目されているが、反対にオンラインでの信頼性がある機械学習システムの開発は難しく、技術的負債が溜まりやすい
図1 では、左側が伝統的なシステムのテストとモニタリング、右側は、機械学習システムのテストとモニタリングである
機械学習システムのテストとモニタリングが複雑になる要因として、コードだけではなく、動的に決定されるデータの質とモデルの多種多様な設定に依存するからである
TL; DR;
-
機械学習システムの信頼性を評価する
28の実行可能なテスト項目とスコアリング方法を提案する。 -
Google 内部の調査では、調査対象の 80%のチームが 28 のテスト項目の１つさえも行っていなかった。。(エンジニアリングに長けている Google 内部でさえも十分に行われてはいない)
-
もし手持ちの機械学習システムの ML Test Score を計算したい場合は、簡単に計算可能な Google Spread Sheets を公開します。
- 閲覧権限のみ与えているので、File-> Make a copy を選択して手元にコピーしてお使いください。
- ML Test Score template - Googpe Spread Sheets
TEST FOR DATA AND FEATURES
- Data 1: 期待する特徴量は全てスキーマで管理され、読み込み可能か?
- How: このスキーマは学習データの統計値を計算することに有用である。これらを可視化することで事前のバイアスを検知したり、Fasets1などのツールを用いた統計値の可視化もとても有用である
- Data 2: 全ての特徴量は有用か?
- 全ての特徴量は、追加すればするほどコストになる。独立した全ての特徴量は有用だろうか?
- How: 特徴量削除や目的変数と特徴量の相関などを見てみよう
- Data 3: 特徴量のコストは高くないか?
- How: 推論速度や RAM の使用率だけを見るのではなく、その特徴量に関連するデータの依存先や不安定性なども考慮する
- Data 4: 特徴量は要件に準拠しているか?
- 一般的には、機械学習システムにデータが送られる際には単一のリソースからデータを取得することが前提ですが、実験の際には知らずしらずのうちに精度を向上させるために特徴量をどんどん追加してしまいがちである
- How: 学習データのリソースがプロダクション環境から逸脱していないか監視する
- Data 5: データパイプラインは適切なプライバシーコントロールはされているか?
- How: データパイプライン構築の時には権限管理を厳密に行う
- Data 6: 新しい特徴量は素早く追加可能か?
- 新しいアイデアを素早く試せるチームは強い。世界規模、またはトラフィックが多い機械学習システムでも、1-2 ヶ月で新しい機能を追加することが可能である
の。Data 5 と相反する形にはなっている。
- Data 7: 全ての特徴量生成コードはテストされているか?
- 特徴量生成のコードは一見シンプルでユニットテストなどは必要そうに見えないかもしれないが、ここで発生するバグは発見することはとても難しい
TESTS FOR MODEL DEVELOPMENT
- Model 1: 全てのモデルはレビューされ、リポジトリに格納されている
- バージョン管理され、過去の実験との比較や再現実験などを可能にする
- Model 2: オフラインの疑似指標はオンラインメトリクスに相関しているか?
- How: A/B テストで意図的にモデルのスコアを劣化させてテストする
- Model 3: 全てのハイパーパラメータはチューニングされているか?
- 学習率・NN の層の数・次元数など数多くのハイパーパラメータがあり、予測精度に大きな影響を与える
- How: グリッドサーチや確率的なパラメータチューニングをおこなう
- Model 4: 古くなった(陳腐)モデルの影響は把握されているか?
- 例えば学習パイプラインが失敗し、更新されなかったモデルをここで古びたモデルと呼ぶ。モデルが更新されないことでどれくらい予測精度に影響を与えるか理解することで、再学習の適切な期間も決定できる。ほとんどのモデルは外部世界の要因により更新しなければならない。
- How: 小規模な A/B テストにより、新モデルと旧モデルを比較することでモデルのリフレッシュネスがどれくらい重要か計測することができる
- Model 5: 単純なモデルは必ずしも良くはない
- 少ない特徴量で単純な線形モデルがベースラインとして使われることがあるが、パイプライン構築のコストとその利益のトレードオフを常に考えていくべきである
- Model 6: 全ての重要なデータの部分集合でもモデルの質は十分なものになっているか?
- How: 多様な基準でデータを抜き出し、モデルの精度が変化しないかを確認する。例えば、時間帯や性別、年齢などの基準でデータを抜き出してもモデルの精度は同一か？
- Model 7: 包括性を考慮したモデルになっているか?
- 機械学習システムでは Fairness などが最近課題となっている。例えば、Bolukbasi らは文字埋め込みにおいて性別の差が予測において不適切な影響を発生させていることがわかった。
- How: 特定のグループ間で、実験をおこない結果が異なっていないか確認する。
TESTS FOR ML INFRASTRUCTURE
- Infra 1: 学習は再現性があるか?
- 理想としては、同じデータで学習を行った際には同じ結果が期待される。しかし不幸なことに非凸な問題(e.g. Deep Learning)などの学習は再現不可能なことがめずらしくない。シードの固定などをしても必ず再現性が担保されるわけでもない
- How: モデルのアンサンブルなどは有効である
- Infra 2: モデルの仕様はユニットテストされているか?
- ユニットテストは外部依存性を排除し、素早く実行可能でなければならない。だが実際はモデルの学習には非常に時間がかかり、計算機資源も必須である
- How: まずモデルのテストはAPIとしてのテストとアルゴリズムとして正しいかのテストの２つに分解して考える。(著者が執筆当時 OSS としての公開を計画中らしい…DATA VALIDATION FOR MACHINE LEARNING を指しているのだろうか？)
- 学習データをフルに活用したモデルの開発は律速になりがちである。そのためベストプラクティスとしては、ランダムに生成した入力データに対して、一つのステップで勾配降下法が上手く動いているかを確認するなどがある。また、モデルの学習過程でチェックポイントを作成しておくことで、学習ジョブが死んだとしても復旧可能になる
- 機械学習アルゴリズムが正しいかどうかのテストとして、例えばアルゴリズムの特定の部分の計算が正しく実行されているかを確認することができます。別の解決策としては、数回の反復のみを計算し損失関数が減少しているかどうかを確認する。
- また、モデルのテストを行う際には黄金のテストを避けるべきである。例えば、部分的に学習したモデルと前回のモデルの結果を比較するのはメンテナンスすることが非常に難しい。そして上記のテストはテストが失敗した時に洞察をすることが難しい。
- Infra 3: 全ての機械学習パイプラインは結合テストされているか?
- 完璧な機械学習パイプラインとは主に、学習データの構築 → 特徴生成 → モデル学習 → モデル検証 → サービングシステムへのデプロイから構成される。単一のソフトウェアエンジニアチームは、特定の箇所にのみ集中して開発を行う。そして、その開発によりどこかが壊れパイプライン全体が動かなくなることも珍しくはない。そのため、完全に自動化された結合テストを定常的に行うべきである。
- How: 結合テストをモデルまたはサービングのリリース前に CI として実行する。結合テスト全体がうまく言っているかを目的として高速な結合テストのために、部分的な学習データやシンプルなデータを扱うことを推奨する。また、別途プロダクションに限りなく近づけたミラーリング環境での結合テストも行う
- Infra 4: モデルの品質は、サービングする前に検証されているか?
- この検証段階で、モデルの受け入れ判定を行う
- How: 同じ検証データを用いて、モデル間の比較を行う。
- Infra 5: 一つのサンプルに対する学習、サービングの段階ごとの計算をデバッグ可能か?
- モデルの学習を段階ごとに観測する。特定のツールを使うことで観測可能である。例: TensorFlow Debugger
- Infra 6: カナリーリリースによって、モデルはプロダクション環境下で検証されているか?
- オフラインテストをいくら広範囲に行ったとしても、プロダクション環境下でのパフォーマンスを保証してくれない。現実世界では、予測不可能な問題が起きる。そのため、常にプロダクション環境下への新モデルのリリースはリスクを生じる。
- 一つの再帰的な問題として、カナリーはモデルの生成物とインフラのミスマッチを把握するのに有用である。モデリングのコードは、サービングのコードと比較して高頻度に変更される。新しいモデリングのコードで、サービングのシステムが動かないことは避けておきたい
- 
- 図 2 で示すように、Day1 のモデルから Day2 のモデルに更新された際に、そのオペレーターに対応していないサービングシステムが混在することもあり得る
- How: ミスマッチの問題を解決するために、一つの取組みとしてプロダクション環境下のサービングのバイナリとインフラに対して新モデルの読み込みを行い、予測ができるかの検証を行う。また一般的にモデルのマイグレーションはカナリリリースにより、新モデルの挙動が問題ないことを確認し、徐々に新モデルの比率を上げて、旧モデルを減らす。そして最終的に旧モデルをゼロにすることでマイグレーションを完了させる
- Infra 7: モデルは、安全かつ高速に前のバージョンに戻せるか?
- モデルのロールバックが可能かどうかは主にインシデント発生時の対応方法として有用である。モデルのロールバックは、平常時にも常日頃から備えておくべきである。
MONITORING TESTS FOR ML
あなたの機械学習システムが、リリース時に正しく動いたかどうかだけではなく、機械学習モデルが正常に稼働し続けることを把握することは非常に重要です。
標準的なアプローチとしては、ダッシュボードを作成し、関連するグラフや統計情報を可視化し、確認できるようにします。そして、その値が大きく動いたときには自動的に担当のチームにアラートが飛ぶようにします。
機械学習システムでは、サービングシステム、学習パイプライン、入力データの監視が非常に重要です。
また、インシデントの対応として機械学習システムが主に行うのはシステムのロールバックではなく、モデルのロールバックである。
- Monitor 1. 依存先が変化した結果は通知されるか?
- 機械学習システムは、入力データに強く依存する。学習データや推論時に入力データの傾向や使用が変化した際にも把握しておかないといけない
- How: 開発者チームは、モデルが使用するデータを生み出す依存先をリストアップし依存先に対するアナウンスなどを常に把握しておく。また、依存先のオーナーは、そのデータが機械学習システムに使われていることを知っておく必要もある。
- Monitor 2. 学習とサービングの入力時、両者は普遍性を保っているか？
- 学習データとサービングデータの一貫性を監視することは非常に重要です。機械学習のモデルの振る舞いの異変を把握することは難しいですが、データの普遍性が保たれていないことはまず第一にできる取り組みです。
- How: スキーマ管理されたデータを取り扱うようにし、その監視も行う。例えば、TensorFlow Data Validation では、スキーマのズレを監視することが可能である。また、このアラートの閾値は適切に設定しないと、Google 内の機械学習システム開発者チームはこのアラートを無視をするようになった逸話もある2。
- Monitor 3. 学習時とサービング時の特徴量計算は同一か？
- 同一の入力に対しても学習時と推論時の一貫性を保っていない、training / serving skewと呼ばれる問題がある。
- 
- How: この問題を解決するためには、実際のサービングシステムへのトラフィックを保管することが肝心である。サービングシステムへの入力データを保管することで、特徴量生成の比較も容易に行うことができる。確認すべき項目として、特徴量は、必ず学習時と推論時は同一でなければならない。
- 別のアプローチとしては、学習データの統計値と推論時に入力されたデータの統計値を比較することも有用なアプローチである。典型的な統計値としては、最大・最小・平均・欠損値の割合などが挙げられる。
- Monitor 4. モデルは極端に古い状態ではないか？
- Model 4でも述べたが、モデルの古さは予測精度において重要な指標である。なので、プロダクションで運用されているモデルがどれくらい古いかは監視する必要しておこう。以外にも更新頻度の低いモデルはメンテナンスコストが高い。想像してみよう、例えば一人のエンジニアが手作業で年に 1,2 回再学習されるモデルがあったとする。もしそのエンジニアがチームを離れることになれば、このモデルの再学習の再現は困難になるだろう。たとえ、ドキュメントなどを残していても時間経過により、それも意味を成さなくなる。
- How: 週次、もしくはもっと頻繁にモデルの再学習パイプラインを実行する。プロダクション環境下のモデルの古さは常に監視し、どのレベルの古さが予測精度に影響を与えるかを基準にアラート条件を策定する。
- Monitor 5. モデルは数値的に安定しているか?
- How: モデルから NaN や無限の値が出力されていないか監視する。
- Monitor 6. このモデルは学習速度や、サービングレイテンシー、スループット、RAM 使用率に影響を与えるようなメモリリークやデグレーションなどは発生していないか?
- DNN の学習は、計算コストが非常に高く計算機コストの増大はスケーリングのボトルネックにもなる。
- How: 計算使用の監視は、一般的なモニタリングでも重要な指標です。コードのコンポーネントやバージョンごとにモニタリングをするだけではなく、データやモデルも軸にした監視を行う。
- Monitor 7. サービングシステムへの予測品質は測定可能か？
- How: データの変更や設定の変更などによる予測品質が低下していないことを確認するためのいくつかの方法を説明する
- 例えば、特定のタスクなどでは、データのラベルが即座に手に入る（広告クリックなど）。このラベルデータを使って、実際のサービングシステムの予測性能をほぼリアルタイムに算出可能である。このようにヒトを介したモデルの評価機構などは Human In The Loop ともよばれる。
- この仕組によって、定期的に学習のための新たなデータが取得できるようになる。
文化の変化
技術的負債は定量化が難しい。また負債を返済するための優先順位付けもやどれくらい改善されたかの測定も難しい。ここで提案した試験項目は定量化した機械学習のテストスコアを提供する。これは、測定可能かつ改善可能なものである。
この指標は、機械学習システムの開発者はどこを改善すればより信頼性のある機械学習システムを作ることができるかのガイドラインとなる。この方針は Google の Test Cerfiedの仕組みを基に発案され、信頼性向上のためのはしごを提供する。
- ML Test Score の計算方法
- 手動で確認され、ドキュメントに結果をまとめ配布されている場合は、0.5ポイント
- 反復的に自動的に検証されていたら1.0ポイント
- 4 つの章で、独立して各ポイントの合計を計算
- 各章のスコアを集計し、最小の値を最終的な ML Test Score とする
なぜ最小の値を選択する理由として、全ての章が重要であり、すべての章を考慮したスコアを計算するべきだからである。また全てのテスト項目は同一の価値を持つ。
以下に、ML Test Score からその機械学習システムがどのレベルに達しているかの説明を示す
| ポイント | 説明 |
| -------- | :--------------------------------------------------------------------------------------------: |
| 0 | プロダクションレベルというよりも、研究プロジェクトの一種 |
| (0,1] | 総合的にテストはされていないが、可能な限り信頼性向上に努めている |
| (1,2] | 基礎的なプロジェクトの要求事項は通過した。しかし、信頼性向上のためのさらなる投資が必要とされる |
| (2,3] | 適切なテストがされている、だが更に自動化の余地が残っている |
| (3,5] | 信頼性の高い自動化されたテストとモニタリングレベル。ミッションクリティカルな状況でも問題はない |
| >5 | 卓越したレベルの機械学習システム |
Rubic の現実世界の機械学習システムへの適用と実際に起きたこと
我々は Google 内部の機械学習に携わるチームのために ML Test Score Certified Program を開発した。
36 チームにインタビューや Rubric を通じた評価を行い、その統計値を以下の図にまとめた。
Rubric の重要性
Google 内の事例では、グローバル・サービスがローカライズされた際に、特定の単一の国に対して粗悪な予測を提供していないかどうかのチェックリストとして役立ったり、各機械学習システムの評価の標準化の普及に役立った。最終的に ML Test Score が普及をしていく中で、あるチームは training / serving skew の危険性を認識し、特徴生成の部分にテストを実施したり、手動テストを自動テストに切り替えていったりしていきました。
依存性の問題
機械学習システムのデータの依存性の問題として、開発チームが Upstream サービスから提供されるデータの完全なる理解のオーナーシップを失ってしまう傾向もあります。
フレームワークの重要性
結合テストは、サービングシステムには適合されていることが多いが、学習パイプラインに適用されていることは稀である。それは、アドホックなスクリプトや手動実行に依存している部分が多いからである。
モデルのカナリリリース(Infra 6) は、頻繁に多くのチームで既に実装されていた。だがカナリリリースに面白い２つの興味深い問題が浮き彫りになった。
-
カナリリリースにより、サービングできない問題や数値的にモデルが安定していないなど多くの問題が見つかるが、実際には単体テストや結合テストで発見することが可能である
-
既存のフレームワークでカナリリリースを実行しているチームは、好意的な印象をカナリリリースに対してもっているが、独自実装が必要だったチームは二度とやりたくないと言っていた
おそらく、一番重要かつ、最も実装されていないテストの一つがtraining / serving skew (Moniro 3)だ。実際この問題は非常に発見が難しいが、TFX などのフレームワークによりこの課題を解決可能である。
Rublic の評価検証
Google 内で開発チームに対して、この指標が有用かそうでないかの評価を行った。
興味深い結果として、画像や音声のみを扱うチームは Data の章は多くの部分が適切ではないと答えた。
だが、人的検査やLIMEなどの解析は音声・画像のみのデータでも重要だと確認できた。
例えば、そのような検査は分布の不均衡や不確かな影響を受けている学習データを明らかにした。
教師あり学習は、ラベル付きデータを必要とする。しかし、特定のドメインではそもそもデータセットが手に入らなかったり、取得コストが非常に高い。
あるグループはとても巨大で多様性があるデータセットを所有しており、人力でラベルを付けていくことは不可能に見えた。彼らは、ヒューリスティックなシステムを構築して、それを活用して機械学習モデルを構築しました。（機械学習の専門家はこの学習モデルは狂っていてうまくいくわけがないと言っていました）
実際にヒトが評価を行ってみるとヒューリスティックシステムの性能は一貫して良いが、そこから学習した機械学習システムのほうが更に良かった。しかし、ここで基本的なヒューリスティックシステムに対する指標を我々が用意できていないことが露呈した。ラベリングコストが高いことは、学習モデルの定量的評価も難しいことを意味し、Model4, Infra 4の検査も困難になる。