NIPS2017論文読みメモ: Inverse Reward Design(その1)

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

Dylan Hadfield-Menell, Smitha Milli, Pieter Abbeel, Stuart Russell and Anca Dragan. Inverse Reward Design. arXiv: 1711:02827, 2017. https://arxiv.org/abs/1711.02827
※ 以下、キャラクターが会話します。それぞれの原作とは関係ありません。論文内容の解釈誤りは本ブログ筆者に帰属します。
次回: その2
f:id:cookie-box:20180101155919p:plain:w60

強化学習エージェントを学習させるときの報酬関数って実はちゃんとわからないから、「報酬関数は『真の報酬関数』のある観測結果に過ぎない」という前提で学習させようという話みたいだねー。共著者に連なっている Russel や Abbeel は「逆強化学習」の定式化やその解法である「見習い学習」を提唱した人だにゃー。「これからの強化学習」の2.3節に載ってるね。

f:id:cookie-box:20180101155951p:plain:w60

強化学習の報酬の話ですか。Sutton の強化学習本には、「報酬を最大化することでエージェントが我々の目的を達成してくれるように報酬を与える必要がある」とありました。チェスをプレイするエージェントは勝負に勝ったときのみに報酬を得るべきであって、敵の駒を取ったときなどに報酬を与えると勝ちにつながらない駒取りばかりするおかしなエージェントになりかねないとか…。

f:id:cookie-box:20180101155919p:plain:w60

そーそー。そーいう報酬関数の設計ミスによる悪影響をこの論文では「(未特定の報酬による)ネガティブサイドエフェクト」と「報酬ハッキング」の2つ挙げているね。前者は考慮漏れにより望まないふるまいが引き起こされること、後者は報酬自体が望まないふるまいを引き起こすことっぽいかなー。いま瑞希ちゃんが言ってくれたのはまさに「報酬ハッキング」の例だねー。報酬ハッキングとして本文に挙げられている例は、

  • 「ゴミを吸引すること」に報酬を与えられたお掃除ロボが、ゴミをもっと吸引するために一度吸引したゴミを外に出してしまった。
  • 標的を撃ち落としながらゲームを周回するボートレースゲームで、標的を撃ち落とすことに報酬を与えたら、標的をずっと撃ち続けてコースを周回してくれなくなった。

f:id:cookie-box:20180101155951p:plain:w60

…なぜお掃除ロボが自らゴミを外に出せるような設計になっているのでしょうか。…そんな機能要らないぞ。

f:id:cookie-box:20180101155919p:plain:w60

…きっとロボで掃除したい場所がすごいごみだらけで、満杯になったごみをごみ箱に捨てるって行動も学習させたかったんじゃない? だから自分でゴミを外に出す機能も付けておいたんじゃないかなー。話を戻すと、もう1つの報酬による悪影響である「ネガティブサイドエフェクト」の例は、宝探しロボットに草むらを避けてほしくて草むらを進むことにマイナスの報酬を与えたら、草むらを避けて溶岩に突っ込んじゃったって(論文に挿絵が載ってるね)。溶岩に出くわすとわかっていたら溶岩には草むらよりもっと大きなマイナスの報酬を与えていたけど、想定していなかったってことだね。

f:id:cookie-box:20180101155951p:plain:w60

なるほど。でも、溶岩に出くわすレベルで想定外な事態は、チェスのエージェントには起こりえないと思います。ルールは、決まっているから。そもそも、「勝ったときに報酬を得る」というトリビアルな報酬デザインができるので、ネガティブサイドエフェクトや報酬ハッキングに悩まされる余地はありません。

f:id:cookie-box:20180101155919p:plain:w60

それはそーだよねー。でも、「これからの強化学習」の2.3節にあるように、一般に「目標状態や終端状態にだけ定義された報酬によって学習することは難しいことは多い」んだ。それは、状態空間が広い場合、まず初期方策からはじめて目標の終端状態にたどり着くのに時間がかかるのと、たどり着けてもだから序盤どう行動するべきかまでわかるにはまた時間がかかるんだよね。それに、もし終端状態に報酬を与えるだけでじゅうぶん学習できるだけの状態数だったとしても、一般的なタスクの終端状態は「勝ち or 負け」のようにシンプルじゃないよね。「まあまあよい終わり方」とか「もっとよい終わり方」とかあって、それらをどう評価するかはやっぱりトリビアルじゃないと思う。

f:id:cookie-box:20180101155951p:plain:w60

そうですね。一般的には報酬をどうデザインするべきかはトリビアルでなく、考慮漏れによるネガティブサイドエフェクトや、報酬の与えどころの誤りによる報酬ハッキングが起きかねないというのは理解できます。それで、この論文はどのようにしてこの問題に対処するというのでしょうか。

f:id:cookie-box:20180101155919p:plain:w60

それはねー、もう真の報酬がわからないことを認めるんだ。ヒトがデザインできるのはあくまでプロキシ報酬(代理報酬)で、真の報酬は推定しなければならない。マルコフ決定過程、プロキシ報酬関数、報酬関数候補の集合を所与として真の報酬関数を推定する問題をIRD: Inverse Reward Design(逆報酬デザイン)と定義するよ。

f:id:cookie-box:20180101155951p:plain:w60

待ってください。真の報酬がわからないというのはいいです。それはむしろ自然だと思います。でも、真の報酬がわからないのに真の報酬を推定するということができるのでしょうか。

f:id:cookie-box:20180101155919p:plain:w60

プロキシ報酬がある程度真の報酬に近いとか、エピソードが選択される確率が「最大エントロピー」の分布にしたがうとかの仮定は置くけど、事後分布を効果的に近似することができるみたいだよー。ここから先は式を追っていった方がいいかにゃー。

つづく