MLOps und Bereitstellung: Verlagerung des Modells vom Labor in die Produktion

Gewinne:

• Fähigkeit, die besonderen Herausforderungen von ML im Zusammenhang mit dem Code-Daten-Modell-Trio und -Paket zu erkennen und das Modell je nach Geschäftsbedarf online oder im Batch zu präsentieren.
• Möglichkeit zur Implementierung schrittweiser und Rollback-Bereitstellungsmuster (Shadow, Canary, A/B, Rollback) und das Hinzufügen eines getesteten Rollback-Plans zu jeder Bereitstellung
• Möglichkeit, die Daten-Code-Metrik-Verbindung des in Produktion genommenen Modells mit bewertungsschwellengesteuertem CI/CD und Modellregister rückverfolgbar zu halten

Es ist nur die halbe Miete, ein Modell im Notebook auf eine Genauigkeit von 95 % zu bringen. Die andere Hälfte – oft der schwierige Teil – besteht darin, dieses Modell auf zuverlässige, skalierbare und wartbare Weise echten Benutzern zugänglich zu machen. MLOps (Machine Learning Operations: die Disziplin, ML-Modelle in die Produktion zu bringen, zu betreiben und zu warten) kombiniert die DevOps-Praktiken der Softwareentwicklung mit den einzigartigen Herausforderungen von ML. In dieser Einheit behandeln wir die Schritte zur Überführung des Modells in die Produktion und wie künstliche Intelligenz dabei hilft.

Warum unterscheidet sich ML von normaler Software?

Bei gewöhnlicher Software liegt das Verhalten im Code; Wenn sich der Code nicht ändert, ändert sich auch das Verhalten nicht. Bei ML hängt das Verhalten sowohl vom Code, den Daten als auch vom Modell ab. Diese drei Dimensionen stellen die zusätzlichen Herausforderungen von MLOps dar:

• Datendrift: Die Daten in der Produktion entfernen sich im Laufe der Zeit von den Daten im Training; Das Modell wird veraltet.
• Sie müssen drei Dinge versionieren: Code, Daten und Modell – alle drei.
• Stilles Versagen: Ein Modell kann ohne Absturz und ohne Fehler scheitern, indem es einfach falsche Vorhersagen liefert. Um dies zu erkennen, ist eine Überwachung erforderlich.

Deshalb gibt es einen großen Unterschied zwischen einem „Arbeitsmodell“ und einem „serienreifen Modell“.

Musterverpackung und Präsentation

Der erste Schritt bei der Produktion des Modells besteht darin, es zu packen: die Modelldatei, die erforderlichen Bibliotheken, den Vorverarbeitungscode und die Versionsinformationen als reproduzierbares Ganzes. Containerisierung (z. B. Docker: die Anwendung in einer isolierten Box mit all ihren Abhängigkeiten ablegen) ist hier Standard; Es beseitigt das Problem, dass es auf meinem Computer funktionierte.

Zwei grundlegende Muster zur Bereitstellung des Modells:

• Online/Echtzeit (online): Das Modell sitzt hinter einer API und gibt für jede eingehende Anfrage eine sofortige Vorhersage zurück. Eine geringe Latenz ist entscheidend.
• Batch: Das Modell verarbeitet regelmäßig große Datensätze (erstellt beispielsweise nachts Scores für alle Kunden). Latenz ist irrelevant, Effizienz ist wichtig.

Welche die richtige ist, hängt von den Geschäftsanforderungen ab: sofortige Online-Empfehlung, monatliche Risikobewertung im Batch.

Tipp: „Echtzeit“ ist ein Kostenfaktor, nicht die Standardeinstellung. Die Chargenverarbeitung ist viel günstiger und einfacher, wenn das Ergebnis innerhalb weniger Stunden verwendet wird. Benötigen Sie wirklich eine sofortige Antwort? Fragen Sie das zuerst.

Sichere Vertriebsstrategien

Es ist riskant, ein neues Modell direkt für den gesamten Verkehr zu öffnen. Wenn es falsch ist, sind alle betroffen. Sichere Verteilungsmuster:

• Schattenbereitstellung: Das neue Modell empfängt Produktionsdatenverkehr, seine Vorhersagen werden dem Benutzer jedoch nicht angezeigt, sondern nur protokolliert. Es wird mit dem alten Modell verglichen, um zu sehen, ob es in realen Daten sicher ist.
• Canary-Bereitstellung: Das neue Modell wird zunächst für einen kleinen Prozentsatz des Datenverkehrs (z. B. 5 %) eingeführt; Wenn es kein Problem gibt, wird es schrittweise erhöht.
• A/B-Testing: Zwei Modelle werden dem realen Nutzer parallel präsentiert und Geschäftskennzahlen (Conversion, Klicks) verglichen.
• Rollback: Möglichkeit, schnell zur alten Version zurückzukehren, wenn sich das neue Modell als fehlerhaft herausstellt. Für jede Bereitstellung sollte ein Rollback-Plan vorhanden sein.

Achtung: Eine Bereitstellung ohne Rollback-Plan ist nicht abgeschlossen. Die Möglichkeit, innerhalb von Minuten zur alten Version zurückzukehren, schützt den Benutzer, wenn sich das neue Modell in der Produktion unerwartet verhält. Testen Sie dies vor der Bereitstellung.

Schwacher Ansatz / Starker Ansatz

Schwach: „Das Modell war im Test gut, wir gingen live, wir haben es für alle geöffnet.“

Güçlü: „Wir haben das Modell in einen Container verpackt und als Version gekennzeichnet. Zuerst haben wir es drei Tage lang im Schattenmodus mit Produktionsverkehr ausgeführt und die Vorhersagen mit dem alten Modell verglichen – die Abweichung war akzeptabel. Dann haben wir es mit 5 % Canary geöffnet, die Durchsatzmetriken und die Latenz überwacht. Als es keine Probleme gab, haben wir es schrittweise auf 100 % erhöht. Wir hatten den Rollback-Befehl zuvor getestet.“

Der Unterschied: Der starke Ansatz ist schrittweise, maßvoll und reversibel. Das Risiko ist bei jedem Schritt begrenzt.

CI/CD und Automatisierung

CI/CD (Continuous Integration / Continuous Deployment: Pipeline zum automatischen Testen und Freigeben von Codeänderungen) in ML deckt nicht nur den Code, sondern auch die Daten- und Modellschritte ab. Eine gute ML-CI/CD-Pipeline: führt Tests aus, wenn sich der Code ändert, führt eine Datenvalidierung durch, trainiert das Modell neu (falls erforderlich), prüft Bewertungsschwellenwerte und treibt die Bereitstellung nur voran, wenn die Schwellenwerte eingehalten werden. Das Prinzip „Training erfolgt automatisch, Bereitstellung erfolgt schwellenwertbasiert“ verhindert, dass das fehlerhafte Modell stillschweigend in die Produktion gelangt.

KI ist beim Einrichten dieser Pipelines sehr hilfreich: Schreiben von Konfigurationsdateientwürfen (YAML), Testfällen und Bereitstellungsskripten. Aber Sie bestimmen die Verteilungsschwellenwerte (welche Metrik auch immer den veröffentlichten Wert überschreitet) und die Rollback-Richtlinie; Dabei handelt es sich um geschäftliche Risikoentscheidungen.

Reproduzierbarkeitsinfrastruktur

Um das Verhalten eines Modells in der Produktion zu reproduzieren, Modellregistrierung: eine Aufzeichnung, die festhält, welches Modell mit welchen Daten und Code trainiert wurde und welche Metriken es erhalten hat. Für jedes Produktionsmodell sollte Folgendes nachverfolgbar sein: Trainingsdatenversion, Codeversion (Git Commit), Hyperparameter, Bewertungsergebnisse und Bereitstellungsdatum. Wenn ein Problem auftritt, sollten Sie in der Lage sein, die Frage zu beantworten: „Welches Modell hat diese Vorhersage mit welchen Daten erstellt?“ innerhalb von Minuten. Wir werden dies in Einheit 11 vertiefen.

drei Mini-Koffer

Fall 1 – Problem durch Schattenverteilung erfasst. Ein Empfehlungsmodell hat das alte im Test übertroffen. Es wurde festgestellt, dass die Ausführung mit Produktionsverkehr im Schattenmodus zu sehr schlechten Empfehlungen für ein bestimmtes Benutzersegment (neue Benutzer) führte – die Testdaten waren für dieses Segment unterrepräsentativ. Das Modell wurde repariert, ohne dass es dem Benutzer jemals angezeigt wurde. Bei einem direkten Öffnen würde das neue Benutzererlebnis gestört.

Fall 2 – Unwiderrufliche Verteilung. Ein Team führte ein neues Preismodell für den gesamten Datenverkehr ein, ohne Rollback-Pläne. Das Modell hat einige Produkte unerwartet sehr günstig bewertet. Das Zurücksetzen auf die alte Version dauerte Stunden, da der Prozess noch nicht fertig war. Es kam zu erheblichen Einkommenseinbußen. Anschließend wurden zu jeder Bereitstellung obligatorische Rollback-Tests hinzugefügt.

Fall 3 – Stille Datendrift. Ein Betrugsmuster zeigte sich monatelang ohne Fehler. Doch die Taktik der Betrüger änderte sich (Datendrift) und der Rückruf des Modells wurde stillschweigend eingestellt. Niemand bemerkte es, weil es keine Überwachung gab. Nachdem ein Überwachungsgremium für die Prognoseverteilung eingerichtet worden war, wurde die Abweichung frühzeitig sichtbar. Wir werden die Überwachung in Einheit 8 behandeln.

Kopierbare Vorlagen

Schreiben Sie einen Entwurf eines Bereitstellungsplans für dieses Modell. Modell: [was es tut], Verwendung: [online oder Batch?] Sollte Folgendes umfassen: 1) Paketierung (Container, Versionierung) 2) Inkrementelle Bereitstellungsstrategie (Shadow/Canary/A-B) und warum 3) Zu verfolgende Metriken (geschäftlich + technisch + Latenz) 4) Rollback-Plan und Testmethoden 5) Bereitstellungsschwellenwerte (welche Metrik sollte welchen Wert überschreiten)

Überprüfen Sie diese ML CI/CD-Pipeline: 1) Ist die Datenvalidierung in der Zeile? 2) Kann die Bereitstellung fortgesetzt werden, ohne den Bewertungsschwellenwert einzuhalten (sollte dies nicht der Fall sein)? 3) Erfolgt das Rollback automatisch? 4) Werden Daten + Code + Metriken in der Modellregistrierung verfolgt? Pline-Konfiguration: [config]

Helfen Sie mir bei der Entscheidung, ob die Online- oder Batch-Präsentation für dieses Modell geeignet ist. Wie lange wird das Ergebnis verwendet: [Moment / Minute / Stunde / Tag] Erwartetes Anforderungsvolumen: [Anzahl] Gibt es eine Verzögerungsbeschränkung: [ms] Welche würden Sie im Hinblick auf Kosten und Komplexität empfehlen und warum?

Schreiben Sie ein Rollback-Verfahren für dieses Modell. – Welche Metrik/welcher Schwellenwert löst eine schlechte Leistung aus? – Was sind die Rollback-Schritte? – Wie lange sollte das Rollback dauern (Ziel)? – Wie teste ich dieses Verfahren vor der Produktion?

Präsentationsmustertabelle

Kriterium

Online (Echtzeit)

Charge

Verzögerung

Kritisch (ms)

unbedeutend

Nutzung

Sofortige Reaktion erforderlich

Periodische Partitur

Kosten

hoch

niedrig

Komplexität

hoch

niedrig

Beispiel

Live-Empfehlung, Betrug

Monatlicher Risikoscore

Häufige Fehler

• Verteilen ohne Rückholplan. Falsches Modell trifft den gesamten Benutzer.
• Direkte Öffnung für 100 % Verkehr. Begrenzen Sie das Risiko durch eine gestaffelte Verteilung.
• Keine Überwachung einrichten. Das Modell erzeugt Fehler stillschweigend und ohne Fehler.
• Redundante Echtzeitpräsentation. Während die Chargenbildung ausreichend ist, steigen die Kosten und die Komplexität.
• Modell-Daten-Code-Versionen werden nicht verknüpft. Sie können das Problem nicht reproduzieren.
• Automatische Veröffentlichung ohne Verteilungsschwelle. Das schlechte Modell schleicht sich lautlos ein.

Zusammenfassend

Das Modell in die Produktion zu bringen ist eine andere und oft schwierigere technische Aufgabe als das Trainieren. ML erfordert zusätzliche Disziplin, da es vom Trio Code-Daten-Modell abhängt: Paketierung und Versionierung, Bereitstellungsmuster (online/Batch), das den Geschäftsanforderungen entspricht, schrittweise und umkehrbare Bereitstellung, schwellenwertgesteuertes CI/CD und Modellregistrierung. Künstliche Intelligenz ist ein leistungsstarkes Hilfsmittel bei der Generierung des Codes und der Konfiguration dieser Infrastruktur; aber Verteilungsschwellen, Rückforderungsrichtlinien und Risikoentscheidungen liegen bei Ihnen. Eine Verteilung ohne Rollback-Plan ist nicht vollständig.

Anwendungsaufgabe

Containerisieren (Docker) ein Modell und beschriften Sie es mit der Version. Entscheiden Sie, ob Sie basierend auf Ihren Geschäftsanforderungen ein Online- oder Batch-Angebot erstellen möchten, und schreiben Sie Ihre Begründung. Dokumentieren Sie einen stufenweisen Bereitstellungsplan (Shadow oder Canary) und ein getestetes Rollback-Verfahren. Stellen Sie sicher, dass Sie die Datenversion, das Code-Commit und die Bewertungsergebnisse in der Modellregistrierung aufzeichnen.

Checkliste

• [ ] Das Modell ist verpackt und versioniert (Container + Etikett).
• [ ] Das Präsentationsmuster (online/Batch) wurde entsprechend den Geschäftsanforderungen ausgewählt.
• [ ] Stufenweise Bereitstellungsstrategie (Shadow/Canary) implementiert.
• [ ] Rollback-Prozedur geschrieben und getestet.
• [ ] CI/CD treibt die Bereitstellung nicht voran, bevor der Bewertungsschwellenwert erreicht ist.
• [ ] Die Modellregistrierung enthält den Daten+Code+Metrik-Link.