← Alle Insights
MLOps · 10 Min · August 2032

MLOps für Trading-Strategien: Modell-Drift, Re-Training, Production-Pipelines.

Ein Empfehlungssystem darf eine Woche schlechte Predictions liefern, ohne dass die Welt untergeht. Ein Trading-Modell kann an einem schlechten Tag eine Quartals- Performance vernichten. MLOps für Trading ist nicht „MLOps wie sonst, plus Geldsumme". Es ist eine andere Disziplin — strenger, schneller, mit anderen Failure- Modi.

Warum Trading-Modelle anders altern.

Klassische Klassifikations- oder Recommendation-Modelle leiden unter Data-Drift: die Verteilung der Inputs verschiebt sich, die Verteilung der Targets aber bleibt stabil. Ein Mode-Empfehler altert, weil Geschmack langsam wandert; das Konzept „Kunde mag das" bleibt erhalten.

Trading-Modelle altern an Konzept-Drift: die Beziehung zwischen Features und Target ändert sich. Eine Vola-Regime-Strategie, die in einer Niedrigvola- Phase trainiert wurde, sieht in einer Hochvola-Phase die gleichen Inputs — aber das Mapping zu Returns ist ein anderes. Schlimmer: andere Marktteilnehmer beobachten den Markt mit, lernen ähnliche Muster und arbitrieren sie aus. Was 2030 als Signal funktioniert hat, ist 2032 vielleicht Rauschen plus Costs.

Konsequenzen:

Drift-Detection: PSI, KL und Statistik-Tests.

Drift lässt sich auf drei Ebenen messen:

Population Stability Index ist mein Standard für Feature-Drift, weil er robust, interpretierbar und schnell zu rechnen ist: 

def psi(expected, actual, bins=10):
    """Population Stability Index zwischen zwei Verteilungen."""
    breaks = np.quantile(expected, np.linspace(0, 1, bins + 1))
    breaks[0], breaks[-1] = -np.inf, np.inf
    e_pct = np.histogram(expected, bins=breaks)[0] / len(expected)
    a_pct = np.histogram(actual,   bins=breaks)[0] / len(actual)
    e_pct = np.clip(e_pct, 1e-6, None)
    a_pct = np.clip(a_pct, 1e-6, None)
    return float(np.sum((a_pct - e_pct) * np.log(a_pct / e_pct)))

# Faustregeln:
#   PSI < 0.10   stabil
#   0.10-0.25    Warnung
#   > 0.25       deutlicher Drift

In der Produktion läuft PSI nightly über jedes Feature, Ergebnis fließt in Grafana oder einen Slack-Alert. Schwelle nicht statisch — pro Feature kalibriert auf historische PSI-Schwankungen.

Champion-Challenger-Setup.

Ein einzelnes Modell in Produktion ist eine fragile Konfiguration. Besser: Champion (das aktuell live tradende Modell) plus mehrere Challenger (Kandidaten, die parallel rechnen aber nicht traden).

Setup:

Wichtig: Promotion-Regel vorher festlegen und nicht im Nachhinein anpassen. Sonst optimiert man die Promotion-Regel statt das Modell.

Shadow Trading vor Live-Deployment.

Bevor ein Modell echtes Geld bewegt, muss es in Produktions-Umgebung gegen Live- Markt-Daten laufen, ohne Orders zu schicken. Shadow Trading deckt drei Klassen von Bugs auf, die im Backtest nie auffallen:

Mein Minimum für Shadow Trading: 4 Wochen plus mindestens 100 Schatten-Trades. Ergebnisse werden gegen das Live-Modell verglichen. Wenn die Verteilung der Schatten-Predictions stark von der erwarteten abweicht, ist etwas falsch — und es muss beantwortet werden, was, bevor Live-Geld läuft.

Re-Training-Trigger.

Drei Trigger-Familien, die sich in der Praxis bewährt haben:

Realistisch nutzt man eine Kombination: feste Untergrenze zeitbasiert (z. B. quartalsweise), zusätzlich Drift-Trigger als Frühwarnung, Performance-Trigger als Notbremse mit Auto-Pause (siehe Rollback).

Rollback und Auto-Pause.

Was passiert, wenn das frisch deployte Modell in den ersten zwei Tagen ungewöhnlich schlecht läuft? Ohne Plan: Diskussion im Chat, Bauchgefühl, zu spätes Eingreifen. Mit Plan: harte Regeln, die vorher festgelegt wurden.

Monitoring: was wirklich überwacht werden muss.

Trading-MLOps-Monitoring hat vier Schichten, die alle live sein müssen:

  1. Infrastruktur: Feature-Pipeline-Latenz, Daten-Aktualität, Order-API-Health. Kein ML-Spezial, aber kritisch.
  2. Daten: Feature-Verteilungen, fehlende Werte, Schema-Drift, Out-of-Range-Werte. Tools: Great Expectations, evidently.ai.
  3. Modell: Prediction-Verteilung, Drift-Metriken, Modell-Latenz-p99. MLflow / Weights & Biases / Neptune.
  4. Trading-Outcome: P&L, Sharpe trailing, Slippage realisiert vs. erwartet, Order-Fill-Rate, Spread-Kosten. Eigene Dashboards aus Order-/Trade-Log.

Ein Alert auf Trading-Outcome ohne Alerts auf Daten und Modell ist gefährlich: wenn das P&L-Signal schlecht wird, ist es schon zu spät. Frühwarnung lebt auf Daten- und Modell-Layer.

Tools 2032.

Meine Praxis.

Eine Faustregel aus zehn Jahren systematischem Trading und MLOps-Beratung: Production-Trading-Models brauchen ungefähr dreimal so viel MLOps-Aufwand wie ein typisches SaaS-ML-Modell. Drei mal mehr Monitoring, drei mal mehr Drift- Detection, drei mal sorgfältiger Rollback, drei mal strenger Champion-Challenger. Wer das nicht aufbringt, bezahlt es mit Performance-Einbrüchen, die niemand früh genug erkennt.

Praktisch heißt das für Mandantenprojekte: das ML-Modell selbst macht 20 % der Arbeit. Pipelines, Monitoring, Re-Training-Logik, Shadow-Setup und Operations machen 80 %. Das ist nicht unangenehm — das ist die ehrliche Verteilung. Wer eine Strategie auf Wochen-Zeitskala Geld verdienen lassen will, baut die Infrastruktur, die diese Verteilung respektiert.

Was ich Mandanten konkret rate, bevor wir Live gehen:

Das ist die Untergrenze. Alles darüber — Streaming-Drift, automatische Hyperparameter- Retuning, Online-Learning — ist sinnvoll, aber kommt erst, wenn das Fundament steht.

Sie wollen Ihre Trading-ML-Pipeline auf Production-Niveau bringen? Erstgespräch buchen — wir bauen Drift-Monitoring, Champion-Challenger und Auto-Pause-Regeln so, dass sie zur Strategie passen.