Architecture d’un bot de poker professionnel : résilience et évaluation

Un bot de poker professionnel est un service évalué, pas une grosse fonction stratégique. Il se reconnecte sans faire d’hypothèses, abandonne le travail périmé, se replie en sécurité lorsque ses dépendances échouent et peut prouver quelle politique a produit chaque action. Le potentiel stratégique compte, mais une exploitation sans surveillance repose sur la récupération, l’observabilité et la rigueur des déploiements.

Série sur l’architecture des bots de poker : partie 3 sur 3. Construisez le socle fiable dans Architecture d’un bot de poker débutant, puis ajoutez l’équité et les tests par replay avec Architecture d’un bot de poker avancé. Budgétez le runtime avec Coût d’un bot de poker en 2026.

Qu’est-ce qui distingue un bot professionnel d’un bot avancé ?

Un bot professionnel considère chaque composant comme faillible et chaque modification stratégique comme une expérience. Le bot avancé sait calculer l’équité et s’adapter aux adversaires. Le bot professionnel peut perdre sa connexion pendant ce calcul, récupérer l’état de référence de la table, rejeter le résultat désormais périmé, choisir un repli sûr et produire une piste d’audit expliquant toute la séquence.

La différence tient aux responsabilités. Un superviseur possède la machine à états de la session. Un coordinateur de tours gère échéances et annulations. Les workers de politique calculent, mais ne peuvent pas écrire sur la socket. Un garde-fou possède les actions exécutables. La télémétrie observe le parcours sans le modifier. L’outillage de publication décide quelle politique signée et versionnée reçoit du trafic.

Davantage d’infrastructure n’est pas automatiquement professionnel. Chaque système ajouté doit correspondre à une défaillance évitée et à une métrique qui le prouve.

Comment gérer reconnexion et resynchronisation ?

La reconnexion doit reconstruire l’état à partir de la vérité du serveur avant de reprendre la stratégie. Conservez le dernier table_id et le plus grand table_seq traité. Après avoir rouvert la socket avec la même clé API, envoyez resync_request avec ces valeurs si une session de table peut encore exister. Appliquez les événements rejoués dans l’ordre, puis remplacez l’état dérivé par le nouvel instantané.

Open Poker conserve le siège d’un joueur déconnecté pendant 120 secondes. C’est une fenêtre de récupération, pas une durée d’attente cible. Réessayez rapidement avec un backoff exponentiel borné et de l’aléa, car des clients se reconnectant simultanément à intervalles fixes peuvent produire un afflux massif. Le guide du cycle de vie d’un bot documente cette fenêtre, et le protocole WebSocket définit resync_request, resync_response et 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)

Le traitement des séquences doit être idempotent. Ignorez tout événement dont table_seq est inférieur ou égal à la dernière séquence appliquée. Si une nouvelle séquence saute une valeur, demandez une resynchronisation au lieu de combler le vide par des suppositions. L’instantané fait autorité; le journal d’événements fournit l’historique nécessaire au modèle adverse.

Comment les budgets d’échéance empêchent-ils les actions périmées ?

Les budgets d’échéance divisent un tour en étapes mesurées et réservent du temps à la validation et à la livraison réseau. Open Poker autorise actuellement 120 secondes avant un check ou un fold automatique, mais un bot professionnel ne doit pas consommer toute cette fenêtre. Un appel de modèle bloqué empêche une récupération utile et réduit le nombre de mains par heure.

Définissez un objectif interne adapté à votre runtime. Une cible raisonnable est un budget de 2 secondes pour les règles ordinaires ou les appels de modèle : 100 ms pour la normalisation et les caractéristiques, 1 500 ms pour la politique, 100 ms pour la validation et une réserve de 300 ms pour la livraison. Le délai de la plateforme reste un ultime filet de sécurité.

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)

L’annulation doit se propager. asyncio.wait_for annule un travail en retard, mais du code CPU synchrone ne rend pas la main à la boucle d’événements. Exécutez les simulations lourdes dans un processus worker ou utilisez une implémentation native bornée. La documentation des tâches asyncio explique l’annulation. Testez-la avec une politique volontairement bloquée, pas uniquement avec une fixture rapide.

Comment isoler les défaillances et organiser les replis ?

L’isolation empêche l’intelligence facultative de neutraliser le jeu obligatoire. Placez modèles distants, grandes simulations d’équité, stockage adverse et exportateurs analytiques derrière des interfaces étroites avec timeout. La boucle de session et le garde-fou doivent rester disponibles lorsque les quatre sont en panne.

Utilisez une échelle de repli classée par coût et dépendances :

1. Politique principale apprise ou assistée par modèle.
2. Politique locale de range et d’équité avec budget de calcul court.
3. Règles déterministes de position et de prix.
4. Check si légal, sinon fold.

Chaque descente incrémente une métrique étiquetée et apparaît dans l’enregistrement de décision. Un disjoncteur doit cesser d’appeler un service distant défaillant après un seuil, attendre une période de refroidissement, puis le sonder avec peu de requêtes. Réessayer trois fois le même modèle pendant un tour est généralement pire qu’un seul repli : cela cumule la latence et peut multiplier les frais.

Le garde-fou reste placé après l’échelle, car un repli peut aussi contenir un bug. Validez l’appartenance de l’action, bornez les montants de relance aux minimum et maximum actuels du serveur, exigez les hand_id et jeton actuels, et générez un nouveau client_action_id. Le guide de débogage des délais couvre les défaillances asynchrones et de modèles les plus courantes.

De quelle observabilité un bot professionnel a-t-il besoin ?

Il lui faut des journaux, métriques et traces corrélés à l’échelle de la décision. Utilisez hand_id comme clé de corrélation poker et client_action_id comme clé de livraison. Ajoutez identifiants de session et de table, hash du jeton, versions de politique, schéma de caractéristiques, modèle, prompt et range, ainsi que la révision du code.

N’enregistrez ni identifiants privés ni cartes privatives brutes dans une télémétrie tierce largement accessible. Ces cartes sont nécessaires dans les journaux protégés et les fixtures, mais leur accès et leur conservation doivent être intentionnels. Les tableaux de bord publics doivent les agréger ou les masquer.

Préférez les histogrammes à la latence moyenne. Un appel de 40 secondes disparaît dans une moyenne basse, mais peut encore produire une réponse périmée. Les spécifications OpenTelemetry sur les métriques et les traces fournissent des concepts indépendants des fournisseurs. Une grosse plateforme n’est pas nécessaire dès le premier jour, mais conservez des noms et unités stables.

Comment fonctionnent les politiques fantômes et l’évaluation contrefactuelle ?

Une politique fantôme reçoit le même instantané immuable que la politique active, mais ne peut pas envoyer d’action. Consignez sa proposition, son montant, sa confiance, sa latence et ses caractéristiques à côté de la décision réelle. Cela teste l’intégration et les différences de comportement sans risquer de jetons ni la correction du protocole.

Les résultats fantômes ne prouvent pas directement le taux de gain. Si la politique fantôme choisit fold alors que l’active suit, la suite observée appartient à la branche du call. Vous ne pouvez pas prétendre que le fold fantôme a causé le résultat ultérieur. Utilisez le mode fantôme pour mesurer accord des actions, latence, erreurs de schéma et couverture. Utilisez un simulateur, une comparaison à un solveur ou une méthode hors politique pour la valeur contrefactuelle.

Pour la recherche locale, OpenSpiel comprend des algorithmes et environnements pour jeux à information imparfaite. Son article de 2019 explique les objectifs d’évaluation du cadre. Pour les modifications en direct, associez contrôles fantômes, suites de replay et cohorte canari.

Un rapport de promotion utile comprend :

• l’accord des actions par street et position;
• les grands écarts de sizing;
• les taux d’échec de schéma et de légalité;
• les latences p50, p95 et p99;
• les métriques comportementales comme VPIP, PFR et taux de call river;
• le résultat de simulation appariée avec son incertitude;
• le résultat canari en direct avec cohorte adverse et nombre de mains.

Nous ne promouvons pas une politique parce que ses explications semblent plus intelligentes. Nous la promouvons parce que le comportement évolue comme prévu tandis que correction et latence restent au vert.

Comment gérer les publications de politique et le retour arrière ?

Les publications doivent être immuables, versionnées et réversibles. Regroupez révision du code, schéma de caractéristiques, données de range, prompt, identifiant du modèle, version de l’évaluateur et configuration dans un manifeste. Le journal de décision conserve l’identifiant du manifeste afin de rejouer chaque main sous la politique exacte qui a agi.

Suivez un parcours avec des critères explicites :

1. Les tests unitaires et de propriétés réussissent, notamment les invariants d’action légale.
2. Les replays de mains enregistrées produisent des différences relues.
3. Une longue simulation ne révèle aucune régression de mémoire ou de latence.
4. Le mode fantôme respecte les critères de schéma, couverture et latence.
5. Une petite cohorte canari reçoit la nouvelle version.
6. Le retour arrière automatique surveille les seuils de refus, replis, décisions périmées et crashs.
7. Les performances stratégiques ne sont examinées qu’après l’accumulation de suffisamment de mains.

Le retour arrière opérationnel doit être rapide et indépendant de la variance. Un pic d’actions illégales peut déclencher un retour immédiat. Une baisse de bb/100 ne le peut généralement pas, car les petits échantillons sont bruités. Séparez les critères stricts de santé des critères lents de performance.

La compatibilité de l’état mérite une attention particulière. Si un nouveau modèle adverse renomme ses caractéristiques persistées, migrez les données ou versionnez le lecteur. Un retour arrière incapable de lire l’état d’hier n’en est pas un. Nous préférons des observations brutes en ajout seul et des caractéristiques dérivées reconstruites par version. Le stockage coûte davantage, mais les changements stratégiques ne corrompent plus l’historique.

Comment mesurer les performances sans se tromper soi-même ?

Mesurez avec incertitude, comparaisons contrôlées et diagnostics comportementaux. Publiez les grosses blindes par 100 mains avec taille d’échantillon et intervalle de confiance. Segmentez par version, taille de table, position et cohorte adverse. Les jetons bruts comptent pour la compétition, mais ne permettent pas une comparaison stable entre des sessions aux buy-ins ou expositions aux blindes différents.

Les petits échantillons mentent. Un bot peut gagner plusieurs all-ins tout en choisissant systématiquement des lignes à espérance négative. Suivez les diagnostics d’abattage et d’all-in, sans prendre une métrique ajustée pour la vérité absolue. Les modèles adverses dérivent, les pots multiway compliquent les estimations et les politiques modifient les données dont elles apprennent ensuite.

Définissez la question avant d’examiner les résultats. « Réduire de 30 % les calls river dont l’équité est inférieure au prix sans augmenter les replis dus au délai » est testable. « Rendre le bot plus GTO » ne l’est pas. Le plan de zéro au classement en sept jours aide à fixer le rythme, tandis que la gestion du tapis couvre des mesures de risque ignorées par le total de jetons.

Que doit contenir le runbook de production ?

Il doit prescrire des actions précises en cas d’échec d’authentification, boucle de reconnexion, trou de resynchronisation, pic de refus, panne du modèle, lenteur des décisions, état corrompu, solde faible et changement de saison. Chaque alerte doit indiquer une action responsable, un repli sûr et les preuves nécessaires au retour à la normale.

Une panne du modèle ne doit pas déclencher d’astreinte après un seul appel. Le disjoncteur s’ouvre, la politique locale prend le relais et une alerte se déclenche si le taux de repli reste durablement supérieur à un seuil. Un pic de refus est différent : passez au repli déterministe ou cessez de rejoindre des tables jusqu’à comprendre l’incompatibilité du protocole.

Testez le runbook par injection de pannes. Coupez le réseau pendant un tour. Renvoyez des événements dupliqués. Retardez la politique au-delà de son budget. Faites renvoyer au modèle un JSON mal formé. Redémarrez entre hand_start et your_turn. Un document qui n’a pas survécu à une répétition n’est qu’une hypothèse.

Le coût est aussi une contrainte opérationnelle. Bornez les appels de modèle par main, les jetons d’entrée, le CPU de simulation, la conservation des journaux et les tentatives de reconnexion. Le guide du coût d’un bot de poker propose un modèle de planification. Une stratégie au léger avantage simulé qui exige un appel distant non borné n’est pas prête à fonctionner seule.

FAQ

Qu’est-ce qu’une architecture professionnelle de bot de poker ?

C’est un service résilient, observable et versionné qui entoure une politique de poker. Il inclut resynchronisation de référence, annulation à l’échéance, niveaux de repli, garde-fous, évaluation fantôme, critères de publication et runbook d’incident.

Comment récupérer après une déconnexion ?

Reconnectez-vous avec un aléa borné et la même identité, envoyez resync_request avec la table actuelle et la dernière séquence traitée, appliquez les événements rejoués de manière idempotente, puis reconstruisez l’état depuis l’instantané de référence avant d’agir.

Que faire lorsque le modèle d’IA dépasse le délai ?

Annulez la requête, consignez le dépassement et descendez l’échelle de repli locale. Avant tout envoi, vérifiez que la main et le jeton actifs correspondent toujours. N’envoyez jamais un résultat tardif.

Le mode fantôme peut-il prouver qu’une politique gagne ?

Non. Il prouve que la politique s’exécute, renvoie une sortie valide, respecte la latence et diffère de façon connue. Utilisez simulation contrôlée et canaris en direct pour les performances.

Quand faut-il déclencher un retour arrière automatique ?

Lors de défaillances opérationnelles strictes : pics de refus, crashs, décisions périmées, erreurs de schéma ou replis excessifs. Les résultats stratégiques exigent une analyse plus lente, car la variance rend les courtes périodes peu fiables.

La démarche professionnelle ne consiste pas à ajouter un autre modèle, mais à rendre le modèle actuel remplaçable, observable et sûr en cas de panne. Inscrivez-vous avec le quickstart Open Poker, exécutez un premier exercice d’injection de panne et vérifiez si votre bot peut perdre toutes ses dépendances facultatives sans perdre le contrôle de la table.