運用環境にデプロイされたモデルのパフォーマンスを監視する
適用対象: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 CLI
- Python SDK
-
[ スタジオ](#tab/azure-studio)
この記事の手順に従う前に、次の前提条件が満たされていることをご確認ください。
Azure CLI と Azure CLI の
ml
拡張機能。 詳しくは、CLI (v2) のインストール、設定、使用に関するページをご覧ください。重要
この記事の CLI の例では、Bash (または互換性のある) シェルを使用していることを前提としています。 たとえば、Linux システムや Linux 用 Windows サブシステムなどです。
Azure Machine Learning ワークスペース。 お持ちでない場合は、CLI (v2) のインストール、セットアップ、使用に関する記事の手順を使用して作成します。
Azure ロールベースのアクセス制御 (Azure RBAC) は、Azure Machine Learning の操作に対するアクセスを許可するために使用されます。 この記事の手順を実行するには、ユーザー アカウントに、Azure Machine Learning ワークスペースの所有者か共同作成者ロール、または
Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*
を許可するカスタム ロールを割り当てる必要があります。 詳細については、「Azure Machine Learning ワークスペースへのアクセスの管理」を参照してください。Azure Machine Learning オンライン エンドポイント (マネージド オンライン エンドポイントまたは Kubernetes オンライン エンドポイント) にデプロイされたモデルを監視するには、次の点を確認します。
モデルが Azure Machine Learning オンライン エンドポイントに既にデプロイされている。 マネージド オンライン エンドポイントと Kubernetes オンライン エンドポイントの両方がサポートされている。 Azure Machine Learning オンライン エンドポイントにデプロイされたモデルがない場合は、「オンライン エンドポイントを使用して機械学習モデルをデプロイおよびスコア付けする」をご覧ください。
モデル デプロイのデータ収集を有効にする。 Azure Machine Learning オンライン エンドポイントのデプロイ手順の間に、データ収集を有効にできます。 詳しくは、リアルタイム エンドポイントにデプロイされたモデルからの運用データの収集に関する記事をご覧ください。
Azure Machine Learning バッチ エンドポイントにデプロイされたモデル、または Azure Machine Learning の外部にデプロイされたモデルを監視するには、次の点を確認します。
- 運用データを収集し、Azure Machine Learning データ資産として登録する手段がある。
- モデルモニタリングのために、登録済みのデータ資産を継続的に更新する。
- 系列の追跡のため、Azure Machine Learning ワークスペースにモデルを登録する。(推奨)
重要
モデルモニタリング ジョブは、 Standard_E4s_v3
、Standard_E8s_v3
、Standard_E16s_v3
、Standard_E32s_v3
、Standard_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 CLI
- Python SDK
-
[ スタジオ](#tab/azure-studio)
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、またはスタジオを使って、モデルモニタリングの高度なセットアップを行うことができます。
- Azure CLI
- Python SDK
-
[ スタジオ](#tab/azure-studio)
次の 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 行がまとめてバッチ処理され、correlationid
が test
である場合、行 1 の ID は test_0
に、行 2 の ID は test_1
に、行 3 の ID は test_2
になります。 グラウンド トゥルース データセットに、収集された運用推論モデル出力と一致する一意の ID が確実に含まれるようにするために、各 correlationid
のインデックスを適切に作成するようにしてください。 ログに記録された JSON オブジェクトに 1 行しかない場合、correlationid
は correlationid_0
になります。
このインデックス作成が使用されないようにするには、一意の ID を Azure Machine Learning データ コレクターでログ記録している Pandas DataFrame 内の独自の列にログ記録することをお勧めします。 その後、モデル監視の構成で、この列の名前を指定してモデル出力データをグラウンド トゥルース データと結合します。 両方のデータセット内の行ごとの ID が同じである限り、Azure Machine Learning のモデル監視ではモデル パフォーマンス監視を実行できます。
モデルのパフォーマンスを監視するためのワークフローの例
モデル パフォーマンス監視に関連した概念を理解するために、次のワークフローの例を考えてみます。 クレジット カードのトランザクションが不正かどうかを予測するモデルをデプロイしている場合は、次の手順に従ってモデルのパフォーマンスを監視できます。
- データ コレクターを使用してモデルの運用推論データ (入力および出力データ) を収集するようにデプロイを構成します。 たとえば、出力データが列
is_fraud
に格納されるとします。 - 収集された推論データの行ごとに、一意の ID をログに記録します。 この一意の ID はアプリケーションから取得することも、ログに記録された JSON オブジェクトごとに Azure Machine Learning によって一意に生成される
correlationid
を使用することもできます。 - 後で、グラウンド トゥルース (または実際の)
is_fraud
データが使用可能になると、それもまたログに記録され、モデルの出力と共にログに記録されたのと同じ一意の ID にマップされます。 - このグラウンド トゥルース
is_fraud
データもまた収集および保持され、Azure Machine Learning にデータ資産として登録されます。 - 一意の ID 列を使用して、モデルの運用推論およびグラウンド トゥルース データ資産を結合するモデル パフォーマンス監視シグナルを作成します。
- 最後に、モデル パフォーマンス メトリックを計算します。
モデル パフォーマンス監視の前提条件が満たされたら、次の 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 には、group
、metric_name
、metric_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_id
はazureml: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 の統合を開始するには:
「Azure portal での設定」の手順に従います。 イベント サブスクリプション に名前 (MonitoringEvent など) を指定し、[イベントの種類] の下にある [変更済みの実行状態] ボックスのみを選択します。
警告
[イベントの種類] には必ず [変更済みの実行状態] を選択してください。 これは Azure Machine Learning モデルモニタリングではなく、データ ドリフト v1 に適用されるため、[検出されたデータセット ドリフト] は選択しないでください。
「フィルター処理とイベントのサブスクライブ」の手順に従って、シナリオのイベント フィルター処理を設定します。 [フィルター] タブに移動し、[高度なフィルター] の下に次のキー 、演算子、値を追加します。
- キー:
data.RunTags.azureml_modelmonitor_threshold_breached
- 値: メトリックのしきい値に違反する 1 つ以上の特徴量が原因で失敗した
- 演算子: 次を含む文字列
このフィルターを使用すると、Azure Machine Learning ワークスペース内のモニターの実行状態が (完了から失敗、または失敗から完了に) 変わると、イベントが生成されます。
- キー:
モニタリング レベルでフィルターするには、[高度なフィルター] の下に次のキー、演算子、値を追加します。
- キー:
data.RunTags.azureml_modelmonitor_threshold_breached
- 値:
your_monitor_name_signal_name
- 演算子: 次を含む文字列
your_monitor_name_signal_name
が、イベントをフィルター処理する特定のモニター内のシグナルの名前であることを確認します。 たとえば、credit_card_fraud_monitor_data_drift
のようにします。 このフィルターを機能させるには、この文字列がモニタリング シグナルの名前と一致している必要があります。 この場合は、モニター名とシグナル名の両方を使用してシグナルに名前を付けます。- キー:
イベント サブスクリプション の構成が完了したら、イベント ハンドラーとして機能する目的のエンドポイント (Azure Event Hubs など) を選択します。
イベントがキャプチャされたら、エンドポイント ページからイベントを表示できます。
Azure Monitor メトリック タブでイベントを表示することもできます。