Simulator baut Trainingsszenen nach den Fehlern des Roboters: CoDA verfünffacht Generalisierung von pi0.5
Statt Simulationsdaten blind zu vermehren, diagnostiziert der Preprint, warum ein Roboter scheitert, erzeugt Szenen, die genau diese Schwäche nachstellen, und liefert das passende Lernsignal. Das betrifft direkt die Datenkosten aller, die Roboter-KI mit synthetischen Daten trainieren.
Wenn ein Simulator unbegrenzt Trainingsumgebungen erzeugen kann, wie wählt man jene aus, die die Schwächen der aktuellen Policy beheben, und welches Lernsignal hilft ihr, daraus zu lernen?
Generative Simulation hat Szenen billig gemacht, doch eine physikalisch gültige Szene ist nicht automatisch nützlich. Bestehende Datenengines variieren Szenen in festgelegten Bereichen, hören nach bestandener Physikprüfung auf oder verteilen Budget nach Erfolgsquote je Aufgabe. Keine sagt, warum eine Policy scheitert oder wie man sie darüber hinausführt, und spärliche Erfolgsbelohnungen machen jedes Update langsam wirksam.
Domain Randomization und gleichförmige Varianten ziehen Änderungen blind; erfolgsgesteuerte Generierung verteilt Szenen nach einem einzigen Wert; Skill-Bibliotheken speichern wiederverwendbaren Code, vermischen aber Wissen über Szenenbau und Training. Eine strukturierte Aufzeichnung der Fehlerursachen fehlte.
CoDA lässt Datenengine und Policy abwechselnd über ein gemeinsames Gedächtnis mit getrennten Speichern für Szenenbau, diagnostizierte Fehler und Lernfortschritt weiterentwickeln. Ein Vision-Language-Kritiker (standardmäßig GPT-5.5) analysiert gescheiterte Ausführungen; nur durch Kontrollexperimente bestätigte Diagnosen gelangen ins Gedächtnis. Daraus entstehen Generierungsprogramme, die die Schwierigkeit nachbauen, und Trainingsprogramme, die helfen, sie zu überwinden. Text2potential übersetzt jede Diagnose in gestufte Teilziel-Potenziale für das Lernen des Werts von Aktionsblöcken, ein dichtes Signal, das unter üblichen Reward-Shaping-Annahmen die optimale Policy nicht verändert. Der gemessene Fortschritt bestimmt die nächste Runde.
Mit pi0.5 als Policy erreichte die mittlere Erfolgsquote außerhalb der Trainingsverteilung über Pick-and-Place, Gelenkobjekte, Hineinlegen sowie Stapeln und Einstecken 27,6 %, gegenüber 5,3 % nach Feinabstimmung auf Startdemonstrationen, 7,9 % mit Domain Randomization, 8,5 % mit gleichförmigen Varianten und 18,1 % mit erfolgsgesteuerter Generierung (52 % relativ besser); nach fünfzehn Runden waren es 42,1 %. Auf LIBERO-Pro stieg der Erfolg bei Positionsänderungen von 25 % auf 84 % und bei Anweisungsänderungen von 1 % auf 76 %, 7 und 9 Punkte über ASPIRE, während das Standard-LIBERO bei 97,4 % blieb (vorher 97,1 %). Text2potential erreichte 25 % nach 21.000 Policy-Updates statt 31.000 mit spärlicher Belohnung, rund 32 % weniger. Ein Wechsel des Kritikers zu Claude Opus 5, InternVL3-78B oder Qwen3-VL-235B kostete 1,5 bis 2,7 Punkte. Mit pi0.5 gesammeltes Gedächtnis hob OpenVLA-OFT ohne neue Szenen von 3,8 % auf 21,1 %. Kosten: 7,4 Millionen Sprachmodell-Token und 66 GPU-Stunden je 1.000 akzeptierte Umgebungen.
Der Preprint bewertet nur Manipulation in der Simulation; die Übertragung auf reale Roboter, besonders bei kontaktsensiblen Aufgaben, steht nach Angabe der Autoren aus. Die Methode stützt sich auf mehrere Foundation-Modelle für Szenenbau, Diagnose und Potenzialerstellung, deren physikalische Fehlannahmen in die Daten einfließen können, und Ergebnisse können sich mit neuen Modellversionen verschieben. Nach fünf Runden liegt die Erfolgsquote außerhalb der Verteilung erst bei 27,6 %, und jede Runde kostet zusätzliche Simulation und Inferenz.
Relevant ist das für alle Firmen, die VLA-Policies mit synthetischen Daten trainieren, darunter Physical Intelligence, dessen pi0.5 hier das Basismodell ist, und Simulationsanbieter wie NVIDIA: Datengenerierung wird zur Rückkopplungsschleife, gesteuert von den Fehlern der Policy, statt zu einem festen Randomisierungsrezept. Für europäische Automatisierer, die Digital Twins für Inbetriebnahme und Training nutzen, verschiebt sich die Frage von der Menge zur Auswahl der simulierten Daten. Zeitrahmen: Einzug in interne Trainingspipelines binnen eines Jahres denkbar; der Nachweis auf echten Robotern ist die Hürde.
Der Volltext wird hier nicht wiedergegeben, weil die Lizenz der Studie das nicht erlaubt. Das Original steht auf arXiv.