WikifitaGitHub live67e8de5
pesquisa · kaggle/pokemon_tcg_action_coverage

Pokemon TCG AI Battle — Action Coverage and Runtime Parity

Historical deterministic legal-action enumeration, bounded full-domain sampling, sidecar schema, and parity between offline prospective groups and the then-current runtime search.

Baixar raw

Pokemon TCG AI Battle — Action Coverage and Runtime Parity

Evidence Boundary

This page reflects the historical rl/prospective_actions.py sidecar builder, the then-current PyTorch runtime planner, and commit 10c3750, which fixed prospective reward balancing and action coverage. The transcript later records serial/parallel byte-for-byte equivalence as observed validation evidence, but competition impact remains unmeasured. The separate sidecar was removed at a942373; this page is retained for method and provenance, not as a current runtime contract.

Candidate Enumeration

The shared enumeration function resolves a complete legal action tuple, not only a single option index. This matters for multi-select decisions because an action can contain zero, one, or several selected option indices depending on the engine's minCount and maxCount.

If the legal combination count is at most max_branches, every legal combination is emitted. If the domain is larger, the sampler chooses evenly spaced lexicographic ranks across the full legal domain, including both endpoints. This removed the old prefix bias while preserving deterministic bounded cost.

legal combinations <= max_branches
    -> enumerate all combinations

legal combinations > max_branches
    -> sample ranks from the whole combination domain
    -> include first and last legal ranks
    -> keep output deterministic

The current default is max_branches=64. That is a compute budget, not a claim that every huge action domain is fully enumerated. The invariant is full-domain coverage by deterministic rank sampling when full enumeration is too large.

Shared Offline/Runtime Function

The offline builder and runtime search both call the same enumerate_prospective_actions implementation through:

ConsumerPurpose
scripts/bc/build_prospective_groups.pymaterialize prospective sidecar branch roots from real replay decisions
rl/prospective_runtime.pyconstruct live runtime branch roots before PyTorch reranking

This is the main parity guarantee. Sidecars and live inference do not maintain separate action-candidate logic.

Multi-Select Relationship

The base Transformer path remains autoregressive:

[ \pi(a_1\mid s),\quad \pi(a_2\mid s,a_1),\quad \pi(\mathrm{SUBMIT}\mid s,a_{<k}). ]

The prospective planner instead ranks complete legal action tuples as branch roots. When the planner succeeds, it returns the full tuple and commits memory once. When it fails, the Transformer fallback recomputes options step by step. Both paths must satisfy the same legality boundary supplied by the game engine and encoder masks.

Versioned Schema

Action coverage is versioned as PROSPECTIVE_ACTION_CANDIDATE_VERSION = "2.0.0". The sidecar manifest records this version next to the planner version, input-adapter version, coordinate schema, source archive hashes, BC dataset fingerprint, config, storage layout, and semantic fingerprint.

Branch actions are stored compactly in a flat int16 array addressed by action_offset and action_count. Group order is source archive, ZIP member, real decision, then trial_index. Node order is parent-before-child within each tree.

Determinism And Resume

Parallel execution changes throughput only. The semantic fingerprint excludes worker count because ordered process results preserve shard/group order. Resume accepts legacy serial shards only when the existing completed groups form the exact deterministic prefix expected by the current contract.

The source task recorded these observed checks after the parallelization work:

  • real smoke sidecar completed with 4 groups, 22 branches and 44 nodes;
  • serial and parallel outputs were byte-for-byte identical;
  • the new parallel output matched the previous serial smoke sidecar;
  • a legacy .work contract with workers=1 was accepted without recalculating already completed shards.

These are validation facts for the builder, not evidence that the trained planner improves ladder performance.

Related Pages