ML in der Praxis

ML in der Praxis: Daten, Features, MLOps

Begriffe vorab

• Pipeline: die Folge von Schritten von den Rohdaten bis zur Vorhersage.
• Datenleck: Information aus den Testdaten oder der Zukunft fließt unbeabsichtigt ins Training.
• Drift: die schleichende Veränderung von Daten oder Zusammenhängen.

Der meiste Aufwand liegt nicht im Modell

In realen Projekten verbringen Teams oft den größten Teil ihrer Zeit mit Datenbeschaffung, -bereinigung und -aufbereitung statt mit dem eigentlichen Modelltraining. Fehlende Werte, falsche Formate, Ausreißer und inkonsistente Kategorien müssen behandelt werden, bevor überhaupt trainiert werden kann.

Feature Engineering

Feature Engineering bezeichnet das gezielte Konstruieren und Auswählen von Eingabemerkmalen, die einem Modell helfen, Muster leichter zu erkennen – etwa das Ableiten des Wochentags aus einem Zeitstempel oder das Kombinieren zweier Rohwerte zu einem aussagekräftigeren Verhältnis. Bei Deep-Learning-Modellen übernimmt das Netz einen Teil dieser Merkmalsextraktion selbst, klassische Verfahren profitieren dagegen stärker von manuell konstruierten Features.

MLOps: Vom Notebook in den Betrieb

MLOps (Machine Learning Operations) übertragt Praktiken aus der Softwareentwicklung (Versionskontrolle, automatisierte Tests, kontinuierliche Integration) auf ML-Projekte, ergänzt um ML-spezifische Aufgaben:

• Versionierung nicht nur von Code, sondern auch von Daten und trainierten Modellen.
• Deployment: das Modell wird als Dienst (z. B. über eine API) bereitgestellt, damit andere Systeme Vorhersagen abrufen können.
• Monitoring: laufende Überwachung der Vorhersagequalität in Produktion, nicht nur einmalig beim Training.
• Retraining: das Modell wird periodisch mit neuen Daten neu trainiert.

Data Drift und Model Decay

Die Welt ändert sich, und mit ihr die Daten: Data Drift bezeichnet Verschiebungen in der Verteilung der Eingabedaten gegenüber den Trainingsdaten (z. B. neues Kundenverhalten nach einer Krise). Dadurch kann die Modellqualität mit der Zeit abnehmen, selbst wenn sich am Modell selbst nichts geändert hat – ein Phänomen, das oft als Model Decay bezeichnet wird und laufendes Monitoring nötig macht.

Ein Modell, das im Notebook auf historischen Daten gut funktioniert, ist erst der Anfang. Ob es in Produktion, mit echten, sich wandelnden Daten und unter echten Zeit- und Ressourcenbeschränkungen funktioniert, zeigt sich erst im Betrieb.

Ein Beispiel für ein Datenleck

Ein Modell soll Kreditausfälle vorhersagen und verwendet ein Merkmal „wurde Mahnung versendet“. Dieses Merkmal entsteht erst nach dem Zahlungsproblem. Im Test wirkt das Modell hervorragend, im Einsatz fehlt das Merkmal zum Zeitpunkt der Entscheidung. Deshalb muss man bei jedem Merkmal fragen: Ist es zum Vorhersagezeitpunkt wirklich bekannt?

Reihenfolge eines Projekts

1. Fachliche Frage und Erfolgsmaß klären.
2. Daten beschaffen, prüfen und bereinigen.
3. Einfache Baseline bauen.
4. Modell verbessern und sauber validieren.
5. Ausrollen, überwachen und bei Drift neu trainieren.

Häufige Stolpersteine

• Kein Verantwortlicher für den Betrieb des Modells.
• Fehlende Überwachung – Qualitätsverlust bleibt unbemerkt.
• Unterschiedliche Datenaufbereitung in Training und Produktion.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind.

Quellen

• Google Cloud – „MLOps: Continuous delivery and automation pipelines in machine learning“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• D. Sculley et al. – „Hidden Technical Debt in Machine Learning Systems“ (NeurIPS, 2015)
• scikit-learn-Dokumentation – „Preprocessing data“ (allgemeine Referenz, nicht Zeile für Zeile geprüft)