Episodische Daten vs. Streaming-Trajektorien von Robotern
Episodische Daten oder ein kontinuierlicher Datenstrom? Die Rahmenentscheidung, die hinter jedem Datensatz mit Robotertrajektorien steht, bestimmt, was eine Policy am Ende tatsächlich lernen kann.
Ein Roboterdatensatz kommt fast nie als eine einzige lange Aufnahme daher. Er ist bereits in Episoden vorgeschnitten: Hinlangen, Greifen, Platzieren, Zurücksetzen, Wiederholen. Jemand, oder irgendein Skript, hat entschieden, wo jeder Clip beginnt und endet. Diese Entscheidung fällt lange vor dem ersten Gradientenschritt, und sie prägt still und leise, was eine auf diesen Daten trainierte Policy lernen kann und was nicht.
Die Alternative ist ein Datenstrom: ein ununterbrochenes Protokoll aus Beobachtungen und Aktionen, das minuten- oder stundenlang läuft, ohne saubere Nahtstellen. Beide beschreiben dieselbe physische Tätigkeit. Sie sind nicht austauschbar. Der Rahmen, für den man sich entscheidet, episodisch oder streamend, bestimmt, wie die Daten gespeichert werden, wie sie annotiert werden, welche Algorithmen sie verarbeiten können, und was eine Benchmark-Zahl überhaupt bedeutet.
Diese Entscheidung ist eine der unauffälligsten im Roboterlernen. Sie ist zugleich eine der folgenreichsten. Hier ist, warum das wichtig ist.
Was eine Episode stillschweigend voraussetzt
Eine Episode ist eine begrenzte Trajektorie: ein Startzustand, eine Abfolge von Beobachtungs-Aktions-Paaren und eine Abbruchbedingung, sei es Erfolg, Misserfolg oder ein fester Zeithorizont. Das Wort „Reset" verbirgt den größten Teil der Arbeit. Zwischen den Episoden bringt jemand die Szene in einen neuen Startzustand zurück, von Hand, per Skript oder mit einem zweiten Arm. Dieser Reset ist ein Privileg des Labors. Ein Humanoid, der in einer echten Werkshalle arbeitet, wird zwischen zwei Aufgaben niemals in eine kanonische Pose zurückteleportiert.
Die meisten Korpora des Imitationslernens sind bereits von ihrem Aufbau her episodisch. Open X-Embodiment aggregiert in der Größenordnung von einer Million Trajektorien, jede eine begrenzte Demonstration mit bekanntem Aufgabenlabel. DROID besteht aus teleoperierten Episoden, die über Hunderte Szenen hinweg gesammelt wurden. RH20T ist um kontaktreiche Aufgaben-Episoden herum organisiert. Diese Struktur ist praktisch fürs Training. Sie ist zugleich eine starke Annahme darüber, wo eine Aufgabe beginnt und wo sie endet.
Was ein Datenstrom bewahrt und eine Episode verwirft
Nun ein Blick auf Videokorpora aus der Ich-Perspektive. Ego4D und sein Multi-View-Nachfolger Ego-Exo4D sind im Kern Datenströme: Tausende Stunden egozentrischer Aktivität, die ohne Resets fließen. Eine Person wischt eine Arbeitsfläche ab, hält inne, greift nach einem Tuch, lässt es fallen, hebt es wieder auf und gleitet in die nächste Hausarbeit über. Nichts davon wird herausgeschnitten.
Der Datenstrom bewahrt das „Dazwischen". Er bewahrt den Übergang von einer Fertigkeit zur nächsten, die Leerlaufsekunden, den Patzer und die Erholung danach. Episodische Zerlegung löscht meist genau dieses Material, weil eine saubere Demonstration leichter zu annotieren ist und in einem Highlight-Reel besser aussieht. Doch genau im Dazwischen liegen die meisten Fehlschläge im realen Einsatz.
Auch Leerlauf- und Fehlermomente sind keine Verschwendung. Ein Datenstrom, der ein fallengelassenes Tuch und den Griff danach bewahrt, lehrt Wiederherstellung gratis mit, genau das Verhalten, das eine auf zurechtgeschnittenen Erfolgen trainierte Policy niemals zu sehen bekommt. Wer aggressiv schneidet, kürzt nicht nur Clips. Er selektiert für eine Welt, in der nie etwas schiefgeht, und wundert sich dann, warum der Roboter beim ersten Mal erstarrt, wenn doch etwas schiefgeht.
Eine Episode ist eine Hypothese darüber, wo eine Aufgabe beginnt und endet. Ein Datenstrom weigert sich zu raten. In der Lücke dazwischen verbergen sich die meisten Fehlschläge einer Policy in der realen Welt.
Die beiden Rahmen im direkten Vergleich
| Dimension | Episodische Daten | Streaming-Daten |
|---|---|---|
| Dateneinheit | Begrenzte Trajektorie mit Abbruchbedingung | Kontinuierliches Protokoll, kein festes Ende |
| Reset zwischen Aufgaben | Angenommen und erforderlich | Keiner; die Aktivität fließt weiter |
| Typische Quelle | Teleoperation, skriptierte Demonstrationen | Egozentrische Wearables, Einsatzprotokolle |
| Am besten passende Algorithmen | Behavior Cloning, episodenweises Offline-RL | Reset-freies RL, kontinuierliches und selbstüberwachtes Lernen |
| Annotation | Grenzen bei der Erfassung bekannt | Erfordert nachträgliche zeitliche Segmentierung |
| Fehler und Wiederherstellung | Meist herausgeschnitten | Vollständig erhalten |
| Speicherform | Viele kleine Dateien | Wenige sehr lange Dateien |
Die Speicherung macht die Trennung greifbar. Episoden zerfallen von Natur aus in viele kleine Dateien, die ein Trainings-Loader zufällig mischen kann, genau das, was der stochastische Gradientenabstieg will. Ein Datenstrom dagegen besteht aus einer Handvoll sehr langer Dateien, die sich dem Mischen widersetzen und einen Index verlangen, nur um die interessante Minute zu finden. Keine der beiden Formen ist falsch. Jede ist auf einen anderen Abnehmer zugeschnitten, und die Umwandlung zwischen beiden ist echtes Engineering, kein bloßer Formatschalter.
Warum der Rahmen den Algorithmus verändert
Behavior Cloning will Episoden. Es lernt eine direkte Abbildung von Beobachtung auf Aktion und stützt sich auf eine klar definierte Aufgabe und eine Abbruchbedingung, um zu wissen, wann es fertig ist. Ein Großteil des Offline-Reinforcement-Learning erbt dieselbe Annahme und berechnet Returns über Episoden mit definiertem Ende. Füttert man diese Verfahren mit einem rohen Datenstrom, fehlt ihnen jeder Ankerpunkt.
Reset-freies Lernen und kontinuierliches Lernen wollen Datenströme. Genauso jeder Roboter, der eine Stunde lang laufen muss, ohne dass ein Mensch zwischendurch die Szene aus- und wieder einschaltet. Der Einsatz erzeugt standardmäßig Datenströme; eine Flotte protokolliert kontinuierliche Erfahrung, keine ordentlichen Clips. Die Diskrepanz ist offensichtlich, sobald man sie benennt: Wir trainieren auf Episoden und setzen in Datenströmen ein.
Auch die Evaluation zerfällt entlang derselben Nahtstelle. Ein episodischer Benchmark berichtet eine Erfolgsquote: wie viele begrenzte Versuche gut ausgegangen sind. Ein Streaming-Einsatz interessiert sich für eine andere Zahl, die mittlere Zeit zwischen menschlichen Eingriffen, also wie lange der Roboter lief, bevor jemand eingreifen musste. Eine Policy kann bei der ersten Kennzahl stark aussehen und bei der zweiten schwach, weil saubere Episoden ihre Fähigkeit, sich durch unübersichtliche Übergänge hindurchzuarbeiten, nie geprüft haben. Nur die episodische Zahl zu berichten, ist die Art, wie ein Laborergebnis der Realität in der Werkshalle davonläuft.
Die Brücke zwischen beiden ist die Segmentierung, und die ist nicht umsonst zu haben. Ein langes Protokoll in wiederverwendbare Episoden zu verwandeln, ist ein Problem der zeitlichen Handlungssegmentierung, und die Fehler pflanzen sich stromabwärts fort. Setzt man eine Grenze zwei Sekunden zu früh, erbt jede daraus geschnittene Demonstration einen abgeschnittenen Griff. Aktuelle Arbeiten auf arXiv Robotics kehren immer wieder zur automatischen Segmentierung zurück, gerade weil sie der tragende Schritt ist, den niemand gerne macht.
Als Datenstrom erfassen, auf Episoden trainieren
Das ist kein Glaubenskrieg, und man muss sich nicht für immer für eine Seite entscheiden. Das praktikable Muster lautet: durchgehend aufzeichnen, jeden Zeitstempel und jeden Ereignismarker behalten und erst stromabwärts in Episoden zerlegen, dort, wo man bei Bedarf neu zerlegen kann, wenn sich die Aufgabendefinition ändert. Wirft man den rohen Datenstrom weg, ist diese Option für immer verloren. Behält man ihn, kann ein und dieselbe Aufnahme heute einen Behavior-Cloning-Lauf speisen und im nächsten Quartal ein Reset-freies Experiment. Der Datensatz, den man neu zerlegen kann, ist mehr wert als der, den jemand anderes schon für einen zerlegt hat.