ARTIKEL 13
Purging und Embargo bei Finanzdaten: Leakage in zeitabhängigen Daten verhindern
SEO-Titel: Purging und Embargo bei Finanzdaten verständlich erklärt
Meta-Description: Purging und Embargo reduzieren Informationslecks bei der Cross-Validation von Finanzzeitreihen. Erfahren Sie, warum klassische K-Fold-Verfahren problematisch sein können.
URL-Slug: /blog/purging-embargo-finanzdaten/
Haupt-Suchbegriff: Purging Embargo Machine Learning
Weitere Suchbegriffe: Purged Cross Validation, Finanzzeitreihen Cross Validation, Data Leakage Trading
Warum Cross-Validation bei Finanzdaten schwierig ist
Machine Learning verwendet Cross-Validation, um die Leistungsfähigkeit eines Modells auf unbekannten Daten abzuschätzen.
Bei unabhängig und identisch verteilten Beobachtungen können klassische Verfahren sehr gut funktionieren.
Finanzdaten besitzen jedoch häufig:
- zeitliche Abhängigkeiten,
- überlappende Beobachtungsfenster,
- Features mit langen Lookback-Perioden,
- Labels, die sich über zukünftige Zeiträume erstrecken.
Dadurch können Trainings- und Testdaten indirekt Informationen miteinander teilen.
Ein scheinbar sauberer Cross-Validation-Score kann dann zu optimistisch sein.
Beispiel mit überlappenden Labels
Angenommen, ein Modell soll die Rendite der kommenden fünf Handelstage prognostizieren.
Das Label am Montag verwendet:
Montag bis Freitag
Das Label am Dienstag verwendet:
Dienstag bis Montag
Beide Labels überschneiden sich erheblich.
Werden Montag und Dienstag unterschiedlichen Cross-Validation-Folds zugeordnet, sind Trainings- und Testdaten nicht wirklich unabhängig.
Sie enthalten teilweise dieselben zukünftigen Marktbewegungen.
Was bedeutet Purging?
Purging bedeutet, aus dem Trainingsdatensatz diejenigen Beobachtungen zu entfernen, deren Informations- oder Label-Zeiträume mit dem Testdatensatz überlappen.
Beispiel:
Ein Test-Label nutzt Marktdaten vom 10. bis 15. Juni.
Eine Trainingsbeobachtung verwendet ebenfalls Informationen bis zum 12. Juni.
Dann besteht eine zeitliche Überschneidung.
Diese Trainingsbeobachtung sollte „gepurgt“, also entfernt werden.
Warum das wichtig ist
Ohne Purging kann das Modell indirekt einen Teil dessen kennen, was im Testdatensatz geschieht.
Der Effekt kann subtil sein.
Es muss keine direkte Kopie eines Testwertes im Trainingsdatensatz vorhanden sein.
Eine zeitliche Überlappung der zugrunde liegenden Informationsfenster reicht bereits aus.
Was bedeutet Embargo?
Embargo bezeichnet eine zusätzliche Sicherheitszone um einen Testabschnitt.
Bestimmte Beobachtungen unmittelbar nach beziehungsweise in zeitlicher Nähe des Testbereichs werden nicht für das Training verwendet.
Ziel ist es, Informationsüberschneidungen und starke zeitliche Abhängigkeiten zwischen Test- und Trainingsbeobachtungen weiter zu reduzieren.
Die konkrete Länge des Embargos sollte zur Struktur der Daten und der verwendeten Informationshorizonte passen.
Purging und Embargo sind nicht dasselbe
Purging
entfernt konkrete Trainingsbeobachtungen mit überlappenden Informations- oder Label-Zeiträumen.
Embargo
erzeugt zusätzlich einen zeitlichen Abstand zwischen Testdaten und angrenzenden Trainingsdaten.
Beide Verfahren verfolgen dasselbe übergeordnete Ziel:
die Unabhängigkeit der Validierung zu verbessern.
Warum zufälliges K-Fold bei Zeitreihen problematisch sein kann
Bei klassischer zufälliger K-Fold-Cross-Validation werden Beobachtungen über verschiedene Folds verteilt.
Bei Finanzdaten kann dadurch Folgendes geschehen:
Trainingsdaten: 2024
Testdaten: 2023
Das Modell wird damit teilweise auf der Zukunft trainiert und in der Vergangenheit getestet.
Für viele Prognoseanwendungen entspricht das nicht dem tatsächlichen Einsatz.
Feature-Lookbacks verursachen zusätzliche Abhängigkeit
Nicht nur Labels können überlappen.
Auch Features besitzen häufig historische Fenster.
Beispielsweise:
60-Tage-Volatilität
Für eine Beobachtung werden die vergangenen 60 Tage verwendet.
Zwei nahe beieinanderliegende Beobachtungen teilen fast dieselben Eingangsdaten.
Sie sind daher statistisch nicht völlig unabhängig.
Purged Cross-Validation
Eine purged Cross-Validation berücksichtigt die zeitlichen Informationsintervalle jeder Beobachtung.
Für jeden Testfold werden Trainingsbeispiele entfernt, deren Informationsbereiche den Testfold überlappen.
Das Ziel besteht nicht darin, möglichst viele Trainingsdaten zu verwenden.
Das Ziel besteht darin, eine glaubwürdigere Out-of-Sample-Schätzung zu erhalten.
Beispiel
Angenommen:
Testperiode: 1.–30. September
Ein Trainingsbeispiel beginnt am 28. August und sein Label endet am 4. September.
Obwohl der Startpunkt vor dem Testzeitraum liegt, reicht sein Label in die Testperiode hinein.
Es sollte deshalb aus dem Training entfernt werden.
Embargo-Beispiel
Angenommen, nach dem Testzeitraum wird zusätzlich ein Embargo von fünf Handelstagen verwendet.
Dann werden auch Beobachtungen unmittelbar nach dem Testblock vorübergehend vom Training ausgeschlossen.
Dadurch entsteht ein zusätzlicher Informationsabstand.
Purging ersetzt keine zeitliche Logik
Purging und Embargo sind keine Rechtfertigung dafür, beliebige zeitliche Datensplits zu verwenden.
Der gesamte Validierungsprozess muss weiterhin zur realen Anwendung passen.
Wenn ein Modell zukünftige Marktdaten prognostizieren soll, sollte die Testlogik grundsätzlich eine echte Zukunftssituation nachbilden.
Besonders wichtig bei Event Labels
Viele Finanz-ML-Verfahren definieren Labels über Ereignishorizonte.
Beispiele:
- Rendite über zehn Tage,
- Triple-Barrier-Labels,
- Stop-Loss/Take-Profit-Ereignisse,
- Volatilitätsereignisse.
Die Länge des Labels kann dabei von Beobachtung zu Beobachtung variieren.
Gerade dann wird eine einfache Zeilenaufteilung des Datensatzes schnell problematisch.
Purging bei Feature Engineering
Auch Feature Engineering sollte in den Validierungsprozess eingebettet sein.
Nicht korrekt wäre beispielsweise:
- gesamten Datensatz normalisieren,
- Features auswählen,
- danach Cross-Validation durchführen.
Dann haben Testdaten bereits die Transformation beeinflusst.
Korrekt ist:
- Fold definieren,
- nur Trainingsdaten zur Bestimmung der Transformation verwenden,
- Transformation auf Testdaten anwenden.
Wie groß sollte das Embargo sein?
Es gibt keine universelle Prozentzahl, die für alle Anwendungen optimal ist.
Die Wahl hängt unter anderem ab von:
- Label-Horizont,
- Feature-Lookbacks,
- Datenfrequenz,
- Autokorrelation,
- Handelslogik.
Das Embargo sollte methodisch begründet und nicht nachträglich auf maximale Performance optimiert werden.
Nachteile
Purging und Embargo reduzieren die Zahl verfügbarer Trainingsbeobachtungen.
Das kann bei kleinen Datensätzen problematisch sein.
Doch zusätzliche Datenmenge ist wertlos, wenn sie zu einer verzerrten Validierung führt.
Die entscheidende Frage ist deshalb nicht:
Wie nutze ich möglichst viele Beobachtungen?
Sondern:
Wie erhalte ich eine möglichst realistische Einschätzung der Generalisierungsfähigkeit?
Fazit
Finanzdaten stellen klassische Cross-Validation vor besondere Herausforderungen.
Zeitliche Abhängigkeiten und überlappende Label-Horizonte können zu unbemerktem Information Leakage führen.
Purging entfernt überschneidende Trainingsbeobachtungen.
Embargo schafft zusätzlichen zeitlichen Abstand.
Zusammen können beide Verfahren eine realistischere Beurteilung von Machine-Learning-Modellen für Finanzdaten ermöglichen.
Weiterführende Literatur
- López de Prado, M.: Advances in Financial Machine Learning, Kapitel zu Cross-Validation in Finance.
- Hastie, T.; Tibshirani, R.; Friedman, J.: The Elements of Statistical Learning.
- Bailey, D. H. et al.: Forschung zu Backtest Overfitting.
Passendes Fachbuch
Machine Learning für Finanzdaten von Olaf Sund.
Weiterführende Beiträge
- Data Leakage
- In-Sample und Out-of-Sample
- Walk-Forward-Analyse
- Overfitting im Trading