Post-Training einer VLA: vom Generalisten- zur Spezialisten-Policy
Fine-Tuning macht aus einer generalistischen Roboter-Policy eine, die sich tatsächlich einsetzen lässt. Ein konkreter Blick auf das Post-Training von VLAs: Methoden, Daten, Fehlermodi und Evaluation.
Eine Falt-Policy, die im Labor eine Erfolgsquote von 90 % erreicht, kann auf Zufallsniveau abstürzen, sobald jemand das Handtuch gegen ein steiferes tauscht, den Tisch um 15 Zentimeter verschiebt oder die Nachmittagssonne ins Zimmer lässt. Die Gewichte haben sich nicht verändert. Die Welt schon. Diese Lücke, zwischen einer Policy, die in der Demo überzeugt, und einer Policy, die tatsächlich ausgeliefert wird, wird fast immer im Post-Training geschlossen, nicht in dem Pretraining-Lauf, über den alle reden.
Ein Vision-Language-Action-Modell (VLA) bildet Kamerabilder plus eine Sprachanweisung direkt auf Roboteraktionen ab. Ein generalistischer Checkpoint, NVIDIAs Isaac GR00T N1 oder π0 von Physical Intelligence, hat bereits einen breiten Ausschnitt an Embodiments, Szenen und Verben aufgenommen. Er trägt einen groben Prior dafür in sich, was „die Tasse aufheben“ bedeutet und wie ein Arm sich auf ein Ziel zubewegt. Was er nie gesehen hat, ist Ihr Greifer, Ihre Kamera-Extrinsik, Ihre Beleuchtung oder das, was für Sie als erledigt gilt. Post-Training ist der Schritt, der aus diesem breiten Prior eine Policy macht, die eine einzelne Aufgabe zuverlässig meistert.
Die Arbeitsteilung ist unbequem: Das Pretraining legt die Obergrenze fest, das Post-Training entscheidet, ob man sie erreicht. Teams verbringen Monate mit der Auswahl eines Basismodells und verlieren den Einsatz dann an ein Fine-Tuning-Rezept, das sie als Nebensache behandelt haben. Im Folgenden geht es darum, was dieses Rezept tatsächlich enthält, wo es versagt und warum die Zusammensetzung der Fine-Tuning-Daten mehr zählt als ihr reines Volumen.
Was der generalistische Prior wirklich bringt
Pretraining auf gepoolten, embodiment-übergreifenden Daten liefert eine Generalisierung, die sich aus Aufgabendaten allein nicht gewinnen lässt. Das Open X-Embodiment-Projekt hat das deutlich gezeigt: Das Poolen von in der Größenordnung einer Million Trajektorien über 22 Robotertypen hinweg und das gemeinsame Trainieren (Co-Training) eines einzigen Modells schlug dieselbe Architektur, trainiert nur auf den Daten eines einzelnen Roboters. Repräsentationen übertragen sich. Ein Arm, der Tausende Küchen gesehen hat, bringt einen brauchbaren Begriff von „Tasse“ und „Griff“ auch in eine Küche mit, die er nie zuvor betreten hat.
Was der Prior nicht liefert, ist Kompetenz auf genau der Verteilung, die einen interessiert. Die Arbeit des Toyota Research Institute zu Large Behavior Models schärft diesen Punkt: Eine vortrainierte Policy startet nicht nur höher, sie braucht auch weniger Demonstrationen, um bei einer neuen Fähigkeit eine Ziel-Erfolgsquote zu erreichen. Pretraining verschiebt die gesamte Dateneffizienz-Kurve nach unten und links. Post-Training ist die Art, wie man diese Effizienz einsetzt.
Eine generalistische VLA liefert eine Policy, die überall plausibel und nirgends zuverlässig ist. Post-Training ist die Verhandlung darüber, wo man diese Zuverlässigkeit einsetzt.
Das Post-Training-Rezept und was jede Stellschraube bewirkt
„Die VLA fine-tunen“ verbirgt mindestens vier unterschiedliche Operationen. Die falsche Wahl kostet Wochen.
| Ansatz | Was sich ändert | Typische Daten | Wichtigster Fehlermodus |
|---|---|---|---|
| Vollständiges Fine-Tuning | Alle Gewichte | Hunderte bis einige Tausend Ziel-Demonstrationen | Katastrophales Vergessen, Overfitting auf den Aufbau |
| Parameter-effizient (LoRA, Adapter) | Kleine zusätzliche Gewichte | Zehn bis Hunderte Demonstrationen | Zu wenig Kapazität für eine große Domänenverschiebung |
| Co-Training | Alle Gewichte, gemischte Batches | Ziel-Demonstrationen plus ein Anteil aus dem Pretraining-Mix | Benötigt die Pretraining-Daten sowie ein abzustimmendes Mischungsverhältnis |
| RL-Post-Training | Policy unter einem Reward | Rollouts am realen Roboter oder in Simulation | Reward-Design, Sample-Kosten, Sicherheit |
Die meisten ausgelieferten Systeme kombinieren mehrere davon. Physical Intelligence beschreibt π0 als eine vortrainierte Basis, die anschließend mit kuratierten, hochwertigen Daten für das Zielverhalten post-trainiert wird, wobei Co-Training gegen einen Anteil des ursprünglichen Mixes die Standardverteidigung gegen Vergessen ist. Google DeepMinds Gemini Robotics wird auf dieselbe Weise dargestellt: ein breites Modell, das auf neue Aufgaben und Embodiments spezialisiert wird, einschließlich einer kleineren On-Device-Variante, die Teams mit einer überschaubaren Menge an Demonstrationen anpassen können.
Wie viele Daten, und welcher Art
Die Frage nach der Menge hat eine langweilige Antwort und eine interessante. Die langweilige Antwort: Für eine einzelne, gut abgegrenzte Manipulationsaufgabe auf einem festen Aufbau bringen schon ein paar Hundert saubere teleoperierte Demonstrationen eine vortrainierte VLA oft von unzuverlässig auf einsatzfähig. Die interessante Antwort ist, dass die Zusammensetzung wichtiger ist als die Anzahl. Hundert Demonstrationen, die die unbequemen Fälle abdecken, den verpassten Griff, das Objekt am Rand des Arbeitsbereichs, die Wiederherstellung nach einem Abrutschen, lehren mehr als tausend nahezu identische Erfolge.
Provenienz und Konsistenz zählen ebenso sehr wie die rohen Trajektorien. DROID ist aufschlussreich: rund 76.000 teleoperierte Trajektorien, gesammelt über Hunderte Szenen und Dutzende Gebäude hinweg, bewusst auf visuelle und räumliche Vielfalt hin angelegt statt auf schiere Größe. Fine-Tuning-Daten erben die Verzerrungen ihrer Erhebung. Wurde jede Demonstration unter derselben Lampe mit denselben drei Objekten aufgenommen, lernt die Policy klammheimlich die Lampe mit. Vielfalt im Fine-Tuning-Datensatz ist kein Nice-to-have, sondern das, was den Kontakt mit einem neuen Raum übersteht.
Wo Fine-Tuning im Stillen versagt
Drei Fehlermodi wiederholen sich immer wieder. Der erste ist katastrophales Vergessen: Drückt man alle Gewichte stark in Richtung einer einzigen Aufgabe, verliert das Modell die Sprachverankerung und die allgemeine Geschicklichkeit, die die Basis überhaupt erst wertvoll gemacht haben. Co-Training und parameter-effiziente Methoden existieren vor allem, um genau das zu verhindern.
Der zweite ist Scheinkorrelation. Eine Policy, die auf einem engen Datensatz fine-getunt wurde, lernt, was in diesem Datensatz den Reward vorhersagt, sei es die Tischdecke, die Tageszeit oder die Angewohnheit des Operators, immer aus derselben Pose zu starten. In der Evaluation wirkt sie brillant und bricht zusammen, sobald sich eines dieser beiläufigen Signale ändert. Der dritte ist eine Fehlpassung im Aktionsraum: Ein über viele Embodiments vortrainiertes Basismodell kodiert Aktionen nach einer bestimmten Konvention, und wenn die Steuerschnittstelle, Frequenz oder Greifergeometrie Ihres Roboters davon abweicht, verwendet das Fine-Tuning sein Budget darauf, die Schnittstelle neu zu erlernen, statt die eigentliche Aufgabe.
Evaluation ist der Teil, den Teams unterschätzen
Einer fine-getunten Policy kann man anhand des Trainingsverlusts nicht trauen. Evaluation am echten Roboter ist teuer, langsam und statistisch verrauscht, genau deshalb wird sie übersprungen. Das Toyota Research Institute war ungewöhnlich offen darüber, dass es geblindete, statistisch kontrollierte Hardware-Evaluationen mit genügend Durchläufen durchführt, um einen echten Gewinn von reinem Glück zu unterscheiden, und diese Disziplin lohnt sich nachzuahmen. Eine Policy, die 8 von 10 Erfolgen bei 10 Durchläufen meldet, und eine, die 80 von 100 meldet, behaupten nicht dasselbe. Legen Sie im Voraus fest, wie viele Durchläufe unter wie viel Variation als „erledigt“ zählen, und halten Sie das Fine-Tuning daran fest.
Der generalistische Checkpoint sind die einfachen 80 Prozent. Der Spezialist, den man tatsächlich einsetzen kann, entsteht auf der letzten Strecke: ein paar Hundert gut gewählte Demonstrationen, eine Fine-Tuning-Methode, die zur Größe der Domänenverschiebung passt, und eine Evaluation, die ehrlich genug ist, um zu sagen, wann Schluss ist. Behandeln Sie diese letzte Strecke als das eigentliche Hauptereignis, denn für alle, die einen Roboter tatsächlich ausliefern, ist sie das.