BUILD · Research → story
動かずに支える手

瓶のふたを開けるとき、目立たない方の手が成功の条件をつくっている。
固い瓶のふたを開ける人を見てみよう。ふたを回す手には見せ場がある。瓶を押さえるもう一方の手は、あまり仕事をしていないように見える。
その手を離すと、話が変わる。瓶がふたと一緒に回ってしまうかもしれない。よく動いているのに、開かない。
この作業では、動いてはいけないものを動かさないことも仕事になる。複数のエージェントを協調させたい人にとって、瓶は小さくてよい問いを投げかけてくれる。
静かな方の手にも役割を
CoRL 2024 の論文 VoxAct-B は、動作を担うアームと対象を安定させるアームを明示的に区別している。著者らは二本のロボットアームで瓶や引き出しを開ける作業を示した。ただし、この手法には言語、視覚言語モデル、シーンのボクセル表現も含まれる。評価されたのはそれらを組み合わせた方法であり、改善を役割分担だけの効果とすることはできない。
協調には別の妥当な道もある。RSS 2023 の ACT は、観測からひとまとまりの動作列を予測する。両腕を制御する方策は、腕同士の関係をまとめて学べる。二つの独立した頭脳が瓶を奪い合う仕組みとは限らない。比較対象に相手の存在を忘れさせてから、もう一方の協調性を褒めても、公平な比較にはならない。
知りたいのは「構造は規模に勝つか」より小さなことだ。同じ場面を見ている共同制御の方策に、役割を明示する情報を加えると役立つのか。
設計者をがっかりさせるかもしれない実験
9月28日の Daily Special は、その比較を提案している。実験はまだ行っていない。
同じ学習器の三つの版を考える。A は両腕を共同で制御する。B は、支える腕と動かす腕を示す役割情報を加える。C は B の追加モジュールを残し、意味のある役割入力だけを、学習時も評価時も同じ固定トークンに置き換える。
C はデモの会場で少し歓迎されない客だ。B が見事に動いても、C が同じ成績なら、役割ラベルの手柄とはまだ言えない。追加モジュールの別の要素が効いたのかもしれない。A と B が同等なら、この課題と予算では明示的な役割が不要かもしれない。
デモデータ、観測、評価場面、総リソースの上限を揃える。役割を割り当てる処理も予算に含める。そうしなければ「協調がうまい」の正体は、追加の情報や計算量かもしれない。
失敗した試行も残す。人が助けてからふたが開いたなら、それは介助ありの完了だ。成功例が速くても、時間切れの試行は消えない。完了率、禁止された接触、人の介入を並べて示せば、都合の悪いトレードオフも見える。
瓶を押さえるのは誰か
瓶が示すのは設計上の問いであって、AI チームの万能な作り方ではない。ソフトウェアなら、別の構成要素が草稿を編集する間、確認済みの入力を保つ役割が近いかもしれない。それが有効かどうかは別途比較が必要で、ロボットの結果が証明してくれるわけではない。
それでも、この問いは持ち帰れる。目の前の動作を成功させるには、何が安定していなければならないか。
忙しく動く参加者を増やす前に、その責任を定めよう。そして、定めたことで結果が変わるかを試そう。静かな方の手を無視する必要も、無条件に称える必要もない。手を離したときに何が起きるかを見逃さないテストが必要なのだ。