TadaoYamaokaの開発日記

個人開発しているスマホアプリや将棋AIの開発ネタを中心に書いていきます。

Windows11+WSL2+Dockerでdlshogiを動かす

学習用のPCをWindows11にアップグレードしたので、CUDA on WSLを試してみた。

ドライバインストール

CUDA on WSLに対応したドライバをインストールする。
GPU in Windows Subsystem for Linux (WSL) | NVIDIA Developer
※2021/11/1 追記
CUDA 11.4に付属するドライバでも大丈夫だった。
このドライバを使うとWindows上で、以前のCUDA+TensorRTでビルドしたdlshogiのNPS性能が低下した。

WSL2インストール

公式のドキュメントの通り、管理者モードでPowerShellを起動して、

wsl --install

でインストールする。
Ubuntuも合わせてインストールされる。

GPUが使用できることを確認

Windows11でWSL2をインストールすると、デフォルトでCUDAが使用可能になっている。

$ nvidia-smi
$ nvidia-smi
Mon Nov  1 00:05:38 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 510.00       Driver Version: 510.06       CUDA Version: 11.6     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA TITAN V      On   | 00000000:01:00.0 Off |                  N/A |
| 43%   53C    P0    31W / 250W |    703MiB / 12288MiB |     N/A      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   1  NVIDIA TITAN RTX    On   | 00000000:21:00.0 Off |                  N/A |
| 41%   29C    P8    14W / 280W |    300MiB / 24576MiB |     N/A      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

GPU使用率は表示できないようなので、GPU使用率を確認するにはWindows側のnvidia-smiを使用する必要がある。

Docker CEインストール

Ubuntuを起動し、公式ドキュメントの通り、Dockerをインストールする。

$ sudo apt-get update
$ sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

$ sudo apt-get update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io

Dockerの設定

sudoなしで起動できるように、ユーザーをdockerグループに追加する。

sudo gpasswd -a $USER docker

Dockerサービス起動

Dockerのサービスを手動で起動する。

sudo service docker start

NVIDIA Container Toolkitインストール

公式の説明の通り、NVIDIA Container Toolkitをインストールする。
※2023/11/23追記 最新版は手順が変わっているため、こちらを参照

$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
$ curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
$ curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list

$ sudo apt-get update
$ sudo apt-get install -y nvidia-docker2

$ sudo service docker stop
$ sudo service docker start

PyTorchコンテナを起動

dlshogiが使用しているPyTorchが使用できるNVIDIAのコンテナを起動する。

docker run --gpus all -it --net=host -v /mnt/d:/mnt/d --name shogi nvcr.io/nvidia/pytorch:21.10-py3

※/mnt/dは自分の環境に合わせて編集する
※共有メモリの警告が表示されるが、データローダをマルチプロセスで使用しない場合は関係ないので無視する。
※気になる場合は、ここに説明があるので、起動オプションを設定する。

dlshogiインストール

# git clone https://github.com/TadaoYamaoka/DeepLearningShogi.git
# cd DeepLearningShogi
# pip install -e .

モデル訓練

dlshogiでモデルの訓練を実行する。

# python -m dlshogi.train floodgate_2019-2021_r3800.hcpe3 floodgate.hcpe --use_amp --eval_interval 100
2021/10/31 14:44:45     INFO    network resnet10_swish
2021/10/31 14:44:45     INFO    batchsize=1024
2021/10/31 14:44:45     INFO    lr=0.01
2021/10/31 14:44:45     INFO    weight_decay=0.0001
2021/10/31 14:44:45     INFO    val_lambda=0.333
2021/10/31 14:44:46     INFO    use amp
2021/10/31 14:44:46     INFO    temperature=1.0
2021/10/31 14:44:46     INFO    optimizer SGD (Parameter Group 0 dampening: 0 lr: 0.01 momentum: 0.9 nesterov: True weight_decay: 0.0001)
2021/10/31 14:44:46     INFO    Reading training data
2021/10/31 14:44:46     INFO    floodgate_2019-2021_r3800.hcpe3
2021/10/31 14:44:55     INFO    Reading test data
2021/10/31 14:44:56     INFO    train position num = 7576031
2021/10/31 14:44:56     INFO    test position num = 856923
2021/10/31 14:45:11     INFO    epoch = 1, steps = 100, train loss = 4.2608442, 0.6415551, 0.6496299, 4.9050882, test loss = 3.4043007, 0.6760992, 0.6944302, 4.0865040, test accuracy = 0.2392578, 0.5654297
2021/10/31 14:45:25     INFO    epoch = 1, steps = 200, train loss = 2.9916522, 0.5849209, 0.6070443, 3.5839402, test loss = 2.9757018, 0.6661907, 0.6929067, 3.6507890, test accuracy = 0.2763672, 0.5869141
...

訓練が実行できることが確認できた。

Windows側のnvidia-smiでGPU使用率を確認すると、GPUが使用されていることが確認できた。

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 510.06       Driver Version: 510.06       CUDA Version: 11.6     |
|-------------------------------+----------------------+----------------------+
| GPU  Name            TCC/WDDM | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA TITAN V     WDDM  | 00000000:01:00.0 Off |                  N/A |
| 61%   84C    P2   210W / 250W |   6285MiB / 12288MiB |     86%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
|   1  NVIDIA TITAN RTX   WDDM  | 00000000:21:00.0 Off |                  N/A |
| 41%   28C    P8    13W / 280W |    300MiB / 24576MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

dlshogiビルド

CPUがRyzenなので、MakefileをZEN2向けに修正して、ビルドする。

# cd usi
# sed -i -e 's/-DHAVE_BMI2 -msse4.2 -mbmi2 -DHAVE_AVX2 -mavx2/-msse4.2 -DHAVE_AVX2 -mno-bmi2 -mavx2 -march=znver2/' Makefile
# make

dlshogi実行

USIエンジンをコマンドから実行する。

# cd bin
# ./usi
setoption name DNN_Model value /workspace/model/model-dr2_exhi.onnx
setoption name UCT_Threads value 3
setoption name UCT_Threads2 value 3
isready
position startpos
go byoyomi 5000
info nps 39707 time 5033 nodes 199848 hashfull 19 score cp 72 depth 31 pv 2g2f 3c3d 7g7f 8c8d 2f2e 8d8e 6i7h 8e8f 8g8f 8b8f 2e2d 2c2d 2h2d 4a3b 2d3d 2b3c 5i5h 5a5b 3g3f 8f7f 8h7g 7f7d 3d7d 7c7d P*2h P*8b 7i6h 3a4b 7h7i 3b3a P*7b
bestmove 2g2f

GPU2枚(TITAN VとTITAN RTX)で4万npsくらいの探索速度である。

Windows上からの比較

Windows上からも同じ条件で探索速度を測った。

info nps 29337 time 5038 nodes 147800 hashfull 14 score cp 72 depth 31 pv 2g2f 3c3d 7g7f 8c8d 2f2e 8d8e 6i7h 8e8f 8g8f 8b8f 2e2d 2c2d 2h2d 4a3b 2d3d 2b3c 5i5h 5a5b 3g3f 8f7f 8h7g 7f7d 3d7d 7c7d P*2h P*8b 7i6h 3a4b 7h7i 3b3a P*7b
bestmove 2g2f

Ubuntuから実行した方が速い。
TensorRTのバージョンとも関連していそうである。
別途、Windows側のCUDAとTensorRTのバージョンを上げて測定してみたい。

まとめ

Windows11のWSL2上のDockerコンテナで、dlshogiの学習とUSIエンジンの実行を試した。
問題なく使用できることがわかった。

NPSはなぜかWindows上よりも高くなったので、CUDAとTensorRTのバージョンをそろえた上で別途測定してみたい。

dlshogiのmateの読み筋表示 続き

昨日の記事で、dlshogiを詰みの読み筋表示に対応させたことを書いた。
その際、王手の合法手に不成を生成していないことで、手順が10手以上長くなる局面があることがわかった。
探索速度が低下しないのであれば、不成を生成することを検討したい。

そこで、不成も生成した場合のdf-pnの探索速度を測定した。

不成の生成

今までは、歩、香車、飛車、角の不成は生成していなかった。
それぞれ直接王手の場合と、開き王手で不成になる場合がある。
それらを、不成も生成するように変更した。

テスト

以前に、王手の合法手の最大数を検討した際に、最大と考えられる局面で合法手がすべて生成されるか確認した。
結果、91手が生成できることが確認できた。

また、それぞれ直接王手の場合と、開き王手で不成になる場合でテストケースを作成してテストした。

また、やねうらお氏が公開している詰将棋500万問の7手詰めで、手数制限を7手にして、すべて詰みになることを確認した。

変更前後の速度比較

1手~37手詰めの51局面で、時間を測定した。

平均(ms) 中央値(ms)
変更前 140 9
変更後 150 9

平均では少し時間がかかるようになっているが、10msの差であり実戦で影響のある時間ではない。
中央値は同じであり、実戦で多くあらわれるであろう短手数の詰みで遅くなっていることはない。

まとめ

dlshogiでは今まで、王手の合法手に不成を生成していなかったが、不成を生成しないことで手順が伸びる場合があるため、不成を生成するようにした。
探索速度がわずかにかかるようになったが、実戦で影響のある時間ではないため、不成も生成するようにする。

ビルド済みバイナリ

https://gist.github.com/TadaoYamaoka/219c900457c30741ea43b512b4ec2f17/raw/923acc35572d1b8c9de28a0bf248e47e2d4fa4a4/dlshogi_matepv.zip

MultiPVで、評価値が異常値になるバグがあったので、それも修正しています(評価値が出せない場合は空欄にする対応)。

dlshogiのmateの読み筋表示

dlshogiは、モンテカルロ木探索とは別に、詰み専用のアルゴリズム(df-pn)で長手数の詰み探索を行っている。
df-pnで詰みが見つかった場合、すぐにその手を返している。

df-pnは、詰みがあるかどうかを見つけるアルゴリズムのため、見つかる手順が最短手順とは限らない。
実戦上は詰ませればよいため、最短になることは考慮していない。
そのため、読み筋は(最短の)手順の参考にならないため表示していなかった。

しかし、issueを頂いたため、最短でなくても表示した方がよいかもしれないので、読み筋表示に対応した。
検討時のMateで読み筋が出ない · Issue #62 · TadaoYamaoka/DeepLearningShogi · GitHub

実装方法

df-pnで詰みが見つかった後に、ルートからゲーム木を辿り、
ORノードでは最初にpn=0になる手を選択し、
ANDノードでは手順が最大になる手を選択する。

先端ノードでは、1手詰めを行っているため、1手詰めで詰みになったノードのdnの値を他と区別するようにしておき、1手詰めのノードで再度1手詰めを行って読み筋に追加する。

テスト

やねうらお氏が公開してくれている詰将棋500万問を使ってテストした。
やねうら王公式からクリスマスプレゼントに詰将棋500万問を謹呈 | やねうら王 公式サイト

3手詰めは、深さ制限を3して、すべて正しく表示できた。ただし、1手詰めの局面が1214件含まれていた。

5手詰めは、深さ制限を5にすると、1件不詰めになる局面があった。
df-pnのANDノードでは、すべて5手以内で詰んでいないと不詰みになることによる。
深さ制限を大きくすると詰みになるが、最短手順ではなくなる。

7手詰めでは、深さ制限を7にすると、同様に不詰みになる局面が13件あった。
深さ制限を大きくすると詰みになるが、手順が17手や19手になるものがあったため、原因を調べたところ、飛車と角の不成を生成していないことで手順が長くなっていることがわかった。

不成の方が手順が短くなる局面

今まで、実戦上は問題ないだろうと思って、王手の指し手に飛車と角の不成は生成していなかった。
しかし、少数だが詰みの手順が10手以上伸びる局面があることがわかった。

いずれも、飛車と角を成ったことで、打ち歩詰めになるため手順が長くなっていた。

飛車の不成の方が良い例
+LR2R2n1/3g1lg2/3N2kp1/p2pp4/5S1Sp/1PP3SP1/P2PP2B1/1G1S2G2/LN2K4 b N6Pblp 121
l4p2l/7g1/6n1b/P2g1kS1p/3p2p2/2S2N1p1/1PKP1S1NP/4g1G2/L1+B1+p1S1L b RN5Pr3p 171
lkB1s3+N/4bs3/2RL2pp1/p1pGpp2p/1n1p5/8P/PP1PPPP1N/1G1S2S+R1/LN2KG2L b Pg2p 89
l8/2+P2+N1k1/4G2p1/2p2ps1G/p3s4/1pP1S4/PlN1gP+p2/1bGp5/L3K4 b R4Prbs2nl3p 193
l4ksRl/3+S5/p4pngp/2pp1bp2/9/P1PP1PP1P/1PNG1K3/1G4r2/L5bNL w G2SN2P3p 78
lR3p2l/2g1k1s2/ps1ppPn2/2pg2p1p/9/2PB1NP2/P1NPP1N1P/2S1KGS2/L2G4L b RPb3p 83
角の不成の方が良い例
9/3S1k3/3pg2+R1/4spP2/1p1PN3L/PP1nPP3/3l1SN2/K1g2G3/L3b+b3 w RGSL7Pn2p 126


不成も生成することで、全体的な探索時間への影響を調べた上で不成も生成するか検討したい。

まとめ

dlshogiのmateの読み筋表示に対応した。

テストしている中で、王手の指し手に不成を生成していないことで手順が10手以上伸びる局面があることがわかった。
今後、不成を生成するか検討したい。

dlshogiの評価値のスケール調整

dlshogiは、開始局面から170点という比較的大きな評価値を出力する。
これは適切でないため、今回調整を行うことにした。

勝率から評価値への変換

dlshogiの内部では、局面の価値は、評価値を使わず勝率で扱っているが、GUIソフトには評価値として返す必要があるため、勝率から評価値にシグモイドの逆関数で変換を行っている。

\displaystyle
 -a \log(\frac{1}{x} - 1)

ここで、xは勝率である。
係数aは、Aperyややねうら王では、Ponanza定数と呼ばれるa=600が使われている。
ただし、Aperyややねうら王でこの定数を使うのは、学習時だけである。
探索時は評価値そのものを使用している。

dlshogiの係数a

dlshogiでは、以下の2か所で係数aを使用している。

  • 教師ありで棋譜を学習する際に、棋譜に記録された評価値から、勝率に変換する場合
  • 探索時に、GUIソフトに評価値を表示するため、勝率から評価値に変換する場合

かなり初期の頃に、前者の方で、elmo_for_learnの自己対局データを教師あり学習するために、係数aを調整した。
そして、その際に調整した係数aを後者の方でも使用している。

その値は、a=756.0864962951762となっており、この値が大きいことが大きめの評価値の原因になっている。

係数aの特定

評価値と勝率の関係は、使用するエンジン、読みの深さ、評価関数の精度によって、変わるものである。
そのため、ある特定の条件でしか調整できない。

参考として、dlshogiの自己対局のデータで、係数aを近似すると、以下のようになる。

モデル プレイアウト数 係数a
dlshogi with GCT 3000 456
dlshogi-dr2_exhi 10000 473
dlshogi-dr2_exhi 15000 458

モデルにより基準が異なり、同じモデルでも読みが深くなると小さくなる。

水匠4改の固定ノード数での自己対局では、以下のようになる。

ノード数 係数a
5M 180
8M 171

学習時にはa=600が使われているが、それよりもかなり小さい値になる。

係数aの再調整

初期にelmo_for_learnで調整した係数aが、現状のモデルと乖離しているため、再調整が必要と考えている。

何を基準に調整するかが問題になるが、例えば自己対局時のデータを使うと、読みが浅いため検討で使うと大きめの値がでてしまう。
かといって、長時間の対局で十分なデータを集めるのは難しい。
しかも、モデルごとに調整が必要なため、毎回実施が必要になる。

ユースケースを考えると、大きめの値で困るのは、検討時に水匠4などと比較した時なので、開始局面付近で同じくらいの値になっていればよさそうである。

そこで、開始局面で水匠4で1億ノード検討した際の評価値(71)とほぼ同じになるように調整することにする。

dlshogiと水匠4が互角の条件では、ノード数を1/338すればよいので、30万プレイアウトで、評価値が同じになるように調整する。

ということで、調整した結果、a=285という値になった。

水匠4と1手3秒で対局すると、序盤の評価値が小さめの値になったことが確認できる。評価値のグラフ推移も近くなった。

モデルごとに調整が必要なため、USIオプション(Eval_Coef)にして、デフォルト値は今まで通りa=756で、モデルごとの.iniファイルで上書きできるようにした。

まとめ

dlshogiの序版の評価値は大げさすぎるという意見があったので、評価値のスケールを調整した。
どういう基準で調整するかは、決まった基準があるわけでないので、今回は水匠4と互角の探索ノード数で、開始局面の評価値が一致するという条件で調整した。

Windows用ビルド済みファイルはこちら
https://gist.github.com/TadaoYamaoka/cc0fcbb0a9e7b62062215f6ee02ae9ad/raw/eab5bad93047f2d8b308bce40c71ec3abaecd467/dlshogi_eval_coef.zip
.exeファイルを差し替えてください。
Eval_Coefは、デフォルトの756になっているので、285に変更してください。
もしくは、model-dr2_exhi.onnx.iniに、「Eval_Coef=285」の行を追記してください。

2023/8/26追記

評価値と勝率の関係をグラフにしたものを以下に示す。

接待dlshogi

接待水匠にインスパイアされて接待dlshogiを作ってみた。

仕組み

MultiPVを使うのではなく、モンテカルロ木探索(PUCT)で、勝率の期待値が接待係数に近づくように探索を行う。

接待係数(USIオプションSettai)は、1から99の整数で、50の場合に互角になるように指して、0に近いと負けるように指す。100に近いと最善手に近づく。

利点

MultiPVは探索した中で上位の手から選ぶが、この方法では接待係数に近づくように探索するので、接待の精度が高い。
また、方策の確率が高い手を優先するため、あからさまな悪手は指しにくい。

その他
  • 温度パラメータ(Softmax_Temperature)は、デフォルト500で、なるだけ方策の影響を小さくしている。
  • モデルの.iniファイルがある場合、温度パラメータはデフォルト値を上書きしないようにしている。
  • 詰み探索は、デフォルト5手にして、短手数の詰みについては、わざと見逃して負けるようなことはしないようにする。

テスト

電竜戦エキシビジョンバージョンのモデルを使って、GPSFishとLesserkaiを相手に対局させた。

GPSFish

GPSFishとの対局では、接待係数51で、良い感じに負けた。
f:id:TadaoYamaoka:20211011225500p:plain

Lesserkai

Lesserkaiとの対局では、接待係数30で、良い感じに負けた。
f:id:TadaoYamaoka:20211011225135p:plain

ダウンロード

以下のURLからダウンロードできる。
https://gist.github.com/TadaoYamaoka/b9953b05df61b32bcea75eee18c94d4c/raw/a9c3c14985981ebe26d7d2173c442b09f0b77c23/settai_dlshogi.zip

TensorRT版とONNX版の実行可能ファイルが含まれる。
モデルは、別途Releaseから入手する。

ソースコード

feature/settaiブランチにプッシュした。

まとめ

接待で、モンテカルロ木探索の特性を活かせるかもと思いついたので、思いつきでを作ってみた。
コードの修正はほとんどないので、ほとんど手間はかかっていない。

自分で対局してみましたが、接待係数50だと、最後に負けました・・・orz

将棋AIの実験ノート:活性化関数Mishを試す

以前にdlshogiのモデルで活性化関数をReLUからSwishにした場合の比較を行った。

今回は、活性化関数Mishを試した。

Mish

Mishは、
\displaystyle
f(x)=x \tanh(softplus(x))
で表される活性化関数である。

論文によると、6層CNNのCIFAR-10の訓練で、Swishの正解率を上回ると報告されている。
[1908.08681] Mish: A Self Regularized Non-Monotonic Activation Function

PyTorchの実装

Mishの論文が出た直後に、PyTorchにリクエストのissueが上がっていたが、コミュニティに広く受け入れられていないという理由でリジェクトされていた。

しかし、PyTorch 1.9で、標準機能として実装されていた。
Mish — PyTorch 1.10 documentation

PyTorchに実装されていないため、dlshogiで試すのを保留していたが、標準で実装されたので試してみた。

比較条件

dlshogiのResNet15ブロック224フィルタのモデルの活性化関数を、ReLUとSwish、Mishにした場合で比較を行った。

訓練データには、dlshogiの最新モデルの自己対局で生成した50000157局面(同一局面の平均化後は41895205局面)を使用した。
dlshogi.trainのオプションは、「--use_average」、「--use_evalfix」、「--use_amp」、「--use_swa」を有効にした。

バッチサイズ4096で、学習率0.04から始めて、エポックごとに半減、2エポックを学習して、SWAモデルのテストデータに対する精度を比較した。

それぞれ4回測定し、平均で比較した。

テストデータには、floodgateのレート3500以上の対局の棋譜からサンプリングした856,923局面を使用した。

比較結果

方策損失 価値損失 方策正解率 価値正解率 方策エントロピー
ReLU 1.708107425 0.543135325 0.45590225 0.712226825 1.67308225
Swish 1.66914235 0.5330944 0.4644194 0.720270625 1.631262975
Mish 1.678887075 0.53691395 0.462033475 0.7182632 1.6450056
正解率比較グラフ


訓練時間
時間/epoch
ReLU 2:08:18
Swish 2:12:37
Mish 2:15:17

考察

精度は、方策、価値ともに、Swish > Mish > ReLU の順になった。
訓練時間は、ReLU < Swish < Mishの順になった。

MishはSwishと比べると、精度は低くなり、訓練時間も長くなることがわかった。
ReLUと比べると、精度は高くなっているが、訓練時間が長くなる。

まとめ

活性化関数MishがPyTorchの標準に取り込まれたので、dlshogiのモデルで精度が上がるか試した。
結果、Swishの方が精度が高く、訓練時間も短いという結果であった。
dlshogiで、Mishを採用するメリットはないと言える。

dlshogiの学習時の自己対局での先手勝率

少し前にdlshogiの先手勝率について調べた。
今回は、dlshogiの学習時の自己対局での先手勝率について調べた。

開始局面

現在、dlshogiの自己対局は、floodgateの16手目までの出現頻度が99パーセンタイル以上の局面を初期局面集として、そこからさらに16手MCTSの訪問回数に応じた確率で手を選択(ただし、価値が最善手の0.9以下は除く)した局面を開始局面としている。
したがって、開始局面は、16手目~32手目の局面になる。

開始局面をこのようにした場合、生成される局面は、87%がユニークな局面になる。
なお、対局中の指し手の選択では最善手と次善手の訪問回数が僅差の場合は、訪問回数に応じた確率で選択することで、ランダム性を加えている。

水匠4改とのリーグ戦

自己対局中に、32/384の割合で、水匠4改との対局も行っている。
開始局面での手番はランダムに選択している。

対局条件

dlshogi 1万プレイアウト(探索延長あり)
水匠4改 510万ノード

この条件で、dlshogiと水匠4改の勝率は、50.46%でほぼ互角になる。

なお、以前にdlshogiと水匠のNPSの違いについて記事にしたときに、dlshogiのNPSは水匠の1/338であったが、強化学習ではdlshogiも水匠もシングルスレッドで動作しているため、互角となるノード数の条件が変わってくる。

先手勝率

259,873対局のデータについて調べたことろ、自己対局と、水匠4改との対局での、先手勝率は以下の通りであった。

自己対局 0.534
dlshogi対水匠4改(dlshogi先手) 0.547
dlshogi対水匠4改(dlshogi後手) 0.537

以前の平手開始局面からの調査では、dlshogi対水匠4の先手勝率は57.55%であったが、それよりもやや低い値となっている。

まとめ

floodateの頻出局面ら一定手数のランダムプレイを行った局面から開始すると、先手勝率は、約53%であることがわかった。
平手開始局面から測定した場合の勝率と比べると、やや低い値となった。

なお、水匠4改との対局では、dlshogiの先手勝率が54.7%とやや高かった。dlshogiがfloodgateでの先手勝率が高いことと関連していそうである。


調査時のログ

F:\hcpe3>python -m dlshogi.utils.stat_hcpe3 F:\hcpe3\selfplay_pre8_resnet15_swish_b4096lr004-008_floodgate16_s4k_po10000-20.hcpe3
               moves      black win           draw       nyugyoku       opponent
count  259873.000000  259873.000000  259873.000000  259873.000000  259873.000000
mean      118.161009       0.496596       0.071223       0.016343       0.109519
std        45.420141       0.499989       0.257198       0.126790       0.412878
min        23.000000       0.000000       0.000000       0.000000       0.000000
25%        90.000000       0.000000       0.000000       0.000000       0.000000
50%       113.000000       0.000000       0.000000       0.000000       0.000000
75%       139.000000       1.000000       0.000000       0.000000       0.000000
max       508.000000       1.000000       1.000000       1.000000       2.000000
black win rate 0.5346779138562503
               moves      black win           draw       nyugyoku  opponent
count  240890.000000  240890.000000  240890.000000  240890.000000  240890.0
mean      116.860110       0.494753       0.073623       0.013155       0.0
std        43.384848       0.499974       0.261157       0.113940       0.0
min        23.000000       0.000000       0.000000       0.000000       0.0
25%        90.000000       0.000000       0.000000       0.000000       0.0
50%       113.000000       0.000000       0.000000       0.000000       0.0
75%       138.000000       1.000000       0.000000       0.000000       0.0
max       508.000000       1.000000       1.000000       1.000000       0.0
black win rate 0.5340727297170128
             moves    black win         draw     nyugyoku  opponent
count  9505.000000  9505.000000  9505.000000  9505.000000    9505.0
mean    130.786007     0.516465     0.038927     0.050395       1.0
std      62.515211     0.499755     0.193431     0.218769       0.0
min      23.000000     0.000000     0.000000     0.000000       1.0
25%      87.000000     0.000000     0.000000     0.000000       1.0
50%     116.000000     1.000000     0.000000     0.000000       1.0
75%     163.000000     1.000000     0.000000     0.000000       1.0
max     499.000000     1.000000     1.000000     1.000000       1.0
black win rate 0.5373836891078271
             moves    black win         draw     nyugyoku  opponent
count  9478.000000  9478.000000  9478.000000  9478.000000    9478.0
mean    138.563304     0.523528     0.042625     0.063199       2.0
std      64.715036     0.499472     0.202021     0.243333       0.0
min      23.000000     0.000000     0.000000     0.000000       2.0
25%      92.000000     0.000000     0.000000     0.000000       2.0
50%     127.000000     1.000000     0.000000     0.000000       2.0
75%     173.000000     1.000000     0.000000     0.000000       2.0
max     483.000000     1.000000     1.000000     1.000000       2.0
black win rate 0.5468371170376901
           positions  candidates avr  max candidates     visits avr  top visits avr
count  259873.000000   259873.000000   259873.000000  259873.000000   259873.000000
mean       96.200879       11.320640       35.235723    5597.170238     4018.777710
std        43.629254        2.362279       20.427705     538.479582      267.355648
min         3.000000        4.272727        5.000000    3062.600000     1552.294118
25%        69.000000       10.040816       23.000000    5261.786885     3935.833333
50%        92.000000       10.864865       28.000000    5519.361963     4062.797619
75%       118.000000       11.906250       40.000000    5834.141026     4172.319149
max       490.000000       44.182692      263.000000   13453.400000     5747.750000
sum positions 25000011
unique positions 21749595
unique positions / sum positions 0.8699834172072964