学步园

前面的文章中提到过UCG的思想，也就是认为博弈树实际上应该看做是一个图，因为下棋时的每一个局面，都可以用不止一种顺序走出来，也就是每个节点不止一个父节点。我刚接触UCT算法时，就想到了这一点，而且奇怪为何没人这么做，总觉得如果按照图来处理，模拟的结果应该更逼近真实情况吧！因为图的处理比树麻烦，还是使用树结构去做了。

再后来，我发现计算机围棋论坛上也有人提出UCG，而我又想到了可以用置换表等效的实现后，很是兴奋，人都是会对自己的想法夸大优点，并且无意中忽略缺点。例如我对我实现的UCG多占用的一倍内存视而不见，速度比UCT慢我也能接受，并且出于良好的自我感觉，在与程序对战后，我做出了“UCG使得程序棋力立即有了提高”的判断。

幸好我在进一步改进UCG机制前，我写了个脚本让两个程序之间对战。并从对战结果中发现一个残酷的事实：使用UCG的程序完败。

在事实面前，我才想明白了原由：UCT算法本身是一个对所有节点公平的算法，如果某个节点在树中有同型节点存在，那么其任何一个兄弟节点也存在同型节点。而UCG的作用是使一个节点的模拟结果被其全部同型节点共享，共享或者不共享，影响的只是对节点过往胜率的重视程度，但是UCT算法本身就有调节这种重视程度的机制，还记得UCT的本质吗？就是在开发和探索之间寻求一种平衡，对过往胜率的重视就意味着把开发的权重加大。

这就是说我挖空心思做的一个UCG改进没有丝毫意义，它的效果可以通过调整UCB公式的参数模拟出来。

这是一种最大限度利用模拟结果的手段，All Moves As First，即所有的棋步都像第一步一样。例如，黑棋假设它在A1处下一步棋，然后进行模拟，模拟结果为黑胜，那么传统的UCT计分方法是为A1这个节点加一分，并把结果向A1的祖先节点汇总，也就是把黑棋胜利归功于A1这步棋。而按照AMAF的做法，则是把功劳均摊到A1以及模拟对局中黑方所下的每一个位置。

这个方法的优点在于能用少量的模拟局数获取大量的得分情况，从而加快局面评估速度。但是其缺点和优点一样突出，在棋类游戏中的一个常识是，棋步的顺序是与胜负有关系的。这样的快速评估很可能会得出错误的结论。因此，AMAF不是一个一致的算法。

一个折中的做法是设定一个分割比率，只对模拟对局前一部分的棋步计分，通常我们认为先下的棋步要比后下的棋重要。这个比率的取值从0到1，显而易见，如果取0，算法就还原为原始的UCT了；如果取1，则又相当于一个完整的AMAF了。取什么样的值，我用自然选择来决定。

遗传因子我已经选好了，一共3个，分别是节点的成熟度（一个节点被模拟多少局后才为其创建子节点，going down的说法是ooxx多少次后才生娃），探险的权重，AMAF的分割比率。

维护一个种群数量不变，每次随机取出两个遗传因子不同的个体，让它们分先下两局棋，输了的杀掉，赢了的可以无性繁殖一个后代，繁殖的过程中有一定几率发生变异。如果没有分出胜负，那也不能让它们无限的活下去，无论胜负，每下一次棋，生命减1，生命到0也直接抹掉。然后我会再随机创造新的个体去补齐数量的。

听起来颇有造物主的感觉呀，进化将会是一个漫长的过程，为了让它们下的棋有意义，我每步棋给了它们足足一秒钟的思考时间。从本文开始写作时，它们的竞争已经开始了，到现在，预先设置的两个种子选手之一已经被淘汰掉了一个，不过离进化的终点还差的很远，按照游戏规则，这场进化的结束条件是全部的个体都拥有相同的遗传因子。

程序实现上，我采用了unix的传统，用C实现核心部分，脚本语言作为黏合剂。至于代码，实在没什么新东西，无非是测试和调整了些参数，我也懒得一遍遍上传了。实现自然选择的脚本我贴在下面，有兴趣可以参考。