Pythonで学ぶ強化学習 -一問一答-
Pythonで学ぶ強化学習の発売から約1カ月となりました。
多くの方に手に取っていただいているようで、著者としてありがたい限りです。受け取ってばかりなのも申し訳ないので、読者の方から質問を募集し、回答することにしました。本記事では、頂いた質問に一問一答の形式で回答していきたいと思います。なお、執筆にあたっては実際頂いた質問の統合、また要約を行っています。
Q: 電子版は出ないのでしょうか?
A: 今日(2/22)出ました！
お待たせしました。提出した原稿は当然電子なのですが、そこでは参考文献などについて全部リンクを張っています。それが再現されていると嬉しいのですが・・・もし、買われた方がいればご連絡いただければありがたいです！
Q: A2Cの実装で、なぜ分散収集を採用しなかったんですか？
A: コードが複雑になりすぎると判断したためです。
本書のA2Cの実装は、実際のA2Cと異なりDQNと同様Replay Bufferを使った実装になっています。分散環境による経験収集は進化戦略の実装でほぼ同じことをやっているのでできないことはなかったのですが、A2Cの解説では「戦略をDeepにする」という章の目的に解説の中心をあてたいと思いこのような実装にしました。
他の背景としては、A2Cで分散実行するならRayを使いたかったというのがあります。
分散収集は、論文ではもう一般的なテクニックになりつつあります。では実装でも一般的に取り入れられるようになった場合、何が実装フレームワークとして使われるだろう？と考えたときRayではと思ったのです。読者に届けるならRayベースの実装だけれども、さすがにRayの解説/実装入れたらボリューム的にパンクするでしょ、となって丸ごと省いたという側面もあります。Rayはまだ使ってないので、使ってみたいです。
Q: 機械学習スタートアップシリーズの既刊と、書体が異なっているのは、何か理由があるのでしょうか。
A: 読みやすいフォントを提案していただき、それを使いました。
原稿はメイリオで書いており、それが見やすかったので近いフォントをお願いしました。そうしたところ編集の方から幾つかサンプルを提案していただくことができ、その中から一番読みやすいものを採用しました。読みやすかったら幸いです。
Q: TD(λ)法の説明で、各stepにおける実際の価値に(1-λ)を掛け算しているのは何故でしょうか。
A: 各stepにかける重みの総計を、1にするためです。
TD(λ)の目的は、各stepの価値を組み合わせることです。その場合、組み合わせの配合率は合計1になることが好ましいです。これは計算上のトリックになりますが、1-λをかけることでこれを実現できます。図解としては、以下がわかりやすいです。
右上に「total area=1」とありますが、各stepにかかる重みを合計していくと総計1になります。
なお、この質問で改めてTD(λ)を調べたのですが、書籍中のTD(λ)の式に誤りがありました。正しくは以下となります(これについては、後の版で修正予定です)。
書籍の式だと右側の項がない状態なので、TD(1)の時ゼロになってしまいます。連続時間の場合(Continuous)は永遠に続くのでなくてもいいのですが、終点がある場合(Episodic)の場合は、終点における価値を切り出す必要がありました。
Q: 行動の最適化における制御について、ロボット及びインフラ(電力)の制御を例として挙げられています。インフラの事例は何かあるでしょうか?また、その際の報酬設計などはどのようになるのでしょうか。
A: 実用化されているかわかりませんが、研究は進んでいるようです。
電力プラント制御に強化学習を適用する研究はちらほらとあり、”Reinforcement Learning for Electric Power System Decision and Control: Past Considerations and Perspectives”に既存の研究がまとめられています。プラントで強化学習、というと完全自動プラントのような姿が思い起こされますが、実際は「制御」という問題をもう少し細かく分けています。その問題設計は”Real-time computer control of power systems”にて提案されています(1974年なので、出自は古い)。
Eは需要/供給のバランス、Iは機器への負荷を表しているようです。バランスが崩れたら修復(Restorative control)、機器が壊れたら緊急対応(Emergency control)、危なそうなら予防措置(Preventive control)といった形で問題が分けられています。Reinforcement Learning for Electric Power~では、この観点で既存の研究を分類しまとめています。報酬設計は、もちろん問題ごとに異なってくると思います。
強化学習ではゲームの環境が多いですが、こうした実際の問題に近い環境も出てくればなと思います。
Q: A2C、PPOについて質問です。A2CにPPOのような制約を設ければそれはA2CではなくPPOと呼ばれるものになるのでしょうか。
A: PPOになると思います。
PPOの定義でAdvantageが登場するため、Advantageを算出する機構=Actor Criticは前提と思われるためです。こちらの記事では、明確に”PPO is based on Advantage Actor Critic.”と書いてあるぐらいです。
Q: Policy Gradient の所でどこでNNが学習してるのかが分かりません。K.backend.function の所ですか？
A: その通りです。
K.backend.functionは入力/出力(loss)に加えupdates=重みの更新を含むことができ、実行により更新まで行うことが可能です。しれっと書いていますが、私も最初はこの挙動がちょっと不思議でした。
Q: Policy IterationとValue Iterationの、収束速度の違いについて教えてください。
A: Policy Iterationの収束速度が常に速いわけではありません。
ここはレビューでも指摘されていた点で、表記は新版が出る際は改めようと思います。収束速度についての記述に続く文で、「一方でPolicy Iterationは戦略が更新されるたびに価値を計算しなおさなければならないというデメリットがあります」とあるように、Policy Iterationのデメリットが大きく出る場合収束速度は遅くなります。
Q: Value Iterationの実装でsの価値を順番に更新していますが、順番の遅いsに関してはすでに更新済みのsがnext_stateとして計算に含まれてはしまわないのでしょうか?
A: 含まれますがOKです。
最初のsの更新よりも、最後のsの方が更新済みのV[s]が使えます。そのため、最後のsの方が正確、という見方ができると思います。ただ最終的な更新の停止は delta の最大値で決定されるため、最初でも最後でも更新幅が小さくならないと停止されないようになっています。
Q: policyの訳語が統一されていないのには意図があるのでしょうか、policy自体は「戦略」、policy gradientは「方策勾配法」、on-policyは「on-policy」となっていて、やや気になりました。
A: 基本的には「戦略」で通していて、手法名として定着しているものはそのまま残しています。
本書では、基本的にはpolicy=戦略としています。その一方で「無理に日本語に訳さない」「日本語にする場合は、十分定着しているものを使う」というスタンスも取っています。そのためon-policyを「戦略オン」とかにはせず、「方策勾配法」をあえて聞き馴染みのない「戦略勾配法」にはしなかった、という形になります。このため表記がちょっと混じる形になってしまいましたが、そんなポリシーが背景になります。
質問回答は以上となります。質問を受けて改めて調べたところもあり、個人的にも勉強になりました。読む際の参考になれば幸いです。
