我正在使用典型的 minimax + alpha-beta 剪枝算法制作 Connect Four 游戏。我刚刚实现了一个转置表，但我的测试告诉我 TT 只在 17% 的时间里有帮助。我的意思是，我的引擎在其计算中遇到的 17% 的位置可以自动赋予一个值（由于之前通过不同的移动顺序计算的位置）。
对于大多数游戏来说，这个数字是预期的吗？对我来说，这似乎很低，我乐观地希望 TT 能够将我的引擎加速大约 50%。应该注意的是，在游戏的每一回合，我都会重置我的 TT（因为之前分配给每个位置的评估由于当时的深度较低而不准确）。
我知道 TT 的有效性在很大程度上取决于它们所用于的游戏，但是任何关于它们加速常见游戏（国际象棋、围棋等）的速度都会有所帮助。
编辑 - 在运行了更多测试并调整了我的代码后，我发现 TT 将我的引擎加速到了大约 133%（因此计算时间缩短了 75%）。这意味着这 17% 的节点在树中可能相当高，因为不必计算这 17% 的评估将事情加速了 33%。这肯定更好，但我的问题仍然是这是否是典型 TT 的大致预期性能。
我认为这不一定是一个奇怪的数字。如果不复制它，任何人都不可能真正告诉您这 17% 是否“正确”，这需要更多信息（基本上必须知道实现的每一个微小细节才能重现）。
需要考虑的一些事项：
转置表的大小/用于索引 TT 的位数。如果您的 TT 相对较小，这意味着您使用相对较少的位进行索引，那么您将有更大的冲突概率。这意味着您将不得不更频繁地替换现有条目，这意味着当您在搜索过程中遇到换位时，它们可能不再出现在表中。
在搜索树中，哪些节点位于表中已被识别为转置的位置？如果您在搜索树的非常高处检测到换位，则与在搜索树深处某个位置检测到换位相比，您可以节省更多的搜索时间；一旦您检测到已经搜索到足够深以使存储在表中的值有效的转置，您可以从搜索中删除该节点下方的完整子树。这变得更有价值，因为它更接近根。所以，仅仅“17% 的节点”这个数字并不能告诉我们太多。
您是否使用迭代深化？由于您在问题中仅提到了 minimax + alpha-beta 修剪，我怀疑您没有使用迭代深化。一旦你确实使用了迭代深化，TT 就会变得更有价值，因为这样几乎遇到的每个状态都会变成“转置”。您已经在先前的迭代中看到了所有这些状态，搜索深度限制较低。现在，重要的是要注意这个 ID + TT 的组合，您不能再完全切断对所有已识别换位的搜索。如果表中的条目包含一个使用搜索深度计算的值，当执行 ID 的后续迭代时，该值将不再有效，最大搜索深度为例如。但是，存储在 TT 中的“过时”值仍可用于移动排序，这可能会导致 alpha-beta 修剪的修剪次数显着增加。
您的引擎其余部分的效率如何？TT 不是 100% 免费的，它也需要一些额外的时间（例如计算游戏状态的哈希值）。如果您的引擎的其余部分相对较慢（即下棋动作、复制游戏状态等的实现效率低下），则 TT 的计算开销不会有太大影响，即使识别的转置数量很少，仍然很有价值。如果您的引擎的其余部分非常快，那么拥有大量转置以使 TT 真正有价值将更为重要。
作为一个“有根据的猜测”，我想说你描述的 17% 的数量并不一定很奇怪。特别是考虑到您对问题的编辑，您确实提到很可能在树的高处（靠近根）发现转置。发生这种情况时，您会立即消除在自己被识别为转置的树中更深地识别所有这些状态的可能性。因此，可以在 TT 中“潜在”找到的状态池远小于存储在 TT 中的 100% 的状态。
不过，这实际上只是一个有根据的猜测。任何人都很难给出结论性的“是”或“否”。