PDCAな話

やる人は普通にやってて,出来ていない人は時代遅れだとか言ってるPDCAサイクルの基本的な話をメモしておきます。

 

Plan(計画)

 そもそものスタート地点です。何を目標にするのか誰が何をするのか。具体的にターゲットを決めてスケジュールを定めます。基本的にここが雑だと何の役にも立ちません。私の場合はよほどの自由度のない案件以外は長期目標・それに対し複数の短期目標を区分して置き,スケジュールもベスト・ワーストの二つくらいは用意します。

 もちろん先が見えないままのプロジェクトが多いため短期目標が複数未達の場合のオプションくらいまで事前に用意することも割とあります。

 

Do(実行)

 まぁほとんどの時間がここだと思いますが,基本的に淡々と取り組むことです。不安や迷いがあるのはPlanが甘いからでしょう。そもそも失敗するしないはここの担当責任ではありません。

 
Check(評価)

 チェック段階は定期的に行うのがいいですね。邪魔にならない範囲で短期で回すのが望ましいですが,その辺意思統一もプラン段階で決定しておくのが良いでしょう。

 

Act(改善)

 ここは概ね問題点の抽出と次の策を練るところです。チェックはざっくりですが,それを改善する案が出ないと次につながりません。頭が足りないなら他人の頭を借りましょう。これが出来てこそ次のプランです。

 

基本的に回るのが止まると駄目です。

実行過程が止まるのは論外ですが,PとAはアイデアが出ないと止まりやすいです。C過程が止まるのは所謂「逃げ」ですね。

イデア部分を外部に委託してでも回すことをやめないことですね。特にその過程のみ人数を増やしても良いくらいです。

 

そして重要な責任問題はプランの段階にあります。実行者は淡々と行えるようにプラン設計を行うのが味噌かと思っております。

  

次いでなので国政に例えてみましょう。

 

プランは国会です。予算委員会は年間予算を決めます。

予算委員会で評価や改善をやってる議員がいますが基本的に論外です。

様々な法整備は近未来を見越して先回りして行わなければなりません。「過去の話ばかりしている議員」がいればよほど無能か議論の停滞を狙っていると考えていいでしょう。

 

ドゥは行政ですね。

行政府に対してプランの話をするのは愚行です。法で決められたことを淡々と行うのが行政です。

もしこの過程で「仮定の話ばかり聞くマスメディア」がいるならこれも愚行か悪意と見て良いでしょう。担当部局が違います。

 

チェックも行政です。

多くのチェック項目に対して情報開示を行うのも行政の仕事です。加えてNPO的な外部団体もチェック機能として機能しています。透明性が要求される過程ですね。

 

アクトは選挙でしょうか。

行政に対して有権者が改善を要求する最も分かりやすい機会です。他にも有識者会議など大小様々な機会が準備されています。こちらも情報開示がされる場合が多いですが一般には理解されにくい難問が多いようです。

 

 

40ブロックの件

bleu48.hatenablog.com

 

先週の追記でもいいんですが長くなるので新ページ,ネタ的には連続しています。

昨今SlackやDiscordで多くのやり取りがあって,そこで回答することも増えているのですが個人的には恩恵を受けた経験からオープンな場で記録を残すべきと考えております。

 

前回は40ブロックの6000nps程度でfloodgateレーティング4000に達している件に触れました。

基本構造はCNN層が80層あって演算数量の大半になりますのでこれは囲碁などでも同じくらいのデータ数量かと思います。囲碁は19路ですので単純に4倍くらいでしょうか。

ファイルサイズは200MBくらいになります。

KPPT時代を経験していれば可愛いものでしょうか。

 

演算は結構大変でGTX1050Ti級で秒200回くらいです。10ブロックではこの4倍ほど出ますので他にボトルネックがないことは確認できます。

つい最近気づいたのですがAMDのRX580のOnnxruntime-DirectMLが結構改良されておりこちらが秒300回ほど計算できます。市場的にはGTX1060対抗とされていたのですが推論のみでは若干優位なのかもしれません。

(注:これらはモバイル用のGPUです)

 

低スペックマシンが遊んでいるので,それらをfloodgateに放り込んでみました。

200npsや300npsでまともな探索になっている感じはしないのですが,意外にも基準レートであるgikou2_1cには完勝のようです。この技巧2は以前調べたときにRyzenの1スレッドと言うことで700,000nps級です。しかも概ね中終盤で勝っている感じが見受けられます。

 

今まで探索ノード数が少ないと読み抜けて逆転を許すと言うのが通説でしたがどうも思っていた感じと違いますね。特に技巧は終盤力が優れているとの評判のソフトです。

この辺も深く調査してみると面白いかもしれないなと,構想が広がり始めているのが二番絞り効果でしょうか。

 

実は来週UEC杯の囲碁もあるんですがそっちは勝ち負けを争う気がないので(笑)

正直囲碁の方は強さ計測法すら確立していないので調整手段すら未定です。大きなバグは無いだろうくらいの準備加減で妥協してます。

二番絞り近況(2021年3月)

第45回のゲーム情報学研究会も無事終わりました。

第45回GI研究発表会-情報処理学会

 

また,反省なのですがやはり20分程度の口頭発表の内容じゃなかったですね。1つか2つのトピックに絞って丁寧に説明しないといけません。つい,盛り込んでしまうのが悪い癖。暇があればそれぞれのテーマを詳細に掘り下げたいです。

 

で,簡単に触れた近況です。

電竜戦では20ブロックの深層学習モデルを使っていましたが,その過程で使った強化学習用のデータを利用して5ブロックや15ブロック,40ブロックなどをテスト中です。

教師データがさくさく量産できればいいのですがそれには計算機が全然足りません。

 

5ブロックは1秒指しや2秒指しで結構強くなりました。10ブロックのdlshogiやGCT相手でもこの低ノードレンジでは優位に戦えます。

 

15ブロックは非常に良い成功例になりました。20ブロックの二番絞りに遜色ないというかむしろ強いかもしれません。floodgateにて2080Tiでレート4000超えですのでトップクラスでしょうかね。

 

今絞り中なのが40ブロックです。教師データ全部で2億強ありますが,40ブロックになるとこれを1エポック回すのに4日くらいかかります。

5エポック,6エポック目のものがfloodgateにてRTX3070でレート4000超えて意外にやるなって感じになってきています。RTX3070はRTX2080Tiと近い性能で,ざっくりRTX3090の半分くらいかと概算してます。

6000nps程度でこのレートは想定外です。10秒平均とすると6万ノードですからこれでdepth40近いやねうら王エンジンと戦えているのは結構驚きかと思います。

 

じゃあ,6万ノードくらいあればそこそこ戦えるのかとむしろ古いGPUを使ってfloodgateに色々放り込んでみました。お気づきの方もいるかもしれません。

 

低スペック軍はTensorCore勢に桁落ちの性能なので退役かと思っていたのですが計測にそこそこ使えると思いなおすような結果でした。特に上記の15ブロックやつが以下の結果です。

Player Statistics

 

GTX1060でレート3700ですと,GTX1080Tiで3800以上は期待できます。

これって私が初参加だった統一ハードの公対局である第5回の電王トーナメントなら優勝ラインですよね。まぁ開発速度の問題もありますがKPPの三駒評価関数相手なら追いついたと言えるでしょう。(まぁ,もちろんi7 6700にGTX1080Ti乗せたのが公平な統一ハードウェアかと言うと違うでしょうけど)

 

上記GI45でもコメントしていますが,AlphaZeroはKPPの三駒評価関数相手にしか勝っていません。AobaZeroでは比較にKristallweizenが入っていますが対elmoより苦戦されているように思います。

Leela Chess ZeroもNNUE搭載前のStockfishに勝ってますが,NNUE搭載後は逆転を許しています。

 

さぁ,今年のコンピュータ将棋選手権はどうなるんでしょうか。

40ブロックで教師データを生成して強化学習が出来ればいいのですが現有ハードウェアでは2か月程度でクリアできる課題ではなさそうです。

 

---

参考に分散学習はじめたKataGoのグラフ載せておきます。

対数グラフで右上の紫色のところが40ブロックです。

f:id:the48:20210309074850p:plain

KataGo Distributed Training

ONNXが強化されそう

昨年末の合同勉強会でお話ししましたが、FacebookMicrosoftなどが主導でニューラルネットワークの標準化が劇的に進みました。

gbdaitokai.connpass.com

 

ONNX

onnx.ai

 

ONNX自体はニューラルネットワークを表現するモデルの標準化ですから、計算グラフな訳です。

各ライブラリでは学習後にONNXモデルを出力できるようになっていますし、組み込み系などのインフラではONNXモデルをうまく計算できるようなライブラリが整備されています。例えばMicrosoftのonnxruntimeはハードウェアの差を吸収し高速実行可能になっており劇的な進化中です。

 

で、この度ONNXの最適化部分だけ独立することになったそうで、うまくいけば結構汎用性の高いものになりそうでワクワクです。

github.com

 

個人的な関心は熱流体とかですが、汎用の計算モデルの最適化問題に使えたりすると素晴らしいですよね。

囲碁の用語2(盤面編)

bleu48.hatenablog.com

 

雑記,続編です。追記でもいいくらいかもしれませんが(笑

 

第12回UEC杯のテストの機会がありました。

通信対局規約

結果はつながらなかったので残念でした。

こういったオンライン対戦はルーキーには厳しいですね。

 

通信プロトコルの辺りは結構面倒と言うかイライラします。

コンピュータ将棋界は将棋所がデファクトスタンダードになっていて加えてUSIプロトコルのドキュメントも整理されているために非常に助かりました。

将棋所:USIプロトコルとは

比べて歴史が長いはずのコンピュータ囲碁の方はGTPプロトコルもNNGSプロトコルも結局どのドキュメントを信じていいのか不明でサーバ実装や他のソフトの実装を参考に真似をする的な対応を取られているのが多いように聞きます。

(この辺で通信プロトコルとして相当イタいですよね。)

 

例えば座標ひとつ取ってもです。

将棋は右上原点で縦に一二三,横に123ですね。USIプロトコルだと縦にabc横に123です。

囲碁は左上原点で縦に一二三,横に123です。

GTPプロトコルでは左「下」原点で横にABCDEFGHJKLMNOPQRSTで縦に下から123です。

AからTまでは20個では?と思った人は正常です。よく見て下さいIがありません。

恐らく英語圏棋譜を筆記していた頃の名残ではないでしょうか。

 

ええ,何度もローカル対局で想定盤面がずれてるときがありましたよ。

次に囲碁棋譜の標準であるSGFファイル形式です。

SGFでは左上原点で横にABCDEFGHIJKLMNOPQRSで縦にもABCです。

ええ,今度はIが入りますのでSまでですし原点が左上です。縦には上からA~Sです。

ね,イライラするでしょ。

 

加えてUEC杯で推奨されている中継ソフトであるCgfGobanで盤面コピーをして保存するとGTPプロトコルと微妙に違って左上原点の盤面が保存されます。

そうですね。

ここで気づいたんですが将棋では盤面を表すSFENという表記方法があるのですが,囲碁はないもんですかね。

GTPプロトコルで規定されているshowboardコマンドでも各ソフトが思い思いのテキストアートを表示してくれます。

 

対戦相手と思ってる盤面が違うって辛いなって現状で,

今更ながら将棋所の作者の方に謝意を申し上げたくなる次第です。

---

全部自分でつくるきふわらべ君のスタンスがこの辺から生まれたのではないかと気づきました。

囲碁の用語

参考書として仕入れていたが精読してなかったので

再度目を通してみたが色々読み飛ばしてたことが結構見つかった。

囲碁ディープラーニングプログラミング

囲碁ディープラーニングプログラミング

 

 

そもそも用語が怪しい。

連:String

呼吸点:Liberty

コウ:Ko

ウッテガエシ:snap-back

アタリ:Atari

シチョウ:Ladder

 

読んで行くと13章でAlphaGoが呼吸点(当然連も)やアタリ,シチョウの情報を入力特徴量にしているとあった。

あれ?ルールベースなんじゃなかったっけ?何か誤解してた?

 

この程度のものがアリならチェス・将棋でも利きは当然入れるだろうなぁとか思った週末であった。

 

 

囲碁のルール(その2)

寝言言っててもはじまらないのでちょっとメモ。

  bleu48.hatenablog.com

 

良し悪しは知らないけど明文化したルールがないのでKataGoを参照する。

https://lightvector.github.io/KataGo/rules.html

中国ルール:

Ko:Simple

Scoring:Area

Tax:None

MultiStoneSuicide:Disallowed

Button:Not Used

日本ルール:

Ko:Simple

Scoring:Territory

Tax:Seki

MultiStoneSuicide:Disallowed

Button:Not Used

 

Scoringは良いとしてセキの問題は結構面倒かな。

KataGoも日本ルールの終盤用に色々苦心されているらしい。

 

囲碁GTPエンジン同志の対局をさせるのとか見つかりにくいのって

勝敗判定部分が定義しづらいからなんよね。

結局双方のエンジンの自己判定ベースになってるのとか第三者判定になってるのとか

 

まぁ,強化学習まで間に合うとは思えないが終局付近で変なことになるエンジンが多いって話は想像に難くない。主にそういったところを体験しに参加するんだけどねぇ。

誰かオープンソースで勝敗判定部だけでも実装しないかね?

 

とりあえずローカル対局用のスクリプトくらいは完成させて,ゴミのようなエンジン同志が終盤に茶番をみせるのを確認した。