Diskussion zum Artikel "Vereinheitlichte Validierungspipeline gegen Backtest-Overfitting"

Neuer Kommentar
 

Neuer Artikel Vereinheitlichte Validierungspipeline gegen Backtest-Overfitting :

Dieser Artikel erklärt, warum Standard-Walk-Forward und k-fache Cross-Validation Ergebnisse bei Finanzdaten systematisch zu positiv erscheinen lassen, und zeigt dann, wie dies behoben werden kann. V-in-V erzwingt strikte Datenpartitionen und verankertes Walk-Forward über Zeitfenster hinweg, CPCV bereinigt Datenlecks mittels Purging und Embargo und aggregiert die Performance auf Pfadebene, und CSCV misst die Wahrscheinlichkeit von Backtest-Overfitting. Anwender erhalten einen kohärenten Rahmen zur Bewertung der Robustheit über verschiedene Marktregime hinweg und der Verlässlichkeit der Strategieauswahl.

Jeder algorithmische Trader stößt irgendwann auf einen Backtest, der zu gut aussieht, um wahr zu sein. Die Equity-Kurve gleicht einer nahezu perfekten Treppe, die zur oberen rechten Ecke des Diagramms ansteigt. Die Sharpe-Ratio ist außergewöhnlich. Drawdowns sind flach und kurz.

Die Strategie scheitert dann sofort, sobald sie live eingesetzt wird.

Dieses Ergebnis ist so verbreitet, dass sich in der quantitativen Forschungsgemeinschaft dafür sogar ein eigener Ausdruck eingebürgert hat. Der Übeltäter ist fast immer eine Form von Overfitting: Der Algorithmus hat das historische Rauschen eines spezifischen Datensatzes gelernt, anstatt eine dauerhafte, in die Zukunft übertragbare Marktstruktur. Weniger bekannt ist, dass Overfitting kein einzelnes Phänomen ist. Es tritt über verschiedene Kanäle auf, von denen jeder eine andere Gegenmaßnahme erfordert. Ein Anwender, der nur eine Schutzmaßnahme einsetzt – die gebräuchlichste ist eine einfache Train/Test-Aufteilung –, bleibt gegenüber den anderen weiterhin anfällig.

Dieser Artikel untersucht drei der rigorosesten Werkzeuge, die zur Bekämpfung von Overfitting bei der Entwicklung algorithmischer Strategien verfügbar sind: Validation-within-Validation (V-in-V), wie von Timothy Masters formuliert; Combinatorially Purged Cross-Validation (CPCV), entwickelt von Marcos Lopez de Prado; und Combinatorially Symmetric Cross-Validation (CSCV), eingeführt von Bailey und Lopez de Prado. Jedes adressiert eine eigene Fehlerquelle. Zusammen bilden sie eine umfassende Verteidigung gegen die folgenreichsten Formen der statistischen Selbsttäuschung in der quantitativen Forschung.


Autor: Patrick Murimi Njoroge

 
Zwar ist die technische Tiefe dieses Artikels lobenswert – insbesondere der Fokus auf CPCV und Purging/Embargo –, doch gibt es eine erhebliche „Implementierungslücke“, in die die meisten Retail-Trader tappen werden. Das Kernproblem einer manuell implementierten „Unified Validation Pipeline“ besteht darin, dass sie eine neue Ebene des „Researcher Overfitting“ einführt . Wenn ein Trader für die Konfiguration der Datenpartitionen, der Bereinigungsfenster und der Sperrfristen verantwortlich ist, passt er diese Parameter oft (unbewusst) so lange an, bis die „validierten“ Ergebnisse günstig aussehen. Dies ist nichts anderes als Überanpassung auf einer höheren Abstraktionsebene. Darüber hinaus ist die direkte Implementierung dieser komplexen statistischen Methoden in MQL5 äußerst fehleranfällig. Ein einziger Fehler in der Bereinigungslogik oder eine geringfügige Überlappung der verankerten Walk-Forward-Fenster kann zu katastrophalen Datenlecks führen und ein falsches Gefühl der Sicherheit vermitteln. In der institutionellen Welt bewegen wir uns weg von „manuellen Pipelines“ hin zuautomatisierten Teststudios v . Das Ziel ist nicht nur, eine Pipeline zu haben, sondern eine standardisierte, praxiserprobte Umgebung, in der der menschliche Faktor vollständig aus dem Validierungsprozess entfernt wird. Ohne diese Automatisierung und Standardisierung ist selbst die „einheitlichste“ Pipeline nur ein weiteres Werkzeug für P-Hacking.
 

Oh, ich bin mit meinen Gedanken etwas spät dran, Warren Giddings hat bereits gute Argumente vorgebracht. ;-)

Insbesondere möchte ich erwähnen, dass eine sehr wichtige Metaoptimierung in dem Artikel außer Acht gelassen wurde – nämlich die Anpassung der In-Sample-Fenster- und Vorwärtsschrittgrößen. Denn Walkforward ist nicht auf „Rolling“ und „Anchored“ beschränkt, sondern es gibt auch die Cluster-Walkforward-Optimierung.

Daher sollten alle beschriebenen Methoden sozusagen in einer weiteren, senkrechten Dimension von IS/OOS-Größenkombinationen erneut angewendet und im Testzeitraum überprüft werden.

 
Tolle Arbeit! Vielen Dank!
 
Warren Giddings bewegen wir uns weg von „manuellen Pipelines“ hin zuautomatisierten Teststudios v . Das Ziel ist nicht nur, eine Pipeline zu haben, sondern eine standardisierte, praxiserprobte Umgebung, in der der menschliche Faktor vollständig aus dem Validierungsprozess entfernt wird. Ohne diese Automatisierung und Standardisierung ist selbst die „einheitlichste“ Pipeline nur ein weiteres Werkzeug für P-Hacking.
Hallo Warren,

vielen Dank für dein Feedback. Ich stimme allen von dir angesprochenen Punkten voll und ganz zu, und der Aufbau einer solchen automatisierten Pipeline ist der Kern meiner Serie

„MetaTrader 5 Machine Learning Blueprint“. Dieser Artikel sollte den Lesern, die sich noch nie viele Gedanken über die Art von Überanpassung gemacht haben, die ich in diesem Artikel thematisiert habe, die Augen öffnen. Aus diesem Grund habe ich ihn bewusst getrennt von den anderen Artikeln der ML-Blueprint-Reihe verfasst.

 
Stanislav Korotky #:

Ach, ich bin mit meinen Gedanken etwas spät dran – Warren Giddings hat bereits gute Argumente vorgebracht. ;-)

Insbesondere möchte ich darauf hinweisen, dass eine sehr wichtige Meta-Optimierung in dem Artikel außer Acht gelassen wurde – nämlich die Anpassung der In-Sample-Fenster- und Vorwärtsschrittgrößen. Denn Walkforward ist nicht nur durch „Rolling“ und „Anchored“ begrenzt, sondern es gibt auch die Cluster-Walkforward-Optimierung.

Daher sollten alle beschriebenen Methoden sozusagen in einer weiteren, senkrechten Dimension von IS/OOS-Kombinationen der Größen neu aufgerufen und im Testzeitraum überprüft werden.

Hallo Stanislav,

absolut richtig. Wie ich Warren bereits gesagt habe, soll dieser Artikel eine Einführung in die Konzepte sein, mit denen wir Überanpassung abmildern können. Diese werden in meiner Reihe „MetaTrader 5 Machine Learning Blueprint“ ausführlicher behandelt.
 
Vasiliy Sokolov #:
Tolle Arbeit! Vielen Dank!
Gern geschehen! Danke, dass du dir die Zeit genommen hast, es zu lesen.
Neuer Kommentar