Wenn LLMs Belohnungen iterativ optimieren: Ein negatives Ergebnis aus der humanoiden Fortbewegung

TL;DR

Wir haben die Eureka-Methodik (Ma et al., NVIDIA 2023) – bei der ein LLM iterativ Belohnungsfunktionen für einen RL-Agenten vorschlägt – angepasst, um das humanoide zweibeinige Gehen auf dem Unitree G1 von Grund auf neu zu trainieren. Bei 24 Kandidaten in zwei Versuchsrunden schlug das LLM strukturell vielfältige Belohnungen vor: multiplikatives Stabilitäts-Gating, minimal aggregierte Kinematik pro Fuß, curriculumförmige Gewichtung über einen Schrittzähler, Unterscheidung zwischen Stand- und Schwungphase anhand der Gelenkgeschwindigkeit. Die Vorschläge waren kreativ, die Iterationsschleife konvergierte, und das LLM korrigierte sich bei beobachteten Fehlermodi korrekt selbst.

Kein Kandidat erreichte ein nachhaltiges Gehen.

Der anhaltende Fehlermodus war eine Überlebensklippe bei 50–70 Schritten, die keine der von uns getesteten Belohnungsformulierungen überwinden konnte – selbst bei einer 4-fach verlängerten Trainingsdauer. Der beste Kandidat (Runde 2, Iteration 2, Kandidat 2) war eine lehrplanförmige Belohnung, die echtes zweibeiniges Gehen mit 0,44 m/s für 61 Schritte erzeugte, bevor der Roboter stürzte. Dann trainierten wir dieselbe Belohnung viermal so lange und erhielten einen zu 1,3 % bilateral ausgeglichenen rückwärts gehenden Walker.

Dieser Beitrag ist das erste negative Ergebnis von Eureka zur humanoiden zweibeinigen Fortbewegung, das uns bekannt ist. Die Erkenntnisse:

• Die LLM-Belohnungsiteration ist ein legitimes Werkzeug. Sie deckt Designfehler auf, die wir nicht vorhersehen, und schlägt Formen vor, auf die ein menschlicher Forscher nicht kommen würde.
• Sie ist kein Ersatz für die Zustandsraumabdeckung. Wenn Ihre Aufgabe einen Cold-Start-Engpass bei der Abdeckung aufweist (zufällige Erkundung kann die Aufgabenvollendung nicht erreichen), erkundet die Belohnungsiteration zwar den Designraum, löst aber nicht das zugrunde liegende RL-Problem.
• Die Methodik ist wiederverwendbar. Andere Aufgabe, anderes Zustandswörterbuch, andere Fitness – derselbe Schleifenablauf.

Loading...

Hintergrund: Was macht Eureka?

Eureka lässt sich einfach beschreiben. Ein LLM schlägt K Kandidaten für Belohnungsfunktionen vor, basierend auf einer Aufgabenbeschreibung und der Historie früherer Versuche. Jeder Kandidat wird kurz trainiert. Die trainierten Strategien werden durch eine unabhängige Fitnessfunktion bewertet. Das LLM erhält die Fitnesswerte sowie strukturierte Fehlerbeschreibungen und schlägt neue Kandidaten vor. Schleife bis zur Konvergenz.

NVIDIAs Veröffentlichung aus dem Jahr 2023 validierte dies anhand von Manipulationsaufgaben – Stiftdrehen, Schubladenöffnen, Benchmarks zur Handgeschicklichkeit. Die vom LLM entworfenen Belohnungen erreichten bei diesen Aufgaben durchweg die von Menschen entworfenen Belohnungen oder übertrafen diese sogar. Das war ein echtes Ergebnis. Die naheliegende Folgefrage: Lässt sich dies auf die zweibeinige Fortbewegung von Humanoiden verallgemeinern?

Unser Projekt ist ein Ein-Mann-Versuch, diese Frage zu beantworten.

Aufbau

Roboter. Unitree G1, 29 angetriebene Gelenke, MuJoCo-Simulation, 50-Hz-Steuerung. Gleiche Konfiguration wie im Rest dieser Serie.

Harte Einschränkungen durch Abbruch. Nach der schmerzhaften Lektion aus der Reward-Hacking-Saga – dass Reward Shaping degenerierte Lösungen nicht verhindern kann – haben wir zwei Abbruchbedingungen auf physikalischer Ebene hinzugefügt, die unabhängig davon ausgelöst werden, welche Belohnung das LLM vorschlägt:

• Beckenhöhe unter 0,55 m → Episode wird beendet (verhindert das Laufen auf den Knien)
• Jeder Körperteil außer den Füßen berührt den Boden → Episode wird beendet (verhindert das Krabbeln)

Die Belohnungsfunktion muss diese Einschränkungen nicht kodieren. Die Beendigung kümmert sich darum. Das LLM kann sich frei darauf konzentrieren, wie das Gehen aussieht, und nicht darauf, was das Gehen nicht ist.

Konfigurierbare Umgebung. Ein neues UnitreeG1ConfigurableEnv akzeptiert eine beliebige Python-Callable als Belohnungsfunktion. Die Umgebung stellt dieser Callable ein strukturiertes Status-Dict (Gelenkpositionen, Geschwindigkeiten, Fußkontakte, Beckenquaternion, Aktionsverlauf) zur Verfügung. Das LLM schreibt die Funktion als Python-Quellcode; wir führen sie in einer Sandbox aus (AST-Whitelist, keine Importe, keine Dunders), um Unfälle und feindliche Ausgaben einzudämmen.

Fitnessfunktion (unabhängig von der Belohnung). Dies ist der Teil, den v16 falsch und v17 richtig gemacht hat. Die Fitness bewertet eine trainierte Strategie anhand von 8 spielfesten Kriterien:

• standing (15 Punkte) — Becken ≥ 0,65 m für ≥80 % der Episode
• forward_vel (15) — mittlere Vorwärtsgeschwindigkeit ≥ 0,3 m/s
• survival (15) — Episode überdauert ≥ 800 / 1000 Schritte
• foot_only (10) – kein Bodenkontakt außer mit den Füßen
• heading (10) – Gierabweichung unter 30°
• bilateral (15) – Bodenkontaktzeiten von linkem und rechtem Fuß in etwa gleich (|L−R|/total < 0,10)
• grounded (10) – Luftanteil unter 20 %
• double_support (10) – beide Füße mindestens 5 % der Zeit gleichzeitig auf dem Boden

Die letzten drei Kriterien wurden hinzugefügt, nachdem der Einbeinhüpfer in Version 16 eine frühere Version getäuscht hatte. Dank der verbesserten Fitness erzielt der Hüpfer nun korrekt eine niedrige Punktzahl: „BILATERALE ASYMMETRIE: Dies ist Einbeinhüpfen, kein Gehen.“

LLM-Zugriff. Claude Opus 4.7 über das Claude Agent SDK unter Verwendung von Abonnement-Anmeldedaten. Jede Eingabeaufforderung enthält die vollständige Historie früherer Kandidaten – die Belohnungen, die Fitnesswerte, die strukturierten Fehlerzusammenfassungen –, sodass das LLM auf beobachteten Fehlern aufbauen kann, anstatt dieselbe Form zweimal erneut zu versuchen.

Trainingsbudget. 2,5 Millionen PPO-Schritte pro Kandidat, 16 parallele Umgebungen, jeweils etwa 20 Minuten Rechenzeit. Vier Iterationen × drei Kandidaten = 12 Kandidaten pro Durchlauf, insgesamt ~4 Stunden. Eine Laptop-GPU.

Runde 1 vs. Runde 2

Wir haben zwei Runden durchgeführt.

In Runde 1 (v16) wurde eine schwächere Fitnessfunktion mit 5 Kriterien verwendet. Der beste Kandidat erzielte 98/100 Punkte und war bei genauerer Betrachtung ein Einbeinspringer – der rechte Fuß berührte in 1000 Frames buchstäblich nie den Boden. Wir berichteten dies zunächst als Durchbruch. Der Nutzer sah sich das Video an und sagte: „Das ist ein hüpfender Flamingo, kein gehender.“ Die Geschichte der Rücknahme wird in der Reward-Hacking-Saga erzählt.

In Runde 2 (v17) wurde die oben beschriebene, verstärkte 8-Kriterien-Fitness verwendet. Die Metriken „bilateral“, „grounded“ und „double_support“ identifizierten den v16-Hüpfer korrekt als nicht gehend. Nachdem die Schwelle verschärft worden war, führten wir den Eureka-Loop erneut durch. Jeder Kandidat wurde nun tatsächlich danach bewertet, ob beide Füße die Arbeit verrichteten.

Es folgen die Ergebnisse von Runde 2.

Ergebnisse: alle 12 Kandidaten

Iter	Cand	LLM-Ansatz	Fitness	ep_len	vx (m/s)	Anmerkungen
0	0	Phasen-getaktete Gangart-Referenz	45,6	41	0,08	Hüpfen + in der Luft
0	1	Taktfreie Kontaktformung	67,0	30	0,21	Stolpern nach vorne
0	2	Energie + Biomechanik gegenphasig	62,3	52	—	Rückkehr zum Hüpfen
1	0	Überlebensorientiertes Design	60,8	46	0,36	beidseitig fixiert, keine Doppelstütze
1	1	Minimal aggregierte Kinematik pro Fuß	70,1	44	0,29	echte zweibeinige Standphase sichtbar
1	2	CoT + Rotation beim Fußauftritt	63,4	42	0,30	teilweise Symmetrie
2	0	Multiplikatives Stabilitäts-Gating	64,3	36	0,27	50 % in der Luft
2	1	Gelenkgeschwindigkeit Stand-/Schwungphase	67,6	52	0,29	bessere Schwungphasenerkennung
2	2	Lernprogramm über Schrittzähler	73,8	61	0,44	am besten – echte Gehhaltung
3	0	Aggressives „Stand-First“-Lernprogramm	64,9	68	0,28	längste Überlebenszeit
3	1	Explizite Gait-Clock-Referenz	65,3	43	0,28	mittelmäßig
3	2	Gelenkgeschwindigkeit + CoT-Effizienz	62,0	—	—	Ende des Laufs

Der beste Kandidat – Iteration 2, Kandidat 2 – erzielte 73,8/100 mit einer lehrplanförmigen Belohnung. Die eigene Begründung des LLM für dieses Design:

„Zu Beginn der Episode wird die Strategie fast ausschließlich für Haltung und Bodenkontakt belohnt, dann steigt die Gewichtung der Geschwindigkeit sanft an, sodass die Strategie zuerst lernt, stabil zu stehen, und erst dann dazu angeregt wird, sich vorwärts zu bewegen, wodurch der Fehlermodus ‚alle Prioren sterben bei Schritt ~50‘ direkt angegangen wird.“

Das ist ein kompetentes Stück Curriculum-Design. Es erzeugte eine Policy, die mit 0,44 m/s und 4 % bilateralem Ungleichgewicht (nahezu symmetrische Schritte), korrekter Links-Rechts-Abfolge und sichtbaren realistischen Gehhaltungen für 30–50 Frames vorwärtsgeht – bevor sie bei Schritt 61 das Gleichgewicht verliert.

Es ist das, was dem Gehen am nächsten kommt, was in diesem Projekt mit einer Nicht-Mocap-Methode erzeugt wurde.

Es ist aber auch eindeutig kein Gehen. 61 Schritte entsprechen 1,22 Sekunden.

Was das LLM gut gemacht hat

Das Durchlesen der Begründungen der Kandidaten ist, ehrlich gesagt, eine angenehmere Erfahrung als das Durchlesen des Notizbuchs eines menschlichen Forschers. Vier Dinge, die das LLM besser gemacht hat als erwartet:

1. Es hat auf tatsächlichen Fehlermodi iteriert. Nachdem es den strukturierten Fehler von Kandidat 1 in Iteration 1 gesehen hatte („Roboter fällt: übersteht nur 44/1000 Schritte“), beginnt Kandidat 0 in Iteration 2 ausdrücklich mit: „direkter Angriff auf den vorherigen Fehlermodus ‚hohe vx, Sturz in 40 Schritten‘.“ Das LLM liest die Fehler der vorherigen Runde und schlägt Änderungen vor, die darauf abzielen.
2. Es schlug bei jeder Iteration strukturell unterschiedliche Belohnungen vor. Keine zwei Kandidaten weisen dieselbe Form auf. Die 12 Kandidaten unterscheiden sich hinsichtlich multiplikativer Gating-Verfahren, Lehrplänen, Min-Aggregation, Kontaktdiskriminierung und Gang-Uhr-Referenzen. Das LLM bleibt nicht bei einer einzigen Vorlage hängen.
3. Es griff auf das Projektgedächtnis zurück. Wenn es relevant war, bezog sich das LLM auf gespeicherte Notizen zur „Standing-Still-Falle“ und auf frühere hybride CPG+RL-Ergebnisse. Es las den verfügbaren Kontext, nicht nur das unmittelbare Fehlerprotokoll.
4. Es korrigierte sich selbst bei degenerierten Lösungen. Als der Curriculum-Ansatz von Kandidat 2 in Iteration 2 bei 61 Schritten an die Grenze stieß, schlugen die Kandidaten in Iteration 3 aggressivere Curriculum-Varianten vor – was das Überleben auf 68 Schritte verlängerte, bevor es zu Einbußen bei der Gangqualität kam. Das LLM diagnostizierte die Überlebensgrenze korrekt als Engpass, auch wenn es diesen nicht beheben konnte.

Wenn die Frage lautete: „Kann ein LLM Belohnungsfunktionen durchdacht entwerfen?“, lautet die Antwort aus diesem Experiment Ja. Die Vorschläge sind einfallsreich, die Iteration ist prinzipientreu und die Schleife konvergiert.

Was nicht funktionierte – die Überlebensklippe

Jeder Kandidat scheiterte bei Schritt 70. Einige bei 30, einige bei 68, alle unter 70. Dies ist der anhaltende Fehlermodus, und er ist struktureller Natur, nicht mit dem Belohnungsdesign verbunden:

• Erkundung beim Kaltstart. Episoden beginnen in der nominalen Standhaltung mit null Geschwindigkeit. Die Policy hat keinen Schwung, mit dem sie arbeiten kann, keine Körperwinkelhistorie und befindet sich sofort an der Grenze der Bewegungsbeschränkung (Becken ~0,79 m, ~0,24 m Spielraum vor dem Abbruch bei 0,55 m).
• Keine Erholungsdaten in der Trajektorienverteilung. PPO lernt aus den Trajektorien, die es sieht. Bei Kaltstarts erlebt die Strategie niemals Neigungen während des Gehens oder Beinahe-Sturz-Zustände. Bis die Strategie überhaupt gelernt hat, einen Schritt nach vorne zu machen, ist jedes kleine seitliche Wackeln fatal – es gibt keine Erholungsfähigkeiten in der Strategie, da es keine Erholungsszenarien in den Daten gibt.
• Das Belohnungsdesign behebt dies nicht. Unterschiedliche Belohnungen führen zu unterschiedlichen Stilen des Stürzens – Einknicken des Knies, Stolpern nach hinten, asymmetrisches Hüpfen, Überdrehen nach vorne –, aber der Fehlermodus ist derselbe: Nach ~50–70 Schritten stößt die Strategie auf einen Zustand, den sie während des Trainings noch nie gesehen hat und auf den sie keine erlernte Reaktion hat.

Die Belohnung kann alles Mögliche sein, von „verfolge dieses spezifische Gang-Takt-Signal“ bis hin zu „belohne bilateralen Fußkontakt bei diesem Bruchteil“ – und die Strategie stürzt immer noch im gleichen Zeitfenster von 50–70 Schritten. Der Engpass liegt nicht darin, was die Belohnung verlangt. Es liegt daran, dass die Strategie in ihrer Trainingsverteilung nichts hat, was ihr eine Antwort ermöglicht.

Erweiterung des Trainingsbudgets – ein noch größerer Fehlschlag

Wir nahmen den besten Kandidaten (Iteration 2, Kandidat 2, curriculum-geformt) und trainierten ihn für das Vierfache des Budgets – 10 Millionen PPO-Schritte statt 2,5 Millionen. Hypothese: Vielleicht ist die Belohnung richtig, das Netzwerk braucht nur mehr Trainingszeit, um sie zu verinnerlichen.

Ergebnis. Die Fitness sank auf 60,9. Die Episodenlänge stieg auf 105 Schritte. Der Roboter läuft nun rückwärts mit -0,42 m/s, bei perfektem bilateralen Gleichgewicht (1,3 % Ungleichgewicht) und einem 1,0-Doppelstütz-Score.

Das zusätzliche Training hat die Vorwärtsbewegungskomponente des Lehrplans in ein stabiles Rückwärtslauf-Basin zusammengefasst. Die Belohnung gab der Policy genügend Zeit, um zu entdecken, dass man, wenn man rückwärts läuft, unbegrenzt stehen bleiben kann. Sie fand ein lokales Optimum, das die neuen bilateralen und Bodenhaftungskriterien besser erfüllte als der Vorwärtslaufversuch – auf Kosten einer falschen Richtung.

Dies ist der zweite Nagel im Sarg. Die Überlebensklippe ist kein Budgetproblem. Es ist ein Problem der Zustandsraumabdeckung. Wenn man 4× Rechenleistung auf eine Belohnung wirft, die der Strategie keinen Zugang zu Erholungszuständen während des Gehens gewährt, lässt man die Strategie lediglich eine stabilere Degeneration entdecken.

Warum Eureka hier unzureichend ist

Der Erfolg von Eureka bei Manipulationsaufgaben (Stiftdrehen, Schubladenöffnen) beruht auf einer Eigenschaft, die das humanoide Gehen nicht besitzt: einem Weg von der zufälligen Erkundung zur Aufgabenvollendung, den die vom LLM entworfene Belohnung formen kann.

Beim Stiftdrehen kann die Strategie zufällig umherfuchteln und gelegentlich etwas Stiftdreh-ähnliches hervorbringen, das die Belohnung als Fortschritt identifiziert. Die Belohnung lenkt die Strategie dann in diese Richtung. Die zufällige Erkundung berührt die Erfolgsmansarde oft genug, damit die Belohnung die Steuerung übernehmen kann.

Beim Cold-Start-Humanoid-Laufen führt die zufällige Erkundung zu Stürzen. Stürze beenden die Episode innerhalb von 5–15 Schritten, bevor die Strategie etwas Laufen-ähnliches entdecken kann. Die Belohnung kann nicht formen, was die Strategie niemals hervorbringt.

Dies ist das Zustandsraumabdeckungsproblem, das in der Literatur zum imitativen Lernen gut untersucht ist. DeepMimics Reference State Initialization (RSI) löst es, indem Episoden an zufälligen Phasen einer Motion-Capture-Referenz beginnen – so sieht die Policy bereits ab Trainingsschritt 1 Zustände in der Mitte eines Gehens. Die Policy lernt Wiederherstellungsfähigkeiten, da die Trajektorienverteilung Szenarien kurz vor einem Sturz enthält.

Ohne Motion Capture gibt es keine offensichtliche Quelle für RSI-Zustände. Man kann nicht bei „Phase 0,3 eines Gehzyklus“ initialisieren, wenn man keinen Gehzyklus hat, auf den man verweisen kann.

Self-RSI – der halbe Schritt, der nicht half

Wir haben Self-RSI ausprobiert: Sammeln von (qpos, qvel)-Snapshots aus den Rollouts einer kurzen Aufwärm-Policy und Verwendung dieser als Startzustände für das Haupttraining. Die Idee ist, die Abdeckung aus dem zu bootstrappen, was auch immer die Aufwärm-Policy produzieren kann, selbst wenn sie degeneriert ist.

Es half – die Überlebensdauer sprang von der ~50-Schritte-Klippe auf etwa 200 Schritte. Aber die zugrunde liegende Warmup-Policy war ein Einbeinspringer, und die RSI-Verteilung erbte diese Sprungtendenz. Die mit Self-RSI trainierte Policy lief weiter, aber im Einbeinmodus.

Die Zustandsraumabdeckung durch ein hüpfendes Warm-up liefert einen besseren Hüpfer, keinen Geher. Die Lehre hier ist, dass RSI funktioniert, wenn die Referenztrajektorie gut ist. Wenn das Einzige, woraus man RSI ableiten kann, ein degenerierter Gang ist, hat man lediglich eine robustere Version dieser Degeneration geschaffen.

Damit Self-RSI für das Gehen ohne Motion-Capture funktioniert, bräuchte man eine nicht-degenerierte Warm-up-Strategie. Eine solche zu erstellen, ist genau das Problem, das Self-RSI eigentlich lösen sollte. Der Henne-Ei-Zirkel ist die eigentliche Herausforderung für die Forschung.

Implikationen

Für Praktiker, die ein LLM-iteriertes Belohnungsdesign in Betracht ziehen:

1. Es ist ein echtes Werkzeug, insbesondere für Aufgaben, bei denen der Belohnungsdesignraum groß und die Fehlermodi vielfältig sind. Das LLM erkennt Designfehler, die Menschen nicht vorhersehen. Die Bandbreite der Kandidatenvariationen über unsere 12 Versuche hinweg ist größer als das, was ein einzelner Forscher in derselben Zeit hervorbringen würde.
2. Es ist kein Ersatz für die Zustandsraumabdeckung. Wenn Ihre Aufgabe einen Abdeckungsengpass aufweist – zufällige Erkundung kann die Aufgabenvollendung nicht erreichen –, erkundet Eureka zwar den Design-Raum, löst aber nicht das zugrunde liegende RL-Problem. Diagnostizieren Sie den Engpass, bevor Sie entscheiden, welches Werkzeug Sie anwenden.
3. Die Methodik ist wiederverwendbar. Unser Framework (g1_configurable_env.py, llm_reward_loop.py, walking_fitness.py) ist aufgabenunabhängig. Setzen Sie ein anderes Zustands-Dict und eine andere Fitnessfunktion ein, und die LLM-Iteration greift. Wenn Ihr Problem durch das Belohnungsdesign begrenzt ist, ist dies ein guter Multiplikator.

Speziell für Forscher im Bereich der humanoiden Fortbewegung:

1. Das erste uns bekannte negative Ergebnis von Eureka bei der Kaltstart-Fortbewegung von humanoiden Zweibeinern. Die Methodik lässt sich von der Manipulation verallgemeinern, aber die Einschränkung der Zustandsabdeckung bleibt bestehen. Die Belohnungsiteration reicht nicht aus.
2. Die Belohnungsvorschläge des LLM sind überraschend kreativ. Es lohnt sich, die Begründungen zu lesen – viele wären vernünftige menschliche Entscheidungen gewesen. Curriculum-by-Step-Counter, minimal aggregierte Korrektheit pro Fuß, Unterscheidung zwischen Stand- und Schwungphase anhand der Gelenkgeschwindigkeit – nichts davon findet sich im Standard-Rezeptbuch für humanoides RL. Das LLM generiert echte Signale darüber, welche Belohnungsformen plausibel sind, selbst wenn keine davon die Überlebensschwelle überschreitet.
3. Starke Einschränkungen durch Terminierung bleiben der zuverlässigste Schutz vor Betrug. Belohnungsgewichte lassen sich manipulieren; Terminierung auf physikalischer Ebene hingegen nicht. Die beiden Terminationen, die wir zu Beginn dieses Experiments hinzugefügt haben, hielten jeden Kandidaten ehrlich – keiner von ihnen versuchte, die Beckenhöhe oder den Nicht-Fußkontakt auszunutzen, weil sie es nicht konnten.

Was wir als Nächstes versuchen würden

Zwei Folgeversuche, die die Überlebensklippe tatsächlich überwinden könnten:

VLM-Kritik als Ersatz für die handcodierte Fitness. Ein Vision-Language-Modell soll die Natürlichkeit des Rollouts bewerten und dies als Fehlerzusammenfassung bereitstellen. Dies löst das Bewertungsproblem (das Erkennen degenerierter Gangarten, die handcodierte Metriken übersehen), aber nicht das Abdeckungsproblem. Wir haben dies weiterverfolgt – das ist der VLM-Kritik-Beitrag – und das Ergebnis war eine eigene Form des negativen Befunds.

LLM-Belohnungsiteration auf Basis von v12 (einer funktionierenden Mocap-Strategie), nicht von Null an. Nutze das LLM, um die Gangqualität einer bereits funktionierenden Strategie zu verfeinern, anstatt zu versuchen, das Gehen von Grund auf neu aufzubauen. Dies umgeht das Problem der Abdeckung bei Null-Start vollständig und sollte zu einem veröffentlichungsfähigen Ergebnis in Form einer „Verfeinerung des natürlichen Gangs“ führen. Wir haben dies noch nicht getestet. Es ist das vielversprechendste nächste Experiment in diesem Thread.

Das allgemeine Muster: Sobald man eine Policy hat, die schlecht laufen kann, ist die LLM-Belohnungsiteration gut geeignet, um sie gut laufen zu lassen. Den schlechten Läufer von Grund auf neu zu erstellen, ist der schwierige Teil, und dafür ist die Belohnungsiteration nicht gedacht.

Rechenaufwand

Jeder Kandidat: 2,5 Mio. PPO-Schritte × ~2200 fps × 16 Umgebungen ≈ 20 Minuten Rechenzeit. 4 Iterationen × 3 Kandidaten = 12 Kandidaten ≈ 4 Stunden Rechenzeit pro Runde. Erweitertes Training: 5,7 Mio. Schritte ≈ 45 Minuten. Alles auf einer einzigen 4-GB-Laptop-GPU.

LLM-API-Kosten: null – Nutzung eines Claude-Code-Abonnements über das Agent SDK, keine Gebühren pro Token. Die gesamte Versuchsrunde (24 Kandidaten, zwei Fitnessfunktionen, erweitertes Training sowie die Analyse-Läufe) kostete etwa 8 GPU-Stunden und einige Stunden LLM-Dialog.

Dies ist eine für einen einzelnen Forscher gut umsetzbare Methodik. Der Rechenaufwand ist gering. Die Schlussfolgerung – dass Belohnungsiteration allein für den Kaltstart des humanoiden zweibeinigen Gehens nicht ausreicht – ist über unsere beiden Durchläufe und das erweiterte Trainingsexperiment hinweg robust.

Wie geht es weiter?

Die Serie endet mit einem weiteren Beitrag zu diesem Thema.

Nachdem handcodierte Fitnessfunktionen immer wieder Degenerationen übersehen hatten (v16 Hopping) und nachdem LLM-iterierte Belohnungen an die Überlebensgrenze stießen (dieser Beitrag), versuchten wir den naheliegenden nächsten Schritt: ein Vision-Language-Modell die Rollouts bewerten zu lassen. Die Hypothese war, dass ein menschenähnliches qualitatives Urteil das erfassen würde, was Metriken nicht konnten.

Das tat es und das tat es nicht. Das Ergebnis ist Das VLM, das einem zusammenbrechenden Roboter 62/100 Punkte gab – eine weitere ehrliche Darstellung dessen, wo die Abstraktion versagt. Das Muster, das sich durch die drei diagnostischen Beiträge dieser Reihe zieht (Reward-Hacking, dieser Beitrag und die VLM-Kritik), ist, dass jeder Versuch, die Überwachung zu automatisieren, eine neue Art von Fehlern hervorbrachte, nicht gar keine Fehler. 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 ausgewählte Posen ausreichen.