AbemaTVの放送で、AIの出力する候補手1と2の読み筋が途中で合流して同じ局面になるはずなのに評価値が1と2で異なるという状況があったらしく、それを解説していたプロの先生が「これはおかしいですね」とか何とかおっしゃっていたそうなのですが、これについて解説します。
やねうら王を始めとするいまどきの将棋ソフトの思考エンジンは、複数の候補手を出力するMultiPVという機能があります。AbemaTVの思考エンジンもこのMultiPVを用いて出力しているのだと思われます。
予測される状況１
ところが、AbemaTVのSHOGI AIでは、複数エンジンの評価値を組み合わせて期待勝率を出しているようです。
なので、
・エンジン1が、候補手A,B,C
・エンジン2が、候補手A,C,D
・エンジン3が、候補手A,C,D
のように候補手を出力した場合、候補手Aは、3つのエンジン(が候補手Aを指した時)の評価値の平均ですが、候補手Bはエンジン1のみの評価値となるのではないかと思います。
この場合、候補手AとBでそのあと同じ局面に合流するとしても、AとBとでは異なる評価値になることはありえます。(エンジン1は候補手AとBとで同じ評価値を出力しているとして)
予測される状況２
AbemaTVのSHOGI AI、候補手が変わるタイミングが早すぎます。やねうら王系の将棋ソフトは普通、反復深化法を用いて探索しているので、1手ずつ深くしながら読んでいきます。ConsiderationModeがtrueのときは、この1手深くするタイミングで読み筋を出力します。読むべき局面数は2のdepth(読みの深さ)乗ぐらいで増えていくので読み筋を出力する間隔は指数関数的に増えます。
これが指数関数的に増えないということは、「1手深くするタイミング」で読みを出力しているのではなく、反復深化の途中の読みも出力しているのだと思われます。
ところが反復深化の途中ではfail high/lowしていると読み筋はそこで途切れてしまいますので、それを回避するために置換表から読み筋をかき集めてこなくてはなりません。
置換表から読み筋をかき集めてくる途中であれ、他のスレッドは依然探索途中であり、1つ目の候補手の読み筋を出力したのちに2つ目の候補手を出力するまでの間にも置換表は更新され、(合流したあとの)読み筋が変わることがあります。このため、1と2の指し手が合流するにも関わらず、それぞれが異なる評価値を出力することは(このへんの作りによっては)ありえます。
予測される状況３
やねうら王などは、LMR(Late Move Reduction)という枝刈りをしていますが、これは、その局面のよさげな指し手順に並び替えて、あとのほうの指し手は指される確率が低いだろうから調べない(枝刈りする)という手法です。
ざっくり言うと、思考開始した局面から1手目は全部の指し手、2手目は上位の10手だけ、3手目は上位の8手だけ…みたいな感じで先の局面にいくほど絞っていきます。あるいは逆に王手は1手延長する、良さげな指し手のあとはreductionを甘めにする、みたいなものもあります。
要するに、2つの候補手の読み筋が同一局面に合流するとしてもそこまでの経路によってその局面の実現確率が異なるので、そのあとの枝刈り具合が違うということは(探索部によっては)ありえます。
枝刈り具合が異なるので、それぞれ異なる読み筋になることもあり、評価値とはleaf node(読みの末端局面)で評価関数から返ってきた値なので、読み筋が異なると異なる評価値になってしまいます。
結論
そんなわけで、MultiPVモードで2つの候補手が途中で合流するのにそれぞれが異なる評価値になることは、時々ならあるのでは？ということで。
上記は例え話でしょうけど，実際のLMRはもっと過激に入ってますね。
また，評価値は読みの末端局面の評価値に違いないですけどPVはそこまでの読み筋を正確表示されないと言うか，現状置換表起こしなのでかなり不正確ですよね。
これを以前からもう少しなんとかできないか考えてます。
> 現状置換表起こしなのでかなり不正確ですよね。
ConsiderationModeがfalseの時は、PV配列をそのまま出力します。PV配列は、Bonanzaにも備わっていたもので、search()を再帰的に呼び出すごとに1手ずつ三角配列に記録しておき、β cutでPVが変わった時に小さな更新コストで変更するためのものです。しかし、MultiPV時にこの配列の更新がうまくなされないロジック上のバグがあるっぽいので(←私の推測)、ConsiderationModeがtrueの時は仕方なくTTからかき集めて出力しています。このコードはStockfish側のコードが修正されたら、変更しようと思っています。
> 上記は例え話でしょうけど，実際のLMRはもっと過激に入ってますね。
ですです。ちなみに「たとえ話」は漢字では「喩え話」と書きます。← たとえ警察
ABEMAのAI表示にほぼ当事者レベルで関わってるかと思ってましたが、そうではなくて、あくまで合議用エンジンのひとつを提供しているだけという感じでしょうか？
大人の事情によりノーコメントでございます。(´ω｀)
(^ω^ )
千日手回避とかは？
私の心はチョココロネという手順で続いたときと私の時刻はチョココロネという手順で続いたときで、チョココロネに合流したときに既に使われている文字が心か時刻か差があって、後で変化していく先で地味に勝率が違うとか。
何言ってんのか、全然頭に入ってこないよ!ヽ（`Д´）ﾉ ｳﾜｧｧｧﾝ
2つ(以上)の手順が合流する他に、さらに何手かの手順を巡って合流する手の盤面に戻せてしまうような状態。
そこで同じ手を繰り返してはいけないから、ちょっとずらした手でチョココロネのスパイラルのように手が進んでいくけど、その時に使っていい盤面というのが減ってるからその分だけ評価が変化するのではと。
なお、刻の字のチョココロネの向きは斜めより、うんこを出す側が下向きになる方向にするほうが、亥の部分の斜めな線がチョココロネスパイラル捻りと合うかと。
合流 + 千日手は面白いトピックだとは思うけども、「その時に使っていい盤面というのが減ってるからその分だけ評価が変化」は、盤面評価を指し手の自由度(指し手の数とか)で評価してるなら、そういうことも起こり得るかも知れないけども、PV leaf(読み筋の末端)で評価関数を呼び出してるだけなので、指し手の自由度は直接的には評価値に影響を与えないのだ。
あ、状況3で千日手の回避のような手から続いていく読みはあり得るかもしれないけど、ゲームの進行状況を見てそれを特例として扱って読んでいくことは(そういう動作をわざわざさせるようなコードを書くことは)ほとんど無いですよというあたりなのかな？わからないけど、まあいいやｗ
自分の手番のほうが相手番の時より勝率が高いのはなぜでしょうか？（最善手を指しても相手番になると必ず少し勝率が下がる）（序盤だと１～２％、終盤だと20％近く変わることがある）勝率１％が評価値換算するとだいたい70くらいだと思いますが、1つのソフトの評価値だとほとんどかわりませんよね。
探索開始直後なので一時的に下がっているだけではなくて？
違いますね。abemaの担当者も手番の側が高くなると言ってました。解説の人はソフトは手番の側を有利に判定するって笑い話で終わってましたけどなんでかなと思って。番組少し見てもらえばわかると思います。
それはえーと、双方の持ち時間の消費量の合計あたりを見て、例の3一銀の手へ既に到達できてる枝があるか、まだ到達できてないかの違いみたいなイメージでいいですか？
手番の差の分だけ持ち時間の消費量にどうしても差が出てるというあたりで。