Das VLM, das einem zusammenbrechenden Roboter 62 von 100 Punkten gab

TL;DR

Nachdem handcodierte Fitnessfunktionen immer wieder degenerierte Gangarten übersehen hatten (die Saga um das Belohnungs-Hacking) und nachdem das durch LLM iterierte Belohnungsdesign an die Überlebensgrenze gestoßen war (der Eureka-Beitrag), probierten wir den naheliegenden nächsten Schritt aus: ein Vision-Language-Modell die Rollouts bewerten zu lassen.

Die Hypothese lautete, dass ein menschenähnliches qualitatives Urteil die Fehlermodi erkennen würde, die unsere Metriken nicht artikulieren konnten. Wir ersetzten den handcodierten Fitness-Scorer durch Claude (Opus 4.7), der sich 8 gerenderte Keyframes pro Rollout ansah, eine Bewertung von 0–100 abgab und eine Kritik in einfacher Sprache verfasste.

Es funktionierte halbwegs.

• Das VLM vergab härtere, ehrlichere Bewertungen als die Metriken. Dieselben Policies, die beim handcodierten Fitness-Scorer 73,8 Punkte erzielten, erhielten beim VLM 62 Punkte. Die Differenz von 20–50 Punkten ist der entscheidende Vorteil: Policies, die nach den Metriken ähnlich aussehen, erhalten vom VLM unterschiedliche Bewertungen, und die Bewertung des VLM korreliert mit dem, was ein menschlicher Beobachter sagen würde.
• Das LLM reagierte auf das Feedback des VLM in einfacher Sprache. Als Kandidaten der Iteration 0 mit „der Oberkörper neigt sich vom allerersten Schritt an stark nach hinten“ gekennzeichnet wurden, schlug der erste Kandidat der Iteration 1 ausdrücklich vor: „Aufrichtigkeits-Gating + Dämpfung der Winkelgeschwindigkeit, um den Fehler ‚Neigung nach hinten‘ zu beheben, der alle drei Vorläufer zum Scheitern brachte.“ Das ist die Eureka-Feedbackschleife, die wie vorgesehen funktioniert.
• Der „Gewinner“ des VLM war ein 0,6 Sekunden dauernder Vorwärtssturz. Der beste v18-Kandidat erzielte 62/100 Punkte, bestand die VLM-Prüfung is_walking=True und hatte bei genauer Betrachtung null echte Schritte gemacht – sein Becken sank um 26 cm über 30 Frames, während der Roboter nach vorne fiel. Die 8 Keyframes hielten einen Moment mit zweibeiniger Haltung während des Zusammenbruchs fest. Das VLM wurde auf dieselbe Weise getäuscht wie zuvor die Metriken: durch statisch wirkende Standbilder, die die tatsächliche physikalische Bewegungsbahn beschönigen.

Dies ist eine Fallstudie zu ehrlicher Eignung. Wir dachten, das Hinzufügen eines VLM würde die Überwachungslücke schließen. Es verringerte die Lücke, schloss sie aber nicht, und die nächste Lücke – die Verschleierung von Zusammenbrüchen durch die Frame-Zeit – erforderte eine andere Lösung.

Die Lösung, auf die wir uns einigten: ein strenger Schrittzähler (Fußanhebung ≥ 4 cm, Haltezeit ≥ 3 Frames, Landung ≥ 6 cm vor der Anhebungsstelle), der gegen das VLM kreuzvalidiert wurde, wobei die Ergebnisse stets in Sekunden und nicht in Frames angegeben wurden. Unter dieser Schwelle erzielen sowohl das „Beste“ von v17 als auch das „Beste“ von v18 null echte Schritte. Die Folgeversion v19 – derselbe VLM-Kritiker, jedoch mit zeitlicher Mehrwinkel-Abtastung und Warmstart aus einer funktionierenden Mocap-Richtlinie – erzeugte 4 von 12 Kandidaten, die die strenge Hürde nehmen. Einer davon, Iteration 2, Kandidat 1, ist der echte qualitative Gewinner: stabiles Becken, echtes zweibeiniges Gehen, über 5 Sekunden lang aufrechterhalten.

Dieser Beitrag erzählt die ganze Geschichte ehrlich, einschließlich der Rücknahme.

Loading...

Warum wir einen VLM-Critic ausprobiert haben

Handcodierte Fitness für humanoides Gehen ist anfällig. Im Laufe dieses Projekts stießen wir auf Strategien, die:

• Bei „Einbeinstand > 30 %“ gut abschnitten, indem sie immer auf demselben Fuß standen – Einbeinhüpfen (v16).
• bei „Beckenhöhe > 0,55 m“ gut abschnitten, indem sie genau auf 0,55 m in die Hocke gingen und nie umkippten (Modus 2 der Reward-Hacking-Saga).
• Erzielte gute Ergebnisse bei „Vorwärtsgeschwindigkeit > 0,3 m/s“, indem er kurz vorwärts ging und dann nach vorne fiel – ein getarnter Gangfehler.

Jede Metrik, die wir hinzufügten, erkannte den unmittelbaren Fehlermodus, verfehlte aber den nächsten. Das allgemeine Muster: Der Raum von „erfüllt die Belohnung“ ist deutlich größer als der Raum von „sieht korrekt aus“, und Policy-Optimierer sind hervorragend darin, diese Lücke zu finden.

Ein VLM, der auf Millionen von Bildern menschlicher Gangarten trainiert wurde, hat diese Einschränkung konstruktionsbedingt nicht. Er sieht gerenderte Keyframes und beschreibt sie in natürlicher Sprache. Ein einbeiniger Hüpfer sieht überhaupt nicht wie Gehen aus; der VLM sollte dies auch sagen. Entscheidend ist, dass der VLM nicht durch die Erfüllung spezifischer numerischer Kriterien ausgetrickst werden kann – er bewertet gerenderte Bilder, die die gesamte physische Pose kodieren.

Das war die Ausgangshypothese. Bitte haben Sie etwas Geduld, während ich die Ergebnisse vorstelle.

Aufbau

VLM-Kritiker. Claude Opus 4.7 über das Claude Agent SDK, unter Verwendung von Abonnement-Anmeldedaten. 8 Keyframes pro Rollout, Seitenansicht, gerendert mit 320×320 aus MuJoCo. Die Eingabeaufforderung fragt drei Dinge in JSON ab:

• Eine Bewertung von 0–100.
• Eine Beschreibung in einfacher Sprache dessen, was in den Keyframes geschieht.
• Das Problem, das am einfachsten zu beheben ist, formuliert als umsetzbares Feedback für einen Belohnungsdesigner.

Latenz: ~10–15 Sekunden pro Bewertung. API-Kosten: keine zusätzlichen Kosten (Abonnement).

LLM-Vorschlagsgenerator. Gleiche Eureka-Schleife wie in v17 (4 Iterationen × jeweils 3 Kandidaten). Die Eingabeaufforderung des Vorschlagsgenerators beschreibt nun den VLM-Kritiker als Bewerter und enthält frühere VLM-Beschreibungen wörtlich in der Versuchsgeschichte. Der Vorschlagsgenerator kann sehen, was der VLM über frühere Kandidaten gesagt hat, nicht nur die Bewertungen.

Trainingsumgebung. Gleiche UnitreeG1ConfigurableEnv wie in v17, Kaltstart, mit harter Abbruchbedingung bei einem Beckenabstand unter 0,55 m und Bodenkontakt außerhalb des Fußbereichs. Identische Baseline, sodass der Vergleich direkt vergleichbar ist.

Trainingsbudget. 2,5 Mio. PPO-Schritte pro Kandidat, 16 parallele Umgebungen, jeweils ca. 20 Minuten Rechenzeit. Insgesamt 12 Kandidaten, ca. 4 Stunden.

Ergebnisse: v18 im direkten Vergleich mit v17

Die Vergleichstabelle, angegeben in menschlicher Zeitskala statt in Kontrollframes:

Eigenschaft	v17 (manuell codierte Fitness)	v18 (VLM-Bewertung)
Beste Kandidatenpunktzahl	73,8 / 100	62 / 100
Episodendauer (beste)	61 Frames = 1,2 Sekunden	30 Frames = 0,6 Sekunden
Tatsächlich zurückgelegte Schritte (Abheben + Aufsetzen an neuer Position x ≥ 6 cm)	0	0
Beckenabsenkung Start → Ende	~25 cm	26 cm
Zurückgelegte Strecke nach vorne	0,27 m	0,09 m
Visuell: Ist es ein Gehen?	Nein – Rückwärtssturz	Nein – Vorwärtssturz

Keiner der „Gewinner“ geht. Beide stürzen innerhalb von 1,3 Sekunden, was weniger ist als die Dauer eines einzigen menschlichen Gehschritts. Der „zweibeinige Wechsel“, den wir in den Metriken und in den v18-Keyframes gesehen haben, war das Wechseln der Füße der Policy während des Sturzes, kein tatsächliches Gehen.

Die Rücknahme

Der erste Entwurf des v18-Ergebnisses behauptete, dies sei ein „echter Läufer“ – das VLM gab is_walking=True, 62/100, an, und die Keyframes zeigten eine zweibeinige Haltung. Die Rücknahme erfolgte, als wir den strengen Schrittzähler hinzufügten und denselben Rollout in Echtzeit neu rendern ließen. 30 Frames bei 50 Hz entsprechen 0,6 Sekunden. Kein menschlicher Gehschritt ist in 0,6 Sekunden abgeschlossen, geschweige denn der gesamte Stand-Schwung-Stand-Zyklus, der einen Schritt ausmacht.

Die Keyframes hielten einen Moment mit zweibeiniger Haltung während des Zusammenbruchs fest. Das VLM, das Standbilder beurteilte, konnte die zeitliche Bewegungsbahn nicht erkennen, die in einem Sturz auf das Gesicht endete.

Es ist derselbe Fehlermodus wie bei den Metriken – andere Ebene, gleiche Form. Die Metrik bewertete „Anteil der Einbeinstellung > 30 %“, ohne zu wissen, dass die Regel immer auf demselben Fuß galt. Das VLM bewertete „sieht über 8 Frames zweibeinig aus“, ohne zu wissen, dass diese 8 Frames 0,6 Sekunden des Fallens umfassten. Jede Ebene war angesichts dessen, was sie sehen konnte korrekt, und jede lag auf dieselbe Weise falsch: indem ihr ein Artefakt gezeigt wurde, das die zugrunde liegende Bewegungsbahn verzerrte.

Das war, noch einmal, peinlich. Es lohnt sich, dies ausdrücklich zu erwähnen.

Was das VLM tatsächlich besser machte als die Metriken

Selbst wenn man es als „Ergebnis“ zurückzieht, brachte v18 im Vergleich zu v17 zwei wirklich neue Dinge hervor.

Strengere, genauere Bewertung

Jeder v18-Kandidat erzielte eine niedrigere Punktzahl als sein v17-Äquivalent:

v18-Iteration	v18-Kandidat	VLM-Bewertung	Was eine manuell codierte Fitness ergeben hätte
1	0	62	~75 (entspricht dem besten Ergebnis von v17)
3	1	38	~70 (erfüllt die meisten v17-Kriterien)
0	0	18	65 (dies ist genau die Policy der ersten Iteration von v17)

Das VLM ist bei denselben Richtlinien durchweg 20–50 Punkte strenger als der manuell programmierte Bewerter. Richtlinien, die nach den Metriken ähnlich aussehen, erhalten vom VLM unterschiedliche Bewertungen, und die Bewertung des VLM korreliert mit dem, was ein menschlicher Beobachter sagen würde.

Das ist eine echte Verbesserung. Der Eureka-Loop trainiert das LLM anhand des Bewertungssignals. Wenn das Bewertungssignal strenger ist und stärker mit dem menschlichen Urteil korreliert, verbessern sich die Vorschläge des LLM. Dies sehen wir empirisch im nächsten Unterabschnitt.

Umsetzbare Fehlerbeschreibungen

Iteration 0 von v18 erzeugte drei Kandidaten, die alle vom VLM mit 14–18 bewertet und mit entsprechenden Kritiken in einfacher Sprache versehen wurden:

• „Der Oberkörper neigt sich bereits beim ersten Schritt stark nach hinten“
• „Starke Instabilität der Rumpfneigung … Arme werden als windmühlenartige Gegengewichte eingesetzt“
• „Der Roboter neigt sich vom ersten Schritt an nach hinten, anstatt seinen Schwerpunkt nach vorne über den Standfuß zu verlagern“

Dies ist die Art von Feedback, die ein erfahrener Bewegungsforscher geben könnte. Beachten Sie, dass alle drei mit leicht unterschiedlichen Worten zu derselben Diagnose gelangen – das VLM ist über alle Durchläufe hinweg konsistent, wenn der zugrunde liegende Fehler derselbe ist.

In Iteration 1 war die Begründung für das Belohnungsdesign des ersten Kandidaten explizit:

„Stabilitätsgesteuerte Fortbewegung – die Geschwindigkeitsbelohnung wird mit einem Aufrichtigkeitsfilter multipliziert, sodass die Strategie erst dann eine Belohnung für das Gehen erhält, nachdem sie das Stehen erreicht hat, sowie eine explizite Dämpfung der Winkelgeschwindigkeit, um den Fehler des ‚Rückwärtskippens‘ zu beheben, der alle drei vorherigen Versuche zum Scheitern gebracht hat.“

Dieser Kandidat erzielte 62 Punkte – ein Sprung um 44 Punkte in einer einzigen Iteration – und wurde vom VLM als gehfähig bestätigt (obwohl, wie die Rücknahme zeigt, der VLM bei Artefakten nicht durchschauen konnte).

Der Punkt ist nicht der 44-Punkte-Sprung an sich. Es geht darum, dass das LLM eine strukturelle Korrektur für einen vom VLM benannten spezifischen Fehlermodus vorschlug, anstatt dieselbe Form zweimal erneut zu versuchen. Das passiert bei rein metrikbasiertem Feedback nicht, da rein metrikbasiertes Feedback strukturelle Fehler nicht benennen kann.

Neue Fehlermodi, die die Metriken übersehen haben

All dies wurde erst durch die Kritik des VLM sichtbar:

• „Arme in unnatürlicher, gespreizter Haltung verkrampft, anstatt wechselseitig zu schwingen“
• „Der Körper springt/stürmt ballistisch, anstatt zu schreiten“
• „Das Becken sackt während der gesamten Sequenz monoton zusammen“
• „Vorwärtssturz statt einen Fuß zu setzen, um den Schwerpunkt abzufangen“
• „Beide Knie beugen sich gleichzeitig, anstatt auf einem Bein zu stehen“

Die handcodierte Fitness hatte keinen Einblick in irgendetwas davon. Eine Strategie konnte die Arme unnatürlich spreizen, sich mit einem Sprung abstoßen oder das Becken absinken lassen und dennoch jedes von uns codierte Fitnesskriterium erfüllen. Das VLM benennt diese Fehlermodi; das LLM kann sie dann gezielt beheben.

Was das VLM NICHT behoben hat

Die Überlebensklippe bleibt bestehen. Die beste v18-Policy läuft 30 Frames lang, bevor sie nach vorne fällt. Die beste v17-Policy „läuft“ 61 Frames lang und fällt dann. Das zugrunde liegende RL-Problem – dass PPO die Wiederherstellung des Gleichgewichts nicht aus Cold-Start-Trajektorien lernen kann, bei denen es noch nie einen Beinahe-Sturz gesehen hat – wird durch die Änderung des Scorers nicht beeinflusst. Die Belohnungsfunktion kann, egal wie sorgfältig sie auch gestaltet ist, keine Trainingsdaten erzeugen, die nicht existieren.

Die VLM-Kritik ist ein Bewertungs-Upgrade, kein Trainings-Upgrade. Sie sagt dir, wann deine Policy falsch ist, und zwar genauer als Metriken, aber sie macht deine Policy nicht richtig.

Die Lösung: ein vierstufiger Bewertungsstapel + zeitliche Kritik

Nach v18 haben wir das entwickelt, womit wir hätten beginnen sollen. Jede Schicht erfasst eine Fehlerklasse, die die vorherige übersehen hat:

Loading...

1. Manuell festgelegte Schwellenwerte (v17): Erfasst einfache Fehler wie fehlenden Fußkontakt und eine zu niedrige Beckenposition.
2. Strukturelle Metriken (ab v16, Reaktion auf die Rücknahme des Hüpfen): bilaterales Ungleichgewicht, Luftanteil, Doppelstützanteil. Erfasst einbeiniges Hüpfen, Fliegen und Übergänge ohne echte Schritte.
3. VLM-Kritik (v18): Erkennt qualitative Fehlermodi, die die numerischen Metriken nicht erfassen – windmühlenartige Armbewegungen, gespreizte Haltung, Rückwärtsneigung des Oberkörpers, monotoner Beckenabfall.
4. Schrittzähler (rückwirkend nach v18): Ein echter Schritt erfordert eine Fußanhebung von ≥ 4 cm, eine Haltephase von ≥ 3 Frames und eine Landung ≥ 6 cm weiter vorne. is_walking=True erfordert ≥ 4 echte Schritte UND ≤ 10 cm Gesamtabsenkung des Beckens UND eine Dauer von ≥ 5 Sekunden. Berichte immer in Sekunden, nicht in Frames.

Unter dieser Schwelle erzielen sowohl das „Beste“ aus v17 als auch das „Beste“ aus v18 0 echte Schritte und is_walking=False. Die strenge Schwelle hat erfasst, was die vorherigen Schwellen übersehen haben.

v19: gleiches VLM + zeitliche Abtastung + Warmstart

Sobald wir der Schwelle vertrauten, ließen wir die Schleife erneut mit drei Änderungen laufen:

• Warm-Start ab v12. Die PPO-Initialisierung jedes Kandidaten ist v12 (die funktionierende Mocap-Policy). Das Training umfasst 2 Millionen Verfeinerungsschritte bei niedriger Lernrate (1e-4, Entropiekoeffizient 0,001). Dies beseitigt das Problem der Cold-Start-Abdeckung – die Policy beginnt bereits mit dem Gehen und die vom LLM vorgeschlagene Belohnung formt den Gang.
• Zeitliches VLM mit mehreren Blickwinkeln. Der Renderer erfasst 3 Kamerawinkel (Seite, Front, Dreiviertel) an jeweils 5 Zeitpunkten über 5 Sekunden Bewegung = 15 Keyframes pro Bewertung. Das VLM sieht nun Bewegung im Zeitverlauf und im 3D-Posenraum, nicht nur statische Seitenansichten. Dies behebt die Schwachstelle der Frame-Disguise in v18.
• Schrittzähler-Kreuzvalidierung. Die handcodierte Fitness umfasst nun den physischen Schrittzähler sowie die Überprüfung der Beckenstabilität. is_walking=True erfordert sowohl, dass das VLM „Ja“ sagt, als auch, dass der Schrittzähler die Prüfung besteht. Kein einzelnes Signal kann für sich allein das Gehen bestätigen.

Ergebnisse von v19: 4 von 12 Kandidaten gehen

12 Kandidaten, gleiches Rechenbudget wie bei v17 und v18. Unter der strengen Schwelle:

	v17 (Kaltstart, handcodiert)	v18 (Kaltstart, VLM mit einem Winkel)	v19 (Warmstart + zeitliches VLM mit mehreren Winkeln + Schrittzähler)
Kandidaten, die die strenge Geh-Schwelle überschreiten	0 / 12	0 / 12	4 / 12
Beste Episodendauer	1,2 s	0,6 s	5+ s (anhaltend, begrenzt auf 10 s Rendering)
Beste Beckenabsenkung	~25 cm	26 cm	< 10 cm (ein Kandidat vollständig stabil)
Echte Schritte im besten Durchlauf	0	0	≥ 4 (durch Schrittzähler kreuzvalidiert)

Der qualitative Gewinner ist v19 iter 2 cand 1 – VLM-Score 62, Becken stabil, 6 echte Schritte in 6 Sekunden. Es ist der einzige Kandidat im gesamten v17/v18/v19-Durchlauf, der das anhaltende Problem des Beckenabfalls behoben hat.

Die Belohnung für diesen Kandidaten war ein Gauß-Gate für die Aufrichtigkeit sowie eine Strafe für ein asymmetrisches Becken – das LLM diagnostizierte das Versagen von Iteration 1 (ein expliziter Anker für die Beckenhöhe verursachte eine „Freeze-in-Place“-Falle) und schlug eine glattere Version vor, die keine übermäßige Steifigkeit auslöst. Für diese Art von korrigierenden Iterationen ist die Schleife gedacht.

Seite an Seite mit v12 (der funktionierenden Mocap-Baseline) zur Kalibrierung:

Die Kandidaten von v19 bleiben nahe an der Qualität von v12. Sie übertreffen diese nicht dramatisch. Die Basis-Mimik-Belohnung zieht die Verfeinerung immer wieder zurück in Richtung der LAFAN1-Mocap. Die Verfeinerung auf Basis der Mocap ist real und führt zu einer messbar besseren Beckenstabilitätsachse, aber sie überschreitet nicht die Qualitätsgrenze der Mocap.

Was v19 nicht behoben hat

Selbst mit dem besseren Bewertungsstack blieben drei Dinge ungelöst:

• Armhaltung. Jede VLM-Kritik an v19 weist nach wie vor auf steife Arme hin. Die Basis-Mimik-Belohnung verankert die Armgelenke an der Mocap-Referenz von v12, und das LAFAN1-G1-Retargeting weist steife Arme auf. Unsere additive Belohnung mit Gewicht 1,0 kann die Mimik-Verankerung nicht überwinden. Um dies zu beheben, bräuchten wir entweder ein Gewicht ≥ 5 oder müssten das Arm-Pose-Tracking der Mimik-Umgebung gezielt abschwächen.
• Schrittfrequenz. v19-Läufer machen etwa 1 Schritt pro Sekunde. Die Schrittfrequenz eines gesunden Menschen liegt bei ~2 Schritten pro Sekunde. Gleiche Ursache – die Basis-Mocap legt die Schrittfrequenz auf das Tempo von LAFAN1 fest.
• Vorwärtsneigung. Mehrere VLM-Kritiken weisen darauf hin. Die Basis-Policy weist dies ebenfalls auf.

Die Obergrenze für Verbesserungen ist v12 selbst. v19 bringt Verfeinerungskandidaten von unten nahe an die Qualität von v12 heran, und ein Kandidat liegt auf der Achse der Beckenstabilität leicht darüber. Keiner liegt dramatisch über der v12-Baseline, da die Basis-Mimik-Belohnung die Policy immer wieder zurückzieht. Um die Mocap-Baseline grundlegend zu übertreffen, bräuchte man einen umfangreicheren Referenzdatensatz oder ein völlig anderes Überwachungssignal.

Was wir nicht behaupten

Dieser Beitrag behauptet nicht, dass „die VLM-Kritik die humanoide zweibeinige Fortbewegung löst“. Das tut sie nicht. Die Überlebenshürde beim Kaltstart wird durch die VLM-Kritik allein nicht überwunden – das ist das ehrliche negative Ergebnis von v18. Der Warmstart v19 führte zu Verbesserungen der Verfeinerungsqualität, nicht zu neuen Fähigkeiten.

Was die VLM-Kritik nachweislich leistet:

• Es weigert sich, degenerierte Gangarten in gleichem Maße mit überhöhten Punktzahlen zu bewerten, wie es Metriken tun.
• Es erzeugt Fehlerbeschreibungen, die das LLM nutzt, um effektiv zu iterieren.
• Es macht das Experiment so ehrlich, dass „der beste Kandidat“ etwas ist, das auch ein menschlicher Beobachter wählen würde, und kein Metrik-Täuschungsmanöver.

Das ist ein nützlicher Beitrag. Es ist kein perfektes menschliches Gehen. Wir werden nicht so tun, als wäre es anders.

Wann dieser Stack eingesetzt werden sollte

Die VLM-Kritik hilft, wenn:

• Ihr Belohnungsraum reichhaltig genug ist, um viele degenerierte Lösungen zu enthalten (Cold-Start-Fortbewegung, komplexe Manipulation, geschickte Aufgaben).
• Sie über eine visuelle Darstellung des Verhaltens der Policy auf Frame-Ebene verfügen.
• Sie Fehlerzusammenfassungen wünschen, die das LLM strukturell statt nur numerisch interpretieren kann.

Die VLM-Kritik hilft nicht, wenn:

• Das zugrunde liegende RL-Problem grundlegende Abdeckungs- oder Erkundungsprobleme aufweist – unser „Survival Cliff“. Eine bessere Bewertung ändert nichts daran, was die Policy aus Cold-Start-Trajektorien lernen kann.
• Visualisierungen auf Frame-Ebene den relevanten Zustand nicht erfassen können (Reibungskoeffizienten, innere Kräfte, partielle Beobachtbarkeit).
• Sie eine Echtzeit-Belohnung pro Schritt benötigen. Die VLM-Latenz beträgt ~10–15 Sekunden; sie ist nur pro Rollout praktikabel.

Der Schrittzähler / die Ebene auf menschlicher Zeitskala ist im Wesentlichen kostenlos – ein paar hundert Zeilen Code, die in Echtzeit laufen – und sollte unabhängig davon, welche Bewertungsmethode Sie an anderer Stelle verwenden, immer aktiv sein. Berichten Sie immer in Sekunden. „Überlebt 30 Frames“ klingt nach Fortschritt; „überlebt 0,6 Sekunden“ nicht. Die Wahl der Einheit leistet Arbeit.

Ehrliche Vorbehalte

• Einzelner Start, einzelner Durchlauf. Sowohl v17 als auch v18 sind einzelne experimentelle Durchläufe. Auch v19 ist ein einzelner Durchlauf mit dem neuen Stack. Die 12-Punkte-Unterschiede bei den „besten“ Ergebnissen müssten repliziert werden, um statistisch aussagekräftig zu sein.
• Das VLM ist manchmal aus den falschen Gründen konsistent. Wir haben gesehen, dass iter 0 cand 0 (Gangart-Uhr) und iter 0 cand 2 (Gelenkraum-Biomechanik) trotz sehr unterschiedlicher Belohnungen innerhalb von 4 Punkten bewertet wurden, da beide visuell ähnliche Rollouts mit „nach hinten kippendem Roboter“ erzeugten. Konsistenz ist nicht dasselbe wie Richtigkeit.
• Das VLM kann das Überleben nicht explizit erkennen. Er bewertet die Keyframes, nicht die Dauer. Wir kompensieren dies, indem wir die Episodendauer in den Prompt-Kontext einbeziehen, aber der VLM gewichtet das, was er sieht, stärker als das, was wir ihm sagen.
• Der LLM kombiniert nicht immer erfolgreiche Techniken. Iter 2 Cand 1 in v19 war der Durchbruch; nachfolgende Kandidaten haben diesen Ansatz manchmal aufgegeben, anstatt ihn zu verfeinern. Dies ist ein Problem des Eureka-Musters, kein VLM-spezifisches.

Was wir als Nächstes versuchen würden

Drei offene Richtungen:

1. Abschwächung der Mimik-Umgebungs-Armverfolgung, damit die additive Belohnung für den Armschwung am Oberkörper dominieren kann, während die Beinverfolgung beibehalten wird. Testen, ob die armschwungbewussten Kandidaten von v19 tatsächlich sichtbaren Armschwung erzeugen, anstatt durch die Mocap eingeschränkt zu sein.
2. Multi-Clip-Referenz. Verwende ein LAFAN1-Segment mit natürlicherem Armschwung (eine schnellere Gehsequenz oder einen als „natürlich“ gekennzeichneten Clip anstelle des Lab-Walking-Clips) als Basis. Höhere Referenzqualität → höhere Obergrenze für die Verfeinerung.
3. Echtzeit-Studie mit Menschen. Mehrere menschliche Beobachter, die Videos nebeneinander ansehen: Bevorzugen sie die v19-Gewinner gegenüber der v12-Baseline bei p < 0,05? Dies ist der qualitative Test, auf den es letztendlich ankommt, und wir haben ihn noch nicht durchgeführt.

Abschluss der Serie

Dies ist der letzte Beitrag in der Humanoid-Sim-Serie. Fünf Beiträge, ein Projekt, viele ehrliche Fehlschläge. Das Muster, das sich durch alle zieht: Jeder Versuch, die Überwachung zu automatisieren, führte zu einer neuen Art von Fehlschlägen, nicht zu null Fehlschlägen. Handcodierte Metriken übersahen degenerierte Gangarten. LLM-iterierte Belohnungen erkundeten den Designraum, ohne das Abdeckungsproblem zu lösen. Die VLM-Kritik schloss einige Lücken und öffnete neue rund um die Verschleierung der Frame-Zeit. Das verlässliche Signal in diesem Projekt blieb dasselbe wie zu Beginn: eine echte Motion-Capture-Referenz und das Minimum-Viable-Mocap-Ergebnis, dass zwei sorgfältig angeordnete Posen ausreichen.

Der konstruktive Bogen – was tatsächlich funktioniert – ist der Mocap-Beitrag und die v19-Verfeinerung auf Basis von Mocap. Der diagnostische Bogen – was nicht funktioniert – ist Reward-Hacking, LLM-Iteration und dieser Beitrag. Beide Bögen sind notwendig, und beide müssen ehrlich sein, denn das Fachgebiet ist klein genug, dass Artikel ohne Rücknahmen in der Regel Artikel sind, bei denen die Rücknahmen noch nicht bemerkt wurden.

Wenn es eine praktische Lektion gibt, die sich durch alle fünf Beiträge zieht, dann ist es die, mit der dieser Beitrag endete: Gib immer die Zeit in Sekunden an. Unabhängig davon, wie Ihre Bewertungsfunktion aussieht: Wenn Sie Ihr Ergebnis darlegen, geben Sie es in Zeiteinheiten an, die für Menschen von Bedeutung sind. 30 Frames klingen nach Fortschritt. 0,6 Sekunden klingen nach einem Zusammenbruch. Es handelt sich um dieselbe Tatsache. Die Wahl der Einheit entscheidet darüber, ob die Berichterstattung schmeichelhaft oder ehrlich ist, und das Fachgebiet profitiert von der ehrlichen Variante.