[API] 強化学習する際の行動空間の設計を考える

[sotetsuk]

• 普通の強化学習タスクは一つの行動空間Aがあり、これが全状態で共通
• 麻雀のようなタスクは、行動空間が状態に依存している。例えば、A_0, ... A_Nまでの空間があってA = A_0 ∪ , ..., ∪, A_N。
  • E.g., A_0 = discardの行動空間、A_1 = chiの行動空間

ややこしいのが

• 赤
• チーのときの、[2]34 or 1[2]3 みたいなやつ
• チーとポンの組み合わせ
• あと、赤とチーの組み合わせ

[sotetsuk]

行動の種類

• discard
• riichi
• chi
• pon
• kan
  • minkan
  • ankan
  • kakan
• tsumo
• ron
• kyuusyu

[sotetsuk]

https://github.com/openai/gym/blob/master/gym/spaces/tuple.py

もし、チーが一種類しかなく、赤もなければ、

Tuple(34, 2, 2, 2, ...., 2)

で終わりだったが、現実はそうではない。

[sotetsuk]

赤の扱い方

1. 34 => 37
2. 別の赤を使うみたいなbinaryの行動次元を追加する

[sotetsuk]

チー

全パターン数N

• [m1]m2m3
• m1[m2]m3 ...

3 7 3 (= 63) くらい

状態依存のパターン数M

高々5くらい。捨てられた牌の数をXとすれば

1. しない
2. X, X+1, X+2
3. X-1, X, X+1
4. X-2, X-1, X

ソリューション

1. NNの都合を無視すれば、全チーのパターンNを列挙して、Discrete(N)を使う
2. 状態依存のパターン数Mを列挙して、Discrete(M)を使う

[sotetsuk]

鳴きはチーポンカン含めて全部一緒の方が良いか

• 自分がツモった後
  • Discard(34~37)
  • Ankan
  • Kakan
• ターチャの捨て牌の後
  • No
  • Chi (5くらい）
  • Pon（赤のせいで2通りある）
  • Minkan

くらいだったら

• Tuple(Discrete(40くらい), Discrete(10くらい)) 赤込み
• もし赤を別次元で扱うなら
  • Multi(Tuple(Dsicrete(40くらい), Discrete(10くらい)), Discrete(2)) 最後は赤を見せるか否か
  • Tuple( Multi(Discrete(36), Discrete(2)) , Multi(Discrete(6), Discrete(2)) )

[sotetsuk]

• Tuple(Discrete(40くらい), Discrete(10くらい)) 赤込み
  • NNの構造は簡素（２股）
  • 学習が遅そう
• Tuple( Multi(Discrete(36), Discrete(2)) , Multi(Discrete(6), Discrete(2)) )
  • 赤なしルールもやるときにアジャストしやすい
  • NNの構造がやや複雑化（４股）
  • 最悪、赤のところはルールベースにできる
• 天鳳に忠実な形にすると...
  • Tuple ( Tuple ( Discrete(2), Discrete(2) , Discrete(2) , Multi ( Discrete(34), Discrete(2) ) ), Tuple( Discrete(2), Multi( Discrete(6), Discrete(2) ))) 多分外側のTupleは２つまとめても良さそう
  • ツモ後
  • Tsumo: Discrete(2)
  • Kyuusyu: Discrete(2)
  • Ankan, Kakan, No: Discrete(3)
    • Ankanは4枚たくさん持っている可能性がある
  • Riichi: Discrete(2)
  • Discard: Multi ( Discrete(34), Discrete(2) )
  • ターチャの捨て牌のあと
  • Ron: Discrete(2)
  • No, Chi, Pon, Minkan: Multi( Discrete(6), Discrete(2) )
  • 問題: 例えばRonとChiの分け方が恣意的だし、同時に天秤にかけたいときもある
• ルールの観点で中立な感じにすると...全部同時に判断しないといけない
  • ツモ後: Discrete(40+)
  • Tsumo (1)
  • Kyuusyu (1)
  • Ankan (34) どうにかなんないかな....
  • Kakan (1)
  • Riichi (1)
  • Discard (34 + 3)
  • ターチャの捨て牌の後: Dsicrete(10くらい)
  • No (1)
  • Ron (1)
  • Chi (5)
  • Pon (2)
  • Minkan (1)
  • 問題: Ankanの34...., Chiも本当は相対ではなく絶対で60通りくらいある
• 34枚と、他のアクションのMulti（ファミコンの十字キーとABみたいな感じ）
  • ちょっと冗長。自然さがたりない。人間はそんな風に判断しない。
  • 例:
  • Discard(m1) => discardフラグ + m1のフラグ
  • RIichiしてm1切るときは => Riichiフラグ + m1のフラグ
  • m1m2m3でチー => チーフラグ + m1のフラグ or (m1m2m3のフラグ)
  • フィルタが無理か（学習が厳しいか）
• 一番原始的なのは、本当に全可能アクションを列挙

[habara-k]

未解決

openai/baseline においてTuple, Multi, Discreteがどのようにvector化されているのか？

[sotetsuk]

• Riichiした: ( (-1, -1, -1, 1, -1), (-1, (-1, -1)) )
• Riichiしなかった: ( (-1, -1, -1, 0, -1), (-1, (-1, -1)) )
• Discard: ((-1, -1, -1, -1, 10), (-1, (-1, -1)))

[sotetsuk]

• [x] ターチャの捨て牌のあとのRonが恣意的... 今の実装・天鳳の実装と比較
  • => 検証するまでもなく恣意的でした...

[sotetsuk]

PettingZooの麻雀を確認してもいいかもしれない（中麻で赤はないが） => かなりsimplifyされてて参考にはならなさそう。

[sotetsuk]

冷静に考えると、加カンも34種類必要...（ポンを２つ以上しているとき用）

[sotetsuk]

いくつかベクトル化の仕方を提供する形になるか（ユーザも定義できる）

• Flatなやつ（一番シンプルで、全て列挙）
• Suphxと同じような分割の仕方
• ツモ後と、鳴くときで分けたやり方
• 十字コントローラ方式

[sotetsuk]

全部列挙するのが、いくつになるのか厳密に数える

1. Tsumo (1)
2. Kyuusyu (1)
3. Ankan (34)
4. Kakan (34)
5. Riichi (1)
6. Discard (34+3 =37)
7. No (1)
8. Ron (1)
9. Chi ((3+7) * 3 = 30)
10. Pon (34+3 = 37)
11. Minkan (1)

計178 （？）

[sotetsuk]

ちょっとポンの赤の扱いだけ検討の余地がある気がしてきた

[sotetsuk]

例えば天鳳でポンのボタンは赤を持っていなければ一つしか出てこないことが決まっているわけで、それなのに37種類あるのは変な気がする。

• Pon w/o 赤
• Pon w/ 赤

とかの方が自然な気がするなあ。。。

[sotetsuk]

ただ、ポンを二択にするなら、例えばチーも五択でいいじゃんってなりそう。

[sotetsuk]

Ponが37択の懸念は

• 学習 => Noがあるから大丈夫では？
• 冗長すぎないか？
  • 将棋も冗長だし
  • Ponを二択とかにするなら、極論discardも最大14択なのに34個あるのはおかしい。

[sotetsuk]

11 x 37 通りも考えられるといえば考えられるが。。。

[sotetsuk]

確定版

• Discard (34+3 =37)
• Chi ((3+7) * 3 = 30)
• Pon (34+3 = 37)
• Kan (34)
• Tsumo (1)
• Ron (1)
• Riichi (1)
• Kyuusyu (1)
• No (1)

合計143

[sotetsuk]

これらベクトル化はmjx側で実装

• mjx::VectorizerFlat(mjxproto::Action) -> int ?
• mjx::VectorizerSuphx(mjxproto::Action) -> vector<int> ?

みたいな感じか。（命名は検討の余地がある）

[sotetsuk]

• Kanをまとめるなら、TsumoとRonもWinでまとめることは可能だが
• 天鳳/雀魂のボタンは一応区別されている

=> 否決

[sotetsuk]

ツモ切りを検討していなかった。。。。。。。。。

[sotetsuk]

ツモ切りを検討していなかった。。。。。。。。。

discardの次元を2倍にするのが一番シンプルか。

[sotetsuk]

確定版

• Discard (34+3 =37)
• Chi ((3+7) * 3 = 30)
• Pon (34+3 = 37)
• Kan (34)
• Tsumo (1)
• Ron (1)
• Riichi (1)
• Kyuusyu (1)
• No (1)

合計143

ツモ切りを追加すると

• Discard (34+3 =37)
• Tsumogiri (34+3=37)
• Chi ((3+7) * 3 = 30)
• Pon (34+3 = 37)
• Kan (34)
• Tsumo (1)
• Ron (1)
• Riichi (1)
• Kyuusyu (1)
• No (1)

合計180

[sotetsuk]

追加で、

• dummyが合ったほうがいいかもしれない
  • 局毎の報酬情報を共有するため
  • 次の局にいくとEventHistoryが空になってしまうので、情報が色々失われている（例: ３位で降りていたが、2位が暴牌を切って4位があがって4位に落ちてしまった。dummyがないと、2位が暴牌を切った情報が失われてしまう）
• Noが複数の意味合いで使われているので、(Chi: 30) => (Chi:30 + NO1)とかにした方がいいかもしれない。 => チーとポンが両方できるときにうまくいかない

とかはありかもしれない。