Datenpipeline: Sammlung, Bereinigung, Tagging und Versionierung

Gewinne:

• Möglichkeit, eine Datenpipeline einzurichten (Sammlung, Validierung, Bereinigung, Transformation, Aufteilung, Versionierung) und die Schemavalidierung am Anfang der Pipeline zu platzieren
• Fähigkeit, fehlende Werte und Kennzeichnungsentscheidungen auf der Grundlage der Feldbedeutung und -aufteilung zu treffen, um Datenlecks (gruppenweise und zeitlich) zu verhindern.
• Möglichkeit, eine reproduzierbare Datenbank zu erstellen, indem die Datenversion und der Zufallsstartwert festgelegt werden

Die wahre Stärke jedes maschinellen Lernsystems liegt in den Daten, nicht im Modell. Erfahrene Ingenieure wissen: „Müll rein, Müll raus“ – selbst das fortschrittlichste Modell, das mit schlechten Daten gefüttert wird, führt zu schlechten Ergebnissen. In dieser Einheit etablieren wir die Datenpipeline (Datenpipeline: die Schrittkette, die die Rohdaten für das Modelltraining bereit macht) End-to-End und lernen, an welchem ​​Schritt dieser Linie wir künstliche Intelligenz sicher einsetzen können.

Schritte der Datenleitung

Eine Datenleitung verläuft typischerweise durch diese Haltestellen:

1. Sammlung (Aufnahme): Daten aus Quellen abrufen (Datenbank, API, Protokolldateien, Ereignisströme).
2. Validierung: Überprüfen, ob die Daten dem erwarteten Schema, den erwarteten Typen und Bereichen entsprechen.
3. Bereinigung: Umgang mit fehlenden Werten, doppelten Datensätzen, Ausreißern und Inkonsistenzen.
4. Transformation: Rohdaten in Attribute umwandeln – beispielsweise die Umwandlung einer kategorialen Variablen in eine Zahl, wodurch aus einem Datum ein „Wochentag“ erzeugt wird.
5. Aufteilung: Aufteilung in Trainings-, Validierungs- und Testsätze.
6. Versionierung: Aufzeichnung, welches Modell mit welchen Daten trainiert wurde.

Künstliche Intelligenz spart Zeit durch die Generierung von Code-Entwürfen und Ideen, insbesondere in den Schritten 2, 3 und 4. Aber Entscheidungen, wie z. B. welcher Datensatz verworfen werden soll, welcher fehlende Wert gefüllt werden soll und wie, obliegen dem Ingenieur, der die Daten kennt; denn eine unsachgemäße Reinigung kann dem Modell eine versteckte Verzerrung verleihen.

Datenüberprüfung: Frühzeitige Verteidigung der Linie

Die teuersten Fehler beginnen nicht in der Produktion, sondern dort, wo der Verifizierungsschritt übersprungen wird. Die Schemavalidierung prüft automatisch, ob jeder eingehende Datenstapel der erwarteten Struktur entspricht. Liegt die Altersspalte beispielsweise zwischen 0 und 120, ist das E-Mail-Feld leer, hat sich die Anzahl der Spalten geändert?

Tipp: Platzieren Sie die Bestätigung am Anfang der Zeile. Je früher beschädigte Daten erkannt werden, desto kostengünstiger ist die Reparatur. Ein in der Produktion entdeckter Schemafehler ist um ein Vielfaches teurer als ein in der Trainingsphase entdeckter Schemafehler.

Schreiben Sie ein Validierungsschema mit pandera (oder Great Expectations) für das folgende Datenschema. Spalten und Regeln: – Benutzer-ID: Ganzzahl, darf nicht null sein, eindeutig – Alter: Ganzzahl, darf nicht zwischen 0 und 120 liegen – Anmeldedatum: Datum, darf nicht in der Zukunft liegen – Land: kategorisch, aus der Menge {TR, DE, US, UK} – Kontostand: dezimal, darf nicht negativ sein. Erzeugen Sie für jeden Regelverstoß eine aussagekräftige Fehlermeldung. Zeigen Sie den Test mit einer gestrichelten Beispiellinie am Ende des Codes an.

Reinigung: Der Mensch entscheidet

Fehlende Werte sind in jedem Datensatz eine Realität. Möglichkeiten zur Handhabung:

• Löschen: Verwerfen einer Zeile/Spalte mit einer sehr hohen Fehlquote. Es besteht jedoch die Gefahr von Informationsverlust und Voreingenommenheit.
• Imputation: Imputation mit Mittelwert, Median, häufigstem Wert oder modellbasierter Vorhersage.
• Flag: Speichern von „fehlt“-Informationen in einer separaten Flag-Spalte – manchmal ist das Fehlen selbst das Signal.

Welche die richtige ist, hängt vom Problem ab. In einem medizinischen Datensatz sollte die Information „Blutwert nicht gemessen“ beibehalten und nicht gelöscht werden; Denn auch die Weigerung des Arztes, Messungen vorzunehmen, ist ein Signal. KI kann Ihnen Optionen und Code geben; Sie entscheiden, welches zur Realität des Fachgebiets passt.

Schwache Eingabeaufforderung / Starke Eingabeaufforderung

Schwache Eingabeaufforderung: „Füllen Sie fehlende Werte ein.“

Starke Aufforderung: „In den folgenden Spalten fehlen Werte: Einkommen (12 % fehlen, rechtsschiefe Verteilung), last_login (30 % fehlen). Schlagen Sie vor, Einkommen mit dem Median zu füllen, aber erklären Sie, warum der Median und nicht der Mittelwert. Für last_login gehen Sie davon aus, dass der fehlende Wert signifikant sein könnte (der Benutzer hat sich möglicherweise noch nie angemeldet). Erwägen Sie die Erstellung eines Never_logged_in-Flags anstelle einer Löschung. Notieren Sie die Verzerrung, die jeder Ansatz zum Modell hinzufügen würde.“

Unterschied: Eine starke Eingabeaufforderung gibt Informationen zur Verteilung und zur Gebietsbedeutung an. Künstliche Intelligenz erzeugt Entscheidungsunterstützung statt mechanisches Ausfüllen.

Kennzeichnung: Qualität wird gemessen

Beim überwachten Lernen (Lernen, bei dem Beispiele mit den richtigen Antworten angegeben werden) lernt das Modell Beschriftungen (Beschriftungen: die richtige Antwort für jedes Beispiel). Die Labelqualität setzt eine Obergrenze – wenn Menschen inkonsistente Labels verwenden, lernt das Modell inkonsistent.

Die Inter-Annotator-Vereinbarung misst die Häufigkeit, mit der verschiedene Personen derselben Stichprobe die gleiche Bezeichnung geben. Es wird durch einen Koeffizienten wie Cohens Kappa ausgedrückt. Eine geringe Compliance weist darauf hin, dass entweder die Aufgabe unklar ist oder die Anweisung schwach ist.

Künstliche Intelligenz hilft bei der Kennzeichnung auf zwei Arten: (1) beim Entwerfen der Anmerkungsrichtlinie, (2) bei der Vorbeschriftung und der Korrektur durch den Menschen. Die Vorkennzeichnung mit LLM birgt jedoch eine Gefahr: Systematische Fehler des Modells können sich auf den gesamten Etikettensatz auswirken. Aus diesem Grund überprüfen Menschen immer einige der LLM-Labels.

Achtung: Betrachten Sie von LLM erstellte Etiketten nicht als „Ground Truth“. Überprüfen Sie eine Probe mit einem Menschen und messen Sie die LLM-Mensch-Passform. Bei geringer Compliance schadet eine Vorabkennzeichnung mehr als sie nützt.

Datenpartition: Leckage verhindern

Der gefährlichste Fehler bei der Aufteilung von Daten in Training/Validierung/Test ist der Datenverlust: die Vermischung von Testinformationen mit Training. Beispiele:

• Die Datensätze desselben Benutzers fallen sowohl in die Schulung als auch in die Tests (Gruppenleck).
• Verwendung der Zukunft im Training und der Vergangenheit beim Testen in Zeitreihen (zeitliche Leckage).
• Berechnen von Skalierungsparametern (Normalisierung) aus allen Daten und anschließendes Dividieren.

Bei zeitlichen Problemen ist die zeitliche Aufteilung unerlässlich: Trainieren Sie mit der Vergangenheit, testen Sie in der Zukunft. Die zufällige Aufteilung bietet einen „zukünftigen“ Vorteil, der in der Produktion niemals auftreten wird, und bläht die Kennzahlen auf.

Datenversionierung und Reproduzierbarkeit

„Mit welchen Daten haben wir dieses Modell trainiert?“ Die Frage Monate später beantworten zu können, ist das Markenzeichen ernsthaften ML-Engineerings. Bei der Datenversionierung wird jeder Daten-Snapshot mit einer ID (Hash oder Versions-Tag) gespeichert. Tools wie DVC (Data Version Control) Versionsdaten wie Code.

Um das Ergebnis eines Modells zu reproduzieren, müssen drei Dinge festgelegt werden: die Datenversion, die Codeversion und der Zufallsstartwert. Ohne dieses Trio kann man nicht sagen: „Ich habe das gleiche Ergebnis erzielt.“ Wir werden die Reproduzierbarkeit in Einheit 11 vertiefen; Aber das Fixieren des Seeds in der Datenpipeline beginnt hier.

drei Mini-Koffer

Fall 1 – Die Tagesschemavalidierung wurde gespeichert. Als ein Team ein Preisfeld eines vorgelagerten Systems von Pennies in Lira umwandelte, fielen alle Preise um das Hundertfache. Die Schemavalidierung hat den Batch als „Preis außerhalb des zulässigen Bereichs“ abgelehnt und das Modell wurde nicht mit beschädigten Daten trainiert. Ohne Verifizierung würde der Fehler erst in der Produktion mit falschen Vorhersagen auffallen.

Fall 2 – Verzerrung durch falsche Ausfüllung. In einem Kreditmodell wurden fehlende Einkommenswerte mit dem Mittelwert aufgefüllt. Die fehlenden Einkommen entfielen jedoch überwiegend auf die Gruppe mit niedrigem Einkommen; Durch die Mittelung wurde diese Gruppe künstlich „bereichert“, und das Modell bot ihr eine ungerechtfertigt hohe Grenze. Das Problem mit der Markierung „Median + Fehlen“ wurde behoben.

Fall 3 – Zeitliche Leckage. Ein Nachfrageprognosemodell sah auf dem Testset gut aus (95 % Genauigkeit), stürzte jedoch in der Produktion ab. Warum: Aufgrund der zufälligen Aufteilung hatte das Modell die Zukunft gesehen. Durch die Umstellung auf zeitliches Binning sank die Testgenauigkeit auf 78 % – aber das war echte Leistung und hielt sie in der Produktion.

Kopierbare Vorlagen

Teilen Sie den folgenden Datensatz in drei Sätze auf: Training/Validierung/Test. Einschränkung: Dies ist eine Zeitreihe; Verwenden Sie die zeitliche Aufteilung (in der Vergangenheit trainieren, in der Zukunft testen). Verhindern Sie Batch-Lecks: Verwenden Sie dieselbe „customer_id“ nur in einem Cluster. Berechnen Sie die Skalierungsparameter NUR aus dem Trainingssatz und wenden Sie sie dann auf alle an. Geben Sie aus, wie viele Zeilen bei jedem Schritt im Code verbleiben, und fügen Sie eine Zusicherung hinzu, die prüft, ob Lecks vorhanden sind.

Schreiben Sie einen Entwurf einer Anmerkungsrichtlinie für diese Kennzeichnungsaufgabe. Aufgabe: [z. B. Kennzeichnen Sie die Kundenbewertung als positiv/negativ/neutral.]Klären Sie Grenzfälle: Sarkasmus, gemischte Emotionen, wie kann man eine Bewertung kennzeichnen, die keinen Bezug zum Produkt hat? Geben Sie 5 Beispiele und 3 schwierige Randfälle an, die die Konsistenz zwischen Taggern erhöhen.

Erstellen Sie eine Reproduzierbarkeits-Checkliste für diese Datenpipeline: – Wie sollte die Datenversion korrigiert werden? – Welche Zufallsstartwerte sollten wo festgelegt werden? – Welche Metadaten (Daten-Hash, Zeilenanzahl, Datum) sollten protokolliert werden? Meine Codebasis: [Sprache/Bibliothek]

Überprüfen Sie diesen Bereinigungscode auf Datenlecks. Sehen Sie sich Folgendes konkret an: Werden die Skalierungs-/Kodierungsparameter VOR der Aufteilung berechnet? Werden Statistiken aus allen Daten berechnet oder nur aus dem Training? Code: [Code]

Entscheidungstabelle: Missing-Value-Strategie

Status

Empfohlener Ansatz

Warum

Numerische, schiefe Verteilung

mit Median füllen

Der Durchschnitt wird durch Ausreißer beeinflusst

Numerisch, symmetrisch

mit Durchschnitt füllen

Schützt Informationen

Der Mangel kann erheblich sein

Flag-Spalte + Füllung

Mangel ist ein Signal

Fehlquote > 60 %

Spalte auswerten/verwerfen

Lärm ist zu viel

Kategorisch

Kategorie „Unbekannt“.

Schafft keine künstliche Mehrheit

Häufige Fehler

• Verifizierung überspringen. Ohne Schemakontrolle schleichen sich beschädigte Daten unbemerkt ein.
• Skalieren vor dem Teilen. Es gibt Teststatistiken an die Bildung weiter.
• Verwendung zufälliger Aufteilung in Zeitreihen. Es erzeugt gefälschte hohe Messwerte.
• LLM-Labels blind vertrauen. Systematische Fehler breiten sich in den Daten aus.
• Die Datenversion wird nicht gespeichert. Sie können das Ergebnis nicht reproduzieren.
• Mechanische Füllung mit Durchschnitt. Es ignoriert die Feldbedeutung und fügt Voreingenommenheit hinzu.

Zusammenfassend

Die Datenpipeline ist die Grundlage des ML-Systems und verdient mehr Aufwand als das Modell. Platzieren Sie die Bestätigung oben; Treffen Sie Reinigungs- und Etikettierungsentscheidungen mit Domänenwissen. Leckagen (gruppenweise und zeitlich) im Fach verhindern; Korrigieren Sie die Datenversion und den Seed. KI generiert auf dieser Linie Code und Ideen, aber Sie entscheiden, welche Daten Sie wie verarbeiten – denn jede Fehlentscheidung geht hier als versteckter Fehler in das Modell ein.

Anwendungsaufgabe

Schreiben Sie ein Validierungsschema (Pandera/Great Expectations) für Ihren eigenen Datensatz, fügen Sie absichtlich eine fehlerhafte Zeile hinzu und zeigen Sie, dass sie abgefangen wurde. Teilen Sie die Daten dann zeitlich oder stapelweise auf, berechnen Sie die Skalierungsparameter nur aus dem Training und stellen Sie mit einer Bestätigung sicher, dass keine Datenlecks vorliegen. Schreiben Sie die Datenversion und Zeilenanzahl in eine Metadatendatei.

Checkliste

• [ ] Die Schemavalidierung wird am Anfang der Zeile ausgeführt.
• [ ] Ich habe die Strategie für fehlende Werte basierend auf der Feldbedeutung ausgewählt und sie nicht automatisch ausgefüllt.
• [ ] Ich habe die Etikettenqualität (Compliance) gemessen; Ich habe LLM-Tags von Menschen überprüft.
• [ ] Ich habe Gruppen- und Zeitlecks im Bereich verhindert.
• [ ] Skalierung/Kodierung wird nur aus dem Trainingssatz berechnet.
• [ ] Datenversion, Anzahl der Reihen und Saatgut erfasst.