A transposition table is a hash table cache used in adversarial search algorithms like Monte Carlo Tree Search (MCTS) and alpha-beta pruning to store the evaluated value of previously encountered game states. Different move sequences can lead to the same board position—a transposition—and the table prevents expensive re-evaluation by returning the cached value, best move, and search depth. This memoization dramatically reduces computational overhead, allowing deeper search within the same time or memory budget.
Glossary
Transposition Table

What is a Transposition Table?
A transposition table is a cache used in search algorithms like Monte Carlo Tree Search to store and reuse the evaluation of game states that can be reached via different sequences of moves, preventing redundant computation.
In MCTS, the table stores node statistics—like total reward and visit count—keyed by a Zobrist hash of the game state. During tree traversal, the algorithm checks the table before expanding a node. A hash collision is managed via replacement strategies that prioritize entries from deeper searches. This optimization is critical in games with many symmetries or reversible moves, like chess and Go, and is a foundational technique for achieving the performance seen in systems like AlphaZero and Leela Chess Zero.
Core Characteristics of a Transposition Table
A transposition table is a cache used in search algorithms like Monte Carlo Tree Search to store and reuse the evaluation of game states that can be reached via different sequences of moves, preventing redundant computation. Its design involves several key engineering trade-offs.
Zobrist Hashing
The standard method for generating a unique, compact key for a game state to use as a lookup index. It works by precomputing a table of random bitstrings for each possible piece on each board square. The hash for a position is computed by XOR-ing together the bitstrings for all pieces present.
- Properties: Fast incremental update (XOR out old piece, XOR in new piece).
- Minimizes Collisions: Uses 64-bit or 128-bit keys for a near-zero probability of two distinct states hashing to the same value.
- Critical for Performance: Enables O(1) average-time lookups, making the cache practical.
Replacement Schemes
Algorithms for managing cache entries when the table is full. A naive scheme overwrites any existing entry, but advanced schemes preserve more valuable information.
- Always-Replace: Simple but can discard critical deep-search results.
- Depth-Preferred: Retains the entry from the deeper search tree ply, as it is typically more precise and expensive to compute.
- Two-Bucket Scheme: Stores two entries per hash index (e.g., one deep, one shallow), offering a good balance of simplicity and effectiveness.
Bound Types & Entry Data
A transposition table entry stores more than just a value; it includes bound information critical for correct pruning in algorithms like Alpha-Beta search.
- Exact Bound: The stored value is a proven minimax score for the node.
- Lower Bound: The node's value is at least this much (e.g., from a fail-high in Alpha-Beta). Useful for the maximizing player.
- Upper Bound: The node's value is at most this much (e.g., from a fail-low). Useful for the minimizing player.
- Other Data: Entry also stores the best move found, the search depth (ply) of the result, and the hash key for verification.
Collision Handling
Strategies to manage the rare but inevitable event where two different game states produce the same hash key (a hash collision).
- Key Verification: Storing a full or partial extra verification key (e.g., 32 bits) alongside the entry. On lookup, this key is compared to ensure the stored state matches the current state.
- Depth/Distance Heuristic: In MCTS, some implementations accept a collision if the stored entry's depth is sufficiently greater, prioritizing deeper, more expensive computations.
- Impact: Uncaught collisions can lead to catastrophic errors, returning the evaluation of a completely different board position.
Applications Beyond Minimax
While foundational to chess engines, transposition tables are vital in other search paradigms.
- Monte Carlo Tree Search (MCTS): Caches the value estimate (win rate) and visit count of a state. When the same state is reached via a different move order, the cached statistics are used, drastically accelerating tree growth and convergence.
- Puzzle Solvers: Used in single-agent search problems (e.g., the 15-puzzle) to avoid re-exploring previously visited states, turning a depth-first search into a dynamic programming solution.
- Model-Based RL: In algorithms like MuZero, a learned model predicts a latent state. A transposition table keyed on this latent representation can cache planning results.
Memory vs. Performance Trade-off
The size and configuration of the transposition table are primary levers for tuning search performance.
- Table Size: Generally allocated as a power-of-two number of entries (e.g., 2^24 entries) for fast index masking. Larger tables reduce the replace rate and increase hit accuracy.
- Entry Size: A typical entry might be 16-24 bytes (hash, move, value, depth, bound). A 2^24 entry table with 16-byte entries uses 256 MB of RAM.
- Performance Curve: Performance improves with size up to a point, after which diminishing returns set in as the working set of the search is fully cached. The optimal size is problem-dependent.
Frequently Asked Questions
A transposition table is a critical performance optimization in search algorithms, acting as a cache for computed game states. This FAQ addresses its core mechanics, implementation, and role in advanced AI systems.
A transposition table is a hash table cache used in game-playing and search algorithms like Monte Carlo Tree Search (MCTS) and alpha-beta pruning to store and reuse the evaluated value of game states that can be reached via different sequences of moves (transpositions). It works by generating a hash key (e.g., using Zobrist hashing) for each unique game state encountered during the search. When the algorithm reaches a state, it first checks the table. If the state's hash key is present and the stored information (like value, depth, and node type) is usable, it retrieves the cached value instead of performing a costly re-evaluation or subtree search. This prevents redundant computation of identical board positions arising from different move orders.
Key Mechanism:
- Hashing: A fast, deterministic function converts the game state into a unique integer key for table lookup.
- Entry Storage: Each table entry typically stores the hash key, the computed value (e.g., win probability), the search depth (or iteration count) at which it was computed, a flag indicating the node type (e.g., EXACT, LOWER_BOUND, UPPER_BOUND), and the best move found.
- Replacement Policy: Schemes like always-replace or depth-preferred manage collisions in the fixed-size table, deciding which entry to keep when two states hash to the same location.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
A transposition table is a core optimization for search algorithms. These related concepts define the broader algorithmic and architectural context in which it operates.
Monte Carlo Tree Search (MCTS)
Monte Carlo Tree Search (MCTS) is the primary heuristic search algorithm that utilizes transposition tables. It is a best-first search algorithm for optimal decision-making in sequential problems (like games or planning) that builds a search tree through iterative random simulations. The four-phase cycle—Selection, Expansion, Simulation, Backpropagation—is where the transposition table caches state evaluations to prevent redundant computation across different search paths.
Zobrist Hashing
Zobrist hashing is the canonical technique for generating a compact, unique hash key for a game state to index a transposition table. It works by pre-generating a table of random bitstrings for each possible piece-location combination. The hash of a board state is computed via XOR operations over the relevant table entries. This method is incremental: making or undoing a move updates the hash with a constant-time XOR, making it extremely efficient for tree search algorithms that explore state spaces by applying and reversing moves.
Alpha-Beta Pruning
Alpha-beta pruning is the foundational adversarial search algorithm for perfect-information games like chess, against which MCTS is often compared. It dramatically reduces the number of nodes evaluated in a minimax tree. Transposition tables are equally critical here, often called a transposition table-driven alpha-beta or TTAB. The table stores previously computed minimax values and bounds (EXACT, LOWERBOUND, UPPERBOUND) for states, allowing the algorithm to prune entire subtrees if a cached entry proves the current branch cannot influence the final decision.
Replacement Strategies
Replacement strategies are policies for managing collisions in a fixed-size transposition table, which is essentially a hash table. Common strategies include:
- Always Replace: Overwrites any existing entry.
- Replace by Depth: Keeps the entry from the search conducted at the greater depth, as it is considered more accurate.
- Replace by Quality: A more sophisticated method used in alpha-beta that prioritizes keeping EXACT entries over bounds (LOWER/UPPER). Choosing the right strategy is crucial for maximizing the hit rate and the quality of retrieved information.
Killer Heuristic
The killer heuristic is a complementary search optimization that works alongside a transposition table. It identifies "killer moves"—moves that caused a beta cutoff (a successful prune) in a sibling node at the same search depth. These moves are tried early in the move ordering of other nodes at that depth. While the transposition table provides a global cache of state values, the killer heuristic provides a dynamic, depth-specific ordering heuristic, both aiming to make the search more efficient by prioritizing promising or refuting moves.
Iterative Deepening
Iterative deepening is a search control strategy that performs a series of depth-limited searches (e.g., depth 1, then 2, then 3). It is memory-efficient and allows for time-bound operation. The transposition table is vital here, as results from shallower searches (stored in the table) provide excellent move ordering for deeper searches. The principal variation from a depth d search guides the root move ordering for the depth d+1 search, causing an exponential reduction in the effective branching factor.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us