Zum Inhalt springen

Data Leakage und Look-ahead Bias

Informationen, die zum Entscheidungszeitpunkt nicht verfügbar waren, verunreinigen Features, Regeln, Validierung oder Ordersimulation und erzeugen historisch nicht kausal reproduzierbare Ergebnisse.

Für wen dieser Artikel gedacht ist — Für alle, die historische Daten in Signale verwandeln, Parameter optimieren, Machine Learning einsetzen oder Orders simulieren. Ein Modell kann fehlerfrei programmiert sein und dennoch die Zukunft „kennen“, weil eine Verknüpfung, ein Feature, ein Split oder ein Ausführungspreis die Kausalität verletzt.

Data Leakage ist die Verunreinigung eines Forschungsprozesses mit Informationen, die an der betreffenden Stelle noch nicht verfügbar sein durften. Look-ahead Bias ist der zeitliche Spezialfall: Die Entscheidung zum Zeitpunkt t enthält direkt oder indirekt Daten, die erst nach t bekannt wurden. Das Ergebnis ist nicht nur zu optimistisch. Simuliert wird eine andere Strategie mit einem Informationskanal, den es real nicht gab.

Einfach gesagt — Nach Datum sortierte Zeilen reichen nicht. Jeder Schritt muss dieser Reihenfolge folgen: verfügbare Information → Signal → Order → möglicher Fill → Position → Ergebnis.

Kausale Pipeline: Ereignis, Signal, Order und FillJeder Pfeil respektiert Verfügbarkeit und ersten ausführbaren Zeitpunkt. Zeitliches Beispiel: Kein Fill in derselben Bar wird ohne nachweisbare Marktregel angenommen.Kausale Pipeline: Ereignis, Signal, Order und FillJeder Pfeil respektiert Verfügbarkeit und ersten ausführbaren ZeitpunktZeitliches Beispiel: Kein Fill in derselben Bar wird ohne nachweisbare Marktregel angenommen.t₀1EreignisDaswirtschaftlicheoder marktbezogeneEreignis tritt zuseiner…t₁2VerfügbarkeitDie Strategieempfängt undverarbeitet Datenerst nach demzugehörigen Lag.t₂3SignalDie Berechnungendet mit demverfügbarenInformations-Snapshot.t₃4OrderDie Anweisung wirdnach Protokollaufgebaut,gesendet undangenommen.t₄5FillAusführungbenötigt späteren,zur Orderpassenden Preisund Liquidität.Ereignis ≤ Verfügbarkeit ≤ Signal ≤ Order ≤ erster möglicher FillCyclepedia · bedingtes Lehrdiagramm, weder Prognose noch Versprechen
Jeder Pfeil muss von der Vergangenheit in die Zukunft zeigen. Ein Rücksprung nach links weist auf ein mögliches Informationsleck hin.

Die wichtigsten Abgrenzungen

Problem Was geschieht Beispiel
Look-ahead Ein zukünftiger Wert fließt in die Entscheidung ein Mit dem Schlusskurs einer Kerze entscheiden und ohne nachgewiesene Auktionsmechanik zum selben Schlusskurs kaufen
Target Leakage Die Zielvariable sickert in die Features Eine Aggregation umfasst bereits den künftigen Zielzeitraum
Leakage im Preprocessing Schätzung oder Auswahl nutzt Training und Test gemeinsam Standardisierung mit Mittelwert und Streuung des gesamten Datensatzes
Leakage zwischen Stichproben Abhängige Beobachtungen liegen auf beiden Seiten der Grenze Überlappende Labels befinden sich in Training und Test
Revidierte Information Der endgültige statt des damals bekannten Werts wird verwendet Eine Monate später korrigierte Makrozahl
Nicht kausale Simulation Eine Order erhält einen unmöglichen Preis Signal auf dem Close und garantierter Fill am selben Close

Der Survivorship Bias ist davon zu unterscheiden: Er entsteht, wenn nur später überlebende oder rückblickend ausgewählte Einheiten beobachtet werden. Korrekte Zeitstempel stellen allein keine gescheiterten Unternehmen, geschlossenen Fonds oder früheren Indexmitglieder wieder her.


Drei Uhren: Signal, Order und Fill

Eine Handelsregel muss mindestens drei Zeitpunkte festlegen:

  1. Signalzeit: letzte Information, die in die Berechnung eingehen darf.
  2. Orderzeit: erster Moment, in dem eine Order erzeugt und übermittelt werden kann.
  3. Fillzeit: Zeitpunkt oder Intervall, in dem das Ausführungsmodell Menge und Preis zuweisen darf.

Verwendet das Signal close[t], setzt ein Fill zu close[t] eine tatsächlich verfügbare Mechanik vor oder während der Auktion sowie dazu passende Daten voraus. Fehlt dieser Nachweis, ist es belastbarer, die Order erst nach dem Signal zu senden und eine spätere Ausführung zu modellieren. Ebenso dürfen das vollständige Hoch und Tief einer Kerze keine Ausführung innerhalb derselben Kerze steuern, wenn ihre Intrabar-Reihenfolge unbekannt ist.

Bei Meldungen, Filings und Makrodaten zählt der Zeitpunkt der Veröffentlichung, nicht das Datum des wirtschaftlichen Berichtszeitraums. Point-in-time-Daten müssen zusätzlich Vintage, Lieferverzögerung des Datenanbieters und spätere Revisionen abbilden.


Wo Leakage verborgen sein kann

Features und Transformationen

  • zentrierte gleitende Durchschnitte, bidirektionale Filter oder Interpolation mit künftigen Beobachtungen;
  • Cross-Section-Rankings auf einem mit heutigem Wissen rekonstruierten Universum;
  • Winsorisierung, Imputation oder Standardisierung auf dem gesamten Datensatz;
  • Fundamentaldaten am Quartalsende statt am tatsächlichen Filing-Zeitpunkt;
  • Splits und Dividenden ohne Trennung von Wirksamkeit und Bekanntwerden.

Forschung und Auswahl

Auch ohne zukünftige Spalte kann ein Testset verunreinigt werden. Wird sein Ergebnis wiederholt zur Auswahl von Features, Schwellen oder Modellen betrachtet, wird es schrittweise zum Entwicklungsdatensatz. Out-of-Sample ist keine Dateibeschriftung, sondern eine Rolle im Entscheidungsprozess. Getestete Alternativen, verworfene Entscheidungen und Auswahlkriterien gehören ins Forschungsprotokoll.

Orders und Ausführung

Ein OHLC-Preis beweist keinen Fill. Stop- und Limitkurse können berührt werden, ohne dass eine Ausführung stattfindet; die verfügbare Menge kann fehlen; die Warteschlangenposition ist unbekannt; Verzögerungen und Teilfills verändern die Position. Immer den günstigsten Preis der Kerze zuzuweisen ist rückblickendes Wissen und berührt zugleich die Transaktionskosten im Backtest.


Kausales Prüfprotokoll

  1. Entscheidung vor dem Code beschreiben. Inputs, Zeitstempel, Zeitzone, Cut-off, Frequenz und Aktion festhalten.
  2. Rohdaten versionieren. Snapshots, Vintages, Universum und Corporate Actions aufbewahren, ohne Geschichte zu überschreiben.
  3. Jedes Feature „as of“ berechnen. Eine Abfrage bei t muss alle Datensätze mit available_at > t ausschließen.
  4. Nur im Training fitten. Imputation, Skalierung, Variablenauswahl und Optimierung im erlaubten Teil lernen und anschließend vorwärts anwenden.
  5. Zeitliche Ordnung wahren. Chronologische Splits verwenden; bei überlappenden Labels oder Positionen Purging und eine zum Horizont passende Lücke prüfen.
  6. Spezifikation einfrieren. Regeln, Parameter, Universum, Benchmark und Kennzahlen vor der finalen Bewertung versionieren.
  7. Signal, Order und Fill trennen. Verzögerung, Kalender, Ordertyp und wirklich beobachtbare Daten berücksichtigen.
  8. Alle Versuche erhalten. Ein Variantenregister macht Data Snooping sichtbar.
  9. Aus sauberem Snapshot wiederholen. Das Ergebnis muss ohne mit Zukunftswissen erzeugte Zwischendateien reproduzierbar sein.

Illustratives Beispiel — Eine Regel kauft zur Eröffnung, wenn der Quartalsgewinn die Erwartungen übertrifft. Die Datenbank ordnet den Wert dem Quartalsende zu, obwohl die Meldung erst sechs Wochen später erscheint. Der ursprüngliche Test handelt damit vor der Veröffentlichung. Die Korrektur speichert den Meldungszeitpunkt, wartet auf die nächste handelbare Phase und nutzt den damals verfügbaren Vintage. Zahlen und Ablauf erläutern die Kausalprüfung; sie sind keine Strategieempfehlung.


Diagnosetests

Test Möglicher Befund
Jedes Feature um eine Kerze verzögern verborgene Abhängigkeit von der aktuellen Kerze
Datensatz zu einem historischen Stichtag rekonstruieren Revisionen oder rückblickende Mitgliedschaften
Latenz und zeitliche Lücke künstlich erhöhen Empfindlichkeit gegenüber der kausalen Reihenfolge
Preprocessing je Fold getrennt fitten Verunreinigung zwischen Training und Test
Den „perfekten“ Kerzenpreis entfernen unmögliche Fills oder günstige Auswahl
Placebo mit zeitlich verschobenem Ziel ausführen verdächtige Korrelationen in der Pipeline

Ein Einbruch nach diesen Tests ist ein Warnsignal, aber kein automatischer Ursachenbeweis. Umgekehrt beweist Stabilität nicht die Abwesenheit von Leakage: Manche Lecks überstehen solche Störungen.

Grenzen

Zeitliche Splits, Walk-forward oder Cross-Validation reparieren keine bereits verunreinigten Daten. Purging und Embargo müssen aus der Labelstruktur folgen und dürfen kein Ritual sein. Ein kausaler Datensatz kann weiterhin Messfehler, Mehrfachselektion, Regimewechsel, geringe Teststärke oder ein unvollständiges Universum enthalten. Validierung benötigt daher statistische Kontrollen und ein Audit des gesamten Informationswegs.


Quellen

Verwandte Artikel