Zielkonditionierte Policies: ein Modell, viele Ziele

Trainieren Sie einen Roboter darauf, einen roten Block auf einen blauen zu stapeln. Bitten Sie ihn nun, den blauen auf den roten zu stapeln. Wurde er auf die alte Weise trainiert, eine Policy pro Aufgabe, haben Sie Pech: Das ist eine andere Aufgabe, also müssen Sie neu trainieren. Eine zielkonditionierte Policy behandelt das Ziel als Eingabe, nicht als Konstante, die in die Gewichte eingebrannt ist, sodass dasselbe Modell beide Aufgaben verfolgen kann, ohne neu trainiert zu werden.

Genau diese eine Design-Entscheidung, das Ziel in die Policy einzuspeisen, ist einer der stillen Gründe dafür, dass ein einzelnes humanoides Modell heute Hunderte Aufgaben versuchen kann. Sie verändert auch, was Ihr Datensatz enthalten muss. Eine Policy, die jedes beliebige Ziel akzeptiert, muss viele Ziele gesehen haben, jedes gepaart mit dem Verhalten, das dorthin führt, und dieses Paar richtig hinzubekommen ist schwerer, als es klingt.

Das Ziel als Eingabe, nicht als Annahme

Eine einfache Policy bildet eine Beobachtung auf eine Aktion ab. Eine zielkonditionierte Policy bildet Beobachtung und Ziel gemeinsam auf eine Aktion ab. Das Ziel ist ein zusätzliches Argument, das das Netzwerk bei jedem Schritt liest, und dieselben Gewichte erzeugen je nach Anfrage unterschiedliches Verhalten.

Der Gewinn ist Wiederverwendung. Ein einziger Satz Gewichte deckt eine ganze Familie von Aufgaben ab, die dieselbe Dynamik teilen, sich aber in der Absicht unterscheiden. Das ist das Rückgrat moderner Multi-Task-Systeme, und deshalb werden Foundation Models wie NVIDIA Isaac GR00T und die generalistischen Policies, die im Physical-Intelligence-Blog beschrieben werden, als ein einziges Modell dargestellt, das vielen Anweisungen dient, statt als ein Regal voller Einzelaufgaben-Controller.

Vergleichen Sie das mit der Alternative. Ohne Zielkonditionierung trainieren Sie ein Netzwerk pro Aufgabe, und nichts, was über das Stapeln von Blöcken gelernt wurde, hilft beim Einschenken von Wasser. Gemeinsame Struktur wird verschwendet. Ein zielkonditioniertes Modell amortisiert stattdessen das, was den Aufgaben gemeinsam ist, das Heranreichen, das Greifen, das Gespür für Kontakt, und wendet seine Kapazität nur auf das an, was sich unterscheidet. Deshalb kann ein einziger Satz Gewichte Hunderte Anweisungen aufnehmen, ohne massiv an Größe zuzunehmen.

Wie Sie einem Roboter sagen, was Sie wollen

Ein Ziel bleibt abstrakt, bis Sie sich für eine Repräsentation entscheiden, und diese Entscheidung hat echte Konsequenzen.

• Sprache: „Stell die Tasse in die Spüle.“ Flexibel und menschenfreundlich, aber mehrdeutig, und sie braucht gepaarte Sprach-Aktions-Daten, um die Worte in Bewegung zu verankern. Das ist der VLA-Weg, den Systeme wie Gemini Robotics gehen.
• Zielbild: ein Bild des gewünschten Endzustands. Präzise und eindeutig, aber Sie brauchen dieses Bild für jedes Beispiel, und eines zur Testzeit anzugeben kann umständlich sein.
• Koordinaten oder Posen: exakte Zielpositionen. Hervorragend für klar definierte Bewegungen, nutzlos für „den Tisch aufräumen“.

Jede Repräsentation verlangt ein anderes Label auf jeder Trajektorie. Diese Annotationslast ist der versteckte Preis des Wechsels zu Multi-Task, und deshalb investieren offene Korpora wie Open X-Embodiment echten Aufwand darin, zu standardisieren, wie Ziele und Anweisungen über Dutzende beitragende Datensätze hinweg erfasst werden.

In der Praxis entscheiden sich Teams selten für nur eine davon. Ein modernes System nimmt vom Menschen oft eine Sprachanweisung entgegen und verankert sie dann intern in einem Bild- oder Koordinatenziel, dem der Low-Level-Controller folgen kann. Diese Schichtung bedeutet, dass dieselbe Trajektorie mehrere Ziel-Labels gleichzeitig braucht, was die Anforderungen daran erhöht, wie reichhaltig jede Demonstration aufgezeichnet wird.

Eine zielkonditionierte Policy ist nur so allgemein wie die Menge der Ziele in ihren Daten. Enge Ziele, enger Roboter, ganz gleich, wie groß das Modell ist.

Das Datenproblem, das sich in „vielen Zielen“ versteckt

Hier liegt die Falle. Um eine Policy zu trainieren, die jedes beliebige Ziel erreicht, scheinen Sie Demonstrationen für jedes einzelne Ziel zu brauchen, was unmöglich ist. Der Ausweg ist ein Relabeling-Kniff namens Hindsight.

Hindsight-Zielrelabeling ist einfach und wirkungsvoll. Ein Roboter versucht, Ziel A zu erreichen, und landet stattdessen in Zustand B. Diese Trajektorie ist ein Fehlschlag für A, aber sie ist eine perfekte Demonstration dafür, wie man B erreicht. Also relabeln Sie sie: dieselben Aktionen, ein neues Ziel, jetzt ein Erfolg. Ein gescheiterter Versuch wird zu Trainingsdaten für ein Ziel, nach dem niemand gefragt hat. Genau das erlaubt es zielkonditioniertem Lernen, aus endlichen Daten viele Ziele herauszuholen, und es verändert, wie ein Datensatz aufgebaut sein sollte.

Die Idee stammt aus dem Reinforcement Learning, wo sie als Hindsight Experience Replay bekannt ist, und sie dreht das Problem der spärlichen Belohnung um. Statt dass ein Roboter tausendmal scheitert und nichts lernt, bis er zufällig über das Ziel stolpert, lehrt jeder Versuch etwas, weil jeder Versuch einen Zustand erreicht, der es wert ist, gelabelt zu werden. Die Konsequenz für die Datenerfassung ist unmittelbar. Eine Trajektorie hat Wert, selbst wenn der Demonstrator sein Ziel verfehlt hat, solange Sie aufgezeichnet haben, wo sie tatsächlich endete.

Warum Relabeling verändert, was Sie erfassen

Wenn gescheiterte Versuche und ungeplante Endzustände Trainingsdaten sind, dann verschenkt eine Erfassungs-Pipeline, die nur saubere Erfolge behält, die Hälfte ihres Ertrags. Hindsight belohnt unordentliche, explorative, unvollkommene Daten, weil jede Trajektorie irgendeinen Zustand erreicht und jeder erreichte Zustand ein gültiges Ziel für diese Trajektorie ist.

Das kehrt den üblichen Instinkt um, nur die perfekte Einstellung zu filmen. Unter Hindsight ist der ungeschickte Versuch, der zum falschen Regal abgedriftet ist, kein Ausschuss, sondern ein gelabeltes Beispiel dafür, dieses falsche Regal absichtlich zu erreichen. Der Fehler des Demonstrators wird zum Ziel von jemand anderem. Eine Pipeline, die um diese Idee herum gebaut ist, erfasst mehr nutzbare Daten pro Stunde als eine, die makellosen Demonstrationen hinterherjagt.

Offene Frameworks machen das konkret. Der Hugging Face LeRobot-Stack liefert zielkonditionierte und Multi-Task-Rezepte, die Daten in einem standardisierten episodischen Format erwarten, mit Zielen und Ergebnissen, die pro Episode erfasst werden. Die Lehre daraus ist immer dieselbe: Das Format, in dem Sie aufzeichnen, entscheidet, ob Sie später relabeln können, oder ob dieses Signal verloren geht.

Allgemein dem Namen nach, oder in den Daten

Ein Modell, viele Ziele ist nicht allein ein Modellierungstrick. Es ist eine Wette auf die Daten. Die Policy kann nur Ziele verfolgen, die sie tatsächlich gesehen hat, und der günstigste Weg, mehr Ziele zu sehen, ist, damit aufzuhören, die Zustände zu verwerfen, die Ihre Demonstratoren zufällig erreicht haben. Legen Sie die Zielrepräsentation früh fest, zeichnen Sie Ergebnisse so sorgfältig auf wie Absichten, und ein endlicher Berg an Demonstrationen erstreckt sich über eine viel breitere Menge an Aufgaben. Lassen Sie das aus, und eine leistungsfähige Multi-Ziel-Architektur wird am Ende nur auf einem schmalen Ausschnitt von Zielen trainiert, allgemein nur dem Namen nach.