Ein perfekt reproduzierbarer Backtest kann weniger verlässlich sein als einer, dessen Ergebnis sich leicht verändert. Wiederholbarkeit beweist, dass du zweimal dieselbe Antwort erhältst; sie sagt nichts darüber aus, ob die Antwort von einem beliebigen Datensnapshot, einer Eigenheit der Bibliothek oder einem versteckten Standardwert abhängt.
Das klingt nach einem Argument gegen Reproduzierbarkeit, ist es aber nicht. Fixiere den Lauf, damit du ihn erklären kannst. Variiere dann bewusst die Annahmen, die das Ergebnis eigentlich nicht bestimmen sollten. Mit dem ersten Schritt wird ein Ergebnis auditierbar; mit dem zweiten findest du heraus, ob es überhaupt etwas aussagt.
Was belegt ein reproduzierbarer Backtest tatsächlich?
Wenn derselbe Code, dieselben Daten, dieselbe Konfiguration und derselbe Zufalls-Seed dieselben Trades und Kennzahlen ergeben, hast du eine wichtige Quelle für Verwirrung ausgeschaltet. Die „Verbesserung“ eines Agenten lässt sich mit dem übergeordneten Lauf vergleichen. Ein Bugfix lässt sich von einer geänderten Gebührenstruktur unterscheiden. Ein Kollege kann dasselbe Ledger prüfen und dieselben Fills finden.
Doch das Ergebnis gilt nur unter allen Bedingungen, die du fixiert hast. Stell dir eine Krypto-Strategie vor, deren historische Datei 1-Minuten-Bars enthält. Du speicherst den Datei-Hash, fixierst den Code und erhältst bei jedem erneuten Lauf einen Sharpe von 1.4. Korrigiert der Datenanbieter später mehrere Candles, beschreibt diese saubere Reproduzierbarkeit weiterhin nur die alte Datei. Sie sagt dir nicht, ob das Signal auch mit der korrigierten Historie Bestand hat oder ob diese Candles zum damaligen Zeitpunkt überhaupt in dieser Form verfügbar waren.
Der Hash ist nützlich: Er macht die Abhängigkeit sichtbar. Er ist kein Beleg dafür, dass diese Abhängigkeit harmlos ist.
Fixiere den Lauf, hinterfrage die Erkenntnis
Ich trenne gern zwei Fragen voneinander: Können wir genau diesen Lauf rekonstruieren? Und hält die Forschungsaussage vernünftigen Änderungen stand? Für die erste braucht es eine unveränderliche Aufzeichnung; für die zweite kontrollierte Variationen, jeweils eine auf einmal.
| Was zu dokumentieren ist | Was sich anschließend variieren lässt | Was dadurch sichtbar werden kann |
|---|---|---|
| Rohdatenversion und Prüfsummen | Revision des Anbieters oder eine zweite Quelle | Abhängigkeit von korrigierten oder anbieterspezifischen Werten |
| Code-Commit und Paketversionen | Numerisch gleichwertige Implementierung | Empfindlichkeit gegenüber Reihenfolge, Rundung oder Bibliothek |
| Gebühren, Funding und Fill-Annahmen | Vertretbare Kostenspanne | Ob ein knapper Edge ungewöhnlich günstige Ausführung voraussetzt |
| Universum und zeitpunktbezogene Mitgliedschaft | Alternative Regeln für zugelassene Märkte | Abhängigkeit von Entscheidungen über Aufnahme oder Ausschluss |
Angenommen, eine Futures-Strategie weist im Baseline-Replay eine annualisierte Überrendite von 8% aus. Lass sie erneut laufen, mit um 25% höheren Taker-Kosten, Funding zum nächsten beobachteten Abrechnungszeitpunkt und entferne nacheinander die beiden größten Beitragsleister. Das sind keine drei Möglichkeiten, das Modell zu verbessern. Es sind Prüfungen: Jede fragt, ob ein plausibles Detail das Schlagzeilenergebnis trägt.
Halte jede Prüfung getrennt. Änderst du gleichzeitig die Daten, die Gebührenstruktur und den Ausführungszeitpunkt, lässt sich ein schlechteres Ergebnis kaum diagnostizieren. Ist eine Prüfung unrealistisch, kennzeichne sie als Stresstest, statt sie als wahrscheinliches Ergebnis darzustellen.
Verwechsle bytegenaue Gleichheit nicht mit numerischer Wahrheit
Manche Berechnungen reagieren empfindlich auf die Reihenfolge. Gleitkommaaddition ist nicht assoziativ, daher kann sich beim Addieren vieler kleiner P&L-Werte in anderer Reihenfolge die letzte Ziffer ändern. Parallele Reduktionen, Hardware und Bibliotheksversionen können sich alle auf die exakte Ausgabe auswirken. Meist ist das harmlos; manchmal kippt eine winzige numerische Änderung einen Schwellenwert, verändert eine Position und schickt den Rest der Simulation auf einen anderen Pfad.
Deshalb würde ich sowohl die exakten Artefakte als auch Toleranzen für Vergleiche aufbewahren. Dokumentiere das Trade-Ledger, nicht nur den finalen Sharpe. Vergleiche zuerst Entscheidungen und Zahlungsströme und anschließend die Kennzahlen innerhalb einer festgelegten Toleranz. Wenn ein Unterschied von einem Cent darüber entscheidet, ob eine Order abgeschickt wird, prüfe diesen Grenzfall ausdrücklich.
Ein nützliches Laufprotokoll enthält die Identität der Daten und des Codes, die Konfiguration, den Zufalls-Seed, die Ausführungsumgebung und genügend Zwischenergebnisse, um eine Kennzahl bis zu den Fills und Zahlungsströmen zurückzuverfolgen. Ein Endwert allein ist kein reproduzierbares Forschungsartefakt.
Wann ist eine Abweichung Rauschen, wann eine Erkenntnis?
Nicht jede geänderte Zahl ist ein Grund zur Sorge. Eine minimale Kennzahlenabweichung aufgrund einer anderen Reduktionsreihenfolge kann auftreten, ohne dass sich die Trades ändern. Ein geänderter Trade nahe einem Schwellenwert kann eine Überprüfung wert sein. Eine Strategie, die den Großteil ihres Ergebnisses verliert, wenn ein Anbieter einen kleinen Teil der Historie überarbeitet, hat etwas über ihre eigene Fragilität gelernt, auch wenn der ursprüngliche Lauf weiterhin perfekt reproduzierbar ist.
Kritiker von Robustheitsprüfungen haben in einem Punkt recht: Man kann Annahmen immer weiter verändern, bis eine bevorzugte Strategie robust wirkt, oder ein solides Ergebnis verwerfen, weil es an einem bewusst extremen Szenario scheitert. Lege die plausiblen Variationen vorab fest, berichte die gesamte Bandbreite und unterscheide gewöhnliche Alternativen von Stresstests. Bewahre dann die Baseline auf, damit andere Forschende genau das reproduzieren können, was du gesehen hast.
Reproduzierbarkeit bietet dir einen verlässlichen Ausgangspunkt. Die nützliche Frage kommt danach: Welche Teile der Antwort bleiben bestehen, wenn sich die Welt um diesen Lauf auf eine Weise verändert, mit der du vernünftigerweise rechnen kannst?
← Alle Beiträge
