Von der Demonstration zum Einsatz: die Trainings-Pipeline für Roboter

Sieht man einer Manipulations-Policy beim Scheitern zu, lernt man mehr, als wenn man ihren Erfolg beobachtet. Ein Modell, das auf der Werkbank fehlerfrei Wasser eingießt, verfehlt die Tasse, sobald sich das Licht ändert, der Tisch drei Zentimeter höher steht oder der Becher glänzend statt matt ist. Die Demo wirkte wie Intelligenz. Was tatsächlich versagte, war eine Pipeline, an einer bestimmten Stelle, aus einem Grund, den man benennen kann.

Die meisten Beiträge beschreiben Foundation Models für Roboter als eine gerade Linie: Daten sammeln, pretrainen, fine-tunen, deployen. Dieser Rahmen ist bequem und falsch. Pretraining, Post-Training, Sim2Real und Evaluation sind keine Abfolge, die man einmal durchläuft. Sie bilden eine Schleife, geschlossen durch die Evaluation, die man viele Male durchläuft, und jeder Durchlauf verändert, welche Daten als Nächstes erfasst werden. Die Teams, die brauchbare Policies ausliefern, behandeln die vier Stufen als ein System mit einer Rückkopplungsschleife, nicht als vier getrennte Abteilungen.

Dieser Beitrag bezieht Position: Die bindende Restriktion in dieser Schleife ist nicht die Modellarchitektur, die zunehmend konvergiert und gemeinsam genutzt wird, sondern die Demonstrationsdaten und die Ehrlichkeit der Evaluation. Stimmen diese beiden, funktionieren auch mittelmäßige Architekturen. Stimmen sie nicht, stößt auch das beste VLA im Leaderboard noch die Tasse um.

Vier Stufen, eine Schleife

Vor den Details hier die Übersicht. Jede Stufe hat eine Aufgabe, eine charakteristische Datenquelle und eine Art, wie sie im Stillen versagt.

Pretraining: Breite, geliehen von anderen Robotern

Kein einzelnes Labor kann genügend Stunden teleoperieren, um einem Modell die visuelle und physische Welt von Grund auf beizubringen, weshalb sich das Pretraining Breite leiht. Open X-Embodiment bündelt rund eine Million reale Trajektorien aus 22 Robotertypen in einer Mischung, und Modelle, die auf dieser gepoolten Menge trainiert werden, transferieren besser als Modelle, die nur auf einem einzelnen Roboter trainiert wurden. NVIDIA Isaac GR00T und Physical Intelligences pi-zero folgen demselben Rezept: Ein Vision-Language-Backbone trägt semantische Priors, ein Action Head lernt motorische Priors, und beide werden auf einer heterogenen Mischung pretrainiert, bevor sie überhaupt die eigentliche Aufgabe zu Gesicht bekommen.

Menschliches Videomaterial ist die andere Hälfte der Breite. Tausende Stunden alltäglicher Aufnahmen aus der Ich-Perspektive (Ego4D) und rund 1.300 Stunden zeitsynchronisierter Erfassung aus Ich- und Dritte-Person-Perspektive (Ego-Exo4D) geben einem Modell Priors darüber, wie sich Hände Objekten nähern, wie sich Aufgaben zerlegen und wie eine plausible nächste Bewegung aussieht. Ein Mensch erzeugt kontaktreiches, aufgabenrelevantes Verhalten weit schneller und günstiger als ein teleoperierter Arm. Der Haken: Menschen sind nicht der Roboter, weshalb diese Daten als Prior helfen, aber als direktes Ziel schaden, wenn die nächste Stufe übersprungen wird.

Post-Training: die letzte Meile entscheidet über die Policy

Pretraining verleiht Kompetenz im Allgemeinen. Post-Training verleiht Kompetenz auf dem eigenen Roboter, in der eigenen Zelle, für die eigene Aufgabe, und genau hier wird der größte Teil der tatsächlich ausgelieferten Leistung gewonnen oder verloren. Hier sind die Daten knapp und teuer: teleoperierte Demonstrationen auf der Zielhardware. DROID ist der Referenzpunkt für Qualität, 76.000 teleoperierte Trajektorien über 564 Szenen, erfasst auf einem einheitlichen Aufbau, und ist wertvoll gerade weil es divers und kalibriert ist, nicht bloß groß. Kontaktreiche Korpora wie RH20T, in der Größenordnung von 110.000 Episoden, treiben dieselbe Idee in Richtung kraftintensiver, mehrstufiger Aufgaben.

Der Fehlermodus ist subtil. Zweihundert Demonstrationen, die ein einzelner Operator an einem Nachmittag aufnimmt, sind hoch korreliert: derselbe Greifansatz, dasselbe Licht, dieselbe Unordnung. Die Policy überfittet die Gewohnheiten des Operators und wirkt hervorragend in einer Evaluation, die genau diese Gewohnheiten spiegelt. Offene Pipelines wie Hugging Face LeRobot erleichtern es, solche Datensätze zu standardisieren und zu teilen, was hilft, aber kein Format repariert ein Korpus, das die Aufgabe immer nur auf eine einzige Art gesehen hat.

Sim2Real: günstige Daten mit einer Realitätssteuer

Simulation ist der einzige Weg, Millionen Durchläufe einer gefährlichen oder seltenen Bedingung zu erzeugen, ohne Hardware zu zerstören. Domain Randomization, das Variieren von Licht, Texturen, Massen und Reibung, sodass die reale Welt wie nur eine weitere Stichprobe wirkt, ist das, was einer in Simulation trainierten Policy erlaubt, den Kontakt mit der Realität zu überstehen. Das funktioniert bemerkenswert gut für Fortbewegung und Ganzkörperkontrolle, wo die dominante Physik die Starrkörperdynamik ist, die Simulatoren gut modellieren, und wo NVIDIAs GEAR Lab und der Isaac-Stack stark investiert haben.

Weit schlechter funktioniert es für die Aufgaben, die am meisten gewünscht sind: kontaktreiche Manipulation weicher, verformbarer oder gelenkiger Objekte. Ein Simulator, der ein sich faltendes Handtuch, einen Reißverschluss oder einen abrutschenden Griff nicht getreu modellieren kann, trainiert eine selbstsichere Policy, die am echten Objekt versagt. Die ehrliche Faustregel: Simulation kauft Dynamik und Geometrie günstig ein, und sie kauft Kontakt und Verformung nur zu einem steilen und oft verborgenen Preis. Sim2Real ist kein kostenloses Datenpaket, sondern ein Kredit auf das eigene Evaluationsbudget.

Evaluation: der Flaschenhals, den niemand vorführt

Jede der vorangegangenen Stufen wird vom selben Richter bewertet, und dieser Richter ist teuer. Echte Roboterevaluation ist langsam, verrauscht und schwer zu reproduzieren: Dieselbe Policy erzielt am Dienstag andere Werte, weil sich das Licht verändert hat. Simulation und Offline-Metriken sind günstig, weichen aber regelmäßig vom Erfolg am echten Roboter ab, sodass eine Policy auf einer Offline-Kurve steigen kann, während sie in der Zelle schlechter wird. Die Arbeit des Toyota Research Institute zu Large Behavior Models spricht das unverblümt aus: Sorgfältige Evaluation in der realen Welt über viele Versuche und Szenen hinweg ist der Teil, der tatsächlich zeigt, ob die letzte Änderung geholfen hat.

Die meisten Roboter-Demos zeigen den besten von vielen Durchläufen. Die Pipeline, auf die es ankommt, ist die, die ehrlich den durchschnittlichen Durchlauf zeigt, bevor man ausliefert.

Deshalb schließt die Evaluation die Schleife, nicht die Architektur. Eine vertrauenswürdige Evaluation zeigt, in welche Stufe als Nächstes investiert werden sollte: die Pretraining-Mischung verbreitern, diversere Post-Training-Demonstrationen erfassen oder aufhören, einem Sim-Asset zu vertrauen. Eine schmeichelhafte Evaluation führt im Kreis.

Die nächste Policy, die auf einer Bühne ein Hemd faltet, sagt für sich genommen fast nichts aus. Die nützlichen Fragen sind, bei welcher der vier Stufen tatsächlich die Schleife geschlossen wurde, wie viele reale Versuche hinter der Zahl stehen und wessen Demonstrationen die Bewegung gelehrt haben. Wer diese Fragen beantwortet, kann eine Pipeline von einem Highlight-Reel unterscheiden.