Pro Poker Bot Architecture: Resilience और Evaluation

Pro poker bot एक evaluated service है, कोई बड़ा strategy function नहीं। वह बिना guess किए reconnect करता है, stale work discard करता है, dependencies fail होने पर safely degrade होता है और साबित कर सकता है कि हर action किस policy ने बनाया। Strategic ceiling मायने रखती है, लेकिन unattended operation recovery, observability और disciplined releases से जीता जाता है।

Poker bot architecture series: 3 भागों में से भाग 3। भरोसेमंद core Basic Poker Bot Architecture में बनाएँ, फिर Advanced Poker Bot Architecture से equity और replay testing जोड़ें। Runtime का budget Poker Bot Cost in 2026 से बनाएँ।

Pro poker bot को advanced bot से क्या अलग करता है?

Pro poker bot हर component को fallible और हर strategy change को experiment मानता है। Advanced bot equity calculate और opponents के हिसाब से adapt कर सकता है। Pro bot उस calculation के बीच connection खो सकता है, authoritative table state recover कर सकता है, अब stale हो चुके result को reject कर सकता है, safe fallback चुन सकता है और पूरे sequence को explain करने वाली audit trail छोड़ सकता है।

फर्क ownership में दिखता है। एक supervisor session state machine own करता है। Turn coordinator deadlines और cancellation own करता है। Policy workers computation own करते हैं, लेकिन socket पर लिख नहीं सकते। Guard executable actions own करता है। Telemetry path को बदले बिना observe करती है। Release tooling तय करता है कि कौन सी signed, versioned policy traffic पाएगी।

ज्यादा infrastructure अपने-आप professional नहीं होता। हर added system के पीछे ऐसा failure होना चाहिए जिसे वह रोकता है और ऐसा metric जो साबित करे कि वह काम करता है।

Reconnect और resynchronization कैसे काम करने चाहिए?

Strategy resume होने से पहले reconnect को server truth से rebuild करना चाहिए। Last table_id और highest processed table_seq रखें। उसी API key से socket खोलने के बाद, अगर table session अब भी मौजूद हो सकता है तो उन values के साथ resync_request भेजें। Replayed events को sequence में apply करें, फिर fresh snapshot से derived table state replace करें।

Open Poker disconnected seat को 120 seconds तक hold करता है। यह recovery window है, sleep target नहीं। Bounded exponential backoff और jitter के साथ जल्दी retry करें, क्योंकि fixed intervals पर simultaneous client reconnects thundering herd बना सकते हैं। Bot lifecycle guide seat window document करती है और WebSocket protocol resync_request, resync_response और table_state define करता है।

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)

Sequence handling idempotent होनी चाहिए। जिस event का table_seq last applied sequence के बराबर या उससे कम हो, उसे ignore करें। New sequence आगे jump करे तो gap को assumptions से भरने के बजाय resync request करें। Snapshot authoritative है; event log opponent model के लिए जरूरी history देता है।

Deadline budgets stale actions को कैसे रोकते हैं?

Deadline budgets एक turn को measured stages में बाँटते हैं और validation तथा network delivery के लिए time reserve करते हैं। Open Poker अभी automatic check या fold से पहले 120 seconds देता है, लेकिन pro bot को पूरी window consume नहीं करनी चाहिए। Hanging model call useful recovery रोकती है और hands per hour घटाती है।

अपने runtime के हिसाब से internal service objective set करें। Ordinary rules या model calls के लिए 2-second decision budget एक reasonable target है: normalization और features के लिए 100 ms, policy work के लिए 1,500 ms, validation के लिए 100 ms और delivery reserve के लिए 300 ms। Platform timeout outer safety net बना रहता है।

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)

Cancellation propagate होनी चाहिए। Python का asyncio.wait_for overdue work cancel करता है, लेकिन synchronous CPU code event loop को yield नहीं करेगा। Heavy simulations को worker process में चलाएँ या bounded native implementation इस्तेमाल करें। Python की asyncio task documentation cancellation behavior समझाती है। इसे केवल fast unit fixture से नहीं, जानबूझकर hang की गई policy से test करें।

Failure isolation और fallbacks कैसे काम करने चाहिए?

Failure isolation optional intelligence को mandatory play गिराने से रोकता है। Remote models, large equity simulations, opponent storage और analytics exporters को timeouts वाले narrow interfaces के पीछे रखें। चारों down हों तब भी session loop और legal-action guard available रहने चाहिए।

Cost और dependency के क्रम में fallback ladder इस्तेमाल करें:

1. Primary learned या model-assisted policy।
2. Short compute budget वाली local range-and-equity policy।
3. Deterministic position और price rules।
4. Legal हो तो check, वरना fold।

हर नीचे जाने पर labeled metric increment हो और decision record में दिखाई दे। Threshold के बाद circuit breaker failing remote service को call करना बंद करे, cooldown तक wait करे, फिर limited requests से probe करे। एक ही turn में same model को तीन बार retry करना आमतौर पर एक बार fallback करने से बदतर है; इससे latency और charges दोनों multiply हो सकते हैं।

Guard ladder के बाद भी रहता है। Fallback में भी bug हो सकता है। Action membership validate करें, raise-to amounts को server के current minimum और maximum में clamp करें, current hand_id और token require करें और fresh client_action_id बनाएँ। Timeout debugging guide common async और model failure paths cover करती है।

Pro poker bot को कैसी observability चाहिए?

Pro poker bot को decision granularity पर correlated logs, metrics और traces चाहिए। hand_id को poker correlation key और client_action_id को action-delivery key बनाएँ। Session ID, table ID, turn token hash, policy version, feature schema version, model version, prompt version, range version और code revision जोड़ें।

Private credentials record न करें और raw hole cards broad third-party telemetry को न भेजें। Protected decision logs और replay fixtures में hole cards जरूरी हैं, लेकिन access और retention deliberate होने चाहिए। Public dashboards वाले logs में उन्हें aggregate या redact करें।

Core service-level indicators ये हैं:

Average latency के बजाय histograms prefer करें। एक 40-second model call low mean में गायब हो सकती है, फिर भी stale response पैदा कर सकती है। OpenTelemetry की metrics specification और trace specification vendor-neutral concepts देती हैं। Day one पर large observability stack जरूरी नहीं, लेकिन stable names और units रखें ताकि dashboards archaeology न बन जाएँ।

Shadow policies और counterfactual evaluation कैसे काम करते हैं?

Shadow policy active policy वाला same immutable snapshot देखती है, लेकिन action भेज नहीं सकती। उसका proposed action, size, confidence, latency और features live decision के साथ record करें। इससे chips या protocol correctness को risk में डाले बिना integration और behavioral difference test होते हैं।

Shadow results direct win-rate evidence नहीं हैं। Shadow fold चुनती है और active policy call, तो बाकी observed hand call branch पर चलता है। आप यह pretend नहीं कर सकते कि shadow का fold बाद का result लाया। Shadowing से action agreement, latency, schema errors और coverage measure करें। Counterfactual value के लिए simulator, solver comparison या off-policy method इस्तेमाल करें।

Local game research के लिए OpenSpiel में imperfect-information games के algorithms और environments हैं। उसका 2019 paper framework के evaluation goals समझाता है। Live changes के लिए shadow checks को replay suites और canary cohort के साथ मिलाएँ।

Useful promotion report में शामिल हैं:

• street और position के हिसाब से action agreement;
• बड़े sizing disagreements;
• schema और legality failure rates;
• p50, p95 और p99 latency;
• VPIP, PFR और river call rate जैसे behavior metrics;
• uncertainty के साथ paired simulation result;
• opponent cohort और hand count के साथ live canary result।

हम policy इसलिए promote नहीं करते कि उसकी explanations ज्यादा smart लगती हैं। हम उसे इसलिए promote करते हैं क्योंकि correctness और latency gates green रखते हुए behavior intended direction में बदला।

Policy releases और rollback कैसे काम करने चाहिए?

Policy releases immutable, versioned और reversible होने चाहिए। Code revision, feature schema, range data, prompt text, model identifier, evaluator version और configuration को एक release manifest में package करें। Decision log manifest ID store करे, ताकि कोई भी hand उसी exact policy के नीचे replay किया जा सके जिसने action लिया था।

Explicit gates वाला release path इस्तेमाल करें:

1. Legal-action invariants समेत unit और property tests pass हों।
2. Recorded hand replays reviewed diffs बनाएँ।
3. Long simulation कोई memory या latency regression न दिखाए।
4. Shadow mode schema, coverage और latency gates pass करे।
5. छोटा live canary नया version पाए।
6. Automated rollback rejection, fallback, stale-decision और crash thresholds देखे।
7. पर्याप्त hands जमा होने के बाद ही strategy performance review हो।

Operational rollback तेज और poker variance से independent होना चाहिए। एक illegal-action spike तुरंत rollback कर सकता है। bb/100 dip आमतौर पर नहीं, क्योंकि short samples noisy हैं। Hard health gates को slow performance gates से अलग रखें।

State compatibility पर खास ध्यान दें। New opponent model stored feature names बदले तो data migrate करें या reader version करें। जो rollback कल की state पढ़ न सके, वह rollback नहीं है। हम append-only raw observations prefer करते हैं, जिनसे derived features version के हिसाब से rebuild होते हैं। Storage ज्यादा लगता है, लेकिन strategy changes history corrupt करना बंद कर देते हैं।

Poker performance को खुद को धोखा दिए बिना कैसे measure करें?

Poker performance को uncertainty, controlled comparisons और behavior diagnostics के साथ measure करें। Sample size और confidence interval के साथ big blinds per 100 hands report करें। Policy version, table size, position और opponent cohort के हिसाब से segment करें। Raw season chips competition के लिए मायने रखते हैं, लेकिन अलग buy-ins या blind exposure वाले runs की stable comparison नहीं हैं।

Short samples झूठ बोलते हैं। Bot कई all-ins जीत सकता है जबकि लगातार negative-expectation lines ले रहा हो। Showdown और all-in diagnostics track करें, लेकिन adjusted metric को भी ground truth न मानें। Opponent models drift करते हैं, multiway pots estimates को complicate करते हैं और live policies उस data को बदलती हैं जिससे वे बाद में सीखती हैं।

तीन evidence sources इस्तेमाल करें:

Results देखने से पहले experiment question set करें। “Timeout fallbacks बढ़ाए बिना equity below price वाले river calls को 30% घटाना” testable है। “Bot को ज्यादा GTO बनाना” testable नहीं। Zero-to-leaderboard plan iteration cadence के लिए useful है, जबकि stack management उन risk measures को cover करता है जिन्हें chip totals अकेले miss करते हैं।

Production runbook में क्या होना चाहिए?

Production runbook में authentication failures, reconnect loops, resync gaps, action rejection spikes, model outages, slow decisions, corrupted state, low balance और season transitions के लिए specific actions होने चाहिए। हर alert में owner action, safe fallback और normal पर लौटने से पहले जरूरी evidence लिखा हो।

उदाहरण के लिए, केवल एक call fail होने से model outage को किसी को page नहीं करना चाहिए। Circuit breaker open होता है, local policy control लेती है और fallback rate sustained window तक threshold से ऊपर रहे तो alert fire होता है। Action rejection spike अलग है: deterministic fallback पर जाएँ या protocol mismatch समझ आने तक rejoin रोकें।

Fault injection से runbook test करें। Turn के बीच network kill करें। Duplicate events लौटाएँ। Policy को budget से आगे delay करें। Model से malformed JSON return कराएँ। Process को hand_start और your_turn के बीच restart करें। जो document rehearsal survive नहीं कर पाया, वह केवल guess है।

Cost भी operational constraint है। Per hand model calls, token input, simulation CPU, log retention और reconnect attempts bound करें। Poker bot cost guide planning model देती है। Tiny simulated edge कमाने वाली लेकिन unbounded remote call मांगने वाली strategy unattended play के लिए ready नहीं है।

FAQ

Pro poker bot architecture क्या है?

यह poker policy के चारों ओर resilient, observable और versioned service है। इसमें authoritative resync, deadline cancellation, fallback tiers, action guards, shadow evaluation, release gates और incident runbook शामिल हैं।

Disconnect होने के बाद poker bot को कैसे recover करना चाहिए?

Bounded jitter के साथ reconnect करें, same identity इस्तेमाल करें, current table और last processed sequence के साथ resync_request भेजें, replayed events idempotently apply करें, फिर action लेने से पहले authoritative snapshot से rebuild करें।

AI model timeout हो तो क्या होना चाहिए?

Request cancel करें, timeout record करें और local fallback ladder में नीचे जाएँ। भेजने से पहले confirm करें कि active hand और turn token अब भी match करते हैं। Late model result कभी न भेजें।

क्या shadow mode साबित कर सकता है कि नई policy जीतती है?

नहीं। Shadow mode साबित करता है कि policy चलती है, valid output लौटाती है, latency targets meet करती है और known ways में अलग है। Performance evidence के लिए controlled simulation और live canaries इस्तेमाल करें।

Poker bot को automatically rollback कब करना चाहिए?

Action rejection spikes, crashes, stale-decision spikes, schema failures या excessive fallbacks जैसे hard operational failures पर rollback करें। Strategy results को slower review चाहिए, क्योंकि poker variance short windows को unreliable बनाता है।

Pro move एक और model जोड़ना नहीं है। यह मौजूदा model को replaceable, observable और failure में safe बनाना है। Open Poker quickstart से register करें, पहला fault-injection drill run करें और देखें कि क्या आपका bot table का control खोए बिना हर optional dependency खो सकता है।