前回 データ読み込みの非同期化と勝敗予想モデルの進捗 : TensorFlow将棋ソフト開発日誌 #6
目次 TensorFlow将棋ソフト開発日誌 目次
今回のあらすじ
（あまり面白い話では）ないです
- 入力ベクトルの形式を変える理由
- 新しい入力ベクトルの形式
- 簡易測定
- 次の予定
入力ベクトルの形式を変える理由
今までのモデルは大雑把に言って以下のような感じでした
9x9xコマの状態ベクトル
コマの状態ベクトル = [そのコマに王があるか, そのコマに王を動かせるか, そのコマに玉があるか, そのコマに玉が動かせるか, そのコマに角があるか, そのコマに角が動かせるか, そのコマに角があるか, そのコマに角が動かせるか, そのコマに馬があるか, そのコマに馬が動かせるか, そのコマに馬があるか, そのコマに馬が動かせるか, ... 中略 ... ,そのコマにと金があるか, そのコマにと金が動かせるか]
各次元において自分のコマは1, 相手のコマは-1が代入される。コマが存在しなければ0が代入される。成りゴマ、持ち駒によって自分、相手のコマの持ち数が変動する場合、自分のコマを先、相手のコマを後に詰めていく。
こうしている理由
- コマを別次元に分離することでコマ種についての分離性能を向上したい
- 動き次元を与えることで（単にコマの配置を入力した時のような）コマの動きのルール（すでに人間がわかっているデータ）をニューラルネットに学習させる無駄を排除したい
この方法のデメリット
- 自分のコマと相手のコマが同じ次元にあり得るので分離性能の低下が予測される
- 「自分のコマを先、相手のコマを後にして前方に詰める」という手順があるため似たような盤面に対してベクトルの距離が遠くなりうる
- 自分と相手を入れ替える処理がめんどい
新しい入力ベクトルの形式
前節事由により以下のようにしました
9x9x（自分のコマの状態ベクトル+相手のコマの状態ベクトル)
コマの状態ベクトル = [そのコマに王（玉）があるか, そのコマに王（玉）を動かせるか, そのコマに角があるか, そのコマに角が動かせるか, そのコマに角が成りで動かせるか, そのコマに角があるか, そのコマに角が動かせるか, そのコマに角が成りで動かせるか, そのコマに馬があるか, そのコマに馬が動かせるか, そのコマに馬があるか, そのコマに馬が動かせるか, ... 中略 ... ,そのコマにと金があるか, そのコマにと金が動かせるか]
つまり
- 自分のコマと相手のコマでコマ状態ベクトルを分離した
- 成りについて成りゴマの動きベクトルに状態を代入していたが専用の次元を作った
これで分離性能が上がるはず。たぶん。
デメリット
- 次元が増えたので学習コストが増える
- スパース性が上がったのでニューラルネットの学習が困難になるかもしれない
- まだ完全に「近い状態に対して近いベクトル」になっていない
簡易測定
測定と言いつつ比較のための前回のログデータを保存してなかった。時間がないのでスクリーンショットベースで。今までのモデルだと以下のような感じでした。２５０００イテレーションあたりを比べます。
前回までのモデルでのスクリーンショット
ロス、２５０００イテレーションで0.5付近
正答率、２５０００イテレーションで0.64付近
今回のモデルでのスクリーンショット
ロス、２５０００イテレーションで0.45付近
正答率、２５０００イテレーションで0.69
バッチのランダムのことを考えると有意に差がある気はしない。けれども性質としては合理的だしプログラムも組みやすいし学習も出来ているので今後はこの入力ベクトルの形式で作業を進めます。
次の予定
- 学習サンプルとテストサンプルの整理
- 左右反転の学習
- 後手の学習
- サンプルを消費し尽くしたら学習を止める処理の実装
- 今まで実験的に学習したモデルは使い捨てていたがエポックを導入して複数回学習させたりする
- そのためにモデルのセーブとレストアを実装する
- ここまでの実装で「学習 -> 学習データとは別の動作で試験」をやってみる
ここまで出来たら一旦勝敗予測モデルは区切りをつけて指し手モデルに着手していきます。