RPG: 練習の変更を実機へ届かせずに、ロボットのスキルライブラリを改善する

残してよい変更を、どう決めるか

ロボットの改善は、よりよいモデルとして説明されがちです。10月1日に投稿された Reconstruct, Practice, Go Real（RPG）は別の問いを扱います。モデルの重みを変えず、実行系の記号的なスキルライブラリと system prompt をどう改善するかです。要点は、agent がコードを直せることではありません。変更を提案する役、失敗を診断する役、共有された変更を残してよいか決める役に、それぞれ別の根拠を割り当てています。

これは、シミュレーションで合成可能なスキルライブラリを成長させた2024年の Lifelong Robot Library Learning とつながる見方です。RPG は運用上の問題をさらに狭めます。候補の修正は共有基盤への変更なので、修正の発端になった一つの課題だけでは判定できません。この系譜は、育つライブラリという考え方の由来です。両者のデータ、ロボット、結果が同じことを示すものではありません。

1. 1オフライン軌跡と課題説明
2. 2固定したシミュレーション練習課題を構成

1. 1Runtime Agent: ロボットから見える観測
2. 2記号的スキルを呼ぶ
3. 3実行記録

1. 1Privileged Agent: 同じスキル + simulator state
2. 2診断だけに使う参照記録

1. 1記録と固定評価器
2. 2スキルまたはpromptの変更候補
3. 3課題横断の判定

1. 1採用されたシミュレーション変更
2. 2固定した配備候補
3. 3別途の実機安全審査

これは原論文を読むための独自の図です。特に Privileged は重要です。シミュレーションで診断を助ける情報であって、実機が受け取れると仮定してよい情報ではありません。「背の高い物を置く」のようなスキルは役立つ手順になり得ますが、手順だけではありません。課題の評価器、初期状態の分布、センサー、制御の接続、停止方針がそろって初めて、ある環境で意味を持ちます。

役割を分けてから改善と呼ぶ

RPG はオフラインデータセットから練習課題を作り、練習前に課題と結果判定器を固定します。Runtime Agent はロボットで得られる観測を使って再利用可能なスキルを選び、組み合わせます。別の Privileged Agent は同じモデルとスキルを使いますが、simulator state も見ます。Video Analyzer は両者の記録と、存在する場合のデータセット動画を比較します。Implementor は一つずつ変更を提案し、Merger は適格な変更を統合します。これらは著者の実験上の役割であり、製品の権限制御の設計図ではありません。

大切なのは情報の通り道です。

役割	シミュレーション練習で使えるもの	実機で前提にしてはいけないもの
Runtime Agent	ロボットから見える観測、スキルの戻り値、実行履歴	隠れた物体姿勢、評価器の内部状態
Privileged Agent	同じ入力に加え、診断比較のための simulator state	実機での simulator state
Analyzer / Implementor	記録済みの軌跡と固定した課題契約	実機を動かす権限、自分の変更を黙って採用する権限
課題横断の判定	固定した課題群での完了結果	安全証明、実世界での一般化の証明

この分離は、調査の焦点を絞ります。Privileged 側が成功し Runtime 側が失敗するなら、欠けた情報や知覚の接続が原因候補です。両方が失敗するなら、共有スキルか課題契約が疑わしいかもしれません。ただし、どちらも因果を証明しません。「ロボットをよくして」と汎用モデルに頼むより、調べる対象を狭くできます。

論文中の判定は具体的です。候補を練習課題群全体で評価し、平均成功が上がることを求め、固定した五つの開発試行で各課題の成功回数の減少が一回以内に収まる候補だけを通します。統合後にも再評価します。これは著者が用いた simulator、seed、評価器、モデル、予算の下での回帰判定です。普遍的な採用基準でも、安全性の証明でもありません。

報告された結果が示す範囲

論文は、15回の練習後に22課題の保留初期状態220 episodeで209成功だったと報告しています。また、共通の calibration と hardware adaptation の後、三課題・計30回の実機試行が成功したと報告しています。どちらも著者による測定であり、この教材のロボットでの独立再現ではありません。

転用には限界があります。練習の一方の agent は診断のために privileged simulator state を使いましたが、配備時の Runtime は使いません。実機評価は YAM robot、固定の課題基準、各課題10試行、定めた reasoning/call budget、初期配置の手動再現、著者の calibration と adaptation に依存します。project page はコードを “coming soon” としており、この確認では、実行可能な repository、ソフトウェアライセンス、重み、データセットライセンス、controller 設定、安全承認は確認できません。映像や整った集計表は、この欠けた条件を補いません。

論文はシステム全体の曲線と、ライブラリだけを比べた比較も分けています。この分離は将来の作業でも必要です。prompt、知覚の使い方、モデル呼び出し、スキル、課題分布が同時に変わり得るため、全体の成功率が動いても原因を一つには絞れません。著者の保留評価の曲線も単調ではなく、開発時の判定が後の回帰を取り逃す場合があることを示しています。

未実行の N=1 ワークシート: 一つの変更、一つのオフライン境界

RPG の再現やロボット操作から始めません。既に記録された、作動させないシミュレーション episode 一つ、または合成した記録一つを使います。以下はこの教材のための独自設計であり、実行していません。

1. 初期状態ID、許可する観測項目、記号的スキル名、成功条件、停止の責任者からなる課題契約を一つ書きます。hidden simulator state 由来の項目をすべて印し、Runtime 列では読ませません。
2. pick の後に verify_grasp を加えるなど、変更候補を一つ選びます。同じ保存済み初期状態で baseline と候補の記録を残します。prompt、評価器、モデル版、action interface は同時に変えません。
3. event index、Runtime から見える観測、スキル呼び出しと戻り状態、評価器の結果を四列で残します。診断メモでは hidden state を引用してよいですが、候補の Runtime 入力へ入れてはいけません。
4. 合格の問いを先に決めます。この一つの記録で、候補が baseline の成功条件を保ち、指定した失敗を新たな違反なしに改善したかです。結果は candidate_supported_for_offline_review、rejected、unknown のいずれかだけにします。
5. 評価器がない、状態を reset できない、変更に Runtime で privileged field が必要、結果を実機の根拠に使う、のどれかなら停止します。停止記録を残し、別環境への切替や条件の緩和でやり直しません。

このワークシートは、論文の課題横断結果、安全な把持、Sim2Real transfer、実機を動かす許可を示せません。隠れた状態の境界と、提案した変更を、プログラムの権限を増やす前に見える形にするためのものです。

配備判断には別の責任者が必要

RPG は実機評価の前に実行系を固定し、ロボットが動いている間に Privileged Agent や Video Analyzer を使いません。実運用でもこの分離を守りつつ、論文の評価だけでは与えられない制御を足します。承認された動作範囲、emergency stop の担当、力と速度の上限、立入区域、reset 手順、観測喪失時の扱い、責任を持つ運用者です。シミュレーション課題を受理する評価器は、人や物にロボットを近づけてよいと決める人や仕組みではありません。

共有スキルライブラリで残すべき成果は、「学習したロボット」ではありません。base version、変更差分、課題と評価器の版、Runtime と Privileged の入力、記録、回帰結果、未解決の失敗、実機は対象外という明示的な判断を揃えた revision packet です。それがあれば、次に必要なのがデータ、simulator 契約、コードレビュー、別途承認された安全試験のどれかを、後のレビューで決められます。