Live-Backtest-Vergleich in die Pipeline: core/stichprobe.py + Abschnitt E
Konsequenz aus dem Messfehler vom 07.08.: der Vergleich lief nur, wenn jemand
daran dachte - und als er lief, war er falsch gebaut.
1) core/stichprobe.py - die Praevention ist KONSTRUKTIV, nicht ermahnend:
entkoppeln() / anteil_ci() / unterscheidbar() / schluessel_level_stunde().
Regel: vor jeder berichteten Rate entkoppeln, jede Aussage ueber einen
Unterschied mit Konfidenzintervall belegen. Die Zeilen in
pbreak_predictions und recommendations sind nicht unabhaengig.
8 Tests, darunter einer, der die reale Konstellation nachspielt
(roh 77 %, entkoppelt 33 %).
Fallstrick beim Bau, gefunden weil ich es laufen liess: ein sqlite3-Cursor
liefert Tupel, keine dicts - die Feldangabe akzeptiert jetzt Namen UND
Spaltennummern.
2) analyze_divergence.sec_d0 war selbst der Fehler. Es mittelte AVG(p_break)
ueber ALLE Rohzeilen und flaggte bei Delta > 8 Pp:
vorher 1058 rohe Zeilen, Delta +8,7 Pp -> ALARM
jetzt 110 entkoppelte, 37,6 % liegt in [37,3 ... 55,5] % -> OK
Der Waechter haette heute also einen Fehlalarm produziert - genau den, dem
ich elf Hypothesen lang nachgegangen bin.
3) NEU: Abschnitt E "GLEICHES FENSTER" (--backtest). Rechnet den Backtest ueber
genau den Live-Zeitraum und haelt ihn gegen das Intervall der entkoppelten
Live-Rate. Erster Lauf: live 46,4 % [37,3 ... 55,5] gegen Backtest 43,9 %
-> im Intervall, kein Befund.
4) Eingebaut in den Wochenreport (weekly_review._divergenz_section, montags
07:30 per Mail + Telegram), mit demselben Fail-safe wie der
Squeeze-Abschnitt. Bewusst NICHT in den pre-commit-Hook: der braucht MT5 und
Minuten, Stufe 1 muss bei ~5 s bleiben.
Ausserdem ein Rechenfehler in meinem ersten Entwurf behoben (p_break steht in
der DB bereits in Prozent, ich hatte zusaetzlich skaliert -> "3763,9 %") und
ein \n-Heredoc-Fall, der genau gegen die dokumentierte Regel verstiess.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
1f58049049
commit
3f1f19087d
@@ -4911,6 +4911,53 @@ Modell schliesst keine Trades.
|
||||
„die Rangfolge ist kaputt" ist **nicht** belegt; belegt ist nur die
|
||||
Basisraten-/Kalibrierungslücke.
|
||||
|
||||
## ✅ LIVE↔BACKTEST-VERGLEICH IST JETZT TEIL DER PIPELINE (2026-08-07)
|
||||
|
||||
Konsequenz aus dem Messfehler direkt darunter: der Vergleich lief nur, wenn
|
||||
jemand daran dachte — und als er lief, war er falsch gebaut. Beides behoben.
|
||||
|
||||
**(1) `core/stichprobe.py` — die Prävention ist KONSTRUKTIV, nicht ermahnend.**
|
||||
`entkoppeln()` · `anteil_ci()` · `unterscheidbar()` · `schluessel_level_stunde()`.
|
||||
⚠ **Regel: vor jeder berichteten Rate entkoppeln, jede Aussage über einen
|
||||
Unterschied mit Konfidenzintervall belegen.** Ein Punktschätzer ist auf
|
||||
`pbreak_predictions`/`recommendations` keine Aussage — die Zeilen sind nicht
|
||||
unabhängig. 8 Tests, darunter einer, der die reale Konstellation vom 07.08.
|
||||
nachspielt (roh 77 %, entkoppelt 33 %).
|
||||
⚠ Fallstrick beim Bau, gefunden weil ich es laufen liess: ein sqlite3-Cursor
|
||||
liefert **Tupel**, keine dicts (`TypeError: tuple indices must be integers`) —
|
||||
die Feldangabe akzeptiert deshalb Namen **und** Spaltennummern.
|
||||
|
||||
**(2) `analyze_divergence.sec_d0` war selbst der Fehler — behoben.** Es mittelte
|
||||
`AVG(p_break)` über ALLE Rohzeilen und flaggte bei Δ > 8 Pp.
|
||||
| | vorher | jetzt |
|
||||
|---|---|---|
|
||||
| Grundmenge | 1.058 rohe Zeilen | **110 entkoppelte** |
|
||||
| Urteil | Δ +8,7 Pp → **ALARM** | 37,6 % liegt in **[37,3 … 55,5] %** → **OK** |
|
||||
Der Wächter hätte heute also einen Fehlalarm produziert — genau den, dem ich
|
||||
elf Hypothesen lang nachgegangen bin.
|
||||
|
||||
**(3) NEU: Abschnitt E „GLEICHES FENSTER"** (`--backtest`). Rechnet den Backtest
|
||||
über **genau den Live-Zeitraum** und hält ihn gegen das Intervall der
|
||||
entkoppelten Live-Rate. Erster Lauf: live 46,4 % [37,3 … 55,5] gegen Backtest
|
||||
**43,9 %** → im Intervall, kein Befund. ⚠ Braucht MT5 und ~1–2 min, deshalb
|
||||
opt-in — der Rest des Wächters bleibt DB-only und schnell.
|
||||
|
||||
**(4) EINGEBAUT IN DEN WOCHENREPORT** (`weekly_review._divergenz_section`,
|
||||
montags 07:30 per Mail + Telegram). CLAUDE.md nannte den Wächter seit dem 31.07.
|
||||
als „Kandidat für den Wochenreport" — jetzt ist er drin, mit demselben
|
||||
Fail-safe wie der Squeeze-Abschnitt (schlägt er fehl, fehlt der Abschnitt, der
|
||||
Report läuft weiter).
|
||||
⚠ **Bewusst NICHT in den pre-commit-Hook**: der braucht MT5 und Minuten; die
|
||||
Stufe-1-Prüfung muss bei ~5 s bleiben, sonst wird sie deinstalliert.
|
||||
|
||||
**Damit deckt die Pipeline drei verschiedene Fehlerklassen ab:**
|
||||
| Stufe | schützt gegen | Takt |
|
||||
|---|---|---|
|
||||
| pre-commit (`check_nfalle` + `pytest`) | Syntax, undefinierte Namen, `\n`-Falle | jeder Commit |
|
||||
| Track B (2 Stichproben, Nachbarn, KI) | **Overfitting** — Edge existiert nicht | je Strategie-Idee |
|
||||
| **Divergenz-Wächter D0/E** | **Deployment-Drift** — Edge existiert, läuft aber anders | **wöchentlich** |
|
||||
| `tools/deploy.py --feld` | Aktivierung ohne Wirkung | jeder Rollout |
|
||||
|
||||
## ✅⚠⚠ DIE „BASISRATEN-LÜCKE" WAR EIN MESSFEHLER — MEINER (2026-08-07, aufgelöst)
|
||||
|
||||
Nach elf geprüften Hypothesen ist der Befund: **es gab keinen Fehler im System.**
|
||||
|
||||
Reference in New Issue
Block a user