Diskussion zum Artikel "MetaTrader 5 – Leitfaden für maschinelles Lernen (Teil 8): Bayes’sche Hyperparameter-Optimierung mit Purged Cross-Validation und Trial Pruning"

 

Neuer Artikel MetaTrader 5 – Leitfaden für maschinelles Lernen (Teil 8): Bayes’sche Hyperparameter-Optimierung mit Purged Cross-Validation und Trial Pruning :

GridSearchCV und RandomizedSearchCV teilen eine grundlegende Einschränkung im finanziellen ML: Jeder Versuch ist unabhängig, sodass sich die Suchqualität durch zusätzliche Rechenleistung nicht verbessert. Dieser Artikel integriert Optuna – unter Verwendung des Tree-structured Parzen Estimator – mit PurgedKFold-Kreuzvalidierung, HyperbandPruner-Frühstopp und einer Dual-Weight-Konvention, die Trainingsgewichte von Bewertungsgewichten trennt. Das Ergebnis ist ein System aus fünf Komponenten: eine Zielfunktion mit Fold-Level-Pruning, eine Vorschlagsebene, die das Gewichtungsschema gemeinsam mit den Modell-Hyperparametern optimiert, ein finanziell kalibrierter Pruner, ein fortsetzbarer, SQLite-basierter Orchestrator und ein Konverter für das scikit-learn cv_results_-Format. Der Artikel zieht zudem die Grenze – basierend auf Timothy Masters – zwischen statistischen Zielen, bei denen eine gezielte Suche vorteilhaft ist, und finanziellen Zielen, bei denen sie schädlich ist.

Sie erstellen einen finanziellen ML-Klassifikator auf Basis von Triple-Barrier- oder Meta-Labels und müssen Hyperparameter fair auswählen – ohne die Suche selbst in eine Overfitting-Maschine zu verwandeln. Standard-Tools versagen bei diesem Anwendungsfall in drei konkreten Punkten. GridSearchCV und RandomizedSearchCV lernen nicht aus vergangenen Versuchen (Trials), sodass sie Budget verschwenden, indem sie Bereiche des Hyperparameter-Raums erneut prüfen, die sich bereits als schlecht erwiesen haben. Sie können eine wenig vielversprechende Konfiguration nicht nach dem ersten aufwendigen Fold PurgedKFold stoppen, sodass jeder Versuch den vollen Aufwand aller Folds trägt, selbst wenn der erste Fold bereits ein Scheitern signalisiert. Und sie lassen sich nicht natürlich in den Datenkontrakt für Finanzdaten integrieren – PurgedKFold als einziger gültiger Splitter, separate Gewichtungen für Anpassung und Bewertung sowie persistente Speicherung, damit eine lange Suche Abstürze übersteht und parallele Worker unterstützt. Die messbaren Symptome sind verschwendete Rechenleistung, verzerrte Out-of-Sample-Vergleiche aufgrund von Informationslecks über die Purge-Grenze hinweg und fragile Experimente, die nach jeder Unterbrechung von Grund auf neu gestartet werden müssen.

Dieser Artikel zeigt einen praktischen Ersatz: Optuna (TPE-Sampler + Pruning + SQLite-Speicherung), nativ verbunden mit den Finanz-Cross-Validation- und Gewichtungskonventionen, die in früheren Teilen dieser Serie etabliert wurden. Nach der Lektüre verfügen Sie über eine konkrete, ausführbare HPO-Struktur, die aus fünf Komponenten besteht. (1) eine Zielfunktion, die eine PurgedKFold-Kreuzvalidierung mit renditeattributionsgewichteter Bewertung durchführt und Ergebnisse auf Fold-Ebene für das Pruning meldet, (2) FinancialModelSuggester, eine Parameter-Übersetzungsschicht, die scikit-learn-Verteilungsspezifikationen in trial.suggest_*()-Aufrufe umwandelt und gleichzeitig das Stichprobengewichtungsschema sowie den Zerfall optimiert, (3) ein finanzspezifisch kalibrierter Pruner (TradingModelPruner), der eine auf Entropie basierende ökonomische Basislinie und eine regime-skalierte Volatilitätstoleranz erzwingt, (4) ein Orchestrator (optimize_trading_model) mit SQLite-Speicher für die Wiederaufnahme und parallele Worker, und (5) ein Konverter von Study zu cv_results_ für die Kompatibilität mit bestehenden scikit-learn-Analysen. Die Ausgabe-Artefakte sind eine persistierte Study, ein neu angepasster best_estimator_ (_WeightedEstimator, der ein abgestimmtes Basismodell umschließt) und ein cv_results_ DataFrame mit Ergebnissen pro Fold – bereit für dieselben nachgelagerten Diagnosen, die im Rest der Pipeline verwendet werden.


Autor: Patrick Murimi Njoroge