機械学習システムの評価

はじめに

機械学習システムが中核を担い、信頼性が重要になっている現在、信頼性を向上させ，技術的負債を減らし，長期的な保守コストを削減するためのテストとモニタリング戦略は重要です。 しかし、何を、どのくらいテストすればよいか、分からないまま進むのは難しいため、ガイドラインとして利用可能なML Test Scoreの知名度を高め、活用できたらと思っています。The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction@Google Research

この論文は「オンラインで継続的に学習され，サーバ上で高速かつ低レイテンシの推論を実行する教師あり機械学習システム」に関心を持っており、特徴量が受信データのストリーミングログのような大量のデータから得られる場合を想定しています。ただ、このほとんどは，推論のためにクライアント側のシステムにプッシュされた，学習頻度の低いモデルのような他の形態の機械学習システムにも適用可能なはずです。

この記事では、ML Test Scoreのざっくり日本語訳し、機械学習システム開発者がカジュアルに評価&整備可能にすることにあります。 もちろんですが、これ自体がビジネスを押し除けるほど優先度の高いものだとは思いません。ビジネスのフェーズに合わせて、適切なレベルになっているかの評価に使えることを願います。

ML Test Score

4つのセクションから構成され、各セクション7つの検査項目が提案されています。

• 特徴量とデータのテスト
• モデル開発のテスト
• 機械学習インフラのテスト
• 機械学習のモニタリングテスト

検査項目は、「結果を文書化して配布した上で、手動でテストを実行している場合」は、0.5ポイント、「テストを自動的に繰り返し実行するシステムがある場合」は1.0ポイントになります。 4つのセクションのポイントをそれぞれに合計し、4セクションのポイントの最小値が最終的なML Test Scoreです。4つのセクションすべてが重要であり，システムがスコアを上げるためにはすべてのセクションを考慮しなければならないため、最小値を選ぶようになっています。

以下が、ML Test Scoreにおける、機械学習システムがどのレベルに達しているかの説明です。

ポイント	説明
0	プロダクションシステムというよりは研究プロジェクト。
(0,1]	完全に未検証というわけではないが、信頼性に重大な穴がある可能性を考慮する必要がある。
(1,2]	基本的なプロダクションシステムへのファーストパスはあるが、追加投資が必要かもしれない。
(2,3]	合理的にテストされていますが、より多くのテストや手順が自動化される余地がある。
(3,5]	ミッションクリティカルなシステムに適した高度なレベルの自動化されたテストとモニタリングを行うことができる。
>5	卓越したレベルの自動化されたテストとモニタリングができる。

それでは具体的な項目をみていきましょう。

コピー用簡易版

Googleスプレッドシートも用意したので、さくっと使いたい場合には、コピーしてお使いください。

セクション	テスト
特徴量とデータ	特徴量の期待値はスキーマ管理される。
特徴量とデータ	すべての特徴量は有益である。
特徴量とデータ	特徴量のコストが高すぎるものはない。
特徴量とデータ	特徴量が要件に準拠している。
特徴量とデータ	データパイプラインに適切なプライバシーコントロールがある。
特徴量とデータ	新しい特徴量を迅速に追加できる。
特徴量とデータ	すべての入力特徴量のコードがテストされている。
モデル開発	モデル仕様がレビューされた後、本番投入される。
モデル開発	オフラインとオンラインのメトリクスが相関している。
モデル開発	すべてのハイパーパラメータが調整されている。
モデル開発	モデルの陳腐化の影響がわかっている。
モデル開発	より単純なモデルが良いわけではない。
モデル開発	モデルの品質は重要なデータスライス上で十分である。
モデル開発	モデルは，包含の考慮のためにテストされている。
機械学習インフラ	トレーニングは再現性があります。
機械学習インフラ	モデル仕様はユニットテストされている。
機械学習インフラ	機械学習パイプラインが統合テストされている。
機械学習インフラ	モデルの品質は提供前に検証されている。
機械学習インフラ	モデルはデバッガブルである。
機械学習インフラ	モデルはカナリアリリースされている。
機械学習インフラ	サービング中のモデルはロールバック可能である。
機械学習のモニタリング	依存関係の変更は通知される。
機械学習のモニタリング	入力データは不変である。
機械学習のモニタリング	トレーニングとサービングが普遍である。
機械学習のモニタリング	モデルはあまり古くない。
機械学習のモニタリング	モデルは数値的に安定している。
機械学習のモニタリング	計算性能が後退していない。
機械学習のモニタリング	予測の質が後退していない。

説明用詳細版

特徴量とデータのテスト

テスト	方法
特徴量の期待値はスキーマ管理していますか？データが直感に反しないか自動的にチェックするのに有効です。	訓練データから統計量を計算することから始め、ドメイン知識に基づいて適切に調整しましょう。また、アンカリングバイアスを避けるために、期待値を書き出すことから始めて、データと比較することも有用かもしれません。Facetsのような可視化ツールは、スキーマを生成するためにデータを分析するのに便利です。
すべての特徴量は有益ですか？各特徴量による付加的な予測力（他の特徴量とは独立した）の価値を理解しましょう。	相関係数を計算する、または、1、2この特徴量を持つモデルをトレーニングする、特徴量から1つだけを個別に削除したモデルのセットをトレーニングしてテストできます。
特徴量のコストが高すぎないですか？付加的な予測力が少ない特徴量は、過剰に計算資源コストとメンテナンスコストを増大します。	特徴量のコストを測定するには、追加された推論のレイテンシとRAMの使用量だけでなく、上流のデータ依存性や、その特徴量に依存することで発生する追加の不安定性も考慮してください。
特徴量は要件に準拠していますか？システムに入ってくるデータには利用可能性や即時性などの要件が課されます。	要件はプログラムで強制することで、運用中のすべてのモデルが適切に要件を遵守するようにします。
データパイプラインは適切にプライバシーコントロールされていますか？データに含まれる、個人を特定可能な情報の漏洩は深刻な影響を及ぼす可能性があります。	機密データに依存する新機能開発の際には、適切な処理ができるように十分な時間を確保してください。パイプラインデータへのアクセスが，生のユーザデータへのアクセスと同様に厳重に制御されていることをテストしてください。最後に，ユーザが要求したデータの削除が，機械学習の学習パイプライン内のデータや学習済みモデルに伝搬するかどうかをテストしてください。
新しい特徴量は迅速に追加できますか？機能のアイデアから本番稼動までの時間が早ければ早いほど、システムの改善と外部からの変更への対応の両方を迅速に行うことができます。
入力された特徴量のコードはすべてテストされていますか？特徴量のバグは一度データ生成プロセスに入ってしまうと、検出することは難しいため、テストは正しい動作，その品質維持に重要です。

モデル開発のテスト

テスト	方法
すべてのモデル仕様はコードレビューされ、バージョン管理されていますか？本番のインシデントに対応する場合、学習モデルを生成するために実行されたコードを正確に知ることは重要です。また、モデル仕様の適切なバージョン管理は、訓練を監査可能にし、再現性を向上させるのに役立ちます。
オフラインのプロキシメトリクスは、実際のオンラインのインパクトメトリクスと相関しますか？ユーザーに対するシステムのインパクトは、エンゲージメント、ユーザーの幸福度、収益などのメトリクスによって判断されますが、機械学習システムは、対数損失や二乗誤差などの損失メトリクスを最適化するように訓練されます。	オフライン/オンラインのメトリクスの関係は、意図的に劣化させたモデルを使用して、小規模なA/Bテストで測定することができます。
すべてのハイパーパラメータが調整されていますか？機械学習モデルの持つハイパーパラメータの値の選択は，予測品質に劇的な影響を与えることがあります。	グリッドサーチやより洗練された手法によって、予測品質を向上させるだけでなく隠れた信頼性の問題を発見することもできます。
古くなったモデルの影響は認知していますか？古くなったモデルが予測の質にどのように影響するかを理解することは、モデルをどのくらいの頻度で更新するかを決定するために必要です。	古くなったモデルを使って小規模なA/Bテストを行うことで影響を評価できます。
より単純なモデルとの比較は定期的に実施されていますか？特徴量の少ない線形モデルなど、単純なベースラインモデルに対して定期的にテストを行うことは、大規模なパイプラインの機能性を確認したり、より洗練された技術のコストと利益のトレードオフを評価したりするために効果的な戦略です。
モデルの品質は、すべての重要なデータスライスで十分ですか？興味のある特定の次元に沿ってデータセットをスライスすることで、モデル品質の詳細な理解を向上させることができます。スライスは、例えば、国別のユーザー、利用頻度別のユーザー、ジャンル別の映画など、質的に異なる振る舞いをする可能性のあるデータのサブセットを指します。スライスされたデータを調べることで、例えば、グローバルな精度が1%向上したが、ある国の精度が50%低下したなどのように、グローバルなサマリーメトリックによって隠された細かな品質問題を回避することができます。	モデルのリリーステストで、絶対的な閾値(例えば、スライスxのエラーが5%未満)や増分的な閾値(例えば、スライスxのエラーの変化が以前にリリースされたモデルと比較して1%未満)を課すことで品質の大きな低下を捉えることができます。
モデルは包括性（全ユーザに十分に役立つロバスト性）を考慮してテストされていますか？学習データセットにおける潜在的に見落とされていたバイアスが、より大きなシステムの動作に影響を与える可能性があります。	異なるユーザーグループで条件付けされたときに予測出力が大きく異なるかどうかを判断するための予測のスライスなどが実行可能です。

機械学習インフラのテスト

テスト	方法
トレーニングに再現性がありますか？理想的には、同じデータで2回のトレーニングを行うと、2つの同一のモデルが生成されます。	決定論的なトレーニングは、システム全体の推論を劇的に単純化し、モニタリングとデバッグを支援することができます。例えば、新旧の特徴量生成コードが同一のモデルに訓練されることを検証することで、リファクタリングが正しい確信を得ることができます。残念ながら、ディープラーニングやランダムフォレストのような非凸法を使用している場合は特に、モデルの学習は再現性がないことがよくあります。適切に乱数生成のシーディングを行ったとしても、初期化の順序を指定することができないため、モデルの異なる部分が異なる実行で異なる時間に初期化され、非決定性につながります。さらに、初期化が完全に決定論的である場合でも、単一のマシン上または分散システム上で複数のスレッドが実行された場合、学習データの順序が予測できない場合があり、これも非決定論の原因となります。非決定性を取り除く作業の他に、アンサンブルモデルが役立つこともあります。
モデル仕様書のコードはユニットテストされていますか？コードの誤りが学習後に明らかになる（学習の失敗やモデルの性能低下）と開発のループは遅くなります。	ランダムな入力データを生成し、勾配降下のシングルステップでモデルを訓練する単純なユニットテストは、多くの一般的なライブラリの間違いを検出するために非常に強力であり、結果として開発サイクルがはるかに速くなります。またチェックポイントを用意することで、訓練中にジョブがクラッシュした後、モデルが復元できます。機械学習アルゴリズムの新しい実装の正しさをテストする方法は、１、アルゴリズムの特定の部分計算が正しいこと、２、ユニットテストでは完了するまで訓練を行わず、数回の反復訓練だけを行い、訓練によって損失が減少すること、３、モデルがオーバーフィットすること、を検証するなどがあります。モデルをテストするときは、モデルを部分的に訓練して、以前に生成されたモデルと結果を比較するテストは維持が難しいため避けるように注意しなければなりません。
機械学習パイプライン全体は統合テストされていますか？パイプラインは，通常，トレーニングデータの組み立て，特徴量の生成，モデルのトレーニング，モデルの検証，サービングシステムへの展開で構成されています。各段階では後続の段階に影響を与えるエラーが発生する可能性があるため、定期的に実行され、パイプライン全体を演習し、データとコードが各ステージを正常に通過し、結果として得られるモデルが正常に動作することを検証する、完全自動化されたテストが必要です。	統合テストは、モデルやサーバーの新規リリース時と同様に、継続的に実行する必要があります。トレーニングデータのサブセットやよりシンプルなモデルを使用して統合テストを高速に実行すると、開発者へのフィードバックがより速くなりますが、本番環境をより忠実に再現したセットアップでは、あまり頻繁に実行されない長時間の実行バージョンでも、開発者へのフィードバックが得られます。
モデルの品質は提供前に検証されますか？モデルが訓練された後、実際にトラフィックに影響を与える前に、自動化されたシステムはそれを検査し、その品質が十分であることを検証する必要があります。	新しいバージョンでの突然の品質低下のテストには、ゆるい閾値を設定し、検証セットの予測値と比較することが有用です。多くのバージョンにわたって品質がゆっくりと低下するかどうかをテストするには、より厳しい閾値を設定しながら、予測値を以前のバージョンのモデルと比較することが有用です。
モデルは、単一の例での訓練や推論のステップバイステップの計算を観察することで、デバッグ可能ですか？モデルが奇妙な振る舞いをしているケースを見つけたとき、その理由を解明するのはどれほど難しいでしょうか？モデルに1つの例を与えて、モデルの各段階（ニューラルネットワークの各内部ノードなど）を通して計算を調査するための簡単で十分に文書化されたプロセスはありますか？
モデルはカナリアリリースでテストされますか？実世界では、過去のデータの有用性を制限するような重大な非定常性やその他の問題が存在することが多いため、オフラインでのテストがどんなに広範であっても、それ自体でモデルが本番環境で良好に動作することを保証することはできません。カナリアリングがキャッチするのに役立つ反復的な問題の1つは、モデルのアーティファクトと提供インフラストラクチャ間のミスマッチです。モデリングコードは提供コードよりも頻繁に変更されることがあるので、古い提供システムが新しいコードで訓練されたモデルを提供できなくなる危険性があります。	不一致の問題を緩和する方法として、モデルが本番サーバのバイナリに正常にロードされ、本番の入力データに対する推論が成功するかどうかをテストすることがあります。
モデルは迅速かつ安全に前のサービングバージョンにロールバックできますか？ロールバックは緊急時の手順であるため，オペレータは緊急時以外は通常通りに行うことを練習しておくべきです。

機械学習のモニタリングテスト

テスト	方法
依存関係の変化は通知されますか？機械学習システムは，通常，他のシステムからのデータを幅広く利用して，有用な特徴量を生成しています。ソースシステムの部分的な停止、バージョンアップグレード、その他の変更は、必ずしも他のモニタリングのトリガーとなるほど奇妙な値を生成しなくても、特徴の意味を根本的に変更し、モデルの学習や推論を混乱させる可能性があります。	チームがすべての依存関係のアナウンスリストを購読し、読んでいることを確認し、依存チームがあなたのチームがデータを使用していることを知っていることを確認してください。
トレーニングやサービングの入力でデータの不変性が保持されますか？学習モデルの内部動作を効果的に監視して正しさを確認することは難しいかもしれませんが、入力データはより透明性の高いものでなければなりません。	構築したスキーマを用いて，データがスキーマと一致しているかどうかを測定し，データが大きく乖離している場合には警告を発します。実際には、警告の閾値を慎重に調整することで、偽陽性率と偽陰性率のバランスをとることができ、警告が有用で実用的なものであり続けることができます。
トレーニング特徴量とサービング特徴量は普遍性を持つか？実際に入力特徴量を生成するコードパスは、トレーニング時と推論時で異なる場合があります。「トレーニング/サービングスキュー」と呼ばれ、検出して回避するためには慎重な監視が必要です。	これを測定するには、実際のサービングトラフィックのサンプルをログに記録することが重要です。将来のトレーニングデータとしてサービング入力を使用するシステムでは、サービング時に各例に識別子を追加することで、直接比較が可能になります（同じ例のトレーニング時とサービング時では、特徴量は完全に同一でなければなりません）。ここで監視すべき重要なメトリクスは、スキューを示す特徴量の数と、各スキューを示す各特徴量についてスキューを示す例の数です。もう1つのアプローチは、訓練特徴量とサンプリングされた提供特徴量の分布統計量を計算し、それらが一致することを確認することです。典型的な統計量には、最小値、最大値、または平均値、欠落した値の割合などがあります。ここでも、これらのメトリクスでアラートを出すための閾値は、実用的な応答のために十分に低い偽陽性率を確実にするために慎重に調整されなければなりません。
モデルが古くなりすぎていませんか？警告を出すのに十分な問題のある古さを決定するためのガイドとして、事前の測定を使用して、プロダクションシステムがどれくらい古いか（年齢）を監視することをお勧めします。驚くべきことに、頻繁に更新されないモデルにはメンテナンスコストがかかります。特定のエンジニアが年に1～2回、手動で再トレーニングを行うモデルを想像してみてください。そのエンジニアがチームを離れた場合、このプロセスを再現するのは難しいかもしれません。慎重に書かれた指示でさえ、このような時間軸では陳腐化したり、不正確になったりするかもしれません。	定期的に再トレーニングを行うモデル（例えば、毎週またはそれ以上の頻度で）の場合、最も分かりやすい指標は、プロダクションモデルの年齢です。どこで失速が発生したかを迅速に判断し、適切に対応するために、トレーニングパイプラインの各段階でモデルの年齢を測定することも重要です。再訓練の頻度が低いモデルであっても、特徴を生成するためにデータ集約やその他のプロセスに依存していることが多く、それ自体が古くなってしまうことがあります。
モデルは数値的に安定していますか？無効な数値やありえない数値は、明示的なエラーをトリガーしなくても、モデルのトレーニング中に発生する可能性があり、それらが発生したことを知ることで、問題の診断を迅速に行うことができます。	NaNや無限大の初期発生を明示的に監視します。重みとゼロ値を返すレイヤー内のReLUユニットの割合に妥当な範囲を設定し、これらが適切な閾値を超えた場合にトレーニング中にアラートをトリガーします。
モデルは、トレーニング速度、サービングレイテンシー、スループット、RAM使用量において、劇的な、またはスローリーク回帰を生じていますか？機械学習システムの計算性能（予測品質とは対照的に）は、しばしばスケールでの重要な関心事です。ディープニューラルネットワークは，学習や推論の実行に時間がかかり，特徴が交差する広い線形モデルは多くのメモリを使用します。データ、特徴、モデリング、または基礎となる計算ライブラリやインフラストラクチャの変更によるパフォーマンスの変化に迅速に対応することは、パフォーマンスの高いシステムを維持するために非常に重要です。	計算性能を測定することは、あらゆるモニタリングの標準的な部分ですが、コードのバージョンやコンポーネントだけでなく、データやモデルのバージョンごとにパフォーマンスメトリクスをスライスすることも有用です。計算性能の低下は、劇的な変化（以前のバージョンの性能との比較やタイムスライスが検出に役立ちます）やスローリーク（事前に設定した警告閾値が検出に役立ちます）で発生する可能性があります。
モデルは提供されたデータ上で予測品質の回帰を生じていますか？検証データは常に実際のサービング入力データよりも古いので、サービングに移行する前に検証データでモデルの品質を測定することは、実際のサービング入力の品質メトリクスの推定に過ぎません。しかし、提供時間の直後でも正しいラベルを知ることができるとは限らないため、品質測定は困難です。	データの変更やコードパスの違いなどによるサービス予測の品質の低下がないことを確認するためのいくつかのオプションを以下に示します。１、予測における統計的バイアス、すなわち、特定のデータのスライスにおける予測の平均を測定します。２、予測が行われた直後または直後にラベルが実際に利用可能になるタスクの場合、ほぼリアルタイムで予測の質を判断し、問題を素早く特定することができます。３、人間の評価者がログに手動でラベルを付けることで、提供された予測を検証するために持ち出すことができます。このような測定を行うには、許容できる品質の閾値を設定しなければなりません（例えば、初期システムの立ち上げ時の品質の境界線に基づいて）。計算性能と同様に、予測品質の劇的回帰とスローリーク回帰の両方を監視することが重要です。

おわりに

この記事では、ML Test Scoreを紹介しました。具体的にやってみると、結果は、ML Test Score=1.5で「基本的なプロダクションシステムへのファーストパスはあるが、追加投資が必要かもしれない。」と言った温度感のスコアでした。機械学習インフラ、モニタリングテストが重いので、ぜひ改善して「合理的にテストされていますが、より多くのテストや手順が自動化される余地がある。」状態に持っていきたいなと思える評価になりました。ぜひ皆さんお試しください。