Azure Machine Learning を使用したモデルモニタリング

この記事では、Azure Machine Learning でのモデル監視、監視できるシグナルとメトリック、モデル監視を使用するために推奨されるプラクティスについて説明します。

モデルモニタリングのケース

モデル、機械学習のエンドツーエンド ライフサイクルにおける最後のステップです。 この手順では、運用環境でのモデルのパフォーマンスを追跡し、データ サイエンスと運用の両方の観点からパフォーマンスを理解することを目的としています。

従来のソフトウェア システムとは異なり、機械学習システムの動作は、コードで指定されたルールだけでなく、データから学習されたモデルの動作によっても制御されます。 そのため、データ分布の変化、トレーニングとサービスのスキュー、データ品質の問題、環境の変化、コンシューマーの行動の変化はすべて、モデルが古くなる原因となる可能性があります。 モデルが古くなると、そのパフォーマンスが低下して、ビジネス価値を高めることができなくなったり、厳しく規制された環境で重大なコンプライアンス問題を引き起こし始めたりする可能性があります。

Azure Machine Learning でのモデル モニタリングの制限事項

Azure Machine Learning モデル モニタリングでは、データストアに含まれるデータにアクセスするための資格情報ベースの認証 (SAS トークンなど) の使用のみがサポートされます。 データストアと認証モードの詳細については、「データ管理」を参照してください。

Azure Machine Learning でのモデル監視のしくみ

モニタリングを実装するために、Azure Machine Learning は、ストリーミングされた運用環境の推論データと参照データに対して統計計算を実行して、モニタリング シグナルを取得します。 参照データには、履歴トレーニング データ、検証データ、またはグラウンド トゥルース データが含まれる場合があります。 一方、運用推論データは、運用環境で収集されたモデルの入出力データを指します。

各監視シグナルには、1 つ以上のメトリックがあります。 ユーザーは、モデルまたはデータの異常に関するアラートを Azure Machine Learning または Azure Event Grid 経由で受け取るために、これらのメトリックのしきい値を設定できます。 これらのアラートは、継続的なモデル品質の向上のために、Azure Machine Learning スタジオの監視シグナルを分析またはトラブルシューティングするようにユーザーに求めることができます。

次の手順では、運用環境のモデルの組み込みのモニタリング シグナル (データ ドリフトなど) を取得するために使用される統計計算の例について説明します。

• トレーニング データ内の特徴量については、その値の統計分布を計算します。 この分布は、特徴量のベースライン分布です。
• 運用環境で見られる特徴量の最新の値の統計分布を計算します。
• 統計テストを実行するか、距離スコアを計算して、運用環境の特徴量の最新の値の分布をベースライン分布と比較します。
• テスト統計または 2 つの分布間の距離スコアがユーザー指定のしきい値を超えると、Azure Machine Learning によって異常が識別され、ユーザーに通知されます。

モデルモニタリングの設定

Azure Machine Learning でモデルモニタリングを有効にして使用するには:

1. 運用推論データ収集を有効にします。 Azure Machine Learning オンライン エンドポイントにモデルをデプロイする場合は、Azure Machine Learning のモデル データ収集を使用して運用推論データ収集を有効にすることができます。 ただし、Azure Machine Learning の外部または Azure Machine Learning バッチ エンドポイントにモデルをデプロイする場合は、運用推論データを収集する責任が生じます。 このデータを Azure Machine Learning のモデル監視に使用できます。
2. モデル監視を設定します。 Azure Machine Learning SDK/CLI 2.0 またはスタジオ UI を使用して、モデルモニタリングを簡単に設定できます。 セットアップ中に、推奨される監視シグナルを指定し、各シグナルのメトリックとしきい値をカスタマイズできます。
3. モデル監視の結果を表示および分析します。 モデルモニタリングを設定すると、Azure Machine Learning によって、モニタリング ジョブが指定した頻度で実行されるようにスケジュールされます。 各実行は、選択したすべての監視シグナルのメトリックを計算して評価し、指定されたしきい値を超えたときにアラート通知をトリガーします。 アラート通知のリンクに従って、Azure Machine Learning ワークスペースでモニタリング結果を表示および分析できます。

モデル監視の機能

Azure Machine Learning には、継続的なモデル監視に対して次の機能が用意されています。

• 組み込みの監視シグナル。 モデル監視では、表形式データの組み込みの監視シグナルが提供されます。 これらのモニタリング シグナルには、データ ドリフト、予測ドリフト、データ品質、特徴量属性ドリフト、モデルのパフォーマンスが含まれます。
• Azure Machine Learning オンライン エンドポイントを使用した、設定不要ですぐに使用できるモデル監視のセットアップ。 Azure Machine Learning オンライン エンドポイントで運用環境にモデルをデプロイすると、Azure Machine Learning によって運用推論データが自動的に収集され、継続的な監視に使用されます。
• 広い視野のための複数の監視シグナルの使用。 1 つの監視設定に複数の監視シグナルを簡単に含めることができます。 監視シグナルごとに、任意のメトリックを選択し、アラートのしきい値を微調整できます。
• 比較のための参照データとして、トレーニング データまたは最近および過去の運用データを使用。 Azure Machine Learning では、トレーニング データまたは最近および過去の運用データを使用してモニタリング シグナルに参照データを設定できます。
• データ ドリフトまたはデータ品質に関する上位 N 個の特徴量の監視。 トレーニング データを参照データとして使用する場合は、特徴量の重要度に重ねてデータ ドリフトまたはデータ品質のシグナルを定義できます。
• 監視シグナルを定義できる柔軟性。 組み込みの監視シグナルがビジネス シナリオに適していない場合は、カスタム監視シグナル コンポーネントを使用して独自の監視シグナルを定義できます。
• あらゆるソースからの運用推論データを使用できる柔軟性. Azure Machine Learning の外部にモデルをデプロイする場合、またはモデルを Azure Machine Learning バッチ エンドポイントにデプロイする場合は、モデルモニタリングのために Azure Machine Learning で使用する運用推論データを収集できます。

ルックバック ウィンドウのサイズとオフセット

ルックバック ウィンドウのサイズは、モニタリングの実行日から遡った、運用または参照のデータ ウィンドウの期間 (ISO 8601 形式) です。

ルックバック ウィンドウ オフセットは、モニタリングの実行日からデータ ウィンドウの終了をオフセットする期間 (ISO 8601 形式) です。

たとえば、モデルが運用中で、1 月 31 日の午後 3 時 15 分 (協定世界時: UTC) に実行されるように設定されたモニターがあるとします。その場合、モニターの運用ルックバック ウィンドウ サイズを P7D (7 日間) に設定し、運用ルックバック ウィンドウ オフセットを P0D (0 日間) に設定すると、1 月 24 日午後 3 時 15 分 (UTC) から 1 月 31 日午後 3 時 15 分 (UTC) (モニターの実行時間) までのデータがモニターで使用されます。

さらに、参照データについては、ルックバック ウィンドウ オフセットを P7D (7 日) に設定すると、運用データ ウィンドウが開始される直前に参照データ ウィンドウが終了するため、重複することがなくなります。 その後、参照データのルックバック ウィンドウのサイズを好きな大きさに設定できます。 たとえば、参照データのルックバック ウィンドウ サイズを P24D (24 日間) に設定すると、参照データ ウィンドウには 1 月 1 日午後 3 時 15 分 (UTC) から 1 月 24 日午後 3 時 15 分 (UTC) までのデータが含まれます。 この例を次の図に示します。

場合によっては、運用データの "ルックバック ウィンドウ オフセット" を 0 日より大きい数値に設定すると便利な場合があります。 たとえば、モニターが毎週月曜日の午後 3 時 15 分 (UTC) に実行されるようにスケジュールされているが、モニタリングの実行で週末のデータを使用したくない場合は、P5D (5 日間) の "ルックバック ウィンドウ サイズ"と、P2D (2 日間) の "ルックバック ウィンドウ オフセット" を使用できます。 その後、データ ウィンドウは前の月曜日の午後 3 時 15 分 (UTC) に開始され、金曜日の午後 3 時 15 分 (UTC) に終了します。

実際には、参照データ ウィンドウと運用データ ウィンドウが重複しないようにする必要があります。 次の図に示すように、重複しないウィンドウを確保するには、必ず参照データのルックバック ウィンドウ オフセット (この例では P10D (10 日間)) を、運用データのルックバック ウィンドウ サイズとそのルックバック ウィンドウ オフセットの合計 (合計 7 日間) 以上にします。

Azure Machine Learning モデルモニタリングを使用すると、ルックバック ウィンドウ サイズとルックバック ウィンドウ オフセットにスマートな既定値を使用したり、ニーズに合わせてそれらをカスタマイズしたりできます。 また、ローリング ウィンドウと固定ウィンドウの両方がサポートされています。

ルックバック ウィンドウ サイズのカスタマイズ

運用データと参照データのルックバック ウィンドウ サイズは、どちらも柔軟に選択できます。

• 既定では、運用データのルックバック ウィンドウ サイズは、モニタリングの頻度です。 つまり、モニタリング ジョブが実行される前のモニタリング期間に収集されたすべてのデータが分析されます。 production_data.data_window.lookback_window_size プロパティを使用して、運用データのローリング データ ウィンドウを調整できます。

• 既定では、参照データのルックバック ウィンドウは完全なデータセットです。 reference_data.data_window.lookback_window_size プロパティを使用して、参照ルックバック ウィンドウ サイズを調整できます。

• 参照データの固定データ ウィンドウを指定するには、プロパティ reference_data.data_window.window_start_date と reference_data.data_window.window_end_dateを使用できます。

ルックバック ウィンドウ オフセットのカスタマイズ

運用データと参照データの両方のデータ ウィンドウのルックバック ウィンドウ オフセットを柔軟に選択できます。 オフセットを使用して、モニターが使用するデータをきめ細かく制御できます。 このオフセットは、ローリング データ ウィンドウにのみ適用されます。

• 既定では、運用データのオフセットは P0D (0 日) です。 このオフセットは、production_data.data_window.lookback_window_offset プロパティを使用して変更できます。

• 既定では、参照データのオフセットは production_data.data_window.lookback_window_size の 2 倍です。 この設定により、統計的に意味のあるモニタリング結果を得るのに十分な参照データが確保されます。 このオフセットは、reference_data.data_window.lookback_window_offset プロパティを使用して変更できます。

監視のシグナルとメトリック

Azure Machine Learning モデルモニタリングでは、次のリストにあるモニタリングのシグナルとメトリックがサポートされています。

データ品質のモニタリング シグナルのメトリック

データ品質のモニタリング シグナルは、モデルの入力データの整合性を追跡するために、次の 3 つのメトリックを計算します。

• Null 値率
• データ型のエラー率
• 範囲外率

Null 値率

"null 値率" は、各特徴量に対するモデルの入力における null 値の割合です。 たとえば、モニタリング運用データ ウィンドウに 100 行が含まれており、そのうちの 10 行で特定の特徴量 temperature の値が null である場合、temperature の null 値率は 10% になります。

• Azure Machine Learning では、すべての特徴量データ型の Null 値率の計算がサポートされています。

データ型のエラー率

"データ型のエラー率" は、現在の運用データ ウィンドウと参照データの間のデータ型の違いの割合です。 各モニタリングの実行中、Azure Machine Learning モデルモニタリングにより、参照データから各特徴量のデータ型が推測されます。 たとえば、特徴量 temperature のデータ型が参照データから IntegerType であると推測されるが、運用データ ウィンドウでは、temperature の 100 個の値のうち 10 個が IntegerType でなはい (おそらく文字列である) 場合、temperature のデータ型のエラー率は 10% になります。

• Azure Machine Learning では、PySpark で使用できる次のデータ型に対するデータ型のエラー率の計算がサポートされています: ShortType、BooleanType、BinaryType、DoubleType、TimestampType、StringType、IntegerType、FloatType、ByteType、LongType、DateType。
• 特徴量のデータ型がこのリストに含まれていない場合でも、Azure Machine Learning モデルモニタリングは実行されますが、その特定の特徴量のデータ型のエラー率は計算されません。

範囲外率

"範囲外率" は、参照データによって決定された適切な範囲またはセットから外れる各特徴量の値の割合です。 各モニタリングの実行中、Azure Machine Learning モデルモニタリングにより、参照データから各特徴量の許容可能な範囲またはセットが決定されます。

• 数値特徴量の場合、適切な範囲は、参照データセットの最小値から最大値までの数値間隔 ([0, 100] など) です。
• color などのカテゴリ特徴量の場合、適切な範囲は、参照データセットに含まれるすべての値のセット ([red, yellow, green] など) です。

たとえば、数値特徴量 temperature があり、参照データセットではすべての値が [37, 77] の範囲内に収まっているが、運用データ ウィンドウでは、temperature の 100 個の値のうち 10 個が範囲 [37, 77] の外にある場合、temperature の範囲外率は 10% になります。

• Azure Machine Learning では、PySpark で使用できる次のデータ型に対する範囲外率の計算がサポートされています: StringType、IntegerType、DoubleType、ByteType、LongType、FloatType。
• 特徴量のデータ型がこのリストに含まれていない場合でも、Azure Machine Learning モデルモニタリングは実行されますが、その特定の特徴量の範囲外率は計算されません。

Azure Machine Learning モデルモニタリングでは、null 値率、データ型のエラー率、範囲外率の計算に対して、最大 0.00001 の精度がサポートされています。

モデル監視に推奨されるベスト プラクティス

各機械学習モデルとそのユース ケースは固有のものになります。 そのため、モデル監視は状況ごとに異なります。 モデル監視に推奨されるベスト プラクティスの一覧を次に示します。

• モデルを運用環境にデプロイした直後に、モデルモニタリングを開始します。
• モデルに精通しているデータ サイエンティストと協力して、モデル監視を設定します。 モデルとそのユース ケースに関する分析情報を持つデータ サイエンティストは、モニタリングのシグナルとメトリックを推奨し、(アラート疲れを回避するために) メトリックごとに適切なアラートしきい値を設定するのに最適なポジションにいます。
• 監視設定に複数の監視シグナルを含めます。 複数の監視シグナルを使用すると、監視の広範なビューと詳細なビューの両方が得られます。 たとえば、データ ドリフトと特徴量属性ドリフトのシグナルを組み合わせて、モデルのパフォーマンスの問題に関する早期の警告を受け取ることができます。
• モデル トレーニング データを参照データとして使用します。 比較ベースラインとして使用される参照データとして、Azure Machine Learning では、最近の運用データまたは履歴データ (トレーニング データや検証データなど) を使用できます。 意味のある比較を行うには、データ ドリフトとデータ品質の比較ベースラインとしてトレーニング データを使用することをお勧めします。 予測ドリフトの場合は、検証データを比較ベースラインとして使用します。
• 運用データが時間の経過に伴ってどのように増加するかに基づいて、モニタリング頻度を指定します。 たとえば、運用モデルに毎日多くのトラフィックがあり、監視するのに毎日のデータ蓄積で十分な場合は、監視頻度を毎日に設定できます。 それ程多くない場合は、時間の経過に伴う運用データの増加に基づいて、毎週または毎月の監視頻度を検討できます。
• 上位 N 個の重要な特徴または特徴のサブセットを監視します。 比較ベースラインとしてトレーニング データを使用する場合は、上位 N 個の特徴量のデータ ドリフト監視またはデータ品質監視を簡単に構成できます。 多数の特徴を持つモデルの場合は、それらの特徴のサブセットを監視して計算コストを削減し、ノイズを監視することを検討してください。
• グラウンド・トゥルース・データにアクセスできる場合は、モデル・パフォーマンス・シグナルを使用します。 お使いの機械学習アプリケーションの詳細に基づいたグラウンド トゥルース データ (実績とも呼ばれます) にアクセスできる場合は、モデル パフォーマンス シグナルを使用してグラウンド トゥルース データを実際のモデルの出力と比較することをお勧めします。 この比較により、運用環境でのモデルのパフォーマンスを客観的に確認できます。

Azure Event Grid とのモデルモニタリングの統合

Azure Machine Learning モデルモニタリングの実行によって生成されたイベントを使用して、Azure Event Grid でイベントドリブン アプリケーション、プロセス、または CI/CD ワークフローを設定できます。

モデル モニターでドリフト、データ品質の問題、またはモデルのパフォーマンス低下が検出されたら、Event Grid でこれらのイベントを追跡し、プログラムでアクションを実行できます。 たとえば、運用環境での分類モデルの精度が特定のしきい値を下回った場合は、Event Grid を使用して、収集されたグラウンド トゥルース データを使用する再トレーニング ジョブを開始できます。 Azure Machine Learning と Event Grid を統合する方法については、Azure Machine Learning で継続的なモデル監視を実行するに関するページを参照してください。

関連するコンテンツ

• モデル データ収集
• 運用推論データを収集する
• 生成 AI アプリケーションのモデル監視