Glückwunsch! Sie haben das Einhorn-Modell bereitgestellt. Ihr Modell sollte rund um die Uhr ohne Probleme laufen. Um dies sicherzustellen, müssen Sie Ihre ML-Pipeline überwachen.
Datenschema zum Validieren von Rohdaten schreiben
Um Ihre Daten im Blick zu behalten, sollten Sie sie kontinuierlich anhand der erwarteten statistischen Werte prüfen. Dazu müssen Sie Regeln festlegen, die die Daten erfüllen müssen. Diese Sammlung von Regeln wird als Datenschema bezeichnet. So definieren Sie ein Datenschema:
Sie können den Umfang und die Verteilung Ihrer Funktionen ermitteln. Bei kategorischen Features ist es wichtig, die möglichen Werte zu kennen.
Codieren Sie Ihr Verständnis in das Datenschema ein. Im Folgenden finden Sie einige Beispiele für Regeln:
- Achten Sie darauf, dass von Nutzern eingereichte Bewertungen immer zwischen 1 und 5 liegen.
- Prüfen Sie, ob das Wort the am häufigsten vorkommt (bei einer englischen Textfunktion).
- Prüfen Sie, ob für jedes kategorische Feature ein Wert aus einem festen Satz möglicher Werte festgelegt ist.
Testen Sie Ihre Daten anhand des Datenschemas. Ihr Schema sollte Datenfehler wie die folgenden erkennen:
- Anomalien
- Unerwartete Werte kategorialer Variablen
- Unerwartete Datenverteilungen
Unittests zum Validieren von Feature-Engineering schreiben
Auch wenn Ihre Rohdaten das Datenschema bestehen, wird Ihr Modell nicht mit Rohdaten trainiert. Stattdessen wird Ihr Modell mit Daten trainiert, die mithilfe von Feature Engineering erstellt wurden. Ihr Modell wird beispielsweise mit normalisierten numerischen Merkmalen statt mit Rohdaten trainiert. Da sich aus den Features erstellte Daten stark von Rohdaten unterscheiden können, müssen Sie sie separat von Ihren Prüfungen der Rohdaten prüfen.
Schreiben Sie Unit-Tests basierend auf Ihrem Verständnis von Feature-Engineering-Daten. Sie können beispielsweise Unit-Tests schreiben, um Folgendes zu prüfen:
- Alle numerischen Merkmale werden skaliert, z. B. auf einen Wert zwischen 0 und 1.
- One-Hot-codierte Vektoren enthalten nur eine einzige 1 und N‑1 Nullen.
- Die Datenverteilungen nach der Transformation entsprechen den Erwartungen. Wenn Sie beispielsweise mit Z-Werten normalisiert haben, sollte der Mittelwert der Z-Werte 0 sein.
- Außerhalb der Norm liegende Werte werden behandelt, z. B. durch Skalierung oder Ausbschneiden.
Messwerte für wichtige Datenschnitte prüfen
Ein erfolgreicher Gesamtwert verdeckt manchmal einen erfolglosen Teil. Mit anderen Worten: Ein Modell mit guten Gesamtmesswerten kann für bestimmte Situationen trotzdem schlechte Vorhersagen treffen. Beispiel:
Ihr Einhornmodell funktioniert insgesamt gut, aber nicht bei Vorhersagen für die Sahara.
Wenn Sie der Typ von Entwickler sind, der mit einem insgesamt guten AUC zufrieden ist, fallen Ihnen die Probleme des Modells in der Sahara möglicherweise nicht auf. Wenn Sie gute Prognosen für alle Regionen treffen möchten, müssen Sie die Leistung für jede Region im Blick behalten. Teilmengen von Daten, wie die, die der Sahara entspricht, werden als Datenschnitte bezeichnet.
Ermitteln Sie relevante Datenschnitte. Vergleichen Sie dann die Modellmesswerte für diese Datenschnitte mit den Messwerten für den gesamten Datensatz. Wenn Sie prüfen, ob Ihr Modell in allen Datensegmenten eine gute Leistung erzielt, können Sie Verzerrungen beseitigen. Weitere Informationen finden Sie unter Fairness: Voreingenommenheit prüfen.
Realistische Messwerte 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 wirkt sich die Änderung aber auf die Nutzerfreundlichkeit aus? Wenn Sie die tatsächliche Wirkung messen möchten, 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 vorhersagte, dass sie es tun würden.
Abweichungen zwischen Training und Bereitstellung prüfen
Abweichungen zwischen Training und Bereitstellung: Die Eingabedaten während des Trainings unterscheiden sich von den Eingabedaten bei der Bereitstellung. In der folgenden Tabelle werden die beiden wichtigsten Arten von Abweichungen beschrieben:
| Typ | Definition | Beispiel | Lösung |
|---|---|---|---|
| Schemaasymmetrie | Trainings- und Bereitstellungsdaten 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 Statistiken, die nicht von Ihrem Schema geprüft werden, wie der Anteil der fehlenden Werte, korrekt sind. |
| Abweichungen von Features | Erstellte Daten unterscheiden sich zwischen Training und Bereitstellung. | Der Code für die Feature-Erstellung unterscheidet sich zwischen Training und Bereitstellung, wodurch unterschiedliche erstellte Daten entstehen. | Ähnlich wie bei der Schemaverzerrung sollten Sie dieselben statistischen Regeln auf die Trainings- und die bereitgestellten Daten anwenden. Erfassen Sie die Anzahl der erkannten verzerrten Features und das Verhältnis der verzerrten Beispiele pro Feature. |
Die Ursachen für Abweichungen zwischen Training und Bereitstellung können subtil sein. Berücksichtigen Sie immer, welche Daten für Ihr Modell zum Zeitpunkt der Vorhersage verfügbar sind. Verwenden Sie während des Trainings nur die Funktionen, die auch bei der Bereitstellung verfügbar sind.
Übung: Wissen testen
Angenommen, Sie haben einen Onlineshop und möchten vorhersagen, wie viel Geld Sie an einem bestimmten Tag verdienen werden. Ihr ML-Ziel besteht darin, den täglichen Umsatz anhand der Anzahl der Kunden vorherzusagen.
Antwort:Das Problem ist, dass Sie die Anzahl der Kunden zum Zeitpunkt der Vorhersage nicht kennen, bevor die Verkäufe des Tages abgeschlossen sind. Diese Funktion ist also nicht nützlich, auch wenn sie den täglichen Umsatz sehr gut vorhersagen kann. Wenn Sie ein Modell trainieren und hervorragende Bewertungsmesswerte erhalten (z. B. 0,99 für den AUC), sollten Sie nach diesen Arten von Funktionen suchen, die sich auf Ihr Label auswirken können.
Auf Labellecks prüfen
Labelleckage bedeutet, dass Ihre Ground-Truth-Labels, die Sie vorhersagen möchten, versehentlich in Ihre Trainingsfeatures gelangt sind. Labellecks sind 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 Erkrankungen
- Name des Krankenhauses
- Vitalparameter
- Testergebnisse
- Vererbung
Das Label sieht so aus:
- Boolescher Wert: Hat der Patient Krebs?
Sie partitionieren die Daten sorgfältig und achten darauf, dass Ihr Trainings-Dataset gut vom Validierungs- und Test-Dataset getrennt ist. Das Modell schneidet im Validierungs- und Test-Set sehr gut ab. Die Messwerte sind fantastisch. Leider funktioniert das Modell bei neuen Patienten in der realen Welt sehr schlecht.
Antwort:Eine der Funktionen des Modells ist der Name des Krankenhauses. Bestimmte Krankenhäuser sind auf die Behandlung von Krebs spezialisiert. Während des Trainings lernte das Modell schnell, dass Patienten, die bestimmten Krankenhäusern zugewiesen waren, sehr wahrscheinlich Krebs hatten. Daher wurde der Name des Krankenhauses zu einem stark gewichteten Attribut.
Zum Zeitpunkt der Inferenz waren die meisten Patienten noch keinem Krankenhaus zugewiesen. Schließlich bestand der Zweck des Modells darin, das Vorhandensein oder Fehlen von Krebs zu diagnostizieren und den Patienten dann an ein geeignetes Krankenhaus zuzuweisen. Daher war die Funktion „Krankenhausname“ während der Inferenz noch nicht verfügbar und das Modell musste auf andere Funktionen zurückgreifen.
Alter des Modells in der gesamten Pipeline im Blick behalten
Wenn sich die Daten für die Auslieferung im Laufe der Zeit ändern, Ihr Modell aber nicht regelmäßig neu trainiert wird, nimmt die Modellqualität ab. Sie können die Zeit seit der Neuberechnung des Modells mit neuen Daten erfassen und einen Grenzwert für Benachrichtigungen festlegen. Neben dem Alter des Modells bei der Bereitstellung sollten Sie das Alter des Modells in der gesamten Pipeline überwachen, um Pipelineausfälle zu erkennen.
Prüfen, ob Modellgewichte und -ausgaben numerisch stabil sind
Während des Modelltrainings dürfen die Gewichte und Schichtausgaben nicht NaN (keine Zahl) oder Inf (unendlich) sein. Erstellen Sie Tests, um NaN- und Inf-Werte Ihrer Gewichte und Ebenenausgaben zu prüfen. Prüfen Sie außerdem, ob mehr als die Hälfte der Ausgaben einer Ebene nicht null ist.
Modellleistung beobachten
Die Vorhersage, wann ein Einhorn erscheint, war beliebter als erwartet. Sie erhalten viele Anfragen für Vorhersagen und noch mehr Trainingsdaten. Das ist großartig, bis Sie feststellen, dass Ihr Modell immer mehr Arbeitsspeicher und Zeit für das Training benötigt. Sie möchten die Leistung Ihres Modells im Blick behalten. Gehen Sie dazu so vor:
- Erfassen Sie die Modellleistung nach Code-, Modell- und Datenversionen. So können Sie die genaue Ursache für Leistungseinbußen ermitteln.
- Testen Sie die Trainingsschritte pro Sekunde für eine neue Modellversion anhand der vorherigen Version und eines festen Grenzwerts.
- Speicherlecks können Sie durch Festlegen eines Grenzwerts für die Arbeitsspeichernutzung erkennen.
- API-Antwortzeiten überwachen und die Perzentile verfolgen Die API-Antwortzeiten liegen zwar möglicherweise nicht in Ihrer Kontrolle, aber langsame Antworten können zu schlechten Messwerten in der Praxis führen.
- Anzahl der pro Sekunde beantworteten Abfragen im Blick behalten
Qualität des Live-Modells anhand der gesendeten Daten testen
Sie haben Ihr Modell validiert. Was aber, wenn sich reale Szenarien wie das Verhalten von Einhörnern ändern, nachdem Sie Ihre Validierungsdaten erfasst haben? Die Qualität des ausgelieferten Modells verschlechtert sich dann. Die Qualität der Auslieferung zu testen, ist jedoch schwierig, da reale Daten nicht immer gekennzeichnet sind. Wenn Ihre Auslieferungsdaten nicht gekennzeichnet sind, sollten Sie die folgenden Tests durchführen:
Modelle untersuchen, die bei Vorhersagen einen signifikanten statistischen Bias aufweisen Weitere Informationen finden Sie unter Klassifizierung: Voreingenommenheit bei der Vorhersage.
Messwerte in der Praxis für Ihr Modell erfassen Wenn Sie beispielsweise Spam klassifizieren, vergleichen Sie Ihre Vorhersagen mit von Nutzern gemeldetem Spam.
Sie können potenzielle Abweichungen zwischen Trainings- und Bereitstellungsdaten minimieren, indem Sie eine neue Modellversion für einen Teil Ihrer Abfragen bereitstellen. Während Sie Ihr neues Bereitstellungsmodell validieren, wechseln Sie schrittweise alle Abfragen zur neuen Version.
Achten Sie bei diesen Tests darauf, sowohl plötzliche als auch allmähliche Verschlechterungen der Vorhersagequalität im Blick zu behalten.
Randomisierung
Sorgen Sie dafür, dass Ihre Datengenerierungspipeline reproduzierbar ist. Angenommen, Sie möchten ein Feature hinzufügen, um zu sehen, wie sich das auf die Modellqualität auswirkt. Für einen fairen Test sollten Ihre Datensätze bis auf diese neue Funktion identisch sein. Achten Sie daher darauf, dass jede Zufallsmix-Funktion bei der Datengenerierung deterministisch ist:
- Legen Sie einen Startwert für Ihre Zufallszahlengeneratoren fest. Durch das Seeding wird sichergestellt, dass der Zufallsgenerator bei jedem Durchlauf dieselben Werte in derselben Reihenfolge ausgibt und der Datensatz neu erstellt wird.
- Verwenden Sie unveränderliche Hash-Schlüssel. Hashing ist eine gängige Methode, um Daten zu teilen oder zu stichproben. Sie können jedes Beispiel hashen und anhand der resultierenden Ganzzahl entscheiden, in welche Aufteilung das Beispiel eingefügt 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 in Ihrem Hash nicht die aktuelle Uhrzeit oder eine Zufallszahl, z. B. wenn Sie Ihre Hashes bei Bedarf neu erstellen möchten.
Die oben genannten Ansätze gelten sowohl für die Stichprobenerhebung als auch für die Aufteilung Ihrer Daten.
Hinweise zum Hashen
Stellen Sie sich noch einmal vor, Sie erfassen Suchanfragen und verwenden Hash-Technologie, um Suchanfragen ein- oder auszuschließen. Wenn für den Hash-Schlüssel nur die Abfrage verwendet wurde, wird sie in den Daten mehrerer Tage entweder immer ein- oder immer ausgeschlossen. Es ist nicht empfehlenswert, eine Abfrage immer ein- oder auszuschließen, da:
- Ihr Trainingssatz enthält dann weniger vielfältige Suchanfragen.
- Ihre Bewertungssätze sind künstlich schwierig, da sie sich nicht mit Ihren Trainingsdaten überschneiden. In der Realität werden Sie bei der Auslieferung bereits einige der Live-Zugriffe in Ihren Trainingsdaten gesehen haben. Das sollte sich in Ihrer Bewertung widerspiegeln.
Stattdessen können Sie die Hash-Technologie auf Abfrage + Datum anwenden, was jeden Tag zu einem anderen Hashwert führt.
