Bonanza型の評価関数の限界について

Bonanza以前の評価関数は挟撃形ならば挟撃する側はプラス何点というような評価をしていたわけですが、Bonanzaで導入された3駒関係(KPP)は、それを内包していました。

これと同様に、4〜6駒関係は自動的に重要なさまざまな概念を内包しているということは言えると思います。昨日と一昨日の記事で見てきたような、3駒関係だけでは表現できていなかった入玉しやすさ・玉頭戦での勝ちやすさetc…。

究極には、N駒関係のNを81まで大きくすれば…いや、手駒が先後7種類ずつあるので14を足して、81+14 = 95まで大きくすれば、盤面全体を覆うことになり、95駒関係を正しく学習できるなら、あらゆる局面の勝ち/負けを判定できることになります。まあ、95駒どころか10駒関係すらも現実的には到底無理ですが、このようにNを大きくしていけば強くなることが保証されていると心強いものがあります。例えば、「探索深さNを無限大に近づけていくと(評価関数の精度が悪くとも)強くなる」みたいな感じですね。

まあそれはそれとしまして、4駒〜6駒の関係を棋譜から学習させるためには、対象となる駒を玉まわりの駒だけに限定したり、金・銀・成駒はすべて同一とみなすだとか、場合によってはそこに駒があるのかないのかだけを問題にするだとか、そういうことが必要になるとは思いますが、工夫してやってみる価値は十分あるのではないでしょうか。

4駒〜6駒関係を学習させたものを実戦投入しないにせよ、実際に4駒〜6駒関係を学習させて、どのような数値がついているのかを観察すれば、新しい知見が得られるかも知れません。

もう少し現実的な話をするなら、現在のCPUはL3 cacheが10MB前後ありまして、ここに評価関数のよくアクセスするところが収まる必要があります。KPPの場合、K(王)は盤面の端から端まで移動するようなことは稀であって、探索深さ20ぐらいですと玉はそんなに移動していなくて、KPPのテーブルのうちの1/5〜1/10ぐらいにしか実際はアクセスしていないと思います。[要検証]

ということはKPPのテーブルはいくら大きくとも50MB程度には収めないと(KPP以外にもテーブルはいろいろ必要なので)、L3 cacheに収まらなくなりまして、大幅な性能ダウンにつながります。そういう意味ではいまのBonanzaのKPPのテーブルはもう限界近いサイズであると言えると思います。

そこでまず、KPPのPの範囲を玉周辺に限定して(そうすると多少弱くなるでしょうが)、その代わりに(余ったL3 cacheの容量を活かして)KPPPやKPPPPを実装すればいまよりもう少しは強くなるんじゃないかというのが私の考えで、Bonanzaのような利きを利用しないような評価関数で頑張るとすれば評価関数としてはもうそのへんがL3 cacheのサイズ的には限度ではないかなぁと思っています。

探索に関してはまだ新しい手法が出てくる可能性はありますし、評価関数もBonanza型ではなく、利きを利用して、GPS将棋のように有望な評価因子を人間が手で探り当てていくという方法でならばまだまだ伸びしろはあると思うのですが、Bonanza型の評価関数を拡張していこうと思うとL3 cacheのサイズから強烈な制約を受けていて、あまり自由が利かないなぁというのも本音であります。

「L3 cacheのサイズが将来的に大幅増になったとしたら、6駒関係までを実装すればR500ぐらい強くなるのになぁ」という妄想を垂れ流してコンピューター将棋界に混乱を撒き散らすのが私に出来るやっとのところであります。

ところで、私が気になっているのはGPS将棋、大会では意外と結果が残せていないということです。あれだけ評価関数に力を入れていれば、ぶっちぎりで優勝しても良さそうなものなのですが、そうはならないところにコンピューター将棋の奥深さを感じます。

利きを計算する(計算機的な)コストが意外と馬鹿にならないのか、それともそれぞれの評価因子の値を個別に計算するコストが馬鹿にならないのか、新しい効果的な評価因子を人間が考える→実装→効果を検証するというターンアラウンドタイムがかかりすぎるところに開発上の問題があるのかなど、私はいろんな憶測をしてしまうのですが、本当のところどうなんでしょうかね…。