リゼロ評価関数では、評価関数をゼロから学習させているが、駒割り(駒の点数)は、Aperyのソースコードで定義されている点数を初期値として用いてある。実際のところ、これがすべてゼロであってもきちんと学習できることは確かめた。
そもそもで言うと駒割りはKKPで表現できるので、それとは別に駒点を扱うことの意義はあまりない。強いて挙げるならSEE(Static Exchange Evaluation)で、駒点を使っていることぐらいであろうか。SEEで使っている駒点はそこまで厳密なものは要求されていないし、枝刈り用の探索パラメーターの一種であるとみなせるので、ここの調整は駒点とは別だと考えて、自己対局から調整したほうが良いように思う。
そうなってくるとそもそも駒点とは何なのかという話になってくる。USIプロトコルでは歩を100点として現在の局面の評価値を出力することになっているが、KKPに歩の価値が乗ってきているなら、本当に歩を100点として計算しているのか怪しくなってくる。
細かいことを言えば、KKPだけではなくKPPにも歩の価値が乗ってくる。いまKKPはないものとして考える。KPPの1枚めの駒をP1、2枚目の駒をP2と書くとしたときに、例えば、P1 = 76歩 だとする。P2は必ず37枚あるので、KPPを計算するときに76歩の価値が1/37ずつ乗ってきているとも考えられる。
このようにKKPやKPPに歩の価値が乗って来ている。こうなっていると、歩=100点で計算しているとは言い難い。いくら駒割りで歩=100点と定めていても、KKPやKPPに歩の価値の学習能力がある限り、歩=100点で正規化された評価値であるとは言い難い。
例えば、今回のSDT5で優勝したぽんぽこは、評価値を他のソフトより高めに出す傾向がある。下手すると倍ぐらいの値が出ている。evaluate()で評価値を計算するとき、その値16bit符号付き整数型に収まらないといけないが、その範囲を超えやしないか、見ていてヒヤヒヤする。
そう考えると、KKP,KPPに乗ってきている歩の価値を正規化して駒点のほうに還元してやるような処理をしたほうがいいような気はする。例えば、KKPに乗っている歩の価値を取り除くには、P=81升の任意の場所の歩に関して、KKPに乗って来ている歩の価値 = ΣKKP / 81 であるから、この値をこの81のKKPの要素から引いてやって、その分を歩の価値に加算しておくことだ。
あるいは、ΣKKP(Pは任意の升の歩) = 0となるように学習時に正則化してしまうかである。
ともかく、現状、このような正則化をしているソフトはないのであるが(たぶん)、評価値ベースで行なう枝刈り(razoringやfutility pruning等)があるので、何らか統一しておいたほうが良いような気はしている。(やねうら王も統一していない状況ではあるのだが、今後、しようと思っている。)
あと、千田先生は局面の良さを将棋ソフトの出力する評価値ベースで(自分の脳に)学習させようとしているそうで、「評価値がいままでのソフトより大きめに出ると困りますね」とのことであった。
技術が進むと厳密な単位が必要になってきて、単位が厳密になればなるほど直感的にわかりにくくなるっていうのは案外普通の流れに思います
おお、なるほろ…。いま、現状、KKP、KPPの自由度が大きすぎて、駒割りまで内包してしまっているのが原因なので、このへん、どうにかしないと出力されている評価値自体が意味のある尺度でなくなってしまいますね…。
KKPとKPPの平均が0付近になるように、駒の価値を修正するのは以前(汎化性能を期待して)やってみました。駒割だけ変更して、KKP,KPPが次の学習で平均0付近に”自動的に補正される”ことを期待したのですが、概ね同程度残りました。評価値的には10以下程度だった記憶が有りますが、FV_SCALEもあるのでそこまで無視出来る数字でも無いはずで、何かマズってたかもです。
我々には見えざる力が働いているのかも…。
技巧が初代より、学習時に適当なイテレーションで駒割を再計算していたと思います
ほほー、そうなんですね!
(技巧のソースコード、追いかけてない勢..)
200が100の2倍であるとは限らないし、200が100の2倍であっても300が100の3倍であるとは限らないというイメージでいい？
そうなっていて、かつ、100が他のソフトの100ではない感じですかね…。
そろそろ歩100点と言われても元あった筋に寄るし，歩得の歩か交換した自分の歩かでも違う。初期状態の先手と後手の差で再定義する方が安定するような気がしてます。
平手の初期局面の先後の差って、どれくらいあるんでしょうね。
2年ぐらい前に千田先生が、初手58玉をソフトに指させてみて、「これは最大でも1手の損にすぎない(初期局面から手番を相手に渡しただけ)ので、この局面で初期局面の評価値より小さくなるのは理屈上、おかしい」ということをおっしゃっていて、なるほどと思いました。当時は将棋ソフトの機械学習があまりうまく行ってない時代でしたので、そのようないびつな評価値を出してしまうソフトが多かったように思います。
パラメータの自由度とパラメータの個数の差の数だけの制約を設定するとして、何が自然な制約なのかって話になると思います。sumを0にするのでなく最大最小の計を0にするとか、二乗ノルムを最小にするとか色々考えられると思います。
そういう制約を入れた上でさらに発展させると、評価関数を線形結合でなくn乗(n<1)の和にすれば個々の3駒関系の影響より複数の駒関係間の組合せに対して高く評価 するように学習してくれるのではないでしょうか。
また別の視点として、学習する上では自由度より高次元に問題にあわせて上手にマップして学習すると収束が早くなるって話もあったかと思います。
> 評価関数を線形結合でなく
これ、いままで成功した人がいないんですよね…。(なぜかはわかりません)
gradientを取る時の微分可能性の問題ですかね。0の近傍で微分できる関数じゃないとだめなのかも。
ああ、またレスつける所を間違えました。すみません。
微分可能性という表現は正しくなかったです。原点での傾きが無限大になるのが良くないのでは、という意味でした。
例えば sign(x) log(|x|+1) みたいなのはどうかな、と思います。