シンガポール国立大学の研究チームが発表したAPPL(Agent Priors-guided Policy Learning)は、ロボットスキルを訓練する際に用いた「設計上の仮定」を捨てず、後からスキルを組み合わせる段階で再び使う。各スキルが何をするか(名前)だけを組み合わせ器に渡していた従来の手法と違い、そのスキルがどこで通用するかまで言語で書いて渡す。このたった一つの再利用で、わずかなデモンストレーションだけでも、初めて見る状況・初めて見る組み合わせをより上手く解けた、というのが要点だ。
家庭や倉庫で働くロボットは、学んだことよりはるかに多くの仕事を求められる。デモンストレーション(demonstration)を集めるのはコストが高いので、ふつうは数個の課題を数回デモしただけで学習する。ところが現場では、新しい目標、慣れた動作の新しい順序、そして以前とは違う位置に置かれた物体が次々に押し寄せる。
ここで二種類の汎化が同時に必要になる。一つは組み合わせ汎化(compositional generalization)、学んだスキルを組み直して新しい課題を解く能力だ。もう一つはスキル汎化(skill generalization)、物体が動いたり、前のスキルが残した見慣れない状態から始まったりしても、各スキルが依然として機能する能力だ。
問題は、この二つが互いに噛み合っているのに、肝心の両者のあいだで情報が漏れてしまう点にある。課題レベル(task level)の判断は「どのスキルをどの順序で」を考えるが、そのスキルが実際に物理的にどこまで通用するのかは知らない。逆にスキルは数回のデモから学んだだけで、上位の判断が前提にしている構造を知らない。著者らの言葉を借りれば、組み合わせ器はスキルを、名前・指示文・記号演算子といった「別立ての説明」を通してしか見ていない。その説明には、スキルがどんな構造で学習されたのかが抜け落ちている。
既存のアプローチもこの溝を埋めようとしてきた。ビジョン・言語・行動モデル(VLA)は課題の意味と低レベル制御を一つのモデルに統合するが、どんな条件で汎化するかが暗黙のまま残り、配置や物体位置の変化に弱いという指摘を論文は引用している。課題・動作計画(TAMP)系は記号的な前提条件・効果で二つのレベルを結ぶが、その構造を手で定めるか、データから学ばなければならない。エージェント系はポリシーをツールのように呼び出し、言語をインターフェースとして使うが、名前や指示文は「何のためのツールか」は教えても「どんな物理条件で通用するか」は教えてくれない。そのため、スキルとスキルのあいだの受け渡し(handoff)がよくある失敗ポイントとして残る。
APPLの発想はシンプルだ。スキルを学習させる際に用いた構造的な事前仮定(structural prior)を、組み合わせ段階のインターフェースとしてそのまま再利用しよう、というものだ。
構造的な事前仮定とは「この行動が何に依存するか」を明示したものだ。論文が挙げる例は把持(grasp)である。把持は世界座標上の絶対位置ではなく、「物体に対するグリッパーの相対姿勢」だけに依存すると仮定できる。この仮定を二か所で使う。第一に、学習に組み込めばポリシーがどこへ汎化するかを形づくる。物体相対座標で学んだ把持は、物体が新しい絶対位置に現れても通用する。第二に、同じ仮定を言語で書いて上位のエージェントに渡せば、そのポリシーがどこに適用されるかを教えてくれる。
料理にたとえると、レシピカードに「完成料理の写真」だけを貼っておく代わりに、「この調理法は常温の材料を前提とする、冷凍では不可」といった適用条件も一緒に書いておくようなものだ。シェフ(組み合わせ器)は料理名だけを見て選ぶのではなく、いまの材料の状態でこのレシピが通用するかを判断できるようになる。
具体的には、APPLは二つのエージェントで動く。
この設計の巧みな点は、「ポリシーの構造をどう決めるか」を固定された設計判断ではなく、スキルごとの仮説に変えたところにある。仮説は提案され、実装され、検証され、ランタイムで再利用される。学習を形づくった情報が、後からそのポリシーを選んで組み立てるときにも生き残るわけだ。
論文は、良いインターフェースの条件も形式化している。ポリシーが実際に成功する領域を成功領域(R)、インターフェースが「ここで通用する」と主張する領域を適用領域(A)とすると、AがRより広ければ通用しない場所でポリシーを呼び出して失敗し、AがRより過度に狭ければ使える呼び出しを手放すことになる。だからインターフェースは忠実でありながら(AがRの内にある)、同時に情報量が多くなければならない(AがRを広く覆う)。
実験は、事前仮定の二つの役割をそれぞれ狙っている。注意すべきは、以下の数値が異なる二つの実験から出た値だということだ。
一つ目の実験はスキル汎化を見る。MetaWorldの課題6種で、エージェントが設計した事前仮定は、少数デモ条件での分布外(OOD)汎化を、バニラのDiffusion Policyや固定された関係性事前仮定(fixed relational prior)と比べて大きく引き上げた。論文が示す数値では、デモ2個の条件でOOD成功率が89.6%となり、同条件の固定関係性事前仮定37.9%と対比される。
二つ目の実験は長期課題の組み合わせを見る。デモ12個ずつ与えられたManiSkillの長期課題5種で、APPLは物体配置が変わった条件で50.0%成功し、同条件で課題全体を一つに学習したfull-task Diffusion Policyは10.0%にとどまった。途中地点から始めたり早期終了を要求したりする課題レベルの変形では92.5%を記録し、初めて見るスキル組み合わせ16個のうち8個を解いた。
最も重要な結果は別にある。学習済みのポリシーライブラリはそのままにして、構築時のインターフェース情報だけをランタイムエージェントから隠したところ、成功率が有意に下がった。これが論文の中心的な仮説を裏づける。スキルを汎化させるために使った構造的な仮定が、そのスキルをいつ・どう使うか決めるうえでも有用な情報だということだ。つまり性能を上げたのはポリシーそのものだけでなく、「そのポリシーがどこで通用するか」を伝えたインターフェースだった。
著者ら自身も結論で限界を認めている。いくつかは、記事の事実の範囲内で検討する価値がある。
組み合わせ汎化の結果は、まだ絶対値が高いとは言いにくい。初めて見る組み合わせ16個のうち8個を解いたというのは半分だ。物体配置が変わった条件の50.0%も、ベースライン(10.0%)の五倍ではあるが、それ自体としては半分の成功だ。難しい設定だという証でもあり、まだ道のりが残っているという信号でもある。
実験の舞台がMetaWorldとManiSkillである点も念頭に置くべき箇所だ。両ベンチマークともシミュレーションの操作課題であり、実機ロボット・実際の家庭環境で同じ幅の利得が再現されるかは、この論文の事実の範囲を超えている。
そして、事前仮定を「複数提案し、仮定ごとにポリシーを一つずつ学習・検証する」構造は、スキル一つに複数のポリシーを作って保存するコストを伴う。ライブラリが大きくなるほど、ランタイムエージェントが正しい候補を選ぶ選択問題も一緒に大きくなる。インターフェースが忠実性と情報量を同時に守らねばならないという要求は概念的には明快だが、エージェントが作った適用領域の説明が実際の成功領域とどれだけずれるかは、課題ごとに異なるだろう。
この研究をAI PMのある場面に重ねてみると、示唆がくっきりする。ツール(スキル)委任の瞬間だ。
ONTLEのAI PMは顧客の要望を受け取ると、その仕事を複数の実行ツールとサブエージェントに分けて任せる。いまの大半のエージェントシステムがそうであるように、PMがツールを知る方法は「名前と説明」だ。たとえば「エクセル表プレビューツール」「サブドメイン発行ツール」といった具合に。APPLがロボットで指摘した問題が、ここでもそのまま繰り返される。PMはそのツールが何をするかは知っていても、そのツールがどんな条件で信頼できる形で動くのかは知らない。表プレビューツールが上位200行・30列までしか見ないとか、特定の連携はプロジェクト専用DBが先に作られていなければならないといった「適用領域」は、ツール名には含まれない。
APPLの処方を移すとこうなる。各実行ツールを登録するとき、名前だけでなく「このツールは何に依存するか / どんな入力状態を前提とするか / 前段がどんな状態を残せば引き継げるか(受け渡し条件) / 過去にどんな範囲で成功が検証されたか」を、機械が読めるインターフェースとして一緒に書いておくのだ。そうすればPMが作業を分解して委任するとき、ツールを「通用する場所」でだけ呼び出し、「通用しない場所」では別の実装を選んだり先行作業を先に挟んだりする判断ができる。とりわけ段階と段階のあいだ、あるツールの出力が次のツールの入力前提を破る受け渡し地点は、ONTLEのようなパイプラインでもよくある失敗箇所だが、受け渡し条件をインターフェースに明示するという発想は、まさにその箇所を狙う。
ここには落とし穴も一緒に見える。APPLでインターフェース情報を隠したら性能が下がったという結果は、少なくともこの論文が扱った特定のポリシーライブラリでは、インターフェースが貧弱だと、良いポリシーを揃えても組み合わせがうまくいかなくなりうることを示している。ただし論文が実証したのはこの設定での性能低下であって、あらゆるツールやソフトウェアエージェントに同じことが普遍的に成り立つと証明したわけではない。それでも、ツールカタログを「名前+一行の説明」だけで管理するよくある慣行が、なぜ危うくなりうるのかを一つの実験で示した、と読むことはできる。ONTLEの立場から当面やるべきは、ロボットのポリシーを真似ることではなく、ツール・連携・サブエージェントの「適用条件と受け渡し条件」を説明メタデータへ格上げすることだ。それが、この論文がロボットアームで見せた利得を、ソフトウェアエージェントの委任判断へ移す最もまっすぐな道だ。
その行動が何に依存するかを明示した仮定です。論文の例では「把持は物体に対するグリッパーの相対姿勢だけに依存する」といった言明です。これを学習に入れればポリシーがどこへ汎化するかを決め、言語で書いておけば上位のエージェントにそのポリシーがどこに適用されるかを教えます。
構築エージェントがスキルごとに一つの抽象化に固定せず複数の事前仮定を提案し、仮定ごとにDiffusion Policyを一つずつ学習させるからです。異なる帰納バイアスを持つ実装がライブラリに共存するので、ランタイムエージェントが状況に合った実装を選んで使えます。
いいえ。89.6%はMetaWorld6種でのデモ2個条件のOODスキル汎化成功率(固定関係性事前仮定37.9%との対比)で、50.0%はManiSkillの長期課題5種で物体配置が変わった条件の組み合わせ成功率(full-task Diffusion Policy 10.0%との対比)です。異なる実験・条件の数値なので、一つにまとめて語ってはいけません。
この論文の実験はMetaWorldとManiSkillというシミュレーションの操作ベンチマークで行われました。実機ロボット・実環境で同じ幅の利得が再現されるかは、本文に示された事実の範囲を超える未解決の問いです。