FailBank: Self-Evolution von Vision-Language-Action-Modellen durch Laufzeit-Feedback
FailBank ist ein vierstufiges Self-Evolution-Framework, das Laufzeit-Feedback einer CBF-basierten Sicherheitskomponente in persistente Policy-Verbesserungen für Vision-Language-Action-Modelle umwandelt. Ein Preprint auf arXiv berichtet, dass FailBank die Aufgabenerfolgsrate gegenüber den Basispolicies um 8,5 bzw. 6,9 Prozentpunkte steigert und die policy-induzierten kumulativen Kosten um 35,6 bzw. 23,8 Prozent senkt. Damit wird gezeigt, dass Laufzeitkorrekturen nicht nur temporäre Eingriffe, sondern auch Trainingssignal für künftiges Verhalten sein können.
Kann Laufzeit-Feedback in Lernaufzeichnungen umgewandelt werden, die selbst-evolvierende Policy-Updates ermöglichen und künftiges Verhalten verbessern?
Runtime Shields korrigieren einzelne Aktionen, lassen aber die zugrunde liegende Policy unverändert. Wiederholte Diskrepanzen zwischen Policy und Shield können den Aufgabenfortschritt blockieren, insbesondere in komplexen Szenen mit unbeabsichtigtem Kontakt. Bestehende Systeme lösen diesen persistenten Policy-Shield-Mismatch nicht auf.
Bisherige Ansätze wie AEGIS kombinieren CBF-Projektion mit visueller Fundierung als Laufzeit-Sicherheitsschicht, wirken aber nur temporär auf die Aktion und aktualisieren die Policy nicht. Weitere Methoden wie SafeVLA, SAFE oder constrained Flow Matching integrieren Sicherheit über eingeschränktes Lernen oder interne Repräsentationen, lassen jedoch die wiederkehrende Diskrepanz zwischen nominaler Policy und Sicherheitsmodul ungelöst.
FailBank nutzt eine feste CBF-Lehrerkomponente, die während der Rollout-Sammlung nur beobachtet und Gegenvorschläge protokolliert, ohne die Ausführung zu verändern. Die vier Stufen umfassen: erstens beobachtende Sammlung mit Gegenvorschlägen, zweitens ergebnisabhängige Zulassung von Korrekturzielen und erfolgreichen unkorrigierten Aktionen als stille Anker, drittens Akkumulation der zugelassenen Aufzeichnungen in einer Failure Bank, viertens Anpassung eines frischen LoRA-Adapters, der nur bei bestandener Holdout-Prüfung zu Flussverlust und Erstdrift akzeptiert wird. Im Einsatz benötigt die Policy nur RGB-Beobachtungen und Propriozeption.
Auf dem VLA-Arena-Benchmark über zwei Schwierigkeitsgrade und zwei VLA-Backbones steigert FailBank die mittlere Aufgabenerfolgsrate gegenüber den Basispolicies um 8,5 Prozentpunkte (pi_0.5) bzw. 6,9 Prozentpunkte (pi_0) und senkt die policy-induzierten kumulativen Kosten um 35,6 % bzw. 23,8 %. Gegenüber AEGIS beträgt der Erfolgsratengewinn 25,4 bzw. 9,5 Prozentpunkte bei vergleichbaren policy-induzierten Kosten. FailBank erreicht auf 8 von 10 Task-Backbone-Paaren eine gleichzeitige Verbesserung von Erfolg und Kosten, AEGIS nur auf 3. Die Generalisierung umfasst gehaltene Zustände, ungesehene Aufgaben und Level 2: auf pi_0.5 steigt die Erfolgsrate bei gehaltenen Mango-Zuständen von 71,1 % auf 93,3 %, bei ungesehenen Level-1-Aufgaben von 82,5 % auf 88,7 % und bei Level-2-Aufgaben von 50,5 % auf 59,4 %. Auf pi_0 steigt die Erfolgsrate bei ungesehenen Level-1-Aufgaben von 51,0 % auf 62,7 % und bei Level-2-Aufgaben von 35,7 % auf 40,0 %. In Ablationsstudien führt das Hinzufügen stiller Anker zu weiterer Kostensenkung bei gleicher Erfolgsrate, und über fünf Selbst-Evolutionsrunden wächst die Failure Bank von 3,7 k auf 22,7 k Datensätze.
Die aktuelle Implementierung unterstützt nur kontinuierliche Flow-Matching-Policies; andere Aktionsformulierungen erfordern angepasste Überwachungs- und Guard-Ziele. Die Evaluation beschränkt sich auf statische Hindernisse im VLA-Arena-Simulator; dynamische Szenen benötigen zeitliche Hindernisvorhersage und Lehrer-Korrekturen für bewegte Gefahren. Es werden keine Experimente auf realen Robotern berichtet. Das Paper ist ein Preprint und nicht begutachtet.
Robotik-Unternehmen, die VLA-Modelle für Manipulationsaufgaben mit Sicherheitsanforderungen einsetzen, könnten FailBank nutzen, um aus Laufzeitkorrekturen dauerhafte Policy-Verbesserungen abzuleiten. Innerhalb von 1 bis 3 Jahren ist eine Anwendung denkbar, sofern kontinuierliche Flow-Matching-Policies vorliegen, eine zuverlässige CBF-Lehrerkomponente für die Zielumgebung verfügbar ist und der Ansatz auf reale Roboter mit entsprechenden Sicherheitslehrern übertragen wird. Voraussetzung ist außerdem die Integration in bestehende Trainingspipelines und die Validierung der Guard-Schwellen für die jeweilige Hardware.
Der Volltext wird hier nicht wiedergegeben, weil die Lizenz der Studie das nicht erlaubt. Das Original steht auf arXiv.