TadaoYamaokaの開発日記

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

将棋AIの進捗 の検索結果:

将棋AIの進捗 その31(cuDNNによるSENetの推論処理の実装)

dlshogiの10ブロックのWideResnetの自己対局による強化学習を続けていましたが、230サイクルほどでほぼ頭打ちになりました。訓練損失は下がり続けていますが、floodgateの棋譜に対する損失が上昇傾向になっており、技巧2のとの勝利も上がらないため、このモデルでの強化学習は打ち切ることにしました。 技巧2(4コア CPU)との勝率は、GPU2080Ti1枚、1手3秒で32%程です。 訓練損失 floodgateの棋譜に対する損失 floodgateの棋譜に対する…

将棋AIの進捗 その30(NNキャッシュ)

先日、Leela Chess Zeroのソースを流用して、LRUキャッシュを実装したが、これを自己対局プログラムに組み込んだ。はじめ、LRUキャッシュを1つにしてすべての探索スレッドで共有するようにしたが、ゲーム木の展開済みノードのNN計算結果が、他のスレッドの探索によって削除されることがあった。 キャッシュサイズを十分に大きくすればよいが、メモリ効率が悪いため、探索スレッドごとにNNキャッシュを保持するようにした。 それにより、必要なキャッシュサイズの見積もりが可能になる。…

将棋AIの進捗 その29(自己対局におけるノードの再利用)

先日の記事に書いたが、AlphaZeroは自己対局時にノードの再利用を行っている。 dlshogiでは、先手が探索した結果を後手が利用することになるため(逆も同様)、先手と後手の探索のバランスが崩れるため、ノード再利用を行わず各手番でハッシュをクリアしていた。しかし、先日の記事で考察した通り、ルートノードをクリアすることで、ノードを再利用しても先手、後手の偏りはそれほど問題にならないと思われる。 そこで、実際にノードを再利用しない場合とする場合で、精度を比較してみた。 測定条…

将棋AIの進捗 その28(探索時のノイズの効果)

世界コンピュータ選手権まで残り1ヵ月もなくなったので、強化学習で強くするのはあまり望めないので探索部の調整を行っている。以前のdlshogiでは、Policyの読み漏れによって、受けを間違えて数手先で詰まされる状況がよく起きていたため、Policyにノイズを加えて対策を行っていた。 ノイズをどれくらい加えるかは、GPSFishと対局の勝率から手動で調整を行い、効果が高かった1手目と3手目に加えていた。手動で数回の実験で適当に決めていたこともあるので、今回ノイズの効果を測定し直…

将棋AIの進捗 その28(弱点の克服)

前回、自己対局の報酬を詰み探索の結果に変更したことで、valueの精度向上したことを書いた。詰み探索結果を報酬にしたのは、評価値が2000近くある局面から、詰みが見つかり一気に負ける局面があるためだが、そのような局面をより積極的に是正することにした。 方法 優勢と考えていた局面から負けた局面の評価を正しくするには、そのような局面を学習する機会を増やせばよいため、そのような局面を抽出して初期局面集に追加することにした。今まで自己対局で生成した局面を3億局面以上残しているので、そ…

将棋AIの進捗 その27(やねうら王に初勝利)

前回記事にした自己対局の終了判定にdf-pnによる詰み探索を加えて、学習を進めた結果、valueの精度が1%近く向上しました(floodgateのR3500以上の棋譜との一致率)。 横軸の80サイクルから詰み探索を加えています。どれくらいの棋力になったか、やねうら王 2017 Early KPPT 4.55(標準設定)と対局させてみました(GPUは1080Ti1枚、CPUはCorei7 6700K、1手3秒)。 まだ対局数は多くなく、勝率は非常に低いですが、数回は勝つことがで…

将棋AIの進捗 その26(自己対局による強化学習の経過2)

前回から時間が空いたが、自己対局による強化学習を続けている。10ブロック、192フィルタのモデルの自己対局による学習が、79サイクル※回したところで飽和気味になったため、10ブロックのモデルからパラメータを転移して15ブロックのモデルで強化学習を行うことにした。 ※1サイクルで、250万局面を生成(55サイクルまでは500万局面にしていた) 自己対局の速度比較 10ブロックの自己対局では43.1局面/秒で生成できていたが、15ブロックにしたことで37.30局面/秒になり、局面…

将棋AIの進捗 その25(自己対局による強化学習の経過)

前回からだいぶ期間が空きましたが、自己対局による強化学習で、教師ありで収束するまで学習したモデルより有意に強くすることができました。前回は、19イテレーションでほぼ互角の強さでしたが、38イテレーションまで自己対局を行うことで有意に強くなりました。 自己対局における探索延長 強化学習の方法は前回までの方法とほとんど同じですが、途中から探索延長を行うように変更しました。 探索延長は、固定回数シミュレーションの結果、1番目に訪問回数が多い手が2番目に訪問回数が多い手の1.2倍未満…

将棋AIの進捗 その24(自己対局による強化学習)

これまではAperyの初期局面集にfloodgateの棋譜を加えたものを初期局面集として自己対局を行っていたが、中終盤のバリエーションを増やすため、 やねうら王教師局面からAperyの初期局面集を作成(評価値200以内局面を抽出) 初期局面集から詰みの局面を除く という方法で、初期局面集を作成した。 出来上がった初期局面集は、重複なしで394,003,767局面になった。 これだけあれば、自己対局で局面が重複することはないため、自己対局の効率を上げることができる。 自己対局に…

将棋AIの進捗 その23(探索と評価の直列化 その2)

前回、対局プログラムを探索と評価の直列化することによって高速化を行ったが、自己対局プログラムについても探索と評価の直列化を行った。以前は、探索を複数スレッドで行って、ニューラルネットワークを計算をキューにためて専用のスレッドでバッチ処理を行っていたが、スレッドの同期がボトルネックになっていた。 2枚のGPUのPCで、GPUごとに180スレッドと140スレッドという大量のスレッドで探索を行い、ニューラルネットワークの計算完了を探索スレッドでビジーウェイトで待機していた。 ニュー…

将棋AIの進捗 その22(探索と評価の直列化)

前回、ねね将棋が世界コンピュータ将棋選手権で高い探索速度を出していたので、バリューの計算中に末端ノードから新しく探索を行う方法で簡易な実装をして実験を行った。 しかし、末端ノードから新しく探索を始めると、新しく始めた探索のバリューの計算されるまで、元の探索のバックアップが行われないため、正しくゲーム木が成長しない状態となっていた。そこで、ねね将棋と同じように経路を保存して、バッチで評価した後にバックアップを行う実装に変更して検証をやり直した。 ねね将棋では、シングルスレッドで…

将棋AIの進捗 その21(探索の深さ)

dlshogiでは、MCTSの末端ノードでバリューを計算し、その値をバックアップしているが、GPUでバリューの計算が終わるまで待機している。 バリューの計算が終わる前に次の探索を始めると、ノードにバーチャルロスのみが反映された状態で、勝敗の推定値が反映されておらず、その状態で探索すると精度が落ちるためである。 そのため、GPUを増やしても探索速度(シミュレーション/秒)が上げられない点が課題となっている。第28回世界コンピュータ将棋選手権で、ねね将棋が、CPUを1スレッドにし…

将棋AIの進捗 その20(自己対局による強化学習)

自己対局による強化学習を続けています。 現在、1サイクルあたり500万局を自己対局で生成するサイクルを17サイクル実行したところです。 教師ありでelmoで深さ8で生成した4.9億局面を事前学習したモデルを初期モデルとしています。 初期モデルは、収束前のLesserkaiには勝つがGPSfishには1度も勝てない程度のモデルです。数サイクル回した時点では、初期モデルに対して弱くなっていましたが、17サイクル回したところで、やっと初期モデルに対して1手3秒の50回の対局で有意水…

将棋AIの進捗 その19(初期局面集)

自己対局による強化学習を行う際に、対局の開始局面には、初期局面集を使用している。 AlphaZeroでは、固定手数まではノイズを加えルートノードの訪問回数に応じた確率で手を選択することで局面の多様性を確保している。 しかし、この方法ではモデルに依存した限られた序盤進行になってしまうため、初期局面集を使う方が良いと考えている。 実際のところは、どちらが良いかは検証してみないとはっきりはわからない。他の将棋AIでも決まった方法があるわけではなさそうだ。 Aperyでは、初期局面集…

将棋AIの進捗 その18(スケーラビリティ)

AWSのp3.8xlargeインスタンスを試験的に借りてGPUを増やした場合の性能を測定しました。 Linuxだとマルチスレッドの性能がでないので、OSはWindowsです。p3.8xlargeのマシンスペックは以下の通りです。 Tesla V100 GPUs 4 vCPUs 32 Main Memory 244GiB 各GPUに割り当てる探索スレッド255として、GPUを増やしながら平手初期局面での探索速度(シミュレーション/秒)を測定しました。 GPU枚数 探索速度(シミ…

将棋AIの進捗 その17(AWS対応を検討)

世界コンピュータ選手権の参加者のマシンスペックをみると、マシンスペック高すぎです( ゚Д゚)GPUを2枚詰んだ個人のPCで参加しようと思っていましたが、GPU8枚とかで来られたらモデルと探索の性能ではどうにもならなそうです。 モンテカルロ木探索は並列化の効果が高く、私の実験でも、GPUを2枚にするだけで、GPSfishに対して勝利が40%から75%(R+261)に上がっています。 8枚になると単純計算で、R+2088です(実際は線形には伸びませんが)。ということで、AWSでp…

将棋AIの進捗 その16(マルチGPU)

将棋AIをChainerを使用した実装からcuDNNを使用した実装に変更できたので、マルチGPUでの性能を測定した。 Chainerを使用した場合 Python経由でChainerを使用しているPythonのGIL機構によってマルチスレッドの性能に制限がある。 Chainerを使用した場合の、マルチGPUによる効果は1.33倍程度であった。 playout/sec シングルGPU(Titan V) 5724 マルチGPU(Titan V+GeForce 1080 Ti) 76…

将棋AIの進捗 その15(cuDNNを使用)

モデルの学習にディープラーニングフレームワークのChainerを使用していますが、対局時にChainerで推論を行うと、Python経由で呼び出すためマルチGPUで動かす際、Python経由だとGILによってマルチスレッドの性能が出なくなる。 また、実行環境にPythonが必要になるため、実行バイナリを配布しても利用者側で環境構築が必要になってしまう。それらの問題を解決するため、対局時にはChainerを使用しないで、cuDNNを直接しようして推論を行えるようにした。 実装方…

将棋AIの進捗 その14(自己対局による強化学習)

自己対局による強化学習の検証をはじめた。強化学習の手法は、以前の日記で書いた通りで、Alpha Zeroの手法を参考にして、1手800シミュレーションで自己対局を行う。自己対局→学習のサイクルを繰り返してモデルを成長させる。 1回のサイクルで、どれだけの自己対局を行うかは、AlphaZeroの論文には記載がないが、AlphaGo Zeroの論文には、 In each iteration, αθ* plays 25,000 games of self-play, using 1…

将棋AIの進捗 その13(自己対局のマルチGPU対応 その2)

前回マルチスレッドで2つのCPUを使用して自己対局を行うプログラムを作成したが、局面生成の速度はGPU1つの場合と変わらなかった。 ChainerをPython経由で使用しているため、GILのために効率が上がらなかったためと考えている。そこで、プロセスを分けてマルチプロセスで実行するようにした。 単に引数でGPU IDを指定できるようにしただけで、特別な仕組みはない。マルチプロセスで100スレッドずつで実行した結果、局面の生成速度は以下の通りとなった。 比較のため前回の結果も…

将棋AIの進捗 その12(自己対局のマルチGPU対応)

自己対局のプログラムをマルチGPUに対応させました。処理方式は、対局プログラムのマルチGPU対応とほとんど同じです。マルチGPU対応により局面生成の速度がどれくらいあがるか測定しました。 測定条件 シングルGPUは、TitanV 1枚。200スレッドで対局。 マルチGPUは、Titan VとGeForce 1080 Ti。GPUごとに100スレッドで対局。 モデルは10ブロック、192フィルターのResNet 測定結果 局面/秒 シングルGPU 9.30 マルチGPU対応 9…

将棋AIの進捗 その11(マルチGPU対応)

GPUが2つになったので、dlshogiをマルチGPUに対応させました。ニューラルネットワークの計算要求をキューにためてミニバッチで推論を行う仕組みにしていたので、キューをGPUごとに用意して、探索スレッドを一方のキューに対応させて、キューを監視してニューラルネットワークの予測を行うスレッドをそれぞれのGPUごとに用意する仕組みにしました。はじめ、単にニューラルネットワークの計算用のスレッドを2つにしてそれぞれが、Pythonの処理を呼び出してChainerに推論を行わせれば…

将棋AIの進捗 その10(Linux対応)

ChainerのMNISTサンプルをUbuntuで動かすとWindowsよりも早いことがわかったので、dlshogiの自己対局をUbuntuで行えるようにした。AperyのMakefileを参考に、g++でビルドできるようにした。Windowsで32スレッドで1手800シミュレーションで自己対局を行うと、2.68局面/秒で生成できる。Ubuntuで同じ条件で実行すると、期待に反して1.03局面/秒でしか生成できなかった。 コンパイルオプションはAperyにbmi2をターゲット…

将棋AIの進捗 その9(千日手対応)

dlshogiを千日手に対応させました。対応方法は以下の通り。 value networkで評価中に千日手チェックを行い、value networkの評価が終わったら、value networkの値を使わずに千日手チェックの結果を使うようにする。 同じ局面でも経路によって千日手チェックの結果は異なるため、ハッシュのvalue networkの評価値を上書きしない。 同じ局面を探索したときに、以前に千日手になった局面は、再度千日手チェックを行い、千日手の場合、探索を打ち切る。 …

将棋AIの進捗 その8(ponder対応)

電王トーナメントの出場ソフトが公開されました。 私のソフトは「dlshogi」です。 denou.jpディープラーニングを使ったソフトがいくつか出場するようです。 対局できるのが楽しみです。 電王トーナメントに向けて、時間制御まわりを改善しています。 ひとまずponderに対応させました。USIのponderの仕様は、ponderhitの際、続けて思考するための残り時間情報が渡されないので、通常のgoの処理と分けないといけないのが面倒ですね。 バグがないか確認のためにfloo…

将棋AIの進捗 その7(詰み探索の有効性)

df-pnの検証のために、詰みの局面でテストしていたが、やねうら王では詰みと出る局面で不詰みの判定になる局面があった。調べてみると、次のような王手でない局面で、相手がどんな手を指しても次の王手で詰みとなる局面だった。 df-pnの指し手生成に王手のみという条件を入れてしまうと、こういう局面が正しく判定できなくなる。 しかし、連続王手以外を探索に含めてしまうと、df-pnの中間ノードでのpnとdnの値がほとんど無意味になってしまうので、探索空間が膨大になってしまう。これを解決し…

将棋AIの進捗 その6(df-pn)

前回の日記で書いた通り、df-pnの実装を行いました。実装の参考にしたのは、以下の論文です。 CiNii 論文 - df-pnアルゴリズムの詰将棋を解くプログラムへの応用 コンピュータ詰碁の探索戦略の改良 上記の論文にはほぼ同じ疑似コードが掲載されていますが、ANDノードとORノードで処理を共通化しており、理解しづらかったため、ANDノードとORノードを別々の処理として記述した。 速度比較 次の15手詰めの局面で、df-pnと優先なし探索で速度を比較した。 position …

将棋AIの進捗 その5(王手の指し手生成)

前回の日記で、Aperyに王手の指し手生成がないという話を書いたが、仕方がないので自分で実装した。やねうら王には王手の指し手生成が実装されていたので、実装方法を参考にさせてもらった。 YaneuraOu/movegen.cpp at master · yaneurao/YaneuraOu · GitHubやねうら王ではマクロを使っていたが、少々分かりにくかったのでマクロを使わずに実装した(その分冗長になっている)。 使用方法 for (MoveList<Check> ml(p…

将棋AIの進捗 その4(詰みの探索)

前回の日記で、末端ノードで詰みの探索を行う予定と書いた通り、詰みの探索をするようにしました。ディープラーニングは詰みの探索が苦手なので、ディープラーニングと詰み探索を組み合わせるのは有効だと思っています。 Policy Network、Value Networkの計算中は、CPUが空いているので、詰み探索を行ってもNPSへの影響はないので、確実に終盤の棋力向上につながるはずです。 といっても、棋力でいえばPolicy Network、Value Networkの精度の方が重要…

将棋AIの進捗 その3

以前の日記で、電王トーナメントに出るつもりと書いていましたが、申し込みをしました。 予選通過も厳しそうですがとりあえず頑張ります。 さて、前回からの進捗ですが、35億局面の学習が3エポック回したところで飽和しました。 一致率は、Policy Networkが46%、Value Networkが78.1%となりました。Policy Networkは強化学習を行っているので、単純に一致率では評価できませんが、少し微妙な感じです。 入力特徴、ネットワーク構成、フィルターサイズなど変…