Machine Learning Operations (MLOps)

Der Betrieb von Systemen für maschinelles Lernen (MLOps) umfasst die Verfahren und Werkzeuge, mit denen Modelle des maschinellen Lernens (ML) zuverlässig und reproduzierbar entwickelt, bereitgestellt und in der Produktion gewartet werden. MLOps erweitert DevOps, das das Testen und Veröffentlichen von Software automatisiert, auf Systeme, deren Verhalten sowohl von Daten als auch von Code abhängt: Ein Modell kann sich verschlechtern, ohne dass eine einzige Zeile geändert wird, weil sich die beobachtete Welt verändert hat. Das Modell selbst ist nur ein kleiner Teil eines solchen Systems. Googles Leitfaden zur MLOps-Architektur weist darauf hin, dass ML-Code nur einen kleinen Teil eines realen ML-Systems ausmacht. Der Rest besteht aus Datenerfassung und -prüfung, Bereitstellungsinfrastruktur und Überwachung. Die NeurIPS-Arbeit Versteckte technische Schulden in Systemen des maschinellen Lernens beschrieb die langfristigen Wartungskosten, die dieses umgebende System verursacht.

Zentrale Praktiken#

MLOps verbindet Data Engineering, Modellentwicklung und Betrieb durch einige wenige Verfahren. Jedes davon wird sowohl auf die Trainingsdaten als auch auf den Code angewendet:

• Datenversionierung: Jeder Datenbestand erhält eine unveränderliche Version. So lässt sich jedes Modell genau den Daten zuordnen, mit denen es erstellt wurde.
• Experimentverfolgung: Jeder Trainingslauf protokolliert die Codeversion, Datenversion, Hyperparameter, Kennzahlen und Artefakte, damit Ergebnisse verglichen und reproduziert werden können.
• Kontinuierliche Integration und Bereitstellung: Automatisierte Pipelines testen den Code, prüfen eingehende Daten, trainieren Modelle erneut und blockieren jeden Kandidaten, der eine Qualitätsprüfung nicht besteht.
• Modellregister: Freigegebene Modellversionen werden zusammen mit ihren Metadaten, ihrer Herkunft und ihrem Status gespeichert, etwa Staging oder Produktion. So beziehen sich Bereitstellungen und Rollbacks auf genau festgelegte Versionen.
• Modellbereitstellung: Modelle werden häufig in Containern verpackt und über APIs bereitgestellt oder auf Edge-Geräten eingesetzt.
• Modellüberwachung: Eingaben, Vorhersagen, Latenz und Genauigkeit in der Produktion werden erfasst, um Drift zu erkennen und über ein erneutes Training zu entscheiden.

Der Google-Leitfaden beschreibt den Reifegrad in drei Stufen. Auf Stufe 0 trainieren Data Scientists Modelle manuell und übergeben sie anschließend. Stufe 1 automatisiert die Trainingspipeline selbst und ergänzt kontinuierliches Training (CT): Modelle werden automatisch neu trainiert und bereitgestellt, wenn neue Daten eintreffen oder Datenverschiebungen erkannt werden. Stufe 2 automatisiert außerdem das Erstellen, Testen und Bereitstellen des Pipeline-Codes mit CI/CD, sodass neue Pipeline-Versionen ebenso sicher wie neue Modelle in der Produktion landen. Zusammen bilden diese Praktiken einen Kreislauf:

MLOps in der Praxis#

• Qualitätsprüfung in der Fertigung: Wenn ein Werk eine Produktlinie ergänzt, werden neue Fehlerbilder beschriftet und versioniert. Eine Pipeline trainiert das Erkennungsmodell erneut, und die freigegebene Version wird ohne Ausfallzeit auf die Edge-Kameras jeder Produktionslinie ausgerollt.
• Überwachung von Ladenregalen: Änderungen am Verpackungsdesign und an der Ladenbeleuchtung verändern das Kamerabild. Die Überwachung meldet sinkende Konfidenzwerte, Bilder mit niedrigen Konfidenzwerten werden annotiert, und das erneut trainierte Modell wird in den Filialen eingesetzt, sobald es die Evaluierung besteht.

Eine Qualitätsprüfung automatisiert die Entscheidung über die Freigabe. Das folgende Skript trainiert ein Kandidatenmodell zur Objekterkennung, bewertet es und das aktuelle Produktionsmodell mit denselben Validierungsdaten und exportiert den Kandidaten nur dann nach ONNX, wenn sein mAP_50-95 höher ist:

from ultralytics import YOLO

# Kandidatenmodell trainieren; der Lauf speichert seine Gewichte, args.yaml und results.csv unter project/name
candidate = YOLO("yolo26n.pt")
candidate.train(data="coco8.yaml", epochs=10, project="mlops", name="candidate")

# Qualitätsprüfung: Kandidatenmodell und Produktionsmodell mit denselben Validierungsdaten bewerten
candidate_map = candidate.val(data="coco8.yaml").box.map
production_map = YOLO("yolo26n.pt").val(data="coco8.yaml").box.map

# Nur Verbesserungen freigeben und in einem Format exportieren, das der Bereitstellungsstack ausführen kann
if candidate_map > production_map:
    candidate.export(format="onnx")

In einer Produktionspipeline führt ein Scheduler oder CI-Auftrag ein solches Skript aus, sobald neue annotierte Daten eingehen. Das exportierte Modell wird zusammen mit seiner Datenversion und seinen Kennzahlen registriert. Ultralytics Platform deckt diesen Lebenszyklus für Bildverarbeitungsmodelle in einem einzigen Arbeitsbereich ab: mit unveränderlichen Datenversionen, Cloud-Training mit Live-Kennzahlen, Export in Formate wie TensorRT, dedizierten Inferenzendpunkten und Überwachung bereitgestellter Modelle.

MLOps im Vergleich zu verwandten Begriffen#

• DevOps: Automatisiert das Erstellen, Testen und Veröffentlichen von Software, wobei eine Codeänderung die Pipeline auslöst. MLOps ergänzt Daten und Modelle als versionierte Ressourcen, sodass auch neue Daten oder eine sinkende Genauigkeit in der Produktion die Pipeline auslösen können.
• LLMOps: Der Bereich von MLOps für Anwendungen mit großen Sprachmodellen. Im Mittelpunkt stehen Prompts, Abruf, die Bewertung generierter Texte und Tokenkosten.
• Automatisiertes maschinelles Lernen (AutoML): Automatisiert die Entwicklung eines Modells, etwa die Auswahl von Algorithmen und Hyperparametern. MLOps verwaltet den gesamten Lebenszyklus darum herum – von der Datenversionierung bis zur Überwachung – und ruft AutoML häufig als einen Schritt der Pipeline auf.
• MLflow und Weights & Biases: Werkzeuge, die Teile des Lebenszyklus abdecken, etwa die Experimentverfolgung und Modellregister. MLOps verbindet solche Werkzeuge mit Pipelines, Bereitstellung und Überwachung.