モンテカルロ木探索 並列化、囲碁、マリオ · –hpc業界 (?) の取り組み...
TRANSCRIPT
モンテカルロ木探索
並列化、囲碁、マリオAI
美添 一樹 ETATO研究員 湊離散構造処理系プロジェクト
2013年度秋のワークショップ 2013年11月26日
並列モンテカルロ木探索の意義
• コンピュータ囲碁で人間を超える
–情報科学の有効性を示す
• 大規模並列探索ライブラリ
–近い将来、全てのアルゴリズムは大規模並列化が必要
–並列探索は実装が「非常に」大変なのでライブラリとして提供できると良い
AIの進歩：チェス、将棋、囲碁
IBM Deep Blue
FPGAで将棋プログラムを作ってみるブログ
http://blog.livedoor.jp/yss_fpga/archives/53897129.html
将棋プログラム
MCTSの発明
並列化で
進歩を
加速する IBM DeepBlue Kasparov
1997 第2回 電王戦 GPS将棋 2013
1万コア以上を用いる
並列探索アルゴリズムで
囲碁名人に勝つ
科研費 代表者 美添
注: これが課題名
従来の探索アルゴリズム
評価関数を使う
モンテカルロ木探索
(MCTS)
ランダムシミュレーションを使う
プレイアウトと呼ぶ
評価関数1回、約 1μ秒
プレイアウト1回、約 1ミリ秒
UCT algorithm [Kocsis & Szepesvari 2006]
Upper Confidence bound applied to Trees
Upper Confidence Bound によって
確率分布を比較する
[Auer, Cesa-Bianchi and fischer 2002]
s
t
s
w ln2
Multi-Armed Bandit Problem
mean + bias 節点の比較にUCBを用いる探索アルゴリズムがUCT
UCT は幅広く応用されている
正確にはこれはUCB1
MCTS の応用
two player
multi player
single player
(real time)
[H. Nakhost and M. Müller 2009]
“Monte-Carlo Exploration for
Deterministic Planning”, IJCAI’09
Planning
[Tanabe, Yoshizoe and Imai 2009] “A study on security evaluation methodology for
image-based biometrics authentication systems”,
biometric security
[Browne et al. 2012]
“A Survey of Monte Carlo Tree
Search Methods “
[Gelly et al. 2012]
The Grand Challenge of Computer Go:
Monte Carlo Tree Search and Extensions
サーベイ論文
CACM
並列化の難しさ
• 探索には枝刈りが必須
–囲碁や将棋などでは実質的には9割以上の手が枝刈りされる
• 均等な負荷分散が困難
–単純な方法は駄目
注意：うまく負荷が予測できれば、これでもかなりうまく行く。（参考：GPS将棋）
探索木を分割して
各計算機が担当
並列化手法
011001 11 01001011
ノード番号= 3
0 1 2 3
101100 01 10001110
ノード番号= 1
分散ハッシュテーブル
による並列探索
depth-first
reformulation (深さ優先変形)
グラフの各節点を、異なる計算ノードに割り当てる
アルゴリズムの深さ優先変形によって通信の集中を回避する
r
f g
c d e
a b
3
2
1
011001 11 01001011
ハッシュキー
ノード番号= 3
101100 10 11010001
101100 01 10001110
ノード番号= 2
ノード番号= 1
ノード0 ハッシュ表
ハッシュ表に基づく並列探索 (TDS) Transposition table Driven Scheduling
ノード1 ハッシュ表
ノード2 ハッシュ表
ノード3 ハッシュ表
他のノードに探索を依頼
• 各節点はハッシュ値を持つ
• ハッシュ値の一部を計算ノードの番号とみなす
• 均等な負荷分散と引き替えに、細かい通信が増える
[Romein et al. 1999]
TDS UCT 動作全体像
どの節点をどの計算ノードが担当
するかはハッシュ関数に依存する
補足：根節点を担当する計算ノードもさらに深い節点を担当している
注意：節点も計算機もどちらも
「ノード」なので非常にややこしい
1
6
3 2
4
5
1 ジョブおよびジョブ番号
当然、ジョブの総数は計算ノードより多くないといけない
データは計算ノードに固定されている。「ジョブ」が移動する。
1
2
3
4
6
5
実験では計算ノード数 x 3～10 個のジョブを使用した
depth-first reformulation による
通信の集中の解消
11
r
f g
c d e
a b
r
f g
c d e
a b
Normal UCT Depth First UCT 不必要に root まで返っている
不必要なリターンを削除
[吉本, 岸本, 金子, 美添 2007]
局所性を高めるのは並列化の基本
virtual loss によるジョブの分散
d は節点を探索中のプロセス数
D は兄弟節点の d の合計
r
f g
c d e
a b
何もしないと全てのプロセスが同じ所を探索する
並列化 と Virtual Loss
そこで、探索中の節点には Virtual
Loss というペナルティーを加える
[Coulom 2007?]
s
t
s
w ln2
ds
Dt
ds
w
)ln(2
TDS-df-UCT: 仮想ゲームの性能
• P-Game を用いた
– 一般的な仮想ゲーム
• 大幅な速度向上を達成 – プレイアウト速度で大きな差がある
– （Infiniband の能力による貢献も大きい）
TDS + depth first UCT = TDS-df-UCT
-
500
1,000
1,500
2,000
2,500
3,000
0 800 1600 2400 3200 4000 4800
Number of Cores
Speedup
19路囲碁に近い
1.0 ms playout 分岐150
9路囲碁に近い
0.1 ms playout 分岐40
ハードウェア: TSUBAME2 supercomputer
各計算ノード: Xeon 2.93GHz x 2 (12 cores)
ネットワーク: Infiniband QDR x 2
MPIライブラリ: MVAPICH2 library を使用
y=x
並列囲碁プログラム
• 仮想ゲームより遅い – 通信遅延の増大
• 囲碁のデータ構造が大きいため
– プレイアウトが速いため • 本実験では序盤で約0.4ms
• 終盤ではより速くなる
– 並列化に伴うオーバーヘッド • 単一コアで並列版を動かすと、
0.6-0.7倍の速度
• 囲碁の性能を仮想ゲームに近づけることが目標 – プレイアウトを複数まとめる
– データ構造の圧縮 (まだ途中)
– その他のパラメータを調整中
SGI UV1000 TSUBAME2
-
50
100
150
200
250
300
350
400
0 200 400 600 800 1000 1200
囲碁プログラムの速度向上
SGI UV1000
Tsubame2
コア数
速度向上
(参考) 自動チューニング
• ハードウェアに合わせたチューニングのこと – HPC業界 (?) の取り組み
– cf. 自動チューニング研究会 (須田礼仁先生) • ほとんどのメンバーは数値計算が専門
– 並列計算機はそれぞれ性質が異なるのでパラメータをチューニングする必要がある
• 並列囲碁との関連 – 十分なテストが難しい (自宅にスパコンが欲しい) – 自動チューニングの成果を利用して、念力に頼る部分を減らしたい • 例、少コア数で実験→多いコア数のパラメータを推測
• 例、オンラインとオフラインの区別をつけない
– 今のところ、それほど成功していない
プレイアウトを複数同時に
(Leaf parallel) ru
n 1
pla
yo
ut
at
leaf
(defa
ult
)
run
N p
layo
uts
at
leaf
プレイアウトが遅ければ速度向上も大きい
複数のプレイアウトを一度に実行すれば見た目は長くなる
Tsubame2 上では 1.0 ms あれば性能向上が得られるので、序盤では2回実行すれば十分
（序盤、終盤ではプレイアウト速度が変わる）
Leaf Parallel の性能 (序盤)
• Leaf 2 以降はそれほど性能が伸びない – 1.0 ms 以上は不要か？
• 現在は Leaf2 を使用中 – 逐次版の対戦実験で、
Leaf2は強さに悪影響がないことを確認済み
– （理由は不明だが、婦考慮時間が長い場合はむしろ強くなる）
0
50
100
150
200
250
300
350
0 200 400 600 800 1000
spe
ed
up
cores
Leaf 1～4 の速度向上
default
leaf2
leaf3
leaf4
その他のパラメータ調整
• 地味なので詳細は省略
• Virtual Loss の調整 – 他のジョブが探索中の節点をどの程度忌避するか
– トレードオフ • 局所性を高める <-> 有望なところに集中
• Total job number – starvation が起こらないギリギリの数に調整する
• 考慮時間に応じた調整 – 考慮時間30秒と3秒では最適な値が異なる
並列囲碁プログラムの途中経過
• ネット対局サーバ KGS に並列版を投入 – 主に人間を相手に対局
– SGI-UV1000 の 512コアを主に使用
– 今後 Tsubame2 もテストする予定
• まだデバッグ中 – 頻繁に時間切れ負けする
• 通信遅延の見積もりが甘い
• 終局時の死活不同意の対応など
• その他の不具合 – 直前のMPIプロセスが生き残っていて止まる
– 1ノードでも止まると全体が止まる
耐故障性 (実装中)
• 青の計算ノードが止まると – 青い計算ノードを通過するジョブが消滅していく
– すぐには分からないのでたちが悪い
• ある程度対応は可能なはず – 故障ノードを検知 – ハッシュ関数を変更して故障ノードの仕事を他のノードに均等に振り分け
– N台以下の故障まで対応、と決める – ルート節点を担当している計算機が故障した場合はあきらめる
人間らしいゲームAI
• 強いAI ≠ 楽しいAI
– 将棋や囲碁は今は強いAI
• 人間らしい（自然に弱い）AI を作る大会
– The 2K BotPrize • FPS (Unreal Tournament 2004) の AI と対戦
• (注: チャットなどはしない。プレイのみで判定)
• 2012年に人間より人間らしい AI（投票結果）
– Mario AI Turing Track • 2013年に人間より人間らしい AI（投票結果）
• 対戦相手、協力相手として意義が大きい
Mario AI
• Mario AI とは
– Java ベースの某有名ゲームクローン
– 探索で与えられる情報は画面に映っている情報のみ • ステージはランダム生成
– 行動は１フレームごとに１１通りの行動がある
– AIは42ミリ秒以内(1/24秒)に探索，出力を行う
– 画面内の敵の動作は決定的
– クリアの早さを競う部門ではA*探索ベースのAIが有名
• Turing Test Track – 人間の投票によって人間ぽい方を選ぶ
– 人間2人と AI 3つが参加 (2013年)
UCT + 進化計算によるマリオAI
• 人間のプレイを模倣する
– プレイアウトの性質、報酬を調整する
• 人間はミスを前提としたプレイをする
– UCTの「勝率」の高い選択肢を選ぶ性質と似ている
– A*で普通に作ると非人間的にうまい
• プレイアウトを調整して人間の挙動に似せる
– 進化計算で調整 (GA と DE)
– 人間の操作履歴との一致率を60%程度に
進化計算と UCT による Mario を人間らしくプレイする AI
中野 雄基, 美添 一樹, 脇田 建.
第18回 ゲームプログラミングワークショップ. 2013.
DE: Differential Evolution (差分進化)
UCT を Mario AI へ適用
UCT 一般的な手法
提案手法
目的 強いAIの作成 人間らしくプレイする
プレイアウト（方策）
強い人間（プロ）から
頻出パターンなどを学習
任意のプレイヤー
から戦略を学習
報酬 負け、勝ち
０ または １
似ていない <-> 似ている
0 ~ 1
探索時間 数秒から十数秒 42ミリ秒以内 （実験では300プレイアウト可能）