Marke Eigenbau als Bremsklotz für KI-Entwicklertools

Im Bereich der ML-Plattformen herrscht derzeit Wildwuchs, der den produktiven Einsatz von KI im Unternehmen bremst.

Lesezeit: 7 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 17 Beiträge
Von
  • Clemens Mewald
Inhaltsverzeichnis

Trotz der rasanten Entwicklung im Bereich Machine Learning (ML) fehlt ein einheitliches Design für ML-Plattformen. Dass sich die Entwickler-Community noch nicht darauf einigen konnte, führt zu einer Vielzahl unterschiedlich gestalteter Systeme mit undefinierten Schnittstellen. Infolgedessen hat es sich als schwierig erwiesen, eine geeignete Infrastruktur für KI-Entwicklertools auszuwählen.

Schließlich leidet die Art und Weise, wie Unternehmen die Werkzeuge nutzen, unter dem sogenannten IKEA-Effekt: das Phänomen, dass Menschen den Produkten, an deren Entstehung sie mitgewirkt haben, mehr Wert beimessen. Ein Ingenieursteam, das von Grund auf seine eigene ML-Plattform aufgebaut hat, wird sie unabhängig von potenziellen Fehlern mehr schätzen, als wenn es einfach etwas von einem Anbieter "out of the box" gekauft hätte.

Wenn neue Techniken entstehen, wächst in der Regel anfangs die Zahl der Ideen, und im Anschluss mangelt es häufig an sinnvollen Konzepten zur Umsetzung. Aller Voraussicht nach wird künstliche Intelligenz viele Industriezweige verändern – oft zu einem strategischen Vorteil. Sie wird sogar neue Geschäftsmodelle schaffen und Unternehmen werden auf "KI First" setzen. Infolgedessen häufen alle großen Cloud-Anbieter (und unzählige Start-ups) Rechenleistung an, um KI-Entwicklertools einem breiteren Publikum bereitzustellen – vor allem großen Unternehmen. Alle Anbieter versuchen im Großen und Ganzen, die gleichen Benutzerbedürfnisse zu erfüllen, aber mit deutlich unterschiedlichen Ansätzen und Ergebnissen. Die Diversität führt zu unterschiedlichen Designs.

Dieses Phänomen existiert auf jeder Ebene des Stacks und schreitet in der Regel "bottom-up" fort. Sobald die Benutzerakzeptanz eines Designs seine Konkurrenten deutlich genug übertrifft, wird es zu einem dominanten Design und damit zu einem De-facto-Standard.

Ein Beispiel dafür sind die zahlreichen ML-Frameworks wie TensorFlow und PyTorch, die mehrere Generationen von APIs zuerst in der Entwicklung eingeführt, aber kurz darauf wieder eingestellt haben. Die Projekte haben sich aber nun auf annähernd standardisierte APIs unter anderem mit Layers geeinigt. Die Notwendigkeit der Konvergenz in Bezug auf ein dominantes Design wird besonders deutlich bei Plattformprodukten, bei denen es teuer ist, unzählige konkurrierende Designs beizubehalten. Das ist bei ML-Frameworks der Fall, bei denen Data Scientists, ML Engineers, ISVs, Trainer und weitere Projektbeteiligte nicht mit Hunderten von überlappenden und inkompatiblen APIs zurechtkommen.

Der hochtrabende Begriff "KI-Entwicklertools für Unternehmen" bezeichnet in Wirklichkeit die Gattung der ML-Plattformen. Da ein vorherrschendes Design dafür fehlt, existiert keine allgemein akzeptierte Definition. Eine denkbare wäre: "Eine ML-Plattform ist eine horizontale Technik (d. h. nicht spezifisch für einen vertikalen Anwendungsfall), die alle Möglichkeiten bietet, um den gesamten Lebenszyklus von ML-Anwendungen abzudecken." Abbildung 1 veranschaulicht einige der Komponenten einer solchen Plattform.

Ein vereinfachter Überblick über die unterschiedlichen Komponenten, die als Teil einer ML-Plattform betrachtet werden (Abb. 1)

Derzeit mangelt es sogar an der Übereinstimmung über den Umfang der ML-Plattformen, von denen einige beispielsweise keine Funktionen für das Pre-Training (Data Prep) bieten.

Für das Fehlen eines vorherrschenden Designs für ML-Plattformen gibt es mehrere Gründe:

  • Die zugrundeliegenden Techniken sind noch nicht ausgereift. Viele Methoden, die innerhalb einer ML-Plattform zum Einsatz kommen, befinden sich noch in einem frühen Stadium ihres Lebenszyklus. Es ist schwierig, eine Plattform aufzubauen, die kontinuierlich aktualisierte ML-Modelle bereitstellt, wenn das für diese Modelle verwendete ML-Framework inkompatible Änderungen an seinem Checkpointing-Format vornimmt. Eine Analogie wäre eine Benutzeroberfläche für eine Webanwendung, zu der anfangs keine Backend-APIs definiert sind. Entwickler müssten dabei stets Code anpassen, während sich die Schnittstellen weiterentwickeln. Im Bereich des Machine Learning verändern sich die APIs äußerst schnell, was viele Anpassungen zur Folge hat.
  • Die Entwickler von ML-Plattformen wissen nicht, was sie nicht wissen. Viele Data Engineers haben anfangs große Pläne für den Aufbau einer umfassenden ML-Plattform. In den meisten Fällen ist ihr Vorstellungsvermögen für deren Umfang jedoch zu begrenzt. Letztlich unterschätzen sie damit die Adaption und Umsetzung für ihr Unternehmen. Die meisten ML-Plattform-Projekte beziehen nur Module zum Trainieren von ML-Modellen sowie eine oder mehrere Optionen für deren Anwendung ein. Oft fehlen wichtige Module wie automatische Tests für ML-Modelle oder Simulationen.
  • Die Nutzer der ML-Plattformen wissen ebenfalls in der Regel nicht, was sie nicht wissen. Viele Unternehmen kaufen ML-Plattformen ein, ohne zu wissen, welche Funktionen sie erwarten oder welche Fragen sie stellen sollten. Es ist für Unternehmen nahezu unmöglich, die Angebote zu bewerten, da die Beschreibungen ähnlich klingen, aber die Plattformen äußerst unterschiedliche Ansätze verfolgen. In Folge dieses Äquivalenzproblems erkennen sie die Unterschiede erst, wenn es zu spät ist (s. Abb. 2).

Die Illustration des Unterschieds zwischen der wahrgenommenen und tatsächlichen Überlappung von TFX, Kubeflow und MLflow ist mit einem Augenzwinkern erstellt (Abb. 2).