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. Der Pfad zur Modellautomatisierung erfordert jedoch 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 Maschinenlern- (ML-) Ingenieurwesen. Ein häufiger Irrtum geht davon aus, dass ML eine Vorgängertechnologie der modernen KI ist und dass Grundmodell einfach ML ersetzt hat. Dies missversteht die Beziehung. Als akademische Disziplin umfasst ML alle Aspekte der Modellierung, einschließlich der Schulung von Grundmodellen im Zentrum des aktuellen KI-Moments. Es gibt jedoch einen bedeutenden Unterschied in Bezug auf Skala und Datenkomplexität.

Traditionelle ML-Modelle werden in der Regel auf sorgfältig kuratierten, domänen-spezifischen Datenbeständen mit Tausenden oder Millionen von Beispielen trainiert. Grundmodelle hingegen werden auf Tausende von Datenbeständen gleichzeitig trainiert, die aus sehr unterschiedlichen Quellen mit inkonsistenten Formaten, Herkunft und Qualität stammen. Dieser Unterschied in der Datenmenge und -heterogenität ist ein grundlegender Grund, warum das Datenmanagement viel schwieriger und wichtiger wird, wenn die Modelle leistungsfähiger werden.

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 erstellen. Sobald die KI den Prozess, durch den sie trainiert wird, verbessern kann, haben sich die Verbesserungen nach unten auf jedes Gebiet aus, in dem die KI eingesetzt 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 ausgelegt waren, miteinander zu kommunizieren. Betrachten Sie ein Gesundheitssystem, das ein Modell zur Erkennung von Sepsis entwickelt. Die klinischen Kriterien, die für dieses Problem relevant sind, wie z. B. Vitale Grenzwerte, Laborwerte und Dokumentationsstandards, können in völlig getrennten Modulen eines elektronischen Gesundheitsakten-Systems leben.

Die zweite Barriere ist die semantische Mehrdeutigkeit. Die Bedeutung ist nicht in den Daten inhärent, sondern kontext- und organisationsabhängig. Der gleiche Feldname in zwei verschiedenen Datenbanken kann sich auf subtil unterschiedliche Dinge beziehen. Konzepte wie Umsatz, aktiver Benutzer und Fluktuationsrate haben routinemäßig mehrere gültige Definitionen innerhalb eines Unternehmens. 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 ziehen aus Feldern, die wörtlich “Umsatz” in ihren jeweiligen Systemen genannt werden, aber ein teamübergreifender Bericht, der sie kombiniert, würde drei unvereinbare Zahlen stillschweigend mischen.

Die dritte und systemischste Barriere ist das Fehlen eines dokumentierten organisatorischen Gedächtnisses. Die Nachverfolgung der Herkunft, die Auflösung von Inkonsistenzen und die Aufrechterhaltung von Qualitätsignalen über so viele Quellen hinweg ist ein ungelöstes Problem, sogar für menschliche Teams. Ohne ein institutionelles Gedächtnis dessen, was versucht wurde und wie gut diese Ansätze funktioniert haben, wird jedes Modellautomatisierungsmechanismus immer wieder die gleichen Sackgassen entdecken, Zeit und Ressourcen verschwenden.

Betrachten Sie ein Data-Science-Team in einem Einzelhandelsunternehmen, das ein Modell zur Nachfrageprognose entwickelt. Über drei Jahre hinweg haben ein Dutzend Analysten unabhängig voneinander entdeckt, dass rohe Wetterdaten die Modellleistung während der Feiertagswochen verschlechtern, dass der Lagerbestand eines bestimmten Lieferanten eine systematische Verzögerung enthält und dass der Standardansatz zur Behandlung von Werbeveranstaltungen eine 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 dem angesammelten Erfahrung 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 der Hyperparameter-Anpassung angegangen, konnte aber nicht mit Zielkonflikten oder organisatorischen Absichten umgehen. MLOps hat Produktionspipelines robuster und einfacher zu überwachen gemacht, aber MLOps-Tools führen eine Strategie aus, anstatt sie zu definieren. Neuere Codierungsagenten stellen einen echten Fortschritt dar, aber sie haben den gleichen blinden Fleck geerbt. Sie generieren Code gut, während sie ohne organisatorischen Kontext oder institutionelles Gedächtnis operieren.

Ein System, das tatsächlich autonome ML-Ingenieurwesen ermöglicht, müsste Fähigkeiten haben, die keine vorhandene Werkzeugkombination bietet. Es müsste Geschäftsziele in Modellziele übersetzen können, was eine Übersetzung ist, die nicht allein aus den Daten abgeleitet werden kann. Es müsste relevante Daten über fragmentierte Systeme mit inkonsistenten Schemata hinweg entdecken, während es automatisch Compliance-, Governance- und Sicherheitsbeschränkungen einhält, anstatt zu verlangen, dass Menschen sie als separaten Prozess verwalten. Es müsste institutionelles Gedächtnis haben, um vorhandene Arbeit zu visualisieren, zu verstehen, warum vergangene Experimente aufgegeben wurden, und auf dem aufzubauen, was Kollegen bereits wissen.

Strenge Audit-Trails, die die Herkunft über Datenversionen, Feature-Definitionen und Code-Commits hinweg nachverfolgen, müssten ein Kernmechanismus für die Verankerung des Systems in dem sein, was tatsächlich passiert ist. Und ein solches System müsste einen sorgfältigen menschlichen Ansatz im Entscheidungsprozess haben. Nicht eine binäre Wahl zwischen vollständiger Automatisierung und vollständiger manueller Kontrolle, sondern Unterstützung für unterschiedliche Ebenen der Interaktion, abhängig von der Aufgabe, den Einsatz und dem Vertrauen des Systems bei jedem Entscheidungspunkt. Automatisierung, die menschliche Urteilsfähigkeit bei kritischen Momenten umgeht, ist kein Merkmal eines gut konzipierten KI-Systems, sondern vielmehr ein Fehlermodus.

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

Was möglich wird

Die wirtschaftlichen Auswirkungen der Lösung dieser Probleme sind erheblich. Die Entwicklung von benutzerdefinierten ML-Modellen 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 könnte, würde diese Gleichung dramatisch verändern, die Zeiträume 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 über Wochen arbeiteten, können jetzt in Tagen abgeschlossen werden, ohne so viel Zeit von knappen ML-Experten zu benötigen.