ML-Produktionssysteme: Monitoring-Pipelines

Glückwunsch! Sie haben das Einhornmodell bereitgestellt. Ihr Modell sollte rund um die Uhr ohne Probleme ausgeführt werden können. Damit das der Fall ist, müssen Sie Ihre ML-Pipeline (Machine Learning) überwachen.

Datenschema zum Validieren von Rohdaten erstellen

Um Ihre Daten zu überwachen, sollten Sie sie kontinuierlich mit erwarteten statistischen Werten vergleichen. Dazu müssen Sie Regeln erstellen, die die Daten erfüllen müssen. Diese Sammlung von Regeln wird als Datenschema bezeichnet. So definieren Sie ein Datenschema:

  1. Reichweite und Verteilung Ihrer Funktionen nachvollziehen Bei kategorialen Features müssen Sie die Menge der möglichen Werte kennen.

  2. Codieren Sie Ihr Wissen im Datenschema. Hier einige Beispiele für Regeln:

    • Von Nutzern eingereichte Bewertungen müssen immer im Bereich von 1 bis 5 liegen.
    • Prüfen Sie, ob das Wort the am häufigsten vorkommt (für eine englische Textfunktion).
    • Prüfen Sie, ob für jedes kategoriale Feature ein Wert aus einem festen Satz möglicher Werte festgelegt ist.

  3. Daten anhand des Datenschemas testen Ihr Schema sollte Datenfehler wie die folgenden erkennen:

    • Anomalien
    • Unerwartete Werte von kategorischen Variablen
    • Unerwartete Datenverteilungen

Unittests zum Validieren von Feature-Engineering schreiben

Ihre Rohdaten entsprechen möglicherweise dem Datenschema, aber Ihr Modell wird nicht mit Rohdaten trainiert. Stattdessen wird Ihr Modell mit Daten trainiert, die für die einzelnen Funktionen optimiert wurden. Ihr Modell wird beispielsweise mit normalisierten numerischen Merkmalen anstelle von numerischen Rohdaten trainiert. Da sich die aus Features abgeleiteten Daten stark von den Rohdaten unterscheiden können, müssen Sie sie separat prüfen.

Schreiben Sie Unittests basierend auf Ihrem Verständnis der Daten, die für die Features entwickelt wurden. Sie können beispielsweise Einheitentests schreiben, um Bedingungen wie die folgenden zu prüfen:

  • Alle numerischen Merkmale werden skaliert, z. B. zwischen 0 und 1.
  • One-Hot-codierte-Vektoren enthalten nur eine 1 und N-1 Nullen.
  • Die Datenverteilungen nach der Transformation entsprechen den Erwartungen. Wenn Sie beispielsweise Z-Scores zur Normalisierung verwendet haben, sollte der Mittelwert der Z-Scores 0 sein.
  • Ausreißer werden verarbeitet, z. B. durch Skalierung oder Begrenzung.

Messwerte für wichtige Datensegmente prüfen

Ein erfolgreiches Ganzes kann manchmal ein erfolgloses Teil verbergen. Mit anderen Worten: Ein Modell mit guten Gesamtmesswerten kann in bestimmten Situationen immer noch schlechte Vorhersagen treffen. Beispiel:

Ihr Einhornmodell schneidet insgesamt gut ab, aber schlecht, wenn es Vorhersagen für die Sahara trifft.

Wenn Sie als Entwickler mit einer insgesamt guten AUC zufrieden sind, bemerken Sie die Probleme des Modells in der Sahara möglicherweise nicht. Wenn es wichtig ist, für jede Region gute Vorhersagen zu treffen, müssen Sie die Leistung für jede Region im Blick behalten. Teilmengen von Daten, z. B. die der Sahara, werden als Datenslices bezeichnet.

Relevante Datensegmente identifizieren Vergleichen Sie dann die Modellmesswerte für diese Datensegmente mit den Messwerten für den gesamten Datensatz. Wenn Sie prüfen, ob Ihr Modell in allen Datensegmenten gut funktioniert, können Sie Bias entfernen. Weitere Informationen finden Sie unter Fairness: Bias bewerten.

Messwerte aus der Praxis verwenden

Mit Modellmesswerten wird nicht unbedingt die tatsächliche Wirkung Ihres Modells gemessen. Wenn Sie beispielsweise einen Hyperparameter ändern, kann sich die AUC eines Modells erhöhen. Wie hat sich die Änderung jedoch auf die Nutzerfreundlichkeit ausgewirkt? Um die tatsächliche Wirkung zu messen, müssen Sie separate Messwerte definieren. Sie könnten beispielsweise Nutzer Ihres Modells befragen, um zu bestätigen, dass sie wirklich ein Einhorn gesehen haben, als das Modell dies vorhergesagt hat.

Abweichungen zwischen Training und Bereitstellung prüfen

Abweichung zwischen Training und Bereitstellung bedeutet, dass sich Ihre Eingabedaten während des Trainings von Ihren Eingabedaten bei der Bereitstellung unterscheiden. In der folgenden Tabelle werden die beiden wichtigen Arten von Abweichungen beschrieben:

Typ Definition Beispiel Lösung
Schema-Abweichung Die Eingabedaten für das Training und die Bereitstellung entsprechen nicht demselben Schema. Das Format oder die Verteilung der Bereitstellungsdaten ändert sich, während Ihr Modell weiterhin mit alten Daten trainiert wird. Verwenden Sie dasselbe Schema, um Trainings- und Bereitstellungsdaten zu validieren. Prüfen Sie separat, ob es Statistiken gibt, die nicht von Ihrem Schema geprüft werden, z. B. den Anteil fehlender Werte.
Abweichungen von Features Die aufbereiteten Daten unterscheiden sich zwischen Training und Bereitstellung. Der Code für das Feature Engineering unterscheidet sich zwischen Training und Bereitstellung, was zu unterschiedlichen aufbereiteten Daten führt. Ähnlich wie bei der Schemaverzerrung sollten Sie dieselben statistischen Regeln für die aufbereiteten Daten für Training und Bereitstellung anwenden. Erfassen Sie die Anzahl der erkannten Features mit Abweichungen und das Verhältnis von Beispielen mit Abweichungen pro Feature.

Die Ursachen für Abweichungen zwischen Training und Bereitstellung können subtil sein. Berücksichtigen Sie immer, welche Daten Ihrem Modell zum Zeitpunkt der Vorhersage zur Verfügung stehen. Verwenden Sie beim Training nur die Features, die auch bei der Bereitstellung verfügbar sind.

Übung: Wissen testen

Angenommen, Sie haben einen Onlineshop und möchten vorhersagen, wie viel Umsatz Sie an einem bestimmten Tag erzielen werden. Ihr ML-Ziel ist es, den täglichen Umsatz anhand der Anzahl der Kunden als Feature vorherzusagen.

Welches Problem könnte auftreten?
Hier klicken, um die Antwort zu sehen

Auf Label-Lecks prüfen

Label-Leakage bedeutet, dass Ihre Ground Truth-Labels, die Sie vorhersagen möchten, versehentlich in Ihre Trainings-Features aufgenommen wurden. Label-Leakage ist manchmal sehr schwer zu erkennen.

Übung: Wissen testen

Angenommen, Sie erstellen ein binäres Klassifizierungsmodell, um vorherzusagen, ob ein neuer Krankenhauspatient Krebs hat. Ihr Modell verwendet Funktionen wie die folgenden:

  • Alter des Patienten
  • Geschlecht des Patienten
  • Vorherige medizinische Beschwerden
  • Name des Krankenhauses
  • Vitalparameter
  • Testergebnisse
  • Vererbung

Das Label sieht so aus:

  • Boolesch: Hat der Patient Krebs?

Sie partitionieren die Daten sorgfältig und sorgen dafür, dass Ihr Trainings-Dataset gut vom Validierungs- und Test-Dataset isoliert ist. Das Modell schneidet im Validierungs- und Test-Dataset sehr gut ab. Die Messwerte sind hervorragend. Leider schneidet das Modell bei neuen Patienten in der realen Welt sehr schlecht ab.

Warum hat dieses Modell, das im Test-Dataset hervorragend abgeschnitten hat, in der Praxis so schlecht abgeschnitten?
Hier klicken, um die Antwort zu sehen

Modellalter in der gesamten Pipeline überwachen

Wenn sich die Bereitstellungsdaten im Laufe der Zeit ändern, Ihr Modell aber nicht regelmäßig neu trainiert wird, sinkt die Modellqualität. Sie können nachvollziehen, wie viel Zeit seit dem letzten Retraining des Modells mit neuen Daten vergangen ist, und einen Schwellenwert für das Alter für Benachrichtigungen festlegen. Neben der Überwachung des Alters des Modells bei der Bereitstellung sollten Sie das Alter des Modells in der gesamten Pipeline überwachen, um Pipeline-Stopps zu erkennen.

Prüfen, ob Modellgewichte und ‑ausgaben numerisch stabil sind

Während des Modelltrainings sollten Ihre Gewichte und Schichtausgaben nicht NaN (Not a Number) oder Inf (unendlich) sein. Schreiben Sie Tests, um die Gewichte und Ausgaben der Ebenen auf NaN- und Inf-Werte zu prüfen. Außerdem muss mehr als die Hälfte der Ausgaben einer Ebene ungleich null sein.

Modellleistung überwachen

Dein Einhorn-Vorhersage-Tool ist beliebter als erwartet. Sie erhalten viele Vorhersageanfragen und noch mehr Trainingsdaten. Das klingt erst einmal gut, bis Sie feststellen, dass Ihr Modell immer mehr Speicherplatz und Zeit zum Trainieren benötigt. Sie entscheiden sich, die Leistung Ihres Modells zu überwachen. Gehen Sie dazu so vor:

  • Modellleistung nach Code-, Modell- und Datenversionen verfolgen. So können Sie die genaue Ursache für Leistungseinbußen ermitteln.
  • Testen Sie die Trainingsschritte pro Sekunde für eine neue Modellversion im Vergleich zur vorherigen Version und zu einem festen Schwellenwert.
  • Speicherlecks erkennen, indem Sie einen Grenzwert für die Speichernutzung festlegen.
  • API-Antwortzeiten überwachen und ihre Perzentile erfassen. Die Antwortzeiten der API liegen möglicherweise außerhalb Ihres Einflussbereichs. Langsame Antworten können jedoch zu schlechten realen Messwerten führen.
  • Anzahl der beantworteten Anfragen pro Sekunde beobachten.

Qualität des Live-Modells anhand von bereitgestellten Daten testen

Sie haben Ihr Modell validiert. Was aber, wenn sich Szenarien aus der Praxis, z. B. das Verhalten von Einhörnern, nach der Aufzeichnung Ihrer Validierungsdaten ändern? Dann nimmt die Qualität des bereitgestellten Modells ab. Die Qualität von Tests bei der Auslieferung ist jedoch schwierig, da Daten aus der realen Welt nicht immer gekennzeichnet sind. Wenn Ihre Auslieferungsdaten nicht gekennzeichnet sind, sollten Sie die folgenden Tests in Betracht ziehen:

  • Labels mithilfe von menschlichen Prüfern generieren:

  • Untersuchen Sie Modelle, die einen signifikanten statistischen Bias bei Vorhersagen aufweisen. Weitere Informationen finden Sie unter Klassifizierung: Bias bei Vorhersagen.

  • Messwerte für Ihr Modell in der realen Welt erfassen Wenn Sie beispielsweise Spam klassifizieren, vergleichen Sie Ihre Vorhersagen mit von Nutzern gemeldetem Spam.

  • Sie können potenzielle Abweichungen zwischen Trainings- und Bereitstellungsdaten verringern, indem Sie eine neue Modellversion für einen Teil Ihrer Anfragen bereitstellen. Wenn Sie Ihr neues Bereitstellungsmodell validieren, stellen Sie nach und nach alle Anfragen auf die neue Version um.

Achten Sie bei diesen Tests sowohl auf plötzliche als auch auf langsame Verschlechterungen der Vorhersagequalität.

Randomisierung

Machen Sie Ihre Pipeline zur Datengenerierung reproduzierbar. Angenommen, Sie möchten ein Feature hinzufügen, um zu sehen, wie sich das auf die Modellqualität auswirkt. Für einen aussagekräftigen Test sollten Ihre Datasets bis auf diese neue Funktion identisch sein. Achten Sie darauf, dass die Randomisierung bei der Datengenerierung deterministisch erfolgen kann:

  • Zufallszahlengeneratoren (RNGs) initialisieren. Durch das Seeding wird sichergestellt, dass der Zufallszahlengenerator bei jeder Ausführung dieselben Werte in derselben Reihenfolge ausgibt und Ihr Dataset neu erstellt wird.
  • Invariante Hash-Schlüssel verwenden: Hashing ist eine gängige Methode zum Aufteilen oder Erstellen von Stichproben von Daten. Sie können jedes Beispiel hashen und die resultierende Ganzzahl verwenden, um zu entscheiden, in welchem Split das Beispiel platziert werden soll. Die Eingaben für Ihre Hash-Funktion sollten sich nicht jedes Mal ändern, wenn Sie das Programm zur Datengenerierung ausführen. Verwenden Sie nicht die aktuelle Uhrzeit oder eine Zufallszahl in Ihrem Hash, wenn Sie Ihre Hashes beispielsweise bei Bedarf neu erstellen möchten.

Die oben beschriebenen Ansätze gelten sowohl für die Stichprobenerhebung als auch für das Aufteilen Ihrer Daten.

Hinweise zum Hashen

Stellen Sie sich noch einmal vor, Sie würden Suchanfragen erfassen und Hashing verwenden, um Anfragen ein- oder auszuschließen. Wenn für den Hash-Schlüssel nur die Abfrage verwendet wurde, müssen Sie diese Abfrage für Daten aus mehreren Tagen entweder immer einbeziehen oder immer ausschließen. Es ist nicht empfehlenswert, eine Abfrage immer einzubeziehen oder immer auszuschließen, weil:

  • Ihr Trainingsset enthält dann weniger unterschiedliche Anfragen.
  • Ihre Evaluierungssets werden künstlich erschwert, da sie sich nicht mit Ihren Trainingsdaten überschneiden. In der Realität werden Sie zum Zeitpunkt der Bereitstellung einen Teil des Live-Traffics in Ihren Trainingsdaten gesehen haben. Ihre Bewertung sollte dies widerspiegeln.

Stattdessen können Sie die Abfrage und das Abfragedatum hashen. Das Ergebnis ist dann für jeden Tag ein anderer Hash.

Abbildung 7. Animierte Visualisierung, die zeigt, wie das Hashing nur der Abfrage dazu führt, dass Daten jeden Tag in denselben Bucket gelangen. Wenn jedoch die Abfrage und die Abfragezeit gehasht werden, gelangen die Daten jeden Tag in andere Buckets. Die drei Gruppen sind „Training“, „Bewertung“ und „Ignoriert“.
Abbildung 7: Hashing für Abfrage im Vergleich zu Hashing für Abfrage + Abfragedatum.
Zurück
Bereitstellungstests (5 Minuten)
Weiter
Fragen stellen (10 Min.)