Data-Science-Plattformen skalieren: Teil 2

Gastbeitrag von Laurenz Wuttke, Gründer und Geschäftsführer von datasolut GmbH

Data Science zu skalieren hat für Unternehmen viele Vorteile. In diesem Beitrag fasst Laurenz Wuttke, Gründer von datasolut GmbH und Autor von „Praxisleitfaden für Künstliche Intelligenz in Marketing und Vertrieb“ seine Lessons Learned aus unzähligen Data-Science-Projekten zusammen:

Data Science in Silos zu betreiben ist keine gute Idee: Wenn alle Data Scientists ihren eigenen Prozess bauen und sich abkapseln, wird das maschinelle Lernen schnell unübersichtlich, fehleranfällig und ineffizient. Ein ordentliches Scoring und ein durchdachter Deployment-Prozess sind nicht möglich. Man ist von einzelnen Personen abhängig und kann kaum eingreifen, wenn etwas schiefgehen sollte. Data Science soll letztendlich operative Prozesse verbessern, es also ermöglichen, Live-Daten aus den Machine-Learning-Modellen in die Anwendung zu geben und auf der Basis Entscheidungen zu treffen.

Aber abgekapselte Prozesse führen nicht zu wirklich zufriedenstellenden Ergebnissen. Stattdessen ist es wichtig, dass die Data Scientists auf einer Plattform zusammenarbeiten und sich austauschen können. Daher empfehle ich, dass sich Unternehmen im Aufbau einer Data Science-Einheit breiter aufstellen und zwar Kompetenzzentren bilden, aber infrastrukturmäßig sehr nah aneinander bleiben.

Noch effizienter wird der gesamte Prozess mit einer zentralen Datenaufbereitung. Sie macht den Großteil der Arbeit aus: Data Scientists können bis zu 80 % ihrer Zeit damit verbringen, Daten aufzubereiten und Features zu generieren. Wenn man diese Prozesse, Datenstrukturen und Datenbanken in einem Machine Learning Feature Store zentralisiert und gegebenenfalls sogar automatisiert, trägt das nicht nur zur Qualitätssicherung bei, sondern steigert auch die Kosteneffizienz.

So lassen sich Tausende von Features für die ganze Organisation bauen und unterschiedlichste Anwendungsfälle auf dieser zentrale Datenbasis aufbauen. Der initiale Aufwand ist zwar hoch, lohnt sich aber, je mehr Features man in so einem Feature Store hat. Es ist ein sehr praktisches und wertvolles Tool und Konzept, was in der Data Science meiner Meinung nach viel zu selten eingesetzt wird.

Vor allem in Kombination mit einem guten Feature Store bieten sich auch AutoML-Anwendungen an, mit denen sich Machine Learning automatisieren lässt. Das gilt vor allem in den Bereichen Algorithmusselektion, Hyperparameter Tuning, Model Stacking und auch teilweise beim Feature Engineering. Es gibt bereits zahlreiche Cloud-Anbieter, die AutoML-Funktionalitäten heute schon anbieten, zu Beispiel Google, Amazon und Microsoft.

In der Data Science geht es um 5 % Machine Learning Code – und um sehr viel Code für Teilprozesse und Infrastruktur, Monitoring, Serving und Prozessautomatisierung, den Data Scientists managen und tracken müssen. Dementsprechend sollten Data-Science-Projekte aus meiner Sicht eher als Softwareprojekte gedacht und behandelt werden. Auch der Lifecycle ist ähnlich und grundsätzlich ist auch der Prozess vergleichbar, auch wenn der bei Machine Learning noch etwas komplexer ist als bei der Softwareentwicklung. Letztendlich ähnelt Machine Learning dem Debugging, weil man sehr viel experimentieren muss.

Weil Machine Learning so komplex ist, macht es meiner Meinung durchaus Sinn, sich im Softwarebereich zu bedienen, wenn es darum geht, den Prozess zu tracken. Es gibt mittlerweile einige Tools am Markt sowie Methoden, mit denen sich diese Machine-Learning-Experimente in Form von Modellen inklusive der Parameter und Daten tracken und historisieren lassen. So kann man dann den ganzen Lifecycle von Machine Learning abzubilden und ein zentrales Modell-Repository anzulegen, das den aktuellen Status aller Modelle sowie ihre Versionsgeschichte abbildet.

Das wichtigste Learning für mich ist, dass die Cloud den ganzen Prozess enorm unterstützt und vereinfacht. Zur Wahrheit gehört nämlich auch, dass man selbst es sehr schwer haben würde, sich die Infrastruktur, die man für solche Data Science Plattformen braucht, on premise aufzubauen – da braucht man ein sehr gut aufgestelltes Infrastruktur-Team und trotzdem kann es sehr lange dauern. Schneller und effizienter ist es, auf die zahlreichen Cloud-Anbieter auszuweichen.