Burbubot im Test: Automatisiertes Wett-System noch nicht bereit für echtes Geld

Die Validierung eines automatisierten Wett-Systems erfordert die Trennung von Pre-Match-Recherche und Live-Ausführung, das Einfrieren der Parameter vor der Bestätigung und die Ablehnung eines statistischen Tests, der die Abhängigkeit zwischen Ligen ignoriert. Ohne ausreichende prospektive Daten und ohne einen Ausführungsvertrag, der Rundungen und Duplikate verhindert, ist das System nicht bereit für den Betrieb mit echtem Geld.

Bei solchen automatisierten Systemen gibt es eine sehr menschliche Versuchung: die perfekte Maschine zu bauen, bevor man prüft, ob die Maschine das misst, was sie zu messen glaubt. Der vorliegende Fall hat funktionierenden Code, eine Roadmap und ein unabhängiges Audit, das konkrete Probleme gefunden hat. Und vor allem hat er eine unbequeme Frage: Ist das System validiert oder nur gut gebaut?

Die kurze Antwort lautet: In einigen Teilen ist es gut gebaut, in fast allen schlecht validiert. Die lange Antwort ist dieser Artikel.

## Das Problem, Pre-Match-Recherche mit Live-Ausführung zu vermischen

Das System hat zwei Linien, die nicht verbunden sind. Auf der einen Seite eine historische Live-Wett-Engine mit Statistiken, Klassifikatoren und den Märkten HOME/AWAY/DRAW/OU15/OU25, die den CSV-Emitter für Betting Toolkit enthält. Auf der anderen Seite eine Pre-Match-Rechercheplattform für 1X2 bei T-30, mit Dixon-Coles-Modell, prospektiver Erfassung und statistischer Auswertung.

Das Audit warnt vor etwas Elementarem: Nachzuweisen, dass ein Pre-Match-1X2-Modell den Markt schlägt, validiert weder die Live-Engine noch deren Tor-Märkte. Das sind zwei verschiedene Dinge. Und die aktiven Rechercheaufgaben vervollständigen nicht von selbst die Veröffentlichungs- und Ausführungskette der historischen Engine.

Die vernünftige Entscheidung ist, zuerst eine kleine, überprüfbare Pre-Match-1X2-Version fertigzustellen und In-Play als separate Linie zu halten. Unter welchen Bedingungen ließen sich Komponenten wiederverwenden, ohne die Validierung unzulässig zu übertragen? Die Antwort liegt in der Trennung der Verantwortlichkeiten: Der Erfassungscode, der CSV-Serializer und das Dateisystem können geteilt werden, wenn ihre Tests modellunabhängig sind. Was nicht geteilt werden kann, ist die statistische Validierung. Ein Modell, das im Pre-Match funktioniert, sagt nichts über ein anderes aus, das live mit anderen Märkten arbeitet.

## Dixon-Coles, Quoten und die C(M)-Kontrolle

Das aktuelle prädiktive Design kombiniert zwei Quellen. Einerseits 1X2-Wahrscheinlichkeiten aus einem Dixon-Coles-Modell, trainiert mit Ergebnissen, die vor dem zeitlichen Stichpunkt verfügbar waren. Andererseits Wahrscheinlichkeiten aus den Bet365-Quoten, die über API-Football eintreffen, wobei die Marge durch proportionale Normalisierung entfernt wird. Anschließend kalibriert das System den Markt mit einer Temperatur T nach und kombiniert beide mit einem Gewicht α in einer log-linearen Formel.

Die Hypothese ist, dass die Kombination aus Modell und Markt den nachkalibrierten Markt schlägt. Gemessen wird mit multiklassigem Log-Loss; α und T werden in der Entwicklung geschätzt und zur Bestätigung eingefroren.

Ist diese C(M)-Kontrolle angemessen? Sie hat ein grundlegendes Problem. F und C(M) als Modelle mit „je einem freien Parameter“ darzustellen ist irreführend, wenn A vorheriges Training und Selektion einbezieht. Das Dixon-Coles-Modell ist kein Parameter: Es ist ein Verfahren mit Spezifikationsentscheidungen, Trainingsfenstern und Variablenauswahl. F mit C(M) zu vergleichen, ohne diese Asymmetrie anzuerkennen, ist wie ein Serienfahrzeug mit einem Werkstatt-aufgefrischten Auto zu vergleichen und zu behaupten, beide hätten „einen Motor“.

Der Vergleich mit Elo und Ligahäufigkeiten hilft, löst das Problem aber nicht. Brier, RPS, Kalibrierung und Coverage auszuweisen ist in Ordnung. Was fehlt, ist eine negative Kontrolle, die zeigt, ob die Verbesserung vom Modell oder vom Selektionsprozess stammt.

## Die Feed-Frische und das Trugbild der Schlussquote

Hier gibt es ein Problem, das jeder sofort erkennt, der mit Echtzeitdaten gearbeitet hat. Ein realer Test ergab, dass der Empfang einer Quoten-Antwort um 13:01:31 UTC erfolgte, das Upstream-Update aber von 12:00:21 UTC stammte. Das heißt: Eine Antwort jetzt zu erhalten bedeutet nicht, eine aktuelle Quote zu erhalten.

Die Dokumentation des Anbieters beschreibt Pre-Match-Updates etwa alle drei Stunden, mit Variationen. Das bedeutet, dass eine Erfassung bei T-30 und eine bei T-5 zwei Lesungen desselben Upstream-Updates sein können. In diesem Fall misst eine Schlussdifferenz nahe null keine Markteffizienz: Sie misst die Unbeweglichkeit des Feeds.

Die Roadmap ergänzt Erfassungen bei T-5 und T-1 nur zur Auswertung und berechnet D_close als Differenz des Log-Loss zwischen der Quote bei T-30 und der Schlussquote. Das Problem ist, dass diese Diagnose möglicherweise nichts misst.

Was lässt sich mit diesem Anbieter wirklich schlussfolgern? Wenig, solange die Frische nicht systematisch gemessen wird. Sollte D_close aus den Entscheidungsregeln entfernt werden, wenn keine ausreichend frische Schlussquote vorliegt? Ja. Eine Diagnose, die einen effizienten Markt nicht von einem eingefrorenen Feed unterscheidet, ist keine Diagnose: Es ist Rauschen im Datenformat.

Die Frische-Richtlinie darf nicht nach günstigen Ergebnissen gewählt werden. Sie muss vorher festgelegt werden: etwa mit der Anforderung, dass die Differenz zwischen Empfangszeitstempel und Upstream-Update-Zeitstempel unter einem vordefinierten Schwellenwert liegt, und Erfassungen, die dies nicht erfüllen, als ungültig für die Schlussanalyse zu behandeln. In einem Pilotversuch müssten die Verteilung dieser Differenz, die tatsächliche Update-Frequenz und die Korrelation zwischen aufeinanderfolgenden Erfassungen gemessen werden.

## Der statistische Test: die Haupthürde

Die Roadmap schlägt einen einseitigen Test mit Niveau α=0,025 über den ungewichteten Mitteleffekt zwischen den Ligen vor. Die Teststatistik ist ein Ibragimov-Müller-t über die Ligamittelwerte. Das Audit stellt die Annahme der Unabhängigkeit zwischen Ligen infrage und die Beschreibung der Methode als immun gegen jegliche zeitliche Abhängigkeit.

Die Zahlen, die man genau betrachten muss, sind die der bestehenden Kalibrierung. Das empirische Basisszenario ergibt einen Typ-I-Fehler von **0,0394** bei einem nominalen Wert von **0,025**. Das Heterogenitätsszenario steigt auf **0,0536**. Das 12-Ligen-Szenario bleibt bei **0,0378**. Und die Power für einen MDE von **0,002** übersteigt im besten Fall nicht **0,2946**.

PASS wurde deklariert, weil alle Fehler ≤0,060 waren. Das belegt keine Kontrolle am einseitigen Niveau von 0,025. Auch liegt keine Power nahe 80 % vor. Ein System, das einen Effekt von 0,002 nicht einmal mit 30 % Wahrscheinlichkeit erkennt, ist nicht validiert: Es wartet darauf, dass der Zufall ihm recht gibt.

Die unabhängige Simulation des Audits verwendete 26 Gaußsche Mittelwerte unter exakter Nullhypothese mit gemeinsamer Korrelation ρ und 20.000 Replikate. Die Ergebnisse sind aussagekräftig: Bei ρ=0,05 steigt die Ablehnungsrate auf **0,0936**; bei ρ=0,10 auf **0,1555**; bei ρ=0,20 auf **0,23185**; bei ρ=0,50 auf **0,3468**. Das schätzt nicht die reale Korrelation des Projekts. Es ist ein Gegenbeispiel zur allgemeinen Garantie und zeigt, warum gemeinsame Schocks untersucht werden müssen.

Welches Inferenzverfahren wäre bei Abhängigkeit nach Liga, Team und Kalender vertretbar? Es gibt mehrere Optionen, aber keine ist kostenlos. Ein Block-Bootstrap, der die zeitliche und Querschnittsstruktur erhält, erfordert die Schätzung der Abhängigkeit, und drei Wochen Daten erlauben keine zuverlässige Schätzung. Ein Bayes'sches hierarchisches Modell würde die Einbeziehung der Abhängigkeit erlauben, erfordert aber die Spezifikation einer ebenfalls unbekannten Struktur.

Das Kriterium zur Akzeptanz der Kalibrierung sollte die Monte-Carlo-Unsicherheit einbeziehen. Bei 5.000 Replikaten beträgt der Standardfehler einer Ablehnungsrate von 0,025 etwa 0,0022. Das bedeutet, dass ein 95-%-Konfidenzintervall für die beobachtete Rate von 0,0207 bis 0,0293 reicht. Wenn das System PASS mit 5.000 Replikaten deklariert, während die Roadmap 20.000 verlangt, akzeptiert es eine Präzision, die es nicht hat.

## Sich reproduzierende operative Mängel

Das Audit fand Mängel, die nach 52 ausgewählten Unit-Tests und 804 dokumentierten Prüfungen weiterhin reproduzierbar sind. Das ist kein Testproblem: Es ist ein Designproblem.

Das erste sind mehrdeutige Wiederholungsversuche. Im Status/Fixtures-Client wird vor dem Senden ein Ticket reserviert. Bei einem Timeout beim Lesen der Antwort wird der Versuch wiederholt und nach Erschöpfung die Reservierung gelöscht. Mit simuliertem Transport führten zwei Zyklen desselben Tickets zu sechs Sendungen und null verbleibenden dauerhaften Datensätzen. Es sind Daten-GETs, keine Wetten, aber Rückverfolgbarkeit und Verbrauchsbuchhaltung gehen verloren.

Das zweite ist das falsche HEALTHY. Der Erfasser kann state=RUNNING und network_status=OFFLINE_AWAITING_RECONNECT melden; der Supervisor ignoriert Letzteres und gibt HEALTHY zurück. Das ist ein System, das behauptet, in Ordnung zu sein, obwohl es das nicht ist.

Das dritte ist der falsche Uhr-Erfolg. Das Panel kann ok=true und „Synchronisierung abgeschlossen“ ausgeben, obwohl beide NTP-Befehle fehlschlagen und keine Messprobe existiert.

Das vierte sind Zeitfenster und Latenzen. Es gibt Aufgaben jede Minute, Anfragen, die 45 Sekunden blockieren können, und sequenzielle Abschaltungen mit einem Timeout von 120 Sekunden. Die Priorität von T-30 innerhalb eines Zyklus stellt nicht sicher, dass der nächste bearbeitet wird, wenn der vorherige noch blockiert ist.

Eine minimale Zustandsmaschine für Reservierung, Sendung, Antwort, Unsicherheit und Wiederherstellung müsste zwischen „nicht gesendet“, „gesendet ohne Bestätigung“, „bestätigt“ und „fehlgeschlagen“ unterscheiden. GET-Wiederholungen dürfen keine Beweise löschen: Jeder Versuch muss mit seinem Zeitstempel und seinem Ergebnis protokolliert werden. Und Lasttests müssten Blockierungen, Timeouts und Wiederherstellungen simulieren, um zu prüfen, dass das System keine Rückverfolgbarkeit verliert.

## Der CSV-Vertrag und die Ausführung

Die bestehende CSV enthält Provider, SelectionId, MarketId, SelectionName, MarketName, MarketType, BetType, EventName, EventId, Handicap, Price, MinPrice, MaxPrice und Points. Sie wird über temporäre Datei und atomaren Austausch veröffentlicht. Sie enthält weder signal_id noch ein Ablaufdatum.

Synthetische Tests des Serializers ergaben, dass er NaN akzeptiert und rundet: MinPrice 2,005 wird zu 2; MaxPrice 2,999 wird zu 3. Es wurden keine realen Signale mit diesen Werten gefunden, aber der Mangel besteht darin, dass die letzte Veröffentlichungsschranke nicht verhindert, ein Limit durch Rundung auszuweiten. Ein Preislimit, das durch Rundung erweitert wird, ist ein Limit, das nicht existiert.

Der vollständige Vertrag müsste abdecken: eindeutige Identifikation von Spiel, Markt und Runner; aus API-Football abgeleitete Preisgrenzen, die der Executor respektiert; wirksames Ablaufen; Deduplizierung nach Neustarts; die Lücke zwischen Veröffentlichung und Empfang der Annahme; Ablehnung, Teilausführung, Stornierung und Abstimmung; sowie ausgeführter Preis und tatsächliche Gebühr.

Der ökonomische Test muss an realen oder getreu simulierten Ausführungen erfolgen, nicht unter der Annahme, dass zum API-Preis gewettet wird. Eine über API-Football erhaltene Bet365-Quote kann als Referenz dienen, aber sie ist nicht der Preis, zu dem Betting Toolkit auf Betfair ausführen wird. Diese Unterscheidung ist der Unterschied zwischen einem Backtest und einer Fantasie.

## Was fehlt und was gemessen werden muss

Das System verfügt über 29.719 historische FT-Ergebnisse, einen historischen Proxy von 709 Spielen mit 504 in drei Wochen auswertbaren, 26 Liga-IDs und eine neue Kampagne mit 124 Spielen und 125 erfassten Vorkommnissen. Eine gültige prospektive Quotenbeobachtung und null vollständige gemeinsame Paare zur Auswertung.

Mit diesen Zahlen ist die fehlende Mindestevidenz klar: ausreichend prospektive Paare, um die Abhängigkeit zwischen Ligen zu schätzen; ein Null-Generator, der die zeitliche und Querschnittsstruktur erhält, ohne Strukturen als bekannt vorauszusetzen, die drei Wochen nicht erlauben zu schätzen; und ein Stoppkriterium, das zwischen „keine Evidenz“ und „Evidenz dagegen“ unterscheidet.

Der bestätigte API-Football-Plan läuft am 17.11.2026 ab. Das System läuft unter Windows, mit vier geplanten Aufgaben und einer von dem Dokumentenordner auf Drive getrennten Laufzeitumgebung. Es hängt vom PC und der Sitzung ab. Das ist keine Produktionsarchitektur: Es ist ein Prototyp mit Verfallsdatum.

Die Schlussfolgerung, wenn man Offenheit erlaubt ist, lautet: Das System ist nicht bereit für echtes Geld. Nicht, weil der Code schlecht ist, sondern weil die Validierung die Entscheidungen, die mit ihr getroffen werden sollen, nicht trägt. Ein breites, mit Verbesserung vereinbares Intervall ist keine günstige Evidenz. Eine alte Schlussquote ohne Änderung ist nicht die Abwesenheit einer Gelegenheit. Und ein PASS mit 5.000 Replikaten, wenn 20.000 verlangt werden, ist kein PASS: Es ist Ungeduld.

Bevor man einen einzigen Euro riskiert, muss bewiesen werden, dass das System misst, was es zu messen behauptet. Und das ist mit den aktuellen Daten noch ausstehend.