MLOps für Forschungsteams

Viele Machine Learning Teams stehen oft vor ähnlichen Herausforderungen. Um diese zu bewältigen empfehlen wir allen Teams, mit MLOps zu arbeiten: einer Reihe von Arbeitsschritten und Komponenten, mit deren die Herausforderungen von Machine Learning Projekten leichter gemeistert werden können.

In diesem Artikel gehen wir die einzelnen im Punkte durch bei denen MLOps Forschern hilft besser mit Machine Learning umzugehen.

Warum benötigt dein Team MLOps?

Viele Machine Learning Teams konzentrieren sich auf die Entwicklung neuer Algorithmen oder auf das Training hochleistungsfähiger Modelle. Das sind zwar wichtige Bestandteile von Machine Learning-Lösungen; im Vergleich zu all den anderen Prozessen, die in einer Lösung benötigt werden - wie z. B. Data Engineering und Monitoring - nehmen sie jedoch nur einen relativ geringen Anteil ein.

Forschungsteams tendieren häufig dazu, sich vor allem auf den Machine Learning Code zu konzentrieren. Die Infrastruktur drumherum bleibt dabei oft außen vor. Da es jedoch immer wichtiger wird, mit anderen Teams zusammenzuarbeiten und Ergebnisse untereinander auszutauschen, stoßen Forschungsteams so schnell an ihre Grenzen. MLOps geht dieses Problem an und unterstützt Forschungsteams bei allen Schritten, die neben dem ML-Code wichtig sind. So können die gesetzten Ziele trotz der vielen Schwierigkeiten, die der Umgang mit großen Datensätzen, Code und Machine Learning-Modellen mit sich bringt, eingehalten werden.

Welche Herausforderungen entstehen ohne eine MLOps-Architektur?

Herausforderung #1: Modelle können nicht rekonstruiert werden

Dein Team hat ein Machine Learning Modell, das gut funktioniert, aber leider nicht rekonstruiert werden kann. Entweder haben sich Daten und Software-Versionen geändert, oder das Teammitglied, das die Trainings-Pipeline auf seinem Rechner eingerichtet hat, ist nun auf einem anderen Projekt. Dein Team kann in diesem Fall zwar die Modelldatei weiter nutzen, das Modell kann aber nicht mehr verbessert oder aktualisiert werden.

Herausforderung #2: Modelle können nicht effektiv geprüft oder überwacht werden

Die Ergebnisse des Modells deines Teams waren in der Evaluierungsphase hervorragend. Allerdings findet keine fortlaufende Prüfung oder Überwachung statt, um sicherzustellen, dass die Vorhersagen des Modells nach wie vor stimmen. Dein Team muss dem Modell also blind vertrauen, dass es wie erwartet funktioniert.

Herausforderung #3: Modelle können nicht einfach weitergegeben werden

Jedes Teammitglied hat seine eigene Pipeline erstellt, um Daten zu verwalten und Modelle zu trainieren. Da man nicht einfach mit den Modellen der anderen arbeiten oder vorhandene Zwischenergebnisse wiederverwenden kann, ist es schwierig, Ergebnisse gemeinsam zu nutzen.

Herausforderung #4: Das Proof-of-Concept wirkte vielversprechend, aber das Training lässt die Hardware abstürzen

Du konntest dein Modell auf einem kleinen Datensatz auf deinem Laptop trainieren; um es zu skalieren müsstest du es jedoch entweder auf einen leistungsfähigeren Rechner auslagern oder Rechencluster verwenden. 

Die Umsetzung des Proof-of-Concept in eine Produktionslösung ist daher nun mit erheblichem Aufwand verbunden.

Herausforderung #5: Fehler werden zu spät entdeckt.

Da dein Team die Infrastruktur und den Glue-Code für jedes Projekt komplett neu aufbaut, entstehen viele Bugs und andere Probleme, die oft erst nach der Veröffentlichung der Ergebnisse entdeckt werden. Bei jedem neuen Projekt treten dieselben Probleme wieder auf, weil man den Code nicht einfach wiederverwenden kann.

Wie kann eine MLOps-Architektur diese Herausforderungen lösen?

Die Implementierung von MLOps-Praktiken und eine standardisierte Architektur helfen, all diese Herausforderungen zu überwinden. Die meisten Machine Learning Teams sollten über eine Architektur verfügen, die Folgendes umfasst:

Experimentier-Hub

In einem Experimentier-Hub können Forscher Jupyter Notebooks nutzen, mit neuen Modellen und Architekturen experimentieren und Hypothesen validieren. Der Experimentier-Hub hilft den Teammitgliedern, Code zu teilen und gewährleistet, dass jeder die Modelle der anderen reproduzieren kann. 

Da alle in der gleichen Umgebung arbeiten, müssen alle Einstellungen nur einmal vorgenommen werden. Der gemeinsame Hub verhindert Schwierigkeiten hardware-spezifischer Probleme, z. B. wenn Teammitglieder unterschiedliche Betriebssysteme verwenden oder ihre Rechner nicht leistungsstark genug sind.

Wir nutzen dafür JupyterHub.

Modellregister und Experiment-Tracker

In einem Modellregister wird jedes vom Team entwickelte Modell mit einem Namen und einer oder mehrerer Versionen gespeichert. Ein Experiment-Tracker funktioniert ähnlich, arbeitet aber noch etwas detaillierter: hier werden Name, Version und Metadaten für alle Experimente definiert.

Indem jedes einzelne Modell und Experiment, das vom Team entwickelt wird, gespeichert und versioniert wird, können die Ergebnisse eines bestimmten Experiments jederzeit reproduziert werden. 

Außerdem hilft ein Modellregister bzw. Experiment-Tracker auch dabei, rechtliche Anforderungen einzuhalten, da es den gesamten Entwicklungsprozess transparent und nachvollziehbar macht.

Wir nutzen dafür MLFlow.

Model Serving Tool

Ein Model Serving Tool stellt ein Modell automatisch in Staging- oder Produktionsumgebungen bereit und stellt eine einheitliche API für das Team und die Endnutzer zur Verfügung.

Mit einer einheitlichen API und Infrastruktur wird es wesentlich einfacher, alle Modelle zu verwenden und zu überwachen. Die automatische Bereitstellung der Modelle in Staging- und Produktionsumgebungen bedeutet, dass die aktuellsten Version eines Modells sofort eingesetzt werden kann.

Wir nutzen dafür Seldon.

Dataflow Tool

Ein Dataflow Tool verfolgt jeden Arbeitsschritt in einer Pipeline und kann bei Bedarf die jeweiligen Schritte erneut ausführen. So lässt sich vermeiden, dass ein Modell nicht neu entwickelt werden kann, da alle Schritte nachvollzogen werden können.

Außerdem spart es Zeit und beugt Fehlern vor.

Wir nutzen dafür Prefect.

Feature Store

Manchmal benötigt man die genauen Features, die zum Trainieren eines bestimmten Modells verwendet wurden, aber die zugrundeliegenden Daten haben sich zwischenzeitlich geändert. Ein Feature Store speichert Versionen jedes Features, damit man die entsprechende Version jederzeit wiederverwenden kann. 

Wir nutzen dafür FEAST.

Ist MLOps unverzichtbar oder eher "nice-to-have"?

Auch wenn manche Forschungsteams noch immer ohne MLOps-Tools oder Best Practices arbeiten, sind wir der Ansicht, dass MLOps ein wesentlicher Bestandteil für beinahe alle Teams geworden ist. Abgesehen von sehr kleinen Teams, die an eher trivialen Problemen arbeiten, müssen alle Machine Learning Forschungsprojekte reproduzierbar, verlässlich, kollaborativ und kontinuierlich sein. Ohne MLOps können diese Ziele kaum erfüllt werden.

Brauchst du Unterstützung bei der Einrichtung von MLOps in deinem Forschungsteam?

Wir finden gerne die richtige MLOps-Architektur für unterschiedliche Machine Learning Forschungsteams. Melde dich dafür einfach bei uns.