Ein autonom fahrendes Auto erzeugt allein mit seinen Kameras etwa 1,1 TB Rohdaten pro Stunde, wie die Quelle vorrechnet, ohne LiDAR und Radar. Und trotzdem ist die Datenmenge nicht das eigentliche Problem. Ein Blogeintrag von Sangmin Yoon, der diese Woche über news.hada.io die Runde machte, verlegt den Engpass woanders: Zeitbezug zwischen den Sensoren, seltene Ereignisse und die Versionierung der Labels.
- Das Dataset nuScenes, das Motional 2019 veröffentlichte, liefert sechs Kameras pro Fahrzeug mit 1600 × 900 Pixeln bei 12 Hz. Ein unkomprimiertes Bild wiegt so rund 4,3 MB, zusammen knapp 311 MB pro Sekunde (laut Rechnung der Quelle: 1600 × 900 × 3 Byte).
- Bei 100 km/h entsprechen 10 Millisekunden Zeitversatz einer Positionsabweichung von 28 cm, abgeleitet aus den rund 28 Metern Weg pro Sekunde laut Quelle.
- Für einen statistischen Sicherheitsbeweis müsste eine autonome Flotte einige Jahrzehnte bis mehrere hundert Jahre fahren, so eine in dem Beitrag zitierte Studie.
Warum ist die Datenmenge eigentlich das leichte Problem?
Weil die Infrastruktur dafür längst ausgereift ist: Objektspeicher, Kompression und verteilte Verarbeitung beschreibt der Beitrag als ausgereift und gut bedienbar. Größe sei deshalb keine Machbarkeitsfrage („wie schaffen wir das?“), sondern eine Kostenfrage („wie viel geben wir dafür aus?“). Mehr Budget löst das automatisch, die drei Probleme darunter nicht.
Warum führt der nächste Zeitstempel als Join in die Irre?
Weil Kameras, LiDAR und Radar auf getrennten Uhren laufen und unterschiedliche Aufnahmeraten haben. Bei 100 km/h legt das Auto rund 28 Meter pro Sekunde zurück, 10 Millisekunden Versatz bedeuten damit 28 cm Unterschied in der erfassten Objektposition (laut Rechnung der Quelle). Was im Web-Backend ein entspannter Join über user_id oder request_id ist, wird hier zu zwei verschiedenen Weltbildern.
Wie beweist man, dass so ein Auto sicher ist?
Momentan kaum: Der Großteil der Fahrdaten ist laut Quelle schlicht langweilig, gebraucht werden seltene Momente wie plötzliches Schneiden, Baustellen, Falschgänger oder unbekannte Objekte auf der Fahrbahn. Eine in dem Beitrag zitierte Studie schätzt, dass ein statistischer Sicherheitsnachweis Jahrzehnte bis mehrere hundert Jahre Fahrleistung bräuchte. Wettbewerbsfähigkeit entsteht deshalb nicht beim Sammeln, sondern beim Finden der seltenen Daten.
Und dann ist da noch Problem drei, das mir am längsten im Kopf blieb: Fahrlogs werden immer wieder neu beschrieben, neue Metadaten schichten sich auf die alten Rohdaten, wohingegen ein normaler Log nach der Aggregation fertig ist. Jedes Mal muss das Team beantworten können, mit welcher Daten- und Label-Version ein Modell trainiert wurde. Yoons Fazit, sinngemäß: Datenengineering für autonomes Fahren heißt vor allem Bedeutung erhalten, nicht Menge verwalten.
Kurz beantwortet
- Worin besteht das Kernproblem bei AV-Daten? Nicht in der Größe, sondern in der Bedeutungssicherung: Zeitbezug, Seltenheit, Reproduzierbarkeit.
- Warum ist Daten-Versionierung so wichtig? Weil auf die Rohdaten ständig neue Metadaten geschrieben werden und jede Modellversion nachvollziehbar bleiben muss.
Nachlesen lässt sich das auf sanspareilsmyn.github.io, eine Fortsetzung ist dort bereits angetippt.
Bleibt meine konkrete Frage: Wenn ein Team 2026 ein Modell neu trainiert, findet es 2029 noch exakt die Label-Version von damals, oder hat es dann nur ein sehr teures Déjà-vu im Serverraum?