RL in Production: TRPO, PPO, SAC für reales Trading.

Reinforcement-Learning-Papers zeigen beeindruckende Equity-Kurven. Im Live-Trading überlebt davon fast nichts. Der Unterschied zwischen Forschung und Produktion ist kein Hyperparameter-Tuning — er liegt in einer harten Liste von Anforderungen, die in den meisten Veröffentlichungen schlicht ignoriert werden.

Forschung vs. Produktion: der eigentliche Unterschied.

In einem Paper genügt es, dass der Agent auf einem Testfenster eine schöne Sharpe- Ratio zeigt. In Produktion muss der Agent: konsistent über Regime hinweg performen, keine fatalen Trades unter Stress machen, bei API-Ausfällen graceful degradieren, jeden Trade nachvollziehbar begründen können (Audit-Trail) und seine eigene Unsicherheit kalibrieren. Keiner dieser Punkte taucht in den Standard-Benchmarks auf.

Das wichtigste Mantra für RL in Produktion: ein produktiver Agent ist primär ein Risiko-Manager, sekundär ein Profit-Maximierer. Wer das umdreht, verbrennt Geld.

Die drei produktiven RL-Algorithmen.

PPO (Proximal Policy Optimization, 2017)

PPO ist der pragmatische Industrie-Standard. Schulman et al. (OpenAI) haben mit PPO einen Algorithmus gebaut, der robust gegenüber Hyperparametern, gut parallelisierbar und vergleichsweise einfach zu debuggen ist. Der Clip-Mechanismus verhindert zu große Policy-Updates pro Schritt — exakt das Problem, an dem viele frühere Policy-Gradient-Methoden gescheitert sind.

Für Trading: PPO eignet sich für diskrete Action-Spaces (kaufen/halten/verkaufen, kleine Positions-Gitter) und für moderat-dimensionale continuous-Spaces. Mein Default-Algorithmus bei jedem RL-Trading-Projekt.

SAC (Soft Actor-Critic, 2018)

SAC ist Off-Policy, sample-effizient, und der natürliche Kandidat für continuous action spaces — also Positions-Sizing in Echtzeit, Hedge-Ratio-Entscheidungen, Order-Size-Optimierung. Der „Soft"-Teil bezieht sich auf Maximum-Entropy: SAC wird explizit dafür bestraft, eine zu deterministische Policy zu lernen. Das hält die Exploration aufrecht und vermeidet, dass der Agent in lokale Optima kollabiert.

Für Execution-Optimierung und Position-Sizing ist SAC fast immer besser als PPO. Der Preis: SAC ist empfindlicher gegenüber Reward-Skalierung und braucht mehr Tuning-Zeit am Anfang.

TRPO (Trust Region Policy Optimization, 2015)

TRPO ist der historische Vorgänger von PPO. Theoretisch sauberer (echte KL-Constraint), praktisch deutlich komplizierter — natürliche Gradienten, Conjugate-Gradient-Lösungen, Line-Search. In Produktion benutze ich es nicht mehr. Wichtig nur, um die Linie PPO → SAC ideengeschichtlich zu verstehen.

Reward-Shaping: die wichtigste Design-Entscheidung.

Die Wahl der Belohnungsfunktion entscheidet über alles. Drei typische Varianten:

• Roher P&L: maximal verrauscht. Funktioniert in Papers, in Live-Trading kollabiert die Strategie regelmäßig in High-Risk-Verhalten.
• Sharpe-Ratio-Reward: P&L geteilt durch rollende Volatilität. Deutlich stabiler, aber schwierig korrekt zu differenzieren (Quotient).
• Differenzieller Sharpe (Moody & Saffell, 1998): rekursive Approximation, sauber als Reward verwendbar.
• P&L mit Drawdown-Penalty: meine bevorzugte Variante, weil sie das Verhalten produziert, das ich tatsächlich will.

Eine Mini-Implementation in PyTorch-nahem Pseudocode:

def reward(pnl_step, equity_curve, lambda_dd=2.0):
    peak = max(equity_curve)
    current = equity_curve[-1]
    drawdown = (peak - current) / peak if peak > 0 else 0.0
    return pnl_step - lambda_dd * drawdown ** 2

Der quadratische Drawdown-Term ist Absicht: kleine Drawdowns akzeptiert der Agent, tiefe Drawdowns werden überproportional bestraft. Das produziert sichtbar risikoärmere Policies.

Sim-to-Real: der Gap, an dem fast alles scheitert.

95 % der RL-Trading-Setups, die in Backtest beeindrucken, versagen Live. Die Gründe sind fast immer dieselben:

• Slippage falsch modelliert: der Simulator nimmt Mid-Price, die Realität nimmt Bid/Ask plus Impact.
• Latency ignoriert: der Agent reagiert in Simulation auf Bar-Close, im Live-System ist die Information beim Eintreffen der Order schon 200ms alt.
• Survivorship Bias: das Trainings-Universum enthält nur Aktien, die überlebt haben.
• Look-Ahead über Features: ein Feature wird zur falschen Zeit verfügbar gemacht.

Das standardmäßige Gegenmittel ist Domain-Randomization: der Simulator variiert Slippage, Latency, Liquidität in jedem Episode neu. Der Agent wird gezwungen, mit einer Verteilung umzugehen, statt mit einer Konstante. Robust-Lernen statt Overfit-Lernen.

Konkretes Setup: Stable-Baselines3 für PPO.

Stable-Baselines3 ist die ausgereifte Library für PPO/SAC. RLlib (Ray) ist mächtiger, aber komplizierter — sinnvoll erst, wenn Sie verteilt über mehrere Maschinen trainieren wollen. Minimal-Setup:

from stable_baselines3 import PPO
from stable_baselines3.common.vec_env import SubprocVecEnv

def make_env(seed):
    def _init():
        env = TradingEnv(data_path="./data", randomize_slippage=True)
        env.seed(seed)
        return env
    return _init

envs = SubprocVecEnv([make_env(i) for i in range(16)])

model = PPO(
    "MlpPolicy",
    envs,
    n_steps=2048,
    batch_size=256,
    learning_rate=3e-4,
    clip_range=0.2,
    ent_coef=0.01,
    gamma=0.995,
    verbose=1,
)
model.learn(total_timesteps=10_000_000)

Die 16 parallelen Environments sind essenziell — RL braucht Stichproben-Volumen, und ein einzelner Sequential-Simulator ist viel zu langsam.

Wo RL realistisch funktioniert.

Aus drei Jahren produktivem Einsatz die ehrliche Bilanz: RL liefert Mehrwert in genau zwei Bereichen, in einem dritten ist es debattierbar, im vierten klar unterlegen.

• Execution-Optimierung (klarer Win): saubere Reward-Signale, viele Episoden, kurze Zeitskalen. Hier sind Banken seit 2018 produktiv.
• Dynamische Allokation zwischen Strategie-Buckets (klarer Win): RL als Meta-Layer über fertigen Strategien.
• Risk-Overlay (debattierbar): RL entscheidet, wann der Risk-Knopf herunter gedreht wird. Funktioniert, aber simple Heuristiken oft genauso gut.
• End-to-End Direction-Forecasting (klar unterlegen): ich habe noch keine reproduzierbare öffentliche Implementation gesehen, die hier sauber funktioniert.

Meine Praxis.

Ich setze RL ausschließlich für Execution und Allokation ein. Nie für Direction-Forecasting. Die Verlockung, einen Agent direkt auf Marktrichtung losschnüren, ist groß — aber die Erfolgsrate ist in der Praxis so niedrig, dass es den Aufwand schlicht nicht lohnt.

Ein typisches Setup bei einem Mandanten: ein klassisches Faktor-Modell generiert Signale, ein SAC-Agent entscheidet pro Signal über Order-Größe, Order-Typ und Ausführungs-Schedule. Der Agent sieht Order-Book-Features, eigenen Drawdown-Status, Volatilitäts-Regime. Sharpe-Verbesserung gegenüber Naiv-Execution: 0.2–0.4. Das ist kein Wunder, aber sehr solide.

Wer Ihnen einen autonomen End-to-End-RL-Trader verkauft, verkauft Marketing. Wer Ihnen eine RL-Komponente in einem klar abgegrenzten Sub-Problem anbietet, könnte etwas Echtes haben — vorausgesetzt, er kann den Sim-to-Real-Gap konkret adressieren.

Sie überlegen, RL in einer konkreten Trading-Komponente einzusetzen? Erstgespräch buchen — wir prüfen, ob es der richtige Hebel ist.