人机大战结束了。感觉人类棋手已经勘破一些alphago的破绽，大致掌握了战略走向，只
是实践起来仍有非常难度。假如说李世石在五场对弈中取得进步，那么alphago呢？或者
说alphago背后的google工程师呢？
评论alphago在唯一败局中展露的缺点，应该以FB工程师田渊栋的分析最具公信力。毕竟
他手上有一套darkforest随时可以佐证棋步的胜率估计，更重要的是他本身就是顶尖ML演
算法工程师，对算法缺失的直觉应该同等于李世石对围棋胜负的理解。他提出了两种面
向，一种是MCTS搜索过早结束，一种是对叶节点的胜率估计出了问题。然而相同的猜测是
，这两种失误都容易在盘面需要复杂计算才能算清的情况下出现。假设google事后调阅
log档发现原因果真如此，这个工程问题该如何解决呢？
也许一般人会想，换掉训练资料就好啦，这次挑选一些复杂盘面的棋谱再对两个神经网络
重新或增强训练，还不把人类棋手赶尽杀绝？不过要训练出一个好的ML模型并不是真的狂
灌资料就能办到了。假如模型复杂度不足，却硬吃太多资料变异性，相当于加偏差
(biased)资料下去，可能降低模型的泛化能力。反过来说，一味提升模型复杂度则会造成
训练过程困难。虽说ML研究本来就有一些经验法则的味道，但工程师困在这种try and
error的循环里不是google这种等级应该花时间干的事。以下试着提供三点从工程师思维
出发的解决方案：
1. 目前论文上的MCTS搜寻策略还是有缺点的。当搜寻树抵达一定深度时，就开始对叶节
点进行胜率估计。若没看漏细节alphago并没有对这个搜寻深度进行动态调整，但当棋局
陷入难以算清的盘面时，棋手本来就该投入更多思考时间分析最佳解，例如第四局李世石
的40分钟78手就如是。所以最直觉的做法是一旦陷入这种局面，alphago的搜寻深度就得
在考虑时间限制之下尽可能提高。
2. 胜率估计出问题可能原因有二。一个是价值网络预测不准，一个是快速走子模拟胜负
的结果不佳，最糟的情况是如前面一篇分析文章的作者陈经所说的两者皆差(顺带一提我
觉得他的分析很不错)。论文中对胜率估计的权重设计相当偷懒，就是一半一半。Google
工程师若事后检查，发现在难以算清的盘面上其中一种估计品质极差，就该根据盘面复杂
度动态调整权重值。若不幸的是worst case两者皆差，那么我建议在时间限制许可下启用
policy network进行走子胜负预测。
3. 采用前两点补丁都有一个前提：如何决定盘面复杂度？这里就是很主观的个人看法了
，我认为google可以再训练一个风险网络(risk network)，专门根据盘面判断此时落子的
风险程度。这个模型的预测目标与胜率无关，所以与价值网络/走棋网络的性质应该要起
到互补作用，专门泛化那些一触及发的棋局的pattern。当然这个做法的问题是如何定义
与生成训练资料，但这件事对有丰富围棋知识背景的开发团队而言应该不难解决。
基本上工程师思维就是主要框架不动，并且在方法原本精神下(ML+MCTS)提供可靠的补丁
机制。以google现在拥有的资源，完成这些事应该不用三个月。三个月后……alphgo可能
真的可以变身betago了。

通常快速走子的结果不会太差, 至少会比评估网络准很多所以最怕是关键棋步被根本没下去算(逻辑等同于被剪掉)

访问的时候好像听到是第18版,应该再改版不会改名字吧!

我们不会区分 李世石2016 跟 李世石2015, 一样道理吧 :)或许时间控制子系统也需要纳入训练的概念, 前中后盘

恩 所以搜寻树深度很重要

人类采用的策略会不同, 对机器来说似乎也有必要

不过我记得快速走子好像单独使用才24%左右 这..算准吗

hmm... 依田渊栋的说法, 快速走子的广度也很重要不需要它准 开发了 RL 却不用(最后只用在训练估值网络)应该也是这个道理

想看贝他狗虐柯KJ

如果是广度问题 那就要更换MCTS的UCT策略了

这点我完全不担心 路人甲工程师想的到的开发团队当然更不可能漏掉 不涉及重复训练的话 测试时间应该都很快

我倒是觉得大家不用妄自菲薄 都是对ML有想法的人罢了

还会变成omegago哦

风险网络的训练资料是？如果kgs的棋谱有时间记录，那还有机会，看盘面猜下一手会想多久才落子想得久就比较复杂

这个建议不错耶

下网络棋到一半接电话泡咖啡拉屎老板来了 也是有的

棋谱没有记载思考时间吧 XD