Die Baseline im Backtest ist der Wert, gegen den alles andere gemessen wird: die Strategie ohne Filter, ohne Zusatzregel, ohne Eingriff. Sagt man „dieser Filter bringt 5 Prozentpunkte", dann bringt er sie gegenüber der Baseline. Ist der Anker verrutscht, ist jede Aussage darüber verrutscht — und zwar alle in dieselbe Richtung.
Unsere war verrutscht. Von 4.232 Läufen, die in unserer Edge Library als „kein Filter" zählten, waren 2.370 gar keine filterlosen Läufe — sie hatten einen Mindestgewinn-Schutz aktiv. 61,6 Prozent. Wir haben die Auswertung neu gerechnet, und dabei gleich noch eine zweite Sache geändert, die kein Fehler war. Beides zusammen dreht 20 von 352 Verdikten. Dieser Text zeigt, was passiert ist, wie wir die beiden Ursachen auseinandergerechnet haben, und welche Regel daraus geworden ist.
Der Fehler: eine Spalte, die es nicht gibt
Unsere Backtest-Läufe speichern für jeden Filter ein Kennzeichen: 200-Wochen-Durchschnitt an oder aus, Volatilitätsfilter niedrig/hoch/steigend, Altcoin-Season an oder aus, Bullenmarkt-Ampel in drei Stufen. Die Auswertung liest diese Kennzeichen und sortiert jeden Lauf in seine Gruppe.
Für den Mindestgewinn-Schutz gibt es kein solches Kennzeichen. Er wird gesetzt, er wirkt, er verändert das Ergebnis — aber in der Datenbank hinterlässt er keine Spur, die die Auswertung lesen könnte. Damit sah ein Lauf mit aktivem Schutz für die Auswertung exakt aus wie ein Lauf ohne jeden Filter. Er landete in der Baseline.
Was das ausmacht, lässt sich beziffern:
| Gruppe | Läufe | Median-CAGR |
|---|---|---|
| echte Baseline | 1.862 | 0,00 % |
| Mindestgewinn-Schutz | 2.370 | −3,75 % |
| veröffentlichter Anker | 4.232 | −1,85 % |
Der Anker lag also 1,85 Prozentpunkte zu tief. Und weil jeder Filtervorteil als Differenz zu diesem Anker ausgewiesen wird, war jeder ausgewiesene Vorteil um genau diesen Betrag zu hoch. Filter sahen systematisch besser aus, als sie waren.
Je Strategie wird es deutlicher, weil die Zusammensetzung schwankt:
| Strategie | echte Baseline | veröffentlichter Anker | Verschiebung |
|---|---|---|---|
| wma_trend | 14,0 % | −2,5 % | −16,5 pp |
| regime_200d | 21,6 % | 12,3 % | −9,3 pp |
| btc_signal_rsi_sma | 19,8 % | 12,0 % | −7,8 pp |
| ema_trend_bias | 0,5 % | −5,1 % | −5,6 pp |
Zwei kleinere Geschwister desselben Problems kamen dazu. Die Variante „Bullenmarkt (früh)" traf auf keine der acht Gruppen-Regeln und fiel damit komplett aus der Auswertung — 2.003 Läufe, die nirgends auftauchten. Und die wöchentliche Berechnung las die Läufe seitenweise aus der Datenbank, ohne eine feste Sortierung zu verlangen. Ohne Sortierung garantiert die Datenbank zwischen zwei Seiten keine gleichbleibende Reihenfolge: Zeilen können doppelt kommen, andere ganz fehlen. Die veröffentlichten Zahlen entstanden also wöchentlich aus einer Teilmenge, die niemand kannte.
Die Wahl: welche Kerzen-Intervalle im Topf liegen
Der zweite Eingriff war kein Fehler, und das ist der interessantere Teil.
Unsere Edge Library fasst je Markt, Strategie und Filter alle Läufe zusammen und bildet den Median. „Alle Läufe" heißt: über alle Kerzen-Intervalle hinweg — Tages-, Wochen- und Monatskerzen zusammen in einem Topf. Wer den Topf anders füllt, bekommt einen anderen Median. Vollkommen legitim, solange man weiß, was drin ist.
Wir wussten es nicht genau. Nachgemessen enthielt der Topf nur 1-Tages-, 1-Wochen- und 1-Monats-Kerzen. Die 2- und 3-Tages-Intervalle, die unsere Oberfläche seit jeher anbietet, hatte die automatische Auswertung nie gefahren — exakt null Zellen. Damit trugen ausgerechnet die beiden langfristigen Intervalle, die bei kurzen Kurshistorien am wenigsten Signale liefern, überproportionales Gewicht.
Das ist keine Bagatelle: Es hieß, dass eine unerklärte Entscheidung — welche Intervalle zählen — jede veröffentlichte Kennzahl mitprägte, ohne irgendwo zu stehen. Wir haben 15.152 Backtests nachgerechnet und die Basis auf 1d/2d/3d/1w/1M vereinheitlicht.
Die alten Zahlen waren unter ihrer eigenen Wahl korrekt. Wir wählen jetzt anders und sagen es dazu.
Warum wir beides getrennt gemessen haben
Zwei Eingriffe treffen dieselben Zahlen. Ein simpler Vorher-Nachher-Vergleich hätte nur die Summe gezeigt — und damit die Frage offengelassen, ob die Bewegung von einem Fehler kommt oder von einer Entscheidung. Das ist ein Unterschied, den ein Leser wissen sollte.
Also zwei Läufe statt einem: Der alte Auswertungs-Code auf den neuen Daten isoliert den Intervall-Effekt. Der neue Code auf denselben Daten isoliert den Klassifikations-Effekt. Beide rechnen auf einer einmal geladenen Zeilenmenge, damit der Unterschied garantiert nur der Code ist.
| Ursache | Verdikte gedreht | DSR-Ergebnis gekippt | Deltas bewegt |
|---|---|---|---|
| Intervall-Basis (Wahl) | 18 | 30 | 99 |
| Baseline-Korrektur (Fehler) | 10 | 0 | 164 |
| gesamt | 20 | 30 | 164 |
Die Zeilen addieren sich nicht: Dreht ein Verdikt im ersten Schritt hin und im zweiten zurück, zählt es zweimal einzeln und gar nicht in der Summe.
Bemerkenswert ist das Verhältnis. Die größere sichtbare Bewegung kommt aus unserer Entscheidung, nicht aus dem Fehler. Wer nur „wir haben einen Bug behoben" schreibt, hätte den größeren Teil verschwiegen.
Was sich für Leser ändert
Vier Filter kehren ihr Vorzeichen um. Wir sagen dort jetzt das Gegenteil von vorher:
| Strategie / Filter | vorher | nachher |
|---|---|---|
| ema_cross + ATR-Expansion | hilft (+1,8 pp) | schadet (−2,9 pp) |
| ema_trend_bias + Bullenmarkt (streng) | hilft (+5,3 pp) | schadet (−2,3 pp) |
| ema_trend_bias + Bullenmarkt (bestätigt) | hilft (+1,5 pp) | schadet (−2,2 pp) |
| fg_cadence + 200-Wochen-Durchschnitt | hilft (+1,4 pp) | schadet (−1,6 pp) |
Dazu kommen 88 neue Zeilen: Mindestgewinn-Schutz und Bullenmarkt (früh) sind jetzt eigene Einträge statt in der Baseline zu verschwinden oder ganz zu fehlen.
Und die Zahl der geprüften Konfigurationen steigt von 7 auf 9. Das klingt nach einer Nebensache, ist aber die härteste Konsequenz: Je mehr Varianten man testet, desto wahrscheinlicher findet man rein zufällig eine gut aussehende. Die Korrektur dagegen — die Deflated Sharpe Ratio — wird mit mehr getesteten Varianten strenger. 30 Zellen weisen jetzt ein Ergebnis aus, wo vorher „nicht berechenbar" stand, und bestehen es nicht. Das ist keine Verschlechterung der Strategien, sondern eine Aussage, die es vorher nicht gab.
Grenzen dieser Auswertung
Drei Dinge, die wir nicht belegen können:
Der Intervall-Effekt und der Paginierungs-Fehler lassen sich nicht sauber trennen. Der eingefrorene Vorher-Stand stammt aus dem fehlerhaften wöchentlichen Lauf, und die alte Datenlage existiert nicht mehr. Sauber isoliert ist nur der Klassifikations-Effekt. Die 18 Drehungen im ersten Schritt enthalten also beides.
Für Läufe ohne Filter-Kennzeichen bleibt der Mindestgewinn-Schutz unsichtbar. Wir lesen das Kennzeichen jetzt, wo es existiert — bei Läufen aus der Weboberfläche existiert es nicht, dort greift weiterhin die Ableitung aus den Filter-Spalten, und der Schutz taucht darin nicht auf. Das ist der Rest des alten Fehlers. Ihn ganz zu schließen braucht eine neue Spalte.
Die 2- und 3-Tages-Zellen decken einen etwas längeren Zeitraum ab als ihre Tages-Geschwister. Sie wurden an einem Tag nachgerechnet, während die alten Zellen über 67 Rotationstage entstanden sind. Für einen Median über Dutzende Paare fällt das kaum ins Gewicht, aber es ist kein Nullwert.
Was daraus als Regel wurde
Der eigentliche Befund liegt unter den Zahlen. Rohdaten haben Objektivität: Ein Schlusskurs ist ein Schlusskurs. Abgeleitete Zahlen haben keine — sie haben eine Methode, und die Methode hat Entscheidungen. Ein „Median-CAGR der Strategie X" hängt ab von der Paar-Auswahl, den Intervallen, dem Zeitraum, brutto oder netto, der Gewichtung und der Version der Rechenlogik. Nichts davon gibt die Natur vor.
Und eine Entscheidung, die nirgends steht, wird irgendwann still neu getroffen. Genau das erzeugt den Eindruck, eine Plattform korrigiere sich im Kreis — obwohl sich niemand geirrt hat.
Wir haben daraus eine verbindliche Regel gemacht. Vor jeder Änderung an einer veröffentlichten Zahl wird schriftlich festgelegt, was der Eingriff ist:
| Fehler | Methoden-Entscheidung | |
|---|---|---|
| Erkennbar an | Es gibt einen prüfbaren Beleg: ein Code-Unterschied, ein Quell-Datum, eine Reproduktion. Die alte Zahl war nachweisbar falsch. | Die alte Zahl war nicht falsch. Ein Parameter wird anders gewählt. |
| Behandlung | Wird behoben, Beleg dokumentiert. | Braucht Begründung, Versionierung und einen Changelog-Eintrag. Die alte Zahl bleibt nachvollziehbar. |
| Rücknehmbar? | Nur mit neuem Gegenbeleg. | Ja — es ist eine Wahl. Deshalb muss sie als solche markiert sein. |
Treffen beide dieselbe Zahl, wird der Beitrag zerlegt statt summiert. Genau das ist oben passiert.
Die Lücke, die diese Regel schließt, ist präzise: Eine Methoden-Entscheidung darf nicht als Fehlerbehebung durchgehen. Sonst ist sie beliebig oft in beide Richtungen wiederholbar, ohne dass jemand Rechenschaft schuldet.
Wer die Vorgeschichte kennen möchte: Wir haben im Juli schon einmal eine eigene Historie neu gerechnet, damals wegen Look-Ahead-Bias in Makro-Daten. Und warum wir Backtests überhaupt so aufziehen, steht in Warum ehrliches Backtesting anders aussieht.
Was Backtesting Arena hier beiträgt
Die Edge Library vergleicht Strategien mit und ohne Filter über ein festes Universum, korrigiert für Mehrfachtesten und weist Stichprobengrößen aus. Sie ist damit genau die Art von Auswertung, die still falsch sein kann, ohne dass es jemandem auffällt — es steht ja eine Zahl da.
Was wir daraus mitnehmen, ist weniger die Korrektur als die Mechanik dahinter: Prüfungen, die anschlagen, wenn sich eine Gruppenzugehörigkeit verschiebt; ein Test, der die Filter-Varianten der Pipeline gegen die Auswertungs-Gruppen hält; eine feste Sortierung beim seitenweisen Lesen. Der Fehler oben war zwei Jahre lang unsichtbar, weil es keine Prüfung gab, die ihn hätte sichtbar machen können. Die gibt es jetzt.
Beide Auswertungsstände — vorher und nachher — liegen als Datei im Projekt. Wer eine alte Zahl nachschlagen will, kann das.
Häufige Fragen
Waren die alten Zahlen also falsch? Teilweise. Der Baseline-Anker war nachweisbar falsch — das ist ein Fehler. Die Intervall-Zusammensetzung war nicht falsch, sondern unerklärt; wir haben sie geändert. Von den 20 gedrehten Verdikten gehen 18 auf die Intervall-Wahl und 10 auf die Anker-Korrektur, manche zählen in beiden.
Warum hat das niemand früher bemerkt? Weil eine falsche Baseline nicht auffällt: Sie erzeugt keinen Fehler, keine leere Seite, keine absurde Zahl. Sie erzeugt eine plausible Zahl, die um einen konstanten Betrag daneben liegt. Aufgefallen ist es erst, als wir die Filter-Varianten der Pipeline gegen die Gruppen der Auswertung gehalten haben — 11 gegen 8, und die Differenz war die Antwort.
Wird sich das wieder ändern? Der Fehler nicht, ohne neuen Gegenbeleg. Die Methoden-Entscheidungen können sich ändern — ob die beiden Altcoin-Season-Modi getrennt oder zusammen ausgewiesen werden, zum Beispiel, ist offen. Solche Änderungen bekommen künftig eine Begründung und einen Changelog-Eintrag, statt als Korrektur aufzutreten.
Heißt „schadet" jetzt, dass ich diese Filter nicht nutzen soll? Nein. Ein negativer Median-CAGR über ein Paar-Universum heißt, dass der Filter im Schnitt Rendite gekostet hat. Er kann trotzdem den Drawdown gesenkt oder die Zahl der Fehlsignale reduziert haben — beides Gründe, ihn zu nutzen. Die Edge Library liefert Evidenz, keine Empfehlung.
Warum steigt die Zahl der getesteten Konfigurationen und was ändert das? Weil zwei Varianten dazugekommen sind, die vorher unsichtbar waren. Wer mehr Varianten prüft, findet häufiger eine, die zufällig gut aussieht. Die Deflated Sharpe Ratio rechnet das heraus und wird dabei mit jeder zusätzlichen Variante strenger. Dass 30 Zellen sie jetzt nicht bestehen, ist die Folge einer genaueren Buchführung, nicht schlechterer Strategien.
Wie wirkt sich das auf laufende Backtests aus? Gar nicht. Die einzelnen Backtest-Ergebnisse sind unverändert — es hat sich nur geändert, wie sie zu Gruppen zusammengefasst und miteinander verglichen werden.