Azure Machine Learning モデルモニタリング

モデル、機械学習のエンドツーエンド ライフサイクルにおける最後のステップです。 このステップでは、実稼働中のモデルのパフォーマンスを追跡し、このパフォーマンスをデータ サイエンスと運用の両方の観点から分析します。 この記事では、Azure Machine Learning でのモデルモニタリングについて説明し、監視できるシグナルとメトリックについて、およびモデルモニタリングに関する推奨事項についても説明します。

従来のソフトウェア システムとは異なり、機械学習システムの振る舞いは、コードで指定されたルールのみに依存するのではなく、データからも学習されます。 データ分布の変化、トレーニング/サービング スキュー、データ品質の問題、環境の変化、コンシューマーの振る舞いの変化はどれも、モデルの陳腐化の原因となる可能性があります。

モデルが古くなると、そのパフォーマンスが低下して、ビジネス価値を高めることができなくなったり、厳しく規制された環境で重大なコンプライアンス問題を引き起こし始めたりする可能性があります。 そのため、モデルのパフォーマンスを監視することが重要です。

Azure Machine Learning モデルモニタリングのしくみ

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

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

Azure Machine Learning は、次のプロセスを使用して実稼働中のモデルに対する組み込みのモニタリング シグナル (たとえばデータ ドリフト) を処理します。

• まず、Azure Machine Learning はトレーニング データ内の特徴量の値の統計的分布を計算します。 この分布は、特徴量のベースライン分布です。

• 次に、Azure Machine Learning は実稼働中に記録された特徴量の最新の値の統計的分布を計算します。

• Azure Machine Learning は、統計的検定を実行するか距離スコアを計算することによって、この実稼働中の特徴量の最新の値の分布をベースライン分布と比較します。 2 つの分布間の検定統計量または距離スコアがユーザー指定のしきい値を超えている場合は、Azure Machine Learning は異常とみなしてユーザーに通知します。

モデルモニタリングを設定して使用する

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

まず、運用推論データ収集を有効にします。

• Azure Machine Learning オンライン エンドポイントにモデルをデプロイする場合は、Azure Machine Learning のモデル データ収集を使用して運用推論データ収集を有効にすることができます。
• モデルを Azure Machine Learning の外部に、または Azure Machine Learning バッチ エンドポイントに展開する場合は、Azure Machine Learning モデルモニタリングに使用できる運用推論データの収集はユーザーの責任で行います。

次に、モデルモニタリングを設定します。Azure Machine Learning SDK/CLI 2.0 またはスタジオ UI を使用して、モデルモニタリングを簡単に設定できます。 セットアップ中に、監視したいモニタリング シグナルを指定し、各シグナルのメトリックとしきい値をカスタマイズできます。

最後に、モデルモニタリングの結果を見て分析します。モデルモニタリングの設定後は、指定したスケジュールで Azure Machine Learning によってモニタリング ジョブが実行されます。 各実行は、選択したすべての監視シグナルのメトリックを計算して評価し、指定されたしきい値を超えたときにアラート通知をトリガーします。 アラート通知のリンクに従って、Azure Machine Learning ワークスペースでモニタリング結果を表示および分析できます。

モデル監視の機能

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

• 組み込みのモニタリング シグナル。表形式データに対するものであり、データ ドリフト、予測ドリフト、データ品質、特徴量属性ドリフト、モデル パフォーマンスが含まれます。
• オンライン エンドポイントに対するアウトオブボックス モデルモニタリング。 モデルをオンライン エンドポイントで実稼働に展開する場合は、Azure Machine Learning によって運用推論データが自動的に収集されて継続的なモニタリングに使用されます。
• 複数のモニタリング シグナルを 1 つのモニタリング設定に含める。 モニタリング シグナルごとに、希望するメトリックとアラートしきい値を選択できます。
• 比較用の参照データの選択。 モニタリング シグナルに対する参照データを、トレーニング データまたは最近の実稼働データを使用して設定できます。
• データ ドリフトまたはデータ品質に関する上位 N 個の特徴量のモニタリング。 トレーニング データを参照データとして使用する場合は、特徴量の重要度に重ねてデータ ドリフトまたはデータ品質のシグナルを定義できます。
• 独自のモニタリング シグナルを定義できる。 組み込みの監視シグナルがビジネス シナリオに適していない場合は、カスタム監視シグナル コンポーネントを使用して独自の監視シグナルを定義できます。
• あらゆるソースからの運用推論データを使用できる柔軟性. モデルを Azure Machine Learning の外部に展開する、またはモデルをバッチ エンドポイントに展開する場合も、Azure Machine Learning モデルモニタリングで使用する運用推論データをユーザーが収集できます。

モデルモニタリングに関するベスト プラクティス

各機械学習モデルとそのユース ケースは固有のものになります。 そのため、モデル監視は状況ごとに異なります。 次のリストでは、モデルモニタリングに関して推奨されるベスト プラクティスを説明します。

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

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

"ルックバック ウィンドウ サイズ" とは、実稼働または参照データ ウィンドウの時間の長さを 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 値率
• データ型のエラー率
• 範囲外率

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

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 Event Grid とのモデルモニタリングの統合

Azure Machine Learning モデルモニタリングの実行によって生成されたイベントを使用して、イベントドリブンのアプリケーション、プロセス、または継続的インテグレーション/継続的デリバリー (CI/CD) ワークフローを Azure Event Grid で設定できます。 モデル モニターでドリフト、データ品質の問題、またはモデルのパフォーマンス低下が検出されたら、Event Grid でこれらのイベントを追跡し、プログラムでアクションを実行できます。

たとえば、運用環境での分類モデルの精度が特定のしきい値を下回った場合は、Event Grid を使用して、収集されたグラウンド トゥルース データを使用する再トレーニング ジョブを開始できます。 Azure Machine Learning を Event Grid と統合する方法については、「運用環境にデプロイされたモデルのパフォーマンスを監視する」を参照してください。

関連するコンテンツ

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