Freigeben über

Modellüberwachung mit Azure Machine Learning

  • Artikel

In diesem Artikel erfahren Sie mehr über das Überwachen von Modellen in Azure Machine Learning, die Signale und Metriken, die Sie überwachen können, und die empfohlenen Methoden für die Verwendung der Modellüberwachung.

Anwendungsfall für die Modellüberwachung

Das Überwachen von Modellen ist der letzte Schritt im End-to-End-Lebenszyklus des maschinellen Lernens. Dieser Schritt verfolgt die Modellleistung in der Produktion und hat zum Ziel, sie sowohl aus Data-Science- als auch aus operativer Sicht zu verstehen.

Im Gegensatz zu herkömmlichen Softwaresystemen wird das Verhalten von Systemen für das maschinelle Lernen nicht nur durch im Code angegebene Regeln gesteuert, sondern auch durch modellbasiertes Verhalten, das aus Daten gelernt wird. Aus diesem Grund können Datenverteilungsänderungen, Trainingsfeatures, Probleme mit der Datenqualität und Änderungen an Umgebungen oder Behavior Changes bei Benutzer*innen dazu führen, dass ein Modell veraltet. Wenn ein Modell veraltet, kann die Leistung zu dem Zeitpunkt, hat es möglicherweise keinen geschäftlichen Nutzen mehr oder verursacht schwerwiegende Complianceprobleme in stark regulierten Umgebungen.

Einschränkungen bei der Modellüberwachung in Azure Machine Learning

Die Azure Machine Learning-Modellüberwachung unterstützt nur die Verwendung der auf Anmeldeinformationen basierenden Authentifizierung(z. B. SAS-Token) für den Zugriff auf in Datenspeichern enthaltene Daten. Weitere Informationen zu Datenspeichern und Authentifizierungsmodi finden Sie unter Datenverwaltung.

Funktionsweise der Modellüberwachung in Azure Machine Learning

Azure Machine Learning erfasst Überwachungssignale, indem statistische Berechnungen für gestreamte Produktionsrückschlussdaten und Referenzdaten durchgeführt werden. Die Referenzdaten können verlaufsbezogene Trainingsdaten, Validierungsdaten oder Ground-Truth-Daten sein. Andererseits beziehen sich die Produktionsreferenzdaten auf die in der Produktion gesammelten Eingabe- und Ausgabedaten des Modells.

Jedes Überwachungssignal verfügt über eine oder mehrere Metriken. Benutzer*innen können Schwellenwerte für diese Metriken festlegen, um über Azure Machine Learning oder Azure Event Grid Warnungen zu Modell- oder Datenanomalien zu erhalten. Diese Warnungen können Benutzende zur Analyse oder Problembehandlung von Überwachungssignalen in Azure Machine Learning Studio auffordern, um die Modellqualität kontinuierlich zu verbessern.

Die folgenden Schritte beschreiben ein Beispiel für die statistische Berechnung, die verwendet wird, um ein integriertes Überwachungssignal für ein Produktionsmodell abzurufen, zum Beispiel zum Datendrift.

  • Berechnen Sie bei einem Feature in den Trainingsdaten die statistische Verteilung seiner Werte. Diese Verteilung ist die Baselineverteilung für das Feature.
  • Berechnen Sie die statistische Verteilung der neuesten Werte des Features, die in der Produktion angezeigt werden.
  • Vergleichen Sie die Verteilung der neuesten Werte des Features in der Produktion mit der Baselineverteilung, indem Sie einen statistischen Test durchführen oder die Divergenz berechnen.
  • Wenn die Teststatistik oder der Divergenz-Score zwischen den beiden Verteilungen einen vom Benutzenden angegebenen Schwellenwert überschreitet, identifiziert Azure Machine Learning die Anomalie und benachrichtigt den Benutzenden.

Einrichten der Modellüberwachung

So aktivieren und verwenden Sie die Modellüberwachung in Azure Machine Learning:

  1. Aktivieren sie die Sammlung von Produktionsrückschlussdaten. Wenn Sie ein Modell an einem Azure Machine Learning-Onlineendpunkt bereitstellen, können Sie die Sammlung von Produktionsrückschlussdaten mithilfe der Azure Machine Learning-Modelldatensammlung aktivieren. Wenn Sie jedoch ein Modell außerhalb von Azure Machine Learning oder auf einem Azure Machine Learning-Batch-Endpunkt bereitstellen, sind Sie für das Sammeln von Produktionsrückschlussdaten verantwortlich. Sie können diese Daten dann für die Azure Machine Learning-Modellüberwachung verwenden.
  2. Richten Sie die Modellüberwachung ein. Sie können das Azure Machine Learning SDK, die CLI 2.0 oder die Studio-Benutzeroberfläche verwenden, um die Modellüberwachung unkompliziert einzurichten. Während des Setups können Sie Ihre bevorzugten Überwachungssignale angeben und Metriken und Schwellenwerte für jedes Signal anpassen.
  3. Zeigen Sie die Ergebnisse der Modellüberwachung an und analysieren Sie sie. Nachdem die Modellüberwachung eingerichtet wurde, plant Azure Machine Learning einen Überwachungsauftrag, der mit der von Ihnen angegebenen Häufigkeit ausgeführt wird. Jede Ausführung berechnet und wertet Metriken für alle ausgewählten Überwachungssignale aus und löst Warnungsbenachrichtigungen aus, wenn ein festgelegter Schwellenwert überschritten wird. Sie können dem Link in der Warnungsbenachrichtigung folgen, um Überwachungsergebnisse in Ihrem Azure Machine Learning-Arbeitsbereich anzuzeigen und zu analysieren.

Funktionen der Modellüberwachung

Azure Machine Learning bietet die folgenden Funktionen für die kontinuierliche Modellüberwachung:

  • Integrierte Überwachungssignale Die Modellüberwachung bietet integrierte Überwachungssignale für tabellarische Daten. Diese Überwachungssignale umfassen Datendrift, Vorhersagedrift, Datenqualität, Featurezuordnungsdrift und Modellleistung.
  • Setup der vorkonfigurierten Modellüberwachung mit dem Azure Machine Learning-Onlineendpunkt. Wenn Sie Ihr Modell in der Produktion in einem Azure Machine Learning-Onlineendpunkt bereitstellen, erfasst Azure Machine Learning automatisch Produktionsrückschlussdaten und verwendet sie für die kontinuierliche Überwachung.
  • Verwendung mehrerer Überwachungssignale für eine umfassende Ansicht Ein Überwachungssetup kann problemlos mehrere Überwachungssignale enthalten. Für jedes Überwachungssignal können Sie Ihre bevorzugte(n) Metrik(en) auswählen und eine Feineinstellung des Warnungsschwellenwerts vornehmen.
  • Verwendung von Trainingsdaten oder Produktionsdaten der jüngsten Vergangenheit als Referenzdaten für den Vergleich: Für die Überwachung von Signalen können Sie mit Azure Machine Learning Referenzdaten aus Trainingsdaten oder Produktionsdaten der jüngsten Vergangenheit festlegen.
  • Überwachung von Datendrift oder Datenqualität für die Top-N-Features. Wenn Sie Trainingsdaten als Referenzdaten verwenden, können Sie Datendrift- oder Datenqualitätssignale definieren, die die Featurerelevanz überlagern.
  • Flexibilität beim Definieren Ihres Überwachungssignals Wenn die integrierten Überwachungssignale nicht für Ihr Geschäftsszenario geeignet sind, können Sie Ihr eigenes Überwachungssignal mit einer benutzerdefinierten Überwachungssignalkomponente definieren.
  • Flexibilität bei der Verwendung von Produktionsrückschlussdaten aus einer beliebigen Quelle. Wenn Sie Modelle außerhalb von Azure Machine Learning bereitstellen oder Modelle für Azure Machine Learning-Batchendpunkte bereitstellen, können Sie Produktionsrückschlussdaten sammeln und diese in Azure Machine Learning für die Modellüberwachung verwenden.

Größe und Offset des Lookbackfensters

Die Größe des Lookbackfensters ist die Zeitdauer (im ISO 8601-Format) für das Produktions- oder Referenzdatenfenster, ausgehend vom Datum der Überwachungsausführung.

Der Lookbackfensteroffset ist die Offsetdauer (im ISO 8601-Format) für das Ende Ihres Datenfensters, ausgehend vom Datum der Überwachungsausführung.

Beispiel: Ihr Modell befindet sich in der Produktion und Sie haben einen Monitor eingerichtet, der am 31. Januar um 15:15 Uhr UTC ausgeführt werden soll. Wenn Sie für die Produktion eine Lookbackfenstergröße von P7D (sieben Tage) für den Monitor und einen Lookbackfensteroffset von P0D (null Tage) festlegen, verwendet der Monitor Daten vom 24. Januar um 15:15 Uhr UTC bis zum 31. Januar um 15:15 Uhr UTC (die Zeit, zu der Ihre Überwachung ausgeführt wird) im Datenfenster.

Wenn Sie für die Referenzdaten den Lookbackfensteroffset auf P7D (sieben Tage) festlegen, endet das Referenzdatenfenster direkt vor dem Start des Produktionsdatenfensters, sodass keine Überlappung vorhanden ist. Anschließend können Sie die Lookbackfenstergröße für Referenzdaten so groß wie möglich festlegen. Wenn Sie beispielsweise die Größe des Lookbackfensters für Referenzdaten auf P24D (24 Tage) festlegen, enthält das Referenzdatenfenster Daten vom 1. Januar um 15:15 Uhr UTC bis zum 24. Januar um 15:15 Uhr UTC. Die folgende Abbildung veranschaulicht dieses Beispiel.

Ein Diagramm, das die Größe des Lookbackfensters und den Offset für Referenz- und Produktionsdaten zeigt.

In einigen Fällen kann es hilfreich sein, den Lookbackfensteroffset für die Produktionsdaten auf eine Zahl festzulegen, die größer als null Tage ist. Wenn Ihr Monitor beispielsweise für die wöchentliche Ausführung immer montags um 15:15 Uhr UTC geplant ist, Sie aber keine Daten vom Wochenende in Ihrer Überwachungsausführung verwenden möchten, können Sie eine Lookbackfenstergröße von P5D (fünf Tage) und einen Lookbackfensteroffset von P2D (zwei Tage) verwenden. Dann beginnt Ihr Datenfenster am letzten Montag um 15:15 Uhr UTC und endet am Freitag um 15:15 Uhr UTC.

In der Praxis sollten Sie sicherstellen, dass sich das Referenzdatenfenster und das Produktionsdatenfenster nicht überlappen. Wie in der folgenden Abbildung dargestellt, können Sie vermeiden, dass sich Fenster überlappen, indem Sie sicherstellen, dass der Offset des Lookbackfensters für Referenzdaten (P10D oder 10 Tage in diesem Beispiel) größer oder gleich der Summe der Lookbackfenstergröße der Produktionsdaten und des Offsets des Lookbackfensters (insgesamt sieben Tage) ist.

Ein Diagramm mit nicht überlappenden Fenstern für Referenzdaten und Produktionsdaten.

Mit der Azure Machine Learning-Modellüberwachung können Sie intelligente Standardwerte für die Größe und den Offset des Lookbackfensters verwenden oder diese an Ihre Anforderungen anpassen. Außerdem werden sowohl rollierende Fenster als auch feste Fenster unterstützt.

Anpassen der Größe des Lookbackfensters

Sie können die Lookbackfenstergröße sowohl für die Produktionsdaten als auch für die Referenzdaten flexibel auswählen.

  • Standardmäßig ist die Lookbackfenstergröße für Produktionsdaten Ihre Überwachungsfrequenz. Das heißt, dass alle Daten analysiert werden, die im Überwachungszeitraum vor der Ausführung des Überwachungsauftrags gesammelt wurden. Sie können die production_data.data_window.lookback_window_size-Eigenschaft verwenden, um das rollierende Datenfenster für die Produktionsdaten anzupassen.

  • Standardmäßig ist das Lookbackfenster für die Referenzdaten das vollständige Dataset. Mit der reference_data.data_window.lookback_window_size-Eigenschaft können Sie die Größe des Referenzlookbackfensters anpassen.

  • Um ein festes Datenfenster für die Referenzdaten anzugeben, können Sie die Eigenschaften reference_data.data_window.window_start_date und reference_data.data_window.window_end_date verwenden.

Anpassen des Offsets des Lookbackfensters

Sie können den Lookbackfensteroffset für Ihr Datenfenster sowohl für die Produktionsdaten als auch für die Referenzdaten flexibel auswählen. Sie können den Offset für die präzise Kontrolle über die von Ihrem Monitor verwendeten Daten verwenden. Der Offset gilt nur für rollierende Datenfenster.

  • Standardmäßig ist der Offset für Produktionsdaten P0D (null Tage). Sie können diesen Offset mit der Eigenschaft production_data.data_window.lookback_window_offset ändern.

  • Der Offset für Referenzdaten ist standardmäßig doppelt so viel wie production_data.data_window.lookback_window_size. Diese Einstellung stellt sicher, dass genügend Referenzdaten für statistisch aussagekräftige Überwachungsergebnisse vorhanden sind. Sie können diesen Offset mit der Eigenschaft reference_data.data_window.lookback_window_offset ändern.

Überwachen von Signalen und Metriken

Die Azure Machine Learning-Modellüberwachung unterstützt die folgenden Überwachungssignale und -metriken:

Wichtig

Die in diesem Artikel markierten Elemente (Vorschau) sind aktuell als öffentliche Vorschau verfügbar. Die Vorschauversion wird ohne Vereinbarung zum Servicelevel bereitgestellt und ist nicht für Produktionsworkloads vorgesehen. Manche Features werden möglicherweise nicht unterstützt oder sind nur eingeschränkt verwendbar. Weitere Informationen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.

Überwachungssignal BESCHREIBUNG Metriken Modellaufgaben (unterstütztes Datenformat) Produktionsdaten Referenzdaten
Datendrift Datendrift verfolgt Änderungen in der Verteilung der Eingabedaten eines Modells, indem sie mit der Verteilung der Trainingsdaten des Modells oder den Produktionsdaten der jüngsten Vergangenheit verglichen werden. Jensen-Shannon-Divergenz, Populationsstabilitätsindex, normalisierte Wasserstein-Divergenz, Kolmogorow-Smirnow-Test mit zwei Stichproben, Chi-Quadrat-Test nach Pearson Klassifizierung (tabellarische Daten), Regression (tabellarische Daten) Produktionsdaten – Modelleingaben Produktionsdaten der letzten Vergangenheit oder Trainingsdaten
Vorhersagedrift Die Vorhersagedrift verfolgt Veränderungen in der Verteilung der vorhergesagten Ausgaben eines Modells, indem sie mit der Verteilung von Validierungsdaten, gekennzeichneten Testdaten oder Produktionsdaten der jüngsten Vergangenheit verglichen werden. Jensen-Shannon-Divergenz, Populationsstabilitätsindex, normalisierte Wasserstein-Divergenz, Tschebyschew-Norm. Kolmogorow-Smirnow-Test mit zwei Stichproben, Chi-Quadrat-Test nach Pearson Klassifizierung (tabellarische Daten), Regression (tabellarische Daten) Produktionsdaten – Modellausgaben Produktionsdaten der letzten Vergangenheit oder Validierungsdaten
Datenqualität Die Datenqualität verfolgt die Datenintegrität der Modelleingaben, indem sie mit den Trainingsdaten des Modells oder den Produktionsdaten der jüngsten Vergangenheit verglichen wird. Die Datenqualitätsprüfungen umfassen die Überprüfung auf NULL-Werte, Typkonflikte oder Werte außerhalb der Grenzen. NULL-Wert-Rate, Datentypfehlerrate, Rate von Werten außerhalb der Grenzen Klassifizierung (tabellarische Daten), Regression (tabellarische Daten) Produktionsdaten – Modelleingaben Produktionsdaten der letzten Vergangenheit oder Trainingsdaten
Featurezuordnungsdrift (Vorschau) Der Featurezuordnungsdrift basiert auf dem Beitrag von Features zu Vorhersagen (auch bekannt als Featurerelevanz). Der Featureabweichungsdrift verfolgt die Featurerelevanz während der Produktion durch Vergleich mit der Featurerelevanz während des Trainings. Normalisierter diskontierter kumulativer Gewinn Klassifizierung (tabellarische Daten), Regression (tabellarische Daten) Produktionsdaten: Modelleingaben und -ausgaben Trainingsdaten (erforderlich)
Modellleistung – Klassifizierung (Vorschau) Die Modellleistung verfolgt die objektive Leistung der Ausgabe eines Modells in der Produktion, indem sie mit gesammelten Ground-Truth-Daten verglichen wird. Genauigkeit, Präzision und Abruf Klassifizierung (Tabellendaten) Produktionsdaten – Modellausgaben Ground-Truth-Daten (erforderlich)
Modellleistung – Regression (Vorschau) Die Modellleistung verfolgt die objektive Leistung der Ausgabe eines Modells in der Produktion, indem sie mit gesammelten Ground-Truth-Daten verglichen wird. Mittlere absolute Abweichung (MAE), mittlere quadratische Abweichung (MQA) und mittlere quadratische Gesamtabweichung (RMSE) Regression (Tabellendaten) Produktionsdaten – Modellausgaben Ground-Truth-Daten (erforderlich)
Generative KI: Sicherheit und Qualität der generierten Inhalte (Vorschau) Bewertet generative KI-Anwendungen auf Sicherheit und Qualität mittels GPT-gestützter Metriken Fundiertheit, Relevanz, Geläufigkeit, Ähnlichkeit, Kohärenz Fragen und Antworten Vorlagen für Eingabeaufforderung, Abschluss, Kontext und Anmerkung N/V

Metriken für das Datenqualitätsüberwachungssignal

Das Datenqualitätsüberwachungssignal verfolgt die Integrität der Eingabedaten eines Modells, indem diese drei Metriken berechnet werden:

  • NULL-Wert-Rate
  • Datentypfehlerrate
  • Out-of-Bounds-Rate

NULL-Wert-Rate

Die NULL-Wert-Rate ist die Rate der NULL-Werte in der Eingabe des Modells für jedes Feature. Wenn das Überwachungsfenster für Produktionsdaten beispielsweise 100 Zeilen enthält und der Wert für ein bestimmtes Feature, z. B. temperature, null für zehn dieser Zeilen ist, beträgt die NULL-Wert-Rate für temperature 10 %.

  • Azure Machine Learning unterstützt die Berechnung der NULL-Wert-Rate für alle Featuredatentypen.

Datentypfehlerrate

Die Datentypfehlerrate ist die Rate der Datentypunterschiede zwischen dem aktuellen Produktionsdatenfenster und den Referenzdaten. Während jeder Überwachungsausführung leitet die Azure Machine Learning-Modellüberwachung den Datentyp für jedes Feature aus den Referenzdaten ab. Wenn beispielsweise der Datentyp für ein Feature wie temperature aus den Referenzdaten als IntegerType abgeleitet wird, aber im Produktionsdatenfenster 10 von 100 Werten für temperature keine Integerwerte sind (sondern möglicherweise Zeichenfolgen), dann beträgt die Fehlerrate des Datentyps für temperature 10 %.

  • Azure Machine Learning unterstützt die Berechnung der Datentypfehlerrate für die folgenden Datentypen, die in PySpark verfügbar sind: ShortType, BooleanType, BinaryType, DoubleType, TimestampType, StringType, IntegerType, FloatType, ByteType, LongType und DateType.
  • Wenn der Datentyp für ein Feature nicht in dieser Liste enthalten ist, wird die Überwachung des Azure Machine Learning-Modells trotzdem ausgeführt, die Datentypfehlerrate für dieses bestimmte Feature wird jedoch nicht berechnet.

Out-of-Bounds-Rate

Die Out-of-Bounds-Rate ist die Rate der Werte für jedes Feature, die außerhalb des zulässigen Bereichs oder der zulässigen Menge liegen, der bzw. die durch die Referenzdaten bestimmt wird. Während jeder Überwachungsausführung bestimmt die Azure Machine Learning-Modellüberwachung den zulässigen Bereich oder die zulässige Menge für jedes Feature aus den Referenzdaten.

  • Bei einem numerischen Feature ist der entsprechende Bereich ein numerisches Intervall vom Minimalwert im Referenzdatensatz bis zum Maximalwert, z. B. [0, 100].
  • Bei einem kategorisierten Feature, z. B. color, ist der zulässige Bereich eine Menge aller Werte, die im Referenzdatensatz enthalten sind, z. B. [red, yellow, green].

Wenn beispielsweise das numerisches Feature temperature vorhanden ist, in dem alle Werte im Referenzdataset [37, 77] liegen, aber im Produktionsdatenfenster 10 von 100 Werten für temperature außerhalb des Bereichs liegen [37, 77], dann beträgt die Out-of-Bounds-Rate für temperature 10 %.

  • Azure Machine Learning unterstützt die Berechnung der Out-of-Bounds-Rate für diese Datentypen, die in PySpark verfügbar sind: StringType, IntegerType, DoubleType, ByteType, LongType und FloatType.
  • Wenn der Datentyp für ein Feature nicht in dieser Liste enthalten ist, wird die Überwachung des Azure Machine Learning-Modells trotzdem ausgeführt, die Out-of-Bounds-Rate für dieses bestimmte Feature wird jedoch nicht berechnet.

Die Azure Machine Learning-Modellüberwachung unterstützt eine Genauigkeit von bis zu 0,00001 für Berechnungen der NULL-Wert-Rate, der Datentypfehlerrate und der Out-of-Bounds-Rate.

Jedes Machine Learning-Modell und seine Anwendungsfälle sind einzigartig. Daher ist auch die Modellüberwachung für jede Situation einzigartig. Im Folgenden ist eine Liste der empfohlenen bewährten Methoden für die Modellüberwachung aufgeführt:

  • Beginnen Sie mit der Modellüberwachung unmittelbar nach der Bereitstellung eines Modells in der Produktion.
  • Arbeiten Sie mit Data Scientists zusammen, die mit dem Modell vertraut sind, um die Modellüberwachung einzurichten. Wissenschaftliche Fachkräfte für Daten, die Erkenntnisse über das Modell und seine Anwendungsfälle haben, sind am besten positioniert, um Überwachungssignale und Metriken zu empfehlen und auch die richtigen Warnschwellenwerte für jede Metrik festzulegen (um überzählige Warnungen zu verhindern).
  • Nehmen Sie mehrere Überwachungssignale in Ihre Überwachungseinrichtung auf. Mit mehreren Überwachungssignalen erhalten Sie sowohl eine sowohl umfassende als auch präzise Ansicht der Überwachung. Beispielsweise können Sie die Signale für Datendrift und Featurezuordnungsdrift kombinieren, um eine frühzeitige Warnung zu Leistungsproblemen Ihres Modells zu erhalten.
  • Verwenden Sie Modelltrainingsdaten als Referenzdaten. Für Verweisdaten, die als Vergleichsbaseline verwendet werden, ermöglicht Azure Machine Learning die Verwendung der Produktionsdaten der letzten Vergangenheit oder historischer Daten (z. B. Trainingsdaten oder Validierungsdaten). Für einen aussagekräftigen Vergleich empfiehlt es sich, die Trainingsdaten als Vergleichsbaseline für Datendrift und Datenqualität zu verwenden. Verwenden Sie für die Vorhersagedrift die Validierungsdaten als Vergleichsbaseline.
  • Geben Sie die Überwachungshäufigkeit basierend darauf an, wie Ihre Produktionsdaten über die Zeit zunehmen werden: Wenn Ihr Produktionsmodell beispielsweise täglich viel Datenverkehr aufweist und die tägliche Datenakkumulation ausreichend groß ist, um sie zu überwachen, können Sie die Überwachungshäufigkeit auf täglich festlegen. Andernfalls können Sie eine wöchentliche oder monatliche Überwachungshäufigkeit basierend auf dem Wachstum Ihrer Produktionsdaten über die Zeit in Betracht ziehen.
  • Überwachen Sie die wichtigsten n Features oder eine Teilmenge der Features. Wenn Sie Trainingsdaten als die Vergleichsbaseline verwenden, können Sie die Datendrift- oder die Datenqualitätsüberwachung ganz einfach für die Top-N-Features konfigurieren. Bei Modellen mit einer großen Anzahl von Features sollten Sie eine Teilmenge dieser Features überwachen, um die Berechnungskosten und das Überwachungsrauschen zu reduzieren.
  • Verwenden Sie das Modellleistungssignal, wenn Sie Zugriff auf Ground-Truth-Daten haben. Wenn Sie Zugriff auf Ground-Truth-Daten (auch als tatsächliche Daten bezeichnet) haben, die auf den Besonderheiten Ihrer Machine Learning-Anwendung basieren, wird empfohlen, das Modellleistungssignal zu verwenden, um die Ground-Truth-Daten mit der Ausgabe Ihres Modells zu vergleichen. Dieser Vergleich bietet einen objektiven Einblick in die Leistung Ihres Modells in der Produktion.

Integration der Modellüberwachung mit Azure Event Grid

Sie können Ereignisse verwenden, die von Azure Machine Learning-Modellüberwachungsausführungen generiert werden, um ereignisgesteuerte Anwendungen, Prozesse oder CI/CD-Workflows mit Azure Event Grid einzurichten.

Wenn Ihr Modellmonitor Abweichungs-, Datenqualitäts- oder Modellleistungsbeeinträchtigungen erkennt, können Sie diese Ereignisse mit Event Grid nachverfolgen und programmgesteuert Maßnahmen ergreifen. Wenn beispielsweise die Genauigkeit Ihres Klassifizierungsmodells in der Produktion unter einen bestimmten Schwellenwert sinkt, können Sie mit Event Grid einen erneuten Trainingsauftrag starten, der gesammelte Ground-Truth-Daten verwendet. Weitere Informationen zum Integrieren von Azure Machine Learning mit Event Grid finden Sie unter Durchführen einer kontinuierlichen Modellüberwachung in Azure Machine Learning.

Zugehöriger Inhalt