Reward-Modelle für das Roboterlernen, und warum Rewards scheitern

Hier ist eine Aufgabe, die trivial klingt: einen Roboter dafür belohnen, dass er ein Geschirrteil in einen Geschirrkorb stellt. In einem Simulator schreiben Sie eine einzige Zeile, Reward gleich eins, wenn das Geschirrteil richtig sitzt, sonst null, und Reinforcement Learning erledigt den Rest. Auf einem echten Roboter lässt sich diese Zeile nicht schreiben, weil nichts im System zuverlässig erkennen kann, ob das Geschirrteil richtig sitzt.

Genau diese Lücke ist das eigentliche Problem. Reinforcement Learning braucht bei jedem Schritt einen Reward, und bei Manipulationsaufgaben ist der Reward genau das, was sich nicht messen lässt. Gelenkwinkel lassen sich messen. Ob ein Hemd ordentlich gefaltet ist oder ob ein Stecker vollständig eingesteckt ist, lässt sich nicht messen, ohne im Grunde bereits die Wahrnehmung gelöst zu haben.

Das Feld verlagert den schwierigen Teil daher unauffällig. Statt Rewards von Hand zu schreiben, lernen Teams sie, aus menschlichen Präferenzen, aus Demonstrationen, aus Video. Das verändert, welche Daten ein Robotik-Team tatsächlich braucht, und es hilft zu verstehen, warum handgeschriebene Rewards scheitern, bevor man sich ansieht, was an ihre Stelle tritt.

Warum handgeschriebene Rewards scheitern

Reward-Engineering funktioniert in Spielen hervorragend. Der Punktestand steigt, also steigt der Reward. Physische Manipulation hat drei Eigenschaften, die diesen sauberen Kreislauf zerstören.

Der Reward ist nicht beobachtbar. Erfolg ist eine Aussage über die Welt, etwa dass die Tasse aufrecht steht, voll ist und auf dem Untersetzer steht, und dies aus rohen Sensordaten abzulesen, ist selbst schon ein schwieriges Wahrnehmungsproblem. Mit einem perfekten Erfolgsdetektor wäre man bereits auf halbem Weg zu einer Policy.

Dichtes Shaping geht nach hinten los. Um spärliche Rewards zu vermeiden, fügen Ingenieure Shaping-Terme hinzu: näher an die Tasse heran, kleiner Reward; Greifer ausrichten, kleiner Reward. Roboter nutzen dann den Wortlaut des Rewards aus. Eine Policy schwebt bereitwillig endlos neben der Tasse und sammelt Näherungs-Reward, ein Verhalten, das als Reward-Hacking bekannt ist und in der Reinforcement-Learning-Forschung von Gruppen wie dem Google DeepMind-Blog gut dokumentiert ist.

Kontakt macht es spröde. Kleine Änderungen bei Kraft oder Timing verwandeln Erfolg in Misserfolg, sodass ein Reward, der auf ein Objekt, eine Pose und einen Tag abgestimmt ist, sich selten übertragen lässt. Jede neue Aufgabe wird zu einem neuen Reward-Tuning-Projekt. Das skaliert nicht auf die Tausenden Fähigkeiten, die ein Humanoid braucht.

In der Reward-Funktion steckt heimlich der Großteil des menschlichen Aufwands beim Reinforcement Learning für Roboter, und sie von Hand zu schreiben, skaliert nicht über eine Demo hinaus.

Was ein gelerntes Reward-Modell leistet

Ein gelerntes Reward-Modell ersetzt die handgeschriebene Regel durch eine trainierte Funktion, die bewertet, wie gut ein Zustand oder eine Trajektorie ist. Man füttert sie mit einer Beobachtung, sie liefert eine Zahl zurück. Die Policy optimiert gegen diesen gelernten Wert statt gegen eine von Menschen verfasste Formel. Woher kommt dieser Wert? Aus drei Hauptquellen.

Menschliche Präferenzen

Zeigen Sie einer Person zwei kurze Clips, in denen der Roboter eine Aufgabe versucht, und fragen Sie, welcher besser ist. Sammeln Sie Tausende solcher Vergleiche und passen Sie dann ein Reward-Modell an, das mit der menschlichen Rangfolge übereinstimmt. Das ist dasselbe Preference-Learning-Rezept, mit dem große Sprachmodelle abgestimmt wurden, nur angewandt auf physisches Verhalten. Es umgeht das Problem der Unbeobachtbarkeit, weil ein Mensch den Erfolg direkt beurteilt.

Der Aufwand ist real. Jeder Vergleich ist eine menschliche Entscheidung, und bei unübersichtlichen Clips mitten im Versuch sind sich die Bewertenden uneinig, sodass die Labels verrauscht sind. Doch das Rauschen mittelt sich über Tausende Urteile hinweg aus, und am Ende bewertet das Modell Verhalten so, wie Menschen es tatsächlich tun, nicht so, wie ein Ingenieur es vermutet hätte.

Demonstrationen als impliziter Reward

Liegen Expertendemonstrationen vor, lässt sich der Reward ableiten, der diese Demonstrationen als optimal erscheinen lässt, die Grundidee hinter Inverse Reinforcement Learning. Hier tragen die Daten selbst, der Mensch, der die Aufgabe vorführt, das Reward-Signal. Akademische Gruppen wie der Berkeley BAIR-Blog verfolgen diesen Ansatz seit Jahren.

Video und Foundation Models als Richter

Ein großes Vision-Language-Modell lässt sich per Prompt dazu bringen, zu bewerten, ob ein Bild Aufgabenerfolg zeigt, wodurch ein allgemeines Modell zu einer groben Reward-Funktion wird. Das ist verrauscht, skaliert aber, und es braucht kein aufgabenspezifisches Engineering. Gruppen, die an generalistischen physischen Agenten arbeiten, darunter das NVIDIA GEAR Lab-Forschung und der Physical Intelligence-Blog, setzen auf gelernte und modellbasierte Signale statt auf handjustierte Rewards.

Was das für die Daten bedeutet, die Sie erfassen

Die Verschiebung von geschriebenen zu gelernten Rewards verlagert die Last auf die Daten und verändert, welche Art von Daten wertvoll ist. Kommt Ihr Reward aus Präferenzen, brauchen Sie paarweise Vergleiche und, entscheidend, Fehlversuche, die Sie den Erfolgen gegenüberstellen können. Kommt er aus Demonstrationen, wird die Demo-Qualität zur Qualität des Rewards. So oder so ist ein Datensatz aus ausschließlich sauberen Erfolgen weniger wert als ein Datensatz, der auch Beinahe-Fehlschläge, Korrekturen und klare Fehlversuche erfasst, weil ein Reward-Modell die Grenze zwischen gut und schlecht von beiden Seiten lernt.

Es gibt einen subtileren Punkt zur Balance. Ein Reward-Modell, das nur mit fehlerfreien Durchläufen trainiert wurde, lernt nie, was ein kleiner Fehler kostet, und kann eine Policy daher nicht vom Rand zurückführen. Gefragt ist eine Bandbreite: eindeutige Erfolge, knappe Erfolge und ehrliche Fehlversuche, jeweils gekennzeichnet. Diese Bandbreite zu kuratieren, ist eine Entscheidung der Datenerfassung, die lange vor jedem Trainingslauf getroffen wird.

Das ist ein wiederkehrendes Thema in aktueller, auf arXiv Robotics (cs.RO) indexierter Robotik-Forschung. Reward, Policy und Daten sind keine voneinander trennbaren Probleme. Entscheiden Sie, wie Sie Verhalten bewerten wollen, und Sie haben bereits zur Hälfte entschieden, was Sie erfassen.

Der Reward ist jetzt ein Datenproblem

Rewards scheitern in der realen Welt aus einem Grund, der leicht zu benennen und schwer zu beheben ist: Das, was Sie belohnen wollen, ist genau das, was Sie nicht sehen können. Gelernte Reward-Modelle beseitigen diese Schwierigkeit nicht. Sie verlagern sie, aus der Formel eines Ingenieurs heraus und in einen Datensatz aus menschlichen Urteilen und Demonstrationen hinein. Das ist Fortschritt, weil Daten skalieren und manuelles Nachjustieren nicht. Es bedeutet auch, dass die Reward-Funktion keine Fußnote eines Trainingslaufs mehr ist. Sie ist ein Datenproblem, und wer die richtigen Vergleiche und Fehlversuche erfasst, besitzt ein Stück davon.