【オセロ,将棋】ボードゲーム Part3【囲碁,War】
比較的地味なボードゲーム専用のスレが欲しくて立ててみました。
前スレ
【オセロ,将棋】ボードゲーム Part2【囲碁,War】
https://mevius.5ch.net/test/read.cgi/gamedev/1508056498/ 軽く計算してみたけど8TBのHDDをもってしても12〜13手くらいしか全記憶できないっぽいな
うーむ 盤面情報と勝率情報をテーブル分けてidでjoinする方向で検討。
親子関係もテーブルに持つようにするかも。 F5f6の筋また死亡。
死亡復活を繰り返して3回目くらいに復活安定した筋もあるので、まだまだかかるかも(汗
というか、こういう作業が面倒臭い。 C++からpostgre sqlにテストデータを1件登録することに成功した。
夢が広がるなぁ テーブル定義は段々固まってきたけどどういう順序で探索ツリーを展開するか一番肝心なところが決まってない。 探索が進むほど有望な局面を選択できるようにしたいがやはりMCTS系の探索だろうか? F5f6の筋復活(汗
その代わり、F5d6E6f4とF5f6E6d6(対称形)に差が出てきて、評価値がずれた。
F5f6E6d6の棋譜をすべてF5f6E6f4に変換して、Bookにはf4系とd6系の2種類登録
しているので、ここの間では差が生じないが、例えばF5f4E3〜の筋からたまたま
F5d6E6d6とかに合流してくると、その棋譜については対称変換しないので、差が
生じてしまうという事になるかなと気が付いて、対称変換で差が生じている棋譜を
Bookから逆生成してみたところ結構な件数が…というか、ざっくり見積もって既に
3万件超え。どうやって復旧するか悩むところ。というか、おそらくこれやったらまた
F5f6の筋が死亡しそうな予感。これから対策を考えます。むむむ。
そのほか、部分的に遡って完全読み切りした時に、そこまでたどり着いていない
筋の方が良い評価値になってしまうという、Bookに生じる矛盾を解消する処理を追加。
こちらは結構綺麗にできた。 対称形の合流問題、一応のプログラムできた…と思う。
ロジック的には色々なやり方があるのだけど、処理時間とどこまでやるのかという
ところが悩みどころ。今のままで動かすか、どうするか。
ちょっと悩みたいので一旦ペンディング。 一晩寝かしてプログラム破棄(汗
もともとある対称盤面の処理ロジックを生かして、F5筋しかない棋譜をC4/D3/E6に
対称変換する事で、根本的に解決しようという方向になりました。副作用はBookが
4倍に膨れるのと、F5スタート限定だった評価関数のエラーがいったん大きくなって
しまうために、学習しなおさなければならない事です。
やってみたら、Bookサイズでかすぎてメモリーギリギリ。仕方がないので60手目まで
作っていたBookを40手目までに限定。あと敢えて残して(意図的に作って)あった、
24手目以降のベストではない分岐も別途保存して一回削除しました。
メモリ64G以上欲しい…。スレッドは16くらいで十分なので。 Ryzen Threadripper 3990Xに最適化したDDR4-3600 256GBメモリキットがG.SKILLから
ttp://www.gdm.or.jp/pressrelease/2020/0212/338305 今更だけど、メモリよりHDDのほうがでかいわけだが、全部メモリに乗らないとするとどうやってプログラム組めばいいか悩ましいな。
ホント今更だけど。 スピードが必要な部分はメモリーに無いといかんわけで。
今は探索でBookを参照しているので、Bookアクセスには速度が必要なわけで。
Bookは重要だけど棋譜は既に重要ではないわけで。
棋譜はSDDに移そうかなと思っていたりします。
どうせ要所要所で保存しているわけだし、都度読み込めばみたいな。
(HDDは遅すぎるので論外かと)
ただ…今のロジックがメモリー前提なのと、棋譜ですら読み込みに数秒かかる
状態なので、できればメモリーに置いときたい。そもそも、大した容量じゃないし。
自分の場合、本体でBook読み込むのと、同時にZebraと突き合わせながら間違い
箇所探しで掘り進める用に、Bookを確認するプログラムも同時に動かしていて、
そちらでも同じサイズのBookを読み込まざるを得ないので、16Gのメモリーが
あっても、半分くらいに抑えておかないといけないという問題があります。
頭の片隅にバイナリファイルのランダムアクセスってのがちょこっとだけありますが、
それって自分用DBを作るようなものなので、悩み中。とはいえ、最終的にもしオセロ
の対戦プログラムにするのなら、今ほど探索時間気にするわけでもなし、動作環境
として要求するメモリー量が大きすぎるのもなんだかなぁと思っていたりもします。 そんな事より、対称形サポートして棋譜作っていたら、またF5f6系が全滅して
途方に暮れていたところで、知らぬ間に復活していたり。間違い可能性高い
パブリックドロー筋が復活したと思ったら、またダメだったり。
まだ棋譜作成が足りていないという事実に直面しています。 対称形サポートでBookはだいぶ良くなって来た感じですが、完全読み切りの探索時間
が遅くなった。まだ新しい教師データに対して学習不足なんだと思いますが、どこまで
復活するか。
残り30手読み切り時間がかかりすぎる。棋譜作成のプログラムの方は、ほぼ出来上
がってしまったので、動作具合を見ているだけになっている。何か探索高速化のネタは
無いものか。
PC一つ買って、そちらでオセロの棋譜作成させながら、別の何かの開発を始める時な
のかも知れない。 とりあえずモンテカルロ1000poで10〜50手打ち進めてその局面で100000po回して結果の黒番の勝利回数、スコアの合計を収集するプログラムを作成。
あんまりいい方法じゃないとはおもうけどこれだというアイディアもないしこれで一回やってみます。 マシンパワー欲しいすな。
3990xでも足りないかも。
アルゴリズム見直せと言われそうだが。 まーでも310さんも言ってるけど計算にマシン取られるとヒマですね。
AWSとか使うのも面白いかもしれないけどいかんせん金が… 夜中動かすとファンがうるさくてねれないorz
やっぱaws…
でも金が… でもまあ、コロナでいつポックリいくともわからないならいっそ3990x買っちゃうってのも考えようによってはなくなないな。 たぶん感染経路不明な感染者が1000人超えたらテレビも飽きてきて
めっきり話題にならなくると思うなw 70499種類の盤面のモンテカルロ勝率スコアデータが取れました。
これをもとにDNNをトレーニングしてみます。 やっぱ素のモンテカルロに勝てない!!!
どうしてなんだ… キター!素のモンテカルロに勝ち越しました!
黒番 31勝20敗
白番 32勝19敗 モンテカルロが間違える局面で間違いを訂正してそれをDNNに学習させる方法ないかなぁ 間違える局面が特定できているて、間違えた手を訂正できるんなら、
訂正後から対戦再開させて、その棋譜で局面DB更新して、学習するとか。
特定できていなくても、基本強化学習は、対戦→DB更新&学習の
繰り返しで、徐々に間違いを訂正していく方法。もうちょっと工夫する
ならε-Greedyなどの手法で既存の棋譜の途中で無理やり別の手に
分岐させていく。その手が悪くても、「悪い手である」という認識を学習
させる事ができる。
線形計画だとモデルが上手くできていないと学習が飽和しちゃうけど、
DNNだったらある程度うまく学習してくれるかも。 >>127
特定も訂正も現状できてないですね。
それよりひどいバグを発見して>>115で取ったデータが全て台無しになる可能性が… あかん、なんか全然おかしいorz
ちゃんと見直さないと… 間違い探しを続けるうちに、何故Zebraの評価値の方がまともに見えるか問題に
突き当りました。で、評価関数を手数毎に60種類に分割している事で、学習データ
が不足しているとか、スムージングしていないために、2手前の自分の番の盤面との
差分が取れないとかの問題があるのかなぁと思い立ちまして…。
また、4対称採用した事で学習時間も4倍になってしまいまして…。
思い切って、評価関数を1つにまとめてみたらどうだろうと思い立って、専用の学習
プロジェクトを作ってやってみました。通常数百回学習しないとまともな学習ができ
ないのですが、20回学習したところで、意外とフィットしてしまいました。学習時間も
少し減ってる気がする。
一旦評価関数の癖を変えたほうが強化学習も進むかなと思い、とりあえず本番採用
してみました。気持ち速度も速くなった気がしています。もっとも、評価関数の学習具合
によってαβのorderingも変わって速度が変わったりするので、今後学習を積み重ね
て、過学習気味になったりした時にどうなるのかは不明。
これから数日動かしてみて、良かったらこっちにしようかと思います。強いオセロAIを
作るのなら、対戦してどっちが強いとかやるのが本来なのですが、特にそういう目標も
現状あるわけでなし(汗 >>127に捕捉しとくと、
自分はGreedyな手法の精度をあげるために、浅い探索(9手)と組み合わせて、
評価値が少しだけ悪い手とか、Book登録ないのに評価値が良いとか、いくつかの
基準の訂正ロジックを作って、明らかに悪い手を排除したGreedy法をとって、
既存の棋譜に対して順次分岐を生成していく事で、Bookを埋めて行っています。
分岐は13手読みで作成していますが、この分岐も間違いがそれなりにあるため、
間違いを積み上げているのではないかという懸念もあります(汗
オセロの場合、黒白両者とも最善の場合、引き分けに収束する可能性が濃厚なため
初手から最善引き分けとなるツリーについては、先頭側からこのGreedy法で分岐を
生成し、また(後ろから)確定読み切りを優先して実行する事で、引き分け手順だけ
優先的に精度を上げています。
評価関数作るのに、こういう制約をつけた方法が良いのかは不明です。現に極端に
形勢が傾いた盤面の読み切りは、学習データが不足しているために、引き分け盤面
よりずっと時間がかかるように感じています。 げげ。>>131の奴、本番に入れて学習させたらうまく動かん…。
原因箇所は特定できたけど、そもそもBook分だけで学習していて、後半の棋譜から
教師データ作ってなかったので、件数が大幅に違う。後ろ15手分が抜けている。
が、これが入ると学習の途中で無限ループに入ってしまう。
何かのオーバフローなんだと思うけど、今は原因不明orz たぶんなおった。
学習の進行具合インジケータの*印の数を作るところでオーバーフローして
延々と*を表示し続けてるだけだったw
こういうところで適当にint使っているのがいかん。
と、怪しそうなところをsize_tに直したら、整合性が取れなくなってワーニングの嵐w
適当にsize_tにすればよいというものでもなかったw オーバーフローが嫌だからついlong longを使ってしまうw
メモリ余計に食うけど。 タイルゲーム、完全解析した後でもそれなりに楽しめる不思議。自力では勝てないからな。
そういやconnect4より複雑で完全解析されててネットで遊べるゲームってなにかあるのかな? データ取りなおしたので再度DNN学習させてみます。
ついでにネットワーク少し大きくしてみます。 なんかDNNほぼ最悪の手を打つんだが…
真逆の学習させちまったか? 試しに評価値に*-1してみたがやっぱり悪い手を打つ。
真逆ってわけでもないのか?
わけわからん うーん、なんかアルファ碁Leeみたいに、数手前の手順を学習データとして食わせるといいかもなぁ。
石がぶつかってる時の判断がちょっとおかしいんだよなぁ もうヒューリスティックもモリモリ入れちゃおうかなぁ 先制攻撃を仕掛ける体制が整っているかどうかの判定が今後の課題ですね。 先制攻撃を仕掛けた時に反撃で逆に取られる確率とか学習させたら駄目かなぁ? ある局面に対し、それぞれの点が黒の地になる確率のベクタを返すようにDNNを学習したらどうだろう? 前回はスコア差を評価値に学習させましたが、今回は勝率で学習させてみます。
結局セオリー通りがいいのかもしれないので。
ホントはスコア最大化はぜひともやりたいんだけど。 勝率で学習させたら黒番は勝ち越してますが、白番は負け越してますね。
白番でも勝てると思いましたが。 うお、バグ発見w
DNNが全く働いてなかったww
黒番で勝ち越したのはたまたまやなこれは。 うーん、石をくっつけて打つなぁ
もっとばらけさせたほうがいいと思うんだけど。 うーん、石がくっついているか離れているか標準偏差のようなものを出して学習パラメータに渡すとか ホントはあんま手動で特徴量出そうとするのよくないアイディアなんだろうけど。 結局モンテカルロの勝率データだけだとだめっぽくて、いろんな戦略の中からより良いものを探すようにしたいなぁ あれ、黒番、白番ともダブルスコアで勝ち越してる??
まだ対局数少ないからあれだけど。 自分は、最近、学習効率アップさせようと入れていたヒューリスティックなロジックは
見つけ次第外す方向だったりします。
棋譜作成の元ネタだけは、結構たくさん手動で追加していますが、見つけ次第追加
みたいなやり方で、偏りが出そうな気がするのと、手動追加だと入力ミスも結構あって
面倒なので、どこかで後続棋譜が少ない手順を順次自動で追加していくようにしちゃ
おうかなと思ったりしています。ただ、本当に見てるだけになっちゃうのがちょっと嫌。
そんな事より、棋譜作成のペースが速すぎて、逆順での読み切り(スコア確定)が
追い付かない。 黒番 188勝 48敗
白番 176勝 55敗
めっちゃ勝ってる!! 結局ポスグレ全く使ってないというw
ま、当面ポスグレは保留かなぁ とりあえず、この新しいAIで勝率データ取りなおして更に学習させるスパイラルへもっていくか。 小人閑居して不善をなす…
評価関数の学習周りをいじっていたら、学習エラーが大きく(4〜5倍)なってしまった。
オプティマイザーをAdamにしてみたのが悪かったのか(バグ?)、それとも他にいじった
ところが悪かったのか。オプティマイザーを戻して、追加学習してみたけど、全然もとに
戻らない。
と言いながら、色々と溜まっていた懸案も機能追加してしまった。
結局、どうにも直らないのでウェイトを一旦クリアしてRMSpropで再学習してる最中です。
明日の朝にはまともになっているかなぁ。 行列パッケージEigenにユーザ拡張のサポート無し機能がいくつか追加されていて、
その中にTensorクラスがある事に気づいた。
速度は期待できないけど、もう一度DCNNやってみようかなぁ。
つか、もう一台PCがあれば、棋譜が既にあるので、テストできるんだよなぁ。 RMSpropで一から学習しなおしで、もうすぐ20エポックだけど、順調な感じ。
前回同様20回+αも回せば結構よいところに行きそうな感じ。
おかしかった時は、もともとの場所から離れて、変な局所解にトラップされていた
ような感じになっていたんだよなぁ。現状のAdamのコードにバグがあるのか調べ
たいけど、もともと参考にしたサイトが見つからない。今見つかるやつはChainerの
類の疑似コードらしく、ちょっとやそっとでは解読できないレベルの記号の羅列orz モンテカルロ+ヒューリスティックAIにも勝利!!
いい感じだ。 あーもう、計算時間かかりすぎ!
あと3〜4日は計算回さないとデータが集まらない。
こんなときスレッドリッパー3990xがあれば… ぶっちゃけ1週間かかる計算が1日で終わるとしたら3990x買うのもありなんじゃないか…???
金がないけど。 まあまあ。
自分は棋譜作成開始して、既に数年経ってる気がする(汗
途中データ飛んだりしているから、実際はもっと長い。
だんだんコツがわかって収集速度は加速的に高速化してきているけど、
今度はメモリー溢れが恐怖。 Eigen UnsupportedのTensorクラスを見つけて、またぞろDCNNに興味が沸いて来ま
した。で、思い出しがてらウェブを眺めていました。前回断念したのは畳み込み層の
計算を行列で行うためのim2colのロジックを高速に行う方法が見つからなかったから
だと思い出しました(汗
しかし、気が付いてしまいました。所詮8×8のマスの定型変換で、汎用性いらないので
64ビットのローテーションとマスク値とのandというビット演算で、前処理ができてしまい
ます。そのあとで行列に変換すれば良いだけの事でした。つまりim2col関数はいらん。
もう少しDCNNの最新動向をフォローしてから、同じ棋譜を学習させて試してみたいと
思います。 DNN学習、損失もいい感じで減ってきました。
素のモンテカルロとの対戦に移ります。 実を言えば私は畳み込みはやってないんですな。
全結合でやってます。 お、
黒番 7勝2敗
白番 9勝0敗
これは期待が高まる!!! 黒番 22勝3敗
白番 20勝5敗
いいね〜いいね〜 そろそろソースコードのバージョン管理とかやったほうがいいのかなぁ
GitHubとか GitHubとかよーわからんのだけど、コメント適当だったり、変数や関数名の英語が
変だったりするソース公開する度胸ないのを言い訳に、調べようとしていない(汗 プライベートプロジェクトにすればいい。昔はパブリックだけプロジェクト数無制限だったけど今はプライベートも無制限。 情報ありがとうございます。
ちと調べてみます。
前みたいにソースもデータも丸ごと飛んだら困るので。 GitHubの前にGitを使おう
使えるようになってからでいいよ、GitHubは ありゃ、
黒番111勝 29敗
白番105勝 33敗
おもったほどじゃなかったorz 業を煮やしてヒューリスティックを実装した。
さてどうなるか。 ちなみにヒューリスティックの内容は石がぶつかってないときは相手の石からも自分の石からも一間以上離して打つというもの。 あーなんか気が抜けちゃったな
次のアイディアもないし しばらくは棋譜の遡りを優先しようと思っていたのですが、やっぱり暇ができると
どうしても何かやりたくなってしまい、結局序盤中盤の貪欲法絡みのブラッシュアップ
をしてしまい、またまた遡り対象の棋譜を増殖させています(汗。
DLやろうか、将棋AIの勉強しようかと思い立ち、将棋AIの本などを買い込んでつらつら
眺めていたら、実現確率探索なるものを見つけてしまいました。遷移確率は評価値の
Softmaxで作れる気がしています。現在、前方の打ち切りはProbCutでやっていますが、
途中の1つの盤面の評価値が酷い状態だと、その時点で問答無用でカット対象となって
しまう懸念があります。その点、実現確率探索の方が多少ロバストなのかなぁと。逆に、
手が広い局面では探索深さが浅くなってしまう悪影響も想定できます。
とはいえ、中盤探索のロジック自体は多少の改良で済むのですが、置換表使って中盤
探索の結果を終盤探索のオーダリングに使うところは結構修正が必要な気がします。
最悪反復深化をまるっとあきらめなきゃならないかも知れません。あと、なぜか評価値
に+1〜2程度の手番加算がついたみたいになっている事から、探索深さを揃えられ
ないと、そっちからも悪影響が出る可能性があります。
かなり大幅な変更と、テストが必要なので、ちょっと躊躇しています。
プロジェクト全体コピーして別プロジェクト建てるレベルです。むむむ。 DNN評価値の上位7手を初手から全展開するというのをやろうとしたのですが、意外とDNNの計算が重たいですね。
すぐにメモリ溢れるだろうとみていたのですが、牛歩のような計算の進み具合で、溢れるまでかなり時間かかりそうです。 DNN使わないと100万局面展開するのに4秒www
うーむ 結局、実現確率探索に取り掛かってしまいました(汗
新規ソリューション作ってコピペ始めたところで、いずれ評価関数を整数化したかった
事を思い出して、あちこち修正開始となりました。
一応、普通のDepthバージョンと同じ深さになるように調整して、速度比較してみるつもり。 DNNの評価値上位7手を全展開してポスグレに詰めるのを実行に移すべきかどうか迷ってる。
一応そのつもりで8TBのHDDもポスグレも用意したんだけど、あんまりいいアイディアに思えなくなってきたというか。 実現確率探索の中盤探索、プロトタイプのαβ版を作って癖を見ています。
実現確率は、評価値のSoftmaxで各要素を足して1.0になるように正規化するより、
最大値が1.0になるようにした方が使いやすいです。というのも、最大値をひたすら
追った枝の終了条件が綺麗に決まって最大深さを指定できるようになるからです。
1.0そのままだと終わらないので、例えば0.5にしておくと、深さnにしたい時は1÷2^n
が閾値になります。0.1の時は1÷10^nです。まあ、なんでもよいという事です。
後は各要素の差のつき具合を決める定数を調整すると、評価値が悪い手について、
どこまで探索の深さを確保するのかが決まります。ここが職人的作業なのがネック。
絞ると爆速。∞だと、ただの全幅探索になります。
速度は結構出てるのですが、調整ミスると全くダメみたいな様子が見え隠れしていて、
本当に常に使えるのか、まだ心配です。おそらくProbCutでも同じような問題がおきて
いるんじゃないかと思いますが。
次は置換表ですが、合流が発生した時の実現確率がルートによって違うので、その
時の置換表の評価値を使って良いのか悩みどころです。また、上述のように最大探索
深さを調整できるので、反復進化的に閾値を下げて行く事が可能性です。そうすると、
反復深化的に使いたくなるのが人情ですが、オーダリングにどのように反映するのが
良いのか。これも悩みどころだったりします。
要するにあと1週間くらいは遊べそうです(笑) あと、裏で棋譜作成進行中ですが、評価関数の学習時に、既存データに対する
エラーが増加を始めて、過学習の傾向を示しているのですが、例えばFFOの盤面
のように教師データ中に現れない盤面に対するエラーは減少しています。
状況的には、極端な石差がついている盤面の評価値が、石差ほどの評価値になって
おらず、じわじわと汎化が進んでいる一方、±0近傍の盤面は既に多いため、過学習
気味になっているのかなぁと推測しています。
とはいえ、非常に気持ち悪いです。
というわけで、ちょっと工夫をして石差が大きい棋譜を優先的に遡りチェック対象にしたり、
新規の自己対局するときに石差が大きくなる(悪い)進行も作るようにする事で、ほんの
少しですが、石差が大きい棋譜が増えるようにしてみました。まあ気休めです。 実現確率探索の中盤探索ができました。置換表と並列処理のところまでです。
反復深化→読み切り処理までです。置換表というか、オーダリング処理を結構修正。
反復深化まではそこそこ機能していますが、置換表経由で読み切り処理の高速化が
性能が出ません。置換表経由で、中盤探索の結果を用いて終盤探索のオーダリング
をするところで、置換表データの不足があったり、オーダリングの間違いが生じて、
無駄な探索をしているように思います。
とすると、これは読み切り処理を前提とすると結構致命的な問題な気がします。
もちろん、まだバグや仕様ミスの可能性もありますが。というわけで、Solver関係には
使えない可能性が出てきました。
また、評価関数で実現確率を導いているので、浅い段階での間違いに対して、探索
対象をロックしてしまいやすく、深く探索していっても間違いがなかなか改まらない
傾向が見受けられます。
まあ、仮にダメでも、新バージョンにする過程で、これまでペンディングしていた細かい
修正ができますし、既存タイプの中盤探索も作ってあるので、このまま進めてみます。 DNNの上位7手を幅優先に展開していき200万局面を上限にストップ
展開したものをminmaxで評価値を再計算。
その結果をDNNに学習させようとしています。
ポスグレの出番はいまのところないw 実現確率探索で、探索幅広げる方向の反復を試してみましたが効果はあまりなし。
単体で使用するとかなり早いのですが、置換表使った探索との相性がいまいち。
とりあえずSolverまで作って速度計測していますが、既存の反復深化より遅く、反復
深化無しよりは若干早いという感じで、単体の速度を利用して幅を思いっきり広げて
みましたが、こちらは逆に遅くなるという体たらく。
置換表周りでどこか間違いがあるのかなぁという気もしていますが、今のところ不明。
Solver周りでの活用は一旦置いといて、自己対局で使ってみる事にします。 えー駄目だ負けるorz orz orz
なんで駄目なの??? 今回のはかなり期待してたのにorz orz orz 棋譜見ると素のモンテカルロの動きが思っているよりずっといい。
なんでだろう? 実現確率探索というか、ソース全体見直し版が、だいたいできました。
まだデバッグ全部済んだわけではありませんが、後はログメッセージなんかの
細かいところくらいの修正かなと。
実現確率探索自体は、棋譜作成にフックを入れる感じでの使用にとどめていますが、
しばらく動かして、結果がよさそうなら切り替えようかなと思います。というか、対戦版
作るときには、中盤探索は実現確率探索で行くと思います。
で、実現確率探索と呼んでいますが、実際のところは違います。本来の実現確率は
「プロ棋譜など別途棋譜集から、よく出てくる手を回帰分析で確率化したもの」で、
よく出る手については深く探索しましょうという内容です。自分の奴は、確率を1手読み
の評価値から生成しています。1手読みにした理由は、差分計算で速く計算できる
からです。というわけで、本来は別の名前にした方が良いのですが、ネーミングセンス
が無いので放置です(笑)
他にも、本来と違う形で実装してるけど、放置してある名前が結構ありますorz 囲碁AIでKatagoという凄く強いAIがあるのですがライフゲーム囲碁に流用できないかと思い始めた。 見直し版のチェックを本番やりながら進めてます。
今のところ、学習の速度が30%程度ダウンしたものの、終盤探索の速度が
30〜50%高速化している感じ。どちらも原因不明。