Für wen dieser Artikel gedacht ist — Für alle, die systematische Strategien entwickeln oder beurteilen und eine Messung mit wirklich ungesehenen Daten von einer bloßen Fortsetzung der Optimierung unterscheiden müssen.
Ein Out-of-Sample-Test (OOS) bewertet eine bereits festgelegte Spezifikation mit Daten, die nicht zur Wahl ihrer Regeln, Variablen, Parameter oder Auswahlkriterien beigetragen haben. Er soll zeigen, ob ein Modell über die Entwicklungsstichprobe hinaus generalisiert. Er beweist nicht, dass das Verhalten künftig fortbesteht; bei echter Trennung vermindert er eine bestimmte Form des Optimismus.
Die Reinheit eines OOS betrifft den Entscheidungsfluss, nicht nur eine Datumsspalte. Führt sein Ergebnis zu einer Modelländerung, ist dieser Abschnitt nun Entwicklungsinformation. Die geänderte Version benötigt einen neuen, noch nicht betrachteten Test. Es ist falsch, dieselben Daten nach einer Anpassung weiterhin „out of sample“ zu nennen.
Einfach gesagt — Ein verschlossener Prüfungsbogen ist nur so lange ungesehen, bis er erstmals geöffnet wird. Jede danach vorgenommene Verbesserung hat aus seinen Antworten gelernt.
In-Sample, Validierung, Test und Forward sind keine Synonyme
| Block | Erlaubte Verwendung | Was ihn verunreinigt |
|---|---|---|
| Training / In-Sample | Schätzung und Anpassung von Parametern | Ist nicht für eine unparteiische Endbewertung vorgesehen |
| Validierung | Auswahl zwischen Spezifikationen und Hyperparametern | Wiederholte Abfragen sind zulässig, müssen aber gezählt werden |
| Finaler OOS-Test | Abschließende Bewertung einer eingefrorenen Spezifikation | Jede vom Ergebnis ausgelöste Änderung |
| Walk-forward | Zeitlich geordnete Folge von Fit und Test | Regeln werden nach Sichtung der gesamten Folge neu entworfen |
| Forward- oder Paper-Test | Beobachtung in späterer Kalenderzeit, oft ohne echtes Geld | Unterschiede zwischen simulierten Fills, Betrieb und Live-Kapital |
OOS kann ein finaler Holdout, ein Fenster einer rollierenden Prozedur oder ein Teil zeitlicher Cross-Validation sein. Der Name allein beschreibt das Design nicht. Dokumentiert werden müssen Fenstergrößen, Reihenfolge, Labelhorizont, Refit-Frequenz und die Gesamtzahl der auf den Ergebnissen beruhenden Entscheidungen.
Es gibt keine universelle Split-Proportion
Eine Regel wie „70 % Entwicklung, 30 % Test“ gilt nicht allgemein. Die Aufteilung hängt von Menge und Qualität der Daten, Frequenz, Prognosehorizont, Prozessstabilität, Parameterzahl und der Notwendigkeit verschiedener Regime ab. Ein sehr langer Test verkleinert die Entwicklungsbasis; ein zu kurzer liefert unpräzise Schätzungen oder repräsentiert nur ein Regime.
Bei Zeitreihen zählt die Reihenfolge. Ein zufälliger Standard-Split kann stark verbundene Beobachtungen auf Training und Test verteilen. Er ist aber nicht unter allen Annahmen automatisch ungültig. In der Finanzanalyse erfordern Autokorrelation, Fenster-Features und überlappende Labels häufig blockierte oder rollierende Splits und gezielte Trenntechniken.
Purging und Embargo
Verwendet ein Label ein zukünftiges Intervall — etwa die Rendite zwischen Öffnung und Schließung einer Position —, kann eine Trainingsbeobachtung denselben Informationszeitraum wie eine Testbeobachtung teilen. Purging entfernt Trainingsbeobachtungen, deren Labelintervalle den Test überlappen. Ein Embargo ergänzt einen zeitlichen Puffer, um Abhängigkeiten an der Grenze zu vermindern.
Der Puffer muss aus Horizont, Datenverfügbarkeit und Abhängigkeitsstruktur begründet werden; ein fixer Prozentsatz ist kein allgemeines Prinzip. Purging und Embargo korrigieren weder Survivorship Bias noch revidierte Daten, unrealistische Kosten, multiple Tests oder Regimewechsel.
Validierungsprotokoll
- Informationseinheit definieren. Zeitstempel der Features, Beginn und Ende des Labels, Frequenz und mögliche Überlappungen festhalten.
- Rollen trennen. Daten vor Betrachtung der Endkennzahlen Training, Validierung und Test zuweisen; einen für Tuning genutzten Block nicht „Test“ nennen.
- Design wählen. Holdout, Rolling Origin, wachsendes oder rollendes Fenster, blockierte Cross-Validation und mögliche Purge-/Embargo-Regeln begründen.
- Pipeline einfrieren. Transformationen, Features, Universum, Hyperparameter, Kosten, Benchmark und Entscheidungsregel versionieren.
- Alle Versuche registrieren. Modelle, Seeds, Perioden, Filter und betrachtete Kennzahlen zählen, nicht nur die veröffentlichte Variante.
- Finalen Test ausführen. Nettokennzahlen, Unsicherheit und Benchmarkvergleich berechnen, ohne die Auswahl wieder zu öffnen.
- Ergebnis klassifizieren. „Nicht schlüssig“, „nicht mit der Hypothese vereinbar“ und „mit weiterer Prüfung vereinbar“ sind oft angemessener als ein universelles Pass/Fail.
- Jede Wiederverwendung dokumentieren. Sobald ein Ergebnis eine Änderung lenkt, den Zeitraum formal dem Entwicklungswissen zuordnen.
Walk-forward und finaler Test
Beim Walk-forward wird das Modell vor jedem Testfenster nur mit älteren Daten geschätzt. Das Verfahren imitiert wiederholte Refits und zeigt zeitliche Schwankungen. Es muss offenlegen, ob das Trainingsfenster wächst oder rollt, wie groß Schritt und Testhorizont sind und wie oft neu kalibriert wird.
Die Verkettung der Fenster ist nicht automatisch ein reiner Track Record. Werden nach Sichtung der gesamten Folge Modellfamilie, Features, Fenster oder Stoppregeln geändert, hat die Folge an der Entwicklung mitgewirkt. Wenn möglich, kann neben der internen Auswahl ein äußerer finaler Holdout versiegelt bleiben.
Illustratives Beispiel — Ein monatliches Modell wird in einem rollierenden Fenster neu geschätzt und im Folgemonat geprüft. Positionslabels reichen über mehrere Tage; vor jedem Test werden Trainingslabels mit überlappendem Intervall entfernt. Vier Modellfamilien werden in der internen Validierung verglichen und alle protokolliert. Ein späterer Zeitblock bleibt für die Endentscheidung verschlossen. Die Zeitspannen erklären das Verfahren und sind keine empfohlenen Proportionen.
Das Ergebnis sollte die Streuung zwischen Fenstern, Kosten und Exposures zeigen, nicht nur eine aggregierte Kennzahl. Ein günstiger Mittelwert kann verbergen, dass fast der gesamte Wert aus einem einzigen Zeitraum stammt.
Grenzen
- Ein einzelner Holdout kann stark vom enthaltenen Regime abhängen.
- Mehrere Datenreserven schaffen keine neue unabhängige Information.
- Nichtstationarität kann Training und Test gleichermaßen unrepräsentativ machen.
- Die Wahl des Validierungsdesigns ist selbst eine Forschungsentscheidung und gehört ins Versuchregister.
- OOS, Purging und Walk-forward ersetzen keine Point-in-time-Daten, kausale Simulation, plausiblen Kosten und Kontrolle des Data Snooping.
Quellen
- Leonard J. Tashman, Out-of-sample tests of forecasting accuracy: an analysis and review, International Journal of Forecasting, 2000 — Rolling Origin, Rekalibrierung und mehrere Testperioden.
- Christoph Bergmeir und José M. Benítez, On the use of cross-validation for time series predictor evaluation, Information Sciences, 2012 — Cross-Validation-Designs für Zeitreihenprädiktoren.
- Christoph Bergmeir, Rob J. Hyndman und Bonsoo Koo, A note on the validity of cross-validation for evaluating autoregressive time series prediction, 2018 — Bedingungen für gültige Cross-Validation bei autoregressiven Zeitreihen.
- David H. Bailey et al., The Probability of Backtest Overfitting — Auswahl unter Konfigurationen und Grenzen eines einfachen Holdouts bei Investment-Backtests.
- Marcos López de Prado, Advances in Financial Machine Learning — offizielles Wiley-Inhaltsverzeichnis, Wiley, 2018 — Monografie zu Purged K-fold und Embargo; hier nicht als peer-reviewter Fachartikel zitiert.