Jede Flotte sollte aus ihren eigenen Erfahrungen lernen.

Stellen Sie sich ein Fahrzeug vor, das sich einer Baustelle nähert, die sich über Nacht verändert hat. Sein Modell hat Schwierigkeiten, die neue Anordnung zu verstehen. Die Aufzeichnung sollte mehr werden als eine Protokolldatei oder eine einmalige Untersuchung. Mit dem richtigen Kontext kann sie dem Team helfen, den Fehler zu verstehen, bessere Trainingsdaten vorzubereiten und zu prüfen, ob das nächste Modell diese Situation zuverlässiger bewältigt.

Das ist die Zukunft, die wir uns für autonome Maschinen wünschen: Erfahrungen, aus denen immer wieder nützliches Lernen entsteht – von den ersten Demonstrationen, die ein Team aufzeichnet, bis zu den Flotten, die es später betreibt. Ein Lieferroboter, eine Erntemaschine und ein Industrieroboterarm stehen vor unterschiedlichen Problemen. Ihre Entwickler haben ein gemeinsames Bedürfnis: das Geschehen in der Welt mit den Veränderungen im Modell zu verbinden. Diese Verbindung soll zu verlässlicher Infrastruktur werden.

Bei Tesla Autopilot war ich der erste Ingenieur, der an Fleet Learning arbeitete: an den Systemen, die Flotten-Grenzfälle in Modellverbesserungen verwandelten. Diese Arbeit lehrte mich, über das Modell selbst hinauszusehen: wie das Team nützliche Beispiele findet, den Sensorkontext bewahrt, entscheidet, was passiert ist, und diese Entscheidungen in den nächsten Trainingsdatensatz überführt. Die Fähigkeit, diesen Prozess zu wiederholen, zählt so viel wie jeder einzelne Durchbruch.

Ich gründete Avala, damit andere Teams für Physical AI diese gesamte Grundlage nicht von Grund auf selbst bauen müssen. Sie sollten ihre besten Ingenieursleistungen in die Maschinen und Modelle investieren können, die sie auszeichnen. Avala sollte ihnen einen verlässlichen Weg bieten, aus der Welt zu lernen: vom ersten Arbeitsablauf im produktiven Einsatz bis zu den Flotten, die sie später betreiben.

Der KI-Stack hat fünf Schichten, von der Maschine im Einsatz bis hinunter zum Strom, der sie antreibt. Daten sind keine eigene Schicht. Sie leben in der Modellschicht, als Asset des Kunden, denn sie sind das, woraus das Modell lernt. Infrastruktur ist das, worauf ein Modell gebaut, verbessert und betrieben wird: alles rund um die Daten, aus denen es entsteht, und darunter die Rechenkapazität.

1. Anwendungen

   Was eine Maschine für jemanden tut: der Roboter, das Fahrzeug, die Drohne im Einsatz.

2. Modelle

   Das Gehirn und das, was ihm etwas beibringt: das Modell des Kunden und die Daten des Kunden. Evaluation und Post-Training finden hier statt, auf der eigenen Rechenkapazität des Kunden.

3. Infrastruktur

   Das, worauf Modelle gebaut, verbessert und betrieben werden: alles rund um die Daten, aus denen sie entstehen, von der Erfassung bis zum verifizierten Release, und darunter Werkzeuge, Rechenkapazität und Cloud.

   Hier sitzt Avala

4. Halbleiter

   Das Silizium.

5. Energie

   Der Strom, der all dem Grenzen setzt.

Avala liegt in der Infrastrukturschicht, direkt unter dem Modell des Kunden. Wir bauen keine Roboter, besitzen das Modell des Kunden nicht, verkaufen keine Rechenkapazität und stellen keine Chips her. Wir bauen die Daten- und Lerninfrastruktur, durch die das eigene Modell des Kunden aus seiner eigenen Flotte lernt.

Eine Maschine kann scheitern, weil sie einer Situation noch nie begegnet ist, weil ihre Supervision uneinheitlich ist oder weil das Problem woanders liegt als in ihren Trainingsdaten. Die erste Aufgabe ist, die Lücke zu verstehen.

Unsere Vision ist ein System, das ein Lernziel mit einem expliziten Datenplan verbindet: welche vorhandene Erfahrung genutzt, welche neue Erfahrung beschafft, wie sie qualifiziert wird und welches Experiment zeigen wird, ob sie geholfen hat. Breite Abdeckung und gezieltes Lernen gehören zusammen. Das Ziel ist nicht einfach ein größerer Datensatz. Es ist eine besser begründete Entscheidung darüber, was als Nächstes zu tun ist.

Diese Disziplin gilt in beide Richtungen. Manchmal ist die richtige Maßnahme, eine Kalibrierung zu reparieren, eine mehrdeutige Annotationsrichtlinie zu ändern oder die Daten neu auszubalancieren, die ein Team bereits hat. Ein glaubwürdiger Datenpartner sollte einem Kunden manchmal sagen, keine weiteren Daten zu kaufen.

Ein Datensatz ist ein Nachweis, nicht das Ziel. Für jedes Lernziel bewahren wir die geprüfte Fähigkeit, die Situationen, die sie fordern, die zum Training verwendeten Nachweise, den zur Bewertung verwendeten Standard und das Ergebnis.

Das macht ein Lernprogramm reproduzierbar. Dieselbe Fähigkeit lässt sich gegen ein neues Daten-Release, ein neues Modell oder eine neue Laufzeitumgebung prüfen, ohne die Überlegungen zu rekonstruieren, die zu ihr geführt haben. Mit der Zeit werden diese versionierten Fähigkeiten zur Betriebshistorie dessen, wie eine Maschine gelernt hat.

Ein nützliches Beispiel aus der physischen Welt ist mehr als das Bild eines Objekts. Die Aufgabe kann davon abhängen, was zuvor geschah, was die Maschine oder die Person versucht hat und was danach geschah. Wir verbinden Sensorbeobachtungen mit dem für die Aufgabe verfügbaren Kontext: Zeitverlauf, Geometrie, Trajektorien, Aktionen, wo sie aufgezeichnet wurden, Ergebnisse und menschliche Interpretation.

Dieser Kontext bleibt über Erfassung, Prüfung, Datensatzvorbereitung und Evaluation hinweg einsehbar. Fehlende oder unsichere Informationen sind sichtbar und nicht hinter einem fertigen Label verborgen. Eine rekonstruierte 4D-Szene bewahrt den physischen Kontext, damit er geprüft werden kann; sie ersetzt keine gemessenen Aktionen, keinen Kontakt und keine Validierung, wo eine Aufgabe sie erfordert.

Unsere Arbeit beginnt mit den Produktionsdaten einer Flotte: multimodale Sensoraufzeichnungen, zu 4D-Daten rekonstruiert, von KI und Expertenreviewern gelabelt und als versionierte Datensätze veröffentlicht, auf denen der Kunde trainiert. MCAP- und ROS-Aufzeichnungen, Kamerabilder, LiDAR und Robotertrajektorien müssen mit dem Kontext verbunden bleiben, der sie nützlich macht. Wir bringen Software und Expertenbetrieb zusammen, um Daten aufzubereiten, die die Trainingsanforderungen des Kunden erfüllen.

Beginnen Sie mit einem wiederkehrenden Problem: uneinheitlichen Annotationen, fehlenden Beispielen oder einem Trainingsdatensatz, der eine weitere Korrekturrunde braucht. Definieren Sie, was akzeptabel ist. Messen Sie Durchlaufzeit, Qualität und Gesamtaufwand. Machen Sie dann das nächste Release leichter produzierbar. So kann aus einem konkreten Datenprojekt ein System werden, auf das sich der Kunde verlässt, statt einer weiteren isolierten Lieferung.

2028 ist Avala die offene Infrastruktur, auf der jeder Betreiber von Maschinen in der physischen Welt seine eigene Erfahrung in seine eigene Intelligenz verwandelt, mit Daten, Modellen und Deployment unter eigener Kontrolle, damit jeder Eigentümer seiner Intelligenz sein kann und nicht Mieter einer fremden. Diese Position wollen wir uns in vier zusammenhängenden Stufen verdienen.

1. 01

   Einen Arbeitsablauf im produktiven Einsatz validieren.

   Ein Problem lösen, für das ein Kunde jetzt eine Lösung braucht. Nach einem klaren Abnahmestandard liefern und das Ergebnis am bisherigen Prozess messen. Den nächsten Zyklus zuverlässiger machen, statt sich mit einer beeindruckenden ersten Lieferung zufriedenzugeben.

2. 02

   Zur gemeinsamen Grundlage für Modelle und Teams werden.

   Dieselbe Datensatzidentität, Prüfhistorie und dieselben Qualitätsrichtlinien in weitere Arbeitsabläufe übernehmen. Jede Erweiterung sollte die bereits vorhandene Infrastruktur nutzen. Entscheidend ist, ob ein weiteres Team oder Modell davon profitieren kann, ohne ein weiteres maßgeschneidertes Entwicklungsprojekt zu benötigen.

3. 03

   Die Forschung zwischen Entdeckung und Verbesserung automatisieren.

   Auf Forschungsagenten hinarbeiten, die einen Fehlerfall in der Flotte untersuchen, die Nachweise abrufen, sie mit früheren Fällen vergleichen, ein Experiment vorschlagen, die fehlenden Beispiele finden oder in Auftrag geben und das Ergebnis bewerten können. Ihre Schlussfolgerungen bleiben bis zu den physischen Nachweisen nachvollziehbar, ihre Evaluatoren werden an verborgenen Standards geprüft, und folgenreiche Änderungen bleiben überprüfbar und umkehrbar. Das Ziel ist nicht ein Agent, der mehr Daten erzeugt. Es ist ein System, das besser darin wird zu entscheiden, welches Experiment sich als Nächstes lohnt.

4. 04

   Lernen im gesamten Ökosystem übertragbar machen.

   Robotiksysteme, Modelle und Infrastruktur über offene Schnittstellen verbinden. Teams sollten bessere Werkzeuge einsetzen können, ohne ihre Historie aufzugeben. Geteilte Datensätze und Modelle können diese Grundlage erweitern, wenn ihre Eigentümer sie teilen möchten und die Wiederverwendung erlaubt ist. Interoperabilität sollte den Zugang erweitern, ohne die Aufgabe der Kontrolle zu verlangen.

Nützliche Erfahrung aus der physischen Welt existiert bereits, aber sie ist unvollständig, ungleich abgedeckt und größtenteils von den Entscheidungen getrennt, die ein bestimmtes Modell verbessern würden. Die Erfahrung, die am meisten zählt, entsteht nach wie vor Einsatz für Einsatz bei den Unternehmen, denen die Maschinen gehören, und sie besteht vor allem aus Ausnahmen: den Situationen, die niemand simuliert hat. Kein einzelnes Unternehmen wird sie besitzen. Deshalb muss die Infrastruktur, die sie findet, qualifiziert, kombiniert und ergänzt, unabhängig sein – und deshalb muss das Eigentum dort bleiben, wo die Daten entstanden sind.

Kunden sollten den Vorteil ihrer proprietären Ressourcen behalten. Aus den Erfahrungen einer Flotte zu lernen, darf nicht bedeuten, ihre Daten stillschweigend mit denen eines Wettbewerbers zusammenzuführen. Die Aufzeichnungen, Annotationen, Evaluationsergebnisse und Modelle eines Kunden werden nie ohne die ausdrückliche Zustimmung dieses Kunden zum Vorteil eines anderen Kunden. Ein geteilter Datensatz wird nach Vereinbarung geteilt, mit ausdrücklich geregelter Wiederverwendung. Offen bedeutet für uns etwas Konkretes: interoperable Schnittstellen, exportierbare Daten und Historie, klare Nutzungsrechte und ein vom Kunden kontrolliertes Deployment. Unabhängigkeit heißt: Ihr Infrastrukturpartner gehört weder einem Modell-Labor noch einem Roboterhersteller noch einem Hyperscaler. Avala sollte sich seinen Platz durch den Wert des Systems verdienen, nicht durch die Schwierigkeit, es zu verlassen.

Die Menschen, die Maschinen unterrichten und bewerten, tragen mehr bei als Annotationskapazität. Sie definieren Aufgaben, erkennen bedeutsame Fehler, beurteilen Ergebnisse und setzen die Standards, an denen automatisierte Systeme gemessen werden. Ihr Urteilsvermögen verdient gute Werkzeuge, faire Vergütung und Wege zu anspruchsvollerer Arbeit. Automatisierung soll repetitive Arbeit beseitigen und dabei Expertise wertvoller machen: bessere Entscheidungen, die im Prozess festgehalten werden, bessere Software zur Unterstützung der nächsten Aufgabe und weniger wiederholte Fehler.

Das übergeordnete Ziel sind sicherere und produktivere körperliche Arbeit sowie nützliche Dienstleistungen, die sich mehr Menschen leisten können. Ein kleines Robotikteam soll auf Fähigkeiten aufbauen können, die sonst eine große interne Organisation erfordern würden. Bessere Maschinen sind das Mittel. Mehr Menschen, die damit etwas aufbauen, Geld verdienen und davon profitieren können, sind das Ziel.

Physical AI wird verändern, was Arbeit ist, wer sich Pflege leisten kann und wie Waren und Lebensmittel transportiert werden. Wir wollen, dass diese Veränderung gut für die Menschen ist – auf eine Weise, die sich überprüfen lässt, statt vorausgesetzt zu werden. Vier Verpflichtungen prägen, wie wir bauen.

1. 01

   Die Menschen, die Maschinen unterrichten, werden dafür bezahlt und geschult.

   Avalas Coworker werden für abgenommene Arbeit bezahlt, zu Sätzen über dem Üblichen für die Arbeit und den Ort, mit integrierter Schulung. Automatisierung beseitigt die Wiederholung; das qualifizierte Urteilsvermögen bleibt bei den Menschen.

2. 02

   Wem die Maschine gehört, dem gehört das Modell.

   Die Flottendaten eines Unternehmens und die daraus gelernte Intelligenz bleiben unter seiner Kontrolle, in offenen Formaten, die es mitnehmen kann. Kein Labor, kein Roboterhersteller und keine Cloud steht zwischen einem Team und seiner eigenen Erfahrung.

3. 03

   Gemessen, bevor ihr vertraut wird.

   Jedes Release wird gegen eine Ausgangsbasis bewertet, die der Kunde festlegt, einschließlich dessen, was sich nicht verbessert hat. Eine Maschine verdient sich breiteren Einsatz durch Nachweise, eine Evaluation nach der anderen.

4. 04

   Kleine Teams bekommen die Fähigkeiten großer Unternehmen.

   Ein Robotikteam von zehn Leuten sollte aus der Welt lernen können wie eine Flotte von Tausenden. Wird dieser Kreislauf günstiger, können mehr Menschen bessere Maschinen bauen, damit Geld verdienen und davon profitieren.