Der kritische Pfad zur Automatisierung der Modellentwicklung

Der nächste wichtige Meilenstein für die KI-Forschung ist die Automatisierung der Modellentwicklung. Jeder Fortschritt in der Argumentation, Sprache und Wahrnehmung ist in gewissem Sinne ein Schritt in diese Richtung. Allerdings erfordert der Weg zur Modellautomatisierung die Lösung einer Reihe von grundlegenden Herausforderungen, die zunächst gelöst werden müssen.

Die Brücke zu diesem Ziel führt direkt durch die Maschinenlernen-Engineerings. Ein häufiger Irrtum geht davon aus, dass Maschinenlernen (ML) eine Vorgängertechnologie zur modernen KI ist und dass Foundation-Modelle es einfach ersetzt haben. Dies missversteht die Beziehung. Als akademische Disziplin umfasst ML alle Aspekte der Modelltraining, einschließlich des Trainings von Foundation-Modellen im Zentrum des aktuellen KI-Moments. Es gibt jedoch einen bedeutenden Unterschied in Bezug auf Skala und Datenkomplexität.

Traditionelle ML-Modelle werden typischerweise auf sorgfältig kuratierten, domänen-spezifischen Datensätzen trainiert, die Tausende oder Millionen von Beispielen enthalten. Foundation-Modelle hingegen werden auf Tausende von Datensätzen gleichzeitig trainiert, die aus sehr unterschiedlichen Quellen stammen und inkonsistente Formate, Herkunft und Qualität aufweisen. Dieser Unterschied in der Datenmenge und -heterogenität ist ein grundlegender Grund, warum das Datenmanagement bei der Automatisierung der Modellentwicklung viel schwieriger und wichtiger wird.

Das macht das Datenverständnis zu einem zentralen Engpass bei der Automatisierung der Modellentwicklung. Ein KI-System, das heterogene Daten interpretieren und die Pipelines, die um es herum gebaut werden, verbessern kann, könnte im Prinzip seinen eigenen Trainingsprozess verbessern und dazu beitragen, bessere Modelle zu bauen. Sobald die KI den Prozess, durch den sie trainiert wird, verbessern kann, strömen die Verbesserungen nach unten in jeden Bereich, in dem die KI angewendet wird.

Drei Barrieren, die im Weg stehen

Die erste Barriere ist die Kontextfragmentierung. In fast jeder Organisation sind die Signale, Experimente, Feature-Definitionen und institutionellen Kenntnisse, die für ein bestimmtes Modellierungsproblem relevant sind, über Datenlager, Notebooks und Pipelines verstreut, die nie dafür konzipiert waren, miteinander zu kommunizieren. Betrachten wir ein Gesundheitssystem, das ein Sepsis-Erkennungsmodell aufbaut. Die klinischen Kriterien, die für dieses Problem relevant sind, wie z.B. Schwellenwerte, Laborwerte und Dokumentationsstandards, können in völlig getrennten Modulen eines elektronischen Gesundheitsakten-Systems leben.

Die zweite Barriere ist die semantische Mehrdeutigkeit. Bedeutung ist nicht inhärent in den Daten, sondern kontext- und organisationsabhängig. Der gleiche Feldname in zwei verschiedenen Datenbanken kann sich auf unterschiedliche Dinge beziehen. Konzepte wie Umsatz, aktiver Benutzer und Fluktuation haben innerhalb eines Unternehmens häufig mehrere gültige Definitionen. Sogar ein Konzept wie “Umsatz” kann Probleme verursachen. Ein Vertriebsteam kann Umsatz als den Gesamtwert der in diesem Quartal unterzeichneten Verträge definieren, während das Finanzteam Umsatz als tatsächlich erhaltenen Bargeld definiert. Das Produktteam hat ein anderes Verständnis, da es Umsatz als anerkannten Umsatz über einen Abonnementszeitraum definiert. Alle drei greifen auf Felder zu, die wörtlich “Umsatz” in ihren jeweiligen Systemen heißen, aber ein Bericht, der sie über Teams hinweg kombiniert, würde drei unvereinbare Zahlen stillschweigend mischen.

Die dritte und systemischste Barriere ist das Fehlen dokumentierter organisatorischer Erinnerung. Die Nachverfolgung der Herkunft, die Auflösung von Inkonsistenzen und die Aufrechterhaltung von Qualitätsignalen über so viele Quellen ist ein ungelöstes Problem, sogar für menschliche Teams. Ohne eine institutionelle Erinnerung daran, was versucht wurde und wie gut diese Ansätze funktionierten, wird jedes Modellautomatisierungsmechanismus immer wieder dieselben toten Enden wiederentdecken, Zeit und Ressourcen verschwenden.

Betrachten wir ein Data-Science-Team in einem Einzelhandelsunternehmen, das ein Nachfrageprognosemodell aufbaut. Über drei Jahre hinweg haben ein Dutzend Analysten unabhängig voneinander entdeckt, dass rohe Wetterdaten die Modellleistung während der Feiertage verschlechtern, dass der Lagerbestand eines bestimmten Lieferanten eine systematische Verzögerung enthält und dass der Standardansatz zur Behandlung von Werbeveranstaltungen Zielverlust verursacht. Als die ursprünglichen Analysten zu anderen Teams wechselten oder das Unternehmen verließen, ging das Wissen mit ihnen. Ohne eine institutionelle Aufzeichnung dessen, was versucht wurde, was fehlgeschlagen ist und warum, kann ein Modellautomatisierungsmechanismus nicht auf gesammelte Erfahrungen aufbauen. Es beginnt einfach von vorne, wieder und wieder, und verschwendet unnötig Zeit.

Was eine echte Lösung erfordert

Die Geschichte der ML-Automatisierung ist eine Geschichte von Teillösungen. AutoML hat das enge Problem des Hyperparameter-Tunings angegangen, konnte aber nicht mit Zielmismatch oder organisatorischer Absicht umgehen. MLOps hat Produktionspipelines robuster und einfacher zu überwachen gemacht, aber MLOps-Tools führen eine Strategie aus, anstatt sie zu definieren. Neuere Coding-Agenten stellen einen echten Fortschritt dar, aber sie haben denselben blinden Fleck geerbt. Sie generieren Code gut, während sie ohne organisatorischen Kontext oder institutionelle Erinnerung arbeiten.

Ein System, das tatsächlich autonome ML-Engineerings ermöglichen kann, müsste Fähigkeiten haben, die kein existierendes Tool in Kombination bietet. Es müsste Geschäftsziele auf Modellziele abbilden, was eine Übersetzung ist, die nicht allein aus den Daten abgeleitet werden kann. Es müsste relevante Daten über fragmentierte Systeme mit inkonsistenten Schemata entdecken, während es automatisch Compliance-, Governance- und Sicherheitsbeschränkungen einhält, anstatt Menschen zu verlangen, sie als separaten Prozess zu verwalten. Es müsste institutionelle Erinnerung haben, um bestehende Arbeit zu visualisieren, zu verstehen, warum vergangene Experimente aufgegeben wurden und auf dem aufzubauen, was Kollegen bereits wissen.

Strenge Audit-Protokolle, die die Herkunft über Datenversionen, Feature-Definitionen und Code-Commits verfolgen, müssten ein Kernmechanismus sein, um das System in dem zu verankern, was tatsächlich passiert ist. Und ein solches System müsste eine sorgfältige Mensch-im-Loop-Design haben. Nicht eine binäre Wahl zwischen vollständiger Automatisierung und vollständiger manueller Kontrolle, sondern Unterstützung für verschiedene Interaktionsgrade in Abhängigkeit von der Aufgabe, den Einsatz und dem Vertrauen des Systems an jedem Entscheidungspunkt. Automatisierung, die menschliches Urteilsvermögen bei kritischen Momenten umgeht, ist kein Feature von gut gestalteter KI, sondern ein Fehlermodus.

Was noch kein Labor gelöst hat, ist, wie man ein semantisches Verständnis organisatorischer Daten schafft, das versteht, was die Daten in einem bestimmten institutionellen Kontext bedeuten. MCP löst das Konnektivitätsproblem. Es löst aber noch nicht das Bedeutungsproblem. Das bleibt die offene Forschungsfront.

Was möglich wird

Die wirtschaftlichen Auswirkungen der Lösung dieser Probleme sind erheblich. Die individuelle ML-Entwicklung erfordert heute Spezialisten und Wochen der Iteration, sogar für gut definierte Probleme. Ein System, das den gesamten Workflow autonom von der Problemdefinition über die Datenerfassung, Modellentwicklung und Modellbewertung navigieren kann, würde diese Gleichung dramatisch verändern, Zeitpläne komprimieren und wertvolle Anwendungsfälle öffnen, die derzeit zu ressourcenintensiv sind, um sie zu verfolgen. Projekte, die früher Teams mit tiefem ML-Expertenwissen erforderten, die Wochen lang arbeiteten, können jetzt in Tagen abgeschlossen werden, ohne so viel von den seltenen ML-Expertenzeit zu verwenden.

Die Herausforderungen der Kontextfragmentierung, semantischen Mehrdeutigkeit und fehlenden institutionellen Erinnerung sind nicht einzigartig für die Unternehmens-ML. Sie manifestieren sich unter unterschiedlichen Einschränkungen bei der Konstruktion von Foundation-Modell-Trainingspipelines, bei denen Tausende von heterogenen Datensätzen aggregiert, gefiltert und iterativ verfeinert werden müssen. Während die beiden Szenarien sich in Struktur und Ziel unterscheiden, sind beide durch den gleichen zugrunde liegenden Engpass eingeschränkt: dem Fehlen von Systemen, die Kontext zuverlässig wiederherstellen, Herkunft verfolgen und auf vorherige Arbeit über Iterationen aufbauen können. Die Automatisierung der Modellentwicklung im Unternehmen ist daher ein kritischer Schritt auf dem Weg zu KI-Systemen, die sich selbst verbessern können.