Algorithm 蒙特卡罗树搜索算法中的换位表对UCT分数的意外影响

Algorithm 蒙特卡罗树搜索算法中的换位表对UCT分数的意外影响,algorithm,tree,hashmap,graph-algorithm,monte-carlo-tree-search,Algorithm,Tree,Hashmap,Graph Algorithm,Monte Carlo Tree Search,因此,我使用UCT在Monte Carlo树搜索算法中实现了一个换位表。这允许为游戏状态保留一个累积奖励值,无论在树中的何处以及遇到多少次。这提高了在特定游戏状态下收集的信息的质量 唉,我注意到这在UCT的开发与勘探选择阶段造成了一定的问题。简言之,分配给某个州的UCT分数考虑了访问父州的次数与访问子州(我们计算UCT分数的对象)的次数之间的比率。从这个图中可以看出,当将状态从转置表拉入树的新创建的分支时,这个比率完全不正常,子状态被访问了很多次(从树的其他地方),而父状态被访问的次数要少得多,

因此,我使用UCT在Monte Carlo树搜索算法中实现了一个换位表。这允许为游戏状态保留一个累积奖励值,无论在树中的何处以及遇到多少次。这提高了在特定游戏状态下收集的信息的质量

唉,我注意到这在UCT的开发与勘探选择阶段造成了一定的问题。简言之,分配给某个州的UCT分数考虑了访问父州的次数与访问子州(我们计算UCT分数的对象)的次数之间的比率。从这个图中可以看出,当将状态从转置表拉入树的新创建的分支时,这个比率完全不正常,子状态被访问了很多次(从树的其他地方),而父状态被访问的次数要少得多,这在技术上是不可能的


因此,使用换位表并保持状态的累积奖励值有助于算法的利用部分做出更好的选择,但同时它以一种潜在有害的方式扭曲了算法的利用部分。你知道有什么方法可以解决这个意外问题吗?

直觉上,我想你会想尝试以下方法

对于UCT的开发部分,您需要存储并使用子节点的平均分数
W/V
。整个平均值可通过换位共享。因此,在您的示例中,您不一定要单独共享
W=300
V=600
,而是只共享平均分数
W/V=300/600=0.5
。这意味着,由于换位,您可以共享更准确的分数估计(基于更大样本量的估计)

对于UCT的探索部分,我认为您需要使用父节点(没有换位)的“透视图”统计信息,而不是子节点(树中其他位置的节点的换位)。在选择要转到哪个子节点时,不使用子节点的访问计数,这意味着您将使用父节点中每个
state+action
对收集的访问计数

例如,考虑我们在你写的代码< v:2,w:300 < /代码>的节点(参考这个节点为<代码> p>代码>),并且我们必须选择子节点。更标准的实现将在子节点上循环,并使用子节点的访问计数。在您的情况下,我认为最好是循环节点

P
中的操作,并跟踪这些操作的访问计数,而不是子节点的访问计数。在
P
中,您还没有采取导致换位子节点的操作,因此
(P+操作)
对的访问计数仍然为0


不过,我个人没有MCTS+换位组合的经验,因此您可能希望做更多的研究,看看其他人在过去提出了什么。例如,有以下文件:

  • 如果你环顾四周,可能会有更多,不确定

我已经实现了以下功能,这些功能与国际象棋的Alpha-Zero风格算法配合得很好:

  • 与传统MCT一样构建游戏树
  • 将换位表从游戏状态映射到其最大访问次数和值总和
  • 选择操作时,检查是否在访问次数较多的其他位置看到该操作,并将该值平均为
    (moveValueSum+transpositionValueSum)/(MoveVisitions+TranspositionVisitions)
    • 如果当前操作的访问次数多于换位表中的访问次数,则更新换位表

这样,我们就不会对一个操作的所有访问进行求和,而是只对访问次数最多的一个实例的操作值求平均值。

交叉发布:。请每个社区都应该有一个诚实的回答机会,而不浪费任何人的时间。我的错,我不知道这是一个规则。我希望能够超越“这个问题超出了这个社区的范围,你们应该试着把它发布到其他社区”的评论,我每发布一个问题都会收到这个评论;-)没问题,你不可能知道。您可以选择一个要显示的站点。如果你对它的出现感到满意,你不需要做任何事情——只是让你知道未来。如果你希望它出现在CS.SE上而不是SO上,你可以在SO上删除这里的副本,然后在CS.SE上标记副本以重新打开。我希望它出现在最有可能获得一些高质量答案的地方,但我不知道它在哪里,因此我在两个社区中都发布了它。我想让我们把它留在这里,看看会发生什么。相关论文:“UCD:有根有向无环图的置信上界”