Best Practices für Backfilling
Aus verschiedenen Gründen kann es erforderlich sein, Daten nachzufüllen (Backfilling) – sei es aufgrund von Datenfehlern, neuen Informationen (z. B. neuen Features) oder der Abstimmung von Daten zwischen zwei Systemen. Wenn ein Backfilling durchgeführt wird, befolgen Sie die Grundsätze in diesem Artikel, um die Datenqualität und die Performance des Modells aufrechtzuerhalten.
Wann ein Backfilling erforderlich ist
Backfilling bezeichnet das nachträgliche Befüllen eines Datensatzes mit historischen Daten. Typische Szenarien sind:
| Szenario | Beschreibung | Beispiel |
|---|---|---|
| Neue Features | Sie haben eine neue Metrik identifiziert, die für Ihr Modell wichtig ist, und verfügen über die historischen Rohprotokolle, um sie zu berechnen. | Sie fügen die „Click-through-Rate“ als Feature hinzu und benötigen drei Monate Verlauf, damit das Modell genügend Daten zum Lernen hat. |
| Datenwiederherstellung | Ihre Daten-Pipeline ist an bestimmten Tagen ausgefallen, wodurch Lücken in den an Decisioning Studio Pro zugestellten Daten entstanden sind. | Ein Pipeline-Ausfall am Dienstag hat eine Lücke hinterlassen. Nachdem die Korrektur bereitgestellt wurde, füllen Sie die fehlenden Datensätze aus dem Quellsystem nach. |
| Logikänderungen | Sie haben die Formel für die Berechnung eines Features aktualisiert oder die Definition eines Events geändert. | Sie haben „aktive:r Nutzer:in“ neu definiert und müssen historische Daten erneut exportieren, damit das Modell mit der aktualisierten Definition trainiert wird. |
Anforderungen
Damit Decisioning Studio Pro korrekt funktioniert, müssen alle eingehenden Daten ein Backfilling für historische Zeiträume unterstützen. Das erforderliche Lookback-Fenster (in Monaten) hängt von den Trainingsanforderungen des KI-Modells ab. Wenden Sie sich an Ihr AI Decisioning Services Team, um den richtigen Wert für Ihren Anwendungsfall zu bestätigen.
Bei einem historischen Backfill gelten die folgenden Standards verbindlich:
- Prozesskonsistenz: Historische Feature-Snapshots müssen mit einem Prozess erstellt werden, der vollständig mit der Erstellung von Live-Snapshots übereinstimmt. Wenn Ihre Live-Pipeline Transformationen, Aggregationen oder Filter anwendet, müssen dieselben Schritte auch auf die Backfill-Daten angewendet werden.
- Schemakonsistenz: Das Schema der Backfill-Daten muss exakt mit der regulären täglichen Pipeline übereinstimmen. Das umfasst dieselben Felder, Datentypen und Namenskonventionen für Spalten.
Häufige Fallstricke
Data Leakage (Look-ahead-Bias)
Data Leakage ist der schwerwiegendste Fehler beim Backfilling. Er tritt auf, wenn der Backfill-Prozess unbeabsichtigt Informationen einbezieht, die zum Zeitpunkt der Erstellung des historischen Datensatzes noch nicht verfügbar gewesen wären.
Warum das wichtig ist
Wenn das Modell mit Daten trainiert wird, die „die Zukunft kennen“, scheint es während des Trainings gut zu funktionieren, liefert in der Produktion jedoch schlechte Ergebnisse, da Realtime-Entscheidungen keinen Zugriff auf zukünftige Daten haben.
Ein Beispiel: Sie berechnen ein historisches „Lifetime-Value“-Feature anhand der bisherigen Gesamtausgaben einer Kund:in (also bis heute) und verwenden diesen Wert dann, um ein Verhalten vorherzusagen, das vor Monaten stattgefunden hat. Zum Zeitpunkt dieses historischen Ereignisses war der vollständige Lifetime-Value noch nicht bekannt.
Vermeiden Sie dies, indem Sie jedes historische Feature aus den Informationen rekonstruieren, die zum jeweiligen historischen Zeitpunkt verfügbar waren.
Schema- und Logik-Drift
Datenstrukturen und geschäftliche Definitionen entwickeln sich im Laufe der Zeit weiter. Inkonsistenzen zwischen historischen und Live-Daten können die Modellqualität unbemerkt verschlechtern.
- Schema-Drift: Wenn ein Feld (zum Beispiel
zip_code) erst kürzlich zu Ihrer Datenbank hinzugefügt wurde, enthalten per Backfill erstellte Datensätze aus der Zeit vor dieser Änderung Nullwerte für dieses Feld. Stellen Sie sicher, dass Ihre Pipeline fehlende Felder sauber verarbeitet und dass das Modell nicht übermäßig von Feldern mit lückenhafter historischer Abdeckung abhängt. - Logik-Drift: Wenn sich die Definition einer Metrik zu einem bestimmten Zeitpunkt geändert hat (zum Beispiel wurde „aktive:r Nutzer:in“ im Jahr 2024 neu definiert), kann die einheitliche Anwendung der neuen Definition auf ältere Daten (zum Beispiel Datensätze aus 2022) künstliche Spitzen oder Einbrüche erzeugen, die tatsächlich nie stattgefunden haben. Wenden Sie nach Möglichkeit die Definition an, die zum Zeitpunkt des jeweiligen historischen Datensatzes galt, oder dokumentieren Sie den Bruchpunkt klar, damit das Modell ihn berücksichtigen kann.
Doppelte Datensätze durch fehlgeschlagene Backfill-Jobs
Backfill-Jobs, die während der Ausführung fehlschlagen und neu gestartet werden, können doppelte Datensätze erzeugen, wenn der Prozess nicht darauf ausgelegt ist, dies zu verhindern. Doppelte Datensätze blähen Metriken künstlich auf und bringen Rauschen in das Modelltraining.
Die Lösung: Gestalten Sie alle Backfill-Skripte idempotent: Wird derselbe Job zweimal ausgeführt, sollte er dasselbe Ergebnis liefern wie bei einer einmaligen Ausführung. Verwenden Sie eines der folgenden Muster:
- Upsert (Update oder Insert): Basiert auf einer eindeutigen Transaktions-ID oder einem Zeitstempel, sodass das erneute Einfügen eines vorhandenen Datensatzes diesen aktualisiert, anstatt ein Duplikat zu erstellen.
- Löschen und dann einfügen: Löschen Sie vor dem Einfügen vorhandene Datensätze für den betreffenden Zeitraum, sodass der Datensatz immer sauber ersetzt wird.