【DRL,Montezuma】学習状況確認のためのツール
Montezuma's Revengeの強化学習において、平均スコアだけでは、学習状況が良くわからないので、各種状況を表示するツールを追加しました(plot2.pyとall-plot)。これらを用い、下記のような感じで学習状況をモニタしながら実験を進めています。ご参考まで。
各グラフの説明は下記です。なお、説明順は、左端から上下にグラフを辿ったものです。
- *.r: 全てのScore(実reward)の分布と、その平均の推移
- *.R: 凡例に示した番号の部屋(Room)の訪問頻度
- *.RO: 凡例に示した番号の部屋(Room)でのOHL頻度
- *.k: 凡例に示した部屋でのkill頻度
- *.tes: 凡例に示したScoreを取得でのOHL学習長(Train-Episode-Steps)
- *.lives: 凡例に示したScoreを取得した際の残りライフ数(lives)
- *.s: 凡例に示したScoreを取得するまでのstep数
- *.pr: 各ステップでのpseudo-rewardの分布とその平均値の推移
- *.v: 各ステップでのvの値の分布とその平均値の推移
【DRL,Montezuma】Scoreが0になり回復しない原因の分析
Montezua's Revengeの強化学習で、下記のように、Scoreが0になり回復しない場合がありましたが、原因を少し分析してみました。
Scoreが0になり回復しない状況調査
Scoreが0になった後は、ROOM#1でPanama Joeが死にまくるのかと思っていましたが、これは誤っていることが分かりました。下記は、どの部屋でkillが起きているか(kill頻度：一定stepあたりのkill回数)を図示したものです。なお、凡例に書かれた数字が部屋の番号です。
Scoreが0になる直前で(約28 Mstep)、ROOM#1のkill頻度が高まっていますが、28 Mstep以降は、kill頻度がほぼ0なのがわかります。ほぼ0の部分を拡大したものが下記です。
ほぼ0ではあるものの、完全に0ではなく、多少のkillが発生していることが分かります。つまり、あまりkillされない範囲で、微妙に移動しているようです。(この部分の動画を撮っておけば、もっとハッキリしたのですが...*1 )
ちなみに、先頭から2つめの図を見ると、Scoreが0になる直前では、ROOM#2のkill頻度だけでなく、ROOM#2、ROOM#7のkill頻度も増えています。
下記は、各部屋の訪問頻度を図示したものです。Scoreが0になる直前で、ROOM#7の訪問回数が増えていることが分かります。
原因分析／推測
これらから、下記のような現象が起きているのではないかと推測しています。
- ROOM#7や他の部屋での学習の副作用として、ROOM#1でkeyを入手できなくなる(NNの値が、そのように変化するということ)。
- これにより、ROOM#1から脱出できなくなり、Scoreは100点以下になる。
- また、実rewardが0になるので、各地点(実際はstatus)でのVが順次減少する。
- 更に、ROOM#1内の地点(実際はstatus)は通過頻度が高く、pseudo-rerawdはほぼ0。これにより、Vを増加させるものが全く無い状態となる。
- そのため、ROOM#1内で、僅かなpseudo-rewardだけに基づいて学習が起こり、killが起きない程度の僅かな動きだけになる。
- 上記全体の結果として、Scoreを取得する上で重要なルートほど、通過回数が非常に多いので、pseudo-rewardは0に近く、一度Vが0に近くなると回復することはない。
上記推測が正しいとすると、pseudo-rewardだけに基づいた学習では、実rewardを取れる所まで辿り着けるようになるものの、その地点へのルートの学習が一度失われると、回復しないということとなります。そのために、学習が非常に不安定になるのだと思います。
上記は、A3Cで学習ですが、Double DQNでは、一度学習したパスを覚えておき、後で利用するので、一度Scoreが0になっても、過去に学習したパスでのVに基づいて再学習が行われ、安定な学習に寄与できるのだと思います。
対策案 (Replay Memoryの導入／活用)
逆に、A3Cでも、一度学習したパスをReplay Memoryに覚えておき、後で利用するようにすれば、学習が安定すると思われます。ただ、メモリ量も限られるので、どのパスを覚えておくのが良いか、判断が難しいですね。Scoreは高いほうが良い、Score取得時のLivesは多いほうが良い、点数を取得するまでのsteps数は少ないほうが良い、などの判断基準が考えられますが、これらに対して、どのように重み付けするのが良いか、難しそうです。1つの案としては、重み付けも学習すれば良いかもしれませんが...
対策案のためのメモリ量削減
なお、記憶するパス数や長さを制限する以外に、直接メモリ量を減らすことも可能です。以前に実験した結果として、pythonのlzmaでパスを圧縮すると、メモリ量が約1/40になり、学習速度(steps/h)への影響は16%程度で済むことが分かっています。
実際、現在でも、High Score取得動画や、新しいROOM訪問動画を出力するために、全てのthreadの全ての学習で、GAME OVER直前までのパスを覚えています。実は、パスの圧縮を行う前は、学習途中でメモリ量が16GBを超え、メモリ不足になることもあったのですが、パスの圧縮を行うことにより、現状のメモリ量は4GB程度で済んでいます。
別の対策案 (Mile Stone)
ちなみに、Replay Memory以外にもメモリ量が非常に少ない方法がありそうと思っています。Replayするパスを覚えるのではなく、学習に有効なパスの幾つかの場所(status)をMile Stoneとして覚えておき、そのMile Stoneでは、擬似rewardとしてMile Stoneポイントを与えることが考えられます。ただ、この場合も、どれをMile Stoneにするか、どのようにMile Stoneを更新するかなど、課題が色々ある気がします。
今後の進め方
最近、ウィークディは仕事が忙しく、土日も私用で忙しく、なかなかDeep Learningで遊べなくなってきていますが、できるだけ時間を作って、Replay Memoryの導入・利用処理や、Mile Stoneを実装していこうと思います。
実は、他にも色々とアイデアがあるのですが、実装の手間・時間、その効果を確認するために必要なITリソースや時間などが、膨大に必要なため、なかなか難しい状況です。
【DRL,Montezuma】ALE環境でLaser Barrier通過！
あけましておめでとうございます。
相変わらず、Montezuma's Revengeの強化学習実験を行っています。
GCPから自宅PCへ
昨年は、GCP (Google Cloud Platform)の無料枠($300、3ヶ月以内)を使い、格安のPreemptible VMを活用し、一度に8個の学習を行っていたのですが、無料枠利用は基本的に1回であり、3回めの利用でGCPアカウントが削除されてしまいました。
そこで、今年から、自宅PCで強化学習を継続することにしました。幸い、冬は冷房が不要なので、PCを数日間点けっぱなしにする強化学習には、非常に向いています。自宅学習結果はクラウド(AWS 1年無料枠)にアップし、スマホで確認できるようにしています。
OpenAI GymからALEへ
OpenAI Gymは、かなり多数の実験を実施済みであり(100回程度)、OpenAI社自体はGymからUniverse(昨年12/5発表)に移行しているので、当面はALE(Arcade Learning Environment)での実験に絞ることにしました。
直感と仮説に基づいた狭い探索
自宅PCは、GCPと較べてITリソースが少ないので、ハイパーパラメータ探索は、乱数を使った広域探索ではなく、直感と仮説に基づいた狭い探索とする必要があります。今回、直感と仮説に基づいたアプローチが成功したので、報告させて頂きます。
以前のALE実験結果
ALEでは、昨年10/7に、平均点が2000点近く出ましたが、その後、ALEでの実験は行っていませんでした。OpenAI Gymでは平均点が1500点止まりだったので、ALEの方が平均点が高いのですが、ROOM#0とROOM#7にあるLaser Barriersを通過できず、探索範囲が非常に限定されていました*1。
ALEとOpenAI Gymの違い
ALEとOpenAI Gymの最大の違いは、frameスキップ数*2です。ALEでは、DeepMindのAtari2600でのframeスキップ数である4を使っていました。これに対して、OpenAI Gymでは、frameスキップ数が2〜4の一様乱数となります。当方の強化学習環境では、OpenAI Gymのframeスキップ処理を2回呼び出す度に学習するので、frameスキップ数は中心が6の正規分布(的な分布)になります。
昨年は、frameスキップ数を6にして何回か実験を繰り返しましたが、Laser Barriersを通過でませんでした。また、タイミングを正確に測ってLaser Barriersを通過できるように、frameスキップ数を1や2にしたりもしましたが、この場合は学習が殆ど進まず、うまく行きませんでした。
仮説を立て実験の結果、Laser Barrier通過！
そこで、今回、次の仮説を立てました。
- Laser Barrierを通過できないのは、Laser BarrierがON/OFFする周期(frame数)と、学習高速化のためにスキップするframe数が互いに素ではないため、色々なタイミングでの試行が難しいためではないか？
この仮説に基づき、frameスキップ数を7にしたところ、思惑通り、Laser Barriersを通過することが出来ました。学習曲線と、到達した部屋は、下記です。
OpenAI Gymでは、平均点が急に0になった後で回復しない現象が頻発したのですが、今回の実験では、平均数が度々0になるものの、ちゃんと回復し、1400点弱を維持しています。
ちなみに、frameスキップ数として3,4,5,6を選ばなかったのは、1秒のframe数が60だからです。つまり、3,4,5,6はframe数60の約数となり、各1秒毎に同じframeしか学習対象にならなず、Laser Barrierを通過できるframeが学習対象にならない可能性があると考えたためです。7の次は11や13が良さそうですが、まだ試していません。
今後は、frameスキップ数=7に、他のハイパーパラメーターを組み合わせて実験していこうと思います。また、frameスキップ数として11や13も試したいですが、なにぶんITリソースが余り無いので、週単位で、かなり先になりそうです。
ソースコード等
ちなみに、ソースプログラムは下記にあります。興味のある方はトライください。
github.com
ALEなどの環境を構築後、下記コマンドで学習させてください。
> run-option montezuma-y-cnc-tes60-b020-ff-fs7
ちなみに、学習曲線や到達部屋を表示したい方は、次のようにしてください。
# 1つめの端末で実行
> script log.montezuma-y-cnc-tes60-b020-ff-fs7
> run-option montezuma-y-cnc-tes60-b020-ff-fs7
# 2つめの端末で実行
> python plot.py log.montezuma-y-cnc-tes60-b020-ff-fs7
# 3つめの端末で実行
> while true; do python rooms.py log.montezuma-y-cnc-tes60-b020-ff-fs7 ; sleep 30; done
【DRL,Montezuma】GCPアカウントが停止し続行不能。残念！
DRL用にGoogle Cloud Platformの無料試用枠を使ってましたが、サンフランシスコに行っている間、何故か、学習が進まなくなり、帰国後に確認したところ、Googleから通告が来ていて、GCPアカウントが削除されていました。
やはり、無料試用枠の複数回利用は、検出・阻止されるようです。
これで、Montezuma's RevengeのGCPでの試行はできなくなってしまいました。残念です。
Googleからの通告(日本語、11日前)
Google からのお知らせ
このたび Google では、お客様の Google Cloud Platform と API の請求先アカウント HHHHHH-HHHHHH-HHHHHH を一時的に停止いたしました。お客様のアカウントで不審なアクティビティが検知されたためです。
この問題を解決するには、https://support.google.com/cloud/contact/verify でお客様のアカウント情報をご確認ください。
Googleからの通告(英語、11日前)
Dear Developer,
We have recently detected that your Google Cloud Project AAAAAAAA (id: AAAAAAAA-nnnnnn) has been having an issue with your billing account. We are unable to verify the billing information you provided. Your project AAAAAAAA (id: AAAAAAAA-nnnnnn) has been suspended and a notification has been sent to the Billing Account owner of this project. Please work with them in order to resolve the issue.
We will delete your project unless the billing owner corrects the violation by filling out the Account Verification Form within three business days. This form verifies your identity and ownership of the payment instrument. Failure to provide the requested documents may result in permanent account closure.
GCP API利用でのエラーメッセージ
ERROR: (gcloud.compute.instances.list) Some requests did not succeed: - Project blocked; abuse detected.
- その２
-その１ ERROR: (gcloud.compute.copy-files) Could not fetch instance: - Project blocked; abuse detected.
- その３
ERROR: (gcloud.compute.instances.start) Some requests did not succeed: - Project blocked; abuse detected. ERROR: (gcloud.compute.instances.describe) Could not fetch resource: - Project blocked; abuse detected.
【DRL, Montezuma】スライド再更新＋再々更新
Montezuma's Revengeのスライド更新時に、OpenAI Gymの方から結構詳しく聞かれた「pseudo-countの実装方法」を書き忘れたので、再更新しました。ソースを読めば分かると思っていましたが、それほどわかりやすいソースでもないので... （この後、誤りに気付き、さらに更新しました）
www.slideshare.net
OpenAIのInterviewでのフィードバック受けスライド更新
現在、サンフランシスコに来ており、昨日、Montezuma's Revengeの強化学習の件で、OpenAIのInterviewを受けました。いろいろと質問があり、そこで答えたことや、それ以外も含めてスライドの内容を追加・修正いたしました。ご興味のある方はご覧ください。ちなみに、今回の旅費・宿泊費は、ほぼOpenAI持ちです(1日分の宿泊費だけ自費)。
なお、今回のInterviewで自己紹介に使ったスライドも、ついでにuploadしましたので、ご興味のある方はどうぞ。
更に、今回のInterviewでは結局使いませんでしたが、これまでgithubに載せたプログラムのことなどをスライドに纏めました。ご参考まで。
それにしても、ここ10年ぐらに、英語での会話はあまりしていなかったので、結構冷や汗ものでした。それでも、ある程度、自分のためになった気がします。
【DRL, Montezuma】thread毎多様性の効果確認！(12/7修正)
A3Cをベースにした環境で、Montezuma's RevengeのDeep Reinforcement Learningを行っていますが、thread毎に多様性を持たせた効果が示せました。(12/7訂正)
下記サイト掲載の学習状況をご覧ください。
上記サイトには８個のグラフが掲載され、最初の２つ(gcp10、gcp20)は、全てのthreadが同じパラメーターで学習しています。これらは、途中からSCOREが完全に0に落ち込み、回復していません。参考までに、下記にgcp10のグラフを載せます。
これに対し、gcp30〜gcp80は、thread毎に学習パラメータを変えてあります。下に行くほど、パラメーターの多様性が上ってます。gcp30〜gcp80は、一度0になっても、しぶとく回復しています(12/7訂正。本記事初版ではgcp60のSCOREが完全に0に落ち込んでいましたが、その後回復し、gcp30～gcp80の全てで効果が確認できました)。参考までに、下記にgcp60の例を載せます。
もう少し学習を続けてみるつもりですが、上記で、thread毎の学習パラメーターの多様性が、学習安定化に対して効果があることを十分に示せたと思います。
