Data Science im Betrieb

Was Data Scientists in den meisten Unternehmen bekommen, ist nicht das, was sie brauchen. Sample-Exporte, anonymisierte Snapshots, veraltete CSVs aus dem Data-Warehouse-Team — die Realität liegt drei Datendrehscheiben weg. MLflow auf einer gemeinsamen Operations-Datenbasis verschiebt das. Aus „hier ist ein Sample" wird „arbeite direkt auf den produktiven Daten, in einer kontrollierten Umgebung".

Warum Sample-Exporte ein Anti-Pattern sind

Daten-Drift bleibt unsichtbar. Ein Sample, das vor sechs Monaten exportiert wurde, repräsentiert nicht die heutige Verteilung. Ein Modell, das auf dem Sample trainiert wurde, performt bei Deployment anders — manchmal schlechter, manchmal in unauffälliger Weise.

Edge Cases verschwinden. Sampling glättet die Realität. Genau die seltenen Vorfälle, die ein operatives Modell erkennen soll, sind in einem 5%-Sample meist gar nicht enthalten — oder so selten, dass das Modell sie nicht lernt.

Der Übergang zur Produktion ist ein Bruch. Modell wird auf Sample trainiert, dann auf produktive Daten losgelassen, dann zeigen sich Probleme — Schemas leicht verschoben, Feature-Verteilungen anders, Edge Cases nicht abgedeckt. Drei Iterationen später läuft etwas, das im ersten Wurf hätte laufen können.

Audit-Reproduzierbarkeit fehlt. Welche Daten lagen genau vor, als Modell Version 3.2 trainiert wurde? Eine Antwort, die „wir haben den Snapshot von Mai" lautet, ist gegen ein Audit nicht haltbar — gerade wenn das Modell regulatorisch relevante Entscheidungen unterstützt.

Wie sich der Workflow mit produktionsnaher Datenbasis ändert

Data Scientists arbeiten direkt auf der gemeinsamen Datenbasis. Eine vorintegrierte Browser-IDE plus MLflow als Experiment-Tracking, Model-Registry und Trainings-Runtime — alles auf den gleichen Daten, die im operativen Betrieb fließen. Kein Datenexport, keine Synchronisation, kein Versatz.

Experimente sind reproduzierbar. MLflow erfasst Trainings-Run, Hyperparameter, Metriken, Model-Artefakt — und referenziert die Daten-Version, die genutzt wurde. Wer in sechs Monaten fragt „wie kam Version 3.2 zustande", bekommt eine vollständige Antwort.

Deployment ist ein Konfigurations-Schritt. Modelle aus der Registry kommen über Kubernetes-Workflows in Produktion — auf derselben Infrastruktur, die das Training getragen hat. Der Bruch zwischen „Modell im Notebook" und „Modell im operativen Service" verschwindet.

Drift-Monitoring eingebaut. Wenn die Datenverteilung in Produktion abweicht von der zur Trainings-Zeit, wird das sichtbar — als Metrik, als Alarm, als Trigger für Re-Training. Modell-Verfall wird erkannt, bevor er Geschäft kostet.

Welche Use Cases damit erst möglich werden

Predictive Maintenance auf Telemetrie. Vorausschauende Wartung verlangt Modelle, die auf Echtzeit-Telemetrie reagieren. Wenn die Telemetrie über drei Datendrehscheiben gesynct werden muss, bevor das Modell sie sieht, ist „predictive" eine Lüge — der Vorhersagezeitraum ist vom Lag aufgefressen.

Anomalie-Erkennung in operativen Datenströmen. Ein Modell, das Auffälligkeiten in Treibstoff-Verbrauch, Wartezeiten, Vorfall-Mustern erkennt, muss auf produktiven Daten laufen — nicht auf einem geglätteten Sample, in dem die Anomalien fehlen.

Echtzeit-Decision-Services mit ML-Anteil. Wenn ein Decision-Service Misconnection-Risiko bewertet, Verspätungs-Wahrscheinlichkeiten schätzt, oder Wartungs-Empfehlungen ableitet, ist die Datenfrische sekundenkritisch. ML auf der operativen Datenbasis liefert das ohne Daten-Pipeline-Frickelei.

Continuous Re-Training. Modelle, die kontinuierlich auf neuen Daten nachtrainiert werden, sind nur möglich, wenn Trainings-Daten und Produktionsdaten dasselbe sind. Sonst geht jede Iteration durch denselben Export-Tunnel — Wochen, nicht Stunden.

Der Hebel ist nicht „noch ein ML-Werkzeug", sondern die Verschiebung der Datenbasis. Wer Data Science aus dem Sample-Export-Modus in den produktionsnahen Modus bringen will, klärt das im Tactical Assessment.