Wie bringt man ein ML-Modell vom Notebook in den Produktivbetrieb?
Direkte Antwort
Der Übergang vom Notebook zur Produktion erfordert drei Schritte, die im Prototyp meist fehlen — die exakte Trennung und Wiederverwendung der Feature-Berechnung zwischen Training und Inferenz, eine dedizierte Serving-Infrastruktur statt manueller Notebook-Ausführung, und laufendes Monitoring, das Modellqualität im Betrieb überwacht statt nur einmalig im Test zu prüfen.
"Der Data Scientist, der ein Modell im Notebook baut, und die Infrastruktur, die es später bedient, arbeiten oft mit unterschiedlichen Annahmen über dieselben Daten — genau dort entstehen die teuersten Produktionsfehler.
Ein Modell, das im Notebook mit sauberen, vorbereiteten Testdaten gute Ergebnisse liefert, muss in Produktion mit rohen, oft unvollständigen Echtzeitdaten funktionieren — eine Lücke, die viele Projekte unterschätzen.
Training-Serving-Skew als häufigste Fehlerquelle
Wird die Feature-Berechnung für Training und für die Live-Inferenz getrennt implementiert, etwa einmal in einem Python-Notebook mit Pandas und einmal in einer Produktions-API mit anderer Logik, entstehen leicht unterschiedliche Ergebnisse für dieselbe Eingabe.
Dieser sogenannte Training-Serving-Skew ist eine der häufigsten, aber am schwersten zu diagnostizierenden Ursachen dafür, dass ein Modell in Produktion schlechter performt als im Test — die Lösung ist, dieselbe Feature-Berechnungslogik für Training und Inferenz zu verwenden, etwa über einen gemeinsamen Feature Store.
Von manueller Notebook-Ausführung zu dedizierter Serving-Infrastruktur
Ein Notebook ist für Exploration gebaut, nicht für zuverlässigen, skalierbaren Betrieb unter Last. Produktive Systeme brauchen einen Serving-Layer (etwa FastAPI, TorchServe oder eine Cloud-ML-Plattform), der das Modell containerisiert, versioniert ausliefert und horizontal skaliert.
Diese Umstellung erfordert oft eine komplette Neustrukturierung des Codes aus dem Notebook in testbare, wiederverwendbare Module — ein Aufwand, der in Projektschätzungen häufig unterschätzt wird.
Monitoring als kontinuierlicher, nicht einmaliger Schritt
Anders als ein einmaliger Test vor dem Launch braucht ein produktives Modell laufendes Monitoring von Vorhersagequalität, Eingabeverteilung und Latenz, weil sich die Datenlage in der realen Welt über Zeit verändert.
Ohne dieses Monitoring bleibt unbemerkt, wenn ein Modell durch veränderte Realität schlechter wird, bis der geschäftliche Schaden bereits entstanden ist.
Wann passt es — wann nicht?
Passt gut
- ✓Das Modell soll dauerhaft mit echtem, sich veränderndem Datenverkehr laufen
Passt nicht
- ✗Es handelt sich um eine einmalige Analyse ohne wiederkehrenden Live-Betrieb