Die Idee klingt verführerisch: Ein Quant-Researcher lädt ein SSRN-Paper hoch, eine LLM-Pipeline liest die Strategie aus, generiert vectorbt-Code, läuft den Backtest und liefert einen sauberen Report. Was früher zwei Wochen dauerte, ist in drei Stunden fertig.
Das funktioniert tatsächlich. Aber nur, wenn die Pipeline drei spezifische Fallen kennt, in die LLMs systematisch hineinlaufen. Werden diese Fallen nicht abgefangen, produziert die Pipeline Backtests mit Sharpe-Ratios jenseits von 3, die im Live-Trading binnen Wochen kollabieren. Das ist kein theoretisches Risiko, das ist die wahrscheinlichste Ausgangslage.
Dieser Artikel beschreibt eine reproduzierbare Pipeline vom Research-Paper bis zum validierten Backtest-Report und benennt konkret, wo LLMs scheitern und wie man sie absichert. Zielgruppe: Quant-Verantwortliche in Prop-Trading-Häusern, Asset-Managern und Hedge-Funds im DACH-Raum, die LLM-Tooling produktiv einsetzen wollen, ohne die Modell-Validierung an die Maschine zu delegieren.
Warum Prop-Desks LLM-Pipelines für Strategie-Research einsetzen
Der Engpass im Strategie-Research ist seit Jahren der gleiche. Ein Quant liest ein Paper, formalisiert die Strategie, schreibt Backtest-Code, debuggt Datenprobleme, läuft den Backtest und vergleicht mit den Paper-reported-Returns. Realistisch sind zwei bis vier Wochen pro Strategie, bei guter Datenlage.
Das Verhältnis von gelesenen zu getesteten Papern liegt in den meisten Häusern bei zwanzig zu eins oder schlechter. Das heißt: 95 Prozent der potenziell interessanten Ideen werden nie systematisch evaluiert. Nicht weil sie schlecht sind, sondern weil die Quant-Kapazität fehlt.
LLM-Pipelines verschieben dieses Verhältnis. Paper-to-Backtest in Stunden statt Wochen bedeutet konkret: Hunderte Strategien pro Quartal parallel evaluieren, statt einer Handvoll. Der Quant wird vom Code-Schreiber zum Strategie-Auditor. Das ist die richtige Rollenverschiebung, vorausgesetzt die Pipeline ist sauber gebaut.
Für DACH-Häuser kommt ein zweiter Punkt dazu. MiFID II und die einschlägigen Aufsichtspraktiken der BaFin und FMA verlangen Nachvollziehbarkeit. Ein LLM-Workflow, der jede Spezifikations-Entscheidung, jeden Code-Diff und jeden Backtest-Lauf versioniert, ist auditierbarer als ein Jupyter-Notebook, das ein Quant über drei Wochen handgestrickt hat. Das ist ein unterschätzter Compliance-Vorteil.
Die Pipeline im Detail
Die sinnvolle Architektur hat vier klar getrennte Stufen. Jede Stufe hat ein definiertes Output-Format und ein eigenes Review-Gate. Vermischt man die Stufen, verliert man die Kontrolle über das Modell-Verhalten.
Schritt 1: PDF-Ingestion und strukturierte Extraktion
Das LLM bekommt das Paper-PDF und einen strengen JSON-Schema-Output-Prompt. Extrahiert werden: Signal-Logik (Formel oder Pseudocode), Universe (welche Assets, mit point-in-time-Annahme), Rebalancing-Frequenz, Transaktionskosten-Annahmen, Position-Sizing-Regel, Hold-Out-Definition.
Kritisch: Das LLM darf in dieser Stufe keinen Code generieren. Nur Extraktion. Wer hier Code-Generierung mit reinmischt, bekommt halluzinierte Implementierungsdetails, die das Paper gar nicht enthält.
Schritt 2: Strategie-Spezifikation als YAML
Die extrahierten Felder werden in ein YAML-Format überführt, das als Ground-Truth zwischen Research und Engineering dient. Dieses Zwischenformat ist der wichtigste Hebel der gesamten Pipeline. Es ist menschenlesbar, diff-bar, versionierbar und auditierbar.
Ein Quant-Reviewer prüft die YAML-Spezifikation, bevor irgendein Code generiert wird. Das dauert zehn bis dreißig Minuten pro Strategie. Es ist der billigste Review-Gate der Pipeline und fängt 60 bis 70 Prozent aller späteren Probleme ab.
Schritt 3: Code-Generierung mit Template-Constraints
Das LLM erzeugt aus der YAML-Spezifikation vectorbt-, zipline- oder backtesting.py-Code. Aber nicht freihändig. Die Generierung läuft gegen ein striktes Template, das Bias-sichere Datenhandhabung erzwingt.
Konkret heißt das: Das Template stellt die Datenzugriffs-Funktionen bereit. Das LLM darf nur diese Funktionen aufrufen, keine eigenen Pandas-Indexer auf rohen DataFrames. Damit fällt eine ganze Klasse von Look-Ahead-Fehlern strukturell weg. Das Modell kann sie gar nicht erst schreiben.
Schritt 4: Automatisierter Backtest-Report
Der letzte Schritt läuft ohne LLM. Klassisches Reporting: Performance-Metriken, Drawdown-Analyse, Transaktionskostenmodell, Walk-Forward-Ergebnisse, Vergleich mit Paper-reported-Returns. Wenn die Pipeline saubere Sharpe-Werte von 1,2 produziert und das Paper 2,8 berichtet, ist das ein gutes Zeichen. Das Paper-Sharpe enthält fast immer Survivorship- oder Selection-Effekte.
Look-Ahead-Bias: Warum LLMs ihn systematisch einbauen
Look-Ahead-Bias bedeutet, dass Daten aus der Zukunft in die Signal-Berechnung der Vergangenheit fließen. Klassisches Beispiel: Eine Momentum-Strategie nutzt zur Signal-Berechnung am Tag T den Schlusskurs von T, statt von T-1. Im Backtest läuft das brillant, weil das Signal mit dem Trade auf demselben Bar quasi perfekt korreliert. Im Live-Trading existiert dieses Signal zum Trading-Zeitpunkt schlicht nicht.
LLMs reproduzieren diesen Fehler aus zwei strukturellen Gründen. Erstens enthält ihr Trainingscorpus massenhaft Backtest-Code aus Kaggle-Notebooks, GitHub-Repos und Tutorials, der genau diese Bias-Muster enthält. Das Modell hat gelernt, dass df['close'].rolling(20).mean() ein normales Signal ist. Dass dieses Signal am Bar T den Close von T enthält und damit nicht handelbar ist, ist nicht Teil des Lernsignals.
Zweitens optimiert das LLM auf plausible Lesbarkeit, nicht auf Korrektheit. signal = df['close'] > df['close'].rolling(20).mean() sieht sauber aus. Es ist falsch. Korrekt wäre signal = df['close'].shift(1) > df['close'].shift(1).rolling(20).mean(), ausgewertet auf dem Vortag, gehandelt am Open des aktuellen Bars. Das LLM wählt die ästhetisch glattere Variante.
Die Konsequenz ist drastisch. Ein freihändig LLM-generierter Backtest auf einer Momentum-Strategie produziert routinemäßig Sharpe-Ratios zwischen 2,5 und 4,5. Die gleiche Strategie, sauber implementiert, liegt bei 0,4 bis 0,9. Das ist keine Verbesserung um 20 Prozent, das ist eine andere Größenordnung.
Drei Halluzinations-Fallen, die im Backtest glänzen und live ruinieren
Falle 1: Zeitreihen-Indexfehler
Der häufigste Fehler. Das LLM verwendet den Close des aktuellen Bars für eine Signal-Berechnung, die am Open desselben Bars gehandelt werden soll. Oder es macht einen off-by-one-Fehler bei shift(). Oder es nutzt df.iloc[-1] in einer Schleife, die über historische Daten läuft, und greift damit immer auf das absolute Ende des DataFrames zu.
Gegenmaßnahme: AST-basierte statische Analyse vor jedem Backtest-Lauf. Verbotene Muster werden vor der Ausführung geblockt. Konkret: jeder Zugriff auf df['close'] ohne vorgeschaltetes shift() wirft einen Fehler, es sei denn er ist explizit als „post-execution-fill” markiert.
Falle 2: Survivorship-Bias durch falsches Universe-Handling
Das LLM bekommt die Aufgabe, eine Strategie auf den S&P 500 oder ATX zu testen. Es nimmt die heutige Index-Zusammensetzung, lädt für jedes dieser Tickers die Historie und backtestet darauf. Das Ergebnis: ein Universe, in dem keine einzige Pleite, keine Übernahme, keine Delisting-Aktie enthalten ist. Survivorship-Bias in Reinform, gut für 2 bis 4 Prozent jährliche Überperformance gegenüber der Realität.
Gegenmaßnahme: Der Daten-Layer akzeptiert nur point-in-time-Anfragen. Das LLM kann nicht „lade S&P-500-Konstituenten” aufrufen, sondern nur „lade S&P-500-Konstituenten zum Datum T”. Die zugrundeliegende Datenbank (Arctic, Databento, ein eigenes PostgreSQL-Schema mit Konstituenten-Historie) liefert dann die korrekte Mitgliedschaft inklusive der Aktien, die später aus dem Index geflogen sind.
Falle 3: Parameter-Overfitting durch LLM-Optimierung
Der subtilste Fehler. Das LLM schlägt nicht nur eine Implementation vor, sondern auch Parameter: Lookback-Periode 20, Schwellwert 1,5 Standardabweichungen, Stop-Loss bei minus 8 Prozent. Diese Parameter sind plausibel. Wenn man sie aber durchspielt und das LLM in einer Optimierungsschleife laufen lässt („probiere Lookback 10, 20, 30, welcher Sharpe ist am höchsten?”), produziert es Parametersätze, die auf dem konkreten Backtest-Sample optimiert sind.
Gegenmaßnahme: Walk-Forward-Pflicht im Backtest-Framework. Parameter werden auf dem Trainings-Fenster gewählt, der Sharpe-Wert wird ausschließlich auf dem Out-of-Sample-Fenster gemessen. Die YAML-Spezifikation enthält ein Pflichtfeld holdout_period, ohne das der Backtest-Runner den Lauf verweigert.
Bias-sichere Pipeline-Architektur
Die konkrete Architektur, die in der Praxis trägt, hat vier Leitplanken:
Daten-Layer als Single Source of Truth. Eine point-in-time-Datenbank ist die einzige zulässige Datenquelle für LLM-generierten Code. Kein direkter Dateizugriff, kein pd.read_csv aus dem Modell-Output. Die Datenzugriffs-API ist klein, dokumentiert und enforced bias-sichere Defaults.
AST-basierter Code-Review-Gate. Vor jedem Backtest-Lauf läuft der generierte Code durch einen statischen Analyzer, der verbotene Muster identifiziert. Das ist kein Linting, das ist ein Compliance-Check. Liste der Pattern-Verbote wird vom Quant-Team gepflegt und wächst mit jedem entdeckten Bias-Fall.
Spezifikations-Audit durch Menschen. Die YAML-Datei wird vor Code-Generierung von einem Quant freigegeben. Das ist der einzige Schritt, der nicht automatisierbar ist. Aufwand: 15 bis 30 Minuten pro Strategie. Ohne diesen Schritt verliert die Pipeline ihren Wert.
Walk-Forward und Out-of-Sample als Framework-Pflicht. Das Backtest-Framework akzeptiert keine Strategie ohne definiertes Hold-Out. Punkt. Wer es vergisst, bekommt einen Runtime-Error, keine Performance-Zahl.
Toolstack-Entscheidungen für DACH Prop-Desks
Beim Backtest-Engine ist die Wahl pragmatisch. vectorbt ist deutlich schneller als zipline, weil es vektorisiert arbeitet, und ist für die meisten LLM-Pipelines die richtige Wahl. zipline ist ausgereifter im Bereich Compliance-Logging und Event-Modellierung, eignet sich besser für mittlere und niedrige Frequenzen mit komplexer Execution-Logik. backtesting.py ist die einfachste Variante, gut für schnelle Sanity-Checks, nicht für produktive Pipelines.
Bei der LLM-Auswahl ist die Datenschutz-Frage entscheidend. Ein Prop-Desk, der eigene Strategie-Ideen in die OpenAI-API kippt, gibt unter Umständen geistiges Eigentum preis. Claude über AWS Bedrock mit europäischer Region, Azure OpenAI mit Data-Residency-Garantien oder ein lokal gehostetes Modell (Llama 3.3 70B, Mistral Large) sind die realistischen Optionen. GPT-4o und Claude 3.5 Sonnet liefern für Code-Generierung in der gleichen Liga, der Unterschied liegt im Datenraum, nicht in der Code-Qualität.
Orchestrierung: Für die meisten Pipelines reichen einfache Prompt-Chains. LangChain und LlamaIndex bringen Komplexität, die sich erst lohnt, wenn die Pipeline mehrere Modelle, Vector-Stores und Tool-Use-Patterns kombiniert. Bis dahin ist ein Python-Script mit klaren Funktionen wartbarer.
Logging und Reproducibility: MLflow für Backtest-Artefakte, DVC für Datensatz-Versionierung. Jeder Backtest-Run bekommt einen unveränderlichen Hash, der Daten, Code, Spezifikation und LLM-Prompt versioniert. Das ist die Basis für jeden späteren Audit.
Praxisbeispiel: Momentum-Strategie aus einem SSRN-Paper
Nehmen wir ein typisches Cross-Sectional-Momentum-Paper: Universe ist der S&P 500, Lookback 12 Monate minus letzter Monat, monatliches Rebalancing, Long-Short der Top- und Bottom-Decile. Paper-reported-Sharpe: 1,4.
Das LLM extrahiert in der YAML-Stufe sauber: universe: SP500, lookback: 252 days, skip_recent: 21 days, rebalance: monthly, position: decile_long_short. Soweit gut.
In der Code-Generierung passieren ohne Template-Constraints drei klassische Fehler. Erstens lädt das Modell die heutige S&P-500-Liste statt point-in-time. Zweitens berechnet es Momentum auf df['close'].pct_change(252), ausgewertet auf dem Rebalancing-Tag, ohne shift(21) für die letzte Monatslücke. Drittens ignoriert es Transaktionskosten komplett, weil das Paper sie nur am Rande erwähnt.
Der naive Backtest liefert Sharpe 2,9. Schön. Falsch.
Die bias-korrigierte Pipeline mit point-in-time-Universe, korrektem Lookback-Skip und realistischen Transaktionskosten (10 bps pro Trade) liefert Sharpe 0,8. Das ist unter dem Paper-Wert, was zu erwarten ist: Paper unterschätzen typischerweise Kosten und Slippage, und das Live-Universe enthält Aktien, die das Paper-Universe nicht hat.
0,8 ist ein realistischer Wert für eine bekannte Anomalie. Daraus lässt sich eine Allokationsentscheidung treffen. Aus 2,9 lässt sich nur eine Selbsttäuschung treffen.
Was die Pipeline leistet und wo der Mensch unersetzlich bleibt
Die LLM-Pipeline ist ein Produktivitätshebel, kein Strategie-Validator. Sie skaliert die Code-Produktion. Sie ersetzt nicht das Urteil darüber, ob eine Strategie ökonomisch sinnvoll ist.
Drei Aufgaben bleiben nicht delegierbar. Erstens das Universe-Design. Welche Assets gehören in eine Strategie, welche Liquiditätsgrenze, welcher Kosten-Floor? Das ist eine Markt-Entscheidung, keine Code-Entscheidung. Zweitens die Transaktionskosten-Modellierung. Realistische Slippage hängt von Order-Größe, Markt-Tiefe und Tageszeit ab. Ein LLM kann das nicht ohne Order-Buch-Daten, und Order-Buch-Daten gehören nicht in einen LLM-Prompt. Drittens die Regime-Validität. Eine Strategie, die zwischen 2010 und 2020 funktioniert hat, ist keine Aussage über 2025. Der Quant entscheidet, ob das Regime stabil ist.
Meine Empfehlung für den Aufbau in Prop-Häusern: Beginnen Sie nicht mit der vollen Pipeline. Bauen Sie zuerst den Daten-Layer mit point-in-time-Garantien. Das ist der teuerste und langweiligste Schritt, aber er ist die Basis. Ohne sauberen Daten-Layer liefert auch das beste LLM Müll.
Dann bauen Sie die YAML-Spezifikation und das menschliche Review-Gate. Das ist der zweitwichtigste Schritt, und er ist billig. Ein Quant kann das in zwei Wochen prototypen.
Die Code-Generierung selbst ist der letzte und am wenigsten kritische Schritt. Wenn Daten-Layer und Spezifikation sitzen, ist die LLM-Code-Generierung ein Kommodität-Problem. Wenn sie nicht sitzen, ist die LLM-Code-Generierung ein Risiko-Verstärker.
Die Häuser, die diese Reihenfolge umdrehen und mit der LLM-Generierung anfangen, weil sie am sichtbarsten ist, sind die Häuser, die in 18 Monaten einen Drawdown erklären müssen, den niemand kommen sah. Das ist der eigentliche Punkt.