Warum das Daten-Schwungrad für Roboter Fehlschläge braucht, nicht nur Erfolge

Eine Roboter-Policy, die nur je gesehen hat, wie Dinge gut ausgehen, weiß nicht, was zu tun ist, wenn sie schiefgehen. Zeigt man ihr zehntausend saubere Griffe, lernt sie den sauberen Griff hervorragend. Im Einsatz streift der Greifer dann die Tasse, die Tasse kippt um einen halben Zentimeter, und die Policy blickt auf eine Szene, die in keiner Demonstration je vorkam. Sie hat dafür keine Handlung parat. Die eine Fähigkeit, die sie jetzt braucht, nämlich sich zu erholen, war ausgerechnet das, was aufzuzeichnen niemand für nötig hielt.

Fast jeder Erfassungsaufwand ist auf Erfolg ausgerichtet. Das ist nachvollziehbar: Eine Demonstration ist etwas, das der Roboter nachahmen soll, also behält man den Durchlauf, bei dem es funktioniert hat, und wirft den Fehlversuch weg. Doch eine Policy verbessert sich am schnellsten anhand der Zustände, in denen sie versagt, und genau diese Zustände lässt ein rein erfolgsbasierter Datensatz aus. Das Daten-Schwungrad, das sich alle wünschen, also einsetzen, erfassen, neu trainieren, verstärkt sich nur dann selbst, wenn der Erfassungsschritt Fehlschläge und Beinahe-Fehler einfängt, sie auswertet und den nächsten Erfassungsdurchlauf gezielt auf genau diese Zustände richtet.

Das Problem ist struktureller Natur, keine Frage der Disziplin. Fehlschläge sind in jedem kuratierten Datensatz seltener als Erfolge, sie sind aufwendiger zu speichern, und sie sind weitaus schwerer zu annotieren. Sich selbst überlassen, driftet jeder Datensatz in Richtung Survivorship Bias: ein ordentliches Archiv leichter Siege, das dem Modell schmeichelt und kaum etwas darüber verrät, wo es versagt.

Die Policy versagt, wo der Experte nie war

Beginnen wir mit dem Fehlermodus, der das Imitationslernen von Anfang an verfolgt. Trainiert man eine Policy, indem man Experten-Demonstrationen kopiert, lernt sie die Abbildung von Zuständen auf Aktionen nur für die Zustände, die der Experte tatsächlich besucht hat. Diese Demonstrationen sind konstruktionsbedingt ein schmales Band nahezu perfekter Trajektorien. Im Einsatz macht die Policy einen kleinen Fehler, dieser Fehler stößt sie vom Band ab, und schon befindet sie sich in einem Zustand, der etwas weiter von allem entfernt liegt, was sie im Training gesehen hat, wo ihre nächste Aktion ein wenig schlechter ausfällt. Fehler summieren sich. Das ist Covariate Shift, und deshalb kann eine Policy mit 99 % Schritt-für-Schritt-Genauigkeit bei einer Aufgabe mit langem Zeithorizont trotzdem in den meisten Fällen scheitern.

Die klassische Lösung, DAgger und seine Nachfolger, ist keine raffiniertere Loss-Funktion. Es ist eine Regel für die Datenerfassung: Man lässt die aktuelle Policy laufen, lässt sie in die Zustände abdriften, die sie tatsächlich erreicht, und sammelt genau dort Expertenkorrekturen. Arbeiten aus dem Berkeley BAIR und der breiteren cs.RO-Literatur entdecken denselben Punkt immer wieder in neuem Gewand: Die Daten, die eine Policy reparieren, sind nicht mehr von der idealen Trajektorie des Experten, sondern Abdeckung der Off-Distribution-Zustände, in die die Policy gerät, wenn sie beginnt, schiefzugehen. Diese Zustände liegen dicht neben Fehlschlägen, denn in Richtung eines Fehlschlags abzudriften ist genau das, was sie sind.

Recovery ist eine eigene Fähigkeit, und sie muss vorgeführt werden

Es gibt einen Unterschied zwischen einer Policy, die nicht versagt, und einer, die sich erholt, und nur Letztere übersteht den Kontakt mit der realen Welt. Recovery ist eine eigene Fähigkeit: erneutes Greifen nach einem Abrutschen, erneutes Anfahren nach einem Fehlversuch, das Zurückziehen aus einer Klemmung, um es aus einem anderen Winkel zu versuchen. Nichts davon taucht in einem Datensatz auf, in dem jede Episode mit einem sauberen Reset beginnt und mit Erfolg endet. Hat das Modell den Übergang von misslungen zu behoben nie gesehen, kann es diesen Übergang auch nicht auf Abruf herstellen.

Deshalb ist korrektive, interventionsbasierte Erfassung so wichtig. Ein menschlicher Supervisor beobachtet den Lauf der Policy, übernimmt in dem Moment, in dem sie zu versagen beginnt, demonstriert den Ausweg und gibt die Kontrolle danach zurück. Die wertvollen Bilder sind jene, die die Intervention einrahmen: das Abgleiten ins Problem und der Weg zurück heraus. Sie zu bekommen bedeutet, die Policy absichtlich ein Stück versagen zu lassen, was jedem Instinkt widerspricht, der sagt, Erfassung solle sauber sein. Ein Datensatz, der den Roboter nie straucheln lässt, kann ihm nie beibringen, sich selbst aufzufangen.

Hard Negatives, und der Wert, zu wissen, was man nicht tun soll

Erfolgreiche Demonstrationen sagen einem Modell, was zu tun ist. Sie schweigen darüber, was nicht zu tun ist, und dieses Schweigen wird teuer, sobald ein Modell Verhalten beurteilen, einordnen oder bewerten soll, statt es nur nachzuahmen. Ein Reward-Modell, eine Value-Funktion oder ein gelerntes World-Modell muss eine gute von einer schlechten Trajektorie unterscheiden können. Füttert man es nur mit guten, hat es keine Grundlage für diese Unterscheidung. Es hat die Grenze, die es ziehen soll, nie gesehen.

Hard-Negative-Mining ist die Disziplin, die Fehlschläge zu finden, die dem Erfolg am nächsten liegen, die Beinahe-Fehler, bei denen der Griff fast gehalten hätte oder der Stift fast gesessen hätte, und sie stark zu gewichten, denn genau diese Fälle legen die Grenze tatsächlich fest. Google DeepMind und andere Gruppen, die große Behavior- und World-Modelle bauen, behandeln Deployment-Logs zunehmend als Fundgrube für genau diese Zustände: jene, in denen die Policy unsicher war, oder in denen ein autonomer Lauf von dem abwich, was ein Mensch getan hätte. Ein leichter Fehlschlag, der Roboter verfehlt um Längen, lehrt wenig. Der Hard Negative, der Fehlschlag, der bis zum letzten Zentimeter wie ein Erfolg aussah, ist hundert saubere Erfolge wert.

Ein Datensatz aus nur Erfolgen bringt einem Roboter bei, Glück zu haben, nicht robust zu sein. Die Zustände, die einen Einsatz entscheiden, sind genau die, die niemand aufzeichnen wollte.

Warum sich die leichten Erfolge stapeln und die Fehlschläge nicht

Wenn Fehlschlagsdaten so wertvoll sind, warum sind sie dann so knapp? Weil jeder Teil der Pipeline sich verschwört, sie zu verwerfen. Teleoperation, noch immer das Arbeitspferd der hochwertigen Erfassung, produziert von Natur aus Erfolge: Ein geübter Operator patzt selten, und wenn doch, ist der Reflex, den Take zu löschen und neu zu machen. Fehlschläge sind ohnehin schon seltener, und die guten, die informativen Beinahe-Fehler, sind noch seltener. Sie sind aufwendiger zu speichern, oft unvollständig oder mehrdeutig, ohne sauberen Endzustand, an dem man sie verankern könnte. Und sie sind weitaus schwerer zu annotieren. Ein Erfolg beschriftet sich selbst, die Aufgabe ist erledigt. Ein Fehlschlag wirft Fragen auf, die ein Mensch beantworten muss: Wann genau ging es schief, was wäre in diesem Moment die richtige Aktion gewesen, und wie hätte Recovery ausgesehen. Diese Annotation ist langsam, subjektiv und leicht falsch zu machen.

Das Ergebnis zeigt sich in den öffentlichen Korpora. Die großen Teleoperations- und Cross-Embodiment-Datensätze, mit denen das Feld trainiert, bestehen überwältigend aus erfolgreichen Trajektorien, denn genau das galt unter der alten Annahme, man ahme Erfolge nach, als erhaltenswert. Toyota Research Institute hat in seiner Arbeit an großen Behavior-Modellen offen eingeräumt, dass eine ehrliche Evaluation, und damit auch ehrliches Training, davon abhängt, die Fälle abzudecken, in denen das Verhalten nachlässt, nicht nur jene, in denen es glänzt. Ohne Fehlschläge lässt sich Robustheit nicht einmal messen, geschweige denn dafür trainieren.

Der Vorteil gehört dem, der die Fehler behält

Der Instinkt, Erfolge zu sammeln, ist nicht falsch, er ist nur unvollständig. Eine Policy muss sehen, wie eine Aufgabe gut ausgeführt wird, und sie muss die Momente sehen, in denen die Aufgabe fast auseinanderfiel und noch gerettet wurde. Die Teams, die sich absetzen, sind nicht jene mit dem größten Haufen makelloser Demonstrationen. Es sind jene, die aufgehört haben, die Fehlschläge wegzuwerfen, gelernt haben, sie zu annotieren, und begonnen haben, den nächsten Erfassungsdurchlauf gezielt auf die Zustände zu richten, an denen ihr bestes Modell noch immer scheitert.