本文へスキップ

ガイド

強化学習

Oloproof は強化学習の方策を、エピソード単位で実行するか、その方策が置き換える方策のログから評価します。実行できる場合は実行し、結果が現実の世界でしか生じない場合はログを使います。このページは両方のリファレンスであり、チュートリアルでは、実行可能な例でそれぞれを順に説明します。

Oloproof は環境のホスト、リセット、シミュレーションを行わず、方策の学習も行いません。Oloproof が評価するすべてのシステムが自身のコードを実行するのと同じように、あなたのシステムが自身の環境を実行します。

エピソード

タスクは 1 つのケースです。エピソードはその 1 回の測定です。あなたのシステムが環境の中で方策を実行し、current_case().rl_episode(...) でエピソードを rl_episode/v1 アーティファクトとして記録します。

フィールド型意味
stepsステップのリスト、index は 1 から各ステップの reward、その制約の cost(デフォルト 0)、そして任意で action と observation
successtrue、false、または省略エピソードに対する環境自身の判定
truncated真偽値、デフォルト false終端状態に達する前に、ステップ上限がエピソードを終わらせた
horizon整数、任意ステップ上限。エピソードはこれより長くなれません

レコードはエピソードのすべてのステップを保持します。打ち切られたエピソードとは、評価のプロトコルがその上限で終わると定めたエピソードです。そのため、そのリターンとコストは下限ではなく完全な値です。

システムが記録する種類を宣言してください。そうすれば、システムが一度も書き込まないレコードを必要とする評価器を、実行が拒否できます。

system:
  name: grid-agent
  callable: env:run_baseline
  records: [rl_episode/v1]

エピソードの評価器

型測定するものフィールド
episode_returnリターン(各報酬をステップごとに discount で重み付けしたもの)をスコアとしてreturn_range(必須)、discount(デフォルト 1)
episode_successエピソードが success: true を記録していれば合格。何も記録していなければ欠測なし
episode_cost_within各ステップのコストの合計が budget 以下なら合格budget(必須)

return_range はすべてのリターンが収まる範囲です。たとえば、最悪で 30 ステップそれぞれ -1、最良でゴールの報酬です。平均リターンの区間はその範囲の内側でのみ成り立つため、範囲外のリターンは終了コード 2 で実行を停止させます。SDK では、クラスは oloproof.evaluators の EpisodeReturn、EpisodeSuccess、EpisodeCostWithin です。

タスクごとに複数のエピソード

replicates: を設定すると、すべてのタスクで複数のエピソードを実行します。current_case().replicate は実行中のエピソードがどれか(最初は 0)を示し、保存される実行のキーの一部です。そのため、これをもとにエピソードのシードを決める環境は、同じ反復に対して同じエピソードを再現し、2 回目の実行は保存済みのものを再利用します。

単位はタスクのままです。各基準は、各タスクのエピソードにわたるそのタスク自身の平均を、タスクにわたって平均したものになり、区間はタスクを数えます。1 つのタスクの 5 つのエピソードは、5 つの独立したタスクではありません。

反復したタスクにわたる合格率は、各タスクで合格したエピソードの割合を読みます。代わりに、タスクが毎回合格するかどうかを問うには、every_replicate メトリクスを宣言します。

metrics:
  - {id: solved_every_time, type: every_replicate, criterion: episode_success}

タスクはそのエピソードがすべて合格したときにだけ数えられるため、各タスクは 1 つの合格または不合格となり、正確な二項区間が適用されます。タスクごとに 1 エピソードの場合は合格率と等しくなります。欠測のエピソードを持つタスクは、別のエピソードが不合格であっても欠測です。

2 つの方策を比較する

oloproof compare は各タスクをそれ自身と対にし、各側の値はそのエピソードにわたる平均です。リターンの差はリターン自身の単位で、合格率の差はパーセントポイントで示されます。2 つの実行はタスクごとに異なる数のエピソードを実行してもかまいませんが、every_replicate メトリクスは例外です。5 つのエピソードすべてで成功することと、ただ 1 つのエピソードで成功することは別の問いなので、その比較は計算されません。どちらかの実行がタスクごとに複数のエピソードを持つ場合、分位点とランキングの比較は計算されません。

オフポリシー評価

関心のある結果が現実の世界でしか生じず(チケットが解決された、ユーザーが戻ってきた)、新しい方策を実際のトラフィックでまだ試せないときに使います。エビデンスは、古い方策が行った決定のログです。

各ケースは記録された 1 つの決定です。

{"id":"t001","input":{"topic":"technical","length":"short"},"expected":{"action":"small","logging_probabilities":{"small":0.7,"large":0.3},"reward":1}}
フィールド意味
input決定したときに方策が見たもの
expected.actionロギング方策(logging policy)が取った行動
expected.logging_probabilitiesその時点でロギング方策が各行動に与えた確率。合計は 1
expected.rewardその後に続いたもの。reward_range の内側。届かなかった場合は省略

システムは評価したい方策です。input を受け取り、各行動に対するそれ自身の確率を probabilities、または probabilities_field で指定したフィールドの下に返します。モデルを実行することも、現実の世界に触れることもありません。input には、ロギング方策が決定したときに見たものだけを入れます。記録された行動や報酬は決して入れません。テスト対象の方策はそれらを見てはなりません。選択をサンプリングする方策は、引いた行動ではなく、サンプリングのもとになる確率を返します。各決定は、入力が繰り返されても新たに評価されます。行動はログでの名前とまったく同じに名付けます。綴りの異なる行動は、ロギング方策が一度も取らなかった行動として数えられます。

型推定するもの
off_policy_value記録された決定に似た決定における、方策の平均報酬
off_policy_improvementその平均から、ロギング方策自身の平均を引いたもの

どちらも reward_range と propensity_floor を取ります。propensity_floor は、新しい方策が取りうる行動に対してロギング方策が与えた確率のうち、最小のものです。ロギング方策がどう設計されたか(探索率、最小の割合)から設定し、ログで値を試して決めてはなりません。記録された各決定は、その行動に対する新しい方策の確率をロギング方策の確率で割った値で重み付けし直され、この下限がその重みを抑えます。下限がなければ、どの区間も成り立ちません。SDK では、クラスは OffPolicyValue と OffPolicyImprovement です。

エンジンが、与えられたとおりに読めない決定をどう扱うか:

状況結果
合計が 1 にならない確率、確率 0 で記録された行動、reward_range の外の報酬終了コード 2 で実行が停止します。誤った確率は、それを示すことなく区間を誤らせるからです
新しい方策が、下限未満の確率で記録された行動を取りうるその決定は欠測となり、最悪の値で抑えられます
報酬がないその決定は欠測となり、最悪の値で抑えられます

答えが前提とすること:

  • 確率はロギング方策が決定したときに記録されたもので、それが実際に使った確率です。Oloproof がそれらを推定することはありません。
  • 各決定の報酬は、それ自身の入力と行動に依存し、他の決定には依存しません。
  • ロギング方策は、ログの期間を通じて同じ確率を保っていました。
  • 答えが述べるのは、ログがカバーする期間における、記録された決定に似た決定についてです。

下限が小さいと区間は広くなります。まれにしか選ばれない行動について情報を与える決定は少なく、それぞれが何倍にも数えられるからです。ログを長くすること、そしてより多く探索するロギング方策が、区間を狭めます。

未実装のもの

  • 各選択が次に起こることを変える、一連の決定のオフポリシー評価。
  • 期間中に学習しながら確率を変えた方策のログ。
  • 事後に推定した確率。
  • 環境やシミュレーターのホストやリセット。

次に読むページ