nodchipのコンピューター将棋ブログ

コンピューター将棋ソフト「tanuki-」シリーズの実験結果を掲載しています。

tanuki- 2022-05-12 シャッフル時にqsearch()を行う

 

tanuki- 2022-05-12 シャッフル時にqsearch()を行う

実験内容

  • 学習データのシャッフル時に qsearch() を行い、学習時の qsearch() を省略し、正しく学習が行えるかどうか確認する。

棋譜生成

生成ルーチン tanuki-棋譜生成ルーチン
評価関数 水匠5 FV_SCALE=16
1手あたりの思考 深さ最大 9 思考ノード数最大 50,000 ノード
開始局面 foodgate の 2020 年~ 2021 年の棋譜のうち、レーティング 3900 以上同士の対局の 32 手目までから 1 局面ランダムに選択し、その局面を開始局面とした ランダムムーブなし
生成局面数 10 億局面 × 8 セット
生成条件 対局は打ち切らず詰みの局面まで学習データに出力した

機械学習

機械学習ルーチン やねうら王機械学習ルーチン
学習モデル halfkp_256x2-32-32
学習手法 SGD ミニバッチ法
USI_Hash 1024
Threads 127
loop 100
batchsize 1000000
lambda 0.5
eta eta1=1e-8 eta2=1.0 eta1_epoch=100
newbob_decay 0.5
nn_batch_size 1000
eval_save_interval 100000000
loss_output_interval 1000000
mirror_percentage 50
eval_limit 32000
weight_by_progress 無効
次元下げ K・P・相対KP
学習データ内で重複した局面の除外 しない
初期ネットワークパラメーター tanuki-wcsc29
勝敗項の教師信号 0.80

レーティング測定

対局相手  
思考時間 持ち時間 300 秒 + 1 手 2 秒加算
対局数 2000
同時対局数 64
ハッシュサイズ 768
開始局面 たややん互換局面集

実験結果

機械学習

レーティング測定

対局数=5000 同時対局数=64 ハッシュサイズ=768 開始手数=0 最大手数=320 開始局面ファイル=C:\Jenkins\workspace\TanukiColiseum.2022-05-02\TanukiColiseum\taya36_2020-11-06.sfen NUMAノード数=2 表示更新間隔(ms)=3600000

思考エンジン1 name=YaneuraOu NNUE 7.10 64ZEN2 TOURNAMENT author=by yaneurao exeファイル=C:\Jenkins\workspace\TanukiColiseum.2022-05-02\engine1\source\YaneuraOu-by-gcc.exe 評価関数フォルダパス=D:\hnoda\shogi\eval\suisho5.halfkp_256x2-32-32.preqsearch.evaluate\final 定跡手数=256 定跡ファイル名=no_book 思考ノード数=0 思考ノード数に加える乱数(%)=0 思考ノード数の乱数を1手毎に変化させる=False 持ち時間(ms)=300000 秒読み時間(ms)=0 加算時間(ms)=2000 乱数付き思考時間(ms)=0 スレッド数=1 BookEvalDiff=30 定跡の採択率を考慮する=false 定跡の手数を無視する=false SlowMover=100 DrawValue=-2 BookEvalBlackLimit=0 BookEvalWhiteLimit=-140 FVScale1=16

思考エンジン2 name=YaneuraOu NNUE 7.10 64ZEN2 TOURNAMENT author=by yaneurao exeファイル=C:\Jenkins\workspace\TanukiColiseum.2022-05-02\engine2\source\YaneuraOu-by-gcc.exe 評価関数フォルダパス=D:\hnoda\shogi\eval\suisho5.halfkp_256x2-32-32.80G\final 定跡手数=256 定跡ファイル名=no_book 思考ノード数=0 思考ノード数に加える乱数(%)=0 思考ノード数の乱数を1手毎に変化させる=False 持ち時間(ms)=300000 秒読み時間(ms)=0 加算時間(ms)=2000 乱数付き思考時間(ms)=0 スレッド数=1 BookEvalDiff=30 定跡の採択率を考慮する=false 定跡の手数を無視する=false SlowMover=100 DrawValue=-2 BookEvalBlackLimit=0 BookEvalWhiteLimit=-140 FVScale2=16

対局数5000 先手勝ち2304(54.8%) 後手勝ち1899(45.2%) 引き分け797

engine1

勝ち2103(50.0% R0.2 +-9.6) 先手勝ち1090(25.9%) 後手勝ち1013(24.1%)

宣言勝ち104 先手宣言勝ち61 後手宣言勝ち43 先手引き分け525 後手引き分け272

engine2

勝ち2100(50.0%) 先手勝ち1214(28.9%) 後手勝ち886(21.1%)

宣言勝ち46 先手宣言勝ち27 後手宣言勝ち19 先手引き分け272 後手引き分け525

2103,797,2100

まとめ

学習データのシャッフル時に qsearch() を行い、学習時の qsearch() を省略し、正しく学習が行えるかどうか確認した。

 

学習ロスと検証ロスは、シャッフル時に qsearch() を行ったほうが高くなった。

平手局面の評価値は、ほとんど変わらなかった。

評価値の絶対値は、ほとんど変わらなかった。

レーティングは、有意差はなかった。

 

学習ロスと検証ロスについては、本質的には同じ処理を行っているはずであり、変化する原因がわからなかった。

平手局面の評価値については、学習に致命的な問題が起きていない事を表しているものと思われる。

評価値の絶対値についても、学習に致命的な問題が起きていない事を表しているものと思われる。

レーティングについては、シャッフル時に qsearch() を行っても、学習に問題ないという事を表していると考えられる。

 

本実験の結果より、シャッフル時に qsearch() を行えば十分であることが分かった。 nnue-pytorch の将棋版開発の際は、この方式を取りたいと思う。