ARTIKEL 28
Cross-Validation für Finanzzeitreihen: Warum klassische Verfahren problematisch sein können
SEO-Titel: Cross-Validation für Finanzzeitreihen richtig anwenden
Meta-Description: Warum klassische K-Fold-Cross-Validation bei Finanzzeitreihen problematisch sein kann und wie Time-Series-Splits, Walk-Forward, Purging und Embargo helfen.
URL-Slug: /blog/cross-validation-finanzzeitreihen/
Haupt-Suchbegriff: Cross Validation Finanzzeitreihen
Weitere Suchbegriffe: Time Series Cross Validation, Machine Learning Trading Validierung, Walk Forward Machine Learning, Purged Cross Validation
Warum Cross-Validation wichtig ist
Ein Machine-Learning-Modell kann auf Trainingsdaten sehr gut funktionieren und auf neuen Daten vollständig scheitern.
Deshalb muss seine Generalisierungsfähigkeit untersucht werden.
Cross-Validation ist ein Verfahren, bei dem Daten mehrfach in Trainings- und Testbereiche aufgeteilt werden.
Dadurch kann geprüft werden, ob die Modellleistung über unterschiedliche Stichproben hinweg stabil bleibt.
Bei Finanzdaten entsteht allerdings ein besonderes Problem:
Die Beobachtungen besitzen eine zeitliche Reihenfolge.
Diese Reihenfolge darf nicht beliebig zerstört werden.
Klassische K-Fold-Cross-Validation
Bei K-Fold wird der Datensatz in K Teilmengen aufgeteilt.
Beispiel mit fünf Folds:
Fold 1
Fold 2
Fold 3
Fold 4
Fold 5
In jeder Runde dienen vier Folds dem Training und einer dem Test.
Bei unabhängigen Beobachtungen kann dieses Verfahren sehr sinnvoll sein.
Bei Finanzzeitreihen kann es jedoch problematisch werden.
Das Zukunftsproblem
Angenommen, die Daten reichen von 2010 bis 2025.
Ein klassischer Fold könnte erzeugen:
Training: 2010–2012 und 2016–2025
Test: 2013–2015
Das Modell verwendet dann Informationen aus den Jahren nach 2015, um eine frühere Periode zu prognostizieren.
Für eine reale Investmentanwendung ist das häufig nicht plausibel.
Damals standen die zukünftigen Daten schließlich nicht zur Verfügung.
Zeitliche Cross-Validation
Eine geeignetere Struktur kann so aussehen:
Training 1: 2010–2014
Test 1: 2015
Training 2: 2010–2015
Test 2: 2016
Training 3: 2010–2016
Test 3: 2017
Die Trainingsperiode liegt immer zeitlich vor der Testperiode.
Dadurch wird eine reale Prognosesituation besser nachgebildet.
Expanding Window
Das vorherige Beispiel verwendet ein wachsendes Trainingsfenster.
Mit jedem Schritt kommen neue historische Daten hinzu.
Schema:
Train: 1–100
Test: 101–120
danach:
Train: 1–120
Test: 121–140
Vorteil:
Alle vergangenen Informationen bleiben verfügbar.
Nachteil:
Sehr alte Marktregime beeinflussen das Modell weiterhin.
Rolling Window
Beim Rolling Window bleibt die Trainingslänge konstant.
Beispiel:
Train: 1–100
Test: 101–120
danach:
Train: 21–120
Test: 121–140
Ältere Beobachtungen werden entfernt.
Vorteil:
Das Modell reagiert stärker auf jüngere Strukturen.
Nachteil:
Langfristige Informationen gehen verloren.
Welche Variante ist besser?
Es gibt keine universelle Antwort.
Die Wahl hängt davon ab, wie stabil der zugrunde liegende Prozess erscheint.
Wenn Finanzbeziehungen langfristig stabil sind, kann ein wachsendes Fenster sinnvoll sein.
Wenn schnelle Regimeänderungen erwartet werden, kann ein Rolling Window geeigneter sein.
Diese Entscheidung sollte jedoch möglichst vor der Ergebnisanalyse begründet werden.
TimeSeriesSplit
Softwarebibliotheken stellen spezielle Verfahren für zeitgeordnete Daten bereit.
Das Grundprinzip:
Frühere Beobachtungen werden zum Training genutzt.
Spätere Beobachtungen bilden den Test.
Das verhindert, dass ein Modell unmittelbar auf Zukunftsdaten trainiert und anschließend in der Vergangenheit bewertet wird.
Cross-Validation ist nicht gleich Backtesting
Beide Konzepte sind verwandt, aber nicht identisch.
Cross-Validation
bewertet primär die Generalisierungsfähigkeit eines statistischen Modells.
Backtesting
simuliert zusätzlich einen konkreten Handelsprozess.
Dazu gehören:
- Portfolio,
- Orders,
- Gebühren,
- Slippage,
- Positionsgrößen.
Ein guter Cross-Validation-Score bedeutet daher noch nicht automatisch einen profitablen Backtest.
Das Problem zeitlich naher Beobachtungen
Selbst wenn die Reihenfolge eingehalten wird, können Trainings- und Testdaten stark miteinander verbunden sein.
Beispiel:
Feature:
60-Tage-Volatilität
Beobachtungen an zwei aufeinanderfolgenden Tagen verwenden fast dieselben 60 historischen Werte.
Damit sind benachbarte Samples nicht unabhängig.
Überlappende Labels
Noch problematischer wird es, wenn Labels zukünftige Zeiträume umfassen.
Beispiel:
Label am 1. Juni:
Rendite vom 1. bis 10. Juni
Label am 2. Juni:
Rendite vom 2. bis 11. Juni
Beide Zielvariablen teilen neun Handelstage.
Werden solche Beobachtungen auf Training und Test verteilt, kann erhebliche Informationsüberlappung entstehen.
Purging
Purging entfernt Trainingsbeobachtungen, deren Informations- oder Labelintervalle den Testbereich überschneiden.
Ziel:
Trainingsdaten sollen möglichst keine Informationen enthalten, die direkt mit den Testlabels verbunden sind.
Beispiel:
Testzeitraum beginnt am 10. Juni.
Eine Trainingsbeobachtung vom 8. Juni besitzt ein Label bis zum 15. Juni.
Diese Beobachtung überlappt den Testbereich und sollte gegebenenfalls entfernt werden.
Embargo
Embargo fügt zusätzlich einen zeitlichen Sicherheitsabstand zwischen bestimmten Trainings- und Testbereichen ein.
Damit sollen verbleibende Abhängigkeiten reduziert werden.
Die Länge hängt von:
- Datenfrequenz,
- Label-Horizont,
- Feature-Lookbacks,
- Modellstruktur
ab.
Gap zwischen Training und Test
Auch allgemeine Time-Series-Split-Verfahren können einen Abstand zwischen Trainings- und Testbereich verwenden.
Schema:
Training
→ Gap
→ Test
Das kann sinnvoll sein, wenn Informationen nahe der Grenze besonders stark überlappen.
Warum Random Shuffle gefährlich sein kann
Angenommen, tägliche Aktienbeobachtungen werden zufällig gemischt.
Dann liegen beispielsweise:
Montag im Training
Dienstag im Test
Mittwoch wieder im Training
Bei hoch korrelierten Finanzdaten können dadurch sehr ähnliche Informationen auf beiden Seiten der Validierung landen.
Die Testperformance kann dadurch zu optimistisch erscheinen.
Cross-Sectional-Daten als Sonderfall
Nicht jedes Finanz-ML-Problem ist eine einzelne Zeitreihe.
Ein Aktienmodell kann beispielsweise jeden Monat tausende Aktien betrachten.
Dann existieren zwei Dimensionen:
Zeit
und
Assets
Auch hier sollte darauf geachtet werden, dass zukünftige Zeitperioden nicht in das Training früherer Perioden gelangen.
Innerhalb eines historischen Stichtags können jedoch viele verschiedene Aktien gleichzeitig als Querschnitt betrachtet werden.
Beispiel
Angenommen, jeden Monat werden 2.000 Aktien beobachtet.
Trainingsdaten:
2010–2018
Validation:
2019–2021
Test:
2022–2025
Innerhalb jedes Monats besitzt das Modell viele Aktienbeobachtungen.
Die zeitliche Trennung bleibt dennoch erhalten.
Hyperparameteroptimierung
Cross-Validation wird häufig verwendet, um Hyperparameter auszuwählen.
Beispielsweise:
- Baumtiefe,
- Regularisierung,
- Lernrate.
Wichtig:
Der endgültige Testdatensatz darf dabei nicht verwendet werden.
Ein sinnvoller Ablauf lautet:
Training
→ Modell fitten
Validation / CV
→ Hyperparameter auswählen
Test
→ genau einmal unabhängige Endbewertung
Nested Validation
Bei umfangreicher Modellwahl kann eine verschachtelte Validierungsstruktur sinnvoll sein.
Außen:
Bewertung der Generalisierung.
Innen:
Hyperparameteroptimierung.
Bei Finanzdaten muss auch diese Struktur zeitlich konsistent konstruiert werden.
Preprocessing innerhalb jedes Folds
Dies ist besonders wichtig.
Angenommen, die Daten werden standardisiert.
Falsch:
gesamten Datensatz standardisieren → Cross-Validation
Richtig:
für jeden Fold:
Training
→ Scaler fitten
→ Modell fitten
Test
→ mit Trainings-Scaler transformieren
→ Prognose
Nur so bleibt der Testfold wirklich unbekannt.
PCA innerhalb jedes Folds
Dasselbe gilt für Dimensionsreduktion.
Principal Component Analysis darf nicht auf allen Beobachtungen gleichzeitig berechnet werden, wenn anschließend Cross-Validation durchgeführt wird.
Die Komponenten würden sonst Informationen aus den Testdaten enthalten.
Feature Selection innerhalb jedes Folds
Auch die Auswahl der „besten“ Features muss ausschließlich aus Trainingsinformationen erfolgen.
Wer Features vorab anhand des vollständigen Datensatzes auswählt, hat den Test bereits beeinflusst.
Modellvergleich
Cross-Validation wird häufig genutzt, um verschiedene Modelle zu vergleichen.
Beispielsweise:
- lineare Regression,
- Random Forest,
- Gradient Boosting,
- neuronales Netz.
Der Gewinner sollte nicht nur anhand des höchsten Durchschnittsscores gewählt werden.
Zusätzlich relevant sind:
- Streuung zwischen Folds,
- Stabilität,
- wirtschaftliche Plausibilität,
- Komplexität,
- Handelskosten.
Wahl der Bewertungskennzahl
Die Kennzahl sollte zum Problem passen.
Regression
Mögliche Größen:
- Mean Squared Error,
- Mean Absolute Error,
- R²,
- Rangkorrelation.
Klassifikation
- Accuracy,
- Precision,
- Recall,
- ROC-AUC.
Im Finanzbereich können zusätzlich ökonomische Kennzahlen notwendig sein.
Statistik versus wirtschaftlicher Nutzen
Ein Modell kann einen statistisch besseren Forecast erzeugen, ohne eine bessere Handelsstrategie zu liefern.
Beispielsweise:
Modell A besitzt geringeren Prognosefehler.
Modell B identifiziert dagegen besser die extremsten positiven und negativen Chancen.
Für ein Ranking-Portfolio könnte Modell B wirtschaftlich wertvoller sein.
Walk-Forward als praktische Cross-Validation
Walk-Forward-Analysen sind eine besonders intuitive Form zeitlicher Validierung.
Der reale Prozess wird wiederholt:
Vergangenheit lernen → nächste Periode testen → weiterrücken
Dadurch kann überprüft werden, ob das gesamte Modellierungsverfahren über verschiedene Marktphasen funktioniert.
Regimeabhängigkeit sichtbar machen
Mehrere Testfolds ermöglichen eine wichtige Analyse.
Beispiel:
Fold 1: sehr gut
Fold 2: neutral
Fold 3: schlecht
Fold 4: sehr gut
Dann stellt sich die Frage:
Welche Marktbedingungen unterscheiden diese Perioden?
Cross-Validation dient damit nicht nur zur Berechnung eines Durchschnittsscores.
Sie kann helfen, Modellgrenzen zu verstehen.
Keine Validierung ist perfekt
Auch eine sorgfältige zeitliche Cross-Validation garantiert keine zukünftige Performance.
Gründe:
- Marktregime können neu sein,
- strukturelle Brüche können auftreten,
- historische Stichprobe bleibt begrenzt.
Cross-Validation reduziert Unsicherheit nicht auf null.
Sie versucht, Selbsttäuschung zu verringern.
Ein robuster Validierungsprozess
Ein möglicher Ablauf lautet:
1. finale Holdout-Periode reservieren
2. vergangene Daten für zeitliche CV verwenden
3. Preprocessing innerhalb der Folds fitten
4. Hyperparameter auswählen
5. Purging/Embargo prüfen
6. Modell einfrieren
7. finalen Holdout genau einmal auswerten
8. danach Backtest mit realistischen Kosten
9. Paper Trading
10. Live-Monitoring
Was ist mit dem finalen Testset?
Der finale Holdout ist besonders wertvoll.
Er sollte möglichst lange unangetastet bleiben.
Wenn nach jedem Testergebnis erneut das Modell verändert wird, ist das Testset faktisch Teil des Trainingsprozesses geworden.
Dann benötigt man erneut unbekannte Daten.
In historischen Finanzdaten sind diese jedoch begrenzt.
Die Zukunft ist der einzige echte Out-of-Sample-Test
Letztlich bleibt jeder historische Test künstlich.
Selbst wenn ein Zeitraum bei der Modellentwicklung nicht verwendet wurde, kennt der Researcher häufig die allgemeine Marktgeschichte.
Der tatsächlich stärkste Test ist deshalb der spätere Live- beziehungsweise Forward-Zeitraum.
Gerade deshalb sollte historisches Research möglichst streng aufgebaut sein.
Fazit
Cross-Validation bei Finanzzeitreihen verlangt mehr Sorgfalt als eine zufällige Aufteilung von Daten.
Die zeitliche Ordnung muss respektiert werden.
Zusätzlich können:
- überlappende Features,
- überlappende Labels,
- Preprocessing,
- Feature Selection
Informationslecks verursachen.
Ein belastbarer Prozess kombiniert deshalb:
zeitliche Splits + saubere Pipelines + gegebenenfalls Gap/Purging/Embargo + finalen Holdout
Die wichtigste Grundregel lautet:
Ein Modell darf bei seiner Entwicklung nichts über die Daten wissen, auf denen es später unabhängig bewertet werden soll.
Weiterführende Literatur
- López de Prado, M.: Advances in Financial Machine Learning.
- Hastie, T.; Tibshirani, R.; Friedman, J.: The Elements of Statistical Learning.
- James, G. et al.: An Introduction to Statistical Learning.
- scikit-learn Documentation:
TimeSeriesSplit. - scikit-learn Documentation: Common Pitfalls and Data Leakage.
Passendes Fachbuch
Machine Learning für Finanzdaten von Olaf Sund.
Weiterführende Beiträge
- Machine Learning für Finanzdaten
- Feature Engineering für Finanzdaten
- Purging und Embargo
- Data Leakage
- Walk-Forward-Analyse