tanuki- 2022-05-17 シャッフル時に置換表を有効にして qsearch を行う

tanuki- 2022-05-17 シャッフル時に置換表を有効にして 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 秒加算
対局数 5000
同時対局数 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_with_tt.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 先手勝ち2552(58.1%) 後手勝ち1842(41.9%) 引き分け606

engine1

勝ち1438(32.7% R-108.9 +-10.1) 先手勝ち844(19.2%) 後手勝ち594(13.5%)

宣言勝ち57 先手宣言勝ち34 後手宣言勝ち23 先手引き分け407 後手引き分け199

engine2

勝ち2956(67.3%) 先手勝ち1708(38.9%) 後手勝ち1248(28.4%)

宣言勝ち34 先手宣言勝ち12 後手宣言勝ち22 先手引き分け199 後手引き分け407

1438,606,2956

まとめ

シャッフル時に置換表を有効にして qsearch を行った場合、レーティングが変化するか調べた。

学習ロスと検証ロスは、置換表を有効にしたほうが大きかった。

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

評価値の絶対値は、置換表を有効にしたほうが小さかった。

レーティングは、 置換表を有効にしたほうが有意に弱かった。

過去の経験から、置換表を有効にすると、 qsearch の PV が短くなる事が分かっている。これにより、 qsearch の PV の末端局面が、駒の取り合いのある局面や、玉に王手がかかっている局面となっている可能性がある。また、過去の実験から、駒の取り合いのある局面や、玉に王手がかかっている局面を対象に学習を行うと、学習ロスと検証ロスが上がることが分かっている。今回の学習ロスと検証ロスについては、これと同様の事が起きている可能性がある。

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

評価値の絶対値については、学習対象の局面が異なっているため、値が変化してもおかしくはないと思う。ただし、なぜ低くなっているのかは分からなかった。

過去の実験から、駒の取り合いのある局面や、玉に王手が刈っている局面を対象に学習を行った場合、レーティングが低くなる傾向があることが分かっている。今回のレーティングについても、同様の事が起こっていると考えられる。

置換表を有効にした場合、本当に qsearch の PV が短くなるかどうかについては、再度検証しても良いと思う。いずれにせよ、シャッフル時の qsearch は置換表を無効化した状態で行ったほうが良いと思われる。