Sobald ein Machine Learning Team vielversprechende Ergebnisse erhält, passiert oft folgendes: Sie nahmen das Modell live, beobachten zwei Wochen lang, ob es funktioniert, und wenden sich dann dem nächsten Projekt zu.
Machine Learning Modelle interagieren jedoch meistens mit realen Ereignissen und je mehr sich diese verändern, desto schlechter passt das Modell zur Realität. Das bedeutet, die Genauigkeit der Modelle lässt unter Umständen mit der Zeit nach, was wiederum ohne automatisierte Überwachung lange unentdeckt bleiben kann.
Wenn dieses sogenannte Model Decay dann doch irgendwann auffällt, wird das Modell erneut überarbeitet und ein paar Wochen lang manuell überwacht, bis sich das Team wieder anderen Projekten widmet.
Mit dieser Vorgehensweise können unter Umständen schwerwiegende Fehler entstehen.
In diesem Artikel geht es daher darum, wie dein Team automatisch und rechtzeitig Model Decay erkennen und mit Hilfe von MLOps Modelle automatisch aktuell halten kann.
So funktioniert automatisierte Überwachung
Der erste Schritt besteht darin, Fehler zu erkennen. So können viele Probleme von vornherein vermeiden werden. Selbst wenn man dafür Modelle erst einmal von Hand erneut trainieren und bereitstellen muss.
Theoretisch ist das einfach. Man richtet ein Überwachungs-System ein, das einen Alarm auslöst, sobald die Genauigkeit des Systems unter einen bestimmten Wert fällt.
Praktisch ist das Ganze allerdings etwas schwieriger. Im Modell-Training hat man vielleicht einen manuell annotierten "goldenen" Datensatz; in der Praxis ist jedoch nicht sofort erkennbar, ob das Modell etwas falsch macht: Wenn das so einfach zu erkennen wäre, wäre das Modell selbst ja überflüssig.
Drei Strategien zur Modellüberwachung
Es gibt drei Möglichkeiten, um die Genauigkeit eines Modells zu berechnen:
- Überwachung über einen Proxy. Wenn ein Spam-Klassifikator beispielsweise normalerweise 30% aller Nachrichten als Spam einstuft, plötzlich jedoch 75% der Nachrichten aussortiert, dann gibt es vermutlich einen Fehler im Modell.
- Manuelle Stichproben. Ein Mensch könnte z.B. 5% der Vorhersagen des Modells manuell verifizieren und daraus eine Genauigkeitsmetrik ableiten, und die Entwicklung dieser Metri über die Zeit überwachen.
- Retrospektive Überwachung. Wenn man beispielsweise vorhersagt, ob ein bestimmtes Medikament einem Patienten helfen wird, kann man im Nachhinein die Genauigkeit der Prognose prüfen.
Sobald eine Metrik zur Qualitätskontrolle definiert ist, benötigt man ein Tool, um diese Metrik zu überwachen. Dafür kann entweder ein spezialisiertes Machine Learning Überwachungstool oder ein generisches Überwachungstool wie DataDog eingesetzt werden. Ein spezialisiertes Tool macht es einfacher, weitere nützliche Metriken für Machine Learning-Szenarien zu erhalten, wie z. B. die Fehlerverteilung oder den mittleren absoluten Fehler. Für einfachere Anwendungsfälle sollte jedoch auch ein generisches Tool ausreichen.
Modelle automatisch neu trainieren und einsetzen
Es ist wichtig, zu erkennen, sobald die Qualität eines Modells abnimmt. Genauso wichtig ist es jedoch, darauf dann auch entsprechend zu reagieren. Eine Option besteht darin, das Modell neu zu trainieren und zu deployen. Wenn dieser Schritt jedoch manuell durchgeführt werden muss, ist das Team ständig "auf Abruf" und muss bereit sein, sobald Alarm geschlagen wird. Außerdem ist solch ein manueller Eingriff sehr aufwändig und fehleranfällig, besonders wenn er häufig wiederholt wird.
Mit einer vollständigen MLOps Architektur sollte alles vorhanden sein, um den Prozess komplett automatisch durchzuführen, das heißt das Modell erneut zu trainieren und zu deployen - entweder in einem regelmäßigen Rhythmus oder sobald es Hinweise auf Model Decay gibt.
In der Softwareentwicklung ist ein CI/CD- oder "Continuous Integration/Continuous Deployment"-Ablauf üblich. Neuer Code sollte automatisch in bestehenden Code integriert, getestet und bereitgestellt werden können.
MLOps verfolgt ein ähnliches Ziel, allerdings ist das Training der Modelle ein eigener, wichtiger Schritt. Daher braucht man für Machine Learning Pipelines CT/CI/CD, oder "continuous training/continuous integration/continuous deployment".
Eine CT/CI/CD-Pipeline ist kein kleines Investment. Unserer Erfahrung nach erledigen die meisten Teams viele Aufgaben jedoch zu lange manuell.
Die Tools, die bei Model Decay helfen
Es gibt viele MLOps-Tooling-Optionen, aber das hier sind die Tools, die wir verwenden:
- Prefect als Workflow- und Dataflow-Tool. Damit können wir eine Reihe von auszuführenden Aufgaben definieren und diese dann automatisch ausführen, überwachen und bei Bedarf erneut ausführen lassen. Damit lässt sich sowohl Model Decay überwachen als auch automatisch ein neues Modell trainieren. Hier kannst du mehr darüber erfahren, was wir an Prefect schätzen.
- Feast als Feature Store. Mit Feast tracken wir Datenänderungen und stellen Features bereit für verschiedene Modelle. In unserem Artikel “Der richtige Feature Store für dein Projekt” erfährst du mehr über den Einsatz von Feature Stores.
- Seldon um Modelle bereitzustellen. Mit Seldon können wir jedes Modell ganz einfach in eine API umwandeln und skalierbar bereitstellen, ohne es neu programmieren zu müssen.
Brauchst du Hilfe bei der Einrichtung von MLOps für dein Forschungsteam?
Was viele Teams zögern lässt, in eine richtige Architektur zu investieren, ist die Vielzahl der Unbekannten: Es ist oft unklar, wie lange die Umstellung dauern wird oder wie man anfangen sollen. Wir haben den kompletten Prozess bereits hinter uns und helfen anderen Teams gerne bei ihrer Umstellung. Setze dich daher bei Interesse gerne direkt mit uns in Verbindung.
