NIPS2017論文読み会に参加するので論文を読みたいと思います。今回読むのは以下です。

前回までに、逆報酬デザイン=IRD の問題定義とその解、それに近似解の求め方をみてきました。IRD は環境モデル およびプロキシ報酬関数=なるべく上手くデザインした報酬関数を所与として、真の報酬関数の分布を求める問題として定式化されます。そして、以下の仮定をおくと真の報酬関数の分布を式に表すことができます。
- 報酬関数
は、エージェントがたどった行動系列
の特徴量ベクトル
を用いて
とかける。
が成り立つ。この式は、真の報酬が
のときプロキシ報酬
がデザインされる確率です。どんな
がデザインされやすいのかというと、
をつかって学習した方策にしたがって行動したときの真の報酬の期待値が高ければ高いほどデザインされやすいです。確率は真の報酬の
倍のエクスポネンシャルに比例します。
はどれくらいよい設計ができるかのパラメータでした。
は報酬関数を設計するエンジニアの腕がよければ高いかもしれないし、タスクに不確定要素が大きければ低いかもしれませんね。
- 積分を有限個のサンプル
の和で代替する。
- プロキシ報酬から真の報酬の分布を求める IRD を、手本となる行動系列セットから真の報酬を求める IRL に翻訳する。このとき、あるプロキシ報酬から得る「お手本」は行動系列の特徴量ベクトル
の期待値として丸められる。

前回までのあらすじありがと。今回読むのは実際に IRD で強化学習タスクを解くとどうなるかを検証するセクションだねー。あたしの好きな実験だよ♪ 今回チャレンジするタスクは、格子世界での最短経路探索だね。

格子世界、Sutton 本でもよく出てきました。風が吹く格子世界とか、崖がある格子世界とか…。

今回のもそんな感じだねー。東西南北4方向に移動できて、各地点は「宝物」「草むら」「土」「溶岩」のいずれかだよ。論文5ページの絵の一番左と真ん中を見てほしいかな。黄色が宝物で、緑が草むら、茶色が土、赤が溶岩だね。草むらは土よりも通りにくいみたいで、草むらの上を通る距離は最小限にしつつ宝物まで最短経路で到達したい。ただし、溶岩は即死だから絶対避けないと駄目。だけど、当初は溶岩の存在は想定していなくて、プロキシ報酬には溶岩が考慮されていない。5ページの一番左の絵がプロキシ報酬を設計するのに用いられた環境だね。プロキシ報酬は、ひとまずこの環境で意図通りのパス(絵の中の灰色のパス)を学習するように設計された。たぶん、最短で宝物までたどり着いてくれるように、宝物でないマスは-1、草むらのマスはさらにもう少しマイナスみたいな報酬になったんじゃないかにゃー。

草むらの上を進む距離が最短になるように、スタート地点から宝物のある真東に進むのではなくて、少し南に迂回していますね。

こんな風に、溶岩のない環境で設計したプロキシ報酬関数で、溶岩のあるテスト環境の最短経路を探索するのが今回の実験だよー。今回検証してみる環境は以下の4つ。最初の2つが、報酬の設計ミスによる悪影響を回避できるかの検証で、後の2つがより現実的でチャレンジングな例という位置付けみたいだねー。
- 溶岩を未定義の状態と認識する環境(ネガティブサイドエフェクトを回避できるかの検証)
- 環境からは各マスのカテゴリが2つのシグナルで知らされるという前提で、溶岩については、一方のシグナルは宝物、もう片方のシグナルは草むらと告げる環境(報酬ハッキングを回避できるかの検証)
- 各マスが土とか草とかの手がかりがなく、特徴量が確率的にしか観測できない環境―プロキシ報酬設計時に、観測された特徴量を用いて直接報酬を設計する場合
- 各マスが土とか草とかの手がかりがなく、特徴量が確率的にしか観測できない環境―プロキシ報酬設計時に、まず観測された特徴量によって土か草か宝物かの3クラス分類を行い、各クラス値に対して報酬を設計する場合

溶岩の存在を想定しておらず、想定していなかった状態への対策を何も講じていなければ、そうなってしまいますね。では、IRD ではどうなる?

IRD では真の報酬はわからないことを悟っているから、プロキシ報酬を妄信することはないね。まず、いまもっているプロキシ報酬 と、それを設計した環境
をもとに、真の報酬を推定してみる。すると、溶岩を含むパスの報酬がとても不確かなことがわかる。プロキシ報酬を設計した環境において、溶岩の報酬をいくつにしようと同じ学習結果をもたらしてしまうからね。それで、ここまで触れていなかったんだけど、IRD には「リスク回避計画」を組み合わせてつかうんだ。報酬の不確定さが大きい行動は避けるってことだと思う。詳しくは Appendix に載ってるね。

結局そのような計画が要るのですか。…何だか、それって、「知らない状態に出くわしたら回避しなさい」とエージェントに教えておけば済む話ではないのでしょうか。

まーこの例だとそうだよねー。でも、一般的には、知っているか知らないかの0か1じゃない。「どれくらい知らないか」を定式化したのがこの論文だよね。それに、報酬関数を最初に固定しない立場をとることで、エージェントが自動的に報酬関数を書き換えて成長していく枠組みへの示唆を与えていると思う。

…確かに、知らない状態を避けろといっても、知らない状態とは何なのか、具体的にどうやって避けるべきかを考えなければならないですね。

2つ目の実験は、報酬ハッキングの検証だね。このシチュでは、エージェントにマスの状態を告げるシグナルが2つあるってする。報酬を設計した環境では、土のマスだったら2つのシグナルはどちらも「土」、草のマスだったらどちらも「草」、というように両方とも正しいシグナルになっていたんだけど、テスト環境では溶岩のマスについて片方のシグナルは「宝物」、もう片方のシグナルは「草」となっちゃうんだ。溶岩という未知の状態に、ロボットのセンサがバグっちゃったのかもしれないねー。

すみません、話が見えないのですが、シグナルがそのようにバグっているとなぜ報酬ハッキングの検証になるのでしょうか。

話を端折っちゃったね。報酬ハッキングは、報酬をデザインした環境では釣り合っていたバランスが、デプロイ環境では崩れるときに起きちゃうんだよね。ボートレースゲームの例だと、報酬をデザインした環境では標的を撃ち落とすことにある程度の報酬を与えることがゲームに勝つことにつながっていたんだけど、デプロイ環境ではそうならなかった。今回のテスト環境だと、報酬をデザインした環境では、2つのシグナルの内容がそろっていたんだけど、デプロイ環境ではちぐはぐになった。だから学習が上手くいかなくなるんだけど、上手くいくようにするためには、一つの報酬源に賭けないでほしいんだよね。ボートレースゲームの場合だと、標的を撃ち落とすことって、中間目標あるいはWANTであってMUSTでない目標なのかなって思うんだけど、そういう目標だけから報酬を得るのをやめてほしい。今回のタスクでは、一方のシグナルに賭けないでほしい。それで、IRD は、2つのシグナルがちぐはぐっていう特徴の報酬が不確かなことに気付くから、結局溶岩を回避できる。

…もし IRD をボートレースゲームに適用できるなら、「ゲームに勝つことによる報酬ではなく、標的を撃ち落とすことによる報酬ばかり稼いでいるのは、報酬をデザインした環境のようすと違って何かおかしいぞ」とエージェントが気付ける、のでしょうか。

そんな感じだと思う。残り2つの実験については、次回にするねー。次で最終回にしたいにゃー。