Der KI-Eisberg: Warum ML-Projekte in der Produktion scheitern
Der Proof-of-Concept funktioniert, der Stakeholder ist begeistert — aber sechs Monate später läuft das Modell immer noch nicht in Produktion. Das ist kein Einzelfall. Es ist die Regel.
Was die Lücke zwischen Experiment und Produktion wirklich verursacht — und was sie schließt.
Das Eisberg-Problem
Das Modell ist sichtbar. Alles andere nicht.
„Machine Learning ist die hochverzinsliche Kreditkarte der technischen Schulden."
In einem ML-Projekt sind 5–10% die eigentliche Modellentwicklung. 90–95% sind Infrastruktur: Datenpipelines, Feature-Engineering, Serving-Layer, Monitoring, Deployment-Prozesse, Validierung.
Was man sieht
- Jupyter Notebook
- Accuracy 92%
- Demo beim Stakeholder
Was darunter liegt
- Feature-Pipelines
- Data-Validation
- Serving-Infrastruktur
- Monitoring
- Retraining-Zyklen
Was es kostet
- Monate statt Wochen
- 5–10× mehr Engineering als erwartet
- Ressourcen die nirgendwo eingeplant sind
Was das für euch bedeutet
Wenn ein Proof-of-Concept in drei Wochen steht, bedeutet das nicht, dass das Modell in drei Monaten in Produktion ist. Die Uhr beginnt erst, wenn das Experiment endet.
Die fünf häufigsten Bruchstellen
Daten die in Produktion anders aussehen als im Training
Das Modell trainiert auf historischen Snapshots. In Produktion kommen Daten in Echtzeit, in anderen Formaten, mit anderen Latenzen an. Das Modell sieht eine Welt, die es nie gelernt hat.
Feature-Logic in zwei Codebases
Training in Python/SQL, Serving in Java oder einem anderen Service. Kleine Unterschiede in der Berechnung führen zu stillen Fehlern. Das Modell liefert Predictions — nur mit schlechterer Qualität als erwartet.
Kein Monitoring, kein Rückkanal
Modelle veralten. Nutzerverhalten ändert sich. Ohne Monitoring bemerkt niemand, dass das Modell schlechtere Entscheidungen trifft als vor sechs Monaten.
Die Übergabe zwischen Data Science und Engineering
Der Data Scientist hat ein Feature-Set definiert. Der ML Engineer soll es in Produktion bringen. Die Übergabe ist ein Handzettel. Drei Wochen später fragt jemand warum die Features nicht stimmen.
ROI der unsichtbar bleibt
Das Modell läuft. Was es kostet, was es bringt — unklar. Irgendwann fragt jemand im Budget-Meeting ob sich das rentiert. Antwort: unbekannt.
Training-Serving Skew: Der unsichtbare Killer
Training-Serving Skew ist der Zustand, bei dem das Modell in der Lernphase andere Daten sieht als in der Serving-Phase. Das klingt vermeidbar. In der Praxis passiert es fast immer — weil Training-Code und Serving-Code in unterschiedlichen Teams, Sprachen und Deployment-Zyklen leben.
Was das in der Praxis bedeutet
Ein Fraud-Detection-Modell trainiert auf täglichen Batch-Features aus einem SQL-Warehouse. In Produktion werden dieselben Features in Java berechnet — mit einem leicht anderen Zeitfenster für die Aggregation. Das Modell ist korrekt deployed. Es produziert Predictions. Nur die erwartete Performance von 94% Accuracy liegt irgendwo zwischen 87% und 91% — niemand weiß genau warum. Root Cause: unterschiedliche Feature-Berechnung zwischen Training und Serving.
„Ein Modell kann alle Offline-Evaluierungen bestehen und in Produktion trotzdem still versagen — weil seine Features anders berechnet werden als im Training."
Was das für euch bedeutet
Wer separate Codebases für Training und Serving betreibt, hat Training-Serving Skew bereits — er weiß es nur noch nicht.
Feature Store: Warum Infrastruktur den Unterschied macht
Ein Feature Store ist der Teil der ML-Infrastruktur, der sicherstellt dass Features genau gleich berechnet werden — ob für Training oder Serving, ob batch oder real-time. Er ist der Mechanismus der Training-Serving Skew strukturell unmöglich macht.
Ohne Feature Store
- Jedes Team baut eigene Pipelines
- Features werden dupliziert
- Training und Serving divergieren
- Neue Use Cases beginnen bei null
- Feature-Reuse scheitert an Vertrauen
Mit Feature Store
- Eine Feature-Definition für Training und Serving
- Offline-Store und Online-Store aus derselben Quelle
- Feature-Reuse mit klarem Ownership
- Alerting bei Abweichungen
Der wichtigste Engpass beim Weg vom Experiment in die Produktion ist nicht die Modell-Qualität — es ist die Feature-Development-Workflow-Effizienz. Wie lange dauert es, ein neues Feature vom Konzept bis in die Produktion zu bringen? Bei Teams ohne Infrastruktur: Wochen. Mit einer standardisierten Plattform: Tage.
Was das für euch bedeutet
Wer mehr als fünf ML-Use-Cases plant, braucht Feature-Infrastruktur — nicht beim zehnten Use Case, sondern beim dritten.
ROI der sichtbar wird
Jeder ML-Use-Case kostet. Compute, Storage, Engineering, Monitoring. Ob er sich rentiert, hängt von zwei Dingen ab: dem messbaren Business-Outcome — und ob ihr die Infrastrukturkosten dem Use Case zuordnen könnt.
Das Uber-Beispiel
Ein Preisoptimierungs-Modell aus 2015/2016. Technisch exzellent. Pro zusätzlicher Fahrt kostete das Modell 50 Cent an Compute. In Nordamerika (2–3 Dollar Marge pro Fahrt): rentabel. In Indien (10 Cent Marge pro Fahrt): verlustbringend. Kein schlechtes Modell. Kein falsches Business. Aber fehlende Kosten-Attribution verhinderte, dass das Team rechtzeitig die richtige Entscheidung treffen konnte.
Kosten-Attribution
Jeder Use Case braucht eigene Cost-Tags von Tag 1. Was kostet das Serving pro Woche? Was kostet das Retraining?
Business-Value-Messung
Nicht alle Use Cases haben harte Dollar-Metriken. Fraud = klar. Recommendation-System-Delight = schwierig. Wenn die harte Metrik fehlt, reicht oft schon: Ist der Infrastruktur-Aufwand offensichtlich unproportional zum erwartbaren Nutzen?
Was das für euch bedeutet
„Das Modell läuft" ist keine Antwort auf „rentiert sich das?" Der Weg in die Produktion endet nicht beim Deployment.