このページでは、Vertex Explainable AI で Vertex AI Model Monitoring を使用して、カテゴリ入力特徴と数値入力特徴の特徴アトリビューションのスキューとドリフトを検出する方法について説明します。
特徴アトリビューション ベースのモニタリングの概要
特徴アトリビューションは、モデル内の各特徴が各インスタンスの予測にどの程度影響を及ぼしたかを示します。予測をリクエストすると、モデルに適した予測値を得られます。説明をリクエストすると、予測に加えて、特徴アトリビューションの情報を得られます。
アトリビューション スコアは、その特徴のモデルの予測への寄与度に比例します。これらは通常プラスマイナスの符号が付いており、ある特徴が予測の確度を上げたか下げたかを示します。すべての特徴のアトリビューションはモデルの予測スコアに加算される必要があります。
Model Monitoring は、特徴アトリビューションをモニタリングすることで、モデルの予測に対する特徴の影響の推移を追跡します。多くの場合、主要な特徴アトリビューション スコアの変化は、モデルの予測の正確さに影響する変化があった可能性を示します。
特徴アトリビューション スコアの計算方法については、特徴アトリビューション方式をご覧ください。
特徴アトリビューションのトレーニング サービング スキューと予測ドリフト
Vertex Explainable AI が有効になっているモデルのモニタリング ジョブを作成すると、Model Monitoring は特徴分布と特徴アトリビューションの両方でスキューまたはドリフトをモニタリングします。特徴分布のスキューとドリフトについては、Vertex AI Model Monitoring の概要をご覧ください。
特徴アトリビューションの場合:
トレーニング サービング スキューは、本番環境での特徴アトリビューション スコアが元のトレーニング データ内の特徴アトリビューション スコアから逸脱した場合に発生します。
予測ドリフトは、本番環境での特徴アトリビューション スコアが経時的に大きく変化した場合に発生します。
モデルに元のトレーニング データセットを提供する場合は、スキュー検出を有効にできます。それ以外の場合は、ドリフト検出を有効にする必要があります。スキュー検出とドリフト検出の両方を有効にできます。
前提条件
Vertex Explainable AI で Model Monitoring を使用するには、次の手順を行います。
スキュー検出を有効にする場合は、トレーニング データ、またはトレーニング データセットのバッチ説明ジョブの出力を Cloud Storage または BigQuery にアップロードします。データの URI リンクを取得します。ドリフト検出の場合、トレーニング データや説明ベースラインは必要ありません。
Vertex AI で、表形式の AutoML またはインポートされた表形式のカスタム トレーニングのいずれかのタイプのモデルを使用できるようにします。
AutoML 表形式のモデルには Vertex Explainable AI が自動的に構成されているため、スキュー検出またはドリフト検出を有効にするに進んでください。分類モデルと回帰モデルのみがサポートされています。
インポートしたカスタム トレーニング モデルは、モデルの作成、インポート、またはデプロイを行うときに、Vertex Explainable AI 用に構成する必要があります。
モデルの作成、インポート、またはデプロイを行うときに、Vertex Explainable AI を使用するようにモデルを構成します。モデルの
ExplanationSpec.ExplanationParametersフィールドに値が入力されている必要があります。省略可: カスタム トレーニングされたモデルの場合は、モデルの分析インスタンス スキーマを Cloud Storage にアップロードします。 Model Monitoring では、モニタリング プロセスを開始し、スキュー検出のベースライン分布を計算するためにスキーマが必要です。ジョブの作成時にスキーマを指定しない場合、Model Monitoring が、モデルが受け取った最初の 1,000 件の予測リクエストからスキーマを自動的に解析できるようになるまで、ジョブは保留状態のままになります。
スキュー検出またはドリフト検出を有効にする
スキュー検出またはドリフト検出を設定するには、モデルのデプロイのモニタリング ジョブを作成します。
コンソール
Google Cloud コンソールを使用してモデルのデプロイのモニタリング ジョブを作成するには、エンドポイントを作成します。
Google Cloud Console で、Vertex AI の [エンドポイント] ページに移動します。
[エンドポイントの作成] をクリックします。
[新しいエンドポイント] ペインで、エンドポイントの名前を指定して、リージョンを設定します。
[続行] をクリックします。
[モデル名] フィールドで、インポートされたカスタム トレーニングまたは表形式の AutoML モデルを選択します。
[バージョン] フィールドで、モデルのバージョンを選択します。
[続行] をクリックします。
[モデルのモニタリング] ペインで、[このエンドポイントのモデルのモニタリングを有効にする] がオンになっていることを確認します。構成したモニタリングの設定は、このエンドポイントにデプロイされたすべてのモデルに適用されます。
[モニタリング ジョブの表示名] を入力します。
[モニタリング ウィンドウの長さ] を入力します。
[通知メール] に、モデルがアラートのしきい値を超えたときにアラートを受け取るメールアドレスを、カンマ区切り形式で 1 つ以上入力します。
省略可: 通知チャンネルの場合、モデルがアラートのしきい値を超えたときにアラートを受け取るには、Cloud Monitoring チャンネルを追加します。[Manage notification channels] をクリックして、既存の Cloud Monitoring チャンネルを選択するか、新しい Cloud Monitoring チャンネルを作成できます。コンソールでは、PagerDuty、Slack、Pub/Sub 通知チャネルがサポートされています。
[サンプリング レート] を入力します。
省略可: [予測入力スキーマ] と [分析入力スキーマ] を入力します。
[続行] をクリックします。[モニタリングの目標] ペインが開き、スキュー検出またはドリフト検出のオプションが表示されます。
スキュー検出
- [トレーニング サービング スキューの検出] を選択します。
- [トレーニング データソース] で、トレーニング データソースを入力します。
- [ターゲット列] に、モデルをトレーニングして予測するトレーニング データの列名を入力します。このフィールドはモニタリング分析から除外されます。
- （省略可）[アラートのしきい値] で、アラートをトリガーするしきい値を指定します。しきい値の形式については、 ヘルプアイコンの上にポインタを置いてください。
- [作成] をクリックします。
ドリフト検出
- [予測ドリフト検出] を選択します。
- （省略可）[アラートのしきい値] で、アラートをトリガーするしきい値を指定します。しきい値の形式については、 ヘルプアイコンの上にポインタを置いてください。
- [作成] をクリックします。
gcloud
gcloud CLI を使用してモデルデプロイのモニタリング ジョブを作成するには、まず、エンドポイントにモデルをデプロイします。
モニタリング ジョブの構成は、エンドポイントにデプロイされたすべてのモデルに適用されます。
gcloud ai model-monitoring-jobs create コマンドを実行します。
gcloud ai model-monitoring-jobs create \ --project=PROJECT_ID \ --region=REGION \ --display-name=MONITORING_JOB_NAME \ --emails=EMAIL_ADDRESS_1,EMAIL_ADDRESS_2 \ --endpoint=ENDPOINT_ID \ --feature-thresholds=FEATURE_1=THRESHOLD_1,FEATURE_2=THRESHOLD_2 \ --prediction-sampling-rate=SAMPLING_RATE \ --monitoring-frequency=MONITORING_FREQUENCY \ --target-field=TARGET_FIELD \ --bigquery-uri=BIGQUERY_URI
ここで
PROJECT_ID は、Google Cloud プロジェクトの ID です。例:
my-projectREGION は、モニタリング ジョブのロケーションです。例:
us-central1MONITORING_JOB_NAME は、モニタリング ジョブの名前です。例:
my-jobEMAIL_ADDRESS は、Model Monitoring からアラートを受け取るメールアドレスです。例:
example@example.comENDPOINT_ID は、モデルがデプロイされるエンドポイントの ID です。例:
1234567890987654321。省略可: FEATURE_1=THRESHOLD_1 は、モニタリングする各特徴のアラートしきい値です。たとえば、
Age=0.4を指定した場合、Age特徴の入力分布とベースライン分布の間の [統計的距離][stat-distance] が 0.4 を超えると、Model Monitoring によってアラートがログに記録されます。省略可: SAMPLING_RATE は、ログに記録する受信予測リクエストの割合です。例:
0.5。指定しない場合、Model Monitoring はすべての予測リクエストをログに記録します。省略可: MONITORING_FREQUENCY は、最近ログに記録された入力に対してモニタリング ジョブを実行する頻度です。最小粒度は 1 時間です。デフォルトは 24 時間です。例:
2（スキュー検出の場合のみ必須）TARGET_FIELD は、モデルによって予測されるフィールドです。このフィールドはモニタリング分析から除外されます。例:
housing-price（スキュー検出の場合のみ必須）BIGQUERY_URI は、次の形式で BigQuery に保存されているトレーニング データセットへのリンクです。
bq://\PROJECT.\DATASET.\TABLE
例:
bq://\my-project.\housing-data.\san-franciscobigquery-uriフラグは、トレーニング データセットへの代替リンクに置き換えることができます。Cloud Storage バケットに保存されている CSV ファイルの場合は、
--data-format=csv --gcs-uris=gs://BUCKET_NAME/OBJECT_NAMEを使用します。Cloud Storage バケットに保存されている TFRecord ファイルの場合は、
--data-format=tf-record --gcs-uris=gs://BUCKET_NAME/OBJECT_NAMEを使用します。[表形式の AutoML マネージド データセット][dataset-id]の場合は、
--dataset=DATASET_IDを使用します。
Python SDK
エンドツーエンドの Model Monitoring API ワークフローの詳細については、サンプル ノートブックをご覧ください。
REST API
まだデプロイしていない場合は、エンドポイントにモデルをデプロイします。
エンドポイント情報を取得して、デプロイされたモデルのモデル ID を取得します。DEPLOYED_MODEL_ID はレスポンスの
deployedModels.id値です。モデル モニタリング ジョブ リクエストを作成します。ここでは、アトリビューションを使用したドリフト検出の基本的なモニタリング ジョブの作成方法について説明します。スキュー検出の場合は、リクエスト JSON 本文の
explanationConfigフィールドにexplanationBaselineオブジェクトを追加し、次のいずれかを指定します。トレーニング データセットのバッチ説明ジョブの出力。
サービスが
BatchExplainジョブを実行してベースラインを生成するTrainingDataset。
詳細については、モニタリング ジョブのリファレンスをご覧ください。
リクエストのデータを使用する前に、次のように置き換えます。
- PROJECT_ID: Google Cloud プロジェクトの ID。例:
my-project - LOCATION: モニタリング ジョブのロケーション。例:
us-central1 - MONITORING_JOB_NAME: モニタリング ジョブの名前。例:
my-job - PROJECT_NUMBER: Google Cloud プロジェクトの番号。例:
1234567890 - ENDPOINT_ID: モデルがデプロイされるエンドポイントの ID。例:
1234567890 - DEPLOYED_MODEL_ID: デプロイされたモデルの ID。
- FEATURE:VALUE は、モニタリングする各特徴のアラートしきい値です（例:
"housing-latitude": {"value": 0.4}）。入力特徴の分布と対応するベースライン間の統計的距離が指定のしきい値を超えると、アラートがログに記録されます。デフォルトでは、すべてのカテゴリ特徴と数値特徴がモニタリングされ、しきい値は 0.3 になります。 - EMAIL_ADDRESS: Model Monitoring からアラートを受け取るメールアドレス。例:
example@example.com - NOTIFICATION_CHANNELS:
Model Monitoring からアラートを受け取る Cloud Monitoring 通知チャネルのリスト。通知チャネルのリソース名を使用します。これはプロジェクトの通知チャネルを一覧表示することで取得できます。例:
"projects/my-project/notificationChannels/1355376463305411567", "projects/my-project/notificationChannels/1355376463305411568"。
リクエストの本文（JSON）:
{ "displayName":"MONITORING_JOB_NAME", "endpoint":"projects/PROJECT_NUMBER/locations/LOCATION/endpoints/ENDPOINT_ID", "modelDeploymentMonitoringObjectiveConfigs": { "deployedModelId": "DEPLOYED_MODEL_ID", "objectiveConfig": { "predictionDriftDetectionConfig": { "driftThresholds": { "FEATURE_1": { "value": VALUE_1 }, "FEATURE_2": { "value": VALUE_2 } } }, "explanationConfig": { "enableFeatureAttributes": true } } }, "loggingSamplingStrategy": { "randomSampleConfig": { "sampleRate": 0.5, }, }, "modelDeploymentMonitoringScheduleConfig": { "monitorInterval": { "seconds": 3600, }, }, "modelMonitoringAlertConfig": { "emailAlertConfig": { "userEmails": ["EMAIL_ADDRESS"], }, "notificationChannels": [NOTIFICATION_CHANNELS] } }リクエストを送信するには、次のいずれかのオプションを開きます。
次のような JSON レスポンスが返されます。
{ "name": "projects/PROJECT_NUMBER/locations/LOCATION/modelDeploymentMonitoringJobs/MONITORING_JOB_NUMBER", ... "state": "JOB_STATE_PENDING", "scheduleState": "OFFLINE", ... "bigqueryTables": [ { "logSource": "SERVING", "logType": "PREDICT", "bigqueryTablePath": "bq://PROJECT_ID.model_deployment_monitoring_8451189418714202112.serving_predict" } ], ... }
モニタリング ジョブが作成されると、Model Monitoring は、PROJECT_ID.model_deployment_monitoring_ENDPOINT_ID.serving_predict という名前の生成された BigQuery テーブルに受信予測リクエストを記録します。リクエスト / レスポンス ロギングが有効になっている場合、Model Monitoring は、リクエスト / レスポンス ロギングと同じ BigQuery テーブルに受信リクエストを記録します。
次の省略可能なタスクを行う方法については、Model Monitoring の使用をご覧ください。
Model Monitoring ジョブを更新する
モデル モニタリング ジョブのアラートを構成する。
異常値に対するアラートを構成する。
特徴アトリビューションのスキューデータとドリフトデータを分析する
Google Cloud コンソールを使用すると、モニタリング対象の各特徴の特長アトリビューションを可視化し、スキューやドリフトの原因となった変化を特定できます。特徴分布データの分析については、スキューデータとドリフトデータを分析するをご覧ください。
安定版の機械学習システムでは、特徴量の相対的な重要度は時間の経過とともに比較的安定します。重要な特徴の重要度が低い場合、その特徴についてなんらかの変更が発生した可能性があります。特徴量のドリフトまたはスキューの一般的な原因は次のとおりです。
- データソースの変更。
- データスキーマとロギングの変更。
- エンドユーザー ミックスや行動の変化（季節的な変化や外れ値イベントなど）。
- 別の機械学習モデルによって生成された特徴のアップストリームの変更。以下に例を示します。
- カバレッジ（全体または個別の分類値）の増減を引き起こすモデルの更新。
- モデルのパフォーマンスの変化（特徴の意味が変化する）。
- データ パイプラインの更新。全体的なカバレッジが低下することがあります。
特徴アトリビューションのスキューとドリフトデータを分析する際は、次の点も考慮してください。
重要度の高い特徴を追跡する。ある特徴のアトリビューションが大きく変化した場合は、その特徴の予測に対する寄与度が変化したことを意味します。予測スコアは特徴量の寄与の合計と等しいため、アトリビューションの大きなドリフト（特に重要な特徴の場合）は、通常、モデル予測の大きなドリフトを示します。
すべての特徴表現をモニタリングする。特徴アトリビューションは、基になる特徴タイプにかかわらず、常に数値です。その加法的な性質から、多次元的な特徴（エンベディングなど）のアトリビューションを次元を越えて合計することで、単一の数値に集約できます。これにより、すべての特徴タイプで標準的な一変量ドリフト検出方法を使用できます。
特徴の相互作用を考慮する。ある特徴のアトリビューションは、その特徴単独での予測に対する寄与度と、他の特徴との相互作用を通じた寄与度の両方を説明します。ある特徴と他の特徴との相互作用が変化すると、その特徴の周辺分布が変わらなくても、特徴のアトリビューションの分布が変化します。
特徴グループをモニタリングする。アトリビューションは加法的なので、関連する複数の特徴のアトリビューションを加算して特徴グループのアトリビューションを得ることができます。たとえば、クレジット融資モデルでは、融資タイプに関連するすべての特徴（たとえば、「grad」、「sub_grad」、「purpose」）のアトリビューションを加算して単一の融資アトリビューションを算出できます。その後、このグループレベルのアトリビューションを追跡して特徴グループの変化をモニタリングできます。
次のステップ
- API ドキュメントに従って Model Monitoring を使用する。
- gcloud CLI ドキュメントに従って Model Monitoring を使用する。
- Colab でサンプル ノートブックを試すか、GitHub で表示する。
- Model Monitoring がトレーニング / サービング スキューと予測ドリフトを計算する方法を学習する。