我有 MCTS 的有效实现。为了方便起见，我在 Tic-Tac-Toe 上测试它，但真正的目标游戏会相当大。
据我所知，它会生成正确的获胜计数并以应有的方式探索树，并且大部分会生成良好的动作。然而，在某些情况下，所选择的举动会导致立即损失。同样，它可能不会选择导致强制获胜的举动。
我对获胜计数的分析是，这些棋步实际上在随机游戏中获胜的次数多于输的棋步，而熟练的对手所下的路线没有得到足够的重视。
因此，问题是如何（a）调整 MCTS 以支持短期胜利并避免短期损失，或者（b）向搜索添加功能以检测强制线并确定优先级。
真正编写并完成 MCTS 的人可能最能回答这个问题。关于 SO 和 SWE 还有其他类似的问题，但没有有用的答案。
需要明确的是，我的 MCTS 实现在大约 500 次迭代中实现了 TTT 交通灯变体的完美发挥，但在 100-200 次迭代中有时会发挥非常糟糕的动作，错过即时胜利或失败。相比之下，极小极大化仅需要 81 次迭代就可以完全避免不良动作（2 层），但在 729 次迭代（3 层）时表现出普遍的弱游戏性。任何能够有效实现这些算法的人都应该看到类似的结果。
MCTS 收敛于良好的玩法，但我希望改进它在迭代次数较少的突然死亡游戏中的表现。我发现交通灯是一个很好的测试平台。
我正在尝试解决同样的问题。如果您的“查找动作”代码检查每个合法动作是否获胜，该怎么办？如果立即获胜，则仅将那一步棋返回 MCTS——忽略其他技术上合法但非常糟糕的棋步。通过这种方式，不是修剪坏树枝，而是那些坏树枝从一开始就不会被添加到树中。这可能会大大减慢计算速度，但如果它在短期内运行得更加智能，那么这可能是值得的。
我也有类似的观察，我想对此也有一个解释。
我还尝试使用 tictactoe 进行 mcts 编码。如果模拟环境有一个非常小的决策树（对于 tictactoe 来说大约有 350000 个节点），mcts 的表现似乎会很差。
此外，如果 mcts 能够以高概率重复达到获胜最终状态（无需模拟，而是直接通过遍历），这似乎对 mcts 不利。
问题是，mcts 很快就会直接探索一些最终状态。通常最终状态只是模拟的结果。
当发现并再次选择这样的最终状态时，MCTS 会一遍又一遍地模拟该获胜的最终状态。猜猜模拟always的结果是什么？ :-)
因此，该特定节点的 UCB 分数将变得相当高，并且该节点将在所有其他节点上一遍又一遍地被选择，因为高分数也会传播到根节点。
一段时间后，发现一些获胜路径的移动将具有迄今为止最高的 UCT 分数，并且几乎是其余迭代中考虑的唯一路径。
例如，当我在 tictactoe 上进行 1.000.000 次迭代时，第一次移动就完成了最多 950000 次，而剩下的 8 次移动很少被考虑。 （大概几百次）。
现在的问题是，mcts 偏向于单一的移动，因为它在树上有一两个强大的路径正在获胜并且越来越加强，它忽略了这样一个事实，即树的该部分还有其他移动完全输了。
这就是为什么 mcts 告诉我，TTT 的第一步就是 100% 获胜，即使这不是我们都知道的事实，只是因为 mcts 比所有其他可能性更喜欢一条获胜路径。
可以说，其他选择和替代举措变得完全盲目。
我想这可以通过修改 UCT 函数来调整，以更多地支持探索而不是利用，也可以研究其他路径。
对于这样的小游戏来说，标记最终节点可能是有意义的，这样它们就不会再次被选择。
更进一步，如果整个子树被完全发现，非最终节点也可以被标记。这将导致更高的探索，并再次考虑其他路径，因为选择树中已经完全探索的部分也是没有意义的。
一遍又一遍地对与状态进行模拟是没有意义的，因为这永远不会改变结果。
有趣的是，我发现对于 TTT，迭代设置得越高，结果就越差（集中并完全固定在一个获胜分支上）。