次の方法で共有


運用環境にデプロイされたモデルのパフォーマンスを監視する

適用対象:Azure CLI ml extension v2 (現行)Python SDK azure-ai-ml v2 (現行)

Azure Machine Learning のモデル監視を使用して、運用環境の機械学習モデルのパフォーマンスを継続的に追跡する方法について説明します。 モデル監視によって、監視シグナルの幅広いビューが提供されるため、ユーザーに潜在的な問題が通知されます。 運用環境のモデルのシグナルやパフォーマンス メトリックを監視すると、それらに関連した固有のリスクを批判的に評価し、ビジネスに悪影響を与える可能性のある盲点を識別できます。

この記事では、次のタスクを実行する方法について説明します。

  • Azure Machine Learning オンライン エンドポイントにデプロイされているモデルに対する、すぐに使用できる高度な監視を設定する
  • 運用環境のモデルのパフォーマンス メトリックを監視する
  • Azure Machine Learning の外部にデプロイされているモデル、または Azure Machine Learning バッチ エンドポイントにデプロイされているモデルを監視する
  • カスタムシグナルとメトリックを使用してモデル監視を設定する
  • モニタリング結果を使用する
  • Azure Machine Learning モデルモニタリングを Azure Event Grid と統合する

前提条件

この記事の手順に従う前に、次の前提条件が満たされていることをご確認ください。

  • Azure ロールベースのアクセス制御 (Azure RBAC) は、Azure Machine Learning の操作に対するアクセスを許可するために使用されます。 この記事の手順を実行するには、ユーザー アカウントに、Azure Machine Learning ワークスペースの所有者共同作成者ロール、または Microsoft.MachineLearningServices/workspaces/onlineEndpoints/* を許可するカスタム ロールを割り当てる必要があります。 詳細については、「Azure Machine Learning ワークスペースへのアクセスの管理」を参照してください。

  • Azure Machine Learning オンライン エンドポイント (マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイント) にデプロイされたモデルを監視するには、次の点を確認します。

  • Azure Machine Learning バッチ エンドポイントにデプロイされたモデル、または Azure Machine Learning の外部にデプロイされたモデルを監視するには、次の点を確認します。

    • 運用データを収集し、Azure Machine Learning データ資産として登録する手段がある。
    • モデルモニタリングのために、登録済みのデータ資産を継続的に更新する。
    • 系列の追跡のため、Azure Machine Learning ワークスペースにモデルを登録する。(推奨)

重要

モデルモニタリング ジョブは、 Standard_E4s_v3Standard_E8s_v3Standard_E16s_v3Standard_E32s_v3Standard_E64s_v3の各 VM インスタンスの種類をサポートするサーバーレス Spark コンピューティング プールで実行するようにスケジュールされています。 YAML 構成の “create_monitor.compute.instance_type” プロパティを使用して、または Azure Machine Learning スタジオのドロップダウンから、VM インスタンスの種類を選択できます。

すぐに使用できるモデル監視を設定する

Azure Machine Learning オンライン エンドポイントでモデルを運用環境にデプロイし、デプロイ時にデータ収集を有効にしたとします。 このシナリオでは、Azure Machine Learning によって運用環境の推論データが収集され、Microsoft Azure Blob Storage に自動的に保存されます。 その後、Azure Machine Learning のモデルモニタリングを使用して、この運用環境の推論データを継続的に監視できます。

Azure CLI、Python SDK、またはスタジオを使って、すぐに使用できるモデルモニタリングのセットアップを行うことができます。 すぐに使用できるモデルモニタリング構成には、次のモニタリング機能が用意されています。

  • Azure Machine Learning は、Azure Machine Learning オンライン デプロイに関連付けられている運用推論データセットを自動的に検出し、モデルモニタリングにそのデータセットを使用します。
  • 比較参照データセットは、最近の過去の運用推論データセットとして設定されます。
  • 監視セットアップには、組み込みの監視シグナル (データ ドリフト予測ドリフトデータ品質) が自動的に含められて追跡されます。 監視シグナルごとに、Azure Machine Learning では次のものが使われます。
    • 比較参照データセットとしての最近の運用推論データセット。
    • メトリックとしきい値のスマート既定値。
  • 監視ジョブは、毎日午前 3 時 15 分 (この例の場合) に実行して監視シグナルを取得し、各メトリック結果を対応するしきい値に対して評価するように、スケジュールされています。 既定では、何らかのしきい値を超えると、Azure Machine Learning はモニターを設定したユーザーにアラート メールを送信します。

Azure Machine Learning のモデルモニタリングでは、 az ml schedule を使用してモニタリング ジョブをスケジュールします。 次の CLI コマンドと YAML 定義を使って、すぐに使用できるモデルモニタリングを作成できます。

az ml schedule create -f ./out-of-box-monitoring.yaml

次の YAML には、すぐに使用できるモデルモニタリングの定義が含まれています。

# out-of-box-monitoring.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: credit_default_model_monitoring
display_name: Credit default model monitoring
description: Credit default model monitoring setup with minimal configurations

trigger:
  # perform model monitoring activity daily at 3:15am
  type: recurrence
  frequency: day #can be minute, hour, day, week, month
  interval: 1 # #every day
  schedule: 
    hours: 3 # at 3am
    minutes: 15 # at 15 mins after 3am

create_monitor:

  compute: # specify a spark compute for monitoring job
    instance_type: standard_e4s_v3
    runtime_version: "3.3"

  monitoring_target: 
    ml_task: classification # model task type: [classification, regression, question_answering]
    endpoint_deployment_id: azureml:credit-default:main # azureml endpoint deployment id

  alert_notification: # emails to get alerts
    emails:
      - abc@example.com
      - def@example.com

高度なモデル監視を設定する

Azure Machine Learning には、継続的なモデル監視のための多くの機能が用意されています。 これらの機能の包括的なリストについては、「モデルモニタリングの機能」をご覧ください。 多くの場合、高度な監視機能を使ってモデル監視を設定する必要があります。 次のセクションでは、次のような機能を使用してモデルモニタリングを設定します。

  • 広い視野のための複数の監視シグナルの使用。
  • 比較参照データセットとしての履歴モデル トレーニング データまたは検証データの使用。
  • 上位 N 個の最も重要な特徴量と個々の特徴量のモニタリング。

特徴量の重要度を構成する

特徴量の重要度は、モデルの出力に対する各入力特徴量の相対的な重要度を表します。 たとえば、temperatureは、elevationと比較してモデルの予測にとってより重要な場合があります。 特徴量の重要度を有効にすることで、運用環境でのドリフトやデータ品質の問題の発生を避けたい特徴量を可視化できます。

シグナル (データ ドリフトやデータ品質など) で特徴量の重要度を有効にするには、次の情報を提供する必要があります。

  • reference_data データセットとしてのトレーニング データセット。
  • reference_data.data_column_names.target_column” プロパティ。モデルの出力/予測列の名前です。

特徴量の重要度を有効にすると、Azure Machine Learning モデルモニタリング スタジオ UI で監視している各特徴量の重要度が表示されます。

Azure CLI、Python SDK、またはスタジオを使って、モデルモニタリングの高度なセットアップを行うことができます。

次の CLI コマンドと YAML 定義を使って、高度なモデルモニタリングのセットアップを作成できます。

az ml schedule create -f ./advanced-model-monitoring.yaml

次の YAML には、高度なモデル監視の定義が含まれています。

# advanced-model-monitoring.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: fraud_detection_model_monitoring
display_name: Fraud detection model monitoring
description: Fraud detection model monitoring with advanced configurations

trigger:
  # perform model monitoring activity daily at 3:15am
  type: recurrence
  frequency: day #can be minute, hour, day, week, month
  interval: 1 # #every day
  schedule: 
    hours: 3 # at 3am
    minutes: 15 # at 15 mins after 3am

create_monitor:

  compute: 
    instance_type: standard_e4s_v3
    runtime_version: "3.3"

  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:credit-default:main
  
  monitoring_signals:
    advanced_data_drift: # monitoring signal name, any user defined name works
      type: data_drift
      # reference_dataset is optional. By default referece_dataset is the production inference data associated with Azure Machine Learning online endpoint
      reference_data:
        input_data:
          path: azureml:credit-reference:1 # use training data as comparison reference dataset
          type: mltable
        data_context: training
        data_column_names:
          target_column: DEFAULT_NEXT_MONTH
      features: 
        top_n_feature_importance: 10 # monitor drift for top 10 features
      metric_thresholds:
        numerical:
          jensen_shannon_distance: 0.01
        categorical:
          pearsons_chi_squared_test: 0.02
    advanced_data_quality:
      type: data_quality
      # reference_dataset is optional. By default reference_dataset is the production inference data associated with Azure Machine Learning online endpoint
      reference_data:
        input_data:
          path: azureml:credit-reference:1
          type: mltable
        data_context: training
      features: # monitor data quality for 3 individual features only
        - SEX
        - EDUCATION
      metric_thresholds:
        numerical:
          null_value_rate: 0.05
        categorical:
          out_of_bounds_rate: 0.03

    feature_attribution_drift_signal:
      type: feature_attribution_drift
      # production_data: is not required input here
      # Please ensure Azure Machine Learning online endpoint is enabled to collected both model_inputs and model_outputs data
      # Azure Machine Learning model monitoring will automatically join both model_inputs and model_outputs data and used it for computation
      reference_data:
        input_data:
          path: azureml:credit-reference:1
          type: mltable
        data_context: training
        data_column_names:
          target_column: DEFAULT_NEXT_MONTH
      metric_thresholds:
        normalized_discounted_cumulative_gain: 0.9
  
  alert_notification:
    emails:
      - abc@example.com
      - def@example.com

モデル パフォーマンス監視を設定する

Azure Machine Learning のモデル監視を使用すると、運用環境のモデルのパフォーマンス メトリックを計算することによってそのパフォーマンスを追跡できます。 現在、次のモデル パフォーマンス メトリックがサポートされています。

分類モデルの場合:

  • 精度
  • 正確性
  • リコール

回帰モデルの場合:

  • 平均絶対誤差 (MAE)
  • 平均二乗誤差 (MSE)
  • 二乗平均平方根誤差 (RMSE)

モデル パフォーマンス監視のその他の前提条件

モデル パフォーマンス シグナルを構成するには、次の要件を満たす必要があります。

  • 行ごとに一意の ID を持つ運用モデルの出力データ (モデルの予測) が存在する。 Azure Machine Learning データ コレクターを使用して運用データを収集する場合は、推論要求ごとに correlation_id が提供されます。 このデータ コレクターには、アプリケーションから独自の一意の ID をログに記録するオプションもあります。

    Note

    Azure Machine Learning のモデル パフォーマンス監視の場合は、Azure Machine Learning データ コレクターを使用して、一意の ID を独自の列にログ記録することをお勧めします。

  • 行ごとに一意の ID を持つグラウンド トゥルース データ (実際のデータ) が存在する。 特定の行の一意の ID が、その特定の推論要求のためのモデル出力の一意の ID と一致している必要があります。 この一意の ID は、グラウンド トゥルース データセットをモデル出力と結合するために使用されます。

    グラウンド トゥルース データがないと、モデル パフォーマンス監視を実行できません。 グラウンド トゥルース データはアプリケーション レベルで検出されるため、それを使用可能になったときに収集することはユーザーの責任です。 また、データ資産をこのグラウンド トゥルース データが含まれている Azure Machine Learning に保持することも必要です。

  • (省略可能) モデル出力とグラウンド トゥルース データが既にまとめて結合されている、事前に結合された表形式データセットが存在する。

データ コレクターを使用している場合のモデルのパフォーマンス要件を監視する

Azure Machine Learning データ コレクターを使用して、行ごとの独自の一意の ID を個別の列として指定せずに運用推論データを収集する場合は、correlationid が自動生成され、ログに記録された JSON オブジェクトに含まれます。 ただし、データ コレクターでは、互いに短い時間間隔で送信される複数行をバッチ処理します。 バッチ処理された行は同じ JSON オブジェクトに含まれるため、correlationid が同じになります。

同じ JSON オブジェクト内の行を区別するために、Azure Machine Learning のモデル パフォーマンス監視では、インデックス作成を使用して JSON オブジェクト内の行の順序を決定します。 たとえば、3 行がまとめてバッチ処理され、correlationidtest である場合、行 1 の ID は test_0 に、行 2 の ID は test_1 に、行 3 の ID は test_2 になります。 グラウンド トゥルース データセットに、収集された運用推論モデル出力と一致する一意の ID が確実に含まれるようにするために、各 correlationid のインデックスを適切に作成するようにしてください。 ログに記録された JSON オブジェクトに 1 行しかない場合、correlationidcorrelationid_0 になります。

このインデックス作成が使用されないようにするには、一意の ID を Azure Machine Learning データ コレクターでログ記録している Pandas DataFrame 内の独自の列にログ記録することをお勧めします。 その後、モデル監視の構成で、この列の名前を指定してモデル出力データをグラウンド トゥルース データと結合します。 両方のデータセット内の行ごとの ID が同じである限り、Azure Machine Learning のモデル監視ではモデル パフォーマンス監視を実行できます。

モデルのパフォーマンスを監視するためのワークフローの例

モデル パフォーマンス監視に関連した概念を理解するために、次のワークフローの例を考えてみます。 クレジット カードのトランザクションが不正かどうかを予測するモデルをデプロイしている場合は、次の手順に従ってモデルのパフォーマンスを監視できます。

  1. データ コレクターを使用してモデルの運用推論データ (入力および出力データ) を収集するようにデプロイを構成します。 たとえば、出力データが列 is_fraud に格納されるとします。
  2. 収集された推論データの行ごとに、一意の ID をログに記録します。 この一意の ID はアプリケーションから取得することも、ログに記録された JSON オブジェクトごとに Azure Machine Learning によって一意に生成される correlationid を使用することもできます。
  3. 後で、グラウンド トゥルース (または実際の) is_fraud データが使用可能になると、それもまたログに記録され、モデルの出力と共にログに記録されたのと同じ一意の ID にマップされます。
  4. このグラウンド トゥルース is_fraud データもまた収集および保持され、Azure Machine Learning にデータ資産として登録されます。
  5. 一意の ID 列を使用して、モデルの運用推論およびグラウンド トゥルース データ資産を結合するモデル パフォーマンス監視シグナルを作成します。
  6. 最後に、モデル パフォーマンス メトリックを計算します。

モデル パフォーマンス監視の前提条件が満たされたら、次の CLI コマンドと YAML 定義を使用してモデル監視を設定できます。

az ml schedule create -f ./model-performance-monitoring.yaml

次の YAML には、収集した運用推論データに関するモデル監視用の定義が含まれます。

$schema:  http://azureml/sdk-2-0/Schedule.json
name: model_performance_monitoring
display_name: Credit card fraud model performance
description: Credit card fraud model performance

trigger:
  type: recurrence
  frequency: day
  interval: 7 
  schedule: 
    hours: 10
    minutes: 15
  
create_monitor:
  compute: 
    instance_type: standard_e8s_v3
    runtime_version: "3.3"
  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:loan-approval-endpoint:loan-approval-deployment

  monitoring_signals:
    fraud_detection_model_performance: 
      type: model_performance 
      production_data:
        data_column_names:
          prediction: is_fraud
          correlation_id: correlation_id
      reference_data:
        input_data:
          path: azureml:my_model_ground_truth_data:1
          type: mltable
        data_column_names:
          actual: is_fraud
          correlation_id: correlation_id
        data_context: actuals
      alert_enabled: true
      metric_thresholds: 
        tabular_classification:
          accuracy: 0.95
          precision: 0.8
  alert_notification: 
      emails: 
        - abc@example.com

運用データを Azure Machine Learning に取り込んでモデル監視を設定する

また、Azure Machine Learning バッチ エンドポイントにデプロイされた、または Azure Machine Learning の外部にデプロイされたモデル用に、モデル監視を設定することもできます。 運用データはあるがデプロイがない場合は、データを使用して継続的なモデルモニタリングを実行できます。 これらのモデルを監視するには、次のことが可能である必要があります。

  • 運用環境にデプロイされたモデルから運用環境の推論データを収集します。
  • 運用環境の推論データを Azure Machine Learning データ資産として登録し、データの継続的な更新を保証します。
  • カスタム データ前処理コンポーネントを提供し、Azure Machine Learning コンポーネントとして登録します。

データ コレクターでデータが収集されない場合は、カスタム データ前処理コンポーネントを指定する必要があります。 このカスタム データ前処理コンポーネントがないと、Azure Machine Learning モデルモニタリング システムは、時間枠をサポートする表形式にデータを処理する方法を認識しません。

カスタム前処理コンポーネントには、次の入力シグネチャと出力シグネチャが必要です。

[入力または出力] シグネチャ名 説明 例値
input data_window_start リテラル、文字列 ISO8601 形式のデータ ウィンドウ開始日時。 2023-05-01T04:31:57.012Z
input data_window_end リテラル、文字列 ISO8601 形式のデータ ウィンドウ終了日時。 2023-05-01T04:31:57.012Z
input input_data uri_folder 収集された運用推論データ。Azure Machine Learning データ資産として登録されます。 azureml:myproduction_inference_data:1
output preprocessed_data mltable 表形式データセット。参照データ スキーマのサブセットと一致します。

カスタム データ前処理コンポーネントの例については、「azuremml-examples GitHub リポジトリのcustom_preprocessing」を参照してください。

以上の要件を満たしたら、次の CLI コマンドと YAML 定義を使ってモデル監視を設定できます。

az ml schedule create -f ./model-monitoring-with-collected-data.yaml

次の YAML には、収集した運用推論データに関するモデル監視用の定義が含まれます。

# model-monitoring-with-collected-data.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: fraud_detection_model_monitoring
display_name: Fraud detection model monitoring
description: Fraud detection model monitoring with your own production data

trigger:
  # perform model monitoring activity daily at 3:15am
  type: recurrence
  frequency: day #can be minute, hour, day, week, month
  interval: 1 # #every day
  schedule: 
    hours: 3 # at 3am
    minutes: 15 # at 15 mins after 3am

create_monitor:
  compute: 
    instance_type: standard_e4s_v3
    runtime_version: "3.3"
  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:fraud-detection-endpoint:fraud-detection-deployment
  
  monitoring_signals:

    advanced_data_drift: # monitoring signal name, any user defined name works
      type: data_drift
      # define production dataset with your collected data
      production_data:
        input_data:
          path: azureml:my_production_inference_data_model_inputs:1  # your collected data is registered as Azure Machine Learning asset
          type: uri_folder
        data_context: model_inputs
        pre_processing_component: azureml:production_data_preprocessing:1
      reference_data:
        input_data:
          path: azureml:my_model_training_data:1 # use training data as comparison baseline
          type: mltable
        data_context: training
        data_column_names:
          target_column: is_fraud
      features: 
        top_n_feature_importance: 20 # monitor drift for top 20 features
      metric_thresholds:
        numberical:
          jensen_shannon_distance: 0.01
        categorical:
          pearsons_chi_squared_test: 0.02

    advanced_prediction_drift: # monitoring signal name, any user defined name works
      type: prediction_drift
      # define production dataset with your collected data
      production_data:
        input_data:
          path: azureml:my_production_inference_data_model_outputs:1  # your collected data is registered as Azure Machine Learning asset
          type: uri_folder
        data_context: model_outputs
        pre_processing_component: azureml:production_data_preprocessing:1
      reference_data:
        input_data:
          path: azureml:my_model_validation_data:1 # use training data as comparison reference dataset
          type: mltable
        data_context: validation
      metric_thresholds:
        categorical:
          pearsons_chi_squared_test: 0.02
  
  alert_notification:
    emails:
      - abc@example.com
      - def@example.com

カスタムシグナルとメトリックを使用してモデル監視を設定する

Azure Machine Learning のモデル監視では、カスタム シグナルを定義し、任意のメトリックを実装してモデルを監視できます。 このカスタム シグナルは、Azure Machine Learning コンポーネントとして登録できます。 Azure Machine Learning モデルモニタリング ジョブが指定されたスケジュールで実行されると、事前構築済みのシグナル (データ ドリフト、予測ドリフト、データ品質) の場合と同様に、カスタム シグナル内で定義したメトリックが計算されます。

モデルモニタリングに使用するカスタム シグナルを設定するには、まずカスタム シグナルを定義し、Azure Machine Learning コンポーネントとして登録する必要があります。 Azure Machine Learning コンポーネントには、次の入力シグネチャと出力シグネチャが必要です。

コンポーネント入力署名

コンポーネント入力 DataFrame には、次の項目が含まれている必要があります。

  • 前処理コンポーネントから処理されたデータを含む mltable
  • カスタム シグナル コンポーネントの一部として実装されたメトリックを表す任意の数のリテラル。 たとえば、“std_deviation” という 1 つのメトリックを実装している場合は、“std_deviation_threshold” の入力が必要になります。 一般に、“<metric_name>_threshold” という名前の入力がメトリックごとに 1 つ必要です。
シグネチャ名 説明 例値
production_data mltable 参照データ スキーマのサブセットと一致する表形式データセット。
std_deviation_threshold リテラル、文字列 実装されたメトリックのそれぞれのしきい値。 2

コンポーネント出力署名

コンポーネント出力ポートには、次の署名が必要です。

シグネチャ名 説明
signal_metrics mltable 計算されたメトリックを含む mltable。 スキーマは、次のセクションの [signal_metrics スキーマ]で定義します。

signal_metrics schema

コンポーネント出力 DataFrame には、groupmetric_namemetric_valueおよびthreshold_valueの 4 つの列が含まれている必要があります。

シグネチャ名 説明 例値
グループ リテラル、文字列 このカスタム メトリックに適用される最上位レベルの論理グループ化。 TRANSACTIONAMOUNT
metric_name リテラル、文字列 カスタム メトリックの名前。 std_deviation
metric_value 数値 カスタム メトリックの値。 44,896.082
threshold_value 数値 カスタム メトリックのしきい値。 2

次の表は、“std_deviation” メトリックを計算するカスタム シグナル コンポーネントからの出力例を示しています。

グループ metric_value metric_name threshold_value
TRANSACTIONAMOUNT 44,896.082 std_deviation 2
LOCALHOUR 3.983 std_deviation 2
TRANSACTIONAMOUNTUSD 54,004.902 std_deviation 2
DIGITALITEMCOUNT 7.238 std_deviation 2
PHYSICALITEMCOUNT 5.509 std_deviation 2

カスタム シグナル コンポーネント定義とメトリック計算コードの例については、「azureml-examples リポジトリのcustom_signal」を参照してください。

カスタム シグナルとメトリックを使用するための要件を満たしたら、次の CLI コマンドと YAML 定義を使用してモデルモニタリングを設定できます。

az ml schedule create -f ./custom-monitoring.yaml

次の YAML には、カスタムシグナルを使用したモデル監視の定義が含まれています。 コードに関して注意すべき点:

  • 既にコンポーネントを作成し、カスタム シグナル定義を使用して Azure Machine Learning に登録していることを前提としています。
  • 登録済みのカスタム シグナル コンポーネントの component_idazureml:my_custom_signal:1.0.0 です。
  • データ コレクターを使用してデータを収集した場合は、“pre_processing_component” プロパティを省略できます。 前処理コンポーネントを使用して、データ コレクターによって収集されない運用データを前処理する場合は、それを指定できます。
# custom-monitoring.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: my-custom-signal
trigger:
  type: recurrence
  frequency: day # can be minute, hour, day, week, month
  interval: 7 # #every day
create_monitor:
  compute:
    instance_type: "standard_e4s_v3"
    runtime_version: "3.3"
  monitoring_signals:
    customSignal:
      type: custom
      component_id: azureml:my_custom_signal:1.0.0
      input_data:
        production_data:
          input_data:
            type: uri_folder
            path: azureml:my_production_data:1
          data_context: test
          data_window:
            lookback_window_size: P30D
            lookback_window_offset: P7D
          pre_processing_component: azureml:custom_preprocessor:1.0.0
      metric_thresholds:
        - metric_name: std_deviation
          threshold: 2
  alert_notification:
    emails:
      - abc@example.com

モニタリング結果を使用する

モデル モニターを構成し、最初の実行が完了したら、Azure Machine Learning スタジオの [モニタリング] タブに戻って結果を表示できます。

  • メインの [モニタリング] ビューで、モデル モニターの名前を選択して、[モニターの概要] ページを表示します。 このページには、対応するモデル、エンドポイント、デプロイと、構成したシグナルに関する詳細が表示されます。 次の図は、データ ドリフトとデータ品質シグナルを含むモニタリング ダッシュボードを示しています。 構成したモニタリング シグナルによっては、ダッシュボードの外観が異なる場合があります。

    監視ダッシュボードを示すスクリーンショット。

  • ダッシュボードの [通知] セクションを見て、各シグナルについて、それぞれのメトリックに対して構成されたしきい値に違反した特徴量を確認します。

  • [data_drift] を選択して、データ ドリフトの詳細ページに移動します。 詳細ページでは、モニタリング構成に含める各数値およびカテゴリの特徴量のデータ ドリフト メトリック値を確認できます。 モニターに複数の実行がある場合は、各特徴量の近似曲線が表示されます。

    データ ドリフト シグナルの詳細ページを示すスクリーンショット。

  • 個々の特徴量を詳細に表示するには、参照分布と比較した生産分布を表示する特徴量の名前を選択します。 このビューでは、その特定の特徴量の時間の経過に伴うドリフトを追跡することもできます。

    個々の特徴量のデータ ドリフトの詳細を示すスクリーンショット。

  • モニタリング ダッシュボードに戻り、[data_quality] を選択してデータ品質シグナル ページを表示します。 このページでは、監視している各特徴量の null 値率、範囲外率、データ型のエラー率を確認できます。

    データ品質シグナルの詳細ページを示すスクリーンショット。

モデルモニタリングは継続的なプロセスです。 Azure Machine Learning モデルモニタリングを使用すると、複数のモニタリング シグナルを構成して、運用環境のモデルのパフォーマンスを幅広く確認できます。

Azure Machine Learning モデルモニタリングを Azure Event Grid と統合する

Azure Machine Learning モデルモニタリングによって生成されたイベントを使用して、Azure Event Grid でイベントドリブン アプリケーション、プロセス、または CI/CD ワークフローを設定できます。 Azure Event Hubs、Azure Functions、ロジック アプリなど、さまざまなイベント ハンドラーを通じてイベントを使用できます。 モニターによって検出されたドリフトに基づき、モデルを再トレーニングして再デプロイする機械学習パイプラインを設定するなど、プログラムによってアクションを実行できます。

Azure Machine Learning モデルモニタリングと Azure Event Grid の統合を開始するには:

  1. Azure portal での設定」の手順に従います。 イベント サブスクリプション に名前 (MonitoringEvent など) を指定し、[イベントの種類] の下にある [変更済みの実行状態] ボックスのみを選択します。

    警告

    [イベントの種類] には必ず [変更済みの実行状態] を選択してください。 これは Azure Machine Learning モデルモニタリングではなく、データ ドリフト v1 に適用されるため、[検出されたデータセット ドリフト] は選択しないでください。

  2. フィルター処理とイベントのサブスクライブ」の手順に従って、シナリオのイベント フィルター処理を設定します。 [フィルター] タブに移動し、[高度なフィルター] の下に次のキー 演算子を追加します。

    • キー: data.RunTags.azureml_modelmonitor_threshold_breached
    • : メトリックのしきい値に違反する 1 つ以上の特徴量が原因で失敗した
    • 演算子: 次を含む文字列

    このフィルターを使用すると、Azure Machine Learning ワークスペース内のモニターの実行状態が (完了から失敗、または失敗から完了に) 変わると、イベントが生成されます。

  3. モニタリング レベルでフィルターするには、[高度なフィルター] の下に次のキー演算子を追加します。

    • キー: data.RunTags.azureml_modelmonitor_threshold_breached
    • : your_monitor_name_signal_name
    • 演算子: 次を含む文字列

    your_monitor_name_signal_name が、イベントをフィルター処理する特定のモニター内のシグナルの名前であることを確認します。 たとえば、credit_card_fraud_monitor_data_drift のようにします。 このフィルターを機能させるには、この文字列がモニタリング シグナルの名前と一致している必要があります。 この場合は、モニター名とシグナル名の両方を使用してシグナルに名前を付けます。

  4. イベント サブスクリプション の構成が完了したら、イベント ハンドラーとして機能する目的のエンドポイント (Azure Event Hubs など) を選択します。

  5. イベントがキャプチャされたら、エンドポイント ページからイベントを表示できます。

    エンドポイント ページから表示されたイベントを示すスクリーンショット。

Azure Monitor メトリック タブでイベントを表示することもできます。

[Azure Monitor のメトリック] タブから表示されたイベントを示すスクリーンショット。