Wie man eine Roboter-Policy tatsächlich misst
Eine Roboter-Policy kann bei einem Benchmark 90 % erzielen und im Feldeinsatz trotzdem versagen. Die Fallstricke der Policy-Evaluation, und wie man eine Policy ehrlich testet.
Eine Roboter-Policy erzielt bei einem Benchmark 90 %, und die Schlagzeile schreibt sich von selbst. Neunzig Prozent wovon allerdings: wie gemessen, über wie viele Versuche, an welchen Objekten. Eine Zahl auf einer Bestenliste ist die Komprimierung eines Experiments, und das meiste von dem, was man bräuchte, um ihr zu vertrauen, ist bei dieser Komprimierung verloren gegangen.
Evaluation ist die stille Krise des Roboterlernens. Fast alle sind sich einig, dass die Policies besser werden. Fast niemand ist sich einig, wie man das beweist. Eine Manipulations-Policy ist kein Sprachmodell, das man über Nacht an einem eingefrorenen Testdatensatz benoten kann. Jeder Versuch kostet einen physischen Roboter, ein Reset und einen Menschen, der ihn erneut laufen lässt, und die Welt weigert sich, zwischen den Durchläufen stillzuhalten: Das Licht verändert sich, das Objekt rollt einen Zentimeter weiter, der Greifer nutzt sich ab.
Dieser Beitrag bezieht daher Position. Die meisten berichteten Erfolgsquoten von Robotern liegen näher an Anekdoten als an Messungen, und diese Lücke ist keine Nachlässigkeit. Ehrliche Evaluation ist teuer, langsam und wenig schmeichelhaft, und genau deshalb wird sie übersprungen. Die Teams, deren Policies den Kontakt mit der realen Welt überleben, sind jene, die Evaluation als erstrangiges Experiment behandeln: genug Versuche, um ein Konfidenzintervall zu tragen, Bedingungen, auf die die Policy nie trainiert wurde, und Fehlermodi, die berichtet statt verborgen werden.
Die Zahl ist eine Komprimierung, und sie lässt die Fehlerbalken weg
Beginnen wir mit der Statistik, denn sie ist unnachgiebig und wird routinemäßig ignoriert. Roboter-Evaluationen berichten ein binäres Ergebnis, Erfolg oder Misserfolg, über eine Handvoll Versuche. Bewertet man eine Policy mit 8 von 10, fühlt sich das wie eine solide Note an. Berechnet man das binomiale Konfidenzintervall, kann die tatsächliche Erfolgsquote plausibel irgendwo zwischen etwa 50 % und 95 % liegen. Zehn Versuche können diesen Unterschied schlicht nicht auflösen. Schlimmer noch: Bei jeweils zehn Versuchen lässt sich eine Policy, die 8 von 10 erzielt hat, nicht zuverlässig von einer unterscheiden, die 6 von 10 erzielt hat: Die Intervalle überlappen sich fast vollständig.
Das ist keine Haarspalterei, das ist der Unterschied zwischen einer Demo und einer Messung. Toyota Research Institute hat sich in seiner Arbeit zu Large Behavior Models ungewöhnlich unverblümt dazu geäußert: Dort wird Evaluation als echtes Experiment durchgeführt, mit vielen Versuchen, blinden und randomisierten A/B-Vergleichen, damit die Hoffnung des Operators nicht in die Art einfließt, wie eine Szene zurückgesetzt wird, und mit statistischen Tests, bevor eine Änderung als Verbesserung erklärt wird. Nichts davon ist glanzvoll. All das ist es jedoch, was eine Policy, die an einem Dienstag Glück hatte, von einer wirklich besseren unterscheidet.
Simulationsbenchmarks belohnen das Falsche
Simulatoren sind günstig, schnell und perfekt reproduzierbar, und genau deshalb sind sie verführerisch, und genau deshalb führen sie in die Irre. Eine Policy kann in einem Simulationsbenchmark aufsteigen, indem sie sich an die Eigenheiten einer bestimmten Physik-Engine und eines bestimmten Renderers anpasst statt an die Aufgabe. Das Kontaktmodell ist eine Näherung; überanpasst man sich daran, erhält man eine Policy, die auf eine Welt abgestimmt ist, die es nicht gibt.
Diese Lücke ist nicht einheitlich. Für Fortbewegung und Ganzkörperkontrolle überträgt sich Simulation gut, dort, wo die Starrkörperdynamik originalgetreu modelliert ist und die Forschung stark auf Domain Randomization gesetzt hat. Schlecht überträgt sie sich für die kontaktreiche Manipulation, die man sich am meisten wünscht: weiche, verformbare oder gegliederte Objekte, wo ein Simulator, der ein sich faltendes Tuch oder einen abrutschenden Griff nicht darstellen kann, bereitwillig eine selbstsichere Policy trainiert, die am realen Objekt scheitert. Ein Großteil der Sim2Real-Literatur bei Berkeley BAIR und in den cs.RO-Preprints kreist um dieselbe Warnung: Ein Simulationswert ist eine Hypothese über die reale Welt, keine Messung von ihr. Ein Benchmark, der nie einen echten Greifer berührt, misst, wie gut man eine Physik-Engine überanpasst.
Das Aufgabenset leistet mehr Arbeit als die Metrik
Bevor man über die Metrik streitet, sollte man betrachten, worüber sie überhaupt berechnet wurde. Das Aufgabenset entscheidet still über das Ergebnis. Wer an denselben Objekten, denselben Szenen und derselben Beleuchtung evaluiert, an denen die Policy trainiert wurde, hat Auswendiglernen gemessen, keine Kompetenz. Es wird so lange gelöst aussehen, bis das Handtuch rot statt blau ist oder die Sonne über den Tisch wandert.
Geteilte Benchmarks helfen, und das Feld hat gute geschaffen. Open X-Embodiment hat die Evaluation über viele Roboter und Institutionen hinweg gebündelt, genau damit Ergebnisse auf gemeinsamem Boden verglichen werden können. Aber selbst ein geteilter Benchmark lässt sich austricksen, indem nur die freundlichen Aufgaben berichtet werden, und eine einzelne aggregierte Erfolgsquote verbirgt, welche Bedingungen die Punktzahl getragen haben. Das ehrliche Protokoll ist unspektakulär und schwer zu fälschen: Objekte, Szenen und Beleuchtung zurückhalten, welche die Policy nie gesehen hat, die Anzahl der Versuche vorab festlegen und pro Bedingung berichten statt eines einzigen schmeichelhaften Durchschnitts. Liegt der Wert auf den zurückgehaltenen Daten weit unter dem Wert auf den gesehenen Daten, ist diese Lücke der eigentliche Befund, keine Fußnote.
Die Erfolgsquote verbirgt, wie eine Policy erfolgreich war, und wie sie scheiterte
Binärer Erfolg ist eine verlustbehaftete Metrik, selbst wenn Statistik und Aufgabenset ehrlich sind. Eine Policy, die sich mit einem fahrigen, knapp danebengehenden Griff gerade noch durchmogelt, und eine, die das Objekt beim ersten Versuch sauber ergreift, erzielen dieselbe Punktzahl, doch nur eine der beiden übersteht einen zusätzlichen Millimeter Unordnung. Die Erfolgsquote verzeichnet das Ergebnis und löscht den Spielraum.
Eine reichhaltigere Evaluation berichtet mehr als nur ein Bit. Teilpunkte für den Aufgabenfortschritt unterscheiden eine Policy, die auf halbem Weg war, von einer, die nie angefangen hat. Ein Robustheitsspielraum, also wie viel Störung eine Policy toleriert, bevor sie versagt, sagt das Verhalten im Feld weit besser voraus als der Erfolg im Reinraum. Am wertvollsten und am meisten vernachlässigt ist die Wiederherstellung: Bemerkt die Policy einen Fehler und korrigiert ihn, oder kaskadiert ein einziges Abrutschen in einen ganzen Haufen von Fehlschlägen. Arbeiten von Gruppen wie Stanford IRIS zum Imitation Learning betonen seit Langem, dass es Robustheit und Wiederherstellung sind, nicht makellose Demonstrationen, die generalisieren. Die Fehlermodi zu berichten ist kein Eingeständnis von Schwäche, sondern die nützlichste Information, die eine Evaluation hervorbringt.
| Evaluationsansatz | Was er misst | Wie er in die Irre führt |
|---|---|---|
| Simulationsbenchmark | Verhalten in einer modellierten Welt, günstig und reproduzierbar | Belohnt das Überanpassen an Physik-Engine und Renderer; Kontakt und verformbare Objekte brechen den Transfer |
| Kleiner Satz realer Versuche | Tatsächlicher Erfolg am Roboter | Konfidenzintervall so breit, dass es zwei Policies nicht trennen kann |
| In-Distribution-Aufgabensuite | Kompetenz bei trainierten Objekten und Szenen | Bewertet Auswendiglernen; bricht zusammen, sobald sich Objekte, Unordnung oder Beleuchtung ändern |
| Binäre Erfolgsquote | Ob die Aufgabe abgeschlossen wurde | Ignoriert Spielraum, Robustheit und Wiederherstellung; ein knapper Fehlgriff steht gleichauf mit einem sauberen Griff |
| Handverlesener oder Best-of-N-Durchlauf | Die Obergrenze bei einer freundlichen Aufgabe | Berichtet den besten Versuch, nicht den erwarteten; ein Zusammenschnitt der Glanzmomente, kein Durchschnitt |
Eine Benchmark-Zahl sagt, wie eine Policy bei genau der Aufgabe abgeschnitten hat, für die sie bewertet wurde. Ob sie in der realen Welt funktioniert, ist eine andere Frage, und nur zurückgehaltene Versuche, ehrlich gezählt, können sie beantworten.
Ein gutes Evaluationsset ist erfasste Daten, kein Bauchgefühl
All das läuft auf eine unbequeme Anforderung hinaus. Zurückgehaltene Objekte, zurückgehaltene Szenen, kontrollierte Beleuchtung und wiederholbare Resets erscheinen nicht auf Zuruf. Um als fairer Test zu funktionieren, muss ein Evaluationsset so sorgfältig erfasst, instrumentiert und dokumentiert werden wie die Trainingsdaten, sonst lässt es sich im nächsten Quartal nicht reproduzieren, und seine Zahlen lassen sich nicht zwischen Teams vergleichen. Eine Evaluation, die man nicht erneut laufen lassen kann, ist eine Geschichte, kein Benchmark. Die unbequeme Wahrheit ist, dass der Bau eines harten, ehrlichen Testsets dasselbe Handwerk ist wie der Bau eines guten Trainingssets, und ungefähr genauso teuer.
Wenn also das nächste Mal eine Roboter-Policy mit 90 % gemeldet wird, sollten die drei Fragen gestellt werden, die die Zahl verschüttet hat: Wie viele reale Versuche stehen dahinter, unter welchen zurückgehaltenen Bedingungen, und wie sahen die Fehlschläge tatsächlich aus. Ist die Antwort eine einzelne Zahl über ein freundliches Aufgabenset, blickt man auf einen Zusammenschnitt der Glanzmomente. Kommt die Antwort dagegen mit einem Intervall, einer Lücke bei den zurückgehaltenen Daten und einer ehrlichen Bilanz der Fehlschläge, blickt man auf eine Messung, und solche sind weitaus seltener, als es die Ranglisten suggerieren.