dlshogiの学習部のリファクタリングと各手法の精度比較

世界コンピュータ選手権も終わったので、feature/hcpe3やfeature/hcpe3_averageに分かれていたブランチをmasterに統合して整理した。

リファクタリング

重複局面の平均化や、評価値の補正をオプション(それぞれ--use_averate、--use_evalfix)で有効/無効化できるようにした。

また、hcpeとhcpe3の2つのフォーマットで学習スクリプトを分けていたが、train_hcpe3でどちらも読み込めるようにした。
重複局面の平均化などは、train_hcpe3のみに実装している。

また、train_hcpeのみにあったアクタークリティックとエントロピー正則化を、train_hcpe3でも使用できるようにした（--use_criticと--beta）。

各手法の精度比較

オプションで有効無効を切り替えられやすくなったので、今までちゃんと比較していなかったので、各手法の精度を比較した。

比較対象

条件	説明
hcpe	これまでのtrain_hcpeのデフォルト
hcpe3	train_hcpe3のオプションなし
hcpe3_critic	train_hcpe3の--use_critic --beta 0.001※hcpeと等価
hcpe3_evalfix	train_hcpe3の--use_evalfix
hcpe3_average	train_hcpe3の--use_average
hcpe3_average_evalfix	train_hcpe3の--use_average --use_evalfix
hcpe3_average_evalfix_critic	train_hcpe3の--use_average --use_evalfix --use_critic --beta 0.001

テストデータ

テストデータには、2017年～2018年6月のfloodgateのR3500以上の棋譜からサンプリングした856,923局面(重複なし)を使用した。
シャッフルにより結果が変わるため8回測定して平均を求めている。

精度は、方策、価値(勝率)のテスト損失で比較する。

学習データ

dlshogiの自己対局で生成した4千万局面(重複局面は0.14%)を、既存モデルに追加学習を行った結果を比較する。

比較結果

条件	policy	value
hcpe	1.835472639	0.529408829
hcpe3	1.81209377	0.534351326
hcpe3_critic	1.833132198	0.53397902
hcpe3_evalfix	1.812563669	0.525772249
hcpe3_average	1.816512931	0.534330776
hcpe3_average_evalfix	1.807865608	0.529676239
hcpe3_average_evalfix_critic	1.83458015	0.536404066

考察

hcpeとhcpe3_criticは等価だが、8回測定の平均でも結果には誤差が出ている。
policyとvalueがトレードオフの関係にあり、片方の損失が低くなった場合はもう片方が高く学習される場合がある。

critcの有り無しでは、有りの方がpolicy、valueともに損失が高くなる傾向がある。
アクタークリティックは、方策勾配法で用いられる手法であるため、MCTSの自己対局で生成した教師をオフポリシーで学習する場合には効果がないことが分かった。

averageの有り無しでは、policy、valueともに傾向が見えない。
使用した教師データには、重複がほとんどないデータを用いたためと考えられる。
重複の多い教師データを使用すると、averageなしではpolicyの損失がnanになり学習できない問題があるため、averageは有効にしておいて良いだろう。

evalfixの有り無しでは、valueの損失が小さくなる傾向がある。
前回実験した結果と同様の傾向である。

まとめ

今までブランチで学習手法を分けていたが、masterに統合しオプションで切り替えられようにした。
オプションでオンオフできるようになったので、あらためて各手法の比較を行った結果、MCTSの自己対局ではアクタークリティックは逆効果であることがわかった。
また、重複局面の平均化は重複局面が少ない場合はどちらでもよく、評価値の補正はvalueの損失を下げる効果があることがわかった。
重複が多い場合は、重複局面の平均化がないと学習できないため、常にオンにしておいてよい。
よって、おすすめ設定は、「--use_average --use_evalfix」となる。

あと、今回の結果を受けて、policyのテスト損失にクリティックを使用していたが削除した。
これまでよりも数値が高くでるようになっているので注意（上記の実験結果にも適用されている）。

GCTの学習に使用したデータセットを公開

dlshogi with GCTのWCSC31バージョンのモデルの学習に使用したデータセットを公開します。

https://drive.google.com/drive/u/3/folders/1Lkh4HL0tMx9p3NNbHue9lvh_HOSBGxhv

加納さんのご厚意により、Googleドライブの無料枠を大幅に上回る容量を提供してもらいました。
（いつまで提供できるかは保証できなため、データ取得はお早めに）

ファイルの説明

hcpe3/selfplay_gct-???.hcpe3.xz

• 中盤メインの5億の初期局面集で強化学習したデータ
• 040までは1600playout
• 041～055は1800playout
• 056～070は2000playout
• 071～は2400playout
• hcpe3フォーマット
• 方策の分布を学習したモデルで生成。GCTのモデルはこのデータの一部をhcpeに変換して学習。
• xzで圧縮しているため解凍が必要

hcpe3/selfplay_gct???_floodgate26*.hcpe3.xz

• floodgateの26手目までから作成した初期局面集で強化学習したデータ
• gct???の部分は、selfplay_gct-???のどこまでを学習したモデルで生成したかを表す
• GCTモデルの学習ではほとんど使用していなかった

hcpe3/selfplay_gct???_taya36.hcpe3.xz

• たややん互換局面を初期局面集として強化学習したデータ
• gct???の部分は、selfplay_gct-???のどこまでを学習したモデルで生成したかを表す
• hcpeに変換してGCTモデルの学習に使用した

hcpe3/selfplay_model-0000???_taya36.hcpe3.xz

• たややん互換局面を初期局面集として、GCTのモデルを使用して強化学習したデータ
• model-0000???の部分は、GCTのモデルのバージョン番号を表す
• hcpeに変換してGCTモデルの学習に使用した

aobazero/hcpe

• AobaZeroの棋譜をhcpeに変換したもの
• 電竜戦バージョンのGCTの学習以降もしばらく使用していたが、学習の後半では使用していない
• 序盤の学習に効果があるが、中終盤の質が今一つ

gct/hcpe/play-001

• floodgate/電竜戦/ローカル対局/ローカル対局（棋力計測）から生成したデータ
• _nomateが付くファイルは詰みの局面を除いたもの（除いた方が精度が上がる）

gct/hcpe/selfplay-unique-900xx/selfplay-unique-902xx

• たややん互角局面集での強化学習データ
• GCTの強化学習で生成したデータ
• 学習を安定させるために過去に生成したデータも常に学習に加えていた（効果は未検証）

gct/hcpe/selfplay-unique-901xx/selfplay-unique-903xx

• やねうら互角局面集での強化学習データ
• GCTの強化学習で生成したデータ
• 学習を安定させるために過去に生成したデータも常に学習に加えていた（効果は未検証）

suisho/hcpe

• 水匠の相入玉局面教師（たややんさんには、discord で公開の許可をもらっています。）

大会で使用したモデルについて

hcpe3の方は山岡が作成して、hcpeの方は加納さんの方で生成して、GCTのモデルは加納さんが主に学習を進めて、最後に山岡が生成したファイルも混ぜてお互いで学習して強くなったモデルを採用しています。

公開の目的とか

このデータを生成するために、マシンパワーと労力を費やしています。
ディープラーニングを使ったコンピュータ将棋を始めてみたくても、同じだけのデータを用意するのはかなりハードルが高いと思います。
学習やモデルアーキテクチャにまだまだ工夫の余地があるため、そちらで競い合ってフィードバックしあえる環境を作りたいという思いでデータを公開します。

データ生成にはマシンパワーが必要ですが、学習環境には、TensorCoreのあるGPU1枚か、Google Colab（できればColab Pro）があれば十分です。

新たな人がコンピュータ将棋の開発に参加して、いっしょに盛り上げていってくれることを期待します。

将棋AI実験ノート：自己対局の評価値の補正

Discordで、評価値と勝率を変換する際の以下のシグモイド関数の係数aは、dlshogiはelmo_for_learnの自己対局から求めた756.0864962951762という値を使用しているが、floodgateの棋譜などを学習する場合はもっと低い値になるので補正すべきというやり取りがあった。

floodgateの棋譜から調査

R3800以上の棋譜

実際にどれくらいの値なのか2019年～2020年のR3800以上のfloodgateの棋譜から調べてみたところ、
a = 236.94908509
という結果であった。

R2000以上の棋譜

R2000以上とすると、
a = 398.66185164
という結果であった。

調査に使用したスクリプト：csa_score_value_fit.py · GitHub

Discordでのやり取りの通り、係数aは小さい値になった。
また、レーティングが高いほど、係数aが小さくなる傾向がありそうである。

自己対局の評価値と勝率の関係

dlshogiの自己対局で生成した教師データに対しても、評価値と勝率の係数を調べてみた。
自己対局では評価値はルートノードの訪問回数が最も多い子ノードの平均価値(勝率)を、評価値に変換して記録している。
その際の係数には、a=756.0864962951762を使用しているため、その値に近い値になると考えていた。

しかし、実際に調べてみると、
a = 488.09106542
という結果であった。

調査に使用したスクリプト：hcpe_score_value_fit.py · GitHub

これは、自己対局時の探索で求めた勝率と、実際の対局結果を統計処理した勝率にずれがあることを示している。
係数が小さい方にずれているということは、実際の勝率が探索で求めた勝率よりも高いことを示している。
なぜ係数が小さい方にずれるのかは分からないが、探索で求めた評価値をそのまま学習に使うよりも、実際の勝敗から求めた係数で補正した方がよい可能性がある。

評価値を補正して学習

評価値を勝敗から求めた係数で補正したデータを使用し、dlshogiのモデルを学習して、補正なしの場合とありの場合で、精度を比較した。
テストデータには、2017年～2018年6月のfloodgateのR3500以上の棋譜からサンプリングした856,923局面(重複なし)を使用した。
初期値とデータのシャッフルにより結果が変わるため4回測定して平均を求めている。

精度は、方策、価値(勝率)、Q値(評価値)のテスト損失で比較する。
（正解率は、テストデータのクラスの分布が不均衡だと比較しにくいため、精度の比較には損失の方がよい）

変換に使用したスクリプト：fix_hcpe_eval.py · GitHub

floodgateの棋譜

2019年～2020年のR3800以上のfloodgateの棋譜(6235207局面)の評価値を補正して、初期値から学習した結果は以下の通り。

	方策	価値(勝率)	Q値(評価値)
補正なし	1.70100901	0.656220725	0.688526105
補正あり	1.713669813	0.65317638	0.691249333

補正ありの場合が、価値の損失が小さくなっている。
（その変わり、方策の損失が大きくなっているが、これは、初期値から学習した段階では、方策と価値がトレードオフの関係で学習されるためと考えられる。）

補正を行うことで、価値の精度が上がることを示している。

Q値(評価値)が、補正を行った方が高くなっているのは、テストデータの評価値は補正を行っていないためと考えられる。
テストデータに評価値を補正したデータを使用すると、

	方策	価値(勝率)	Q値(評価値)
補正なし	1.648518813	0.65597565	0.659327383
補正あり	1.659034425	0.65457407	0.65837852

補正ありの方が、Q値(評価値)の損失も小さくなった。

自己対局の棋譜

自己対局で生成した教師データ(4千万局面)の評価値を補正して、学習済みモデルに追加学習を行った結果は以下の通り。

	方策	価値(勝率)	Q値(評価値)
補正なし	0.816202783	0.49896154	0.644653933
補正あり	0.812867498	0.493460893	0.658458863

補正ありの場合が、価値の損失が小さくなっている。
また、方策の損失も小さくなっている。
Q値(評価値)の損失は大きくなっているが、テストデータの評価値の補正を行っていないためである。

テストデータに評価値を補正したデータを使用すると以下の通りになった。

	方策	価値(勝率)	Q値(評価値)
補正なし	0.80054098	0.498679225	0.512195093
補正あり	0.79759852	0.493009955	0.508437538

Q値(評価値)の損失についても小さくなっている。

まとめ

floodgateの評価値と勝率の変換に使用するシグモイド関数の係数は、コンピュータ将棋界隈で知られている600よりも小さい値であることがわかった。
また、自己対局時の探索で求めたPVの平均価値(勝率)と、実際の対局結果の統計から求めた勝率にはずれがあることが確認できた。

どちらのデータも学習に使用する場合、評価値を実際の対局結果から求めた係数で補正することで、価値の精度が向上することが確かめられた。

dlshogiの学習スクリプトにも評価値を自動で補正するオプションを処理を追加する予定である。

dlshogi with GCT（WCSC31バージョン）のWindows版ビルド済みファイル公開

dlshogi with GCT（WCSC31バージョン）のWindows版ビルド済みファイルを公開します。

ダウンロード

Release 第31回世界コンピュータ将棋選手権バージョン · TadaoYamaoka/DeepLearningShogi · GitHub

NVIDIA GPUに対応したTensorRT版と、NVIDIA GPU非搭載のWindows PCでも動作するOnnxRuntime版を含みます。

OnnxRuntime版について

Windows 10 version 1903以降のPCであれば実行可能です。
ただし、探索速度は、TensorRT版にくらべて落ちます。
最高のパフォーマンスを出すには、TensorRT版をTensorCore搭載のNVIDIAのGPU(NVIDIA GeForce 2080Tiなど)で動かすことを推奨します。

同梱しているモデルファイル

model-0000225kai.onnx	比較的オールラウンダー（デフォルト）
model-0000226kai.onnx	たややん互換局面特化

※大会では予行2日目最終戦以外は、model-0000226kai.onnxを使用

検討での使用

ShogiGUIの検討機能で使うには、一部対応できていない機能があります。
「深さ」の指定はできません。
時間無制限でも、UCT_NodeLimitで設定したノード数に達すると探索を終了します。

検討では、設定でDNN_Batch_Sizeを256など大きめにした方がNPSが上がります。

第31回世界コンピュータ将棋選手権 結果報告

「dlshogi with GCT」として、第31回世界コンピュータ将棋選手権に参加しました。
本日は予選2日目で、dlshogiはシードのため2日目からの参加でした。
上位8チームが決勝進出になります。

結果は、30チーム中14位と決勝進出ならず残念な結果でした。

昨年の電竜戦で、dlshogiを使用したGCTが優勝したため、ディープラーニング勢の躍進が期待されていましたが、
決勝進出は、NNUE系が7チームという結果になりました。

唯一PALがディープラーニングで、決勝に進出しています。
（決勝に進出したRyfamateはdlshogiとやねうら王(NNUE)の合議のようです。）

dlshogiが振るわなかった理由について

電竜戦やfloodgateに比べると持ち時間が長いことが関係している

dlshogi(GCT)は、floodgate（10分10秒加算）では大会で使用したGPUより世代が古いV100×8（gct_model-0000225kai_v100x8）で、レーティング4430と水匠4（Suisho4_TR3990X）とほぼ互角になっています。
ローカルの持ち時間3分1秒加算の対局（たややん互換局面使用）でも、3GPUのdlshogiが40スレッドの水匠3改に対して、60%くらいの勝率になっていました。
GCTが優勝した電竜戦は、10分2秒加算でした。

今回の世界コンピュータ将棋選手権は、15分5秒加算のルールで、長い持ち時間になっています。

dlshogiは、Resnet10ブロック192フィルタという軽めのモデル（AlphaZeroは20ブロック256フィルタ）を使用して、指し手のみを学習しているため、長い持ち時間を活かしきれない条件だったと推測しています。

探索ノード数の上限をfloatの桁落ちの制約で3千万局面に設定しているため、上限に達することが多くありました。

また、指し手のみを学習している（AlphaZeroは方策の分布を学習する）ため、探索中の各局面で調べる手がかなり絞られており、探索の深さが60以上(多いときは90以上)になっていました。
持ち時間が長い分を、深さより幅方向に時間を使えた方が読み漏れが防げた可能性があります。

そのため、より大きなモデルの方が有効だったか、温度パラメータを調整する余地があったかもしれません。

戦型に弱点がある

振り飛車が得意なHoneyWaffleに負けたことから、相手が上手い振り飛車だと弱点がありそうです。
強化学習の初期局面には、中盤中心の5億と、たややん互換局面集を多く学習して、たややん互換局面集で勝率測定をしていたため、たややん互換以外の戦型に弱点があったかもしれません。

入玉宣言を最短で目指さい

最後のNovice戦では、ほぼ勝ちで入玉宣言を目指せる局面から、無駄な駒得で手数が伸びて引き分けになってしまいました。
入玉宣言できる局面で、狙いに行くにはどうするかは課題があります。

まとめ

最後の2週間は、かなり強化学習をがんばったのですが、結果が及ばす残念でした。
ディープラーニングはまだ伸びしろがあると考えているので、次の大会では結果が残せるように開発は続けたいと思っています。

決勝に行けなかったので需要があるかはわかりませんが、dlshogiのビルド済みバイナリとGCTのモデルは後日公開する予定です。
強化学習で生成したデータも公開を検討していますが、Googleドライブの無料枠に収まらない(圧縮しても50GBくらい必要)のでディスクをどうしようかと思っています。

将棋AIの実験ノート：重複局面の平均を学習

dlshogiの自己対局で生成したデータを学習すると、方策損失がNaNになるというissueをもらった。
自己対局棋譜を用いるとPolicyのlossがNaNになる · Issue #44 · TadaoYamaoka/DeepLearningShogi · GitHub

原因

実際にデータをもらって、調査したところ、強化学習で生成したデータに重複局面が多いとうまく学習できない(方策損失がNaNになる)ということがわかった。

私が行っているdlshogiの強化学習では、約5億局面の初期局面集を使用しているため、重複がほぼないため問題が起きていなかった。
しかし、floodgateの棋譜から作成した26手まで初期局面集を使用して生成したデータの場合、デフォルト設定(--random 4)では33%が重複局面になっていた。
重複を削除して、データをユニークにするとうまく学習できるようになった。

局面の偏りについての考察

機械学習の一般論として、データの偏りが大きすぎる場合は、汎化性能を上げるためにアンダーサンプリングなどの手法がとられる。
同様に、局面の偏りが大きすぎると学習に悪影響があると考えられる。

ただし、将棋の学習では、序盤の頻度が高い局面は、それに応じてサンプル数が多い方が良い可能性はある。
しかし、自己対局で生成した局面は、対局時の出現頻度と生成された局面の頻度が一致する理想的な状態にはならない。

AlphaZero方式の強化学習では、30手までは、ルートの子ノードの訪問数に応じたボルツマン分布で手を選択し、30手目以降はグリーディーに選択する。
30手までの出現頻度が実際の対局時の頻度に近くなる保証はなく、また、30手目までが同一の場合、それ以降の手順も重複する可能性が高い（30手目以降もディリクレ分布によるノイズが加えられるが、同じになる確率の方が高い）。

dlshogiの場合は、初期局面集を使用してデフォルト4手だけルートの子ノードの訪問数に応じたボルツマン分布で手を選択しているため、初期局面集が少ないとAlphaZero方式よりも重複しやすい。

偏りをなくす方法

自己対局の初期局面集を増やす

dlshogiの強化学習のように、5億局面くらい初期局面集を用意すれば、ほぼ重複が起きない。

ランダムを増やす

オプションを変更して、ボルツマン分布で手を選択する手数を増やすことで、偏りを減らすことができる（例：--random 8）。
しかし、それ以降グリーディーで選択する手で重複が起きる問題は解消されない。

ユニークにする

単純に偏りをなくすには、ユニークにすればよい。
hcpeフォーマットの場合、

hcpes = np.fromfile(file1, dtype=HuffmanCodedPosAndEval)
np.unique(hcpes, axis=0).tofile(file2)

のようにすれば、ユニークにできる。

しかし、単純にユニークにすると、局面が同一で、勝敗が異なる場合の勝敗の分布を無視してしまう。

アンダーサンプリングする

局面の出現頻度に応じてサンプリングされる確率を下げることで、偏りをなくすことができる。
しかし、アンダーサンプリングすると全データが使用されなくなる。

重複局面を平均化する

重複局面の方策の分布と勝敗および評価値を平均化して、1サンプルとして学習する。
実装が容易で、偏りをなくして、勝敗の分布が学習に反映されるようになる。

重複局面を平均化する方法の実験

ここでは、実装が容易な重複局面を平均化する方法を試してみた。

floodgateの26手目までから作成した初期局面集を使用して、--random 8で、500万局面を生成した。
8.4%が重複局面であった。

初期値から学習した場合と、学習済みモデルに追加学習した場合の2パターンで、テスト精度を比較した。
テストデータには2017年～2018年6月のfloodgateのR3500以上の棋譜からサンプリングした856,923局面(重複なし)を使用した。
初期値やデータのシャッフルによって、結果がぶれるため10回測定の平均で比較した。

初期値から学習した場合

• テスト損失

平均化	方策損失	価値損失	Q値損失
なし	1.042137719	0.621680436	0.680630963
あり	1.048347286	0.616545519	0.680523165

• テスト一致率

平均化	方策一致率	価値一致率
なし	0.364850523	0.639321282
あり	0.362664658	0.644984585

• テストエントロピー

平均化	方策エントロピー	価値エントロピー
なし	2.281808841	0.606063402
あり	2.294291323	0.605066263

学習済みモデルに追加学習した場合

• テスト損失

平均化	方策損失	価値損失	Q値損失
なし	0.761351238	0.511269072	0.645805857
あり	0.760675438	0.510021321	0.646256217

• テスト一致率

平均化	方策一致率	価値一致率
なし	0.478925051	0.730855406
あり	0.479427199	0.732262122

• テストエントロピー

平均化	方策エントロピー	価値エントロピー
なし	1.593853935	0.555852106
あり	1.603584761	0.556084998

考察

初期値から学習した場合は、方策は平均化なしが良く、価値は平均化ありが良いという結果になった。
方策が下がったのは平均化によりサンプル数が減ったことが起因している可能性がある。
学習済みモデルに追加学習した場合は、方策、価値どちらも、平均化した方が良い結果になった。

まとめ

自己対局で生成した局面に重複局面が多いとうまく学習できない事象の対策として、重複局面を平均化する方法を試した。
実験の結果、学習済みモデルに追加学習する場合は、重複局面を平均化した方が、良さそうという結果が得られた。

序盤の出現頻度が高い局面のサンプル数を増やした方がよいという考えもあるが、自己対局で生成した局面が理想的な出現頻度になっているかは考慮が必要だと考える。

ソース

feature/hcpe3_averageブランチに平均化する処理を実装したソースをプッシュした。
GitHub - TadaoYamaoka/DeepLearningShogi at feature/hcpe3_average
※平均化に対応したのは、方策の分布を学習する場合(train_hcpe3.py)のみである。

cshogiにリーグ戦モードを追加

プログラムの修正やモデルを学習した後の強さの計測に変更前後の自己対戦のみだと、系統が違うソフトに対して強くなっていないことがあるため、基準となるソフトを加えたリーグ戦で確認を行っている。

連続対局には、cshogiを使用して、PGNファイルを出力して、Ordoでeloレーティングを計算している。
今までcshogiは2つのソフトの連続対局しか対応していなかったため、マシンやプロセスを分けて実行していた。
スペックが同じでもマシンや使用するGPUが変わると、誤差の原因になるため、3つのソフトを指定してリーグ戦で対局できるようにした。
リーグ戦を並列で実行すれば、同じハードを均等に使うので、誤差が出にくい。
また、各ソフトの対局数が同じになるので、途中経過を確認しやすい。

cshogiの使い方についてあまりドキュメントを書いていないので、使い方を書いておく。

cshogiのインストール

pip install cshogi

アップデートの場合は、

pip install cshogi -U

連続対局の実行方法

コマンド例

python -u -m cshogi.cli /work/DeepLearningShogi/usi/bin/usi /work/DeepLearningShogi/usi/bin/usi /work/YaneuraOu/bin/YaneuraOu-by-gcc --name1 model1 --name2 model2 --options1 Draw_Ply:320,OwnBook:false,PV_Interval:0,DNN_Model:/work/model/model1.onnx,UCT_Threads:2 --options2 Draw_Ply:320,OwnBook:false,PV_Interval:0,DNN_Model:/work/model/model2.onnx,UCT_Threads:2 --options3 USI_Hash:2048,Threads:2,PvInterval:9999,NetworkDelay:0,NetworkDelay2:0,ResignValue:10000,MaxMovesToDraw:320 --opening /work/taya36.sfen --draw 320 --time 180000 --inc 1000 1000 1500 --games 128 --pgn model1_vs_model2_time180inc1-01.pgn > log_model1_vs_model2_time180inc1-01.txt &

エンジンは、位置引数に2つもしくは3つ指定できる。
2つの場合は1対1で先後入れ替えて連続対局を行い、3つの場合はリーグ戦になる。
リーグ戦は、先後入れ替えて1局ずつを3ソフト全組み合わせに対し行うことを繰り返す。

同一ソフトで、パラメータのみ変える場合は名前が被るため「--name1 」などで名前を上書きする。「1」の部分が引数の1番目のエンジンであることを示している。
USIオプションは、「--options1」などで指定する。

「--opening」で開始局面集を指定する。
デフォルトでランダムでサンプリングするが、「--opening-seed 0」のようにシードを固定できる。
「--opening-moves」で開始局面集の何手目から開始するか指定できる。

「--draw」で引き分けとする手数を指定できる。

「--time」と「--inc」で、持ち時間と1手加算時間をミリ秒単位で指定する。
エンジンごとに値を分ける場合は、エンジンの数だけ複数指定する。

秒読みの場合は「--byoyomi」で秒読み時間をミリ秒単位で指定する。
こちらも複数指定することでエンジンごとに値を分けることができる。

「--resign」で投了の閾値を設定できる。例）--resign 3000
「--mate_win」を指定すると、手番側の詰みを見つけた時点で終了する（手番側の詰みの探索を信用する）。

「--games」で対局数を指定する。

「--pgn」でPNGの出力パスを指定する。

「--csa」を指定すると、指定したフォルダにCSAファイルを出力する。
「--multi_csa」を指定すると複数対局を1ファイルに出力する。

「--keep_process」を指定すると、1局ごとにエンジンのプロセスを終了しない（リーグ戦の場合は、先後入れ替えのタイミングのみ）。

「--debug」を指定すると、USIコマンドとその応答をすべて標準出力に出力する。

対局の結果は、標準出力に出力される。
ファイルに出力したい場合は、リダイレクトする。
リダイレクトすると、バッファリングされるため、pythonのオプションに「-u」を付けると良い。

eloレーティングの計算

PGNファイルをOrdoに渡すことでeloレーティングが計算できる。

Ordoの実行例

ordo-win64.exe -Q -D -a 0 -W -n8 -s1000 -U "0,1,2,3,4,5,6,7,8,9,10" -p model1_vs_model2_time180inc1-01.pgn

複数プロセスで並列実行した場合は、複数PGNファイルを入力できる。

ordo-win64.exe -Q -D -a 0 -W -n8 -s1000 -U "0,1,2,3,4,5,6,7,8,9,10" -p model1_vs_model2_time180inc1-01.pgn -- model1_vs_model2_time180inc1-02.pgn model1_vs_model2_time180inc1-03.pgn

以下のように表示される。

0   10   20   30   40   50   60   70   80   90   100 (%)
|----|----|----|----|----|----|----|----|----|----|
***************************************************

   # PLAYER                        :  RATING  ERROR  POINTS  PLAYED   (%)  CFS(%)    W    D    L  D(%)
   1 model_gct_010_opt             :    31.3   31.7   116.0     205    57      77  110   12   83     6
   2 model-0000195                 :    10.5   32.0   107.0     205    52      97  100   14   91     7
   3 YaneuraOu NNUE 6.00 64AVX2    :   -41.8   31.3    84.0     204    41     ---   80    8  116     4

White advantage = 11.75 +/- 19.12
Draw rate (equal opponents) = 5.61 % +/- 1.32

レーティングの誤差と、どれくらいの確かさで強いかを表すCFS(%)も表示されるため、有意差があるか確認できる。