GitHubじゃ!Pythonじゃ!

GitHubからPython関係の優良リポジトリを探したかったのじゃー、でも英語は出来ないから日本語で読むのじゃー、英語社会世知辛いのじゃー

tensorflow

minigo – AlphaGoZeroアルゴリズムのオープンソース実装

投稿日:

AlphaGoZeroアルゴリズムのオープンソース実装

Minigo:MuGoをベースにしたAlphaGo ZeroをモデルにしたミニマムGoエンジン

テストダッシュボード

これは、TensorFlowを使用した、ニューラルネットワークベースのGo AIの純粋なPython実装です。 DeepMindのAlphaGoアルゴリズムに触発されていますが、このプロジェクトはDeepMindプロジェクトでもなく、AlphaGo公式プロジェクトと提携していません。

これはAlphaGoの正式版ではありません

これはDeepMindの公式のAlphaGoプログラムではありません これはGoの愛好家がAlphaGo Zeroの論文(「人間の知識なしで動くゲームをマスターすること」、 Nature )の結果を複製するための独立した努力であり、いくつかのリソースが寛大にGoogleによって提供されています。

MinigoはBrian Leeの「MuGo」をベースにしています。これは、 Natureで公開された最初のAlphaGoペーパー「Deep Neural NetworksとTree Searchを使ったゲームのマスター」の純粋なPython実装です。 このインプリメンテーションは、最新のAlphaGo Zeroペーパー「人間の知識なしにゲームをマスターする」に示されている機能とアーキテクチャの変更を追加します。 最近では、このアーキテクチャはチェスと将棋のために拡張されました。 「一般的な強化学習アルゴリズムによるセルフプレイによるチェスと将棋のマスター」 これらの論文は、それぞれ、 AG (AlphaGo用)、 AGZ (AlphaGo Zero用)、およびAZ (AlphaZero用)としてそれぞれMinigoのドキュメントで要約されることがよくあります。

プロジェクトの目標

  1. Tensorflow、Kubernetes、Google Cloud Platformを使用して、さまざまなハードウェアアクセラレータ上で強化学習のパイプラインを確立する明確な学習例を提供します。

  2. オープンソースの実装とオープンソースのパイプラインツールを通じて、元のDeepMind AlphaGo論文の方法を可能な限り忠実に再現する。

  3. Go、機械学習、Kubernetesコミュニティに利益をもたらすために、私たちのデータ、結果、発見事項を公開してください。

このプロジェクトの明白な非目標は、競争の激しいGoプログラムを作り上げて、それが最高のGo AIとして確立することです。 代わりに、われわれの実装が可能な限り高速で効率的でない場合でも、コミュニティに利益をもたらす読める理解可能な実装に努めます。

この製品はこのような強力なモデルを生むかもしれませんが、そのプロセスに注力したいと考えています。 楽しみの半分が得られることを忘れないでください。 🙂

このプロジェクトが、興味を持った開発者が拡張性、適応性などのために利用できるPythonコードのわかりやすいプラットフォームで強力なGoモデルにアクセスできるようにするための、アクセス可能な方法であることを願っています

体験学習モデルについては、 RESULTS.mdを参照してください。

貢献するためのガイドラインについては、 CONTRIBUTING.mdを参照してください。

入門

このプロジェクトでは、次のことを前提としています:

Pythonへヒッチハイクのガイドには、Python開発とvirtualenvの使い方についての優れた紹介があります。 この後の手順は、virtualenvを使用していない環境ではテストされていません。

pip3 install virtualenv
pip3 install virtualenvwrapper

TensorFlowをインストールする

最初にセットアップして、あなたのvirtualenvを入力してから共有する必要があります:

pip3 install -r requirements.txt

次に、GPUまたはCPUのテンソルフロー要件をインストールすることを選択する必要があります。

環境の設定

リソースにクラウドプロジェクトを使用することができます。 そのように設定されている場合:

PROJECT=foo-project

次に、

source cluster/common.sh

他の環境変数のデフォルトを設定します。

ユニットテストの実行

BOARD_SIZE=9 python3 -m unittest discover tests

自動テスト

PRを自動的にテストするために、Minigoは密閉環境の変化をテストするためにKubernetesチームによって作成されたテストフレームワークであるProwを使用します。 私たちは単体テストの実行、コードの記述、テストMinigo Kubernetesクラスタの起動にprowを使います。

ProwとTestgridのUIを見れば、自動化されたテストの状態がわかります:

  • Testgrid(テスト結果ダッシュボード): https ://k8s-testgrid.appspot.com/sig-big-data
  • Prow(テストランナーダッシュボード): https ://prow.k8s.io/?repo=tensorflow%2Fminigo

基本

すべてのコマンドは、Google Cloud Storageとリモートファイルシステム、またはローカルファイルシステムと互換性があります。 ここの例ではGCSを使用していますが、ローカルファイルパスも同様に動作します。

GCSを使用するには、 BUCKET_NAME変数を設定し、 gcloud loginを使用して認証しgcloud login そうしないと、GCSからファイルを取得するすべてのコマンドがハングします。

たとえば、バケットを設定し、認証した後、最新のモデルを探します。

export BUCKET_NAME=your_bucket;
gcloud auth application-default login
gsutil ls gs://$BUCKET_NAME/models | tail -3

どのように見えますか:

gs://$BUCKET_NAME/models/000193-trusty.data-00000-of-00001
gs://$BUCKET_NAME/models/000193-trusty.index
gs://$BUCKET_NAME/models/000193-trusty.meta

これら3つのファイルはモデルを構成し、モデルを引数として取るコマンドは通常、モデルのベースネームへのパスを必要とします(例: gs://$BUCKET_NAME/models/000193-trusty

それらをローカルディスクにコピーする必要があります。 このフラグメントは、 MINIGO_MODELS指定されたディレクトリに最新のモデルをコピーします

MINIGO_MODELS=$HOME/minigo-models
mkdir -p $MINIGO_MODELS
gsutil ls gs://$BUCKET_NAME/models | tail -3 | xargs -I{} gsutil cp "{}" $MINIGO_MODELS

セルフプレイ

ミニゴがゲームをするのを見るには、モデルを指定する必要があります。 バケツで最新のモデルを使って遊ぶ例

python rl_loop.py selfplay --readouts=$READOUTS -v 2

READOUTSは1回の移動で何回の検索を行うかを示します。 タイミング情報と統計情報は、移動ごとに印刷されます。 冗長度(-v)を3以上に設定すると、移動ごとにボードが印刷されます。

ミニゴとの対戦

MinigoはGTPプロトコルを使用しており、gtp準拠のプログラムを使用することができます。

# Latest model should look like: /path/to/models/000123-something
LATEST_MODEL=$(ls -d $MINIGO_MODELS/* | tail -1 | cut -f 1 -d '.')
BOARD_SIZE=19 python3 main.py gtp -l $LATEST_MODEL -r $READOUTS -v 3

(モデルが提供されていない場合、モデルはランダムな値で初期化されます)

いくつかのローディング・メッセージの後、 GTP engine readyが表示され、その時点でコマンドを受け取ることができます。 GTPのチートシート:

genmove [color]             # Asks the engine to generate a move for a side
play [color] [coordinate]   # Tells the engine that a move should be played for `color` at `coordinate`
showboard                   # Asks the engine to print the board.

GTPを使用して遊ぶ方法の1つは、Gogui-display(GTPを使用するUIを実装しています)を使用することです.Goguiセットのツールはhttp://gogui.sourceforge.net/からダウンロードできます。 GTPを使用する興味深い方法に関するドキュメントも参照してください。

gogui-twogtp -black 'python3 main.py gtp -l gs://$BUCKET_NAME/models/000000-bootstrap' -white 'gogui-display' -size 19 -komi 7.5 -verbose -auto

GTPを使ってプレイするもう一つの方法は、ゲームを見ながらGnuGoとの対戦を見ることです

BLACK="gnugo --mode gtp"
WHITE="python3 main.py gtp -l path/to/model"
TWOGTP="gogui-twogtp -black \"$BLACK\" -white \"$WHITE\" -games 10 \
  -size 19 -alternate -sgffile gnugo"
gogui -size 19 -program "$TWOGTP" -computer-both -auto

トレーニングミニゴ

概要

次の一連のコマンドを使用すると、9×9で強化学習を1回繰り返すことができます。 これらは、上で参照したモデルとゲームを作成するために使用される基本コマンドです。

コマンドは次のとおりです。

  • bootstrap:ランダムなモデルを初期化する
  • セルフプレイ:最新のモデルでゲームをし、トレーニングに使用するデータを生成する
  • ギャザー:同じモデルでプレイしたゲームを、大きなサンプルのファイルにグループ化します。
  • train:最新のN世代のセルフプレイ結果を使って新しいモデルを訓練する。

ブートストラップ

このコマンドはランダムなモデルを作成します。 gs://$BUCKET_NAME/models/$MODEL_NAME(.index|.meta|.data-00000-of-00001)

export MODEL_NAME=000000-bootstrap
python3 main.py bootstrap --model-save-path="gs://$BUCKET_NAME/models/$MODEL_NAME"

セルフプレー

このコマンドはセルフプレイを開始し、その生のゲームデータをディレクトリ内のSGF形式と同様にテンソルフロー互換の形式で出力します

gs://$BUCKET_NAME/data/selfplay/$MODEL_NAME/local_worker/*.tfrecord.zz
gs://$BUCKET_NAME/sgf/$MODEL_NAME/local_worker/*.sgf
BOARD_SIZE=19 python3 main.py selfplay gs://$BUCKET_NAME/models/$MODEL_NAME \
  --readouts 10 \
  -v 3 \
  --output-dir=gs://$BUCKET_NAME/data/selfplay/$MODEL_NAME/local_worker \
  --output-sgf=gs://$BUCKET_NAME/sgf/$MODEL_NAME/local_worker

ギャザー

python3 main.py gather

このコマンドは複数のtfrecord.zzファイル(おそらくKBサイズになります)をとり、サイズを〜100 MBのtfrecord.zzファイルにシャッフルします。

1つのモデルによって生成されたゲームが一緒に維持されるように、モデル番号に従って収集が行われます。 デフォルトでは、 rl_loop.pyは環境変数BUCKET_NAMEで指定されたディレクトリを使用します。これはrl_loop.pyの一番上に設定されています。

gs://$BUCKET_NAME/data/training_chunks/$MODEL_NAME-{chunk_number}.tfrecord.zz

ファイルgs://$BUCKET_NAME/data/training_chunks/meta.txtは、これまでにどのゲームが処理されたかを記録するために使用されます。 (これ以上必要なことはありません)

python3 main.py gather \
  --input-directory=gs://$BUCKET_NAME/data/selfplay \
  --output-directory=gs://$BUCKET_NAME/data/training_chunks

トレーニング

このコマンドは、最新のモデルのウェイトから始めて、最新の50モデルのトレーニングチャンクを見つけ、新しいモデルを訓練します。

トレーニングジョブを実行します。

python3 main.py train gs://$BUCKET_NAME/data/training_chunks \
    gs://$BUCKET_NAME/models/000001-somename \
    --load-file=gs://$BUCKET_NAME/models/000000-bootstrap \
    --generation-num=1 \
    --logdir=path/to/tensorboard/logs \

更新されたモデルの重みは最後に保存されます。 (TODO:適切に再開するglobal_step基づいて、ある種のローカル・チェックポイントを実装します。)

さらに、TensorBoardでトレーニングの進捗状況を確認することもできます。それぞれの実行に異なる名前( logs/my_training_runlogs/my_training_run2 )を指定すると、それぞれの実行を重ね合わせることができます。

tensorboard --logdir=path/to/tensorboard/logs/

検証

モデルのオーバーフィットを追跡するための「検証セット」として使用するいくつかのゲームを脇に置くと便利です。 これを行う1つの方法は、 validateコマンドです。

保留データの検証

デフォルトで、Minigoは検証のために5%のセルフプレイゲームを保持し、 gs://$BUCKET_NAME/data/holdout/<model_name>書き込みます。 これは、 selfplayコマンドのholdout-pctフラグを調整することで変更できます。

この設定では、 python rl_loop.py validate --logdir=<logdir> --最新のモデルをpython rl_loop.py validate --logdir=<logdir> -- 、50個前のモデルから保留データを取得し、検証エラーを計算し、テンソルボードログを書きますlogdir

別のデータセットで検証する

これは、プロゲームのセットなど、ネットワークをテストするための既知の「良いデータ」セットを持っている場合に便利です。 適切なkomiとboardsizesを持つ.sgfsのセットがあると仮定すると、それらを.tfrecordファイルに前処理し、

import preprocessing
filenames = [generate a list of filenames here]
for f in filenames:
     try:
         preprocessing.make_dataset_from_sgf(f, f.replace(".sgf", ".tfrecord.zz"))
     except:
         print(f)

ディレクトリ内のすべてのファイルを収集したら、検証を行うのは次のように簡単です。

BOARD_SIZE=19 python main.py validate path/to/validation/files/ --load-file=/path/to/model
--logdir=path/to/tb/logs --num-steps=<number of positions to run validation on>

main.py validateコマンドは、定位置引数として指定されたディレクトリの下にあるすべての.tfrecord.zzファイルを対象にし、それらのファイルからnum_steps * TRAINING_BATCH_SIZE位置の検証エラーを計算します。

KubernetesクラスターでMinigoを走らせる

詳細はcluster / README.mdを参照してください。







-tensorflow

執筆者: