News

07.03.2023

Damit ML-Lösungen nicht in der Pilotphase stecken bleiben

Die Erwartungen an Machine Learning (ML) sind riesig. Dass viele ML-Projekte in der Pilot- oder Proof-of-Concept-Phase stecken bleiben, liegt aber nur zum Teil an überzogenen Erwartungen. Es fehlt den Unternehmen oft an Infrastruktur, den richtigen Capabilities oder schlicht an Daten. Worauf sollten Unternehmen achten, damit ML-Lösungen tatsächlich produktiv eingesetzt werden können? Unser Workstream KI/Machine Learning hat Antworten.

Autoren: Ilir Fetai, Marek Imialek, Eric Liese

Die Erwartungen an ML sind übergroß. Gleichzeitig fehlen die Experten, deren Mangel durch den ultraschnellen Technologiewandel sich noch gravierender bemerkbar macht. Durch den Erfolgsdruck getrieben, verzichten die meisten Unternehmen am Anfang ihrer ML-Projekte auf den Aufbau einer geeigneten Infrastruktur. Damit könnten sie nachvollziehbar und automatisiert Experimente mit verschiedenen Methoden bzw. Lernalgorithmen, Parametrisierungen und Daten durchführen. Aber sie setzen auf Prototypen, bei denen das meiste händisch erledigt werden muss. Das ist bei ML deutlich problematischer als bei klassischen Software-Projekten, weil ML-Modelle durch ihre Abhängigkeit von Daten regelmäßig angepasst werden müssen. Anpassungen sind ohne die entsprechende Infrastruktur deutlich aufwändiger, weil nichts automatisiert werden kann. Das ist einer der wesentlichen Gründe, warum ML-Projekte so oft in der Prototypen-Sackgasse enden.

Unsicherheiten auf der Fachseite

Ein zweiter wesentlicher Grund dafür ist, dass fachliche Entscheider von ML-Lösungen das gleiche erwarten wie von klassischen Softwarelösungen: deterministische Ergebnisse mit erklärbarem Antwortverhalten. Deshalb stellen sich schnell Unsicherheiten ein, wenn Prototypen in Fachbereichen erprobt werden. Die ML-Methode ist häufig unklar, das Zustandekommen der Ergebnisse kann nicht nachvollzogen werden und dass die Auswahl der Trainingsdaten großen Einfluss auf die zu erlernenden Zusammenhänge hat, ist den meisten auf der Fachseite ebenfalls nicht klar.

Weitere Gründe für das Steckenbleiben von ML-Projekten in der Prototypenphase sind:

  • 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, z. B. 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 (z. B. höhere Personalkosten oder Kosten für Datenaufbereitung, Spezialhardware, Modelltraining, Wartezeiten der Fachseite, Überführung in die Produktion).
  • Fehlende Nachvollziehbarkeit der Entscheidungen.
  • Unbekannte Abhängigkeiten der Daten, die für das Trainieren der Modelle verwendet werden.
  • Fehlende oder nicht verlässliche Daten.

ML ist keine Allzweckwaffe

Gerade weil die Erwartungen groß sind und die Hürden hoch, ist es wichtig zu fragen, welche Aufgaben sich mit ML-Methoden tatsächlich lösen lassen. Um diese Frage positiv beantworten zu können, muss eine Aufgabe folgende Eigenschaften aufweisen: Es existiert ein Muster, sie ist mathematisch nicht zu beschreiben und es gibt umfangreiche Trainings- & Testdaten.

Selbst wenn die Voraussetzungen für ML erfüllt sind, ist ML nicht immer der beste Lösungsansatz. Zuerst muss die Frage gestellt werden, ob sich das Problem nicht bereits mit traditionellen Methoden lösen lässt, z. B. durch Berechnung der zugrundeliegenden physikalischen Prozesse. Diese Methoden bieten oft den Vorteil, dass die Vorhersagen weitaus präziser sind als die Vorhersagen mittels ML.

Übersteigt die gestellte Aufgabe eine bestimmte Komplexität und lässt sie sich nicht mehr oder nur mit erheblichem Aufwand durch mathematische Gleichungen oder andere klassische Verfahren beschreiben, dann ist es sinnvoll, ML als Lösungsansatz in Betracht zu ziehen.

MLOps ist angelehnt an DevOps

ML-Lösungen lassen sich am besten im MLOps entwickeln und betreiben. Der Begriff MLOps ist angelehnt an DevOps, aber um ML-Spezifika erweitert. Der ML-Ops-Prozess ist grob in vier Phasen untergliedert:

  1. In der Pre-Development-Phase wird betrachtet, ob alle Voraussetzungen für ein ML-Vorhaben gegeben sind, sowohl aus einer ökonomischen, einer Governance- als auch aus einer Datensicht.
  2. Die Proof-of-Concept-Phase lässt sich grob in eine Exploration- und eine Vertiefungsphase unterteilen. In der Exploration-Phase wird die prinzipielle Machbarkeit des Use-Cases auf schnelle Art und Weise überprüft. Ist diese gegeben und aussichtsreich, wird das Proof of Concept in der Vertiefungsphase tiefergelegt und bereits betriebliche Aspekte mitbetrachtet.
  3. In der Transition- und Development-Phase wird der Use-Case in eine betriebliche Umgebung eingebettet, welche auch die notwendigen Prozesse für Betrieb- und Weiterentwicklung umfasst.
  4. Schließlich wird in der Production-Phase die erarbeitete Lösung betrieben, überwacht und kontinuierlich weiterentwickelt.

Die Einführung von ML-Ops ermöglicht eine Automatisierung, Versionierung, Reproduzierbarkeit von ML-Systemen und unterstreicht gleichzeitig die erfolgreiche Zusammenarbeit der erforderlichen Fähigkeiten von Data Engineers, Data Scientists, ML-Ingenieuren und SW-Entwicklern.

Die richtigen Capabilities entscheiden

Um ML-Lösungen aus der Pilotphase in die Produktion zu überführen, braucht es neben der entsprechenden Expertise noch weitere Capabilities. Das CBA Lab hat insgesamt sechs definiert:

Mensch & Kompetenz: Der Mensch und die benötigten Fertigkeiten sind eine Grundvoraussetzung für ein erfolgreiches MLOps. Es braucht nicht nur den Data Scientist, den ML Engineer, sondern eine Vielzahl unterschiedlichster Fähigkeiten. Diese müssen rekrutiert, ausgebildet und an die Organisation gebunden werden, um bereit für eine funktionierende ML-Umgebung zu sein.

Kultur: Die Organisation muss sich auf die neuen Technologien auch kulturell vorbereiten. Es braucht bei den einzelnen Teilnehmern einer MLOps-Initiative, aber auch in der gesamten Organisation die Bereitschaft, sich auf ML-unterstützte Prozesse einzulassen und diese ständig weiterzuentwickeln. Eine Grundvoraussetzung dafür ist die Unterstützung des Topmanagements: Die Organisation kann sich erst dann zur Einführung von MLOps verpflichten, wenn das Topmanagement klare, unterstützende Signale sendet. Dazu dienen beispielsweise eine AI-Vision sowie eine entsprechende Strategie, aber auch die Förderung des Know-how-Aufbaus im Bereich von ML.

Grundlegende Elemente sind:

  • Transdisziplinäre Zusammenarbeit: MLOps basiert auf dem Zusammenführen unterschiedlicher Perspektiven und Fähigkeiten wie Fachwissen, Datenanalyse, ITC etc.
  • Innovationsbereitschaft: Fördert die Bereitschaft, bestehende Prozesse durch den Einsatz von ML zu verändern.
  • Veränderungsmanagement: Durch die gezielte Begleitung der Mitarbeitenden und konkrete Unterstützungsangebote werden Verständnis und Änderungsbereitschaft gefördert.

Prozesse: Änderungen, die mit der Adaption von ML einhergehen, beeinflussen immer die Prozesse einer Organisation. Die Prozesse werden aufgrund des systematischen Einbezugs von Datenströmen verändert. Qualität und Pflege der Daten für ML bedeuten auch neue Herausforderungen: Die Kontrolle der Prozesse und der generierten Resultate muss kontinuierlich verbessert werden, damit die MLOps nicht außer Kontrolle gerät und beträchtlichen Schaden anrichten kann.

Daten: Daten sind der Treibstoff für eine ML-Organisation. Ohne qualitativ hochwertige, vollständige 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. Folgende Elemente sind dabei von besonderer Bedeutung:

  • Datenverfügbarkeit: ML-basierte Systeme lernen auf der Grundlage großer Datenmengen.
  • Datenqualität: Je höher sie ist, umso bessere Resultate liefern die ML-basierten Systeme.
  • Datenzugriff: Data-Scientists und ML-Engineers benötigen Zugriff auf die relevanten Datenquellen, um Analysen durchzuführen sowie die Bereitstellung und den laufenden Betrieb sicherzustellen.

Technologie und Infrastruktur: ML basiert auf einem komplexen Technologie-Stack und benötigt eine hoch performante Infrastruktur, gleichwohl in einem sehr dynamischen Umfeld. Die stetige technologische Innovation und Pflege sind Grundvoraussetzung 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, welche im schlimmsten Fall Menschen gefährden und eine ganze Organisation bedrohen können. Die Beherrschung der Risiken und die Sicherstellung der Compliance werden damit vor neue Herausforderungen gestellt.

Daten, Daten immer wieder Daten

Weil hinlänglich bekannt ist, dass Daten von herausragender Bedeutung für ML sind, widmen wir ihnen in dieser kleinen Handreichung für die Produktionalisierung von ML-Lösungen noch eine genauere Erklärung. ML-Systeme bestehen grob gesehen aus zwei Komponenten: Einer Modellarchitektur und den Daten. Die Entwicklung eines solchen Systems kann deshalb mit einem modellzentrierten oder einem datenzentrierten Ansatz geschehen. Hier wird besonderes Augenmerk auf den datenzentrierten Ansatz gelegt. Deshalb betrachten wir die Aspekte Datenqualität, Metadaten oder die Daten-Governance sowie den Daten-Life-Cycle hier genauer:

Datenqualität: Mit schlechten Daten entsteht kein gutes Modell. Deshalb fokussiert sich der datenzentrierte Ansatz auf die Daten und ihre Qualität. Bei dieser Vorgehensweise wird die Modellarchitektur festgelegt und das Modell durch eine iterative Datenqualitätssteigerung verbessert, indem beispielsweise Labels korrigiert, die Konsistenz des Labeling erhöht oder die Ausgewogenheit der Daten optimiert werden.

Bei strukturierten Daten haben sich einige etablierte Messgrößen entlang mehr oder weniger etablierter Qualitätsdimensionen entwickelt, wie Vollständigkeit, Rechtzeitigkeit oder Richtigkeit. Diese Dimensionen sind ebenfalls bei unstrukturierten Daten sinnvoll, jedoch ist deren Messung nicht in gleicher Weise etabliert und vielfach auch viel schwieriger umzusetzen. Deshalb hilft die Beschränkung auf drei Qualitätsdimensionen

  • Interpretierbarkeit – Hilft der Datenpunkt den Inhalt zu verstehen?
  • Relevanz – Welchen Wert hat der Datenpunkt für das zu lernende Modell?
  • Genauigkeit – Sind die Daten präzise genug für das Lernen?

Daten-Governance: Ihr oberstes Ziel ist, die Integrität und Qualität der Daten zu gewährleisten, eine Grundvoraussetzung, um das ganze Potential der Daten abschöpfen zu können. Ein weiterer Punkt tritt zunehmend in den Fokus der Datenverarbeitung: Einzelne Unternehmen sind nicht mehr in der Lage, alle anfallenden Daten so zu veredeln, dass sie als Grundlage für ML-Trainings dienen können. Aus diesem Grund haben sie begonnen, ihre Kräfte zu bündeln und die Daten gemeinsam zu nutzen. Das verlangt nach einer gestiegenen Verantwortung, was die Sicherheit der Daten betrifft oder den Ansatz von komplexen Lernumgebungen, wie z. B. Federated-Learning. Standards und Richtlinien sind erforderlich, um sicherzustellen, dass solche gemeinsam genutzten Daten nur innerhalb definierter Grenzen verwendet werden können und kein Missbrauch damit getrieben wird.

Daten-LifeCycle: N. Polyzotis beschreibt den Daten-LifeCycle: Daten werden von einer Primärquelle, z. B. einem Sensor, erhoben und für das ML vorbereitet, zum Beispiel durch den Labeling-Prozess. Parallel dazu muss die „Ground Truth“ sorgfältig erstellt werden. Mit den Trainingsdaten wird anschließend ein Modell erstellt und evaluiert. Schließlich muss die Genauigkeit des Modells anhand der „Ground Truth“ Daten überprüft werden. Diese Validierung muss jedoch nicht nur für ein neu trainiertes Modell erfolgen, sondern kontinuierlich auch für bestehende, produktive Modelle. Gibt es Abweichungen zwischen diesen Datensets, wird das auf Basis der Trainingsdaten erstellte Modell keine konsistenten Resultate zeigen. Deshalb müssen erkannte Abweichungen, zum Beispiel Unterschiede oder Änderungen der Input-Daten, zu den Trainingsdaten zurückgemeldet werden, um die Trainingsdaten zu verbessern. Schließlich sind die Trainings- und eventuell auch die verwendeten „Ground Truth“-Daten an die neuen Verhältnisse anzupassen: Die Daten müssen bereinigt, nicht mehr valide Datenpunkte aus den Trainings- und Validierungsdaten entfernt und schließlich betroffene Modelle optimiert werden. Um dies gewährleisten zu können, ist es unumgänglich, dass alle notwendigen Informationen dazu in den ML-Metadaten festgehalten werden.

Metadaten: Damit Nachvollziehbarkeit und Interpretierbarkeit von ML-Modellen dokumentiert werden können, muss eine durchgehende Kette, angefangen von den Trainings- und Testdaten, über die Parameter und Konfiguration der Lernalgorithmen bis hin zu den einsetzbaren Modellen existieren. Dies wird mit ML-Metadaten erreicht.

Was eine ML-Architektur können muss

Beim Devops- bzw MLOps-Ansatz wird Continuous Delivery immer mitgedacht. Im Fall von Machine Learning hat Continuous Delivery das Ziel, einen einheitlichen Tooling-Ansatz für den Lebenszyklus des maschinellen Lernens bereitzustellen. Besonderer Fokus liegt hierbei auf der automatisierten, skalierbaren Herstellung von KI-Modellen und deren Betrieb. In Data Science-Projekten liegen Auswahl und Anwendung geeigneter analytischer Methoden häufig im Kern der Betrachtung. Die meisten Data-Science-Projekte verfolgen das Ziel, durch ein Modell Entscheidungen oder Vorhersagen zu treffen, welche schließlich in die Wertschöpfungskette einfließen. Für eine ML-Architektur ergeben sich deshalb eine ganze Reihe von erforderlichen Fähigkeiten. Die wichtigsten sind:

  • Automatisierter Zufluss von computer-interpretierbarem Expertenwissen
    • Data Repository für Training Data
    • Erstellen und Verwalten der notwendigen Datenflüsse
  • Zusammenführung von Daten aus mehreren Quellen
    • Datenarchitektur erstellen
    • Datenintegration und -quellen
    • Dateneingabe
    • Datenversionierung
    • Datenerhebung
    • Datenüberwachung
  • Datenverarbeitung und Bereinigung
    • Die Werkzeuge und Technologien zur Datenverwaltung und Bereinigung auswählen
    • Die Datenabhängigkeiten analysieren und verwalten
    • Die Daten erforschen, transformieren, kombinieren und visualisieren
    • Die Daten für Computer Vision annotieren
  • Automatisierte Modelltrainings und Parametersuchen
    • Die Modelle erstellen und bereitstellen
    • Die Modelle aufbereiten und auswerten
    • Die Modelle vergleichen
  • Operationalisierung, Management und Monitoring von Modellen
    • Die Experimente beaufsichtigen und verfolgen
    • Die Ausführung protokolieren und auditieren
    • Die Infrastruktur automatisieren
    • Die Infrastruktur und Modelle überwachen
  • Anwendungsintegration
    • Die Schnittstellen umsetzen
    • Die Integrationstests durchführen

Fazit

ML-Lösungen müssen sorgfältig vorbereitet und von eigenen Teams betreut werden, damit sie produktiv eingesetzt werden können. Der Aufwand für ML entsteht nicht nur in der Entwicklung der ML-Modelle, vielmehr liegt er in der für den Betrieb nötigen Infrastruktur und der Bereitstellung der notwendigen Capabilities im Unternehmen. Diese reichen weit über die Technologie hinaus, berühren viele Prozesse und die Kultur des Unternehmens. Bevor Unternehmen den beträchtlichen Aufwand für ML-Lösungen betreiben, sollten sie sich fragen, wie groß ihr Bedarf an ML tatsächlich ist, bzw. welche ihrer Herausforderungen sich überhaupt mit ML lösen lassen.

Autoren

Dr. Ilir Fetai hat im Bereich verteilte Informationssysteme promoviert. Seine aktuellen Schwerpunkte liegen im Bereich Machine Learning, insbesondere bei der Operationalisierung von Machine Learning Systemen. Er ist Dozent an diversen Hochschulen. Bei der SBB leitet Ilir Fetai das Projekt «AI in der Streckeninspektion» und das Competence-Center «Machine Perception». Davor war er als Softwarearchitekt, Datenbankspezialist und Technologie Manager tätig.

Marek Imialek ist Shape Solution Architect im BSH Data und Analytics Cluster und Partner Architect für BSH Central Data Lake. Verantwortlich ist Imialek für die Konzeption und das Enabling von neuen BSH-Analytics-Lösungen auf Basis von Cloud-, Event-Streaming (Kafka)- und ML-Architekturen. Er arbeitet seit zwei Jahren bei BSH und vorher acht Jahre bei Bosch Mobility Solutions als Softwareentwickler und Architekt. Er studierte Informatik an der Universität Krakau.

Eric Liese arbeitet als leitender Architekt, Advisor und Mentor für die Schwerpunkte AI und Big Data bei der BSH, einem Tochterunternehmen von Bosch. Sein Hauptinteresse gilt der Unterstützung der kulturellen, organisatorischen und technologischen Transformation von traditionellen Unternehmen hin zu Data- und AI-Driven Companies. Er hat Mathematik und Informatik mit Schwerpunkt Künstliche Intelligenz an der Johannes Gutenberg-Universität in Mainz studiert.

Literatur

Alle News