KI, Daten und Infrastruktur – ML-Systeme schnell Ende-zu-Ende verproben und umsetzen

Heutzutage steht fast alles, was mit den Labels „künstliche Intelligenz (KI)“ oder „Machine Learning (ML)“ versehen ist, für Fortschritt. Seltsamerweise schließt diese Assoziation jedoch häufig die Themen Daten und Dateninfrastruktur nicht ausreichend mit ein, und das, obwohl ML-Systeme typischerweise in hohem Maße von einer geeigneten Dateninfrastruktur abhängig sind. Um tatsächlich Mehrwert mit einem ML-System zu erzeugen, sind insbesondere (automatisierte) Daten-Pipelines erforderlich, die das System solide in die IT-Landschaft integrieren.

Hinweis: Dieser Artikel erschien ursprünglich im Softwerker-Magazin Vol. 16. Das gesamte Heft kann hier als PDF heruntergeladen werden .

Eine Wahrheit über Data-Science-Projekte

Betrachten wir die folgende Situation: Ein Data-Science-Projekt startet mit einem Proof of Concept (PoC) und einem versierten Projektteam, das direkt anfängt, in schnellen Iterationen Erkenntnisse zu liefern. Nach Ablauf der Timebox des PoC ist es tatsächlich gelungen, vielversprechende Ergebnisse zu erzielen. So gibt es die Gelegenheit, diese Ergebnisse vor „wichtigen Entscheidungsträger*innen“ zu präsentieren. Nachdem das Projektteam die Präsentation mit Bravour gemeistert hat, wird immer deutlicher: Die Idee ist ein Volltreffer! Alle fühlen sich großartig.

Unter der Haube wurden die vielversprechenden Data-Science-Ergebnisse jedoch auf einem lokalen Rechner mit Daten-Dumps (CSV-Dateien oder Excel-Tabellen) aus mehreren Datenquellen erzielt. Die Daten-Dumps wurden vorab von einer SQL-Expertin mit einer speziellen Abfolge magischer SQL Queries sorgfältig von Hand erzeugt. Dieses Vorgehen ist oft richtig, und es ist sehr sinnvoll, zunächst mit Daten-Dumps zu arbeiten, um schnell Erkenntnisse zu erlangen. Das beschriebene Vorgehen ist aber auch zweifellos eine Abkürzung.

Die Abkürzung wird dann zum Problem, wenn sie nicht transparent ist. Noch schlimmer, wenn sie nicht so kommuniziert ist, dass der zugrunde liegende Trade-off von „den Entscheidungsträger*innen“ verstanden wurde. Denn der Trade-off für die schnellen Einsichten und Ergebnisse während des PoC besteht in der Regel darin, weder die zugrunde liegende Dateninfrastruktur noch den Aufbau geeigneter Daten-Pipelines während des PoC anzugehen. Spätestens nachdem nun alle die erfolgreiche Präsentation gesehen haben und jetzt sofort einen Mehrwert innerhalb weniger Tage erwarten, müssen wir der Wahrheit ins Auge sehen: Wir haben eine Abkürzung genommen. Bevor wir tatsächlich Mehrwert generieren können, müssen wir noch einiges nachlegen.

Eine schwere Bürde für Data-Science-Projekte

Da es, wie in unserer fiktiven Geschichte skizziert, möglich ist, kurzfristige, aber sichtbare Erfolge zu erzielen, treibt der KI-Hype Unternehmen oft dazu, eine Reihe von Data-Science-Projekte zu starten. Jedoch wird häufig nicht zeitgleich ein Bewusstsein dafür geschaffen, welche Implikationen der (gewünschte) Produktiveinsatz eines ML-Systems für die Dateninfrastruktur hat. Klar ist: Um Ideen zu validieren, müssen die potentiell bestehenden Unzulänglichkeiten der Infrastruktur nicht alle zuerst gelöst werden. Ein Problem entsteht aber regelmäßig dann, wenn sich nicht alle Beteiligten darüber im Klaren sind, dass die Entwicklung eines Ende-zu-Ende-Prototyps oder gar eines produktionstauglichen ML-Systems – je nach vorhandener Dateninfrastruktur – ein sehr anspruchsvoller nächster Schritt nach einem PoC sein kann.

Im schlimmsten Fall führt dies zu der bizarren Situation, dass ein Data-Science-Projektteam nach dem PoC vor der Aufgabe steht, die unternehmensweiten Herausforderungen in Sachen Daten und Dateninfrastruktur ganz nebenbei mit zu lösen. Bei dem (verzweifelten) Versuch, Mehrwert zu schaffen, sieht sich das Projektteam dabei mit unlösbaren Aufgaben konfrontiert und es gibt wenig oder gar kein Verständnis für die Schwierigkeiten des Teams bei den Stakeholdern und damit häufig auch keine Unterstützung. Dies führt regelmäßig zu Frustration beim Projektteam und letztlich zum Scheitern der einst so vielversprechenden Idee, da kein Mehrwert in der erwarteten Zeit erzeugt werden konnte.

Im übertragenen Sinne versucht das Team, einen Sportwagen (das State-of-the-Art-KI-Modell) auf einem Waldweg (der Dateninfrastruktur) zu fahren und alle Außenstehenden fragen sich, warum das Team nicht einfach in voller Geschwindigkeit fährt. So entsteht häufig der Eindruck, dass es einfach nicht möglich ist, mit Data-Science-Projekten tatsächlich einen Mehrwert zu generieren.

Daten – eine Frage der Einstellung

Historisch gesehen ist der Aufbau einer neuen Dateninfrastruktur mit großen Schmerzen für Unternehmen verbunden. Dies liegt daran, dass sie typischerweise mit enormen Investitionen von Zeit und Geld (und Nerven) verbunden ist. Darüber hinaus gibt es verschiedene Architekturen, z. B. Data Lakes (siehe hier und hier ), Data Lakehouses , Data Meshes und natürlich das klassische Data Warehouse mit jeweils unterschiedlichen Vorteilen und Kompromissen, die es zu berücksichtigen gilt.

Den eigentlichen Kern und damit das Fundament zur Realisierung der durch eine der Architekturen in Aussicht gestellten Verbesserung sind jedoch ausdrücklich nicht die technischen Feinheiten. Denn im Kern geht es um die Frage, welchen Stellenwert Daten im Unternehmen haben und insbesondere darum, den Umgang und die Bedeutung mit und von Daten im Unternehmen zu verändern. Dieser Wandel ist wahrscheinlich der wichtigste Schritt bei der Umsetzung der Architekturen und damit entscheidend dabei, mit Data-Science-Projekten dauerhaft Mehrwert zu generieren.
Die Erkenntnis, dass die Etablierung einer geeigneten „Data Culture“ im Unternehmen den zentralen Schritt in Richtung Mehrwert mit ML-Systemen darstellt, ist zwar nicht neu, aber nach unserer Beobachtung noch nicht ausreichend in der Breite adaptiert.
Dabei gibt es jedoch (mindestens) zwei Gründe, die für ein Umdenken beim Thema Daten sprechen.

1. Schnellere Zykluszeit für die Validierung von Ideen

Es liegt auf der Hand, dass ein PoC (wie oben beschrieben) schnell erste Erkenntnisse darüber liefert, ob eine Idee vielversprechend ist oder nicht. Ohne eine geeignete Dateninfrastruktur ist es jedoch in der Regel schwierig und kostspielig, eine Idee anschließend auch mittels eines Ende-zu-Ende-Prototyps zu validieren.

Dies führt in der Regel zu langwierigen Diskussionen darüber, ob und wann mit der Validierung welcher Idee begonnen werden soll, ohne in dieser Zeit tatsächlich wertvolle Erkenntnisse über die Ideen selbst zu gewinnen. Dabei ermöglicht es eine geeignete Dateninfrastruktur insbesondere durch schnelle Ende-zu-Ende-Validierung und Experimente, Ideen schneller zu verwerfen. So muss über diese Ideen nicht ständig neu diskutiert werden und der Fokus kann leichter auf potentiell erfolgreiche Ideen gelegt werden. Die grundsätzliche Fähigkeit, Ideen mit schnellen Ende-zu-Ende-Prototypen und Experimenten zu validieren, ist insbesondere für die Entwicklung erfolgreicher ML-Systeme wichtig, da diese typischerweise aus vielen beweglichen Teilen bestehen und sich das System häufig über mehrere Teile des Unternehmens erstreckt.

Für ein Ende-zu-Ende-System müssen (Roh-)Daten geeignet aufbereitet werden, ein passendes ML-Modell entwickelt, trainiert und deployt werden und schließlich die durch das Modell generierten Erkenntnisse genau dort in einer brauchbaren Form zur Verfügung gestellt werden, wo diese schließlich einen Mehrwert liefern können. Darüber hinaus gilt es, noch weitere Herausforderungen wie Monitoring, Versionierung und Validierung mitzudenken.

2. Der eigentliche Wert ist die Fähigkeit, ML-Algorithmen produktiv einzusetzen

Typischerweise gibt es in Unternehmen eine Fülle von Ideen, wie Data Science und Machine Learning genutzt werden könnten, um Mehrwert zu erzeugen. Meistens sind auch bekannte ML-Algorithmen vorhanden, die bereits von anderen erfolgreich verwendet werden, um die gleiche oder eine ähnliche Idee umzusetzen. Es gibt daher oft berechtigten Grund zu der Annahme, dass dieser bekannte Algorithmus mindestens gut genug für eine erste Ver- sion des gewünschten ML-Systems ist.

Tatsächlich sind viele State-of-the-Art-Algorithmen und ML-Modelle heutzutage frei verfügbar:

• XGBoost, ein effizientes, flexibles und portables Gradient- Boosting-Framework, welches das Rückgrat für zahlreiche erfolgreiche ML-Systeme bildet.
• ResNet, ein KI-Modell für moderne Bildklassifikation, ist in verschiedenen Open-Source-Frameworks wie Tensorflow und PyTorch implementiert und direkt einsatzbereit.
• BERT, ein KI-Modell für Natural Language Processing, ebenfalls Open Source und in PyTorch and TensorFlow frei verfügbar.
• Darüber hinaus stehen viele Algorithmen und Modelle auch „as a service“ bei Public-Cloud-Anbietern zur Verfügung und können dort direkt eingesetzt und oft sogar auf eigenen Daten feinjustiert werden.

Zur Umsetzung der vorhandenen Ideen fehlt daher häufig nicht das Wissen über einen geeigneten Algorithmus, sondern es fehlt die Verfügbarkeit von Daten und insbesondere die Fähigkeit, den Algorithmus schmerzlos als ML-System Ende-zu-Ende in die Unternehmensinfrastruktur zu integrieren. Diese Punkte entscheiden am Ende daher regelmäßig darüber, ob mit einer Idee ein Mehrwert erzeugt werden kann – und nicht, ob ein passender Algorithmus gefunden wurde.

Daten neu denken

Wie schon erwähnt, ist das Überdenken von Daten und Dateninfrastruktur kein (rein) technisches Problem und beginnt typischerweise mit den Fragen:

• Welche Daten sind verfügbar?
• Welche Qualität haben die Daten?
• Wem gehören die Daten?
• Wer kontrolliert den Zugriff auf die Daten?
• Wer ist für die Daten und ihre Qualität verantwortlich?
• Wie ist die Beziehung zwischen Datenproduzenten und Datenkonsumenten?
• Wie kann diese (entscheidende) Beziehung verbessert werden?

Ein Hauptantrieb für die Beantwortung dieser Fragen besteht darin, Wege zu finden, um die gesamte End-to-End-Zykluszeit zur Entwicklung von ML-Systemen zu reduzieren – indem beispielsweise die Verfügbarkeit, die Verarbeitungsgeschwindigkeit und die Qualität der Daten sukzessive verbessert werden.

In den meisten Fällen empfehlen wir, ausdrücklich nicht zu versuchen, alle Infrastrukturprobleme im Voraus zu lösen und danach mit Data-Science-Projekten zu starten. Im Gegenteil: Viele Schwierigkeiten werden erst offenbar, sobald die ersten ML-Systeme entwickelt werden, und sind vorab unbekannt. Daher ist es ist meist unmöglich, geeignete Lösungen für diese Schwierigkeiten zu finden, ohne konkrete Anwendungen zu implementieren und dabei zu lernen.

Letztlich gilt es, das Thema Daten in großem Maßstab zu überdenken, aber von Use Case zu Use Case im Kleinen umzusetzen. Dies ermöglicht zum einen die Validierung verschiedener technischer Ansätze. Zum anderen (und das ist wahrscheinlich wichtiger) erlaubt es uns, unsere Denkweise über die Bedeutung von Daten Schritt für Schritt zu ändern. In diesem Stadium bietet die Nutzung einer Cloud-Infrastruktur eine gute Möglichkeit, schnell und ohne große Vorlaufzeit und Anfangsinvestition zu arbeiten. Der Schwerpunkt liegt hier zunächst auf der Ende-zu-Ende-Umsetzung von Use Cases und insbesondere auf der Entwicklung produktionstauglicher ML-Systeme. Sobald tatsächlich mehrere Use Cases umgesetzt sind und einen Mehrwert schaffen, kann eine Vereinheitlichung der zugrunde liegenden Dateninfrastruktur möglicherweise einen zusätzlichen Mehrwert bieten.

Data-Science-Projekte neu denken

Data-Science-Projekte werden häufig mit einem Team aus Data Scientists gestartet. Während das auf den ersten Blick sinnvoll erscheint, verbergen sich in der Praxis hinter dem Begriff Data Scientist oft die unterschiedlichsten Skill Sets. Regelmäßig führt dies dazu, dass im Projektteam die Schwerpunkte der Fähigkeiten auf der Erstellung von ML-Modellen und deren Optimierung liegen, während die Themen Softwareentwicklung, Data Engineering und Produktentwicklung nur schwach vertreten sind.

In diesem Fall ist es häufig nicht zu erwarten, dass das Projektteam die verschiedenen Trade-offs, die im PoC eingegangen wurden und insbesondere deren Implikationen auf die Weiterentwicklung der Idee – etwa in Richtung eines Ende-zu-Ende Prototyps – transparent in Richtung „der Entscheidungsträger*innen“ kommunizieren kann. Zudem stellt die eigentliche Entwicklung eines solchen Prototyps das Team in vielen Fällen vor eine schwer lösbare Aufgabe, und es ist oft schlicht nicht zu erwarten, dass so ein schlanker Prototyp entsteht, der später schmerzlos iterativ angepasst werden kann.

Fehlt ausreichend Expertise für Produktentwicklung im Team, gelingt es in vielen Fällen zudem nicht, eine belastbare Produktvision für die Data-Science-Idee zu erarbeiten. Oft führt dies dazu, dass in Präsentationen vor „den Entscheidungsträger*innen“ der Fokus auf dem ML-Modell und den generellen Modell-Metriken liegt, wohingegen die Fragen „Was muss alles passieren, dass Geld verdient werden kann?“ und „Wie genau führen die Erkenntnisse des Modells nun eigentlich zu Mehrwert?“ zu stark in den Hintergrund rücken.

Wir empfehlen daher, Data-Science-Projekte in der Regel ausdrücklich nicht mit einem PoC und der Frage „Wie gut ist es möglich, mit KI XYZ zu erreichen?“ zu starten, sondern sich von Anfang an die Frage „Was ist notwendig, um mit der Idee XYZ einen Mehrwert zu generieren?“ zu stellen. Bei der Beantwortung spielt das KI-Modell natürlich eine Rolle, ist aber dann nur ein Faktor neben allen anderen Herausforderungen, die gemeistert werden müssen, um Mehrwert zu generieren. Entscheidend ist es dabei, das Team so aufzustellen, dass alle notwendigen Fähigkeiten vorhanden sind, um die ursprüngliche Idee wirklich Ende-zu-Ende validieren zu können. Ein Modell alleine ist hierfür in vielen Fällen nicht ausreichend.

Zusammenfassung

Während alle über KI sprechen, braucht es am Ende viel mehr als Data Science und ML-Algorithmen, um produktionstaugliche ML-Systeme zu entwickeln und Mehrwert zu schaffen. Insbesondere setzt nachhaltiger Erfolg mit ML-Systemen und KI mehr voraus als clevere Algorithmen – er erfordert eine Änderung der Einstellung zum Thema Daten, Dateninfrastruktur und einen ganzheitlichen Blick auf die mögliche Wertschöpfungskette des ML-Systems. Der wahre Wert für Unternehmen im Kontext von ML-Systemen liegt am Ende meistens nicht im Algorithmus, sondern in den zugrunde liegenden Daten und der Fähigkeit, diese Algorithmen schnell in Form eines ML-Systems auf der Dateninfrastruktur umzusetzen.

Ein Big-Bang-Ansatz, um die Dateninfrastruktur zu ändern oder damit zu beginnen, alle verfügbaren Daten an einem einzigen Ort zusammenzufassen, ist oft ein unnötig schwieriges Unterfangen. Meistens ist es erfolgversprechender, das Thema Daten erst einmal zu überdenken – von Use Case zu Use Case – und unterwegs Schritt für Schritt eine geeignete Dateninfrastruktur aufzubauen und insbesondere eine neue Datenkultur zu schaffen.