6. Kontinuierliche Überwachung - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

6. Kontinuierliche Überwachung

Bei der kontinuierlichen Überwachung beobachten und erkennen automatisierte Prozesse Leistungsprobleme und modellieren Probleme. Eigentümer können dann potenzielle Probleme und Bedrohungen in Echtzeit identifizieren, um sie schnell zu beheben.

Durch die kontinuierliche Überwachung werden mögliche Modellprobleme wie Datenqualität, Verlagerung, Änderung des Modellkonzepts und Verschlechterung der Modellqualität aufgedeckt. Die kontinuierliche Überwachung umfasst auch eine umfassende Protokollierung herkömmlicher Systemkennzahlen wie Sättigung, Latenz, Verkehr und Fehler. Es wurde eine praktische Benachrichtigungs- und Warnstrategie eingerichtet, um die Eigentümer zu benachrichtigen, wenn Probleme auftreten.

6.1 Modellüberwachung: Erkennung der Datenqualität

Mithilfe einer regelbasierten Überwachung kann festgestellt werden, wann eingehende Daten von den Trainingsdaten des Modells abweichen. Diese Art der Überwachung erstellt ein Schema aus den Trainingsdaten, legt Einschränkungen auf der Grundlage dieses Schemas fest und führt dann Ausnahmen aus, wenn ein Verstoß auftritt.

6.2 Modellüberwachung: Verlagerung der Verteilung

Bei der Überwachung wird die Verteilung der eingehenden Daten untersucht und überprüft, ob sie nicht von der Verteilung der Modelltrainingsdaten abgewichen ist. Beispielsweise werden die eingehenden Daten als bewegliches Fenster über Inferenzdaten abgetastet. Anschließend wird ein Job ausgeführt, um die Stichprobenverteilung und die Trainingsverteilung zu testen, um festzustellen, ob sie identisch sind.

6.3 Modellüberwachung: Änderung des Modellkonzepts

Bei einer Konzeptdriftprüfung wird darauf geachtet, dass die Beziehung zwischen den Eingaben eines Modells und der Zielvariablen gegenüber den Trainingsdaten unverändert bleibt. Eine zusätzliche Überprüfung besteht darin, sicherzustellen, dass sich die relativen Merkmale und ihre Bedeutung nicht ändern.

6.4 Modellüberwachung: Überprüfung der Modellbewertung

Dabei handelt es sich um eine Überwachungsprüfung, bei der bewertet wird, ob sich die Qualität des Modells verschlechtert hat. Bei der Überprüfung der Modellbewertung werden die Bewertungskennzahlen aus der Trainingszeit mit den eingehenden Ergebnissen verglichen, um zu beurteilen, ob die Genauigkeit des Modells aufgrund neuer Daten gesunken ist. Da es Genauigkeitsmetriken berechnet, setzt diese Prüfung voraus, dass neue Daten erst nach der Inferenz zur Verfügung stehen.

6.5 Systemerfassungen: Eingabeschemas

Das ML-System erfasst das Schema der Trainings-, Test- und Validierungsdaten. Schemas liefern nicht nur Informationen über Eingaben, sondern liefern auch Statistiken zu deren Verzerrung und Vollständigkeit.  Schemas werden für sofortige Tests und zur Überwachung der Datenqualität in der Produktion verwendet.

6.6 Systemerfassungen: Bewertungsergebnisse und Statistiken

Das ML-System gibt Genauigkeitsinformationen zu Validierungs- und Trainingsdaten aus. Es kann die Vorhersagen und wahren Bezeichnungen von Validierungs- und Trainingsläufen ausgeben. Diese werden als Überwachungsbeschränkungen für das Live-Produktionsmodell verwendet.

6.7 Das System erfasst: Anomalien

Es gibt einen Tracking-Mechanismus, um Anomalien in eingehenden Datenströmen zu kennzeichnen. Wenn bei eingehenden Daten Ausreißer auftreten oder wenn sich die Verteilung der wichtigsten Merkmale während eines bestimmten Zeitraums ändert, erkennt das System dies als Anomalie und kennzeichnet sie.

6.8 Protokollierung: Sättigung und Ressourcen

Es wird protokolliert, wie voll das System ist. Die Messwerte für Ressourcen und Sättigung sollten sich auf die CPU-Auslastung, die Auslastung der Grafikprozessoren (GPU), die Speicherauslastung und die Festplattenauslastung konzentrieren. Diese Messwerte sollten im Zeitreihenformat mit der Möglichkeit zur Messung in Perzentilen verfügbar sein. Bei Batch-Aufträgen liefert dies Informationen über den Durchsatz, der angibt, wie viele Informationseinheiten das System in jedem Zeitraum verarbeiten kann.

6.9 Protokollierung: Latenz

Eine Protokollierung sollte vorhanden sein, um die Verzögerung der Netzwerkkommunikation oder die Zeit zu messen, die für die Bearbeitung einer Anfrage benötigt wird. Ein Techniker sollte in der Lage sein zu beurteilen, wie lange es dauert, bis die Inferenzmodelle Prognosen liefern, und wie lange es dauert, bis das Modell geladen ist.

6.10 Protokollierung: Verkehr

Das Logging-Setup für den Datenverkehr misst das Verkehrsvolumen auf jeder Instanz. Der Verkehr wird anhand der Anzahl von HTTP-Anfragen und Bytes oder Paketen gemessen, die während eines bestimmten Zeitraums gesendet oder empfangen wurden. Die Protokollierung des Datenverkehrs bietet Einblicke in die Gesamtauslastung eines Systems.

6.11 Protokollierung: Fehler

Die Einrichtung der Fehlerprotokollierung erfasst die Anzahl der fehlgeschlagenen Anfragen. Es gibt folgende Arten von Fehlern:

  • Explizit (z. B. HTTP 500-Fehler)

  • Implizit (z. B. eine HTTP 200-Erfolgsantwort, die mit dem falschen Inhalt verknüpft ist)

  • Richtlinie (wenn Sie sich beispielsweise zu Antwortzeiten von einer Sekunde verpflichten, ist jede Anfrage, die länger als eine Sekunde dauert, ein Fehler)

Wenn die Protokollantwortcodes nicht ausreichen, um alle Fehlerbedingungen auszudrücken, sind möglicherweise sekundäre (interne) Protokolle erforderlich, um die Ursachen teilweiser Fehler nachzuverfolgen.

6.12 Benachrichtigungen und Warnmeldungen

Benachrichtigungen und Warnmeldungen werden über die Überwachung eingerichtet. Zu den Benachrichtigungen gehören die Möglichkeit, Slack, E-Mail-Benachrichtigungen, Seiten und SMS-Nachrichten (Short Message Service) abzurufen. Warnmeldungen bedeuten nicht, dass Benachrichtigungen für alle möglichen Verstöße gesendet werden. Stattdessen bedeutet es, Warnmeldungen für bestimmte Ausnahmen festzulegen, die für das Entwicklungsteam aussagekräftig und wichtig sind. Auf diese Weise wird Alarmermüdung vermieden.