If implemented correctly and run to completion at the same fixed depth on the same deterministic game tree, alpha-beta pruning will not change the final Minimax decision. Alpha-beta is a correctness-preserving optimization: it only prunes branches when it can prove those branches cannot influence the backed-up min/max value at the root. Therefore, the chosen move and the root score should match plain Minimax exactly. If you see different results, it typically means your search conditions are not actually “the same fixed-depth deterministic tree,” or there is a bug.
The most common reasons developers observe different decisions are practical, not theoretical. First is time cutoffs: if you stop the search mid-branch (because a deadline hit), the result can depend on ordering, since you explored different children first. The fix is iterative deepening: only accept the best move from the last fully completed depth, so ordering affects how deep you get, not what you return at a given completed depth. Second is state mutation bugs: if you apply a move and forget to undo some state (turn, special flags), you’ll evaluate corrupted positions and results can vary with ordering. Third is inconsistent scoring: if your evaluation sometimes returns scores from different perspectives (AI vs current player), then pruning decisions can become invalid and outcomes can shift. Fourth is misuse of transposition tables: caching values without considering search depth or bound type can cause incorrect cutoffs and different root moves.
A practical debugging workflow is to build a small test harness that compares plain Minimax and alpha-beta on the same positions and depth, with deterministic move generation order. Log (1) node counts, (2) returned root score, and (3) best move. They should match. Then randomize move ordering and confirm the result stays the same when the search fully completes. If it doesn’t, you likely have an implementation defect or non-determinism. In retrieval-based pipelines, non-determinism can sneak in if leaf evaluation depends on external calls whose outputs vary across time or across repeated queries. If you’re pulling candidates from Milvus or Zilliz Cloud, keep retrieval deterministic during a single search pass (same parameters, stable snapshot if relevant) or cache results within the search so alpha-beta’s pruning logic remains sound and repeatable.