Foto: Phonlamai Photo - shutterstock.com
"Ich habe drei Wochen gebraucht, um das Machine-Learning-Modell zu entwickeln. Inzwischen ist ein Jahr vergangen und es ist immer noch nicht in Produktion." Diese Klage eines anonymen KI-Entwicklers beschreibt das Dilemma, in dem viele Unternehmen stecken, die ML-Projekte verfolgen und eigentlich die Vorteile von künstlicher Intelligenz und Machine Learning (KI/ML) in größerem Umfang nutzen möchten.
Auch die Mitglieder des Anwenderverbands CBA Lab sehen bei der Übernahme der als Prototypen entwickelten ML-Lösungen in die Produktion noch einige unbewältigte Herausforderungen. Hier ist man noch weit entfernt von einem reifen und etablierten DevOps-Ansatz, der bei Entwicklung und Produktion von Nicht-KI/ML-Projekten inzwischen zum Mainstream geworden ist.
DevOps beschreibt die Verzahnung des Entwicklungsprozesses mit dem IT-Betrieb. Deshalb befasst sich der aktuelle KI/ML-Workstream des CBA Lab genau mit diesem Übergang zwischen Entwicklung und Produktion. Ziel ist es laut Workstreamleiter Jürgen Klein, Chefarchitekt der Carl Zeiss AG, einen Ansatz zu entwickeln, der den Anforderungen in ML-Projekten an Qualität und Automatisierungsgrad entsprechen kann. Der Workstream hat sich deshalb intensiv mit dem sogenannten MLOps-Ansatz auseinandergesetzt. Machine Learning Operations (MLOps) steht für eine auf Machine Learning ausgerichtete Vorgehensweise, die die Tugenden des Development and Operations-Modells (DevOps) nutzt.
Hürden beim Einsatz von Machine Learning
Der Workstream führt einige der Herausforderungen aus, die der ML-Einsatz mit sich bringt:
Der Betrieb von ML-Systemen ist aufwändiger als bei klassischer Software, weil Training, Deployment und das Monitoring sowie die regelmäßige Anpassung (Retraining) der ML-Modelle mehr Aufwand bringen. Auch die Versionierung ist anspruchsvoll, weil bei ML die zugehörigen Modelle, Trainings, Validierungs- und Testdaten mit versioniert werden müssen, um die Nachvollziehbarkeit zu gewährleisten.
Datenschutz ist in Bezug auf ML oft nicht klar. Dürfen zum Beispiel Bilder von Personen für das Training von ML-Modellen genutzt werden? Wenn Entscheidungen von einer ML getroffen werden, etwa bezüglich eines Kredites, ist nicht klar geregelt, wie detailliert die Entscheidung gegenüber den Betroffenen nachvollziehbar gemacht werden muss.
Erfahrene Data Science- und ML-Engineering-Spezialisten sind am Arbeitsmarkt eine rare Ressource. Sie werden aber für kompetente Entwicklungsteams gebraucht - genauso wie Expertise im Bereich Software-Engineering und Betrieb. Den eingesetzten Teams fehlt es außerdem an Kompetenzdiversität. Das kann dazu führen, dass Pilotprojekte in kleinem Rahmen funktionieren, dann aber technisch und organisatorisch nicht skalieren. Cross-funktionale Teams können hier eine Lösung darstellen.
Die Kosten werden häufig unterschätzt, weil mehr Aufwand als in einem klassischen Softwareprojekt berücksichtigt werden muss (zum Beispiel höhere Personalkosten oder Kosten für Datenaufbereitung, Spezialhardware, Modelltraining, Wartezeiten der Fachseite, Überführung in die Produktion).
Entscheidungen sind häufig nicht nachvollziehbar.
Es gibt unbekannte Abhängigkeiten der Daten, die für das Trainieren der Modelle verwendet werden.
Daten fehlen oder sind nicht verlässlich.
Einige dieser Herausforderungen können adressiert werden, in dem man ML-Anwendungen einem erweiterten DevOps-Ansatz unterwirft, dem sogenannten MLOps. Es erweitert die bekannten DevOps-Prinzipien, um die Entwicklung und den Betrieb von ML-basierten Anteilen der Lösungen spezifisch und optimal zu unterstützen. Das Hinzufügen neuer Datensätze, aber auch die schleichende Degradation der Modellperformanz benötigt ein kontinuierliches Training, um diese stabil zu halten oder gar zu verbessern. Da ein ML-Modell meistens nur eine kleine, aber sehr kritische Komponente eines Software-System darstellt, muss ihre Interaktion mit anderen Komponenten ständig überprüft werden. Das bedeutet die Überprüfung neuer Modelle durch besondere Testverfahren wie Daten- und Modellvalidierung.
Voraussetzungen für MLOps schaffen
Das MLOps-Prinzip funktioniert allerdings nur dann, wenn die Organisation auch über die nötigen Fähigkeiten verfügt, die der CBA Workstream in einem Capability Framework zusammenfasst. Es besteht aus folgenden Bausteinen:
Mensch & Kompetenz: Der Mensch und die benötigten Fertigkeiten sind Voraussetzungen für ein erfolgreiches MLOps. Es braucht nicht nur den Data Scientist oder den ML Engineer, sondern eine Vielzahl unterschiedlichster Fähigkeiten. Diese müssen rekrutiert, ausgebildet und an die Organisation gebunden werden.
Kultur: Die Organisation muss sich auf die neuen Technologien auch kulturell vorbereiten. Es braucht bei den einzelnen Teilnehmenden einer MLOps-Initiative, aber auch in der gesamten Organisation, eine Bereitschaft, sich auf ML-unterstützte Prozesse einzulassen und diese ständig weiterzuentwickeln. Voraussetzung dafür ist die Unterstützung des Top Managements. Die Organisation kann sich erst dann zur Einführung von MLOps verpflichten, wenn das Topmanagement klare Support-Signale sendet.
Prozesse: Änderungen, die mit der Adaption von Machine Learning einhergehen, beeinflussen immer die Prozesse einer Organisation. Die Prozesse werden aufgrund des systematischen Einbezugs von Datenströmen geändert.
Daten: Sie sind der Treibstoff für eine ML-Organisation. Ohne qualitativ hochwertige und korrekte Daten gibt es kein ML. Unternehmen haben häufig Probleme mit der Qualität historischer Daten. Deshalb müssen grundlegende Fähigkeiten wie Datenaufbereitung, Datenverarbeitung und Datenqualitätssicherung verbessert werden, um die Bereitschaft für ML zu erhöhen.
Technologie und Infrastruktur: ML basiert auf einem komplexen Technologie-Stack und benötigt eine hoch performante Infrastruktur, die in einem sehr dynamischen Umfeld funktionieren muss. Die stetige technologische Innovation und Pflege sind unabdingbar für ML. Dafür müssen die notwendigen Ressourcen sowohl finanziell als auch personell bereitgestellt werden.
Risiko, Compliance & Ethik: Der Einsatz von Systemen, die potenziell selbständig Entscheidungen treffen, birgt Gefahren. So können unausgewogene Daten zu tendenziösen Resultaten und unethischen Entscheidungen führen, die im schlimmsten Fall Menschen gefährden und die ganze Organisation bedrohen können. Das Beherrschen der Risiken und die Einhaltung von Compliance-Vorgaben werden damit schwieriger.
Der Workstream des CBA fasst seine Erkenntnisse in einem ausführlichen Whitepaper zusammen. Außerdem macht er den Mitgliedern transparent, welche ML-Tools von den KI-aktiven Unternehmen im CBA Lab für welchen Zweck eingesetzt werden. Die sich daraus ergebende Liste wird einheitlich strukturiert sein, sodass auf einen Blick klar wird, welche Tools für was eingesetzt werden.
Das Cross-Business-Architecture Lab
Das Cross-Business-Architecture Lab ist ein Verband von Anwendern für Anwender. Erprobte Best Practices werden geteilt und zu belastbaren, direkt nutzbaren Ergebnissen weiterentwickelt. Der Verband erarbeitet mit und für seine Mitglieder innovative "Bausteine" für die digitale Transformation, die die Architektur prägen und organisieren. (wh)