実世界展開における汎用ロボットポリシーの評価方法

ロボティクスにおける基盤モデルは目覚ましい進歩を遂げました。現在の最良のシステムは、自然言語による指示に従って、多様な物体の把持・配置・選別・操作を行うことができます。しかし、これらのモデルがより高度になるにつれて、厳密に評価することが分野全体で最も解決が難しい課題の一つとなっています。本ブログ記事では、その主要な問題点と、私たちが提案する解決策について紹介します。

現在のベンチマークの限界

実世界でのテストは費用がかかり、時間がかかり、再現も困難です。ロボットの実世界における性能を十分に評価するためには、現実的な代替指標が必要です。シミュレーションこそが、大規模なロボットの評価を行うのに最適な場所です。しかし、既存のベンチマークにはいくつかの重大な課題が共通して存在します。

学習と評価における視覚ドメインの重複

まず第一に、ポリシー（方策）の学習と評価に用いられるデータや環境は、ほぼ常に同じ視覚ソースから得られています。モデルをシミュレーションデータで微調整し、同じシミュレーション環境で評価した場合、高い性能を示すのは単にその設定を記憶しただけであり、一般化できることを示しているわけではありません。これは、シミュレーションの画質がまだ実世界の画像観測と同等レベルに達していないため、ロボット評価における重要な課題として残っています。

Real2sim（実世界からシミュレーションへ）のアプローチは、Gaussian Splatting などの技術を用いて実世界の画像から写実的な環境を再構築することでこの問題を解決しようとしています。しかし、シーンごとのセットアップに1時間以上かかる場合があり、大規模なテストには現実的ではありません。

図 1. 既存のシミュレーションベンチマークは、視覚的・タスク領域での重複が多く、リアリティが低く、シーンやタスク生成に多大なコストがかかるという課題を抱えています。従来の手動によるプロシージャルなシーン生成ではレンダリング品質が低下しやすく、実世界との間に大きな視覚的ギャップが生じます。一方、3D 再構築（3DR）環境は、インペインティングやガウシャン・スプラッティングなどの手法を用いてシミュレーションにリアリティをもたらしますが、その分、各シーンを生成するために必要な人的コストが増大する傾向があります。

ベンチマークの飽和

さらに、タスクを生成するのは退屈で手間のかかる作業です。多くのベンチマークでは固定されたタスクセットが用いられ、ほとんど更新されません。その結果、すぐに性能飽和に陥ります。モデルは静的なタスクセットでスコアを最大限に引き出すだけで、どのモデルが本当に能力が高いかを区別できなくなります。すべてのシステムが同じベンチマークで 90% を超える成功率を報告するようになると、数値自体の意味は薄れてしまいます。

図2. ほぼすべてのモデル論文がこのベンチマークで結果を報告していますが、飽和状態にあるため、モデルの性能について意味のある結論を引き出すことが困難です。

診断のギャップ

さらに深い診断上の課題もあります。単なる成功・失敗の二値スコアでは、ロボットがなぜ失敗したのかという理由が説明できません。物体の色に混乱したのでしょうか？指示文の表現の問題だったのでしょうか？カメラ位置のズレが原因だったのでしょうか？それとも、特定の言語指示に従って効率的にタスクを完了できたのでしょうか？これらの問いに対する答えがない限り、研究者は具体的な改善策を打ち出すことができません。

統計的な信頼性

すべての物理エンジンやポリシーには、何らかの不確実性（確率的要素）が含まれています。N 回のロールアウトにおける単一の成功率を見ても、そのポリシーの真のパフォーマンスに対してどれほど自信を持てるかを知ることはできません。もしあるポリシーが10回中9回成功したとしても、それは「90% の成功率を持つポリシー」なのでしょうか？それとも、小さなサンプルでたまたま幸運だった80% や 95% のポリシーだった可能性はないのでしょうか？この点を検証するために、私たちは Clopper-Pearson 法を用います。

Clopper-Pearson 法は、二項分布から直接計算される「正確な」手法で、成功率の信頼区間を構築します。具体的な例を見てみましょう。70 回のロールアウトで観測された成功率が 90% の場合、95% の Clopper-Pearson 信頼区間は実に 15.4 ポイント（80.5% から 95.9%）に及びます。一方、ロールアウト数を 1,030 回に増やせば、誤差は±2 ポイントの幅（88.0% から 91.8%）まで狭まります。しかし、多くの公開ベンチマークでは、2 つの方策のパフォーマンスを比較する際に統計的な有意性を確保できる十分なロールアウト数が実行されていません。

Introducing RoboLab

これらの課題に対応するため、私たちは「RoboLab」と呼ばれるシミュレーションベンチマークプラットフォームを構築しました。RoboLab は以下の 3 つの原則に基づいて設計されています。

• ロボットに依存しないタスク評価を実現しつつ、意味のある指標を提供する
• ベンチマークの飽和を防ぐため、エージェント AI ワークフローをサポートした新タスクの迅速な生成を可能にする
• ポリシーがどの程度成功しているか、どこで失敗し、なぜ失敗するのかという全体像を把握できる包括的な分析ツールセットを提供する

図 6. ベンチマークは分野の進化に伴い、新しい能力に対応して適応する必要があります。既存ベンチマークのパフォーマンスが飽和に達したら、ベンチマークを拡張し適応させる時です。

エージェント AI の時代におけるロボットベンチマーク

図 7. RoboLab のロボット評価シーン、タスク、環境を生成するための 3 ステップのプロセス。

RoboLab は、実世界のセットアップ手順を模倣しています。具体的には、オブジェクトを配置し、言語指示を入力してポリシーを実行するだけです。オブジェクトライブラリが用意されているため、ユーザーは単にシーン内にオブジェクトを配置し、タスクに対する言語指示（あるいは 3 つの指示）を指定するだけで済み、このプロセス全体にかかる時間は数分です。また、RoboLab にはエージェントスキルも備わっており、コーディングエージェントがこれを利用して、ユーザーのワークフロー内で新規タスクを直接生成することができます。こうした効率性により、ベンチマークは将来にも対応可能になります。一般化モデルの進化に伴い、新しいタスクを追加したり、古くなったタスクを廃止したりすることが容易だからです。

Bring-your-own-robot

汎用的なロボットポリシーを構築するには、長尾にわたる特定のタスクを解決する必要がありますが、あらゆるエンボディメント（物理的形態）において豊富なデータを保有しているチームは存在しません。ある研究室では Franka アームに関する数千時間のデータを持っていても、ヒューマノイドについてはほとんどない場合があり、その逆も同様です。特定のロボットに紐付けられたベンチマークであれば、ユーザーが実際に構築やテストしようとしている内容に関わらず、誰もが同じデータの欠落部分に直面することになります。

RoboLab のタスクは、ロボットやポリシーに依存しない（アジェンスト）設計となっています。つまり、ロボットの物理的形態やポリシーのアーキテクチャにかかわらず、同一のタスクセットで評価が可能です。ユーザーは独自の設計選択を行う自由があり、RoboLab は単に、ユーザーが持ち込む任意のロボットに対して同じシーンとタスクをコンパイルして実行します。将来、利用可能なロボットの選択肢が増えることを考慮しても、このアプローチは理にかなっています。重要なのはデータ生成やトレーニングにどのロボットが使われたかではなく、そのロボットがタスクを解決できたかどうかです。

Capability-specific tasks

有用なベンチマークは、ロボットがタスクを完了したかどうかを単に測定するだけでなく、個々の能力を切り離して評価する必要があります。我々が観察したところ、汎用的な操作には少なくとも3つの異なる能力が必要であることがわかります。

視覚的能力は、ポリシーが色やサイズ、セマンティックカテゴリといった知覚属性を認識し、それに基づいて行動できるかをテストします。例えば、テーブルの上の他の物体から小さな赤いカップを見分けるようなタスクです。

手続的（プロシージャル）能力は、アクション指向の推論を評価するものです。これは、物体を積み重ねたり向きを変えたり、ツールとの相互作用方法を推測したりすることを含みます。

関係的能力は、空間的および言語的なロジックを検証します。これには、「オレンジとライムを両方持ってくる」のような接続詞や、カウント、左側や内部といった相対位置の理解が含まれます。

各タスクが特定の能力に焦点を当てるように設計することで、汎用的なポリシーが必要とするスキル全体を網羅的にカバーできます。RoboLab-120 は、我々が作成した初期ベンチマークで、人間が選定したテーブル上のピック＆プレイスタスク 120 件から構成されています。各タスクには必要な能力が複数タグ付けされており、これによりベンチマークの能力ごとのカバレッジは明確かつバランスよく保たれ、新しいタスクが追加されるたびに調整されます。

表 1：コンピテンシーとは、ポリシーが能力ドメイン内でタスクを遂行する能力のことです。当ベンチマークスイートで設計したタスクの例として、いくつかのコンピテンシーとスキルを紹介します。

ロボットポリシーの評価

「良い」ロボットポリシーを示す指標は何か？

成功率だけでは、ロボットがどのようにタスクを遂行したかについてはほとんど分かりません。単にゴールラインを越えたかどうかしか示さないのです。正しい物体をつかんでいても途中で落としてしまうポリシーは失敗と判定されますが、ぎこちなく、うねるように動き、あるいは非常に遅い動作でようやく成功するポリシーは成功と判定されてしまいます。これら二つのケースは、単なる「成否」の二元評価では捉えきれません。

この課題に対処するため、RoboLab では 3 つの評価ツールを追加し、ポリシーの挙動をより包括的に把握できるようにしています：

• 段階的なタスクスコア：多段階の手順指示においてサブタスクが完了した部分に対して部分的な加点を行います。例えば、正しい物体をつかんだものの落下地点を外してしまったロボットは、何も行動を起こさなかったロボットと同じ評価にはなりません。

• 軌道の質：移動距離や SPARC（スペクトル弧長） といった指標を用いて動作の効率性を測定します。これは人間の知覚に合致した指標で、速度のフーリエスペクトルを通じて滑らかさを捉えるものです。より短く、滑らかな動きが好まれます。

• 実行速度：エンドエフェクタの速度を計測します。これも人間の知覚に合致した指標であり、「速い動作の方が好まれる」という人間の感覚を反映しています。

ロボットポリシーはいつ失敗するのか？

タスクがなぜ失敗したかを知ることは、単に失敗したかどうかを知るのと同等に重要です。通常の性能指標を超えて、RoboLab はポリシーが成功するか失敗するかの理由や、プロセスのどこで何が破綻するのかを深く掘り下げて分析します。

失敗イベントの自動ログ機能は、誤った物体の把持、落下、グリッパー同士の衝突などを追跡し、タスク実行がどこで逸脱したかを特定します。例えば、「プラスチックボトルをすべてゴミ箱に片付ける」というタスクを見てみましょう。このポリシーはすべてのプラスチックボトルを拾ってゴミ箱に入れましたが、誤ってオレンジも一緒に投入してしまいました。

一見すると、技術的にはタスクは完了しているように見えます。仕様通りにタスクが完了したとしても、ロボットは途中で間違った物体をつかんでしまい、その後で回復するケースがあるのです。

Figure 8. 「プラスチックボトルをすべてゴミ箱に片付ける」というタスクで、最終的に成功したロールアウトの過程で、ポリシー実行中に 3 つの別々の失敗イベントが発生しました。

これらのイベントを確認するため、RoboLab にはビルトインのダッシュボードが搭載されています。エピソード中に発生するイベントをリアルタイムで表示し、ユーザーは失敗が発生したフレームに直接ジャンプできます。これにより、診断は事後の推測ゲームから、ロボットの挙動をデバッグするようなプロセスへと進化します。「機能したか？」と問うのではなく、「どこで止まったのか」「その事象に至った文脈は何だったのか」を確認できるのです。

複雑性が増す中で、ロボットポリシーはどれほど堅牢か？

実世界での展開では、ベンチマークのような清潔で制御された環境が整うことはめったにありません。指示の伝え方は無数にあり、シーンには雑多な要素が散在し、タスクも 1 つや 2 つではなく、多くのステップにわたって行われます。ポリシーが真に堅牢かどうかを理解するには、言語、シーン、そしてタスクの範囲（ホライズン）における複雑性の増加に対するパフォーマンスを分析する必要があります。

言語の複雑性

実験室の外で活躍するには、正確に言葉を選んだ指示しか理解できないロボットでは不十分です。なぜなら、人間は自然と多様で曖昧な表現で指示を出すからです。複数の言語指示に対してテストを行うことで、そのポリシーが「特定の言い回しへの依存」に過ぎないのか、「真のタスク理解」に基づいているのかを明らかにできます。

RoboLab では、ユーザーがタスク仕様に複数の言語指示を指定し、実行時にどのバリアントを使用するかを選択できるようになっています。初期ベンチマークでは、3 つのバリアント（曖昧な指示、デフォルト、具体的な指示）を提供しました。その結果、曖昧な指示は常に失敗につながることが分かり、現在のモデルがいまだに言い回しに対して脆いことが示されました。また、指示に詳細すぎる情報を含めすぎると、逆にパフォーマンスが低下する場合もあることも発見しています。

シーン複雑度

実環境は、トレーニング時のような整然とした状況とは異なり、しばしば注意をそらす物体や散らかった物、視覚的なノイズに満ちています。これらは物体の識別を混乱させる要因となります。シーンが複雑になるにつれてパフォーマンスを評価することで、視覚的な妨害物の中でも正しい対象を特定できるかどうかを確認できます。

タスクの複雑さ：短期間と長期間の比較

多くの実世界のタスクは単一のステップではなく、依存関係のあるサブタスクの連続です。初期段階での小さな失敗が連鎖し、最終的にタスク全体の失敗につながる可能性があります。例えば、「食器棚にマグカップを片付ける」というタスクでは、まず食器棚を開ける必要があるため、マグカップをつかむ前にその手順が必要です。タスクの範囲（ホライズン）が大きくなるにつれてパフォーマンスがどのように低下するかを測定することで、ポリシーが長い推論チェーンにわたってどの程度精度を維持できるかがわかります。RoboLab のタスクでは、タスク設計者が期待されるサブタスクの順序を指定し、ポリシーがその順序に沿ってどれだけ進捗しているかを追跡できます。我々の調査では、ほとんどのポリシーは長期ホライズンのタスクで苦戦しており、4 つ以上の複雑なサブタスクを成功裏に実行できるポリシーはありませんでした。

How sensit