コンピュータ将棋の近況(2021年4月)

変な時間に起きてしまったので寝起きポエムでも書きます。

先日も講演依頼があったので恥ずかしいが簡単な自己紹介から入りました。

コンピュータ将棋参加は2017年の第5回電王トーナメントからで,電王トーナメントを見たのはその前年か第3回かくらいだったと思います。そもそも機械学習というものを触ったのが2017年でした。

偶然にも初参加で準優勝して以来世界選手権参戦し4年間1位か2位を維持しています。相当の強運かと感じます。

 

誤解があってはいけないのですが,まず例年皆相当強くなってます。

私は研究職と言う立場上技術的なものは独占より広く普及する方が良いと思っているので説明データが整い次第公表するようにしてます。参考にして頂いていることが多いので一年後には類似技術が普及する様子は分かります。

新技術を導入したものに対して単純な古典的レーティングを出すのは誤解が多くあまり適したものと思っていないので伏せておきますが,一年ごとに強化されており二年差あると別世界と言えるレベルで対戦成績が出ます。戦型もがらっと変わっている雰囲気です。

つまり一度上位を得たといってそれを維持するのは相当向上しているってことです。

上位陣の入れ替えを見れば分かるかもしれません。

 

それに加え強い方が勝つってのも漠然とした話でfloodgate的にも下剋上はイメージしているより多く発生しているのは分かると思います。

経験的にKristallweizenの評価関数公開直後などは非常に対戦成績が安定していたのですが,これは同じ評価関数で性能の違うPCで多数投入されていたんじゃないかと推察しています。これは完全に強弱で勝ち負けがきれいに割れます。

現状選手権前ってこともあって多種多様のエンジンが投入されています。特に私は多目に放り込んでいます。

 

正直運がいいだけだと第5回電王トーナメントでは思っていましたが,ある程度データを取ると統計的に優位が示されるという感じになっています。ただ,強い弱いが一列に並ぶイメージは未だもっていません。単純に戦型って話でもありません。

ざっくり将棋はそんなに浅くないって感じでしょうか。

事実私が事前調査した頃と比較して,平均手数でも相当変化が出ているとCSA瀧澤会長も近年強く強調されています。今は200手以上の棋譜が珍しくなくなりました。

もしかすると近いうちに囲碁棋譜より長くなるのかもしれませんし,既に序盤中盤終盤の分類基準が変わって来ている感じもしています。定量的な再定義ができればとか考えています。

 

ええ,割とカオスな思考状態ですしそういう乱戦だと認識しています。

選手権前はfloodgateに投入して自分の位置を確認するのはそういう不安を払しょくする意味があるのでしょう。

実験系のエンジンは低めに,古い評価済みエンジンは高めのマシンで放り込んであります。興味ある人は御確認頂ければと思います。

Kristallweizen-TR2990WXが上位にいるままなんです。二年前の評価関数に二年前のPCです。ちょっと胃液上がってくる気分ですね。

 

今年の選手権は特に深層学習系がエントリー多いようですので対戦相性的な問題が多数発生しそうで乱戦必至といった感じでしょう。

たらたらと書いているうちに何か頭の整理になると思ったのですが無理ですね。

今年の選手権には松下さんに無理言って白ビールと二番絞りの両方を投入します。

floodgateより少し上の世界を二日間だけお見せできると思います。

(十分準備ができているとは言ってない)

p800という制限

f:id:the48:20210420092124p:plain

 

AobaZeroでp800を基準で投入されてます。最近になってポリシーのみの対局でレート2150程度と実験されてます。

コンピュータ将棋や囲碁の掲示板

 

うちの子もfloodgateで5b, 15b, 40bを投入してみました。

15bと40bは代り映えがしない感じでAobaZeroと同じゾーンにおりますね。5bは2800しかありませんので,探索ノード数を4倍にしてみましたが結局3000に満たない感じです。(ただ,これ3200ノードにしてもGTX1060で1秒未満です)

 

大凡分かるのが15bと40bはAobaZeroと遜色ないくらい学習ができている感じです。(贔屓目に見ると15bとか勝ってるようにも見える)

5bは同ノード比較すると論外だけど15bの三倍速く計算可能なので時間当たりノード数は相当伸びます。同GPUでノード制限なしならAobaZeroよりやや強いところまで行くかんじです。

 

で,ノード制限ってのが相当弱くなるのが分かりますが,これでいいのかってことですね。例えばp800だとKristallweizenの1000kとelmoの10Mとgikou2_1cが三枚僅差のレートで抑え込む形になってます。たまたまレート順に探索ノード数が多く,これは探索深さ順にもなっていると思われます。

そこでふと考えてみるとp800ってどこまで深く探索可能だろうかと。もしかして評価関数関係なくp800でこれら(特に後者二つ)を打ち負かすのって相当高難易度なんではないかと考えました。

 

真面目に書いてると卒論くらいのネタにはなるでしょうか?

---

 さらに4倍してp12800放流中です。こういうのを見る限りp800では頭押さえられるんじゃないかという仮説が強化されます。

酔猿の件(電竜戦予行5の顛末)

ABEMAトーナメント開幕でしたね。

船江先生がひとり満足気な表情だったので勝負師の気質ってものを感じました。

ずっとそっちを見てたので電竜戦予行5は対戦開始を確認しただけで放置プレイでした。運営に不具合はなかったようですね。

カツ丼さん乙です。

 

こっちはと言うと,3つ投入しておりました。

 

二番絞りは深層学習系で最新モデルです。マシンはRTX2060のノートなので昨年の電竜戦決勝と同じPCです。同じモデル(40ブロック10週目)がRTX3070で現在floodgateに放流中です。

地ビールは以前からGo言語で0から作ってあるエンジンでアルゴリズムのテスト等に使っております。半年くらい放置してどこまで更新したか自分でもメモ見ないと忘れています。

予行4のshotgunは不評のようで,今回の3つ目が酔猿です。

 

白ビール系列で放り込んでもよかったのですがKristallweizenは一般ユーザでもfloodgateでも広く普及して2年ですから見飽きている感があるのでちょっと変えてみました。

二番絞りのインフラとして用いているdlshogiですが,指し手生成や局面データ構造の部分はAperyから流用されています。そこでバックポートを試みました。

 

考えたことは単純です。

二番絞りの逆ですね。最新の深層強化学習で生成した教師データを今やクラシックと言える三駒関係のモデルに適用するとどうなるかという実験です。

AperyのソースをダウンロードしてきてLEARNオプションを有効にしてビルドするくらいのことですので技術的にも簡単ですし,数億局面のデータも一晩くらいで学習を終えました。

簡単に確認してみたところApery SDT5といい勝負をする感じです。当時もやねさんが絶賛されていましたがApery SDT5は三駒関係では抜群の逸品です。膨大な計算量か高度な統計処理か詳細は知りませんが滑らかでバランスの良いものです。

これに対して数億程度の流用データで作成したものはさすがに対戦中でも粗が目立つくらいの変動具合です。それに深層学習系でありがちな初期局面相当先手有利評価ですし振り飛車に辛い点付けです。しかしながら戦型選択はモダンになっています。その辺で相殺されて互角級になっているのでしょう。

想定より弱いイメージでしたので,普通のPCと言いながらRyzen 1700搭載ノートPCを選択しておきました。(2018年選手権現場でクジラ養分になってたやつ)

命名が毎回苦労しており,今回は映画酔拳のDrunk Monkeyをもじりました。

結果は御覧の通りです。

第2回世界将棋AI 電竜戦 予行演習5 勝敗表

 

42チーム参加で,10位二番絞り,21位酔猿,30位地ビールです。

 

bleu48.hatenablog.com

ええ,予行4と同じで3つ放り込んでほぼ四分点を押さえてます。

計算通りですね。(事後諸葛亮

CUDA11.2Update2 on Windows10(メモリリークとCUDAの作業メモ)

先日(2021年3月17日付け)のドライバアップデートから一部のマシンでメモリリーク祭がはじまった。

基本的にGPUの類は最新ドライバを使うのが最もパフォーマンスが出るとして推奨される。

実際他のハードウェアに比べアップデート頻度が高い。

 

様々なバージョンチェックの結果CUDAもアップデートしてやるとメモリリークが止まるらしいことを確認した。詳細な前後のバージョンやハードウェアの世代依存に関する詳細までは未確認である。

実際のリーク量は微量で一日中機械学習をするような真似をしない限り表にでないと思う。ただ,私には致命的だっただけだ。

 

 

で,CUDA11.2Update2という最新のものを入れてみたのだが一部動かないものがあった。

対応のTensorRTが7.2.3.4ということで同時に入れておいたのだが,この中のnvinfer.dllがCUDA11.1に入っているnvrtc64_111_0.dllに依存しているらしい。

これだけのために複数バージョンのCUDAを入れる気にもならないので,CUDA11.2に入っているnvrtc64_112_0.dllをコピーしてリネームしてやったら動いている。真似してはいけない。(バイナリエディタでバージョン弄るのとかもダメだ)

 

確認に使ったツールは以下。

GitHub - lucasg/Dependencies: A rewrite of the old legacy software "depends.exe" in C# for Windows devs to troubleshoot dll load dependencies issues.

 

まぁ,MSあるあるなんだがバージョン依存のライブラリとそうでないものがあると見せかけてnvinfer.dllなんてバージョン依存が無さそうに見えるものが依存してるというトラップである。(本件はNVIDIAだが)

ということで酷い対応だが公式バイナリも相当酷いことを確認して,しばらくこのまま様子見する。

 

年に一度あるかないかくらいだが酷い不具合に遭遇する。

今年は年始にWindowsのバッチファイルにおいてREM文(コメント文)が8192文字を超えると勝手に次の行になって解釈される不具合を発見した。一応報告しておいたが修正されるのだろうか。

そもそもREM文が無ければ一行8192文字を超えるバッチファイルが動いているのが結構感動ものであった。コマンドラインで引数400個くらい付けた気がする。

---

追記:

バッチファイルの一行上限が8192byteであるのは仕様らしい。

QUICハンズオン(GDG四国)

gdgshikoku.connpass.com

 

ハンズオン中のメモ。

 

ハンズオンだとちょっとしたところで躓く。

環境変数の設定

コマンドプロンプト:set

PowerShell

Set-Item Env:GOPATH "c:\test1\test2;"

または

$ENV:GOPATH="c:\test1\test2;"

確認はGet-ChildItem env:

 

go.modは手で作らない方がよさそう。(1.16以降デフォルトで必須)

go mod init

 

Tamさんは全集中で鬼滅ネタ

 

ALPNが強い!

Application-Layer Protocol Negotiation - Wikipedia

 

以下略。

QUICでしょぼいサーバとしょぼいクライアントを作られるようになった。

参考URL

GitHub - lucas-clemente/quic-go: A QUIC implementation in pure go

GitHub - tamx/quic-go-test

 

---

追記:

岩田プロの成果物のURLを残しておきます。

 

選手権の準備その2

しばらく囲碁にかまけてたのですが,そう言えば月末がアピール文の締切でした。

今回は以下の経緯で「二番絞り」でエントリーしましたので作文としてはそれなりに書くものがありますが,先日のゲーム情報学研究会で発表済みですのでズボラ人間にはコピペ(もしくはURL提示)で終わらせて良いかとの腹案も浮かんできます。

 

bleu48.hatenablog.com

 

以下,作文下書き。

 

二番絞りプロジェクト自体はそもそも電竜戦のサーバテスト用に多様性のあるエンジンでテスト対局をしたいとのネタで始めたものです。

その元ネタとなる深層学習部は山岡さんがdlshogiを始めたのとほぼ同時期に私も独自に始めたエンジンがスタート地点です。既に独自改造していたものに適当な教師データを食わせることで従来無い中途半端なものが生成できれば御の字との考えでした。終盤弱く頓死するとか,見たことのないような戦型が得意とか,考慮時間を使うのに弱いとか何か違えばテスト用には有用だろうとのことです。もちろんスコア付け,組み合わせ抽選などの工程で不具合が無いか実時間でどのくらいかとの計測が重要ですからね。

 

比較的小規模な学習モデルを既に作ってあった教師データで学習させたものが初期の二番絞りでしたが,そこそこ強くなることが確認できました。その後,よりよい教師データは無いかと考えて流用したのがAobaZeroの自己対戦棋譜でした。普通の教師データは大量に作るため生成コストを考え浅い探索を行うのですが,AobaZeroは複数年に渡り強化学習を進めており,また各モデルはfloodgateでのレートが出ているというお墨付きの棋譜データです。しかしながら,棋譜のみであり局面評価値が含まれていないのが欠点でした。そのため専用の学習機を用意しました。(GCTでは評価値0として教師データを混入させたらしいですがちょっと乱暴に思います。)

 

実のところAobaZeroのモデルをデータ変形するだけでPyTorchで使えるモデルを作ろうとも考えたのですが棋譜を学習させる方がコーディングコストが低いため先に学習から行ったというのが本音のところです。ですから,理想的にはAobaZeroと同等のモデルがPyTorch化されればOKというのが構想です。ということでここで,20ブロック256チャンネルのネットワークサイズが決定されました。

 

2週間程度かかったのですが,概ね似たようなものが完成したかなというのが電竜戦予行3回目だったかと思います。それでも対戦時人間の目にも若干甘い部分があるように見受けられました。

そこからはより良い教師データが存在しない域,つまり自己対戦による強化学習を加えることになります。予行4回目が強化学習1段階目,電竜戦本戦が強化学習2段階目です。AlphaZeroやAobaZeroでは教師データを作るたびに少量加えて過去のものを少量削って多くをオーバーラップさせて小さく強化学習をおこなうのですが,本件は強化学習初期段階で何もありません。AobaZero教師とはデータの互換性もありません。ということで,第1段階である程度の量を貯める工程に入りました。大凡1億局面程度できた段階で学習させました。(というより残り3日で教師生成を止めて学習に入ったというのが本音ですね)

 

電竜戦での結果は御存知の通りですが,以後学習を進めております。

とくに強化学習時に生成したデータを流用した実験を多数行い多くのデータ構造のモデルを生成しております。そういえばこれはNNUEのときも同じでした。ネットワーク構造を多くつくり最も適したものを見つける手作業です。

本件では15ブロック,20ブロック辺りが上手にできておりましたが,つい最近40ブロックでそこそこ良いものが出来るようになりました。

旧世代のGPUを用いてもfloodgateでそこそこの戦いが出来ております。具体的には以下の記事のような感じですね。

bleu48.hatenablog.com

 

5月の選手権では最も出来の良いものを投入予定ですが現時点ではどれと断定はできません。あしからずご了解下さい。

UEC杯雑感

bleu48.hatenablog.com

bleu48.hatenablog.com

 

以上に参加者としての私視点のページは書きましたが,会期中に余裕がなく他のチームの動向は見ておりませんでした。特に上位を占めた強豪の動向を中心に簡単にまとめてみました。

 

1.中国勢のレベルが違う

中国からの参加チームは4チームでしたが,全てAリーグ進出。決勝では1位2位4位5位と上位独占と言っていい状況でした。3位がKataGoなのですがUEC杯でこの順位なのかと驚愕です。KataGoはオープンソースで開発されているので良い練習ターゲットになっているのでしょう。

特に最終戦のKataGo vs RankaGoではRankaGoの半目勝ちを双方認識しており,判定でやきもきしていたのは人間だけだったとの辺りがAIのコンペらしい展開でした。

Bリーグで目数読み違ってたのとは大違いです。

 

2.世代が違う

私はおっさんですが,他のチームは比較的若い人だそうです。また,技術的にもAlphaGoのコピーから完全に一線を越えているようで追い付くだけで息切れしているようでは歯が立ちません。

優勝のVisionGoおよび6位のKohadaではInceptionモデルが使われており,またVisionGoは探索時の枝刈りを行っているとのことでした。

汎用技術を売りにしたAlphaZeroとは異なり専用のものとして改良が施されているようです。将棋で身に着けた技術利用だけで突貫工事した私が全く勝ち目ないわけです。

 

3.棋力が違う

2位に入ったRankaGoの開発者はプロのチェスプレイヤーだそうです。KataGoのWuさんも囲碁の高段者ではないかと懇親会で話がありました。中国勢は当然のようにチーム内に上級者がいるものと思われます。

見えている世界が違うんだろうなぁと思います。私がたまたま将棋で成功を修めたのもなんとなく盤面が読める棋譜に親しみがあるなどのアドバンテージが大きかったと再認識しました。正直大会中盤面見ても何もわからず,特に自分の対局が早めに終わるとうとうとすることが多かったです。興味・好奇心は不可欠ですね。

 

4.恐らくマシンパワーが違う

うちはRTX3090を2枚用いました。Bリーグでは演算力で勝っていたように感じます。特に囲碁知識がないので軽量な局面評価を暴力的な探索で補う策で準備していました。日本ルール実装の甘いチームなどを終盤で崩せたらいいなあ程度の妄想でしょうか。

KataGoや中国勢はクラウドを使っていたようですので恐らく8GPUなどのインスタンスでしょうか。意気込みも違いますね。

この辺は公平にするとまではしなくてもスペック公表義務くらいあっても良い気がします。

 

5.組織力が違う

懇親会で話題になった点ですが,日本では研究組織レベルで取り組んでいるチームが皆無です。今回も私含め個人参加が多かったように思います。

しかしながら,今大会に限らず開発規模を考えると多人数で分担し組織的な開発が上位を争うには不可欠と思われます。特に探索部の改良と深層学習モデルの改良を一人で行うのは技術・知識・労力すべての面で酷です。加えて資金力でしょうか。

とは言っても私自身「どこかのチームに加えてくれないか?」と打診しても断られることが多いので,この分野の人達は皆一匹狼気質なのかもしれません。

組織的に開発が行われていない弊害としてサーバの安定性やドキュメントの不整備などが結果として出てきます。電竜戦サーバの例を挙げるまでもなく将棋の方がずっと進んでいることは言うまでもありません。

勝敗判定の公式オープンソース実装がない状態で強化学習の練習対象にするのは非常に困難だと何度も書いておきます。

 

以上,突貫工事で参加した大会の雑感でした。

個人的には2年ほど前にGo言語の習作で作ったプログラムをきふわらべ化されたのがきっかけですが,結局PythonC++で(他のソフトのルーチンを流用しながら)組むことになりました。シチョウや目算ミス含めて致命的な不具合が相当ありそうなので今後の課題とさせて頂きます。

---

3/28追記:

某所で日本勢3位とコメント頂きました。

そう言われればそうなんですね。

順位気にするところまで考えてません。とりあえず短期開発にしてもシチョウ対応なしは酷かったと反省しております。