Vom Notebook in die Produktion ohne „magisches“ MLOps

Teams kommen mit einem Notebook, das den Baseline auf einem Hold-out schlägt, und einer Folie „MLOps nächstes Quartal”. Die Lücke zwischen Notebook und vertrauenswürdigem System stoppt die meisten KI-Programme. Die Lösung ist keine mythische MLOps-Plattform mit Marketing-Folie — sondern eine minimale Nachweiskette von Rohdaten bis Score, im Besitz der Menschen, die montags um drei Uhr erreichbar sind, wenn das Modell sich falsch verhält.

Dasselbe Muster sehen wir in Nachfrageprognose, Defekterkennung und Credit Scoring: brillante Offline-Metrik, dann sechs Monate Plattform-Evaluation, während Produktion auf Cron und Pickle auf einem Share läuft. Schnell liefern diejenigen, die eng starten: eine Entscheidung, die das Business ohnehin manuell trifft, eine Metrik und ein Rollback. Alles andere folgt dem Beweis, nicht davor.

Minimale Produktionskette

Produktions-ML ruht auf fünf Gliedern. Erstens ein Datenvertrag: Schema, Freshness-SLA, PII-Regeln, Owner und Eskalation bei verzögerten Feeds. Zweitens ein versionierter Trainingssatz — unveränderliche Snapshot-ID in jeder Model Card und jedem Deployment-Record. Drittens eine reproduzierbare Trainingspipeline: Container, Seed, Git-SHA, Dependency-Lockfile. Viertens ein Model-Registry-Eintrag mit Metriken, Limits, Approver und Artefakt. Fünftens Serving mit Observability: Latenz, Fehler, Input-Verteilung, Feedback bei späten Labels. Fehlt ein Glied, zahlen Sie später — meist im Incident, wenn niemand weiß, welche Daten das heute aktive Modell trainiert haben.

Ein Logistikkunde schaffte diese Kette in elf Wochen: nächtliche Features in Parquet, Training im Schedule, Promotion nach Hold-out und Schema-Checks, API-Serving mit Drift-Dashboards. Kein Feature Store, kein Kubernetes fürs Training. Das Modell war langweilig; das Business vertraute, weil Operatoren forensische Grundfragen beantworten konnten.

Was bewusst warten kann

Feature Stores, Streaming und AutoML-Marktplätze warten, bis zwei oder mehr Modelle Features wirklich teilen oder Sub-Minuten-Latenz mit messbarem Batch-Kostenüberhang. Bis dahin ist ein strukturierter Batch mit nächtlichen Features und Promotion-Gates oft zuverlässiger — und leichter für Risk Committees, die fragen „was passiert, wenn das Modell falsch liegt?”

Wir raten zu einer Deferral List mit Triggern: „Feature Store, wenn Modell B über dreißig Prozent Features mit A teilt” oder „Streaming, wenn p95-Batch-Latenz Revenue blockiert”. Das verhindert Plattform-Tourismus — sechs Monate Vendor-Evaluation ohne Produktion.

Governance ohne Meeting-Flut

Model Cards brauchen keine vierzig Seiten. Eine Seite: Intended Use, Out-of-Scope, Trainingsdaten-Zusammenfassung, Fairness/Limits, Owner, Rollback. Promotion über automatische Checks — Schema, Performance-Floor, Bias-Schwellen — plus Human Sign-off für Produktions-Namespaces. Governance akzeptieren Engineers, wenn sie schlechte Deploys blockiert, statt Meetings über das, was CI hätte fangen können.

Governance bedeutet auch wer promote drücken darf. Trennung Trainer/Approver wie Change Control. Ein Credit-Team lernte das nach einem Fehl-Deploy im Deadline-Crunch — Rollback dauerte länger als der Fix, weil niemand sonst Kontext hatte.

Drift vor den Nutzern

Kovariate Shift auf Top-Inputs und verzögerte Labels überwachen. Alert bei Verteilungsänderung, auch wenn Accuracy stabil wirkt — stale Accuracy, wenn sich die Welt vor drei Wochen änderte, Labels aber nachziehen. Ein Händler vertraute einem Nachfragemodell durch Mix-Shift; Überbestände in Kategorien mit neuen Volumina.

Technische Drift-Signale mit Business-KPIs paaren: Retouren, Override-Rate, Margenimpact. Häufigeres manuelles Override ist oft schnelleres Drift-Signal als jeder Statistiktest. Overrides instrumentieren — kostenlose Labels über Modellvertrauen.

Szenario: Fraud Scoring vs Predictive Maintenance

Zwei Modelle, eine Firma, unterschiedliche Reifebedürfnisse. Fraud braucht niedrige Latenz, Explainability für Ermittler und sofortigen Rollback — die Kette umfasst Shadow Mode vor voller Promotion und Kill Switch per Feature Flag. Predictive Maintenance auf Batch-Telemetrie toleriert nächtliches Scoring, betont Datenvertrag mit OT und dokumentiert Safety-Implikationen bei verpassten Alerts.

Ein generisches „AI Platform”-RFP verzögerte beide. Fraud zuerst — höhere regulatorische Sichtbarkeit — baute Registry-, Monitoring- und Access-Control-Muscle, das Maintenance sechs Monate später erbte. Ein Plattformteam, zwei gestaffelte Lieferungen, null Magie.

Promotion-Pfad, den wir auf der Model Card unterschreiben

Können Sie diese Tabelle nicht füllen, sind Sie nicht reif für das zweite Modell — Sie sind noch im Notebook:

• Trainings-Snapshot-ID — unveränderlich, abgelegt, im Registry referenziert. Nicht „der letzte Extract von Donnerstag“.
• Git-SHA + Lockfile — exakt der Code des Artefakts. „Lief auf meinem Laptop“ ist kein Promotion-Kriterium.
• Offline-Metrik + Entscheidungsmetrik — AUC reicht nicht, wenn das Geschäft falsche Versand-Blocks oder verpasste Betrugseuros schmerzen. Beide aufschreiben.
• Bekannte Fehlermodi — Saisonalität, Werk das gerade einen Sensor gewechselt hat, neuer Produktcode ohne Historie.
• Rollback — vorheriges Artefakt in unter 15 Minuten ladbar, mit Namen wer drücken darf.

Eine Pickle-Datei auf einem Share nennen wir vor einem Prüfer nicht „Produktion“. Organisationen die liefern sind langweilig: eine Entscheidung, eine API, eine Bereitschaft, Logs mit prediction_id, Feature-Hash und Modellversion bei jedem Score. Feature Stores nach dem zweiten Modell das Features teilt — nicht als Plattform-RFP im ersten Jahr. Mehr zur Modellseite: AI / Machine Learning und Data-Science-Modelle.

Drift-Checks, die Dienstag vor den Kunden fangen

Uptime des Scoring-Pods ist Hygiene. Weh tun stille Fehler: Schema validiert noch, aber der Lieferant änderte die Einheit; ein Werk kam dazu und die Population verschob sich; ein Kollege „temporär“ hardcodete einen Default der 40% Traffic wurde. Billige Monitore am ersten Serving-Tag:

1. Tägliches PSI oder einfacher Histogrammvergleich auf den fünf Features die die Entscheidung treiben — Schwelle mit dem Owner, nicht 0.2 aus einem Blog.
2. Scores pro Stunde vs. die letzten vier gleichen Wochentage. 30% Drop um 09:00 ist oft kaputter Upstream, nicht „schwache Nachfrage“.
3. Anteil Fallback / leerer Features. Steigt er, rät das Modell.
4. Wöchentliche Stichprobe von zehn Fällen durch den Menschen der die Entscheidung besitzt — fünfzehn Minuten, Notizen, kein Gremium.

Ist niemand in Bereitschaft für „die Scores sehen komisch aus“, haben Sie eine Demo in einem schöneren Container.

Nächster Schritt

Wählen Sie ein Modell, das dieses Quartal eine echte Entscheidung beeinflusst. Schreiben Sie den Datenvertrag, snapshotten Sie letzten Monat, containerisieren Sie Training, registrieren Sie das Artefakt, fügen Sie drei Charts hinzu: Latenz, Fehler, Top-Feature-Verteilung. Kette unvollständig — RFP pausieren. Unsere Praxis Data-Science-Modelle liefert zuerst die minimale Kette — nicht wenn eine Vendor-Broschüre es sagt.