Professionelle Poker-Bot-Architektur: Resilienz und Evaluation

Ein professioneller Poker-Bot ist ein evaluiertes System, keine große Strategiefunktion. Er stellt Verbindungen wieder her, ohne Annahmen zu treffen, verwirft veraltete Berechnungen, wechselt bei Ausfällen sicher auf einfachere Verfahren und kann belegen, welche Policy jede Aktion erzeugt hat. Das strategische Potenzial ist wichtig, doch für den unbeaufsichtigten Betrieb sind Wiederherstellung, Observability und disziplinierte Releases entscheidend.

Serie zur Poker-Bot-Architektur: Teil 3 von 3. Baue zuerst den zuverlässigen Kern mit Grundlegende Poker-Bot-Architektur und ergänze dann Equity und Replay-Tests mit Fortgeschrittene Poker-Bot-Architektur. Plane das Laufzeitbudget mit Kosten eines Poker-Bots 2026.

Was unterscheidet einen professionellen von einem fortgeschrittenen Poker-Bot?

Ein professioneller Poker-Bot behandelt jede Komponente als potenziell fehlerhaft und jede Strategieänderung als Experiment. Der fortgeschrittene Bot kann Equity berechnen und sich an Gegner anpassen. Der professionelle Bot kann während dieser Berechnung die Verbindung verlieren, den autoritativen Tischzustand wiederherstellen, das inzwischen veraltete Ergebnis verwerfen, einen sicheren Fallback wählen und einen Audit-Trail hinterlassen, der den Ablauf erklärt.

Der Unterschied zeigt sich in den Zuständigkeiten. Ein Supervisor verwaltet die Zustandsmaschine der Session. Ein Turn-Koordinator verwaltet Fristen und Abbrüche. Policy-Worker übernehmen Berechnungen, dürfen aber nicht auf den Socket schreiben. Eine Validierungsinstanz ist für ausführbare Aktionen zuständig. Die Telemetrie beobachtet den Ablauf, ohne ihn zu verändern. Das Release-Tooling entscheidet, welche signierte und versionierte Policy Traffic erhält.

Mehr Infrastruktur ist nicht automatisch professionell. Jedes zusätzliche System braucht einen Fehler, den es verhindert, und eine Metrik, die seine Wirksamkeit belegt.

Wie sollten Reconnect und Resynchronisierung funktionieren?

Ein Reconnect sollte den Zustand aus der Serverwahrheit neu aufbauen, bevor die Strategie fortgesetzt wird. Speichere die letzte table_id und die höchste verarbeitete table_seq. Nachdem du den Socket mit demselben API-Key geöffnet hast, sende resync_request mit diesen Werten, falls die Tisch-Session noch bestehen könnte. Wende wiederholte Events der Reihe nach an und ersetze anschließend den abgeleiteten Tischzustand durch den neuen Snapshot.

Open Poker hält den Platz eines getrennten Clients 120 Sekunden lang frei. Das ist ein Wiederherstellungsfenster, kein Schlafziel. Versuche die Verbindung mit begrenztem exponentiellem Backoff und Jitter schnell wiederherzustellen, denn viele Clients, die in festen Intervallen gleichzeitig neue Verbindungen aufbauen, können eine Lastspitze verursachen. Der Leitfaden zum Bot-Lebenszyklus dokumentiert das Zeitfenster für den Platz, und das WebSocket-Protokoll definiert resync_request, resync_response und table_state.

import asyncio
import random
 
 
async def reconnect_forever(connect_and_run):
    attempt = 0
    while True:
        try:
            await connect_and_run()
            attempt = 0
        except asyncio.CancelledError:
            raise
        except Exception as exc:
            cap = min(8.0, 0.25 * (2 ** attempt))
            delay = random.uniform(0.0, cap)
            record_disconnect(type(exc).__name__, delay)
            await asyncio.sleep(delay)
            attempt = min(attempt + 1, 6)

Die Sequenzverarbeitung muss idempotent sein. Ignoriere ein Event, dessen table_seq höchstens der zuletzt angewendeten Sequenz entspricht. Wenn eine neue Sequenz eine Lücke aufweist, fordere eine Resynchronisierung an, statt die Lücke mit Annahmen zu füllen. Der Snapshot ist autoritativ. Das Event-Log liefert den Verlauf, den das Gegnermodell benötigt.

Wie verhindern Fristbudgets veraltete Aktionen?

Fristbudgets teilen einen Zug in messbare Phasen auf und reservieren Zeit für Validierung und Netzwerkübertragung. Open Poker erlaubt derzeit 120 Sekunden, bevor automatisch gecheckt oder gefoldet wird. Ein professioneller Bot sollte dieses gesamte Fenster jedoch nicht ausschöpfen. Ein hängender Modellaufruf blockiert sinnvolle Wiederherstellung und verringert die Zahl der Hände pro Stunde.

Lege ein internes Serviceziel passend zu deiner Laufzeitumgebung fest. Ein sinnvolles Ziel sind zwei Sekunden Entscheidungsbudget für gewöhnliche Regeln oder Modellaufrufe, aufgeteilt in 100 ms für Normalisierung und Merkmale, 1.500 ms für die Policy, 100 ms für die Validierung und 300 ms Übertragungsreserve. Das Plattform-Timeout bleibt das äußere Sicherheitsnetz.

import asyncio
from dataclasses import dataclass
 
 
@dataclass(frozen=True)
class ActiveTurn:
    hand_id: str
    turn_token: str
 
 
async def decide_with_budget(snapshot, policy, active_turn):
    try:
        intent = await asyncio.wait_for(policy(snapshot), timeout=1.5)
    except (TimeoutError, ValueError, RuntimeError) as exc:
        metric("policy_fallback_total", reason=type(exc).__name__)
        intent = safe_fallback(snapshot)
 
    if ActiveTurn(snapshot.hand_id, snapshot.turn_token) != active_turn():
        metric("stale_decision_total")
        return None
    return guard(intent, snapshot)

Abbrüche müssen weitergegeben werden. Pythons asyncio.wait_for bricht überfällige Arbeit ab, doch synchroner CPU-Code gibt die Ereignisschleife nicht frei. Führe aufwendige Simulationen in einem Worker-Prozess aus oder verwende eine begrenzte native Implementierung. Pythons asyncio-Task-Dokumentation erklärt das Abbruchverhalten. Teste es mit einer absichtlich hängenden Policy, nicht nur mit einer schnellen Unit-Test-Fixture.

Wie sollten Fehlerisolierung und Fallbacks funktionieren?

Fehlerisolierung verhindert, dass optionale Intelligenz den zwingend notwendigen Spielbetrieb lahmlegt. Stelle Remote-Modelle, große Equity-Simulationen, den Gegnerspeicher und Analytics-Exporter hinter schmale Schnittstellen mit Timeouts. Die Session-Schleife und die Validierungsinstanz für gültige Aktionen müssen verfügbar bleiben, wenn alle vier ausfallen.

Verwende eine nach Kosten und Abhängigkeiten geordnete Fallback-Kaskade:

1. Primäre gelernte oder modellgestützte Policy.
2. Lokale Range-und-Equity-Policy mit kurzem Rechenbudget.
3. Deterministische Positions- und Preisregeln.
4. Check, wenn gültig, andernfalls Fold.

Jeder Abstieg erhöht eine Metrik mit entsprechendem Label und erscheint im Entscheidungsdatensatz. Ein Circuit Breaker sollte nach einem Schwellenwert keine Aufrufe an einen ausgefallenen Remote-Dienst mehr senden, eine Abkühlphase abwarten und anschließend mit einer begrenzten Anzahl von Anfragen testen. Dasselbe Modell innerhalb eines Zuges dreimal erneut aufzurufen, ist in der Regel schlechter als ein einmaliger Wechsel zum Fallback. Wiederholungen erhöhen die Latenz und können die Kosten vervielfachen.

Die Validierungsinstanz bleibt hinter der Kaskade bestehen. Auch ein Fallback kann einen Fehler enthalten. Prüfe, ob die Aktion angeboten wurde, begrenze die Raise-to-Höhe auf das aktuelle Minimum und Maximum des Servers, verlange die aktuelle hand_id und das aktuelle Token und erzeuge eine frische client_action_id. Der Leitfaden zur Fehlersuche bei Timeouts behandelt häufige Fehlerpfade bei asynchronem Code und Modellen.

Welche Observability braucht ein professioneller Poker-Bot?

Ein professioneller Poker-Bot benötigt korrelierte Logs, Metriken und Traces auf der Ebene einzelner Entscheidungen. Verwende hand_id als Korrelationsschlüssel für Poker und client_action_id als Schlüssel für die Aktionsübertragung. Ergänze Session-ID, Tisch-ID, einen Hash des Turn-Tokens, Policy-Version, Version des Merkmalsschemas, Modellversion, Prompt-Version, Range-Version und Code-Revision.

Zeichne keine privaten Zugangsdaten auf und übermittle rohe Hole Cards nicht an breit zugängliche Telemetriedienste von Drittanbietern. Hole Cards sind in geschützten Entscheidungslogs und Replay-Fixtures notwendig, doch Zugriff und Aufbewahrung sollten bewusst geregelt sein. Logs für öffentliche Dashboards sollten sie aggregieren oder unkenntlich machen.

Die zentralen Serviceindikatoren sind:

Bevorzuge Histogramme gegenüber durchschnittlicher Latenz. Ein 40 Sekunden langer Modellaufruf verschwindet in einem niedrigen Mittelwert, kann aber trotzdem eine veraltete Antwort verursachen. Die OpenTelemetry-Metrikspezifikation und die Trace-Spezifikation bieten anbieterneutrale Konzepte. Du brauchst am ersten Tag keinen großen Observability-Stack, solltest aber stabile Namen und Einheiten beibehalten, damit Dashboards nicht zu archäologischen Projekten werden.

Wie funktionieren Shadow-Policies und kontrafaktische Evaluation?

Eine Shadow-Policy sieht denselben unveränderlichen Snapshot wie die aktive Policy, darf aber keine Aktion senden. Speichere ihre vorgeschlagene Aktion, Höhe, Konfidenz, Latenz und Merkmale zusammen mit der Live-Entscheidung. So testest du Integration und Verhaltensunterschiede, ohne Chips oder Protokollkorrektheit zu riskieren.

Shadow-Ergebnisse sind kein direkter Nachweis der Winrate. Wenn die Shadow-Policy foldet, während die aktive Policy callt, folgt der weitere beobachtete Verlauf der Hand dem Call-Zweig. Du kannst nicht so tun, als hätte der Fold der Shadow-Policy das spätere Ergebnis verursacht. Verwende Shadowing, um Aktionsübereinstimmung, Latenz, Schemafehler und Abdeckung zu messen. Für den kontrafaktischen Wert brauchst du einen Simulator, einen Solver-Vergleich oder eine Off-Policy-Methode.

Für lokale Forschung an Spielen enthält OpenSpiel Algorithmen und Umgebungen für Spiele mit unvollständiger Information. Das Paper von 2019 erklärt die Evaluationsziele des Frameworks. Kombiniere Shadow-Prüfungen bei Live-Änderungen mit Replay-Suites und einer Canary-Kohorte.

Ein sinnvoller Freigabebericht enthält:

• Übereinstimmung der Aktionen nach Street und Position;
• große Abweichungen bei der Setzhöhe;
• Fehlerquoten bei Schema und Gültigkeit;
• p50-, p95- und p99-Latenz;
• Verhaltensmetriken wie VPIP, PFR und River-Call-Rate;
• Ergebnis einer gepaarten Simulation mit Unsicherheit;
• Live-Canary-Ergebnis mit Gegnerkohorte und Handzahl.

Wir geben eine Policy nicht frei, weil ihre Erklärungen intelligenter klingen. Wir geben sie frei, weil sich das Verhalten in die beabsichtigte Richtung bewegt hat und die Kriterien für Korrektheit und Latenz weiterhin erfüllt sind.

Wie sollten Policy-Releases und Rollbacks funktionieren?

Policy-Releases sollten unveränderlich, versioniert und reversibel sein. Bündele Code-Revision, Merkmalsschema, Range-Daten, Prompt-Text, Modellkennung, Evaluator-Version und Konfiguration in einem Release-Manifest. Das Entscheidungslog speichert die Manifest-ID, damit jede Hand mit exakt der Policy wiederholt werden kann, die gehandelt hat.

Verwende einen Release-Prozess mit expliziten Kriterien:

1. Unit- und Property-Tests bestehen, einschließlich der Invarianten für gültige Aktionen.
2. Replays aufgezeichneter Hände erzeugen geprüfte Diffs.
3. Eine lange Simulation zeigt keine Regression bei Speicherverbrauch oder Latenz.
4. Der Shadow-Modus erfüllt die Kriterien für Schema, Abdeckung und Latenz.
5. Eine kleine Live-Canary-Gruppe erhält die neue Version.
6. Der automatische Rollback überwacht Schwellenwerte für Ablehnungen, Fallbacks, veraltete Entscheidungen und Abstürze.
7. Die Strategieleistung wird erst geprüft, nachdem sich genügend Hände angesammelt haben.

Ein operativer Rollback sollte schnell erfolgen und unabhängig von Pokervarianz sein. Ein Anstieg ungültiger Aktionen kann einen sofortigen Rollback auslösen. Ein Rückgang bei bb/100 kann das in der Regel nicht, weil kleine Stichproben stark rauschen. Trenne harte Betriebskriterien von langsamen Leistungskriterien.

Die Zustandskompatibilität verdient besondere Aufmerksamkeit. Wenn ein neues Gegnermodell die Namen gespeicherter Merkmale ändert, musst du entweder die Daten migrieren oder den Reader versionieren. Ein Rollback, der den gestrigen Zustand nicht lesen kann, ist kein Rollback. Wir bevorzugen unveränderliche, nur ergänzte Rohbeobachtungen, aus denen abgeleitete Merkmale je nach Version neu aufgebaut werden. Das kostet mehr Speicherplatz, verhindert aber, dass Strategieänderungen den Verlauf beschädigen.

Wie misst du die Pokerleistung, ohne dich selbst zu täuschen?

Messe die Pokerleistung mit Unsicherheit, kontrollierten Vergleichen und Verhaltensdiagnostik. Gib Big Blinds pro 100 Hände zusammen mit Stichprobengröße und Konfidenzintervall an. Segmentiere nach Policy-Version, Tischgröße, Position und Gegnerkohorte. Rohe Saisonchips sind für den Wettbewerb wichtig, stellen aber keinen stabilen Vergleich zwischen Läufen mit unterschiedlichen Buy-ins oder unterschiedlicher Blindbelastung dar.

Kleine Stichproben täuschen. Ein Bot kann mehrere All-ins gewinnen und trotzdem konsequent Entscheidungen mit negativem Erwartungswert treffen. Verfolge Showdown- und All-in-Diagnostik, aber verwechsle auch eine bereinigte Metrik nicht mit der Wahrheit. Gegnermodelle driften, Multiway-Pots erschweren Schätzungen und Live-Policies verändern die Daten, aus denen sie später lernen.

Verwende drei Evidenzquellen:

Lege die Experimentfrage fest, bevor du die Ergebnisse ansiehst. „River-Calls mit einer Equity unter dem Preis um 30 % senken, ohne die Zahl der Timeout-Fallbacks zu erhöhen“ ist testbar. „Den Bot GTO-näher machen“ ist es nicht. Der Plan von null bis zur Bestenliste ist für den Iterationsrhythmus hilfreich, während Stack-Management Risikomaße behandelt, die reine Chipstände nicht erfassen.

Was muss das Produktions-Runbook enthalten?

Das Produktions-Runbook braucht konkrete Maßnahmen für Authentifizierungsfehler, Reconnect-Schleifen, Resynchronisierungslücken, Spitzen bei abgelehnten Aktionen, Modellausfälle, langsame Entscheidungen, beschädigten Zustand, niedrigen Kontostand und Saisonwechsel. Jeder Alarm sollte eine zuständige Maßnahme, einen sicheren Fallback und die Evidenz benennen, die vor der Rückkehr zum Normalbetrieb erforderlich ist.

Ein Modellausfall sollte beispielsweise nicht schon nach einem einzigen fehlgeschlagenen Aufruf einen Bereitschaftsdienst alarmieren. Der Circuit Breaker öffnet sich, die lokale Policy übernimmt und ein Alarm wird ausgelöst, wenn die Fallback-Rate über einen längeren Zeitraum einen Schwellenwert überschreitet. Eine Spitze bei abgelehnten Aktionen ist anders: Wechsle zum deterministischen Fallback oder tritt keinen neuen Tischen bei, bis der Protokollkonflikt geklärt ist.

Teste das Runbook mit Fehlerinjektion. Trenne während eines Zuges die Netzwerkverbindung. Sende doppelte Events zurück. Verzögere die Policy über ihr Budget hinaus. Lass das Modell fehlerhaftes JSON zurückgeben. Starte den Prozess zwischen hand_start und your_turn neu. Ein Dokument, das keine Übung überstanden hat, ist nur eine Vermutung.

Auch Kosten sind eine betriebliche Einschränkung. Begrenze Modellaufrufe pro Hand, Eingabetokens, Simulations-CPU, Log-Aufbewahrung und Reconnect-Versuche. Der Leitfaden zu Poker-Bot-Kosten bietet ein Planungsmodell. Eine Strategie, die einen kleinen simulierten Vorteil erzielt, aber einen unbegrenzten Remote-Aufruf benötigt, ist nicht für den unbeaufsichtigten Betrieb bereit.

FAQ

Was ist eine professionelle Poker-Bot-Architektur?

Sie ist ein resilientes, beobachtbares und versioniertes System rund um eine Poker-Policy. Dazu gehören autoritative Resynchronisierung, Fristabbruch, Fallback-Stufen, Aktionsvalidierung, Shadow-Evaluation, Release-Kriterien und ein Incident-Runbook.

Wie sollte sich ein Poker-Bot nach einer Verbindungstrennung erholen?

Stelle die Verbindung mit begrenztem Jitter und derselben Identität wieder her, sende resync_request mit dem aktuellen Tisch und der zuletzt verarbeiteten Sequenz, wende wiederholte Events idempotent an und baue anschließend den Zustand aus dem autoritativen Snapshot neu auf, bevor du handelst.

Was sollte passieren, wenn das KI-Modell das Zeitlimit überschreitet?

Brich die Anfrage ab, protokolliere den Timeout und wechsle in der lokalen Fallback-Kaskade eine Stufe nach unten. Prüfe vor dem Senden, ob die aktive Hand und das Turn-Token noch übereinstimmen. Sende niemals ein verspätetes Modellergebnis.

Kann der Shadow-Modus beweisen, dass eine neue Policy gewinnt?

Nein. Der Shadow-Modus belegt, dass die Policy läuft, gültige Ausgaben zurückgibt, Latenzziele einhält und auf bekannte Weise abweicht. Verwende kontrollierte Simulationen und Live-Canaries als Leistungsnachweis.

Wann sollte ein Poker-Bot automatisch zurückgesetzt werden?

Führe einen Rollback bei harten Betriebsfehlern durch, etwa bei Spitzen abgelehnter Aktionen, Abstürzen, Spitzen veralteter Entscheidungen, Schemafehlern oder übermäßig vielen Fallbacks. Strategieergebnisse müssen langsamer geprüft werden, weil Pokervarianz kurze Zeitfenster unzuverlässig macht.

Der professionelle Schritt ist nicht, ein weiteres Modell hinzuzufügen. Er besteht darin, das aktuelle Modell austauschbar, beobachtbar und ausfallsicher zu machen. Registriere dich über den Open-Poker-Quickstart, führe die erste Fehlerinjektionsübung aus und prüfe, ob dein Bot jede optionale Abhängigkeit verlieren kann, ohne die Kontrolle über den Tisch zu verlieren.