比赛结果
这 600 盘棋来自 300 组暗子布局,每组红黑互换各下一次,用 4 个线程,每步 4 秒。和 jqe 对上一版 AB-JChess 的比赛一样,我们的裁判程序把任何三次重复局面,以及双方各连续 60 步无吃子,都判为和棋。暗子被吃时,裁判程序会向两个引擎公开它是什么;在 Mistboard 上,只有吃子方才会知道。
| AB-JChess | 胜-和-负 | 得分率 |
|---|---|---|
| 全部 600 盘 | 306-67-227 | 57% |
| 执红 | 172-34-94 | 63% |
| 执黑 | 134-33-133 | 50% |
AB-JChess 的优势几乎全部来自执红的对局。整场比赛约合 +46 Elo,95% 区间为 +23 to +69。按 Mistboard 自己的重复局面规则计分则约为 +41,下文会说明。
用两个引擎解读五盘棋
如何查看这些对局
每个棋盘都从两个引擎意见不同的一步开始,走这步棋的一方最终输棋或和棋。只要两个引擎选择的着法不同,蓝色箭头就表示 AB-JChess 的选择,橙色箭头表示 jqe 的选择。棋盘下方的曲线是两个引擎按比赛设置评估的胜方胜率,AB-JChess 用青绿色,jqe 用橙色;着法列表中的注释说明局势在哪里转变,以及各引擎当时的预期。翻子旁的骰子根据双方可见的信息,为这次翻子的运气评分;研究中收录了全部六盘棋。
第 1 盘 AB-JChess 获胜:一步进兵输掉残局
所有棋子都已翻开,局面均衡。jqe(红方)选择进兵,AB-JChess 则会用马换掉黑方的士。AB-JChess 立刻看出,进兵会让黑炮转到另一侧攻击红帅;jqe 八个回合后才看出来。第 103 回合,红方无合法着法,黑方获胜。jqe 为什么进兵?时间不够并不是原因:把搜索量增至 16 倍,它仍选择进兵,仍判断为必和。它对局面的判断有误,并非漏算了某步棋。AB-JChess 关闭长捉规则,并增加同样的搜索量后,仍能看出进兵会输。
第 2 盘 AB-JChess 获胜:翻子决定胜负
黑车已经进入红方底线。jqe 把它撤回,AB-JChess 则会让它留下。后来的两步棋决定了胜负:第 35 回合红方翻出兵,两个引擎都认为局面均衡;第 36 回合红方暗吃一子,两个引擎都认为红方已是胜势。红方在第 66 回合获胜。两个引擎对这两步的判断相同,所以这盘棋无法说明它们对车的处理谁对谁错。
第 3 盘 AB-JChess 获胜:jqe 走炮引出一连串不利的兑子
红方在第 14 回合用炮暗吃一子后占优。jqe 走炮,引出一连串兑子:黑方用卒和马换掉红方的相和仕。AB-JChess 认为这些兑子对黑方不利,jqe 却认为没有问题,两个回合后才同意 AB-JChess 的判断。红方在第 72 回合获胜。连续三次翻子促使 jqe 改变判断,所以这个例子的说服力不如第 1 盘。
第 4 盘 jqe 获胜:AB-JChess 两次翻子不利
棋盘上还有很多暗子,jqe 已经认为黑方占优。AB-JChess 走了一步没有直接威胁的炮棋,jqe 则会翻子。两个引擎都无法看清翻子后的走向,所以无法判断谁对。运气决定了胜负:AB-JChess 在第 19 回合翻出兵,随后又翻出车,立刻被黑炮吃掉。黑方在第 30 回合获胜。
第 5 盘和棋:AB-JChess 已是胜势,却走成重复局面
红方在这盘棋的大部分时间里都大幅领先,但黑方逐渐追了回来。第 50 回合红方翻出兵后,AB-JChess 认为黑方已是胜势。随后红车和黑象来回移动,同一局面出现三次,比赛判为和棋。AB-JChess 没有预见到重复局面,因为比赛只向每个引擎提供当前局面,没有提供此前的着法。
第 1 盘相差八个回合,是较长的情况,另外四盘只差两三个回合。纵观整场比赛,以每个引擎自己的评分开始持续给最终胜方至少 70% 胜率的回合为起点比较,AB-JChess 的 304 盘胜局中,有 232 盘两个引擎相差不超过一个回合;判断有先后时,较晚的是 jqe 的有 119 盘,是 AB-JChess 的有 72 盘。在 jqe 的 227 盘胜局中,两者判断较晚的次数接近,AB-JChess 有 76 盘,jqe 有 75 盘。
它们的下法有何不同
jqe 高估了小幅优势
jqe 认为自己略占优势时,最终赢棋的比例低于 AB-JChess 给出相同评分时的比例。
| 小幅优势(+50 to +150),第 6 到第 30 回合 | jqe | AB-JChess |
|---|---|---|
| 最终得分率 | 46% | 64% |
| 局面数 | 592 | 595 |
无论输赢,jqe 都暗吃更多棋子
两个引擎在赢棋时都暗吃得更多,因此表格按比赛结果分组。
| 每盘暗吃子数 | jqe | AB-JChess |
|---|---|---|
| 胜局中 | 2.2 | 1.8 |
| 和局中 | 2.2 | 1.4 |
| 负局中 | 1.8 | 1.4 |
我们没有测出这给 jqe 带来什么损失。在接近均衡的局面中,暗吃后再走一步,jqe 的胜率平均下降 1.7 个百分点,AB-JChess 下降 0.7 个百分点,这一差距小于样本中的随机波动。
这场比赛说明了什么
一半暗子布局本身就决定了胜负
每组暗子布局都红黑互换下了两盘。在 300 组布局中,有 147 组是同一颜色两盘都赢,其中红方 93 组,黑方 54 组,也就是说,无论哪个引擎执这一方,胜负都由布局决定。AB-JChess 的优势来自其余布局:同一组布局的两盘都赢,它做到了 56 次,jqe 做到了 34 次。
AB-JChess 的优势在于判断,而非搜索深度
在 AB-JChess 的胜局中,jqe 判断出结果较晚;而在 jqe 的胜局中,两个引擎没有谁明显更晚。第 1 盘里,把搜索量增至 16 倍后,jqe 仍把必输残局判断为必和;它认为自己略占优势时,最终得分也低于 AB-JChess 给出相同评分时的得分。两者都说明:jqe 的问题在于如何评估平静局面和兑子,而非搜索得不够远。两个引擎都不会搜索翻子之后的着法,所以对双方而言,翻子都仍需猜测,第 4 盘就是如此。
按 Mistboard 的规则,大部分和棋都不该判和
我们的裁判程序把所有三次重复局面都判为和棋。Mistboard 则将重复过程中每一步都将军的一方判负。67 盘和棋中,有 42 盘是一方长将,其中 40 盘两个引擎都已认为另一方是胜势,持续将军成了劣势方避免输棋的办法。按 Mistboard 的规则计分,AB-JChess 赢 323 盘,和 25 盘,输 252 盘,约合 +41 Elo,95% 区间为 +17 to +66。上面的 +46 保留了裁判程序的规则,和 jqe 对上一版 AB-JChess 的比赛相同,便于比较两场比赛。
仍判和棋的 25 盘中,有 9 盘两个引擎都认为一方已是胜势,却仍走成了重复局面,其中 8 盘是 AB-JChess 占胜势。这正是第 5 盘暴露的问题:比赛中每个引擎只能看到当前局面,无法预见重复。Mistboard 会向电脑发送自上次吃子或翻子以来的着法,所以它们能够发现重复局面。
两个引擎还各自带有长捉规则,也就是一方持续攻击同一棋子所形成的重复局面的规则,两者都与 Mistboard 不同。jqe 将重复过程中每一步都捉同一棋子的一方判负。AB-JChess 则只要一方有任何一步捉子,而另一方从未捉子,就将前者判负。
此后红车每走一步都攻击黑马。按 jqe 的规则红方判负,所以 jqe 直到终局都给黑方至少 72% 的胜率;按 AB-JChess 的规则,黑马也在反捉,因此它判断为和棋。Mistboard 对长捉判和,所以 jqe 依赖的是本站对局并不采用的规则。逐步查看棋盘,可以比较两个引擎开启和关闭各自规则时的搜索结果。
神经网络更小,搜索更快
新版本基于 Devin O'Keefe 以 MIT 许可证发布的 jqe 代码重建,使用自己的神经网络。这个网络是 0.6 MB,上一版是 144 MB,jqe 的是 1.5 MB。小网络运行得快,所以新版本每秒查看的局面数约为上一版的 65 倍,也比 jqe 略多。
每个引擎在 4 秒内搜索约 22 百万个局面。为检验它们是否时间不足,我们让各引擎用两倍搜索量,重新搜索 20 盘棋中自己走过的着法。AB-JChess 会在 20% 的时候改走别的棋,jqe 则是 18%,对两者而言,每步改动平均都只增加 0.07 个百分点的胜率。提高至少 5 个百分点的改动,AB-JChess 在 754 步中出现一次,jqe 在 750 步中出现一次。更多时间对双方都有一点帮助,帮助的程度也相近。
复盘
揭棋复盘使用 AB-JChess,因此新复盘会采用新版本。在我们的服务器上,它每秒搜索的局面数约为旧版的 47 倍,同样时间里复盘能看得更远。
复盘中的评分是引擎自己的数值,每个神经网络的尺度不同。旧网络的尺度很陡:+1.1 就已表示 75% 的胜率。新网络的尺度与 jqe 接近,75% 对应 +4.1。所以同一局面现在会显示更大的数值,我们用这场比赛中的 9,776 个局面拟合了新网络的胜率。旧复盘保留旧数值,因此比较新旧复盘时,要看胜率,不要直接比较评分。
致谢
AB-JChess 以 GPL-3.0 许可证开源,地址是 github.com/lxsgx23/AB-JChess。每次构建网站时,神经网络都从作者自己的发布版本下载,我们不另行托管。感谢 Huorongrong 和 Laoxu(Kouza)。Laoxu 负责训练 AB-JChess 的神经网络,这次测试了四种翻子搜索方法,保留了最好的一种;他与 Huorongrong 共同设计了这个小而快的网络。也感谢 Devin O'Keefe,新版本基于他提供的代码开发。