ML im Trading: Warum es keine Preise vorhersagt

Maschinelles Lernen im algorithmischen Handel: Praktische Anwendungen und häufige Fehler

Maschinelles Lernen (ML) im Handel sagt keine Kursentwicklungen direkt vorher, sondern überzeugt bei spezifischen, eng begrenzten Aufgaben: Erkennung von Marktphasen, Filterung von Handelssignalen, Optimierung der Orderausführung und Analyse der Mikrostruktur des Orderbuchs. In Russland übernimmt der Einzelhändler den gesamten Prozess – von der Datenaufbereitung bis zur Produktiveinsatz, anders als bei Hedgefonds, wo Rollen aufgeteilt sind. Die meisten ML-basierten Strategien scheitern aufgrund schlechter Datenqualität und fehlerhafter Tests.

Die Rolle des Solo-Algo-Traders

Der heutige Einzelhändler agiert wie ein komplettes Spezialistenteam. Er verantwortet:

• Datenbeschaffung und -bereinigung;
• Feature-Engineering;
• Modellentwicklung;
• Hypothesentestung;
• Strategiekombination;
• Risikoberechnung;
• Produktiveinsatz.

Dafür benötigt er eine GPU-gekoppelte Heimhardware und moderne AI-Tools. Im Gegensatz zu Fonds mit spezialisierten Rollen trägt eine Person die gesamte Verantwortung. Eine Umfrage auf einer Meetup-Veranstaltung ergab: 70 % haben ML ausprobiert, aber nur 30 % betreiben profitabel laufende Strategien mit echtem Geld. Das Kernproblem? Mangel an wertvollen Inhalten – Diskussionen sind voller vager Andeutungen, und jeder baut das Rad neu, wiederholt dieselben Fehler.

Warum direkte Kursvorhersage nicht funktioniert

Der Mythos, dass Neuronale Netze den Kurs von Sberbank morgen vorhersagen können, bricht unter realen Bedingungen zusammen. Regression auf historische Preise liefert nur Rauschen. Bei Hochfrequenzhandel (HFT) ist ML begrenzt – Modelle bringen Verzögerungen, die bei Nanosekundengenauigkeit entscheidend sind.

Die Signalgenerierung mittels ML schlägt oft fehl. Stattdessen zeigt ML seine Stärke in:

• Erkennung von Marktphasen: Abschalten von Trendfolgestrategien in Seitwärtsmärkten;
• Signalfilterung: Ausschluss verlustreicher Trades aus Basisstrategien;
• Ausführungsoptimierung: Minimierung von Slippage und Gebühren;
• Analyse der Mikrostruktur des Orderbuchs: Erkennen von Mustern im Orderfluss, die für das Auge unsichtbar sind.

Diese Anwendungen generieren Alpha, ohne die Illusion einer Vorhersage zu erzeugen.

Typische Fehler beim Testen

Die meisten Strategien versagen während der Backtestphase. Wichtige Fallen:

• Schlechte Eingabe = Schlechte Ausgabe: 80 % der Zeit wird für Datenfindung und -bereinigung aufgewendet. Ein fehlender Kerzenabschnitt oder schlecht zusammengesetzte Futures erzeugen falsche Muster;
• Blick in die Zukunft: Falsche Train-Test-Splitting lässt Modelle zukünftige Daten sehen (siehe Marcus de Prado). Der Backtest sieht perfekt aus; live führt das zu Margin-Calls;
• Prognose ≠ Gewinn: Das Modell trifft die Richtung zu 60 % richtig, doch Slippage, Gebühren und Latenz fressen alle Gewinne auf.

Der Unterschied zu westlichen Fonds liegt nicht in den Ideen – sondern in der Infrastruktur. Nichtstationarität und Überanpassung sind universelle Herausforderungen.

Ideen validieren, bevor man codiert

Bevor man Python-Code schreibt, sollte man sich fünf Fragen stellen:

• Ist die Aufgabe klar definiert? (Nicht: "ein neuronales Netz hinzufügen", sondern: "Ausführungskosten senken");
• Haben Sie ehrliche Daten? (Sauber, keine Zukunftsinformationen, zeitnah zugänglich);
• Können Sie es inklusive Gebühren und Latenz testen?
• Übersetzt sich die Prognose in eine Aktion? (Klarer Weg vom Modell zum Trade);
• Gibt es einen wirtschaftlichen Nutzen? (Gewinn nach allen Kosten).

Eine negative Antwort auf eine dieser Fragen bedeutet: Es ist noch zu früh, ML einzusetzen.

Das Entscheidende

• ML im Handel löst präzise Probleme – nicht Kursvorhersagen;
• 80 % des Erfolgs liegen in den Daten – Bereinigung und Validierung sind entscheidend;
• Vermeiden Sie Zukunftsinformationen im Backtest;
• Berücksichtigen Sie PnL mit Slippage und Gebühren;
• Validieren Sie Ideen mit dem Fünf-Fragen-Checkliste, bevor Sie programmieren.

ML ist kein Zauberbutton – es ist ein Werkzeug für präzise Anforderungen. Geschlossene Communities führen zu wiederholten Fehlern; der Austausch von Erkenntnissen beschleunigt die Entwicklung.

— Editorial Team