機械学習周りのプログラミング中心。 イベント情報
ポケモンバトルAI本電子書籍通販中

DNNの方策に従来型エンジンのbestmoveをブレンドする 実装編 part02【コンピュータ将棋】

前回、dlshogiのDNN評価と同時にelmoを呼び出し、bestmoveを取得して利用する最低限の実装をしました。その結果、無改造のdlshogiだと2500nps程度出るところ1900nps程度まで下がるという結果でした。今回はこのnps低下の原因究明と改善を行い、無改造のdlshogiと対戦して比較します。結果からいうとレート+70程度の改善になりました。

elmoの探索にかかる時間

elmo (探索部はやねうら王)にランダムな局面を与え、一定ノード数の探索をさせた場合の所要時間を測定しました。pythonからプロセス間通信を用いてpositionコマンドで(互換局面集から抽出した)ランダムなSFENを与え、次にgoコマンドをbyoyomi 100をつけて発行します。エンジンのオプションは、Threads:1,EvalHash:16とし、探索ノード数を表すNodesLimitを変えて所要時間を測定します。

NodesLimit 1回あたりの実行時間[ms]
10 0.14
100 0.20
1000 1.1
10000 10

結果は上の表のようになりました。ノード数1000だと1.1msかかるため、2プロセス並列で動作させれば(1000ms/1.1ms*2プロセス=1818なので)1900npsになるのはほとんどがgoコマンドの処理時間であり、dlshogiとpython間の通信のオーバーヘッドは小さいと考えられます。また、1000ノードから10000ノードでの所要時間はおよそ10倍になっており、pythonとelmo間の通信のオーバーヘッドも少なく、実際の探索にかかる時間が大部分と考えられます。そのため、プロセス間通信関係を高速化するメリットは少ないと思われます。なお、ノード数100, 10の場合は所要時間が線形には減っていません。1000ノード以下を指定しても探索が正確に少ないノード数で停止しないことと、プロセス間通信のオーバーヘッドが表れているものと考えられます。

以上のことから、dlshogi上のnpsを増加する手段として、並列に動作させるプロセス数を増加させる必要があります。前回時点の実装では、dlshogiの探索スレッドとelmoのプロセスが一対一対応していたので2並列での動作になっていました。今回は、python上の実装を変更し、リクエストをキューに蓄積して4つ(CPUのコア数)のelmoプロセスに割り振る機構を実装しました。実装の結果、無改造のdlshogiだと2384npsのところ、elmoを呼び出してbestmoveを利用する実装が2220npsまで高速化しました。もともとdlshogi自体がCPU使用率30%程度なのでコアの取り合いになり、これ以上の高速化はCPUのコア数を増やさない限り難しいでしょう。

強さ比較

dlshogiとの実時間での比較

1手1秒で、無改造のdlshogiとの比較を行いました。これで勝っていればnps低下があっても読み筋のブレンドに効果があるといえます。dlshogiのバッチサイズは16固定、elmo側の探索ノード数は1000で固定しています。

policy比率[%] value比率[%] 勝-負-分
0 0 44-51-5 (46.5%)
1 0 46-48-6 (49.0%)
2 0 46-50-4 (48.0%)
5 0 59-39-2 (60.0%)
10 0 52-44-4 (54.0%)
20 0 38-62-0 (38.0%)
5 2 52-43-5 (54.5%)
5 5 52-45-3 (53.5%)
5 10 51-41-8 (55.0%)

結果として、policyにelmoの読み筋を5%ブレンドしたものが最も強く、無改造dlshogiに対してレート+70程度となりました。有意に強くなったのはこのパラメータのみです。valueブレンドについてはマイナスの効果しか得られませんでした。

elmoとの比較

elmoと1手1秒で比較しました。ブレンドdlshogiのパラメータは、前の節で最善だったpolicy5%, value0%です。

測定対象 基準 勝-負-分
無改造dlshogi elmo 122-369-9 (25.3%)
ブレンドdlshogi elmo 68-227-5 (23.5%)
ブレンドdlshogi 無改造dlshogi 226-162-12 (58.0%)

elmoとの比較では、ブレンドしたほうが若干勝率が低いという結果になりました。統計的に有意とは言えないですが。dlshogi同士の対局数も増やしたところ、こちらではブレンドしたほうが有意に強いという結果は変わりませんでした。 ソフト同士の相性があるのか、elmoとのレート差が大きくてうまく測れていないのかよくわかっていません。

現状、対戦相手として使用したelmoと、dlshogi内部で呼び出すelmoが同じ評価関数なので、今後別の評価関数についても試したいと思います。