Arquitectura profesional de un bot de póquer: resiliencia y evaluación

Un bot de póquer profesional es un servicio evaluado, no una gran función de estrategia. Se reconecta sin hacer suposiciones, descarta el trabajo obsoleto, se degrada de forma segura cuando fallan las dependencias y puede demostrar qué política produjo cada acción. El techo estratégico importa, pero el funcionamiento sin supervisión se gana mediante recuperación, observabilidad y lanzamientos disciplinados.

Serie sobre arquitectura de bots de póquer: Parte 3 de 3. Construye el núcleo fiable en Arquitectura básica de un bot de póquer y después añade equity y pruebas de repetición con Arquitectura avanzada de un bot de póquer. Presupuesta el entorno de ejecución con Coste de un bot de póquer en 2026.

¿Qué distingue a un bot de póquer profesional de uno avanzado?

Un bot de póquer profesional considera que todos los componentes pueden fallar y que cada cambio de estrategia es un experimento. El bot avanzado puede calcular la equity y adaptarse a los rivales. El bot profesional puede perder la conexión durante ese cálculo, recuperar el estado autoritativo de la mesa, rechazar el resultado ya obsoleto, elegir una alternativa segura y dejar un registro de auditoría que explique la secuencia.

La diferencia se aprecia en las responsabilidades. Un supervisor es responsable de la máquina de estados de la sesión. Un coordinador de turnos se ocupa de los plazos y la cancelación. Los procesos de política se encargan del cálculo, pero no pueden escribir en el socket. Un control se ocupa de las acciones ejecutables. La telemetría observa la ruta sin cambiarla. Las herramientas de lanzamiento deciden qué política firmada y versionada recibe tráfico.

Más infraestructura no es automáticamente más profesional. Cada sistema añadido necesita un fallo que evite y una métrica que demuestre que funciona.

¿Cómo deben funcionar la reconexión y la resincronización?

La reconexión debe reconstruir el estado a partir de la verdad del servidor antes de reanudar la estrategia. Conserva el último table_id y el mayor table_seq procesado. Después de abrir el socket con la misma clave de API, envía resync_request con esos valores cuando todavía pueda existir una sesión en la mesa. Aplica los eventos repetidos en orden y después sustituye el estado derivado de la mesa por el de la nueva instantánea.

Open Poker conserva el asiento desconectado durante 120 segundos. Es una ventana de recuperación, no un objetivo de espera. Reintenta pronto con backoff exponencial limitado y jitter, porque varios clientes que se reconecten a intervalos fijos pueden provocar una avalancha de solicitudes. La guía del ciclo de vida del bot documenta la ventana del asiento, y el protocolo WebSocket define resync_request, resync_response y 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)

La gestión de secuencias debe ser idempotente. Ignora un evento cuyo table_seq sea igual o inferior a la última secuencia aplicada. Si una secuencia nueva da un salto hacia delante, solicita una resincronización en lugar de rellenar el hueco con suposiciones. La instantánea es autoritativa; el registro de eventos proporciona el historial que necesita el modelo de rivales.

¿Cómo evitan las acciones obsoletas los presupuestos de plazos?

Los presupuestos de plazos dividen un turno en etapas medidas y reservan tiempo para la validación y la entrega por red. En la actualidad, Open Poker concede 120 segundos antes de efectuar automáticamente un check o un fold, pero un bot profesional no debe consumir toda esa ventana. Una llamada al modelo bloqueada impide una recuperación útil y reduce el número de manos por hora.

Define un objetivo interno de servicio según tu entorno de ejecución. Un objetivo razonable es un presupuesto de decisión de 2 segundos para reglas normales o llamadas a modelos, dividido en 100 ms para normalización y características, 1.500 ms para el trabajo de la política, 100 ms para validación y 300 ms de reserva para la entrega. El tiempo de espera de la plataforma sigue siendo una red de seguridad externa.

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)

La cancelación debe propagarse. asyncio.wait_for de Python cancela el trabajo que supera el plazo, pero el código síncrono que usa intensivamente la CPU no cede el control al bucle de eventos. Ejecuta las simulaciones pesadas en un proceso de trabajo o usa una implementación nativa limitada. La documentación de tareas de asyncio de Python explica el comportamiento de la cancelación. Pruébalo con una política bloqueada de forma intencionada, no solo con un caso unitario rápido.

¿Cómo deben funcionar el aislamiento de fallos y las alternativas?

El aislamiento de fallos evita que la inteligencia opcional derribe el juego obligatorio. Coloca los modelos remotos, las simulaciones de equity grandes, el almacenamiento de rivales y los exportadores de analítica detrás de interfaces estrechas con tiempos de espera. El bucle de sesión y el control de acciones legales deben seguir disponibles cuando los cuatro fallen.

Usa una escala de alternativas, ordenada por coste y dependencia:

1. Política principal aprendida o asistida por un modelo.
2. Política local de rangos y equity con un presupuesto de cálculo corto.
3. Reglas deterministas de posición y precio.
4. Check cuando sea legal y, en caso contrario, fold.

Cada descenso incrementa una métrica etiquetada y aparece en el registro de la decisión. Un disyuntor debe dejar de llamar a un servicio remoto que falle después de alcanzar un umbral, esperar durante un periodo de enfriamiento y después probarlo con solicitudes limitadas. Reintentar el mismo modelo tres veces dentro de un turno suele ser peor que recurrir una vez a la alternativa; acumula latencia y puede multiplicar los cargos.

El control permanece después de la escala. Una alternativa también puede contener un error. Valida que la acción figure en la lista, limita los importes de subida hasta los valores mínimo y máximo actuales del servidor, exige el hand_id y el token vigentes, y genera un client_action_id nuevo. La guía de depuración de tiempos de espera aborda rutas habituales de fallos asíncronos y del modelo.

¿Qué observabilidad necesita un bot de póquer profesional?

Un bot de póquer profesional necesita registros, métricas y trazas correlacionados con granularidad de decisión. Usa hand_id como clave de correlación de póquer y client_action_id como clave de entrega de la acción. Añade el identificador de sesión, el identificador de mesa, el hash del token de turno, la versión de la política, la versión del esquema de características, la versión del modelo, la versión del prompt, la versión del rango y la revisión del código.

No registres credenciales privadas ni envíes las cartas propias sin procesar a servicios amplios de telemetría de terceros. Las cartas propias son necesarias en registros de decisiones protegidos y casos de repetición, pero su acceso y conservación deben ser deliberados. Los registros usados para paneles públicos deben agregarlas u ocultarlas.

Los indicadores principales del nivel de servicio son:

Prefiere los histogramas a la latencia media. Una llamada al modelo de 40 segundos desaparece dentro de una media baja, pero aún puede provocar una respuesta obsoleta. La especificación de métricas y la especificación de trazas de OpenTelemetry proporcionan conceptos independientes del proveedor. No necesitas una gran plataforma de observabilidad desde el primer día, pero conserva nombres y unidades estables para que los paneles no se conviertan en arqueología.

¿Cómo funcionan las políticas en modo sombra y la evaluación contrafactual?

Una política en modo sombra ve la misma instantánea inmutable que la política activa, pero no puede enviar una acción. Registra su acción propuesta, tamaño, confianza, latencia y características junto a la decisión en vivo. Esto prueba la integración y las diferencias de comportamiento sin arriesgar fichas ni la corrección del protocolo.

Los resultados en modo sombra no son evidencia directa de la tasa de ganancias. Si la política en modo sombra elige un fold mientras la política activa paga, el resto de la mano observada sigue la rama del call. No puedes fingir que el fold de la política en modo sombra causó el resultado posterior. Usa el modo sombra para medir la coincidencia de acciones, la latencia, los errores de esquema y la cobertura. Usa un simulador, la comparación con un solver o un método off-policy para estimar el valor contrafactual.

Para la investigación local de juegos, OpenSpiel incluye algoritmos y entornos para juegos de información imperfecta. Su artículo de 2019 explica los objetivos de evaluación del marco. Para cambios en vivo, combina las comprobaciones en modo sombra con conjuntos de repeticiones y una cohorte canary.

Un informe útil de promoción incluye:

• coincidencia de acciones por calle y posición;
• grandes discrepancias de tamaño;
• tasas de fallos de esquema y legalidad;
• latencia p50, p95 y p99;
• métricas de comportamiento como VPIP, PFR y tasa de call en el river;
• resultado de simulación emparejada con incertidumbre;
• resultado del canary en vivo con cohorte de rivales y número de manos.

No promocionamos una política porque sus explicaciones parezcan más inteligentes. La promocionamos porque el comportamiento se ha movido en la dirección deseada mientras los criterios de corrección y latencia siguen en verde.

¿Cómo deben funcionar los lanzamientos de políticas y las reversiones?

Los lanzamientos de políticas deben ser inmutables, estar versionados y ser reversibles. Empaqueta la revisión del código, el esquema de características, los datos de rangos, el texto del prompt, el identificador del modelo, la versión del evaluador y la configuración en un único manifiesto de lanzamiento. El registro de decisiones almacena el identificador del manifiesto, de modo que cualquier mano pueda repetirse con la política exacta que actuó.

Usa una ruta de lanzamiento con criterios explícitos:

1. Las pruebas unitarias y de propiedades se superan, incluidos los invariantes de las acciones legales.
2. Las repeticiones de manos registradas producen diferencias revisadas.
3. Una simulación larga no muestra regresiones de memoria ni latencia.
4. El modo sombra cumple los criterios de esquema, cobertura y latencia.
5. Una pequeña cohorte canary en vivo recibe la versión nueva.
6. La reversión automática vigila los umbrales de rechazos, alternativas, decisiones obsoletas y fallos.
7. El rendimiento de la estrategia se revisa solo después de acumular suficientes manos.

La reversión operativa debe ser rápida e independiente de la varianza del póquer. Un solo pico de acciones ilegales puede activar una reversión inmediata. Una caída del bb/100 normalmente no puede hacerlo, porque las muestras cortas son ruidosas. Separa los criterios estrictos de estado de los criterios lentos de rendimiento.

La compatibilidad del estado merece una atención especial. Si un nuevo modelo de rivales cambia los nombres de las características almacenadas, migra los datos o versiona el lector. Una reversión que no puede leer el estado de ayer no es una reversión. Preferimos observaciones brutas de solo adición y características derivadas que se reconstruyan por versión. Cuesta más almacenamiento, pero los cambios de estrategia dejan de corromper el historial.

¿Cómo se mide el rendimiento en el póquer sin engañarse?

Mide el rendimiento en el póquer con incertidumbre, comparaciones controladas y diagnósticos de comportamiento. Informa de las ciegas grandes por cada 100 manos con el tamaño de la muestra y un intervalo de confianza. Segmenta por versión de la política, tamaño de la mesa, posición y cohorte de rivales. Las fichas brutas de la temporada importan para la competición, pero no son una comparación estable entre ejecuciones con diferentes entradas o exposición a las ciegas.

Las muestras cortas mienten. Un bot puede ganar varios all-ins mientras toma sistemáticamente líneas con expectativa negativa. Registra los diagnósticos del showdown y de los all-ins, pero tampoco confundas una métrica ajustada con la verdad absoluta. Los modelos de rivales derivan, los botes multiway complican las estimaciones y las políticas en vivo cambian los datos de los que después aprenden.

Usa tres fuentes de evidencia:

Define la pregunta del experimento antes de ver los resultados. «Reducir un 30% los calls en el river con una equity inferior al precio sin aumentar las alternativas por tiempo de espera» se puede probar. «Hacer que el bot sea más GTO» no. El plan de cero a la clasificación en 7 días resulta útil para establecer el ritmo de iteración, mientras que la gestión del stack aborda medidas de riesgo que los totales de fichas por sí solos no reflejan.

¿Qué debe incluir el runbook de producción?

El runbook de producción necesita acciones concretas ante fallos de autenticación, bucles de reconexión, huecos de resincronización, picos de acciones rechazadas, caídas del modelo, decisiones lentas, estado corrupto, saldo bajo y transiciones de temporada. Cada alerta debe indicar una acción del responsable, una alternativa segura y la evidencia necesaria antes de volver a la normalidad.

Por ejemplo, una caída del modelo no debe avisar a alguien solo porque haya fallado una llamada. El disyuntor se abre, la política local toma el relevo y se activa una alerta si la tasa de alternativas permanece por encima de un umbral durante un periodo sostenido. Un pico de acciones rechazadas es distinto: cambia a la alternativa determinista o deja de volver al lobby hasta entender la incompatibilidad del protocolo.

Prueba el runbook con inyección de fallos. Corta la red durante un turno. Devuelve eventos duplicados. Retrasa la política más allá de su presupuesto. Haz que el modelo devuelva JSON no válido. Reinicia el proceso entre hand_start y your_turn. Un documento que no ha superado un ensayo es solo una suposición.

El coste también es una restricción operativa. Limita las llamadas al modelo por mano, los tokens de entrada, la CPU de simulación, la conservación de registros y los intentos de reconexión. La guía de costes de bots de póquer ofrece un modelo de planificación. Una estrategia que obtiene una ventaja simulada mínima, pero necesita una llamada remota sin límites, no está preparada para funcionar sin supervisión.

Preguntas frecuentes

¿Qué es una arquitectura profesional de un bot de póquer?

Es un servicio resiliente, observable y versionado en torno a una política de póquer. Incluye resincronización autoritativa, cancelación por plazo, niveles alternativos, controles de acciones, evaluación en modo sombra, criterios de lanzamiento y un runbook de incidentes.

¿Cómo debe recuperarse un bot de póquer después de desconectarse?

Vuelve a conectarte con jitter limitado, usa la misma identidad, envía resync_request con la mesa actual y la última secuencia procesada, aplica los eventos repetidos de forma idempotente y después reconstruye el estado desde la instantánea autoritativa antes de actuar.

¿Qué debe ocurrir cuando el modelo de IA supera el tiempo de espera?

Cancela la solicitud, registra el tiempo de espera y desciende por una escala de alternativas locales. Antes de enviar, confirma que la mano activa y el token de turno siguen coincidiendo. Nunca envíes un resultado tardío del modelo.

¿Puede el modo sombra demostrar que una política nueva gana?

No. El modo sombra demuestra que la política se ejecuta, devuelve una salida válida, cumple los objetivos de latencia y presenta diferencias conocidas. Usa simulaciones controladas y canaries en vivo como evidencia de rendimiento.

¿Cuándo debe revertirse automáticamente un bot de póquer?

Revierte ante fallos operativos estrictos, como picos de acciones rechazadas, bloqueos, picos de decisiones obsoletas, fallos de esquema o un uso excesivo de alternativas. Los resultados de estrategia necesitan una revisión más lenta porque la varianza del póquer hace que las ventanas cortas sean poco fiables.

La decisión profesional no consiste en añadir otro modelo. Consiste en hacer que el actual sea sustituible, observable y seguro ante fallos. Regístrate mediante el inicio rápido de Open Poker, ejecuta el primer ejercicio de inyección de fallos y comprueba si tu bot puede perder todas las dependencias opcionales sin perder el control de la mesa.