ARTIKEL 14
Data Leakage im Machine Learning für Finanzdaten
SEO-Titel: Data Leakage bei Finanzdaten erkennen und vermeiden
Meta-Description: Data Leakage erzeugt unrealistisch gute Machine-Learning-Ergebnisse. Erfahren Sie, wie Leakage bei Finanzzeitreihen, Preprocessing und Feature Engineering entsteht.
URL-Slug: /blog/data-leakage-finanzdaten/
Haupt-Suchbegriff: Data Leakage Finanzdaten
Weitere Suchbegriffe: Machine Learning Trading Fehler, Target Leakage, Time Series Leakage, Quant Machine Learning
Was ist Data Leakage?
Data Leakage entsteht, wenn Informationen in den Modellierungsprozess gelangen, die bei einer realen Prognose nicht verfügbar wären.
Das Modell erhält dadurch einen unfairen Informationsvorteil.
Die Folge:
- hohe Cross-Validation-Scores,
- beeindruckende Backtests,
- scheinbar präzise Prognosen.
Im Live-Betrieb bricht die Performance häufig ein.
Data Leakage gehört deshalb zu den gefährlichsten Fehlern im Machine Learning.
Warum Finanzdaten besonders anfällig sind
Finanzdaten besitzen eine natürliche zeitliche Ordnung.
Eine Information kann heute bekannt sein, morgen jedoch noch unbekannt gewesen sein.
Deshalb ist nicht nur entscheidend:
Welche Daten wurden verwendet?
Sondern:
Wann waren diese Daten tatsächlich verfügbar?
Schon kleine Fehler können Zukunftsinformationen in das Training einschleusen.
Beispiel: globale Standardisierung
Angenommen, ein Feature wird standardisiert:
z = (x − μ) / σ
Wenn Mittelwert μ und Standardabweichung σ aus dem gesamten Datensatz berechnet werden, fließen auch zukünftige Testdaten in die Transformation ein.
Selbst wenn das eigentliche Modell nie direkt die Testlabels sieht, besitzt das Preprocessing bereits Informationen über die Zukunft.
Korrekte Vorgehensweise
Zuerst:
Trainings- und Testdaten trennen
Danach:
Scaler nur auf Trainingsdaten fitten
Anschließend:
denselben Scaler auf Testdaten anwenden
Dieses Prinzip gilt nicht nur für Standardisierung.
Es gilt für fast alle datengetriebenen Transformationen.
Feature Selection Leakage
Angenommen, es existieren 10.000 potenzielle Features.
Aus dem gesamten Datensatz werden zunächst die 20 Features ausgewählt, die am stärksten mit dem Zielwert korrelieren.
Danach wird Train/Test aufgeteilt.
Das ist Leakage.
Der Testdatensatz hat bereits beeinflusst, welche Features ausgewählt wurden.
Feature Selection muss deshalb innerhalb des Trainingsprozesses erfolgen.
Target Leakage
Target Leakage liegt vor, wenn ein Feature Informationen enthält, die eng mit dem Zielwert verbunden sind, aber zum Prognosezeitpunkt nicht verfügbar wären.
Beispiel:
Ein Modell soll morgen steigende Aktienkurse prognostizieren.
Ein Feature enthält jedoch bereits eine Kennzahl, deren Berechnung teilweise morgige Preise verwendet.
Das Modell scheint extrem präzise.
Tatsächlich wurde ein Teil der Antwort bereits in die Eingaben eingebaut.
Look-ahead Bias als zeitliche Leakage
Im Finanzbereich überschneiden sich die Begriffe Data Leakage und Look-ahead Bias.
Look-ahead Bias ist eine spezielle Form zeitlicher Informationsverletzung.
Beispiele:
- endgültige Quartalszahlen werden schon vor Veröffentlichung verwendet,
- revidierte Wirtschaftsdaten werden rückwirkend eingesetzt,
- zukünftige Indexmitglieder sind bekannt,
- Schlusskurse werden genutzt, um zum selben Schlusskurs zu handeln.
Zufälliger Train-Test-Split
Ein Standardverfahren aus vielen ML-Anwendungen ist:
Daten zufällig mischen → 80 Prozent Training → 20 Prozent Test
Bei Finanzzeitreihen kann das problematisch sein.
Dann könnte das Modell auf Daten aus 2025 trainiert und auf Daten aus 2023 getestet werden.
Eine reale Prognosesituation sieht anders aus:
Vergangenheit → Zukunft
Deshalb sollte die zeitliche Reihenfolge häufig ausdrücklich berücksichtigt werden.
Leakage durch Imputation
Fehlende Werte werden häufig ersetzt.
Problematisch wäre beispielsweise, den Mittelwert des gesamten Datensatzes zu berechnen und damit fehlende Trainingswerte zu ersetzen.
Auch hier beeinflusst der Testdatensatz bereits das Training.
Der Imputer muss auf den Trainingsdaten fitten.
Leakage durch PCA
Principal Component Analysis wird häufig zur Dimensionsreduktion eingesetzt.
Wird PCA vor der Train-Test-Trennung auf dem gesamten Datensatz berechnet, beeinflussen zukünftige Testbeobachtungen bereits die Komponenten.
Auch PCA gehört deshalb in eine Pipeline, die ausschließlich auf dem Trainingsfold fitten darf.
Leakage bei Hyperparameteroptimierung
Auch Hyperparameter können Informationen aus dem Testset aufnehmen.
Angenommen:
- Modell trainieren.
- Testset auswerten.
- Parameter verändern.
- erneut Testset auswerten.
- beste Version wählen.
Nach vielen Wiederholungen ist das Testset kein unabhängiger Test mehr.
Es wurde faktisch zum Validierungsset.
Leakage durch überlappende Labels
Finanzprognosen beziehen sich häufig auf zukünftige Zeitfenster.
Beispielsweise:
Label = Rendite der nächsten 10 Tage
Nahe beieinanderliegende Beobachtungen teilen dann viele derselben zukünftigen Kurstage.
Gelangen solche Beobachtungen in unterschiedliche Folds, entsteht Informationsüberschneidung.
Hier können Verfahren wie Purging und Embargo helfen.
Pipeline statt manueller Einzelschritte
Eine saubere ML-Pipeline kann dabei helfen, Leakage zu verhindern.
Beispielsweise:
Training Fold
→ Imputation
→ Skalierung
→ Feature Selection
→ PCA
→ Modell
Alle lernenden Verarbeitungsschritte werden nur aus dem jeweiligen Trainingsfold bestimmt.
Danach werden sie unverändert auf den Testfold angewendet.
Warum Leakage so schwer zu erkennen ist
Leakage erzeugt häufig keine Fehlermeldung.
Der Code läuft.
Die Kennzahlen sehen hervorragend aus.
Gerade das macht das Problem gefährlich.
Typische Warnzeichen sind:
- unrealistisch hohe Prognosegüte,
- ungewöhnlich stabile Ergebnisse,
- starker Einbruch im Live-Betrieb,
- Features mit schwer erklärbarer Prognosekraft.
Praktische Kontrollfragen
Für jedes Feature sollte gefragt werden:
Wäre dieser Wert im echten Betrieb exakt zu diesem Zeitpunkt verfügbar?
Für jede Transformation:
Wurde sie ausschließlich aus Trainingsinformationen geschätzt?
Für jeden Test:
Hat dieses Testset bereits frühere Modellentscheidungen beeinflusst?
Für Cross-Validation:
Teilen Trainings- und Testbeobachtungen möglicherweise dieselben zeitlichen Informationen?
Data Leakage und wissenschaftliche Reproduzierbarkeit
Saubere Modellierung sollte dokumentieren:
- Split-Logik,
- Feature-Zeitstempel,
- Veröffentlichungslags,
- Preprocessing,
- Feature Selection,
- Hyperparameteroptimierung,
- endgültigen Holdout.
Damit kann nachvollzogen werden, ob der Informationsfluss methodisch korrekt war.
Fazit
Data Leakage bedeutet, dass ein Modell Informationen nutzt, die ihm in der realen Anwendung nicht zur Verfügung stehen würden.
Häufige Ursachen sind:
- Preprocessing vor Train/Test-Split,
- Feature Selection mit Gesamtdaten,
- Target Leakage,
- zufällige Zeitreihen-Splits,
- wiederholte Nutzung des Testsets,
- überlappende Labels.
Die wichtigste Regel lautet:
Alles, was aus Daten gelernt wird, muss innerhalb des Trainingsprozesses gelernt werden.
Nur so besitzt die spätere Testperformance eine belastbare Aussagekraft.
Weiterführende Literatur
- Hastie, T.; Tibshirani, R.; Friedman, J.: The Elements of Statistical Learning.
- López de Prado, M.: Advances in Financial Machine Learning.
- scikit-learn: Dokumentation zu Common Pitfalls and Data Leakage.
Passendes Fachbuch
Machine Learning für Finanzdaten von Olaf Sund.
Weiterführende Beiträge
- Purging und Embargo
- Look-ahead Bias
- Overfitting im Trading
- Cross-Validation für Finanzzeitreihen