Gewinne:
- Möglichkeit, Arten von Datenlecks zu erkennen (Ziel, Zeit, Vorverarbeitung, gruppierte Zeile) und die Bewertung „zu gut um wahr zu sein“ als Alarm abzufragen
- Möglichkeit zur Verhinderung von Leckagen durch frühzeitige Trennung von Prüfsatz, Rohrleitung und korrekter Aufteilung (chronologisch/gruppiert)
- Möglichkeit, Analysen mit festen Seeds, Versionskontrolle und Entfernung manueller Schritte reproduzierbar zu machen
Es gibt zwei Fehler, die in der Datenwissenschaft den größten Aufwand verschwenden, und beide sind heimtückisch, weil sie genau dann zur Katastrophe führen, wenn alles „in Ordnung zu sein scheint“. Der erste ist ein Datenleck: Das Modell funktioniert auf dem Testsatz hervorragend, stürzt jedoch in der Produktion ab. Der zweite Grund ist die Unreproduzierbarkeit: Man führt sechs Monate später eine Analyse durch und erhält ein völlig anderes Ergebnis. In dieser Einheit geht es darum, diese beiden Fallstricke eingehend zu kennen und zu vermeiden. KI kann beide Risiken erhöhen (schnelle Generierung, Hinweise auf versteckte Lecks, Erleichterung manueller Maßnahmen), bei richtiger Anwendung aber auch reduzieren. Der Unterschied liegt in der Disziplin.
Datenleck: Hellseher-Modell
Von Datenlecks spricht man, wenn das Modell während des Trainings Informationen sieht, über die es zum Zeitpunkt der tatsächlichen Vorhersage nicht verfügt. Das Modell „schummelt“ mit diesen Informationen, sieht auf dem Testset großartig aus, stürzt jedoch in der Produktion ohne diese Informationen ab. Das Symptom eines Lecks ist fast immer das gleiche: zu schön um wahr zu sein. Bevor Sie sich über eine Genauigkeit von 99 % freuen, sollten Sie nach Lecks suchen.
Die wichtigsten Arten von Leckagen sind:
1. Zielverlust: Eine Funktion ist ein Ergebnis des Ziels. In der Prognose „wurde storniert“ sind die Spalten „Stornierungsdatum“ oder „Rückerstattungsbetrag“ das Ergebnis des Ziels; Sie werden erst ausgefüllt, wenn das Ergebnis eindeutig ist.
2. Zeitleck: Zukünftige Informationen in die Vergangenheit verlagern. Berücksichtigen Sie bei der Berechnung des „Durchschnitts der letzten 30 Tage“ die Tage nach dem Prognosetag oder teilen Sie die Zeitreihe zufällig auf.
3. Vorverarbeitungsverlust: Lernen von Transformationen wie Skalierung, Füllen und Codieren aus allen Daten vor der Trainings-/Testpartition. Die Mittelung der Testdaten beeinträchtigt das Training.
4. Doppeltes/gruppiertes Zeilenleck: Zeilen, die derselben Person gehören, sind sowohl im Training als auch im Test vorhanden (zwei Besuche desselben Patienten in unterschiedlichen Sätzen). Das Modell merkt sich die Person.
Lecktyp
Wie wird geboren
So verhindern Sie
Zielleck
Spalte, die das Ergebnis des Ziels ist
Test „Habe ich es zum Zeitpunkt der Vorhersage?“
Zeitleck
Die Zukunft in die Vergangenheit bringen
Chronologische Einteilung, Fensterkontrolle
Vorverarbeitungsleck
Konvertierung vor der Aufteilung
Pipeline, fit schon vom Training her
Gruppiertes Zeilenleck
Gleiche Einheit in zwei Sätzen
Nach Gruppe aufteilen (GroupKFold)
Die einzige Disziplin, um Leckagen zu verhindern
Die gemeinsame Lösung für alle Arten von Lecks läuft auf einen Satz hinaus: Isolieren Sie den Testsatz so früh wie möglich, um die reale Zukunft nachzuahmen, und „lehren“ Sie ihm nichts. In der Praxis heißt das: Erst teilen, dann alle Transformationen erst aus dem Training lernen und in einer Pipeline (einer Struktur, die alle Schritte in einer einzigen Kette zusammenfasst) anwenden. Stellen Sie für jedes Feature die Frage: „Verfüge ich zum Zeitpunkt der Vorhersage über diese Informationen?“ Wenn noch Zeit vorhanden ist, teilen Sie diese chronologisch auf; Wenn sich dieselbe Einheit wiederholt, teilen Sie sie nach Gruppen auf.
Achtung: Der gefährlichste Aspekt eines Lecks besteht darin, dass es sich als Erfolg darstellt. Ein schlechtes Modell führt offensichtlich zu schlechten Ergebnissen und wird bemerkt; Ein durchgesickertes Modell funktioniert großartig, gefällt allen und wird in Produktion genommen – da beginnt der Zusammenbruch. Deshalb ist ein „sehr gutes“ Ergebnis kein Grund zur Freude, sondern Anlass zur Sorge.
Reproduzierbarkeit: zweimal das gleiche Ergebnis erzielen
Reproduzierbarkeit ist die Fähigkeit, das gleiche Ergebnis zu erhalten, wenn Sie eine Analyse zu einem anderen Zeitpunkt auf einem anderen Computer erneut ausführen. Ohne dies ist Ihre Analyse zufällig und nicht wissenschaftlich. Hauptursachen und Lösungen, die die Reproduzierbarkeit beeinträchtigen:
Manuelle Schritte: Manuelles Ändern einer Zelle in Excel, manuelles Bearbeiten eines Diagramms. Lösung: Führen Sie jeden Schritt im Code aus.
Unfixierte Zufälligkeit: Modelltraining, Stichprobenziehung und Aufteilung beinhalten Zufälligkeit. Lösung: Korrigieren Sie den Zufallsstartwert (den Anfangswert des Zufallsgenerators) (random_state=42).
Versionsverschiebungen: Das Ergebnis kann sich ändern, wenn sich die Bibliotheksversion ändert. Lösung: Abhängigkeiten beheben (requirements.txt, Umgebungsdatei).
Keine Aufzeichnung: Es ist nicht klar, welche Daten, welcher Code, welcher Parameter verwendet wurden. Lösung: Versionskontrolle (Git – das System, das alle Versionen des Codes speichert) und Datenversionierung.
„Es funktioniert nur auf meiner Maschine“: Lösung: Umgebung dokumentieren, wenn möglich Container (Docker) verwenden.
drei Mini-Koffer
Fall 1 – Zielleck. In einer Gesundheitsanalyse wurde die Spalte „Medikamente nach der Entlassung“ berücksichtigt, um vorherzusagen, „ob der Patient wieder aufgenommen wird“. Diese Spalte wurde erst nach der Entlassung des Patienten gefüllt. Das Modell lieferte 96 %, in der Produktion 61 %. Das 8-wöchige Projekt war Müll. Lektion: Fragen Sie jedes Merkmal: „Ist es zum Zeitpunkt der Vorhersage vorhanden?“
Fall 2 – Vorverarbeitungsleck. Ein Team skalierte alle Daten und teilte sie dann auf. Bei der Skalierung floss der Mittelwert der Testdaten ein. CV-Score 89 %, tatsächliche Produktion 76 %. Der vorgetäuschte Erfolg verschwand, als ich zu Pipeline wechselte und nur durch Training etwas über Transformationen lernte. Lektion: Erst dividieren, später transformieren.
Fall 3 – Fehler bei der Reproduktion. Ein Analyst wollte das Diagramm, das er dem Management drei Monate später vorlegte, aktualisieren, konnte sich aber nicht erinnern, wie er es erstellt hatte; Viele Schritte wurden manuell in Excel durchgeführt. Das Ergebnis stimmte nicht und das Vertrauen war erschüttert. Lektion: Keine manuellen Schritte, alles ist in Code und Git.
Vier kopierbare Vorlagen
1) Leckprüfung:
Ihre Rolle: Leckinspektor. Ziel: „Abwanderung“ (0/1), Prognose-Referenzdatum: Datensatzdatum. Ich werde Ihnen diese Liste der Funktionen geben. Für JEDES Merkmal: (a) ist es eine Konsequenz des Ziels, (b) steht es mir zum Zeitpunkt der Vorhersage zur Verfügung, (c) umfasst das Zeitfenster die Zukunft? Markieren Sie es als „unsicher/verdächtig/Leck“ und geben Sie einen Grund an. Funktionen: [Liste]
2) Leckagefreie Rohrleitung:
Richten Sie die Sklearn-Pipeline ein: Teilen Sie zuerst den Zug/Test auf (geschichtet, Startwert = 42) und fügen Sie DANN die gesamte Vorverarbeitung (Imputieren, Skalieren, Kodieren) NUR aus dem Training in die Pipeline ein. Erklären Sie, warum der Code leckagefrei ist und welcher Schritt wo gelernt wurde.
3) Code der Reproduzierbarkeits-Checkliste:
Ich möchte meine Analyse reproduzierbar machen. Schlagen Sie Code/Struktur vor, die Folgendes hinzufügt: (1) harten Startwert für alle Zufälligkeiten, (2) verwendete Versionen der Druckbibliothek, (3) Datums-/Versions-Tag für Daten und Ausgabe. Geben Sie mir auch eine Checkliste, um sicherzustellen, dass keine manuellen Schritte erforderlich sind.
4) Gruppierte Partition (gleiches Einheitsleck):
In den Daten ist dieselbe customer_id in mehreren Zeilen vorhanden. Nehmen Sie eine Aufteilung vor (GroupKFold oder GroupShuffleSplit, Gruppe = customer_id), die VERHINDERT, dass derselbe Kunde sowohl an Schulungen als auch an Tests teilnimmt. Fügen Sie Code ein, um zu überprüfen, dass sich nach der Aufteilung keine Kunden in beiden Gruppen befinden.
Schwache Eingabeaufforderung / Starke Eingabeaufforderung
Schwache Eingabeaufforderung:
Mein Modell hat eine Genauigkeit von 98 % zurückgegeben, ist das nicht großartig? Optimieren Sie den Code.
Das Feiern von 98 % verbirgt das Leck. Vor der Optimierung sollte hinterfragt werden, ob dieser Wert real ist oder nicht.
Kraftvolle Aufforderung:
Ihre Rolle: Leckinspektor. Mein Modell liefert im Testsatz eine Genauigkeit von 98 %, was für mich „zu gut um wahr zu sein“ klingt. Überprüfen Sie: (1) Sind Features das Ergebnis des Ziels, (2) Werden die Konvertierungen vor der Aufteilung durchgeführt, (3) Sind die gleichen Einheiten in zwei Sätzen vorhanden, (4) Gibt es Zeitlecks? Listen Sie alle verdächtigen Punkte auf; Konzentrieren Sie sich darauf, das Leck zu finden, und nicht darauf, den Fehler zu beheben.
Hier wird ein hoher Punktestand als Zeichen betrachtet, das in Frage gestellt und nicht gefeiert werden sollte.
Häufige Fehler
- Wir freuen uns über das „sehr gute“ Ergebnis. Eine „zu gut, um wahr zu sein“-Bewertung ist eine Leak-Warnung und kein Erfolg.
- Lernen der Transformation aus allen Daten vor der Division. Das häufigste Leck; Zuerst mit Pipeline teilen.
- Zufällige Aufteilung der Zeitreihe. Das Modell sieht die Zukunft; Eine chronologische Einteilung ist ein Muss.
- Belassen Sie die gleiche Einheit in zwei Sätzen. Das Modell merkt sich die Person; Nach Gruppe aufteilen.
- Nicht manuell eingreifen und in den Code schreiben. Die Analyse wird nicht mehr reproduzierbar; Alles sollte in Code und Git sein.
Tipp: Schreiben Sie zu Beginn Ihres Projekts ein aus zwei Sätzen bestehendes „Ehrenversprechen“: „Ich habe den Testsatz in keiner Weise berührt, bevor ich ihn in der Produktion sehe. Jeder Schritt ist im Code und der Startwert steht fest.“ Wenn Sie diese beiden Sätze nicht ehrlich unterschreiben können, ist Ihr Ergebnis noch nicht zuverlässig.
Zusammenfassend
Datenlecks und Nichtreproduzierbarkeit sind die beiden teuersten stillen Fehler in der Datenwissenschaft. Leakage ist die Zukunftsvision des Modells und stellt sich als falscher Erfolg dar; Die Lösung besteht darin, den Testsatz frühzeitig aufzuteilen, die Transformationen nur aus dem Training (Pipeline) zu lernen, jedem Feature die Frage zu stellen „Habe ich es zum Zeitpunkt der Vorhersage?“ und die korrekte Aufteilung vorzunehmen (chronologisch/gruppiert). Reproduzierbarkeit bedeutet, dass man zweimal das gleiche Ergebnis erzielen kann; Seine Lösung besteht darin, Schritte manuell zu entfernen, den Seed zu fixieren, die Versionen einzufrieren und alles in Git zu belassen. KI kann diese Risiken entweder erhöhen oder verringern; Es ist Ihre Disziplin, die bestimmt.
Anwendungsaufgabe
Nehmen Sie die Feature-Liste eines von Ihnen erstellten Modells (oder eines hypothetischen Modells) und stellen Sie jedem Feature die Frage: „Verfüge ich zum Zeitpunkt der Vorhersage über diese Informationen?“ schriftlich; Finden Sie mindestens einen Leak-Kandidaten. Füllen Sie dann eine Checkliste aus, um Ihre Analyse reproduzierbar zu machen: Ist der Seed festgelegt, gibt es manuelle Schritte, sind die Versionen registriert, liegen sie in Git vor? Beheben Sie die Mängel.
Checkliste
- [ ] Habe ich die Bewertung „zu gut um wahr zu sein“ als Leckwarnung abgefragt?
- [ ] Habe ich alle Transformationen nach der Trennung nur durch das Training gelernt?
- [ ] Habe ich nach der Zeit-/Gruppenstruktur (chronologisch/GroupKFold) eingeteilt?
- [ ] Habe ich alle Zufälligkeiten mit festem Startwert wiederholbar gemacht?
- [ ] Habe ich die manuellen Schritte entfernt und alles in der Code- und Versionskontrolle belassen?