TadaoYamaokaの開発日記

個人開発しているスマホアプリや将棋AIの開発ネタを中心に書いていきます。

AlphaStarの論文を読む その5(アーキテクチャ)

しばらく空きましたが、続きです。
アーキテクチャは長いので途中までです。

アーキテクチャ

  • AlphaStarの方策は関数\pi_{\theta}\left(a_{t} | s_{t}, z\right)で、以前のすべての観測とアクションS_{t}=O_{1: t}, a_{1: t-1}および𝑧(戦略統計を表す)を現在のステップの行動a_tの確率分布にマッピングする

拡張データ表1 | エージェント入力空間

カテゴリ フィールド 説明
エンティティ:最大512 ユニット型 例:ドローンまたはフォースフィールド
オーナー エージェント、敵、中立
状態 現在の健康状態、シールド、エネルギー
画面タイプ 例:戦場の霧(不確定要素)の中にある敵の建物のスナップショット
ポジション エンティティの位置
労働者数 リソース収集基地建築用
クールダウン 攻撃のクールダウン
属性 目に見えない、動力付き、幻覚、アクティブ、貨物内、および/または画面内
ユニット属性 例:生物または装甲
貨物の状態 現在および最大の貨物スペース
建物の状態 建築の進行状況、建築キュー、およびアドオンの種類
リソースの状態 残りのリソースの内容
命令の状況 命令キューと命令の進捗
バフステータス バフとバフ持続時間
マップ:128x128グリッド 高さ 地図の場所の高さ
可視性 地図の場所が現在表示されているかどうか
クリープ 特定の場所にクリープがあるかどうか
エンティティの所有者 エンティティを所有しているプレーヤー
アラート ユニットが攻撃を受けているかどうか
進行可能 どのエリアをナビゲートできるか
建築可能 建築できるエリア
プレイヤーデータ 人種 エージェントと対戦相手が要求した種族、エージェントの実際の種族
アップグレード エージェントのアップグレードと対戦相手のアップグレード(人間に知られている場合)
エージェント統計 エージェントの現在のリソース、供給、軍隊の供給、労働者の供給、最大供給、アイドル労働者の数、ワープゲートの数、および幼虫の数
ゲームの統計 カメラ時間 現在のカメラ位置。カメラは32x20のゲームユニットサイズの長方形です。現在のゲーム時間

拡張データ表2 | エージェント行動空間

フィールド 説明
アクションタイプ 実行するアクション。アクションの例としては、ユニットの移動、建物からのユニットの訓練、カメラの移動、無操作などがあります。完全なリストについては、PySC2を参照
選択したユニット アクションを実行するエンティティ
ターゲット アクションのターゲットとなる256x256に離散化されたマップ内のエンティティまたは場所
待機中 このアクションをキューに入れるか、すぐに実行するか
繰り返す このアクションを複数回発行するかどうか
ディレイ 次の観測を受信するまで待機するゲームのタイムステップ数

ニューラルネットワークの構造

  • 観測o_tはベクトル表現にエンコードされ、結合され、ステップ間でメモリを維持するディープLSTMによって処理される
  • 行動の引数a_tは、LSTMと観測エンコーダの出力を条件として、自己回帰的にサンプリングされる
  • 可能な報酬ごとに価値関数がある(後述の強化学習を参照)

f:id:TadaoYamaoka:20191106084710p:plain

f:id:TadaoYamaoka:20191111085542p:plain

感想

方策の自己回帰的な表現について詳細が記述されていませんが、前の論文に記述がありました。
このブログでも、以前に記事にしました。

アーキテクチャ詳細

アーキテクチャ詳細は、Supplementary Dataのdetailed-architecture.txtに記載されています。

入力

  • prev_state : 以前のLSTM状態
  • entity_list : ゲーム内のエンティティのリスト(上記拡張データ表1参照)
  • map : ゲームマップを記述する7つのレイヤー(上記拡張データ表1参照)
  • scalar_features : プレイヤーのデータとゲームの統計情報、およびビルドオーダー
  • opponent_observations : 相手の観測値(「entity_list」、「map」、「scalar_features」と構造が似ている)。 ベースラインにのみ使用され、プレイ中の推論には使用されない
  • cumulative_score : ゲームによって追跡されるさまざまなスコアメトリック。ベースラインにのみ使用され、プレイ中の推論には使用されない。 これらは、プレイ中に人間には見えない。スコア、アイドル生産時間、作業時間、ユニットと構造物の合計値、ユニットと構造物の合計破壊値、収集された鉱物とヴェスピンの合計、鉱物とヴェスピンのコレクションの割合、使用済みの合計が含まれます ミネラルとヴェスピン

エンティティエンコーダ

  • 入力:entity_list
  • 出力:
    • embedded_entity : 埋め込みエンティティの1Dテンソル
    • entity_embeddings : 各エンティティの埋め込み(すべてのエンティティに1つの埋め込みを持つ「embedded_entity」とは対照的)
  • entity_listの各エンティティのフィールドは最初に前処理されて連結され、各エンティティに単一の1Dテンソルが存在するようになる。 フィールドは以下のように前処理される。
    • unit_type:最大256のワンホット(不明なユニットタイプを含む)
    • unit_attributes:13個のユニット属性ごとに1つのブール値
    • alliance:最大5つのワンホット(未知の同盟を含む)
    • ※他、current_health,current_shields,current_energy,cargo_space_used,cargo_space_maximum,build_progress,current_health_ratio,current_shield_ratio,current_energy_ratio,display_type,x_position,y_position,is_cloaked,is_powered,is_hallucination,is_active,is_on_screen,is_in_cargo,current_minerals,current_vespene,mined_minerals,mined_vespene,assigned_harvesters,ideal_harvesters,weapon_cooldown,order_queue_length,order_1,order_2,order_3,order_4,buffs,addon_type,order_progress_1,order_progress_2,weapon_upgrades,armor_upgrades,shield_upgrades,was_selected,was_targetedは省略
  • これらの前処理済みエンティティは最大512個あり、512個より後のエンティティは無視される。 エンティティを参照しない512エントリのいずれにも、-1e9のバイアスを使用する。
  • 前処理されたエンティティとバイアスは、2層の自己注意の3つの層を持つトランスフォーマーに入力される。 各レイヤーで、各自己注意ヘッドはサイズ128のキー、クエリ、およびバリューを使用し、カーネルサイズ1のConv1Dを介して集約値を渡し、チャネル数を2倍(256)にする。 ヘッドの結果は合計され、隠れサイズ1024および出力サイズ256の2層MLPを通過する。
  • トランスフォーマーの出力は、ReLU、256チャネルとカーネルサイズ1の1D畳み込み、および別のReLUを介して渡され、「entity_embeddings」が生成される。 ユニット全体のトランスフォーマー出力の平均(欠落しているエントリによってマスクされる)は、サイズ256の全結合層とReLUを介して供給され、「embedded_entity」が生成される。

空間エンコーダ(Spatial Encoder)

  • 入力:map、entity_embeddings
  • 出力:
    • embedded_spatial : 埋め込みマップの1Dテンソル
    • map_skip : 中間計算(intermediate computations)の出力のテンソル
  • 2つの追加のマップレイヤーが、上記拡張データ表1で説明されているレイヤーに追加される。 1つ目は、2つの可能な値を持つカメラレイヤー:場所が仮想カメラの内側か外側か。 2つ目は散在する(scattered )エンティティ。 「entity_embeddings」は、サイズ32の1Dコンボリューションとそれに続くReLUを介して埋め込まれ、特定の場所のサイズ32のベクトルがそこに配置されたユニットに対応するようにマップレイヤーに分散される。 プレーンは次のように前処理される。
    • camera: 位置がカメラ内にあるかどうかの最大2つのワンホット
    • scattered_entities: エンティティの埋め込みからの32個のfloat値
    • height_map: マップの高さ/255.0のfloat値
    • ※他、visibility,creep,entity_owners,alerts,pathable,buildableは省略
  • 前処理後、プレーンは連結され、カーネルサイズ1の2D畳み込みによって32チャネルに投影され、ReLUを通過してから、チャネルサイズ64、128、128の3つの2D畳み込みとReLUを介して128x128から16x16にダウンサンプリングされる。 これらの3つのダウンサンプリング畳み込みのカーネルサイズは4、ストライドは2。128チャネルとカーネルサイズ3の4つのResBlocksがダウンサンプルされたマップに適用され、スキップ接続が「map_skip」に接続される。 ResBlockの出力は、全結合層とReLUによってサイズ256の1Dテンソルに埋め込まれ、「embedded_spatial」になる。
感想

エンティティエンコーダで個々のユニット埋め込み表現を作って、空間エンコーダーの対応するユニットの位置に入力されています。
エンティティエンコーダにユニットを入力する順番をどうするのか疑問に思いましたが、エンティティエンコーダーへの入力順に関係なく、空間エンコーダーではユニット対応する位置に入力するので順番は関係なくなります。
また、エンティティエンコーダのembedded_entityは、すべてのユニットを統合した埋め込み表現となっていますが、トランスフォーマーは自己注意のクエリ、キー、バリューの機構によって入力順に依存しないで出力を得ることができるので、どのような順でユニットを入力しても良いことになります。

スカラエンコーダ

  • 入力:scalar_features、entity_list
  • 出力:
    • embedded_scalar : 埋め込みスカラ特徴量の1Dテンソル
    • scalar_context : 後でゲーティングのコンテキストとして使用する特定のスカラ特徴量の1Dテンソル
  • スカラエンコーダは、各「scalar_features」を1Dテンソルに埋め込み、それらを連結して「embedded_scalar」を生成する。 これらの埋め込み特徴量の一部は、連結されて「scalar_context」を生成する。 特徴量は次のように埋め込まれる。
    • agent_statistics : log(agent_statistics+1)を入力し、サイズ64の全結合層とReLUを通過することにより埋め込まれる
    • race : 両方の種族は、最大5のワンホットに埋め込まれ、サイズ32の全結合層とReLUを介して埋め込まれる。 訓練中、相手の要求された種族は、ランダム種族との対戦をシミュレートするために、対戦の10%では隠される。 この埋め込みは「scalar_context」にも追加される。 敵の種族がランダムであるか、隠されているためにわからない場合、ユニットの1つを観察した後、観測に真の種族を追加する。
    • ※他、upgrades,enemy_upgrades,timeは省略
  • 空間エンコーダのように、いくつかの追加特徴量を追加し、他の「scalar_features」と同様に埋め込み、連結する。 これらの特徴量は次のとおり。
    • unit_counts_bow : 「entity_list」のbag-of-words。 ユニットカウントベクトルは、平方根によって埋め込まれ、全結合層を通過し、ReLUを通過する。
    • mmr : 教師あり学習中、模倣しようとしているプレーヤーのMMR(Match Making Rating)。 それ以外では、6200に固定される。MMRは、最大6のmin(mmr / 1000, 6)のワンホットにマッピングされ、サイズ64の全結合層とReLUを通過する。
    • cumulative_statistics:累積統計(ユニット、建物、効果、アップグレードを含む)は、人間のゲームの統計に存在するかどうかのブールベクトルに前処理される。 ベクトルは、ユニット/建物、効果、およびアップグレードの3つのサブベクトルに分割され、各サブベクトルはサイズ32の全結合層とReLUを通過し、連結される。 この埋め込みは「scalar_context」にも追加される。
    • ※他、begin_build_order,last_delay,last_action_type,last_repeat_queuedは省略
  • 上記のように、すべての特徴量は「embedded_scalar」用に連結され、注記されている特徴量は「scalar_context」用に連結される。

(続く)

AlphaStarの論文を読む - TadaoYamaokaの開発日記
AlphaStarの論文を読む その2 - TadaoYamaokaの開発日記
AlphaStarの論文を読む その3 - TadaoYamaokaの開発日記
AlphaStarの論文を読む その4 - TadaoYamaokaの開発日記
AlphaStarの論文を読む その5(アーキテクチャ) - TadaoYamaokaの開発日記
AlphaStarの論文を読む その6(アーキテクチャその2) - TadaoYamaokaの開発日記
AlphaStarの論文を読む その7(アーキテクチャその3) - TadaoYamaokaの開発日記
AlphaStarの論文を読む その8(教師あり学習、強化学習) - TadaoYamaokaの開発日記
AlphaStarの論文を読む その9(マルチエージェント学習) - TadaoYamaokaの開発日記
AlphaStarの論文を読む その10(リーグ構成) - TadaoYamaokaの開発日記
AlphaStarの論文を読む その11(インフラ) - TadaoYamaokaの開発日記
AlphaStarの論文を読む その12(評価) - TadaoYamaokaの開発日記
AlphaStarの論文を読む その13(分析、AlphaStarの一般性) - TadaoYamaokaの開発日記