前回、DNNの方策に従来型エンジンのbestmoveをブレンドすれば読み抜けが減らせるのではないかというアイデアを示しました。
このアイデアが成立する条件として、DNNで1局面を評価するのと同程度の時間従来型エンジンに手を読ませたときに、DNNが見落とした（確率を非常に低く見積もった）にもかかわらず最善の手を発見できることが必要です。 探索速度を手元の普通のPCで測定しました。CPUはCore i5-7600K(物理4コアHTなし)、GPUはNVIDIA GTX 1060 6GBです。従来型エンジンにはelmo(2019年、評価関数はNNUE型)を用い、DNNを用いたエンジンにはGCT(電竜戦2020)を用いました。elmoは8スレッドで動作させ、300万nps程度でした。一方GCTはバッチサイズ16で動作させ、2500nps程度でした。バッチサイズ128だと3000nps程度出ますが、1手1秒でelmoとGCTを対局させた際、バッチサイズ128だとelmoが100%勝利する状況でした。バッチサイズ16だとelmoが80%勝利するという状況で、こちらのほうが強かったため採用しています。この実験環境では、GCTで1ノード評価する間にelmoは1000ノード程度探索が可能といえます。もちろんこの比率はCPUのコア数、GPUの性能により容易に10倍程度の変動が生じます。
まずはGCTが読み抜けを起こすような局面を探す必要があります。GCTとelmoを1手1秒で対戦させ、棋譜と同時に評価値を記録しました。その結果、下図のような評価値グラフが得られました。グラフから自動的に読み抜けを発見する数式はまだ構築できておらず、目視で読み抜けと思われる事例を抜き出しています。
値はelmo（この対局では先手）側から見た符号に合わせてあります。60手目付近で、GCTは自分が良いと思っていますが直後にelmoが良いという判断に大きく変化しています。この付近の局面で読み抜けがあったのではないかと予想されます。
60手目付近の進行です。59手目▲44銀打（elmoの指し手）のあと、△46金（GCTの指し手）、▲53銀成、△47金、▲52成銀と進みました。この付近の局面を、GCTとelmo両方に読ませ、先手番から見た評価値をプロットしたものが下図になります。思考時間は実際の対局と同じ1手1秒です。
63手目の思考時点でelmoは先手良しとしていますが、GCTはまだ気づいていない、という状況です。なお62手目時点ですでにGCTとelmoで評価値に差があります。62手目をelmoに30秒読ませたところ先手から見て341点、GCTに30秒読ませたところ先手から見て238点となり、62手目の1秒での評価はelmoのほうが正しいようです。問題の62手目ですが、GCTが△47金を指しました。GCTが想定する応手は▲18飛となっていました。しかし実際は▲52成銀で、予想が外れています。▲52成銀が指された後の局面（64手目）ではGCTで評価しても先手有利であることを認識できています。64手目以降の局面評価は正しいが、△47金を指す時点ではこの応手が見えておらず、誤った評価の元で△47金を指してしまったと考えられます。△47金の直後の局面（63手目）をGCTで30秒間思考させたところ、最初の読み筋は▲18飛ですが、思考が進むと正解の▲52成銀が出てきました。DNNの方策を表示させた(DebugMessage=true)ところ、最大確率は▲61飛車打(24%)で、▲18飛は6%で5位、▲52成銀は1%で14位でした。かなり順位が低い指し手のため、探索初期では全く検討されません。一方で、一度検討されると有力であることを認識できています。この手を早期に検討できるようにすることが有力であると考えられます。そしてこの指し手がelmoで1000ノードだけ思考させた場合(NodesLimit=1000)に最善手となるかどうかが課題です。試したところ、10回中8回は▲52成銀を出力し、2回は▲44歩でした。マルチスレッドの影響でランダム性がありますが、この局面では高確率で正解の手を出力することができました。
今回試したのはあくまで1局面ですが、DNNの方策関数が見落とした最善手をelmoが1000ノード分の探索で見つけられるということがわかりました。方策関数に対して従来型エンジンの最善手をブレンドするというアイデアに対する肯定的な結果が得られました。実際には、従来型エンジンの最善手が間違っていて探索の邪魔になってしまうケースがありうるため、統計的にメリットが得られるのかどうか検証することが今後の課題となります。
