Das neue Stratum-Papier von arXiv zeigt eine 16,6-fache Beschleunigung nicht durch intelligentere KI-Agenten, sondern durch den Aufbau einer Commerce-KI-Architektur, die ihre Arbeitslast endlich bewältigen kann. Die meisten Marken sind strukturell unvorbereitet.
Ich saß bei Intelligentsia Coffee in Abbot Kinney, genoss einen lächerlich überteuerten Single-Origin-Pour-over und beobachtete das ganze Theater. Der Barista, eine Studie in konzentrierter Ausführung, wog die Bohnen auf ein Zehntel Gramm genau. Er überwachte die Wassertemperatur an einem digitalen PID-Regler. Er "bloomte" das Kaffeemehl mit einem präzisen, spiralförmigen Guss aus einem Schwanenhalskessel. Es war eine perfekte, handgefertigte Datenpipeline, die Rohdaten (Bohnen, Wasser) in ein raffiniertes Ergebnis (Kaffee, der nach Bergamotte und Bedauern schmeckt) umwandelte. Der gesamte Prozess dauerte vier Minuten.
Es ist ein schönes System für eine einzelne Tasse. Aber was wäre, wenn Sie in der nächsten Stunde 10.000 verschiedene Pour-over-Techniken testen müssten? Leicht unterschiedliche Temperaturen, Mahlgrade, Gussmuster, Bloom-Zeiten – eine erschöpfende Suche nach der global optimalen Tasse. Der Barista kann trotz all seines Könnens nicht skalieren. Sein Workflow ist grundlegend "single-threaded" (einzelsträngig). Er kann seine Bewegungen nicht batch-kompilieren oder auf einem parallelisierten Rust-Backend ausführen.
Genau dieses Problem kennen alle Handelsmarken, mit denen ich spreche. Sie haben die Datenwissenschaftler eingestellt. Sie haben ihnen Zugang zu leistungsstarken LLMs gegeben, die als autonome Agenten agieren können. Diese Agenten sind brillant; sie sind wie tausend Meister-Baristas, die ständig neue Ideen zur Vorhersage von Kundenabwanderung, zur Optimierung des Lagerbestands und zur Personalisierung von Benutzererlebnissen generieren. Aber Ihre Infrastruktur ist der einzelne Barista, der akribisch eine Aufgabe nach der anderen ausführt. Ihre KI ist ein Gehirn im Glas, fähig zu unglaublicher Ideenfindung, aber ohne Hände, um die Arbeit tatsächlich in großem Maßstab zu erledigen.
Ein diese Woche auf arXiv veröffentlichtes neues Papier, "Stratum: A System Infrastructure for Massive Agent-Centric ML", ist der erste echte architektonische Bauplan, den ich gesehen habe, der diese Krise angeht [3, 8]. Es geht nicht darum, einen intelligenteren Agenten zu bauen; es geht darum, eine Fabrik zu bauen, in der Agenten arbeiten können. Es berichtet von einer erstaunlichen 16,6-fachen Beschleunigung für komplexe Machine-Learning-Aufgaben, und das durch die Bewältigung des unglamourösen, grundlegenden Systemproblems, das alle anderen ignorieren [10]. Für einen Commerce-Architekten ist dies das wichtigste Papier des Jahres.
Was ist Agentic Pipeline Search?
Um zu verstehen, warum Stratum so signifikant ist, müssen Sie zuerst die neue Arbeitslast verstehen, für die es entwickelt wurde: agentic pipeline search (Agenten-gesteuerte Pipeline-Suche) [3]. Dies ist nicht die Art von Machine Learning, die Ihr Team gerade betreibt. Ihr aktueller Prozess ist wahrscheinlich linear und menschengesteuert. Ein Datenwissenschaftler stellt eine Hypothese auf, zieht Daten, bereinigt sie in einem Jupyter-Notebook, erstellt ein Modell, testet es und stellt es bereit. Dieser Prozess kann Wochen, sogar Monate dauern. Es ist der einzelne Pour-over.
Agentic pipeline search ist grundlegend anders. Es beschreibt ein Szenario, in dem ein autonomer oder semi-autonomer "MLE Agent" (Machine Learning Engineering Agent) den gesamten Prozess steuert [8]. Das Stratum-Papier verwendet das Beispiel des Aufbaus eines Kundenabwanderungsmodells aus einem unübersichtlichen Data Lake, gefüllt mit CSV-Dateien, Transaktionsprotokollen, unstrukturiertem Text und Bildern – ein Szenario, das jeder DTC-Marke (Direct-to-Consumer) schmerzlich vertraut ist [8, 9].
In diesem neuen Paradigma führt der Agent eine massive, explorative Suche durch und führt Tausende von Pipelines parallel aus:
- Datenprofiling: Der Agent beginnt mit der automatischen Profilierung der Quelldaten. Er betrachtet nicht nur Spaltentypen; er nimmt Stichproben der Daten, um Verteilungen, Kardinalitäten, die Vielfalt des Vokabulars in Textfeldern und Korrelationen zwischen scheinbar unverbundenen Datenquellen zu verstehen [9].
- Hypothesengenerierung: Mit diesem Profil bewaffnet, durchsucht der Agent (wahrscheinlich ein LLM) das Web, akademische Arbeiten und interne Dokumentationen nach vielversprechenden Modellierungsansätzen. Er könnte sich entscheiden, eine einfache logistische Regression, einen Gradient-Boosted Tree und ein komplexeres multimodales Modell auszuprobieren, das tabellarische Transaktionsdaten mit Merkmalen kombiniert, die aus Produktbildern extrahiert wurden [3].
- Pipelinesynthese: Für jede Hypothese generiert der Agent Hunderte oder Tausende von Pipeline-Variationen. Er schreibt Python-Code unter Verwendung von Standardbibliotheken wie Pandas und scikit-learn, um Feature-Engineering, Skalierung, Modelltraining und Hyperparameter-Tuning zu handhaben [9]. Er probiert verschiedene Wege aus, um fehlende Werte zu behandeln, kategoriale Variablen zu kodieren und den Kreuzvalidierungsprozess zu strukturieren.
- Iterative Verfeinerung & Ensembling: Der Agent bewertet die Leistung dieser Tausenden von Pipelines, identifiziert die vielversprechendsten und iteriert dann. Er könnte die leistungsstärksten Modelle zu einem Ensemble kombinieren, wobei er seinen Ansatz ständig auf der Grundlage empirischer Ergebnisse verfeinert [8].
Dies ist nicht nur Automatisierung; es ist eine geführte, massiv parallele Suche über den gesamten Raum möglicher Lösungen. Der "smarte" Teil ist nicht nur das endgültige Modell; es ist der Prozess, es zu finden. Das Problem ist, dass die Tools, die wir unseren Datenwissenschaftlern geben, für den einmaligen, menschengesteuerten Workflow konzipiert sind. Das Ausführen eines einzelnen Python-Skripts ist langsam. Zehntausend davon auszuführen ist unmöglich. Es schafft einen Ausführungsengpass, der das kreative Potenzial des KI-Agenten vollständig unterdrückt. Das Gehirn träumt, aber der Körper kann sich nicht bewegen.
Die 16,6-fache Beschleunigung: Stratums Architektur dekonstruiert
Das Geniale am Stratum-Papier ist kein neues LLM oder ein magischer Algorithmus. Es ist eine systemarchitektonische Erkenntnis, die im Nachhinein offensichtlich erscheint: Entkopplung der Argumentation des Agenten von der Ausführung der Pipeline. Das LLM ist gut im Planen (Python-Code schreiben), aber schlecht darin, ihn effizient auszuführen. Der Python-Interpreter selbst ist, insbesondere für Datenaufgaben, im Vergleich zu Low-Level-Sprachen notorisch langsam [9].
Stratum führt ein System ein, das als Vermittler fungiert, ein hocheffizienter Fabrikmanager für die Arbeitsaufträge des Agenten. Der Prozess sieht wie folgt aus:
Lassen Sie uns aufschlüsseln, was hier passiert.
-
Entkoppelte Generierung: Der MLE Agent, der ein hochentwickeltes LLM wie GPT-4 oder ein spezialisiertes Modell sein könnte, tut, was er am besten kann: Er denkt und schreibt Code. Er generiert Tausende potenzieller ML-Pipelines als Python-Skripte unter Verwendung von Bibliotheken, die jeder bereits kennt, wie Pandas und scikit-learn. Er führt sie nicht aus [3].
-
Batch-Kompilierung zu Ausführungsgraphen: Anstatt diese Skripte einzeln auszuführen, übermittelt er sie als Batch an das Stratum-System. Stratum analysiert dann alle diese Pipelines und kompiliert sie in einen einzigen, optimierten Ausführungsgraphen. Es identifiziert gemeinsame Operationen über verschiedene Pipelines hinweg (z. B. das Laden derselben CSV-Datei, das Anwenden derselben Feature-Transformation) und stellt sicher, dass sie nur einmal ausgeführt werden. Dies ist eine grundlegende Abweichung von der isolierten, interpretativen Natur der typischen Python-Ausführung [9].
-
Optimierte Ausführung auf heterogenen Backends: Hier kommt der große Speedup her. Der kompilierte Graph wird über eine Vielzahl von Backends ausgeführt. Einfache Aufgaben können auf Standard-Python-Workern ausgeführt werden. Aber für performanzkritische Operationen kann Stratum Aufgaben an eine neuartige, hochleistungsfähige Rust-Laufzeitumgebung senden, die speziell für diese Art von datenintensiven ML-Aufgaben entwickelt wurde [8]. Dies ermöglicht es dem System, die Einschränkungen von Python für numerische Berechnungen und Datenmanipulationen zu umgehen, was zu der berichteten 16,6-fachen Beschleunigung in ihren Vorläufer-Experimenten führt [10].
Der Schlüssel ist, dass das System die gesamte Arbeitslast im Voraus versteht, was globale Optimierungen ermöglicht, die bei der isolierten Ausführung von Skripten unmöglich wären. Es ist der Unterschied zwischen 1.000 Köchen, die jeweils ein Gericht in ihrer eigenen Küche zubereiten, und einer einzigen, hochfunktionellen Restaurantküche, in der die Vorbereitung zentralisiert und die Stationen für bestimmte Aufgaben optimiert sind.
Warum Ihr aktueller ML-Stack eine Belastung ist
Beim Lesen des Stratum-Papiers wird deutlich, wie schlecht die meisten Commerce-Tech-Stacks für diese neue Realität gerüstet sind. Sie sind fast alle um das "Single Pour-over"-Ausführungsmodell herum konzipiert.
Betrachten Sie den durchschnittlichen Enterprise-ML-Workflow. Er beinhaltet wahrscheinlich eine Kombination aus Airflow oder dbt für die Orchestrierung, eine Databricks- oder Snowflake-Umgebung für das Data Warehousing und eine Sammlung von Jupyter-Notebooks, in denen Datenwissenschaftler Modelle prototypisieren. Jede dieser Komponenten, obwohl leistungsstark für ihren vorgesehenen Zweck, wird zu einem Engpass in einer "agentic world" (Agenten-Welt).
- Jupyter Notebooks: Das Standardwerkzeug zur Datenexploration ist eine interaktive Einzelbenutzerumgebung. Sie ist fantastisch für das Prototyping, aber absolut miserabel, um Tausende von automatisierten, hochdurchsatzfähigen Experimenten durchzuführen. Sie fördert einen "Human-in-the-Loop"-Prozess, der einfach nicht skaliert.
- Orchestrierungstools (z. B. Airflow): Diese Tools sind darauf ausgelegt, wohldefinierte, gerichtete azyklische Graphen (DAGs) von Aufgaben nach einem Zeitplan auszuführen. Sie sind perfekt für tägliche ETL-Jobs oder das wöchentliche Neulernen eines Produktionsmodells. Sie sind nicht für das "hochgradig explorative Verhalten" und die "geführte Suche nach Strukturen und Hyperparametern" konzipiert, die die agentic pipeline search charakterisieren [9]. Der Workflow des Agenten ist kein statischer DAG; es ist ein dynamischer, verzweigter Baum von Möglichkeiten.
- Text2SQL und relationale Optimierer: Viele Forschungen haben sich auf die Verwendung von LLMs zur Generierung von SQL-Abfragen (Text2SQL) konzentriert [9]. Obwohl nützlich, löst dies ein völlig anderes Problem. Relationale Datenbanken sind für strukturierte Abfragen optimiert, nicht für die komplexen, mehrstufigen Pipelines, die Feature-Engineering, Modelltraining und Validierung umfassen und modernes Machine Learning definieren. Wie die Stratum-Autoren betonen, lassen sich Optimierungen aus der relationalen Welt nicht gut auf ML-Workloads übertragen [9] . Ihr Stack ist für eine Welt von vorhersehbaren, geplanten Jobs gebaut. Agentic Commerce ist eine Welt von massiven, unvorhersehbaren, explorativen Suchen. Ohne ein System wie Stratum, um die Lücke zu schließen, versuchen Sie, einen Stadtbusfahrplan zu verwenden, um ein Formel-1-Rennen zu navigieren. Die "wachsende Diskrepanz zwischen High-Level-Python-APIs und dem Potenzial für Low-Level-Optimierungen" ist kein theoretisches akademisches Problem mehr; sie ist die primäre architektonische Belastung für jede Marke, die mit KI konkurrieren möchte [9].
Kopf-an-Kopf: Stratum vs. Status Quo
Die architektonische Vision von Stratum lässt sich am besten verstehen, indem man sie direkt mit bestehenden und konkurrierenden Ansätzen vergleicht. Dies ist nicht nur eine inkrementelle Verbesserung; es ist eine kategorische Verschiebung in der Art und Weise, wie wir über die Infrastruktur für maschinelles Lernen denken.
| Aspekt | Stratum (arXiv:2603.03589v2) | Traditionelles MLOps (Airflow, Notebooks) | Text2SQL-Systeme (z. B. Russo & Kraska, 2026) | Domänenspezifische Agenten (z. B. SEA-TS) |
|---|---|---|---|---|
| Primäre Arbeitslast | Massive, explorative Agenten-gesteuerte ML-Pipeline-Suche (Tausende von Ausführungen) [10]. | Geplante, vordefinierte, vom Menschen erstellte Pipelines. | Einmalige Übersetzung und Ausführung von natürlicher Sprache in SQL [9]. | Autonome Codegenerierung für eine bestimmte Domäne (z. B. Zeitreihen) [2]. |
| Grundlegender Umfang | Vollständiges End-to-End-ML: Datenprofiling, Generierung, Verfeinerung, Ensembling [8]. | Primär auf Orchestrierung und Planung bekannter Aufgaben fokussiert. | Eng auf Datenbankabfragen fokussiert; kein Konzept von ML-Modellen oder Hyperparametern. | Vollständige Codegenerierung, aber ohne System für massive Skalierung und Optimierung. |
| Optimierungsstrategie | Batch-Kompilierung zu einem Ausführungsgraphen; Verteilung auf heterogene Backends (inkl. Rust) für eine 16,6-fache Beschleunigung [10]. | Parallelität auf Aufgabenebene; keine globale Optimierung über Pipelines hinweg. | Abfragespezifische relationale Optimierungen innerhalb der Datenbank. | Algorithmus-Ebene-Optimierung (z. B. Monte Carlo Tree Search) zur Suche nach besserem Code [2]. |
| Integrationsmodell | Nahtlos mit bestehenden Python-Bibliotheken wie Pandas und scikit-learn [9]. | Erfordert viel Boilerplate-Code und benutzerdefinierte Operator-Definitionen. | Erfordert oft spezialisierte Modelle oder Datenbankerweiterungen. | Generiert Python-Code, verlässt sich aber für die Ausführung auf den standardmäßigen, langsamen Interpreter. |
| Architektonische Reife | Früher Prototyp & architektonische Vision [10]. Ein Bauplan für die Zukunft. | Reife, produktionsreife Tools, aber für ein anderes Paradigma. | Reif als Forschungsbereich, aber mit begrenztem Umfang für vollständiges ML. | Stand der Technik; Benchmarks beweisen Algorithmusqualität, aber nicht Systemska |
| la. | ||||
| Dieser Vergleich macht den zentralen Punkt deutlich: Stratum ist der einzige Ansatz, der explizit die Systeminfrastruktur anspricht, die für 大规模 agentic ML (massiv-skaliertes agentisches ML) erforderlich ist. Andere Ansätze konzentrieren sich entweder darauf, den Agenten intelligenter zu machen (wie SEA-TS, das brillant ist, aber ein anderes Problem löst) oder konzentrieren sich auf die Optimierung eines engen Teils des Problems (wie Text2SQL). Der traditionelle MLOps-Stack wurde einfach nicht für diese Arbeitslast gebaut. |
Stratums Autoren identifizieren korrekt, dass die Explosion der LLM-Fähigkeiten für Agentenverhalten eine "fundamentale Systemherausforderung" geschaffen hat [8]. Man kann den intelligentesten ML-Agenten der Welt haben, aber wenn seine Ausführungsumgebung ihn zwingt, ein Python-Skript nach dem anderen auszuführen, ist seine Intelligenz verschwendet.
Was das für Ihre Marke bedeutet: Aufbau eines AI Experience Lab
Stratum ist also ein Forschungspapier mit einem "frühen Prototyp" [10]. Sie können es heute nicht herunterladen und bereitstellen. Es ist leicht, dies als akademische Nabelschau abzutun. Das wäre ein katastrophaler Fehler. Das architektonische Muster, das es beschreibt, ist die Schrift an der Wand. Marken, die diesen Wandel verstehen und jetzt mit der Re-Architektur beginnen, werden in zwei bis drei Jahren einen unüberwindbaren Wettbewerbsvorteil haben.
Die unmittelbare Erkenntnis ist nicht, Ihren gesamten Daten-Stack zu zerlegen und zu ersetzen. Der umsetzbare Schritt ist die Einrichtung eines AI Experience Lab. Dies ist ein kleines, fokussiertes, funktionsübergreifendes Team – ein paar Ingenieure, ein Datenwissenschaftler, eine Produktperson – dessen gesamte Aufgabe es ist, die Sandbox für Ihre zukünftige "agentic workforce" (Agenten-Belegschaft) aufzubauen. Ihr Auftrag ist es nicht, im nächsten Quartal ein Produktions-Churn-Modell zu liefern. Ihr Auftrag ist es, eine kleine Version der Stratum-Architektur zu bauen und ihren Wert zu beweisen.
Ihr AI Experience Lab Blueprint
-
Isolieren Sie einen Anwendungsfall: Beginnen Sie mit einem begrenzten, aber wertvollen Problem. Versuchen Sie nicht, das Universum zu erobern. Die Abwanderungsvorhersage, wie im Papier, ist perfekt. Die Nachfrageprognose für eine bestimmte Produktkategorie ist eine weitere. Das Ziel ist ein Problem mit unordentlichen, multimodalen Daten, das von massiven Experimenten profitieren könnte.
-
Umfassen Sie das Entkopplungsprinzip: Der Kern der Arbeit des Labs sollte der Aufbau eines Systems sein, das die Agenten-Planung von der Ausführung trennt. Lassen Sie einen LLM-Agenten Python-Pipelines als Textdateien oder JSON-Objekte generieren. Bauen Sie dann einen separaten Dienst – Ihr Mini-Stratum –, der diese Ausgaben analysiert und ausführt. Selbst ohne ein benutzerdefiniertes Rust-Backend wird allein das Batching und die Parallelisierung der Ausführung dieser Skripte erhebliche Gewinne gegenüber einem Notebook-basierten Workflow erzielen.
-
Bauen Sie eine Ergebnisdatenbank auf: Während Ihr System Tausende dieser Pipeline-Experimente durchführt, speichern Sie die Ergebnisse – den Code, die Hyperparameter und die Leistungsmetriken – in einer strukturierten Datenbank. Dies schafft eine Feedbackschleife. Ihr Agent kann diese Datenbank dann abfragen, um seine nächste Experimentreihe zu informieren, wodurch die im Papier beschriebene iterative Verfeinerungsschleife entsteht [8]. So lernt und verbessert sich das System im Laufe der Zeit.
-
Messen Sie alles: Das Lab