飞扬围棋

标题: ELF OpenGo发布,据说比leelazero还强 [打印本页]

作者: lu01    时间: 2018-5-3 05:14
标题: ELF OpenGo发布,据说比leelazero还强
本帖最后由 lu01 于 2018-5-9 14:58 编辑

翻译
检测到英语
中文(简体)

ELF OpenGo
ELF OpenGo是AlphaGoZero / AlphaZero的重新实现。 它在两周内接受了2,000个GPU的培训,并且取得了很高的性能。

“ELF OpenGo已经成功地与其他开源机器人和人类Go玩家对战,我们使用其默认设置并且没有思考,与LeelaZero(158603eb,2018年4月25日)一起赢得了200场比赛,这是最强大的公开可用的机器人。 我们还取得了世界排名前30的人类棋手中四个人的14胜0负的记录。“

“我们感谢LeelaZero团队的高质量工作,我们的希望是开源我们的机器人同样可以让像LeelaZero这样的社区活动受益”



Github:Https://Github.Com/pytorch/elf


作者: lu01    时间: 2018-5-3 05:16
acebook open sources elf opengo #1311 @kityanhem kityanhem opened this issue about 2 hours ago  edited about 2 hours ago https://research.fb.com/facebook-open-sources-elf-opengo/  ELF OpenGo ELF OpenGo is a reimplementation of AlphaGoZero / AlphaZero. It was trained on 2,000 GPUs over a two week period, and has achieved high performance.  "ELF OpenGo has been successful playing against both other open source bots and human Go players. We played and won 200 games against LeelaZero (158603eb, Apr. 25, 2018), the strongest publicly available bot, using its default settings and no pondering. We also achieved a 14 win, 0 loss record against four of the top 30 world-ranked human Go players."  "We thank the LeelaZero team for their high quality work, and our hope is that open-sourcing our bot can similarly benefit community initiatives like LeelaZero"  Github: https://github.com/pytorch/elf
作者: lu01    时间: 2018-5-3 07:52
权重下载地址
https://github.com/pytorch/ELF/releases
代码可以在master下载
作者: lu01    时间: 2018-5-3 08:00
以前公布的
黑暗森林中的光之精灵
田渊栋
田渊栋
人工智能、深度学习(Deep Learning) 话题的优秀回答者

昨天晚上折腾到北京时间凌晨1点,终于完成了ELF开源的任务。这次开源获得了公司的支持,和代码一起公布的还有arXiv文章及公司的官方博客。国内的媒体真是快,我还没来得及写专栏,第二天早晨就看到机器之心的翻译了。

代码见:facebookresearch/ELF

文章见:An Extensive, Lightweight and Flexible Research Platform for Real-time Strategy Games

官方博客见:https://code.facebook.com/posts/ ... -for-game-research/

英文的个人博客:http://yuandongtian.blogspot.com/

ELF的核心思想是“让大家都能做得起深度强化学习的研究”,它给了一个从模拟器到优化算法的一篮子解决方案。通过一些工程上的技巧以降低计算资源的需求,增加程序的可读性,并且提供一个短小精悍的即时战略引擎用来给大家研究。框架的设计和代码,即时战略游戏引擎及文章的撰写由我完成;前端可视化代码,及夺旗和塔防两个游戏的设计和训练由龚渠成(Qucheng Gong)完成;@吴育昕 (Yuxin Wu)把Atari模拟器接入了ELF,并且进行了速度测试;商文龄(Wenling Shang)改进了神经网络结构,加入了LeakyReLU和Batch Normalization并提高了性能;最后Larry对这个项目提出了很多建议,并且帮忙修改了文章。

这个框架前前后后做了半年左右,核心设计改了挺多次,最后收敛到现在这个版本。总的来说我对ELF这个框架的设计还是比较满意的,用C++将许多并行的游戏线程和每个线程的历史数据封装进去,使得每次Python循环时都可以得到一批次的游戏状态,而不是某一个线程单独的游戏状态。这样接强化学习算法时,可以直接调用神经网络的前向/后向传递,而不需要手工在Python里面写多线程或者多进程的代码,这样就使得Python代码清晰可读并享有较高性能。ELF的训练用了PyTorch作为平台,PyTorch,训练算法及模型之间使用Python dict作为接口,这样对于任何一个模型或者算法而言,它只需要通过预先设好的键值,从dict里面读它想要的输入,然后生成它要生成的输出,而不必考虑其它部分的细节。这样就使得框架易读,且扩展性好。这样写还有一个好处,就是可以根据每个游戏线程的序号及其当前状态来采用不同的模型,这样就把蒙特卡罗树搜索(Monte-Carlo Tree Search),自我对弈(Self-Play)等等涉及到游戏状态和神经网络之间复杂互动关系的方法,统一在一起了。如果大家看过围棋引擎DarkForest的代码,可能会觉得分成两个独立程序来运行DF非常不方便,需要先打开一个程序用CPU来做树搜索,同时再打开一个程序用GPU来运行策略及值网络。现在在ELF框架下不需要了。这一部分的代码过一阵子也会开源。另外这个框架其实不仅仅限于游戏,任何一个虚拟环境,比如说物理引擎,比如说连续或者离散控制系统,只要有C/C++的源码,都可以整合进去,ELF会自动处理多线程同步的并返回一批次的内部状态——当然,即便没有源码,只要存在某种形式的接口,也是可以的。

在这个框架下面,我们实现了一个小巧的即时战略引擎,并写了一个简化版的一对一即时战略游戏(MiniRTS),还有夺旗和塔防两个扩展。MiniRTS虽然小,但是基本的采矿、造兵、造建筑、战争迷雾等游戏机制都有,各单位可以在地图上连续移动,并且每个单位有基本的避障及寻路功能。因为这个引擎是从头开始设计的,很多细节可以专为深度学习和强化学习的训练定制。在游戏的复杂性方面,仅仅花两周写出来的MiniRTS当然远不如大型团队开发几个月做出来的商业游戏,不过它胜在速度快占用资源少,并且可以扩展,对于测试一些新的研究思路会比较有帮助。速度是MiniRTS的强项,比如说在一台4核的Mac的笔记本上,运行游戏可以跑到每个核4万帧每秒。用12个CPU和1个GPU去测试训练出来的模型,跑一万局游戏仅需一分半钟。然后我们也提供了一个网页版的可视化工具,可以拿来看Replay,甚至和电脑AI玩一局。相比之下若是用星际等商业化游戏做研究,就需要动用大量资源,而且很多功能无法自行拓展。

在MiniRTS及夺旗和塔防三个游戏上,我们进一步做了强化学习的训练实验,用的是流行的Actor-Critic模型,但加了些off-policy的拓展。在训练MiniRTS时,我们没有加辅助奖励(比如说鼓励造坦克鼓励采矿等),而只告诉算法这一局结束后是赢是输。即时战略游戏的行动空间(action space)是非常广阔的,用现有的框架不太容易找到好的策略,所以这次先做比较简单的方法,把行动空间离散化为一些高层策略,比如说造农民,造兵,全军进攻及防守,等等。这样现有的强化学习方法就可以使用,并且得到了一些比较有趣的结果,能够以70%的胜率战胜我们自己写的基于规则的AI。

如果大家对强化学习和游戏AI有兴趣,这个框架会提供很大帮助,我这里就毫不谦虚地自卖自夸。希望大家喜欢。

PS: 这个框架的原名是LightELF,和之前的DarkForest合起来就是“飞舞在黑暗森林中的光之精灵”,就容我小小地文青一下。
编辑于 2017-07-08
作者: lu01    时间: 2018-5-3 09:17
https://github.com/gcp/leela-zero/issues/1311
tian yuandong提到
这个就是cgos上的美国总统系列
作者: lu01    时间: 2018-5-3 09:19
No worries. All bots with American president names are different version of our bots with 4800 rollouts on single GPU (V100). Sorry for keeping them to be secret for so long. We need to hit F8 deadline.

Update: should be 4800 rollouts instead of 6400.
====
别担心。 所有美国总统名字的机器人都是我们的机器人的不同版本,在单GPU(V100)上推出了4800个机器人。 抱歉让他们这么长时间保密。 我们需要达到F8的最后期限。

更新:应该是4800而不是6400。
作者: fyw    时间: 2018-5-3 11:13
 来源知乎:远东轶事

  我们最近改进了ELF框架,并且在上面实现了DeepMind的AlphaGoZero及AlphaZero的算法。用两千块GPU训练约两到三周后得到的围棋AI,基本上超过了强职业的水平。我们和韩国棋院合作进行了一次测试,给这个AI单卡每步50秒搜索时间(每步搜索8万个局面),给人类棋手任意长时间思考,结果AI以14比0完胜。参与测试的棋手包括金志锡,申真谞,朴永训及崔哲瀚,在这里我们非常感谢他们的合作,大家都很尽力,一些棋局下了三四个小时极其精彩。应棋手们的要求,这14局棋谱中的12局不久将公开。

  另外我们也和现在著名的LeelaZero比较了下。我们采用了LeelaZero除ponder外的缺省配置(约一分钟一步),及4月25日的公开权重(192x15, 158603eb),结果我们的AI以200比0获胜。在此我们非常感谢Leela团队的工作,对于他们的开源精神,我们表示由衷的敬意。

  这次我们将训练代码,测试代码及训练出来的模型(224x20)全部公开,首要目的是贯彻我们一直以来坚持的开源方针,让AI为全世界服务。其次是对于AlphaGoZero及AlphaZero这样非常优秀的算法,我们想要提供一个可重复的参考实现,让全球的研究者们能在这上面继续改进,充分发挥自己的创造力。最后是借此机会推广一下我们的ELF平台和PyTorch深度学习框架,希望更多的人能使用和完善它。

  代码见:https://github.com/pytorch/ELF

  模型见:pytorch/ELF

  英文blog见:https://research.fb.com/facebook-open-sources-elf-opengo/

  感谢大家的支持!

  田渊栋,龚渠成&马子嫯(Jerry Ma), Shubho Sengupta, 陈卓远,Larry Zitnick

(责编:樊璐璐)

作者: 每周一练    时间: 2018-5-3 12:29
怎么玩,有教程吗
作者: lu01    时间: 2018-5-3 15:17
每周一练 发表于 2018-5-3 12:29
怎么玩,有教程吗

很难编译,只能用utubu,我们还是先用leelaz



作者: lu01    时间: 2018-5-3 15:18
挫伤了gcp的积极性


I think we should halt our training effort? We'll have to see about a better relative strength estimate, correcting for time, and perhaps cuDNN speedup, but the CGOS ratings look over a month old and suggest a few hundred of CGOS Elo, which is probably near a thousand self-play Elo and, at the current rate, several months of running our training.

It seems more wise to spend that time trying to make a conversion for the network weights and work from there. Additionally, the weights are probably strong enough that they are superhuman even on modest hardware, so maybe further hammering on 7.5 @ 19x19 is not the best use of resources.
=========
我认为我们应该停止我们的培训工作? 我们必须看到一个更好的相对强度估计值,校正时间,也许cuDNN加速,但CGOS评级看起来超过一个月,并建议几百个CGOS Elo,它可能接近一千个自我娱乐Elo 并按照目前的速度进行数月的培训。

花时间尝试为网络权重进行转换并从那里开展工作似乎更明智。 此外,权重可能足够强大,甚至在适度的硬件上也是超人类的,所以可能在7.5 @ 19x19上进一步敲击并不是资源的最佳利用。
作者: 明月白驼    时间: 2018-5-3 21:06
玩玩人类的棋就很好了      再NB的话    让它们左右互博       管我们人类鸟事
作者: leeking    时间: 2018-5-3 22:49
lu01 发表于 2018-5-3 15:18
挫伤了gcp的积极性

应该作A卡和N卡的加速优化了,目前看做好加速优化,加大网络还是可能的。

作者: lu01    时间: 2018-5-4 05:04
本帖最后由 lu01 于 2018-5-9 14:59 编辑

你好,我们有新的运行结果。 我们从日志中验证LeelaZero正在使用50秒而没有提早停止。  ELF OpenGo赢得了198场比赛,LeelaZero赢得了2场比赛。 我们对我们的博客文章发布了更正。 此外,由于似乎需要大量游戏记录,我们让我们继续为您提供1000个ELF OpenGo vs. LeelaZero游戏记录的数据库。 这些记录将在明天上传。  到目前为止,LeelaZero每次平均使用73k部署(LeelaZero日志中的“播放”)。 和以前一样,ELF OpenGo每次移动使用80k。 我们假设速度差异主要是由两个相反的因素造成的:我们使用加速推理的fp16,以及我们较大的ResNet,这减慢了我们的推断。  我们感谢你们都如此迅速地提出了这个问题 - 这表明了这个社区的活力和奉献精神。 在我们重游我们的游戏时再次感谢您的支持!
作者: lu01    时间: 2018-5-4 05:45
科技频道 广告 观点 | Facebook田渊栋盛赞DeepMind最新围棋论文:方法干净标准,结果好 2017-10-20 08:05 机器之心 T大 原标题:观点 | Facebook田渊栋盛赞DeepMind最新围棋论文:方法干净标准,结果好 机器之心转载自知乎 作者:田渊栋 昨日,DeepMind 在《自然》杂志上发表了一篇论文,正式推出人工智能围棋程序AlphaGo Zero。这篇论文的发布引起了业内极大的关注与讨论。Facebook AI 研究员田渊栋在知乎上发布了一篇简短的文章,介绍了自己对这篇论文的看法。 老实说这篇 Nature 要比上一篇好很多,方法非常干净标准,结果非常好,以后肯定是经典文章了。  Policy network 和 value network 放在一起共享参数不是什么新鲜事了,基本上现在的强化学习算法都这样做了,包括我们这边拿了去年第一名的 Doom Bot,还有 ELF 里面为了训练微缩版星际而使用的网络设计。另外我记得之前他们已经反复提到用 Value network 对局面进行估值会更加稳定,所以最后用完全不用人工设计的 default policy rollout 也在情理之中。  让我非常吃惊的是仅仅用了四百九十万的自我对局,每步仅用 1600 的 MCTS rollout,Zero 就超过了去年三月份的水平。并且这些自我对局里有很大一部分是完全瞎走的。这个数字相当有意思。想一想围棋所有合法状态的数量级是 10^170,五百万局棋所能覆盖的状态数目也就是 10^9 这个数量级,这两个数之间的比例比宇宙中所有原子的总数还要多得多。仅仅用这些样本就能学得非常好,只能说明卷积神经网络(CNN)的结构非常顺应围棋的走法,说句形象的话,这就相当于看了大英百科全书的第一个字母就能猜出其所有的内容。用 ML 的语言来说,CNN 的 induction bias(模型的适用范围)极其适合围棋漂亮精致的规则,所以稍微给点样本水平就上去了。反观人类棋谱有很多不自然的地方,CNN 学得反而不快了。我们经常看见跑 KGS 或者 GoGoD 的时候,最后一两个百分点费老大的劲,也许最后那点时间完全是花费在过拟合奇怪的招法上。  如果这个推理是对的话,那么就有几点推断。一是对这个结果不能过分乐观。我们假设换一个问题(比如说 protein folding),神经网络不能很好拟合它而只能采用死记硬背的方法,那泛化能力就很弱,Self-play 就不会有效果。事实上这也正是以前围棋即使用 Self-play 都没有太大进展的原因,大家用手调特征加上线性分类器,模型不对路,就学不到太好的东西。一句话,重点不在左右互搏,重点在模型对路。  二是或许卷积神经网络(CNN)系列算法在围棋上的成功,不是因为它达到了围棋之神的水平,而是因为人类棋手也是用 CNN 的方式去学棋去下棋,于是在同样的道路上,或者说同样的 induction bias 下,计算机跑得比人类全体都快得多。假设有某种外星生物用 RNN 的方式学棋,换一种 induction bias,那它可能找到另一种(可能更强的)下棋方式。Zero 用 CNN 及 ResNet 的框架在自学习过程中和人类世界中围棋的演化有大量的相似点,在侧面上印证了这个思路。在这点上来说,说穷尽了围棋肯定是还早。  三就是更证明了在理论上理解深度学习算法的重要性。对于人类直觉能触及到的问题,机器通过采用有相同或者相似的 induction bias 结构的模型,可以去解决。但是人不知道它是如何做到的,所以除了反复尝试之外,人并不知道如何针对新问题的关键特性去改进它。如果能在理论上定量地理解深度学习在不同的数据分布上如何工作,那么我相信到那时我们回头看来,针对什么问题,什么数据,用什么结构的模型会是很容易的事情。我坚信数据的结构是解开深度学习神奇效果的钥匙。  另外推测一下为什么要用 MCTS 而不用强化学习的其它方法(我不是 DM 的人,所以肯定只能推测了)。MCTS 其实是在线规划(online planning)的一种,从当前局面出发,以非参数方式估计局部 Q 函数,然后用局部 Q 函数估计去决定下一次 rollout 要怎么走。既然是规划,MCTS 的限制就是得要知道环境的全部信息,及有完美的前向模型(forward model),这样才能知道走完一步后是什么状态。围棋因为规则固定,状态清晰,有完美快速的前向模型,所以 MCTS 是个好的选择。但要是用在 Atari 上的话,就得要在训练算法中内置一个 Atari 模拟器,或者去学习一个前向模型(forward model),相比 actor-critic 或者 policy gradient 可以用当前状态路径就地取材,要麻烦得多。但如果能放进去那一定是好的,像 Atari 这样的游戏,要是大家用 MCTS 我觉得可能不用学 policy 直接当场 planning 就会有很好的效果。很多文章都没比,因为比了就不好玩了。  另外,这篇文章看起来实现的难度和所需要的计算资源都比上一篇少很多,我相信过不了多久就会有人重复出来,到时候应该会有更多的 insight。大家期待一下吧。
作者: lu01    时间: 2018-5-4 05:58
与韩国职业高手对局 https://github.com/pytorch/ELF/releases
作者: lu01    时间: 2018-5-4 06:01
这份档案包含了2018年4月与四位KBA相关专业人员一起参加的14场比赛中的12场比赛(见本文)。 ELF OpenGo通过辞职赢得了所有比赛。  我们尊重玩家不要发布其中两款游戏的要求,并且我们也对游戏进行了匿名处理。 每个玩家至少在这个档案中包含两个游戏。  前两场比赛是使用ELF OpenGo模型权重较弱的预发布版本进行的。 对于每一次移动,ELF OpenGo都使用2个线程,每个线程10000次展开(分为4个批次)。  所有其他游戏都使用v0 pretrained模型(公开可供下载)播放。 对于每一次移动,ELF OpenGo使用2个线程,每个线程有40000个卷展栏(分为16个批次)。 这在V100 GPU上每移动大约需要50秒。  对于所有的游戏,没有对人类思维时间施加约束。  没有与此版本相关的源代码。
作者: lu01    时间: 2018-5-4 08:05
[attach]145217[/attach]

作者: lu01    时间: 2018-5-4 09:54
gcp转化的elf权重
http://zero.sjeng.org/networks/6 ... d02c9852097df4b9.gz

修改后的leelaz能使用上述权重
https://github.com/gcp/leela-zero/files/1972910/leelaz_elf.zip
作者: lu01    时间: 2018-5-4 11:12
elf vs leelaz 的998局
https://github.com/pytorch/ELF/r ... 9-2018-05-03.tar.gz
作者: lu01    时间: 2018-5-4 12:35
也有征子问题

yuandong-tian评论4小时前•

@croosn是的。我们有梯子的问题,但只要机器人发挥了第一个不好的举动,它会意识到并且不会被困住(尽管估计值会大大下降)。非常强大的机器人可能会利用这种弱点并赢得比赛,但似乎人类还不能。

有趣的是,在培训期间,我们发现阶梯问题的几个阶段,展示机器人如何学习它。

添加手动梯形检查(已经存在于旧的DarkForest代码中)将违反我们最初的动机:重新实现AlphaGoZero / AlphaZero,这意味着应用于游戏的零人类知识。所以我们只保留没有它的训练。

我们不打算构建最强大的机器人,而是探索AGZ / AZ算法的优缺点。这种算法似乎非常普遍,但可能存在DeepMind在本文中未提及的自己的问题。作为科学家,我们有责任找出问题并系统性地解决问题(使用更好的算法),而不是用短期的努力来解决问题。
作者: lu01    时间: 2018-5-4 12:40
Opengo权重测试(内有福利)        只看楼主[url=]收藏[/url]回复   
                                                                 
               
            
                                                            
            
                                    测试双方:
黑方:Opengov0 pretrained(20B224F)
白方:Leelazero18e6(15B192F)
贴目:7.5
用时:每步30秒
硬件:1060 3G
引擎:Leelaz引擎


测试情况:
因为用的都是Leelaz引擎,所以并没有Opengo原来对于N卡的优化效果。同时间的输出,20B224F的Opengo大约是15B192F的Leelaz的70%。
本局Opengo表现出厚重的棋风,先为不可胜,待敌有可乘之机,则雷霆一击,然后获些小利就毅然收手,绝不勉强攻击,牢牢把控局面,最后积少成多。
而Leelaz超爱耍大龙,每每逢凶化吉、起死回生,让人看得心惊肉跳,又大呼过瘾。总的来说,Opengo确实更胜一筹。









作者: lu01    时间: 2018-5-4 13:32
一个能读取elf权重的修改版客户端
leela_lizzie_elf
C:\leela_lizzie_elf>leelaz -w elf_converted_weights.txt
Using 2 thread(s).
RNG seed: 6481656193536936341
Leela Zero 0.13  Copyright (C) 2017-2018  Gian-Carlo Pascutto and contributors
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see the COPYING file for details.

Detecting residual layers...v2...224 channels...20 blocks.
Initializing OpenCL.
Detected 1 OpenCL platforms.
Platform version: OpenCL 1.2 CUDA 8.0.0
Platform profile: FULL_PROFILE
Platform name:    NVIDIA CUDA
Platform vendor:  NVIDIA Corporation
Device ID:     0
Device name:   GeForce GT 730
Device type:   GPU
Device vendor: NVIDIA Corporation
Device driver: 376.62
Device speed:  901 MHz
Device cores:  2 CU
Device score:  1112
Selected platform: NVIDIA CUDA
Selected device: GeForce GT 730
with OpenCL 1.2 capability and FP16 precision.

Started OpenCL SGEMM tuner.
Will try 290 valid configurations.
(1/290) KWG=16 KWI=2 MDIMA=8 MDIMC=8 MWG=16 NDIMB=8 NDIMC=8 NWG=16 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 2.3005 ms (69.8 G
FLOPS)
(2/290) KWG=16 KWI=2 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=16 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 1.7344 ms (92.6 G
FLOPS)
(5/290) KWG=16 KWI=2 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=32 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 1.5460 ms (103.9
GFLOPS)
(8/290) KWG=16 KWI=2 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=64 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 1.3205 ms (121.6
GFLOPS)
(69/290) KWG=16 KWI=8 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=64 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=2 1.1971 ms (134.1
GFLOPS)
(160/290) KWG=16 KWI=8 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=64 SA=1 SB=1 STRM=0 STRN=0 VWM=4 VWN=2 1.1265 ms (142.
5 GFLOPS)
(226/290) KWG=16 KWI=8 MDIMA=8 MDIMC=8 MWG=32 NDIMB=8 NDIMC=8 NWG=64 SA=1 SB=1 STRM=0 STRN=0 VWM=2 VWN=4 1.1059 ms (145.
2 GFLOPS)
Wavefront/Warp size: 32
Max workgroup size: 1024
Max workgroup dimensions: 1024 1024 64
BLAS Core: Prescott

Passes: 0            Black (X) Prisoners: 0
Black (X) to move    White (O) Prisoners: 0

   a b c d e f g h j k l m n o p q r s t
19 . . . . . . . . . . . . . . . . . . . 19
18 . . . . . . . . . . . . . . . . . . . 18
17 . . . . . . . . . . . . . . . . . . . 17
16 . . . + . . . . . + . . . . . + . . . 16
15 . . . . . . . . . . . . . . . . . . . 15
14 . . . . . . . . . . . . . . . . . . . 14
13 . . . . . . . . . . . . . . . . . . . 13
12 . . . . . . . . . . . . . . . . . . . 12
11 . . . . . . . . . . . . . . . . . . . 11
10 . . . + . . . . . + . . . . . + . . . 10
9 . . . . . . . . . . . . . . . . . . .  9
8 . . . . . . . . . . . . . . . . . . .  8
7 . . . . . . . . . . . . . . . . . . .  7
6 . . . . . . . . . . . . . . . . . . .  6
5 . . . . . . . . . . . . . . . . . . .  5
4 . . . + . . . . . + . . . . . + . . .  4
3 . . . . . . . . . . . . . . . . . . .  3
2 . . . . . . . . . . . . . . . . . . .  2
1 . . . . . . . . . . . . . . . . . . .  1
   a b c d e f g h j k l m n o p q r s t

Hash: 9A930BE1616C538E Ko-Hash: A14C933E7669946D

Black time: 01:00:00
White time: 01:00:00

Leela:

作者: lu01    时间: 2018-5-4 13:38
lu01 发表于 2018-5-4 13:32
一个能读取elf权重的修改版客户端
leela_lizzie_elf
C:\leela_lizzie_elf>leelaz -w elf_converted_weigh ...

https://github.com/Ka-zam/leela-zero/releases

作者: lu01    时间: 2018-5-4 14:02
https://github.com/gcp/leela-zero/files/1972910/leelaz_elf.zip 也可以用elf权重

作者: lu01    时间: 2018-5-4 14:26
gtp命令用法

play b c1把黑子下在c1
genmove w给出白子选点

Leela: play b c3
=


Passes: 0            Black (X) Prisoners: 0
White (O) to move    White (O) Prisoners: 0

   a b c d e f g h j k l m n o p q r s t
19 . . . . . . . . . . . . . . . . . . . 19
18 . . . . . . . . . . . . . . . . . . . 18
17 . . . . . . . . . . . . . . . . . . . 17
16 . . . + . . . . . + . . . . . + . . . 16
15 . . . . . . . . . . . . . . . . . . . 15
14 . . . . . . . . . . . . . . . . . . . 14
13 . . . . . . . . . . . . . . . . . . . 13
12 . . . . . . . . . . . . . . . . . . . 12
11 . . . . . . . . . . . . . . . . . . . 11
10 . . . + . . . . . + . . . . . + . . . 10
9 . . . . . . . . . . . . . . . . . . .  9
8 . . . . . . . . . . . . . . . . . . .  8
7 . . . . . . . . . . . . . . . . . . .  7
6 . . . . . . . . . . . . . . . . . . .  6
5 . . . . . . . . . . . . . . . . . . .  5
4 . . . + . . . . . + . . . . . + . . .  4
3 . .(X). . . . . . . . . . . . . . . .  3
2 . . . . . . . . . . . . . . . . . . .  2
1 . . . . . . . . . . . . . . . . . . .  1
   a b c d e f g h j k l m n o p q r s t

Hash: EBBE1A1739BEEC90 Ko-Hash: 7BAC2905857680BE

Black time: 01:00:00
White time: 01:00:00

Leela: play w d3
=


Passes: 0            Black (X) Prisoners: 0
Black (X) to move    White (O) Prisoners: 0

   a b c d e f g h j k l m n o p q r s t
19 . . . . . . . . . . . . . . . . . . . 19
18 . . . . . . . . . . . . . . . . . . . 18
17 . . . . . . . . . . . . . . . . . . . 17
16 . . . + . . . . . + . . . . . + . . . 16
15 . . . . . . . . . . . . . . . . . . . 15
14 . . . . . . . . . . . . . . . . . . . 14
13 . . . . . . . . . . . . . . . . . . . 13
12 . . . . . . . . . . . . . . . . . . . 12
11 . . . . . . . . . . . . . . . . . . . 11
10 . . . + . . . . . + . . . . . + . . . 10
9 . . . . . . . . . . . . . . . . . . .  9
8 . . . . . . . . . . . . . . . . . . .  8
7 . . . . . . . . . . . . . . . . . . .  7
6 . . . . . . . . . . . . . . . . . . .  6
5 . . . . . . . . . . . . . . . . . . .  5
4 . . . + . . . . . + . . . . . + . . .  4
3 . . X(O). . . . . . . . . . . . . . .  3
2 . . . . . . . . . . . . . . . . . . .  2
1 . . . . . . . . . . . . . . . . . . .  1
   a b c d e f g h j k l m n o p q r s t
作者: lu01    时间: 2018-5-4 14:26
本帖最后由 lu01 于 2018-5-4 14:32 编辑

Leela: genmove b
Thinking at most 90.0 seconds...
NN eval=0.650270
Playouts: 10, Win: 53.06%, PV: D4 E3 E4 C2 C4 G3 Q4 C16
Playouts: 48, Win: 62.35%, PV: D4 E3 E4 C2 C4 G3 Q4 C16 Q16 F17 G16 F16 G15
Playouts: 178, Win: 65.26%, PV: D4 E3 E4 C2 C4 G3 Q4 C16 Q16 F17 F4 H2 B2 R17 Q17 R16 R14
。。。
  E3 ->    3133 (V: 32.84%) (N: 99.27%) PV: E3 E4 C2 C4 G3 D16 Q3 R5 Q16 P4 R4 S4 Q5 Q4 R3 R6 O3 O4 N3 N4 S3 F4
17
  Q4 ->       0 (V:  0.00%) (N:  0.27%) PV: Q4
15.3 average depth, 32 max depth
2368 non leaf nodes, 1.32 average children

3134 visits, 1080243 nodes

sses: 0            Black (X) Prisoners: 0
ite (O) to move    White (O) Prisoners: 0

a b c d e f g h j k l m n o p q r s t
. . . . . . . . . . . . . . . . . . . 19
. . . . . . . . . . . . . . . . . . . 18
. . . . . . . . . . . . . . . . . . . 17
. . . + . . . . . + . . . . . + . . . 16
. . . . . . . . . . . . . . . . . . . 15
. . . . . . . . . . . . . . . . . . . 14
. . . . . . . . . . . . . . . . . . . 13
. . . . . . . . . . . . . . . . . . . 12
. . . . . . . . . . . . . . . . . . . 11
. . . + . . . . . + . . . . . + . . . 10
. . . . . . . . . . . . . . . . . . .  9
. . . . . . . . . . . . . . . . . . .  8
. . . . . . . . . . . . . . . . . . .  7
. . . . . . . . . . . . . . . . . . .  6
. . . . . . . . . . . . . . . . . . .  5
. . .(X). . . . . + . . . . . + . . .  4
. . X O . . . . . . . . . . . . . . .  3
. . . . . . . . . . . . . . . . . . .  2
. . . . . . . . . . . . . . . . . . .  1
a b c d e f g h j k l m n o p q r s t

sh: 9ED3B4D3AF516C12 Ko-Hash: EC187C11399003C

ack time: 00:59:14
ite time: 01:00:00

作者: lu01    时间: 2018-5-4 16:48
作者:田渊栋
链接:https://zhuanlan.zhihu.com/p/36355033
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


写完了官方报告现在写一点自己的感想。
这个项目不是为了做最好的围棋程序,不是说要打败谁。我们做这个是因为以下三个目的:
(1) AlphaGoZero/AlphaZero算法很有意思,我们想知道为什么它有效果,是怎么会有效果的,是不是如同宣传的那样是百试百灵的通用算法,是不是只要堆机器,强人工智能马上就来了?还是说其实这个算法有什么问题和弱点?DeepMind不开源也不透露细节,文章里面一些地方也没有写得很清楚。我之前写过Blog讨论过,但是没有第一手经验总不是很踏实。所以本着研究目的,我们需要复现一下,先有复现,才有创新,这个是做研究的习惯。
(2) 今年年初我重写了ELF的核心代码,另外也加了分布式训练,需要找个具体应用来测试一下。站在这个角度上,AlphaGoZero/AlphaZero是个完美的选择,再说之前也有DarkForest的代码和围棋程序的经验,所以把它们拼起来不用花太多力气。
(3) 不管是通用算法还是分布式平台,都可以用来干很多别的事情,不一定是围棋,不一定是游戏。如果我们去看ELF OpenGo的代码,会发现其实很大一部分和围棋一点关系也没有,完全适用于其它方向的工作。而围棋对我们来说,只是一个把算法和平台做好的手段。在这一点上,花点时间把围棋做好是值得的。
两年前为什么我决定停止做DarkForest,主要是因为当时科研上再做围棋价值不大了;现在继续做这个,主要是因为AGZ/AZ作为一个一般化的算法非常有趣,研究它可能会有新的感悟,能对问题有新的理解——这个是科学的最终目的。
今天ELF OpenGo终于发布,我觉得这三个目的都达到了,而且为整个研究界贡献了我们在探索中所获得的知识,非常高兴。
这个项目从今年一月开始,做了四个月不到的时间。首先写了一个AZ的版本,效果不是很好;然后写了AGZ,效果还是一般;直到我发现一个PyTorch的bug(见KLDivLoss behaves differently on CPU/GPU · Issue #5801 · pytorch/pytorch,GPU下梯度有错,CPU下正常),修掉了之后,AI水平就像野马奔腾一样往上冲,令人叹为观止。最后为了加快速度又换成了AZ。要是从一开始就没有这个bug,很可能可以提前两个月发布。大家要是做VAE,GAN或者有任何用到KL divergence的地方,要注意用最新的PyTorch,免得掉坑里面。当然有这几个转折后的好处是我们对整个系统的行为有了更深的理解,同时发布的代码里可以选择是用AGZ或者AZ,或者其它的中间方案。
整个新版ELF,分布式框架及快速蒙特卡罗搜索的代码是我搭建起来的,部署在CGOS和LeelaZero上的实验,还有半精度前馈网络的测试由龚渠成负责,各种分布式部署、调参、蒙特卡罗搜索的测试及代码重构由Jerry和Shubho还有卓远负责,Larry则提供了巨大的支持。这里感谢大家的辛勤工作!另外吴育昕在整个项目中也帮了挺多忙,还要感谢公司提供的大量资源,不然最后的模型不会有那么好的效果,更不用说能在无时限慢棋中以单卡战胜职业高手。
插个花絮:之前大家在猜测CGOS上那些以美国总统和朝代为名(除了jin_lee)的bot都是谁,其实那些都是我们各种不同版本的bot。本来是要用朝代名序列的,不过不知道是谁搞了个 jin_lee抢了先,所以切换成了美国总统序列。
作者: hred9D    时间: 2018-5-4 23:15
看看自己的破笔记本,哎,首先得有一台高配的电脑
低端笔记本,在参数上面动动脑筋,或可以提高一点点计算效率。
ELF open狗拿到公司服务器上面跑一跑,,,哈哈
作者: lu01    时间: 2018-5-5 12:49
leelaz 0.14发布了,支持elf https://github.com/gcp/leela-zero/releases
作者: lu01    时间: 2018-5-5 12:55
关于ELF OpenGo一些问题的回复  7 小时前 · 来自专栏 远东轶事 最近网上很多讨论我们刚发布的ELF OpenGo的热帖,没有时间一一回复了。我把一些问题统一起来在这里回复一下。  首先非常感谢LeelaZero团队以最快的速度把我们的权重转成了LeelaZero可以用的格式,这样大家可以在第一时间看到我们这个AI的水平,并且能亲手验证。这个充分说明了我们的工作是可重复的,并且可以造福大家。我们感到非常高兴。  大家可能会觉得这个版本在较少搜索次数(rollouts),比如说每步800或者1600的时候效果没有那么好。这个是因为我们在蒙特卡罗搜索(MCTS)里面用了batching,比如说每8次或者16次搜索(rollout)放一起送给神经网络,这样GPU的效率会高很多。内部测过加和不加batching,在同样搜索次数下,可能要差几倍的速度。但是副作用就是会影响棋力。这个是因为MCTS本来就是个串行算法,理想情况下应该是每一步新的搜索都依赖之前所有搜索的胜率估计;现在每8次或者16次搜索统一处理,那就不是理想情况了。这个问题在较少搜索次数时尤为严重,因为每一次搜索都尤其宝贵。解决的办法当然是减少batch的大小,像800或者1.6k这样的,batchsize选4会比较好(对应的开关是--mcts_rollout_per_batch 和 --batchsize),但是这样速度确实会慢一点。batchsize选16只适合于总搜索次数多(比如说每步80k)的情况,当然更大的batchsize就没有什么好处了。  接下来大家可能会问在自对弈的时候这个要怎么办。自对弈的时候每步只有1.6k的搜索次数,不batch速度慢,batch了棋力变差,两难啊。这里就要提到ELF的好处了。我们自对弈的时候是每个GPU上同时跑32个棋局,开32个独立的MCTS搜索,然后总的batchsize是128。每个棋局上完全没有batch,就把当前搜索的单个局面送给ELF,让ELF去动态batch不同棋局的局面,然后绑一起送给神经网络,这样就兼顾了效率和棋力。在这种设置下,batchsize不再是个常数,基本上平均batchsize在90左右,已经是很好的了。当然副作用是一开始自对弈会出来得慢些。  英文版见:Answer some questions about batchsize.  · Issue #25 · pytorch/ELF
作者: 扳黏童男    时间: 2018-5-7 15:14
星陣算法的ai可以適應古棋規則嗎?
作者: hred9D    时间: 2018-5-7 17:44
征子问题没有解决,但是棋力强于目前的里拉,opengo白棋

[attach]145274[/attach]


[attach]145273[/attach]







欢迎光临 飞扬围棋 (http://flygo.net/bbS/) Powered by Discuz! X3.2