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. 
Полный исторический массив данных
│
├── ВНЕШНЯЯ ОБУЧАЮЩАЯ ВЫБОРКА (~60%)         ← Здесь проводится полный исследовательский поиск
│
├── ВНУТРЕННЯЯ ВАЛИДАЦИОННАЯ ВЫБОРКА (~20%)  ← Здесь проводится предварительный отбор кандидатов
│                                              (число рассматриваемых кандидатов намеренно ограниченно)
│
└── ФИНАЛЬНАЯ ТЕСТОВАЯ ВЫБОРКА (~20%)        ← Открывается только один раз – после полной фиксации решения

Das ist Schrödingers Katze, bei der die Wahrscheinlichkeit 50:50 beträgt, dass es sich um eine funktionierende Handelsstrategie handelt. Solange sich die Katze in einer Superposition befindet (die abschließende Teststichprobe wurde noch nicht durchgeführt), ist die Handelsstrategie gleichzeitig funktionierend und nicht funktionierend.

Sobald der Test jedoch durchgeführt wurde, handelt es sich um eine Anpassung.


Ja, das lässt sich nur schwer mit der klassischen Logik vereinbaren. Denn wenn die Handelsstrategie funktioniert, wie kann ihr abschließender Test sie dann automatisch unbrauchbar machen?! Ich habe kein gutes Argument für diese logische Frage.

Aber die Durchführung des abschließenden Tests scheint doch fast wie ein Todesurteil für den Handelsroboter zu sein.


Dann ergibt sich logischerweise eine weitere Frage: Wäre nicht der Real-Test selbst der Abschlusstest? – Nein, das wäre er nicht. Denn bei diesem Test gibt es keine Wahlmöglichkeit, ob man ihn im vergangenen Intervall des Real-Tests ausführen soll oder nicht.


Insgesamt ist das alles sehr chaotisch und grundlegend.

fxsaber #:

Insgesamt sehr chaotisch und tiefgründig.

Ich habe gerade erst angefangen, den Artikel zu lesen. Aber wo steht etwas über den Robustheitshorizont des Handelssystems?
Wenn man von einem profitablen Handelssystem spricht, muss man sich ein Ziel setzen: Wie hoch soll der Gewinn sein und bis zu welchem Zeitpunkt.
Für welches Ziel sind die vorgeschlagenen Methoden gedacht? Oder geht es hier um den „Heiligen Gral“ des Handels?
MetaQuotes:

Es wurde ein Artikel mit dem Titel „Einheitliche Validierungspipeline zum Schutz vor Backtest-Übertraining“ veröffentlicht:

Autor: Patrick Murimi Njoroge

Ein guter Artikel, so etwas ist hier eine Seltenheit.

Neuer Kommentar