Daten- und Modellprozess für ein ML-System planen

Wenn eine hohe Trefferquote die falsche Entscheidung verdeckt

Die Elbwerk Gerätevermietung GmbH verleiht akkubetriebene Werkzeuge an Handwerksbetriebe. Nach jeder Rückgabe durchläuft jedes Gerät eine kurze Sicht- und Funktionsprüfung. Ein Teil der Geräte benötigt anschließend eine erweiterte Werkstattprüfung. Bisher entscheidet eine feste Regel anhand weniger Fehlercodes, welche Geräte dorthin kommen.

Ein lernendes System soll die Mitarbeitenden künftig bei dieser Triage unterstützen. Es soll bei der Rückgabe einschätzen, ob eine erweiterte Prüfung nötig ist. Die Entscheidung darf nur Informationen verwenden, die zu diesem Zeitpunkt bereits vorliegen. Die abschließende Sicherheitsfreigabe bleibt bei einer qualifizierten Person.

Ein erster Prototyp erreicht 91 Prozent Genauigkeit. Das klingt überzeugend. Die Projektgruppe entdeckt jedoch, dass im Datensatz auch die später bestellten Ersatzteile stehen. Diese Information entsteht erst nach der Werkstattprüfung. Außerdem wurden Zeilen desselben Geräts zufällig auf Training und Test verteilt. Der Wert sagt deshalb wenig darüber aus, wie sich das Modell bei künftigen Rückgaben verhält.

Dein Auftrag lautet: Plane einen Daten- und Modellprozess, der aus einem fachlichen Ziel eine nachvollziehbare, prüfbare und rückfallfähige ML-Unterstützung macht.

Die Grundidee lautet: Ein Modell ist nicht schon dann einsatzbereit, wenn ein Trainingslauf endet. Es braucht eine belastbare Zieldefinition, eine Trennung entlang des späteren Einsatzes, einen ehrlichen Vergleich und einen kontrollierten Betrieb.

Du solltest Anteile verstehen und Tabellen lesen können. Programmierkenntnisse sind hilfreich, aber nicht nötig. Das Unternehmen, die Datensätze und alle Grenzwerte dieser Lektion sind neu für dieses Übungsszenario erstellt.

Formuliere zuerst die fachliche Entscheidung

“Wir wollen Werkstattfälle vorhersagen” lässt wichtige Fragen offen. Ein tragfähiges Ziel legt mindestens fünf Punkte fest:

1. Entscheidungsobjekt: genau eine Rückgabe eines Geräts,
2. Vorhersagezeitpunkt: nach der kurzen Rückgabeprüfung, bevor die Werkstatt entscheidet,
3. Zielvariable oder Label: nachpruefung_noetig, bestätigt durch die spätere Werkstattprüfung,
4. Nutzung: Priorisierung für eine erweiterte Prüfung, keine automatische Sicherheitsfreigabe,
5. Fehlerwirkung: Ein übersehener Werkstattfall wiegt schwerer als eine zusätzliche Prüfung.

Das Label ist das bekannte Ergebnis, das ein überwachtes Lernverfahren aus historischen Beispielen lernen soll. Bei Elbwerk lautet es ja, wenn die dokumentierte Werkstattprüfung einen erweiterten Prüfbedarf bestätigt, sonst nein. Die Dokumentation muss außerdem regeln, wie unklare, abgebrochene oder widersprüchliche Prüfungen behandelt werden. Ein leeres Feld darf nicht still als nein gelten.

Auch die Freigabekriterien entstehen vor dem Training. Für diese Übung vereinbart das Team:

• mindestens 90 Prozent Recall für nachpruefung_noetig auf dem unangetasteten Testzeitraum,
• höchstens 35 Prozent aller Rückgaben als Modellhinweis, damit die Werkstatt die Fälle bearbeiten kann,
• keine automatische Freigabe eines Geräts,
• nachvollziehbare Begründung, Datenversion und Modellversion für jeden Freigabelauf,
• erfolgreicher Schattenbetrieb über einen vereinbarten Zeitraum vor der aktiven Nutzung.

Diese Werte gelten nur im Elbwerk-Szenario. In einem realen Auftrag würden Fachseite, Arbeitsschutz, Informationssicherheit und weitere zuständige Stellen die Fehlerfolgen und Grenzwerte gemeinsam festlegen.

Trenne Merkmale nach ihrem Entstehungszeitpunkt

Ein Merkmal oder Feature ist eine Information, die das Modell für seine Vorhersage verwendet. Nicht alles, was in historischen Daten gut mit dem Label zusammenhängt, steht beim späteren Einsatz rechtzeitig zur Verfügung.

Data Leakage entsteht, wenn Informationen in Training oder Bewertung einfließen, die beim echten Vorhersagezeitpunkt nicht verfügbar wären oder aus dem späteren Ziel stammen. Das Modell erhält dann einen unerlaubten Hinweis auf die Antwort. Gute Testwerte können genau dadurch entstehen und brechen im Betrieb weg.

Baue einen Split, der den späteren Einsatz nachstellt

Ein zufälliger Split einzelner Zeilen wäre für Elbwerk riskant. Dasselbe Gerät kann mehrfach zurückgegeben werden. Nahe beieinanderliegende Rückgaben teilen möglicherweise Gerätezustand, Wartungsereignisse oder Erfassungsbedingungen. Außerdem soll das Modell künftig eintreffende Rückgaben bewerten, nicht eine zufällige Auswahl aus derselben Zeit.

Für das Übungsszenario liegen 18 Monate freigegebene Historie vor. Das Team trennt sie chronologisch:

• Training: Monate 1 bis 12, um Aufbereitung und Modellparameter zu lernen,
• Validierung: Monate 13 bis 15, um Varianten und Schwellenwert auszuwählen,
• Test: Monate 16 bis 18, einmalige Bewertung des festgelegten Kandidaten.

Bei allen drei Mengen gilt: Ein Merkmal aus der Gerätehistorie darf nur Ereignisse vor der jeweiligen Rückgabe verwenden. Das Team prüft zusätzlich, ob Gerätekennungen oder nahezu identische Vorgänge die Grenzen überbrücken. Wenn das Betriebsziel ausdrücklich die Übertragung auf völlig neue Gerätetypen wäre, bräuchte der Split zusätzlich passende Gruppen nach Typ oder Baureihe.

Der Testsatz bleibt während Entwicklung und Schwellenwertwahl geschlossen. Wer nach jedem Fehlschlag den Testwert anschaut und das Modell anpasst, optimiert indirekt auf diesen Satz. Er ist dann kein unabhängiger Abschlussnachweis mehr.

Vergleiche zuerst mit einer einfachen Baseline

Eine Baseline ist ein einfacher, nachvollziehbarer Vergleich. Sie zeigt, ob ein komplexeres Modell überhaupt einen belegbaren Mehrwert liefert. Bei Elbwerk dienen zwei Vergleiche:

• die bisherige feste Fehlercode-Regel,
• die einfache Regel “jede Rückgabe zur erweiterten Prüfung”, die alle positiven Fälle findet, aber die Werkstatt überlastet.

Das Team misst deshalb nicht nur Modellgüte, sondern auch die Zahl der ausgelösten Werkstatthinweise. Ein Kandidat, der Recall gewinnt, aber fast jede Rückgabe markiert, löst die betriebliche Triage nicht.

Für eine Klassifikation liefert die Konfusionsmatrix vier Fälle:

Der Recall der positiven Klasse beantwortet: Welcher Anteil der tatsächlich nötigen Werkstattprüfungen wurde markiert?

Recall = richtig positive Fälle / (richtig positive Fälle + falsch negative Fälle)

Die Precision beantwortet: Welcher Anteil der Modellhinweise war laut späterem Werkstattbefund tatsächlich positiv?

Precision = richtig positive Fälle / (richtig positive Fälle + falsch positive Fälle)

Für Elbwerk ist Recall besonders wichtig, weil ein falsch negativer Fall die Triage verfehlt. Precision und Hinweisquote bleiben trotzdem relevant, weil die Werkstatt nur begrenzte Kapazität hat. Eine Metrik allein bildet diesen Zielkonflikt nicht ab.

Mache den Lauf reproduzierbar

Ein Ergebnis ist nur dann nachprüfbar, wenn ein anderes Team den bewerteten Kandidaten aus denselben Grundlagen wiederherstellen kann. Toolnamen sind dabei austauschbar. Entscheidend sind die gespeicherten Artefakte und ihre Beziehungen.

Für jeden Lauf dokumentiert Elbwerk mindestens:

• fachliche Ziel- und Labeldefinition einschließlich Ausschlussregeln,
• unveränderliche Kennung oder Prüfwert des Daten-Snapshots,
• Abfragecode und zeitliche Merkmalsgrenzen,
• Split-Regel und Zeitraum jeder Datenmenge,
• versionierten Aufbereitungs- und Modellcode,
• Konfiguration, Hyperparameter und verwendeten Zufallsstartwert,
• Laufzeitumgebung und festgelegte Abhängigkeiten,
• Baseline, Metriken, Konfusionsmatrix und Schwellenwert,
• bekannte Grenzen, verantwortliche Rollen und Freigabeentscheidung.

Ein Werkzeug wie eine Pipeline-Komponente kann Aufbereitung und Modell zusammenhalten. Eine Versionsverwaltung kann Codestände kennzeichnen. Ein Experiment-Tracker kann Parameter und Ergebnisse erfassen. Keiner dieser Produktnamen ersetzt jedoch die fachliche Definition oder eine vollständige Nachweiskette.

Verbinde Entwicklung, Freigabe und Betrieb

Im Schattenbetrieb erzeugt das Modell Hinweise, diese steuern den Arbeitsablauf aber noch nicht. Das Team vergleicht die Hinweise mit den tatsächlich bestätigten Werkstattergebnissen und prüft Datenwege, Latenz, Kapazität und Fehlerfälle.

Die Freigabe umfasst mehr als eine Modellnummer. Sie bezeichnet ein Paket aus:

• Daten- und Labeldefinition,
• gespeicherter Aufbereitung,
• Modellartefakt und Schwellenwert,
• Laufzeitumgebung,
• Schnittstellenvertrag,
• Modell- und Datenbeschreibung,
• Testnachweis,
• Monitoringregeln,
• verantwortlichen Rollen und Rückfallplan.

Eine neue Datenaufbereitung mit demselben Modellnamen ist eine relevante Änderung. Sie braucht erneut eine versionierte Bewertung. Das gilt auch für einen veränderten Schwellenwert.

Überwache nicht nur, ob der Dienst erreichbar ist

Im Betrieb ändern sich Daten und Prozesse. Ein Monitoring betrachtet deshalb mehrere Ebenen:

Drift bezeichnet eine relevante Veränderung über die Zeit. Bei Datendrift verändert sich beispielsweise die Verteilung von Eingaben. Bei Konzeptdrift verändert sich der Zusammenhang zwischen Eingaben und Ziel. Eine neue Geräteserie kann Datendrift auslösen. Ein geänderter Werkstattprozess kann zusätzlich die Labelbedeutung verschieben.

Ein Driftalarm beweist noch nicht, dass das Modell schlecht geworden ist. Umgekehrt beweist eine stabile Eingabeverteilung keine stabile Fachleistung. Elbwerk untersucht deshalb Ursache, betroffene Teilgruppe und bestätigte Labels, bevor das Team neu trainiert oder Grenzwerte ändert.

Labels treffen verzögert ein, weil die Werkstattprüfung erst nach der Vorhersage endet. Das Monitoring muss Vorhersage und späteres Ergebnis über eine Ereigniskennung verbinden. Offene Fälle dürfen nicht voreilig als negativ gelten.

Transfer: Entwirf einen Freigabeplan für ein neues Szenario

Was du aus der Lektion mitnimmst

Ein ML-Prozess beginnt mit der fachlichen Entscheidung, nicht mit einem Werkzeug. Zielvariable, Vorhersagezeitpunkt und Fehlerwirkung bestimmen, welche Daten zulässig sind und welche Metriken tragen. Die Trennung in Training, Validierung und Test schützt die Bewertung nur dann, wenn auch Zeit, Gruppen und Vorverarbeitung sauber getrennt bleiben.

Eine Baseline macht den Mehrwert sichtbar. Versionierte Daten, Code, Konfiguration und Umgebung machen den Kandidaten nachvollziehbar. Freigabe, Schattenbetrieb, Monitoring und Rückfall gehören zum Systementwurf. Drift ist ein Untersuchungsanlass, keine automatische Aufforderung zum Neutraining.

Quellenbasis und Abgrenzung

• Der KMK-Rahmenlehrplan trägt in Lernfeld 10c die Auswahl, Anpassung, das Training und die Bewertung von Werkzeugen des maschinellen Lernens im beruflichen Handlungskontext.
• Die Fachinformatikerausbildungsverordnung ordnet das Analysieren und Bereitstellen von Daten sowie ihre Nutzung für Vorhersagemodelle, Mustererkennung und Prozessoptimierung den Berufsbildpositionen D2 und D3 zu. D4 ergänzt Datenschutz und Schutzziele. § 28 trägt die nachvollziehbare Planung, Analyse und Dokumentation eines Datenanalyseprojekts.
• Der interne AP2-Lernguide stützt Train-Test-Trennung, Overfitting, Modellbewertung und einen phasenorientierten ML-Prozess als Themenbreite. Er ist keine Aussage darüber, welche konkrete Aufgabe in einem Prüfungstermin vorkommt.
• Der scikit-learn User Guide dient als technische Fachquelle für Daten-Leakage, konsistente Vorverarbeitung und Klassifikationsmetriken. Die Lektion bleibt werkzeugunabhängig; andere Bibliotheken können denselben Prozess umsetzen.
• Das NIST AI Risk Management Framework stützt die fortlaufende Messung, Dokumentation, Überwachung und Behandlung von Risiken. Es legt für dieses erfundene Szenario keine konkreten Grenzwerte fest.
• Die vorgelagerte Eignungsbewertung entscheidet, ob ML angemessen ist. Diese Lektion beginnt nach dieser Entscheidung und endet beim überwachten Modellbetrieb. Eine allgemeine Datenanalyseprojektplanung deckt zusätzlich Projektorganisation, Aufwand, Termine und Übergabe ab.

Belegmatrix