tanuki- 2024-03-07 nnue-pytorch halfkp_1024x2-8-32 バッチサイズ調整
実験内容
- nnue-pytorch を用い、 halfkp_1024x2-8-32 ネットワークを学習させる。
- バッチサイズを 16384 に増やして学習させる。
棋譜生成
| 生成ルーチン | tanuki-棋譜生成ルーチン |
| 評価関数 | Hao (tanuki-.halfkp_256x2-32-32.2023-05-08) |
| 1手あたりの思考 | 深さ最大 9 思考ノード数最大 50,000 ノード |
| 開始局面 | foodgate の 2020 年～ 2021 年の棋譜を使用した。レーティング 3900 以上同士の対局のみ使用した。戦型が角換わりの対局が 10% になるよう調整した。 32 手目までから 1 局面ランダムに選択し、その局面を開始局面とした。ランダムムーブはしなかった。 |
| 生成局面数 | 10 億局面 × 8 セット |
| 生成条件 | 対局は打ち切らず詰みの局面まで学習データに出力した |
| フォルダ名 | tanuki-.halfkp_256x2-32-32.2023-05-08 |
| 生成ルーチン | tanuki-棋譜生成ルーチン 深さ 9 の思考でレーティングが上がるよう、探索パラメーターを調整している |
| 評価関数 | 水匠 5 |
| 1手あたりの思考 | 深さ最大 9 思考ノード数最大 50,000 ノード |
| 開始局面 | foodgate の 2017 年以降の棋譜のうち、入玉を含む棋譜を使用した。 |
| 生成局面数 | 5 億局面 × 1 セット |
| 生成条件 | 対局は打ち切らず詰みの局面まで学習データに出力した |
| フォルダ名 | suisho5.entering_king.2024-02-20 |
シャッフル条件
| 生成ルーチン | tanuki-シャッフルルーチン |
| qsearch() | あり |
| 置換表 | 無効 |
機械学習
| 機械学習ルーチン | nnue-pytorch + やねうら王 https://github.com/nodchip/nnue-pytorch/tree/shogi.2023-10-29.halfkp_1024x2-8-32 |
| 学習モデル | halfkp_1024x2-8-32 |
| 学習手法 | ミニバッチ SGD |
| 初期学習率 (lr) | 0.5 収束後 0.05 |
| 最適化手法 | なし |
| 学習率調整手法 | Warmup + Newbob 風 |
| batch-size | 16384 |
| threads | 8 |
| num-workers | 8 |
| accelerator | gpu |
| devices | 1 |
| features | HalfKP |
| max-epoch | 1000000 |
| score-scaling | 361 |
| lambda | 1.0 収束後 0.5 |
| 勝敗項の教師信号 | 0.999 |
| num-batches-warmup | 10000 |
| newbob-decay | 0.5 |
| epoch-size | 1000000 |
| num-epochs-to-adjust-lr | 500 |
| 学習を打ち切る下限 newbob scale | 1e-5 |
| 1 epoch 毎のネットワークパラメーターのクリップ | あり |
| ネットワークパラメーターの量子化 | 量子化なしで学習し、収束後に量子化する。 |
| ネットワークパラメーターの初期化方法 | pytorch のデフォルトの初期化手法で初期化する。 |
| 勾配の正規化 | なし |
| momentum | 0.9 |
| 入玉ボーナス | 入玉時、持ち駒および敵陣三段目までに侵入している駒について、小駒 1 枚につき 20 点、大駒 1 枚につき 100 点、敵陣三段目までに侵入している駒 1 枚につき 20 点追加する。 |
レーティング測定
| 対局相手 | https://docs.google.com/document/d/1razZwLBDtB47gLhNsWQwNZqW9S1qC3S7ZVfEzGwaAxo/edit?usp=sharing tanuki-.nnue-pytorch-2024-02-28 |
| 思考時間 | 持ち時間 300 秒 + 1 手 2 秒加算 |
| 対局数 | 5000 |
| 同時対局数 | 64 |
| ハッシュサイズ | 384 |
| 開始局面 | dlshogi 互角局面集の角換わりの割合が 10% になるよう間引いたもの |
実験結果
機械学習
検証ロス
batch-size=16384 … 0.2612318373649352
batch-size=8192 … 0.26106551361083985
学習時間
batch-size=16384 … 67:00:31.889
batch-size=8192 … 109:01:56.602
ネットワークパラメーターの分布
mean=-24.9853515625 std=23.355863571166992
mean=-0.0070372032932937145 std=3.420506000518799
mean=2012.625 std=1921.447265625
mean=-0.1197509765625 std=5.809447765350342
mean=-3127.375 std=4714.5380859375
mean=4.34375 std=32.68085479736328
mean=776.0 std=nan
mean=0.875 std=48.20905303955078
レーティング測定
対局数=5000 同時対局数=64 ハッシュサイズ=384 開始手数=24 最大手数=320 開始局面ファイル=C:\Jenkins\workspace\TanukiColiseum.2023-04-16\TanukiColiseum\floodgate32-80.adjust_bishop_exchange.sfen NUMAノード数=1 表示更新間隔(ms)=3600000
思考エンジン1 思考エンジン2
name YaneuraOu NNUE 7.63 64ZEN2 TOURNAMENT YaneuraOu NNUE 7.63 64ZEN2 TOURNAMENT
author by yaneurao by yaneurao
exeファイル C:\Jenkins\workspace\TanukiColiseum.2023-04-16\engine1\source\YaneuraOu-by-gcc.exe C:\Jenkins\workspace\TanukiColiseum.2023-04-16\engine2\source\YaneuraOu-by-gcc.exe
評価関数フォルダパス D:\hnoda\shogi\eval\tanuki-.nnue-pytorch-2024-03-06 D:\hnoda\shogi\eval\tanuki-.nnue-pytorch-2024-02-28
定跡手数 256 256
定跡ファイル名 no_book no_book
思考ノード数 0 0
思考ノード数に加える乱数(%) 0 0
思考ノード数の乱数を1手毎に変化させる False False
持ち時間(ms) 300000 300000
秒読み時間(ms) 0 0
加算時間(ms) 2000 2000
乱数付き思考時間(ms) 0 0
スレッド数 1 1
BookEvalDiff 30 30
定跡の採択率を考慮する true true
定跡の手数を無視する true true
SlowMover 100 100
DrawValue -2 -2
BookEvalBlackLimit 0 0
BookEvalWhiteLimit -140 -140
FVScale 16 16
Depth=0 0
MinimumThinkingTime 1000 1000
対局数5000 先手勝ち2472(54.7%) 後手勝ち2050(45.3%) 引き分け478
engine1
勝ち2224(49.2% R-5.1 +-9.6) 先手勝ち1224(27.1%) 後手勝ち1000(22.1%)
宣言勝ち40 先手宣言勝ち14 後手宣言勝ち26 先手引き分け227 後手引き分け251
engine2
勝ち2298(50.8%) 先手勝ち1248(27.6%) 後手勝ち1050(23.2%)
宣言勝ち68 先手宣言勝ち35 後手宣言勝ち33 先手引き分け251 後手引き分け227
2224,478,2298
学習ロスと検証ロスは、 tanuki-.nnue-pytorch-2024-03-06 のほうがやや高かった。
学習時間は、 tanuki-.nnue-pytorch-2024-03-06 のほうが 3 割ほど速かった。
レーティングは、 tanuki-.nnue-pytorch-2024-02-28 に対して R5.1 低かったが、有意な差はなかった。
考察
学習ロスと検証ロスが tanuki-.nnue-pytorch-2024-03-06 より高いのは、バッチサイズを大きくしたことにより、汎化性能が下がったためだと思う。
学習時間が速くなったのは、バッチサイズが大きくなったことにより、 GPU とのデータ転送の回数が減ったことが原因だと思う。
レーティングに有意差がなかった原因は、モーメンタムにより教師信号や勾配のノイズが減ったためだと思う。ただし、さらにバッチサイズを大きくし、有意差が出た場合、バッチサイズを大きくするにしたがってレーティングが下がると言えると思う。実験段階ではバッチサイズを大きくし、実験のイテレーションを速く回せるようにするのが良いと思う。大会に出場する際の評価関数を作成する際は、バッチサイズを小さくし、レーティングを挙げるのが良いと思う。
まとめ
nnue-pytorch を用い、 halfkp_1024x2-8-32 ネットワークを学習させた。その際、バッチサイズを 16384 に増やして学習させた。
レーティングは、 tanuki-.nnue-pytorch-2024-02-28 に対して R5.1 低かったが、有意な差はなかった。レーティングに有意差がなかった原因は、モーメンタムにより教師信号や勾配のノイズが減ったためだと思う。ただし、さらにバッチサイズを大きくし、有意差が出た場合、バッチサイズを大きくするにしたがってレーティングが下がると言えると思う。実験段階ではバッチサイズを大きくし、実験のイテレーションを速く回せるようにするのが良いと思う。大会に出場する際の評価関数を作成する際は、バッチサイズを小さくし、レーティングを挙げるのが良いと思う。
次回は、バッチサイズを 32768 に増やして学習させ、学習時間とレーティングを測定したい。
