Seite 2: Formfaktor als Problem

Inhaltsverzeichnis

Gewöhnlich bezieht sich der Begriff Formfaktor entweder auf elektronische Komponenten wie Hauptplatinen oder auf unterschiedliche Technik-Inkarnationen und deren Verpackung für die Nutzer. Das erste iPhone hat beispielsweise den vorherrschenden Formfaktor für Smartphones definiert. Im Folgenden soll dieser Begriff alles zusammenzufassen, was in Betracht zu ziehen ist, wenn von Produktoberfläche, Benutzererfahrung oder Entwicklererfahrung die Rede ist. Es steht für alle Bereiche, in denen Entwickler mit einer ML-Plattform interagieren.

Derzeit unterscheiden sich die KI-Entwicklungstools auch hinsichtlich ihrer APIs deutlich. Diese Aussage lässt sich gut an einem Beispiel veranschaulichen: Ein minimaler Satz an Techniken für das Trainieren und Implementieren eines ML-Modells, könnte wie folgt aussehen:

• Ein Data-Engineering-Produkt wie Spark für den richtigen Umgang mit Daten,
• eine Bibliothek wie TensorFlow für das Training des ML-Modells,
• Docker für das Verpacken von Modellen sowie
• Kubernetes, um die Docker-Container zu orchestrieren

Es ließe sich argumentieren, dass es in diesem Fall eine Arbeitsteilung geben sollte: Dateningenieure sollten die Datenpipelines schreiben, Data Scientists die Modelle trainieren und Softwareingenieure die Deployment-Systeme schreiben. Dabei könnte wohl keine ML-Plattform alle gewünschten Funktionen bieten. Jedoch stellen Unternehmen immer wieder fest, dass diese künstliche Trennung der Belange, die das Ergebnis von Technologiegrenzen ist, die lange vor dem Entstehen der ML-Plattformen gezogen wurden, zu einer erheblichen Verlangsamung, kostspieligen Fehlern und insgesamt zu höheren Ausfallraten von ML-Projekten führt.

Es wäre naiv, davon auszugehen, dass Werkzeuge und Prozesse, die vor Jahrzehnten für das Software Engineering geschaffen wurden, auf magische Weise auf ML übertragbar sind. Beispielsweise ist es wenig sinnvoll, ML-Modellartefakte, die ziemlich groß sein können und sensible Daten enthalten, einfach in für Sourcecode vorgesehene Versionskontrollsysteme zu überführen. So hat beispielsweise Databricks die MLflow Model Registry aufgebaut, um den Versionierungs- und Bereitstellungs-Lebenszyklus von ML-Modellen zu verwalten. Außerdem existiert das Open-Source-Projekt DVC zum Versionieren.

Wenn Data Scientists oder Softwareingenieure in der Lage sein sollen, den gesamten ML-Lebenszyklus zu managen, müssen die Werkzeuge einem breiten Benutzerkreis zugänglich sein und nicht nur DevOps-Experten. Bei Unternehmen wie Google ist es nicht ungewöhnlich, dass eine einzelne Person den gesamten Lebenszyklus von der Datenpipeline bis zur Modelleinführung überwacht. Andere sind zu der gleichen Erkenntnis gelangt und schaffen genau deshalb eine breiter angelegte ML-Engineer-Rolle.

Versuche für konsistentere Formfaktoren

Einige Anbieter haben erkannt, wie begrenzt das Zielpublikum für Anwendungen ist, die technische Kenntnis von Spark, TensorFlow, Docker und Kubernetes erfordern. Sie haben versucht, unterschiedliche Formfaktoren zu schaffen, die die Komplexität abstrahieren. Die meisten von ihnen scheitern jedoch dabei.

Ein Ansatz ist das SQL-basiertes Machine Learning: Einige Hersteller behaupten, dass ihre Produkte Machine Learning so einfach machen wie das Schreiben von SQL-Abfragen. Um das zu erreichen, lassen sie die Anwender jedoch einen Schnipsel Python-Code als Prozedur registrieren, oder sie spiegeln einfach dieselben Python-APIs in SQL wider, um beispielsweise die Schichten eines neuronalen Netzes in einer SQL-Abfrage zu definieren. Der Ansatz ist nicht neu und erschwert häufig sogar langfristig den Umgang mit dem Werkzeug, wenn es beispielsweise um das Debuggen des Python-Codes geht. Sobald Hardwarebeschleuniger wie GPUs ins Spiel kommen, zeigt sich häufig, was mit der Verletzung der Grundprinzipien der Abstraktionsebenen gemeint ist: Eine SQL-Abfrage löst Fehler aus, die spezifisch für die Hardware sind, auf der der Python-Code läuft. Oder sie schlägt im schlimmeren Fall einfach stillschweigend fehl, und die Verantwortlichen müssen sich auf die Jagd nach Protokolldateien begeben.

Das UI-basiertes Machine Learning bezeichnet eine Klasse von Produkten, die versucht, No-Code-Ansätze für sogenannte Citizen Data Scientists anzubieten. UI-basierte Workflows sollen die Benutzer durch die typischen Schritte beim Aufbau von Data- Science- und ML-Modellen führen. Es können zwei übliche Fehlermodi für diese Art von Produkten beobachtet werden:

1. Bei einem oder mehreren Schritten im Arbeitsablauf, üblicherweise dem Modellierungsschritt, fordert das Tool von den Benutzern die Angabe von Low-Level-Parametern wie der L1-Regularisierung an. Letztere trägt dazu bei, ein Modell über die bekannten Datenpunkte hinaus zu generalisieren oder zumindest zu bestimmen, wie sich ein guter Wert dafür wählen lässt. Wer sich damit auskennt, wird kaum auf ein UI-basiertes ML-Produkt setzen.
2. In zahlreichen Fällen bieten die Werkzeuge nur Umsetzungen für die höchste Abstraktionsebene und keine weiteren Optionen für den Fall, dass Benutzer an die Grenzen der Tools stoßen. Infolgedessen stellen viele Unternehmen fest, dass UI-basierte ML-Tools nicht ausreichen, um Anwendungsfälle aus dem wirklichen Leben zu lösen.

Die beiden Gründe führen zu einem typischen Ungleichgewicht zwischen Produkt und Marktanforderung, und die meisten UI-Tools für Machine Learning sind nicht viel mehr als Demos und Proofs of Concept.

Vermeiden des IKEA-Effekts

Viele Unternehmen, die weder über ein dominantes Design noch über einen angemessenen Formfaktor verfügen, kämpfen mit der Einführung von ML-Plattformen. Sie verzweifeln schließlich am Umbau ihrer Unternehmen zu einem "KI-First"-Geschäftsmodell. Diejenigen, die es versuchen, leiden oft unter dem IKEA-Effekt.

Ingenieure lieben es, Produkte zu erfinden und sich neue Fähigkeiten anzueignen. Infolgedessen belegen viele Ingenieure Online-ML-Kurse auf zu niedrigem Niveau. Ermutigt durch ihr neu erworbenes Wissen, das häufig nur winzige Details von ML abdeckt, versuchen sie die konkreten Herausforderungen ihres Unternehmens anzugehen. An dieser Stelle kommt der IKEA-Effekt ins Spiel.

Dabei würde wohl kein Team sagen: "Lasst uns unsere eigene Datenbank von Grund auf aufbauen". Da bei ML-Plattformen ein vorherrschendes Design und ein gemeinsamer Formfaktor fehlt, ist es für ein Team aus wenigen Entwicklern unmöglich, eine passende ML-Plattform zu entwickeln. Dass ihnen Daten und Erfahrungswerte fehlen, kommt erschwerend hinzu.

Blick in die Kristallkugel

Das wirft die Frage auf, wie KI-Entwicklertools in zehn Jahren aussehen werden. Tatsächlich ist in einer idealen Welt der gesamte Prozess des Erstellens datengesteuerter Anwendungen nur ein üblicher Teil der Arbeit von Softwareingenieuren, ohne dass sie einen Doktortitel in KI oder einen Master für Kubernetes erwerben müssen.

Der Autor erwartet für die nächsten zehn Jahre folgende Entwicklungen:

• Die Hersteller werden sich auf einen dominanten Entwurf für ML-Plattformen einigen. Heutzutage konzentrieren sich viele Anbieter nur auf das Trainieren von ML-Modellen und vergessen dabei, dass bei Machine Learning viel Zeit für die Datenverarbeitung anfällt. Wahrscheinlich wird ein Produkt an Zugkraft gewinnen und den Weg zur Definition der Kategorie weisen. Viele Anbieter werden aus dem Markt ausscheiden, während andere sich dem vorherrschenden Design anpassen.
• Es wird einige wenige sinnvolle Formfaktoren für unterschiedliche Zielgruppen geben. Ein einziger Formfaktor ist nicht sinnvoll, aber unterschiedliche Abstraktionsebenen durchaus wünschenswert. Jede Schicht muss gut definiert sein, und Abstraktionen sollten nicht zwischen den Schichten durchsickern. Bislang gibt es noch kein gutes Beispiel für die höchste Abstraktionsebene in Form von Tools wie den genannten SQL- oder UI-basierten ML-Werkzeugen mit ihren derzeitigen Schwächen.
• Unternehmenskunden werden erkennen, dass der Aufbau eigener ML-Plattformen nicht zu ihrem Vorteil ist. Wenn ein vorherrschendes Design vorhanden ist, wird es offensichtlicher sein, wie sinnlos dieser Aufwand ist und dass es nicht in die Kernkompetenz der Unternehmen fällt. Für die meisten von ihnen ergibt sich der Wert aus der Anwendung von ML-Plattformen auf ihre Geschäftsprobleme, nicht aus dem Aufbau und der Instandhaltung eigener ML-Plattformen.