Überwachen der Leistung von Modellen, die in der Produktion bereitgestellt werden
GILT FÜR:Azure CLI ML-Erweiterung v2 (aktuell)Python SDK azure-ai-ml v2 (aktuell)
Erfahren Sie, wie Sie die Modellüberwachung von Azure Machine Learning verwenden, um die Leistung von Machine Learning-Modellen in der Produktion kontinuierlich nachzuverfolgen. Mit der Modellüberwachung erhalten Sie eine umfassende Übersicht über Überwachungssignale und Warnungen zu potenziellen Problemen. Wenn Sie Signale und Leistungsmetriken von Modellen in der Produktion überwachen, können Sie die damit verbundenen Risiken kritisch bewerten und blinde Flecken identifizieren, die sich negativ auf Ihr Unternehmen auswirken könnten.
In diesem Artikel erfahren Sie, wie Sie folgende Aufgaben ausführen:
- Einrichten von sofort einsatzbereiten und erweiterten Überwachungen für Modelle, die für Azure Machine Learning-Online-Endpunkte bereitgestellt werden
- Überwachen von Leistungsmetriken für Modelle in der Produktion
- Überwachung für Modelle einrichten, die außerhalb von Azure Machine Learning oder an Batch-Endpunkten von Azure Machine Learning bereitgestellt werden
- Einrichten der Modellüberwachung mit benutzerdefinierten Signalen und Metriken
- Interpretieren von Überwachungsergebnissen
- Integrieren der Azure Machine Learning-Modellüberwachung in Azure Event Grid
Voraussetzungen
Stellen Sie vor dem Ausführen der Schritte in diesem Artikel sicher, dass Sie über die folgenden erforderlichen Komponenten verfügen:
Die Azure CLI und die
ml
-Erweiterung der Azure CLI. Weitere Informationen finden Sie unter Installieren, Einrichten und Verwenden der CLI (v2).Wichtig
In den CLI-Beispielen in diesem Artikel wird davon ausgegangen, dass Sie die Bash-Shell (oder eine kompatible Shell) verwenden, beispielsweise über ein Linux-System oder ein Windows-Subsystem für Linux.
Ein Azure Machine Learning-Arbeitsbereich. Sofern noch nicht vorhanden, führen Sie die Schritte im Abschnitt Installieren, Einrichten und Verwenden der CLI (v2) aus, um einen Arbeitsbereich zu erstellen.
Die rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) wird verwendet, um Zugriff auf Vorgänge in Azure Machine Learning zu gewähren. Um die Schritte in diesem Artikel auszuführen, muss Ihr Benutzerkonto der Rolle Besitzer oder Mitwirkender für den Azure Machine Learning-Arbeitsbereich bzw. einer benutzerdefinierte Rolle zugewiesen werden, die
Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*
zulässt. Weitere Informationen finden Sie unter Zugriff auf einen Azure Machine Learning-Arbeitsbereich verwalten.Zum Überwachen eines Modells, das auf einem Azure Machine Learning-Onlineendpunkt (verwalteter Onlineendpunkt oder Kubernetes-Onlineendpunkt) bereitgestellt wird, müssen Sie Folgendes beachten:
Ein Modell muss bereits auf einem Azure Machine Learning-Onlineendpunkt bereitgestellt werden. Es werden sowohl verwaltete Onlineendpunkte als auch Kubernetes-Onlineendpunkte unterstützt. Wenn Sie kein Modell auf einem Azure Machine Learning-Onlineendpunkt bereitgestellt haben, finden Sie weitere Informationen unter Bereitstellen und Bewerten eines Machine Learning-Modells mithilfe eines Onlineendpunkts.
Aktivieren Sie die Datensammlung für Ihre Modellimplementierung. Sie können die Datensammlung während des Bereitstellungsschritts für Azure Machine Learning-Onlineendpunkte aktivieren. Weitere Informationen finden Sie unter Sammeln von Produktionsdaten von Modellen, die an einem Echtzeitendpunkt bereitgestellt werden.
Zum Überwachen eines Modells, das auf einem Azure Machine Learning-Batchendpunkt oder außerhalb von Azure Machine Learning bereitgestellt wird, müssen Sie Folgendes beachten:
- Sie benötigen eine Möglichkeit, Produktionsdaten zu sammeln und als Azure Machine Learning-Datenobjekt zu registrieren.
- Aktualisieren Sie die registrierte Datenressource kontinuierlich für die Modellüberwachung.
- (Empfohlen) Registrieren Sie das Modell in einem Azure Machine Learning-Arbeitsbereich für die Nachverfolgung der Datenherkunft.
Wichtig
Modellüberwachungsaufträge werden für serverlose Spark-Computepools mit Unterstützung für die folgenden VM-Instanztypen geplant: Standard_E4s_v3
, Standard_E8s_v3
, Standard_E16s_v3
, Standard_E32s_v3
und Standard_E64s_v3
. Sie können den VM-Instanztyp mit der create_monitor.compute.instance_type
-Eigenschaft in Ihrer YAML-Konfiguration oder in der Dropdownliste im Azure Machine Learning Studio auswählen.
Einrichten der sofort einsatzbereiten Modellüberwachung
Angenommen, Sie stellen Ihr Modell für die Produktion in einem Azure Machine Learning-Onlineendpunkt bereit und aktivieren die Datensammlung zur Bereitstellungszeit. In diesem Szenario sammelt Azure Machine Learning Produktionsinferenz-Daten und speichert sie automatisch in Microsoft Azure Blob Storage. Anschließend können Sie die Azure Machine Learning-Modellüberwachung verwenden, um diese Produktionsinferenz-Daten kontinuierlich zu überwachen.
Sie können die Azure CLI, das Python SDK oder das Studio für eine sofort einsatzbereite Einrichtung der Modellüberwachung verwenden. Die vordefinierte Modellüberwachungskonfiguration bietet die folgenden Überwachungsfunktionen:
- Azure Machine Learning erkennt automatisch das Produktionsinferenz-Dataset, das einer Azure Machine Learning-Onlinebereitstellung zugeordnet ist, und verwendet das Dataset für die Modellüberwachung.
- Das Vergleichsreferenz-Dataset wird als das zuletzt verwendete Produktionsinferenz-Dataset festgelegt.
- Bei der Einrichtung der Überwachung werden die integrierten Überwachungssignale automatisch einbezogen und nachverfolgt: Datendrift, Vorhersagedrift und Datenqualität. Für jedes Überwachungssignal verwendet Azure Machine Learning Folgendes:
- Das Produktionsinferenz-Dataset der jüngsten Vergangenheit als Vergleichsreferenz-Dataset.
- Intelligente Standardwerte für Metriken und Schwellenwerte.
- Ein Überwachungsauftrag wird so geplant, dass er täglich um 3:15 Uhr (für dieses Beispiel) ausgeführt wird, um Überwachungssignale zu erfassen und jedes Ergebnis der Metrik anhand des entsprechenden Schwellenwerts auszuwerten. Wenn ein Schwellenwert überschritten wird, sendet Azure Machine Learning standardmäßig eine Benachrichtigungs-E-Mail an den Benutzer, der die Überwachung eingerichtet hat.
Die Azure Machine Learning-Modellüberwachung verwendet az ml schedule
zum Planen eines Überwachungsauftrags. Mit dem folgenden CLI-Befehl und der folgenden YAML-Definition können Sie eine sofort einsatzbereite Modellüberwachung erstellen:
az ml schedule create -f ./out-of-box-monitoring.yaml
Der folgende YAML-Code enthält die Definition für die sofort einsatzbereite Modellüberwachung.
# 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
Einrichten der erweiterten Modellüberwachung
Azure Machine Learning bietet viele Funktionen für die kontinuierliche Modellüberwachung. Eine umfassende Liste dieser Funktionen finden Sie unter Funktionen der Modellüberwachung. In vielen Fällen müssen Sie die Modellüberwachung mit erweiterten Überwachungsfunktionen einrichten. In den folgenden Abschnitten richten wir die Modellüberwachung mit den folgenden Funktionen ein:
- Verwendung mehrerer Überwachungssignale für eine umfassende Ansicht
- Verwendung von Trainingsdaten für verlaufsbezogene Modelle oder Validierungsdaten als Vergleichsreferenz-Dataset.
- Überwachung der wichtigsten N-Features und einzelner Features.
Konfigurieren der Featurerelevanz
Die Feature-Wichtigkeit stellt die relative Wichtigkeit jedes Eingabefeatures für die Ausgabe eines Modells dar. Beispielsweise kann temperature
für die Vorhersage eines Modells im Vergleich zu elevation
wichtiger sein. Das Aktivieren von Feature-Wichtigkeit kann Ihnen Einblicke geben, welche Features besser nicht driften oder welche Probleme mit der Datenqualität in der Produktion besser nicht vorkommen sollten.
Um die Feature-Wichtigkeit mit jedem Ihrer Signale (z. B. Datenabweichung oder Datenqualität) zu aktivieren, müssen Sie Folgendes bereitstellen:
- Ihr Schulungsdatensatz als
reference_data
-Dataset. - Die
reference_data.data_column_names.target_column
-Eigenschaft, bei der es sich um den Namen der Ausgabe-/Vorhersagespalte Ihres Modells handelt.
Nach der Aktivierung der Feature-Wichtigkeit sehen Sie eine Feature-Wichtigkeit für jedes Feature, das Sie in der Azure Machine Learning-Modellüberwachungs-Studio-Benutzeroberfläche überwachen.
Sie können die Azure CLI, das Python SDK oder das Studio für die erweiterte Einrichtung der Modellüberwachung verwenden.
Mit dem folgenden CLI-Befehl und der folgenden YAML-Definition erstellen Sie eine erweiterte Einrichtung für die Modellüberwachung:
az ml schedule create -f ./advanced-model-monitoring.yaml
Der folgende YAML-Code enthält die Definition für die erweiterte Modellüberwachung.
# 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
Einrichten der Modellleistungsüberwachung
Mithilfe der Azure Machine Learning-Modellüberwachung können Sie die Leistung Ihrer Modelle in der Produktion nachverfolgen, indem Sie ihre Leistungsmetriken berechnen. Die folgenden Modellleistungsmetriken werden derzeit unterstützt:
Für Klassifizierungsmodelle:
- Präzision
- Genauigkeit
- Recall
Für Regressionsmodelle:
- Mittlere absolute Abweichung (Mean Absolute Error, MAE)
- Mittlere quadratische Abweichung (MQA)
- Mittlere quadratische Gesamtabweichung (Root Mean Squared Error, RMSE)
Weitere Voraussetzungen für die Modellleistungsüberwachung
Sie müssen die folgenden Anforderungen erfüllen, damit Sie ihr Modellleistungssignal konfigurieren:
Sie haben Ausgabedaten für das Produktionsmodell (die Vorhersagen des Modells) mit einer eindeutigen ID für jede Zeile. Wenn Sie Produktionsdaten mit dem Azure Machine Learning-Datensammler sammeln, wird eine
correlation_id
für jede Rückschlussanforderung für Sie bereitgestellt. Mit dem Datensammler haben Sie auch die Möglichkeit, Ihre eigene eindeutige ID aus Ihrer Anwendung zu protokollieren.Hinweis
Für die Leistungsüberwachung des Azure Machine Learning-Modells wird empfohlen, Ihre eindeutige ID in einer eigenen Spalte mithilfe des Azure Machine Learning-Datensammlers zu protokollieren.
Haben Sie Grundwahrheitsdaten (Ist-Werte) mit einer eindeutigen ID für jede Zeile. Die eindeutige ID für eine bestimmte Zeile sollte mit der eindeutigen ID für die Modellausgabe für diese bestimmte Rückschlussanforderung übereinstimmen. Diese eindeutige ID wird verwendet, um Ihr Grundwahrheitsdatenset mit den Modellausgaben zu verbinden.
Ohne Grundwahrheitsdaten können Sie keine Modellleistungsüberwachung durchführen. Da Grundwahrheitsdaten auf Anwendungsebene gefunden werden, liegt es in Ihrer Verantwortung, sie zu sammeln, sobald sie verfügbar wird. Sie sollten auch eine Datenressource in Azure Machine Learning verwalten, die diese Grundwahrheitsdaten enthält.
(Optional) Verfügen Sie über ein vordefiniertes tabellarisches Dataset mit Modellausgaben und Grundwahrheitsdaten, die bereits miteinander verbunden sind.
Überwachen der Modellleistungsanforderungen bei Verwendung des Datensammlers
Wenn Sie den Azure Machine Learning-Datensammler verwenden, um Produktionsrückschlussdaten zu sammeln, ohne Ihre eigene eindeutige ID für jede Zeile als separate Spalte anzugeben, wird eine correlationid
automatisch generiert und im protokollierten JSON-Objekt enthalten. Der Datensammler stapelt jedoch Zeilen, die innerhalb kurzer Zeitintervalle voneinander gesendet werden. Stapelzeilen fallen in dasselbe JSON-Objekt und haben daher dasselbe correlationid
.
Um zwischen den Zeilen im selben JSON-Objekt zu unterscheiden, verwendet Azure Machine Learning-Modellleistungsüberwachung die Indizierung, um die Reihenfolge der Zeilen im JSON-Objekt zu bestimmen. Wenn z. B. drei Zeilen gestapelt werden und Zeile correlationid
test
ist, hat Zeile 1 eine ID von test_0
, Zeile 2 eine ID von test_1
, und Zeile 3 eine ID von test_2
. Stellen Sie sicher, dass Ihr Grundwahrheits-Dataset eindeutige IDs enthält, die mit den gesammelten Ausgabeergebnissen des Produktionsrückschlussmodells übereinstimmen, stellen Sie sicher, dass Sie die einzelnen correlationid
entsprechend indizieren. Wenn Ihr protokolliertes JSON-Objekt nur eine Zeile hat, wäre correlationid
correlationid_0
.
Um diese Indizierung zu vermeiden, empfehlen wir, Ihre eindeutige ID in einer eigenen Spalte im Panda DataFrame zu protokollieren, die Sie mit dem Azure Machine Learning-Datensammler protokollieren. Anschließend geben Sie in Ihrer Modellüberwachungskonfiguration den Namen dieser Spalte an, um Ihre Modellausgabedaten mit Ihren Grundwahrheitsdaten zu verknüpfen. Solange die IDs für jede Zeile in beiden Datasets identisch sind, kann die Überwachung des Azure Machine Learning-Modells eine Modellleistungsüberwachung durchführen.
Beispielworkflow für die Überwachung der Modellleistung
Betrachten Sie diesen Beispielworkflow, um die Konzepte der Modellleistungsüberwachung zu verstehen. Angenommen, Sie stellen ein Modell bereit, um vorherzusagen, ob Kreditkartentransaktionen betrügerisch sind oder nicht, sie können die folgenden Schritte ausführen, um die Leistung des Modells zu überwachen:
- Konfigurieren Sie Ihre Bereitstellung so, dass der Datensammler verwendet wird, um die Produktionsrückschlussdaten (Eingabe- und Ausgabedaten) des Modells zu sammeln. Angenommen, die Ausgabedaten werden in einer Spalte
is_fraud
gespeichert. - Protokollieren Sie für jede Zeile der gesammelten Rückschlussdaten eine eindeutige ID. Die eindeutige ID kann aus Ihrer Anwendung stammen, oder Sie können die einzigartige
correlationid
verwenden, die Azure Machine Learning für jedes protokollierte JSON-Objekt generiert. - Wenn später die Grundwahrheitsdaten (oder tatsächliche)
is_fraud
Daten verfügbar werden, werden sie auch protokolliert und derselben eindeutigen ID zugeordnet, die mit den Ausgaben des Modells protokolliert wurde. - Diese Grundwahrheitsdaten
is_fraud
werden auch gesammelt, verwaltet und in Azure Machine Learning als Datenressource registriert. - Erstellen Sie mithilfe der eindeutigen ID-Spalten ein Modellleistungsüberwachungssignal, das die Produktionsrückschluss- und Grundwahrheitsressourcen des Modells verknüpft.
- Berechnen Sie schließlich die Modellleistungsmetriken.
Nachdem Sie die Voraussetzungen für die Modellleistungsüberwachung erfüllt haben, können Sie die Modellüberwachung mit dem folgenden CLI-Befehl und der YAML-Definition einrichten:
az ml schedule create -f ./model-performance-monitoring.yaml
Der folgende YAML-Code enthält die Definition für die Modellüberwachung mit von Ihnen gesammelten Produktionsrückschlussdaten.
$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
Einrichten der Modellüberwachung durch Bereitstellen Ihrer Produktionsdaten in Azure Machine Learning
Sie können auch die Modellüberwachung für Modelle einrichten, die auf Azure Machine Learning-Batchendpunkten oder außerhalb von Azure Machine Learning bereitgestellt werden. Wenn Sie nicht über eine Bereitstellung, aber über Produktionsdaten verfügen, können Sie die Daten verwenden, um eine kontinuierliche Modellüberwachung durchzuführen. Um diese Modelle zu überwachen, müssen Sie folgende Möglichkeiten haben:
- Sammeln Sie Produktionsinferenzdaten aus Modellen, die in der Produktionsumgebung bereitgestellt werden.
- Registrieren Sie die Produktionsinferenzdaten als Azure Machine Learning-Datenressource, und stellen Sie eine kontinuierliche Aktualisierungen der Daten sicher.
- Stellen Sie eine Datenvorverarbeitungskomponente bereit und registrieren Sie sie als Azure Machine Learning-Komponente.
Sie müssen eine benutzerdefinierte Datenvorverarbeitungskomponente bereitstellen, wenn Ihre Daten nicht mit dem Datensammler gesammelt werden. Ohne diese benutzerdefinierte Datenvorverarbeitungskomponente weiß das Azure Machine Learning-Modellüberwachungssystem nicht, wie Sie Ihre Daten in tabellarischem Format verarbeiten, wobei zeitfensterlich unterstützt wird.
Ihre benutzerdefinierte Vorverarbeitungskomponente muss über diese Eingabe- und Ausgabesignaturen verfügen:
Eingabe/Ausgabe | Signaturname | type | Beschreibung | Beispielswert |
---|---|---|---|---|
input | data_window_start |
Literal, Zeichenfolge | Startzeit des Datenfensters im ISO8601-Format. | 2023-05-01T04:31:57.012Z |
input | data_window_end |
Literal, Zeichenfolge | Endzeit des Datenfensters im ISO8601-Format. | 2023-05-01T04:31:57.012Z |
input | input_data |
uri_folder | Die gesammelten Produktionsinferenzdaten, die als Azure Machine Learning-Datenobjekt registriert werden. | azureml:myproduction_inference_data:1 |
output | preprocessed_data |
mltable | Ein Tabellendataset, das einer Teilmenge des Referenzdatenschemas entspricht. |
Ein Beispiel für eine benutzerdefinierte Datenvorverarbeitungskomponente finden Sie unter custom_preprocessing im GitHub-Repository „azuremml-examples“.
Nachdem Sie die vorherigen Anforderungen erfüllt haben, können Sie die Modellüberwachung mit dem folgenden CLI-Befehl und der YAML-Definition einrichten:
az ml schedule create -f ./model-monitoring-with-collected-data.yaml
Der folgende YAML-Code enthält die Definition für die Modellüberwachung mit von Ihnen gesammelten Produktionsrückschlussdaten.
# 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
Einrichten der Modellüberwachung mit benutzerdefinierten Signalen und Metriken
Mit der Azure Machine Learning-Modellüberwachung können Sie ein benutzerdefiniertes Signal definieren und eine beliebige Metrik Ihrer Wahl zur Überwachung Ihres Modells implementieren. Sie können dieses benutzerdefinierte Signal als Azure Machine Learning-Komponente registrieren. Wenn Ihr Azure Machine Learning-Modellüberwachungsauftrag nach dem angegebenen Zeitplan ausgeführt wird, berechnet er die Metriken, die Sie in Ihrem benutzerdefinierten Signal definiert haben, genau wie für die vordefinierten Signale (Datendrift, Vorhersageabweichung und Datenqualität).
Um ein benutzerdefiniertes Signal für die Modellüberwachung einzurichten, müssen Sie zuerst das benutzerdefinierte Signal definieren und als Azure Machine Learning-Komponente registrieren. Die Azure Machine Learning-Komponente muss über die folgenden Ein- und Ausgabesignaturen verfügen:
Signatur der Komponenteneingabe
Das DataFrame-Element der Komponente sollte die folgenden Elemente enthalten:
- Ein
mltable
mit den verarbeiteten Daten aus der Vorverarbeitungskomponente - Eine beliebige Anzahl von Literalen, die jeweils eine implementierte Metrik als Teil der benutzerdefinierten Signalkomponente darstellen. Wenn Sie beispielsweise die Metrik
std_deviation
implementiert haben, benötigen Sie eine Eingabe fürstd_deviation_threshold
. Im Allgemeinen sollte pro Metrik eine Eingabe mit dem Namen<metric_name>_threshold
vorhanden sein.
Signaturname | type | Beschreibung | Beispielswert |
---|---|---|---|
production_data | MLTable | Ein tabellarisches Dataset, das einer Teilmenge des Referenzdatenschemas entspricht. | |
std_deviation_threshold | Literal, Zeichenfolge | Der jeweilige Schwellenwert für die implementierte Metrik. | 2 |
Signatur der Komponentenausgabe
Der Ausgabeport der Komponente sollte die folgende Signatur aufweisen.
Signaturname | type | Beschreibung |
---|---|---|
signal_metrics | mltable | Die ml-Tabelle, welche die berechneten Metriken enthält. Das Schema wird im nächsten Abschnitt signal_metrics-Schema definiert. |
signal_metrics Schema
Der DataFrame der Komponentenausgabe sollte vier Spalten enthalten – group
, metric_name
, metric_value
und threshold_value
.
Signaturname | type | Beschreibung | Beispielswert |
---|---|---|---|
group | Literal, Zeichenfolge | Die logische Gruppierung auf oberster Ebene, die auf diese benutzerdefinierte Metrik angewendet werden soll. | TRANSACTIONAMOUNT |
metric_name | Literal, Zeichenfolge | Der Name der benutzerdefinierten Metrik. | std_deviation |
metric_value | Numerisch | Der Wert der benutzerdefinierten Metrik. | 44.896,082 |
threshold_value | Numerisch | Der Schwellenwert für die benutzerdefinierte Metrik. | 2 |
Die folgende Tabelle zeigt eine Beispielausgabe aus einer benutzerdefinierten Signalkomponente, welche die std_deviation
-Metrik berechnet:
group | 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 |
Eine Beispieldefinition für eine benutzerdefinierte Signalkomponente und einen metrischen Berechnungscode finden Sie unter custom_signal im Repository „azureml-examples“.
Nachdem Sie die Anforderungen für die Verwendung von benutzerdefinierten Signalen und Metriken erfüllt haben, können Sie die Modellüberwachung mit dem folgenden CLI-Befehl und der YAML-Definition einrichten:
az ml schedule create -f ./custom-monitoring.yaml
Die folgende YAML-Datei enthält die Definition für die Modellüberwachung mit einem benutzerdefinierten Signal. Einige Dinge, die Sie bezüglich des Codes beachten müssen:
- Es wird davon ausgegangen, dass Sie Ihre Komponente bereits mit der benutzerdefinierten Signaldefinition erstellt und bei Azure Machine Learning registriert haben.
- Die
component_id
der registrierte benutzerdefinierte Signalkomponente istazureml:my_custom_signal:1.0.0
. - Wenn Sie Ihre Daten mit dem Datensammler gesammelt haben, können Sie die
pre_processing_component
-Eigenschaft weglassen. Wenn Sie eine Vorverarbeitungskomponente verwenden möchten, um Produktionsdaten vorzuverarbeiten, die nicht vom Datensammler erfasst werden, können Sie sie angeben.
# 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
Interpretieren von Überwachungsergebnissen
Nachdem Sie ihre Modellüberwachung konfiguriert und die erste Ausführung abgeschlossen haben, können Sie zurück zur Registerkarte Überwachung in Azure Machine Learning Studio navigieren, um die Ergebnisse anzuzeigen.
Wählen Sie in der Hauptansicht Überwachung den Namen der Modellüberwachung aus, um die Übersichtsseite „Monitor“ anzuzeigen. Auf dieser Seite werden das entsprechende Modell, der Endpunkt und die Bereitstellung sowie Details zu den von Ihnen konfigurierten Signalen angezeigt. Die nächste Abbildung zeigt ein Überwachungsdashboard, das Datenabweichungs- und Datenqualitätssignale enthält. Je nach den von Ihnen konfigurierten Überwachungssignalen sieht Ihr Dashboard möglicherweise anders aus.
Suchen Sie im Abschnitt Benachrichtigungen des Dashboards nach jedem Signal, das den konfigurierten Schwellenwert für ihre jeweiligen Metriken verletzt hat:
Wählen Sie die data_drift aus, um zur Seite mit den Datenabweichungsdetails zu wechseln. Auf der Detailseite können Sie den Metrikwert der Datenabweichung für jedes numerische und kategorisierte Feature sehen, das Sie in der Überwachungskonfiguration einbezogen haben. Wenn Ihr Monitor mehr als eine Ausführung aufweist, wird für jedes Feature eine Trendlinie angezeigt.
Um ein einzelnes Feature detailliert anzuzeigen, wählen Sie den Namen des Features aus, um die Produktionsverteilung im Vergleich zur Referenzverteilung anzuzeigen. Diese Ansicht ermöglicht es Ihnen auch, die Abweichung im Laufe der Zeit für dieses bestimmte Feature nachzuverfolgen.
Kehren Sie zum Überwachungsdashboard zurück, und wählen Sie data_quality aus, um die Datenqualitätssignalseite anzuzeigen. Auf dieser Seite können Sie die NULL-Werte, nicht gebundenen Raten und Datentypfehlerraten für jedes Feature sehen, das Sie überwachen.
Modellüberwachung ist ein kontinuierlicher Prozess. Mit der Azure Machine Learning-Modellüberwachung können Sie mehrere Überwachungssignale konfigurieren, um einen umfassenden Überblick über die Leistung Ihrer Modelle in der Produktion zu erhalten.
Integrieren der Azure Machine Learning-Modellüberwachung in Azure Event Grid
Sie können Ereignisse verwenden, die von der Azure Machine Learning-Modellüberwachung generiert werden, um ereignisgesteuerte Anwendungen, Prozesse oder CI/CD-Workflows mit Azure Event Grideinzurichten. Sie können Ereignisse über verschiedene Ereignishandler wie Azure Event Hubs, Azure-Funktionen und Logik-Apps nutzen. Basierend auf dem von Ihren Monitoren erkannten Drift können Sie programmgesteuert Maßnahmen ergreifen, z. B. indem Sie eine Machine Learning-Pipeline einrichten, um ein Modell neu zu trainieren und erneut bereitzustellen.
So beginnen Sie mit der Integration der Azure Machine Learning-Modellüberwachung in das Event Grid:
Führen Sie die Schritte unter „Einrichten“ im Azure-Portal aus. Geben Sie Ihrem Ereignisabonnement einen Namen, z. B. MonitoringEvent, und wählen Sie unter Ereignistypen nur das Feld Ausführungsstatus geändert aus.
Warnung
Achten Sie darauf, Ausführungsstatus geändert für den Ereignistyp auszuwählen. Wählen Sie nicht Datendrift erkannt aus, da sie für Datenabweichung v1 gilt, anstatt für die Azure Machine Learning-Modellüberwachung.
Führen Sie die Schritte in Filtern und Abonnieren von Ereignissen aus, um die Ereignisfilterung für Ihr Szenario einzurichten. Navigieren Sie zur Registerkarte Filter, und fügen Sie die folgenden Key, Operator und Wert unter Erweiterte Filter hinzu:
- Schlüssel:
data.RunTags.azureml_modelmonitor_threshold_breached
- Wert: Fehler aufgrund eines oder mehrerer Features, die metrische Schwellenwerte verletzen
- Operator: Zeichenfolge enthält
Mit diesem Filter werden Ereignisse generiert, wenn sich der Ausführungsstatus (von „Abgeschlossen“ in „Fehlgeschlagen“ oder von „Fehlgeschlagen“ in „Abgeschlossen“) für einen beliebigen Monitor in Ihrem Azure Machine Learning-Arbeitsbereich ändert.
- Schlüssel:
Verwenden Sie zum Filtern auf Überwachungsebene den folgenden Key, Operator und Wert unter Erweiterte Filter:
- Schlüssel:
data.RunTags.azureml_modelmonitor_threshold_breached
- Wert:
your_monitor_name_signal_name
- Operator: Zeichenfolge enthält
Stellen Sie sicher, dass
your_monitor_name_signal_name
der Name eines Signals im spezifischen Monitor ist, nach dem Sie Ereignisse filtern möchten. Beispielsweisecredit_card_fraud_monitor_data_drift
. Damit dieser Filter funktioniert, muss diese Zeichenfolge mit dem Namen des Überwachungssignals übereinstimmen. Sie sollten Ihr Signal sowohl mit dem Monitornamen als auch mit dem Signalnamen für diesen Fall benennen.- Schlüssel:
Wenn Sie Ihre Ereignisabonnementkonfiguration abgeschlossen haben, wählen Sie den gewünschten Endpunkt aus, der als Ereignishandler wie Azure Event Hubs dienen soll.
Nachdem Ereignisse erfasst wurden, können Sie sie auf der Endpunktseite anzeigen:
Sie können Ereignisse auch auf der Registerkarte Metriken von Azure Monitor anzeigen: