コード生成型ロボットの再試行、失敗ラベルに応じたフィードバックの優位性は確認されず

何が起きたか

arXiv掲載論文「Rethinking Self-Repair in Code-as-Policy Agents: What Drives Retry Success?」は、シミュレーション上のロボット操作で、コード生成型エージェントが失敗後に再試行する際のフィードバックを比較した。同じ252件の初期失敗に対し、失敗ラベルとAPIの種類に応じてテンプレートを選ぶ方式は、5回以内に85.3%を復旧させ、同じ再試行上限で再サンプリングする方式の68.3%を上回った。論文は、失敗ラベルに合わせること自体の効果は検出されず、タスクに合わない指示は復旧を損なう場合があると報告した。

詳細

評価では、固定されたルックアップ方式で失敗ラベルとAPIの種類からフィードバックテンプレートを選び、シーンをリセットした後、凍結したコードモデルが新たなプログラムを生成した。モデルはQwen2.5-Coder-7Bで、テンプレート方式の優位性は総トークン数を固定した比較でも維持された。 別の評価では、初回から固定の誘導プロンプトを使う方式の観測全体成功率がテンプレート方式と同程度だった。一方、リム把持が必要なナット挿入タスクでは、中心把持を促す指示とタスクの不整合に沿う形で、テンプレート方式の復旧率が低下した。

Key Facts

本紙の見方

この評価で目を引くのは、失敗に対応したテンプレート方式の復旧率が85.3%となり、同じ再試行回数の再サンプリングの68.3%を上回った一方、失敗ラベルとの一致自体には検出可能な利点がなかった点だ。結果は、再試行時に何らかの追加情報を与えることと、失敗の種類に特化した情報を与えることを分けて検証する必要を示す。総トークン数をそろえた条件でも優位性が保たれたという報告は、単に再試行時に使える生成量が増えたことだけでは説明しにくい可能性を示すが、どの情報が効いたかを特定した結果ではない。 実験は、同一の252件の初期失敗から出発し、シーンをリセットして凍結モデルに新しいプログラムを生成させている。この条件は比較の枠をそろえる一方、実機での継続動作や、失敗後の環境状態を利用する修復を評価したものではない。したがって、数値はシミュレーションで設定された再試行条件における復旧結果として読むべきで、実機の成功率に直接置き換えることはできない。 さらに、別評価で固定の誘導プロンプトがテンプレート方式と同程度の観測全体成功率を示したことは、初回からタスクに沿った指示を与える方法も比較対象に含める必要を示唆する。失敗後の修復だけを切り出すと、そもそも初回から適切な指示で成功できる場合との違いを見落とすためだ。論文が推奨する再サンプリング、失敗と合わないフィードバック、簡潔でタスクに適合した固定誘導との比較は、特定のフィードバック方式の効果を見分けるための評価設計に関わる。 ナット挿入ではリム把持が必要なのに、中心把持を促すテンプレートが使われ、復旧率の低下と整合した。これは、失敗ラベルを分類できても、そのラベルに結び付いた指示が実際の操作要件と合わなければ修復を助けないことを示す個別例である。今後の評価では、タスクごとの把持要件とテンプレート内容の対応、異なるタスクでも同じ傾向が出るか、シミュレーション外での再現性を確認する必要がある。論文の要旨からは、各方式のタスク別の詳細な数値や実機での検証結果は確認できない。

なぜ重要か

論文の比較では、失敗ラベルに合わせたテンプレート方式は再サンプリングを上回ったが、ラベル一致の効果は検出されず、タスクに合わない把持指示では復旧率が低下した。コード生成型ロボットの修復機能を評価する際は、再試行回数だけでなく、指示が操作要件に適合しているか、固定のタスク誘導や再サンプリングと比べて何が改善したかを分けて確かめる必要がある。