Ein Strategieagent kann einen Testsatz verfälschen, ohne auch nur eine einzige Testzeile in einen Trainingslauf einzubeziehen. Wenn der Agent den Testscore sieht, einen Parameter ändert und erneut ausführt, hat dieser Score die Strategie bereits beeinflusst. Im Code mag der Zeitraum „out of sample“ heißen. Durch den Research-Prozess ist er Teil der Suche geworden.
Ich habe das schon aus reiner Bequemlichkeit erlebt: Ein Agent führt einen Batch aus, liest eine Übersichtstabelle und schlägt dann eine kleine Verbesserung vor. Niemand hat ihn aufgefordert, auf dem Holdout zu fitten. Die Feedbackschleife hat das trotzdem bewirkt.
Fehler 1: Den Agenten nach jedem Lauf spicken lassen
Das Debakel zeigt sich meist an einem Test-Sharpe, der in ordentlichen kleinen Schritten steigt. Der Agent probiert 30 Varianten aus, behält die beste und testet dann 30 Varianten in ihrer Nähe. Jede einzelne Änderung wirkt plausibel. Zusammen machen sie den Testzeitraum zum Optimierungsziel.
Hier ein vereinfachtes Beispiel. Angenommen, die Strategie hat keinen echten Edge und du testest 100 unabhängige Varianten auf einem Holdout. Wenn du den höchsten Sharpe auswählst, kannst du durch Zufall durchaus ein schmeichelhaftes Ergebnis finden. Bei den meisten Strategiesuchen sind die Varianten nicht wirklich unabhängig, aber das rettet den Prozess nicht: Wiederholtes Feedback belohnt weiterhin Einstellungen, die zufällig zu den Eigenheiten des Holdouts passen.
Schirme den Holdout durch eine Ergebnisgrenze ab. Der Agent kann anhand von Trainings- und Validierungszeiträumen entwickeln, aber keine Holdout-Kennzahlen oder Charts abrufen. Führe die abschließende Evaluation in einem separaten Job einmalig aus, nachdem die Research-Entscheidungen feststehen, und speichere zusammen mit dem Ergebnis die Strategieversion und den Daten-Snapshot.
Fehler 2: Jeden späteren Zeitraum als „frisch“ bezeichnen
Ein Datumsbereich ist nicht allein deshalb frisch, weil er auf das Trainingsfenster folgt. Wenn der Agent einen Score aus diesem Bereich gesehen hat oder ein Mensch dessen Drawdown genutzt hat, um ein anderes Feature auszuwählen, ist dieser Bereich Teil der Feedbackschleife geworden.
| Zeitraum | Zulässige Verwendung | Was seinen Status ändert |
|---|---|---|
| Training | Regeln und Parameter fitten | Nichts; dieser Zeitraum ist für die Suche vorgesehen |
| Validierung | Kandidaten vergleichen und Research-Entscheidungen treffen | Wiederholte Nutzung erhöht das Overfitting-Risiko |
| Abschließender Holdout | Einmalige Evaluation des eingefrorenen Kandidaten | Ergebnis ansehen und den Kandidaten ändern |
| Künftiger Paper-Trading-Zeitraum | Das Umsetzungsverhalten prospektiv beobachten | Werden die Ergebnisse zum Tuning genutzt, beginnt ein neuer Research-Zyklus |
Eine rollierende Walk-Forward-Evaluation kann dabei helfen, abzuschätzen, wie sich ein festgelegter Research-Prozess im Zeitverlauf verhält. Sie erlaubt keine unbegrenzten Einblicke in jeden Fold. Sieht ein Agent die Fold-Ergebnisse und passt seine Suche an, sind auch diese Folds Teil des Feedbacks. Bewahre einen abschließenden, unangetasteten Zeitraum für die Entscheidung auf, die du tatsächlich treffen willst.
Fehler 3: Den Code einfrieren, aber die Fragestellung ändern
Manchmal bleibt der Strategiecode unverändert, aber der Researcher ändert nach Sichtung des Ergebnisses die Evaluation: Er tauscht den Benchmark aus, schließt einen schlechten Monat aus, berichtet über ein anderes Anlageuniversum oder konzentriert sich auf die Kennzahl mit dem besten Ergebnis. Der Testsatz hat die Darstellung also beeinflusst, selbst wenn kein Parameter geändert wurde.
Das Debakel zeigt sich in einem ausgefeilten Bericht mit einer klaren Kernaussage, aber ohne Aufzeichnung der anderen Ansichten, die ausprobiert wurden. Eine Aktienstrategie kann gegenüber einem breiten Marktindex schwach, gegenüber Cash aber stark wirken; eine Krypto-Strategie kann auf einer Börse glänzen, nachdem mehrere Börsen geprüft wurden. Solche Vergleiche können nützlich sein, aber nach Sichtung des Holdouts daraus auszuwählen, ist ein weiterer Selektionsschritt.
Führe ein Research-Logbuch. Speichere für jeden Lauf die Hypothese, Codeversion, den Daten-Snapshot, die Parametersuche, Evaluationsfenster, angefragten Kennzahlen und ob der Agent oder der Researcher das Ergebnis gesehen hat. Ein knappes Protokoll ist nützlicher als ein vielversprechendes Label wie „out of sample“.
Lege dann vor der Evaluation die abschließende Fragestellung genau fest: welcher Kandidat, welches Marktuniversum, welcher Benchmark, welche Kosten und welche Kennzahlen? Ändert sich die Antwort nach Eingang des Ergebnisses, behandle den nächsten Lauf als Research und halte neue Daten für die nächste abschließende Prüfung zurück.
Was kann ich aus einem verfälschten Holdout noch lernen?
Er ist nicht nutzlos. Er kann zeigen, wie sich eine Strategie in diesem Zeitraum verhalten hat, und bei der Fehlersuche helfen. Stelle seinen Score nur nicht mehr als unabhängige Bestätigung dar. Nutze ihn als Entwicklungsgrundlage, friere den nächsten Kandidaten ein und evaluiere ihn in einem tatsächlich zukünftigen Paper-Trading-Zeitraum mit denselben Bilanzierungs- und Ausführungsannahmen.
In einem agentengesteuerten Workflow verliert man leicht den Überblick über die Zahl der Experimente: Ein einziger Prompt kann Dutzende Läufe erzeugen, bevor es jemand bemerkt. Der Schutz liegt im Vorgehen. Begrenze, was der Agent einsehen kann, protokolliere jedes Experiment und behalte eine Evaluation, deren Ergebnis den bewerteten Kandidaten nicht beeinflussen kann.
← Alle Beiträge
