MLOps: vom Experiment bis zur Stilllegung

Lifecycle statt Übergabe

NIST strukturiert kontinuierliches Risikomanagement über Govern, Map, Measure, Manage; Messungen sollen Deployment-Kontext, Fachexpertise, Rückmeldungen und Leistungsänderungen einbeziehen.^[1] Ein Release ist deshalb eine überprüfbare Hypothese, kein Endpunkt.

1. Frame & ownerEntscheidung, Nicht-Ziel, Betroffene, Fehlerkosten, Verantwortliche und Exit-Kriterien.
2. Version & reproduceCode, Daten-Snapshot/Abfrage, Features, Labels, Konfiguration, Umgebung und Seeds.
3. Validate & approveBaseline, zeitgerechter Holdout, Subgruppen, Robustheit, Security, Datenschutz und manuelle Rückfallebene.
4. Shadow / canaryTechnische und fachliche Guardrails ohne sofortige volle Wirkung.
5. OperateSystem-, Daten-, Modell-, Workflow- und Impact-Signale mit Owner und Runbook.
6. Rollback / retireRegelmäßig geprobter Rückweg über Artefakt, Schema, State, Zugriff und manuellen Prozess; Daten, Endpunkte und Abhängigkeiten kontrolliert abbauen.

Was überwachen?

NIST hebt Performance-Abfall, Drift, fragmentierte Logs und Human-AI-Feedback-Loops als reale Monitoring-Herausforderungen hervor und beschreibt Metrik/Kadenz als kontextabhängig.^[2]

Shift ist Diagnose, nicht Urteil

Covariate Shift: P(X) ändert sich. Prior Shift: P(Y) ändert sich. Concept Shift: P(Y|X) ändert sich. Ein Population-Stability- oder Distanzsignal beweist weder Performanceverlust noch Ursache. Bei Labelverzug kombiniert man frühe Proxies mit späteren, belastbaren Outcome-Metriken und protokolliert die Unsicherheit.

Feedback Loop: Wenn das Modell bestimmt, welche Fälle Menschen prüfen, entstehen Labels selektiv. Dann darf die spätere Precision auf reviewten Fällen nicht als Populationsgüte ausgegeben werden. Eine zufällige Audit-Stichprobe oder Exploration kann nötig sein; Auswirkungen und Ethik sind vorab zu prüfen.^[3]

Incident- und Rollback-Runbook

1. Erkennen und Schweregrad anhand betroffener Entscheidung/Personen bestimmen.
2. Wirkung begrenzen: Automation aus, Fallback an, Queue sichern.
3. Version, Zeitraum, Inputs, Outputs und Downstream-Konsumenten rekonstruieren.
4. Betroffene Ergebnisse prüfen/korrigieren; Verantwortliche und Eskalation informieren.
5. Ursache beheben, Regressionstest und kontrollierte Wiederfreigabe durchführen.
6. Postmortem ohne Schuldzuweisung; Monitor, Vertrag, Test und Ownership verbessern.

Canary ist begrenzte Evidenz

Ein Canary begrenzt Exposition, garantiert aber keine sichere Vollfreigabe. Population und Dauer müssen seltene Pfade erfassen; Candidate und Control brauchen getrennte, zurechenbare Signale sowie absolute Guardrails. Geteilte Dependencies oder bloße Vorher-nachher-Vergleiche können die Ursache verschleiern.^[5] Ein grüner Canary wird widerlegt, wenn die repräsentative Abdeckung fehlt oder ein absolutes Fehler-/Impact-Limit reißt.

Rollback und Incidentpfad proben

Eine alte Modelldatei ist noch kein Rollback: Schema, State, Konfiguration, Berechtigungen, Downstream-Konsumenten, alternativer Zugriff und manueller Fallback müssen zusammen funktionieren. Ein dokumentierter Google-SRE-Fall zeigt, dass ungeprüfte Rollbackverfahren die Wiederherstellung verlängerten; ein anderer Canary verfehlte eine seltene Konfigurationskombination.^[7]

NIST SP 800-61 Rev. 3 ordnet Vorbereitung sowie Erkennung, Reaktion und Wiederherstellung dem laufenden Risikomanagement zu.^[4] Deshalb prüft ein Tabletop-Drill vorab Owner, alternative Kommunikation, Evidenz- und Outputrekonstruktion, Recovery-Ziel und Folgeaktionen. Scheitert der Drill, ist die behauptete Betriebsbereitschaft widerlegt.