mle-workflow (Machine-Learning-Engineering-Workflow)

Machine Learning Engineering Workflow (MLE-Workflow)

Verwenden Sie diesen Skill, um Modellarbeit in ein produktionsreifes ML-System zu verwandeln – mit klaren Datenverträgen, wiederholbarem Training, messbaren Qualitätsgates, bereitstellbaren Artefakten und operativer Überwachung.

Wann aktivieren?

• Planung oder Überprüfung einer produktionsrelevanten ML-Funktion, eines Modell-Updates, eines Ranking-Systems, eines Recommenders, eines Klassifikators, eines Embedding-Workflows oder einer Forecasting-Pipeline
• Konvertierung von Notebook-Code in eine wiederverwendbare Pipeline für Training, Evaluierung, Batch-Inferenz oder Online-Inferenz
• Entwurf von Modell-Promotion-Kriterien, Offline/Online-Evaluierungen, Experiment-Tracking oder Rollback-Pfaden
• Fehlersuche bei Ausfällen durch Data Drift, Label-Leakage, veraltete Features, Artefaktinkonsistenzen oder inkonsistente Trainings- und Serving-Logik
• Hinzufügen von Modellüberwachung, Canary-Rollout, Shadow-Traffic oder Qualitätsprüfungen nach der Bereitstellung

Umfangskalibrierung

Verwenden Sie nur die Bereiche, die zu dem vor Ihnen liegenden System passen. Dieser Skill ist nützlich für Ranking, Suche, Empfehlungen, Klassifikatoren, Forecasting, Embeddings, LLM-Workflows, Anomalieerkennung und Batch-Analysen, sollte aber nicht eine Architektur auf alle aufzwingen.

• Gehen Sie nicht davon aus, dass jedes Modell überwachte Labels, Online-Serving, ein Feature-Store, PyTorch, GPUs, menschliche Überprüfung, A/B-Tests oder Echtzeit-Feedback hat.
• Fügen Sie kein schweres MLOps-Maschinenwerk hinzu, wenn ein Datenvertrag, eine Baseline, ein Evaluierungsskript und eine Rollback-Notiz die Änderung überprüfbar machen würden.
• Machen Sie Annahmen explizit, wenn das Projekt keine Labels, verzögerte Ergebnisse, Slice-Definitionen, Produktionstraffic oder Überwachungsverantwortung hat.
• Behandeln Sie Beispiele als austauschbare Gerüste. Ersetzen Sie Metriken, Serving-Art, Datenspeicher und Rollout-Mechanismen durch die projekteigenen Äquivalente.

Verwandte Skills

• python-patterns und python-testing für Python-Implementierung und pytest-Abdeckung
• pytorch-patterns für Deep-Learning-Modelle, Data Loader, Geräteverwaltung und Trainingsschleifen
• eval-harness und ai-regression-testing für Promotion-Gates und agentengestützte Regressionsprüfungen
• database-migrations, postgres-patterns und clickhouse-io für Datenspeicherung und Analyseoberflächen
• deployment-patterns, docker-patterns und security-review für Serving, Secrets, Container und Produktionshärtung

Wiederverwendung der SWE-Oberfläche

Behandeln Sie MLE nicht als von Softwareentwicklung getrennt. Die meisten ECC-SWE-Workflows sind direkt auf ML-Systeme anwendbar, oft mit strengeren Fehlermodi:

Die empfohlene minimal --with capability:machine-learning-Installation hält die Kern-Agent-Oberfläche zusammen mit diesem Skill verfügbar. Für Skill-only oder agentenlimitierte Harnesses kombinieren Sie skill:mle-workflow mit agent:mle-reviewer, wo das Ziel Agenten unterstützt.

SWE-Oberfläche	MLE-Verwendung
product-capability / architecture-decision-records	Modellarbeit in explizite Produktverträge umwandeln und irreversible Daten-, Modell- und Rollout-Entscheidungen dokumentieren
repo-scan / codebase-onboarding / code-tour	Vor der Einführung eines parallelen ML-Stacks vorhandene Trainings-, Feature-, Serving-, Evaluierungs- und Überwachungspfade finden
plan / feature-dev	Modelländerungen als Produktfähigkeiten mit Daten-, Evaluierungs-, Serving- und Rollback-Phasen eingrenzen
tdd-workflow / python-testing	Feature-Transformationen, Split-Logik, Metrikberechnungen, Artefaktladung und Inferenzschemata vor der Implementierung testen
code-reviewer / mle-reviewer	Code-Qualität plus ML-spezifische Risiken wie Leakage, Reproduzierbarkeit, Promotion und Überwachung überprüfen
build-fix / pr-test-analyzer	Defekte CI, flaky Evaluierungen, fehlende Fixtures und umgebungsspezifische Modell- oder Abhängigkeitsfehler diagnostizieren
quality-gate / test-coverage	Automatisierte Nachweise für Transformationen, Metriken, Inferenzverträge, Promotion-Gates und Rollback-Verhalten fordern
eval-harness / verification-loop	Offline-Metriken, Slice-Prüfungen, Latenzbudgets und Rollback-Übungen in wiederholbare Gates verwandeln
ai-regression-testing	Jeden Produktionsfehler als Regression bewahren: fehlendes Feature, veraltetes Label, schlechtes Artefakt, Schema-Drift oder Serving-Inkonsistenz
api-design / backend-patterns	Vorhersage-APIs, Batch-Jobs, idempotente Retraining-Endpunkte und Antwort-Envelopes entwerfen
database-migrations / postgres-patterns / clickhouse-io	Labels, Feature-Snapshots, Vorhersageprotokolle, Experiment-Metriken und Drift-Analysen versionieren
deployment-patterns / docker-patterns	Reproduzierbare Trainings- und Serving-Images mit Health-Checks, Ressourcenlimits und Rollback verpacken
canary-watch / dashboard-builder	Rollout-Gesundheit sichtbar machen mit Dashboards für Modellversion, Slices, Drift, Latenz, Kosten und verzögerte Labels
security-review / security-scan	Modellartefakte, Notebooks, Prompts, Datensätze und Logs auf Secrets, PII, unsichere Deserialisierung und Supply-Chain-Risiken prüfen
e2e-testing / browser-qa / accessibility	Kritische Produktabläufe testen, die Vorhersagen konsumieren, einschließlich Erklärbarkeit und Fallback-UI-Zustände
benchmark / performance-optimizer	Durchsatz, p95-Latenz, Speicher, GPU-Auslastung und Kosten pro Vorhersage oder Neuarbeit messen
cost-aware-llm-pipeline / token-budget-advisor	LLM/Embedding-Workloads nach Qualität, Latenz und Budget routen, anstatt standardmäßig das größte Modell zu verwenden
documentation-lookup / search-first	Vor dem Programmieren aktuelles Bibliotheksverhalten für Modell-Serving, Feature-Stores, Vektor-DBs und Evaluierungstools überprüfen
git-workflow / github-ops / opensource-pipeline	MLE-Änderungen zur Überprüfung verpacken – mit klarem Umfang, ausgeschlossenen generierten Artefakten und reproduzierbaren Testnachweisen
strategic-compact / dmux-workflows	Lange ML-Arbeit in parallele Spuren aufteilen: Datenvertrag, Evaluierungs-Harness, Serving-Pfad, Überwachung und Dokumentation

Zehn MLE-Aufgabensimulationen

Verwenden Sie diese Simulationen als Abdeckungsprüfungen bei der Planung oder Überprüfung von MLE-Arbeiten. Ein starker MLE-Workflow sollte jede Aufgabe auf explizite Verträge, wiederverwendbare SWE-Oberflächen, automatisierte Nachweise und ein überprüfbares Artefakt reduzieren.

ID	Häufige MLE-Aufgabe	Optimierter ECC-Pfad	Erforderliche Ausgabe	Abgedeckte Pipeline-Bereiche
MLE-01	Eine mehrdeutige Vorhersage-, Ranking-, Recommender-, Klassifikator-, Embedding- oder Forecast-Fähigkeit einrahmen	product-capability, plan, architecture-decision-records, mle-workflow	Iteration Compact: Wer kümmert sich, Entscheidungsinhaber, Erfolgsmetrik, inakzeptable Fehler, Annahmen, Einschränkungen und erstes Experiment	Produktvertrag, Stakeholder-Verlust, Risiko, Rollout
MLE-02	Metrikziele, Labels, Datenquellen und das Fehlerbudget definieren	repo-scan, database-reviewer, database-migrations, postgres-patterns, clickhouse-io	Daten- und Metrikvertrag mit Entitätskorn, Label-Timing, Label-Konfidenz, Feature-Timing, Point-in-Time-Joins, Split-Policy und Dataset-Snapshot	Datenvertrag, Metrikdesign, Leakage, Reproduzierbarkeit
MLE-03	Ein Baseline-Modell und einen Scoring-Pfad erstellen, bevor Komplexität hinzugefügt wird	tdd-workflow, python-testing, python-patterns, code-reviewer	Baseline-Scorer mit Confusion-Matrix, Kalibrierungsnotizen, Latenz-/Kostenschätzung, bekannten Schwächen und Tests für Score-Form und Determiniertheit	Baseline, Scoring, Testen, Serving-Parität
MLE-04	Features aus Hypothesen darüber generieren, was Ergebnisse trennt	python-patterns, pytorch-patterns, docker-patterns, deployment-patterns	Feature-Plan und Transform-Modul: Signalquelle, fehlende Werte, Ausreißer, Korrelationen, Leakage-Prüfungen und Train/Serve-Äquivalenz	Feature-Pipeline, Leakage, Training, Artefakte
MLE-05	Schwellenwerte, Konfigurationen und Modellkomplexität unter Abwägungen abstimmen	eval-harness, ai-regression-testing, quality-gate, test-coverage	Schwellenwert-/Konfigurationsbericht: Precision, Recall, F1, AUC, Kalibrierung, Gruppen-Slices, Latenz, Kosten, Komplexität und akzeptable Fehlerklassen	Evaluierung, Schwellenwert, Promotion, Regression
MLE-06	Fehleranalyse durchführen und Fehler in das nächste Experiment verwandeln	eval-harness, ai-regression-testing, mle-reviewer, silent-failure-hunter	Fehlerclusterbericht: Falsch-Positive, Falsch-Negative, mehrdeutige Labels, veraltete Features, fehlende Signale und Bug-Traces mit gewonnenen Erkenntnissen	Fehleranalyse, Bug-Trace, Iteration, Regression
MLE-07	Ein Modellartefakt für Batch- oder Online-Inferenz verpacken	api-design, backend-patterns, security-review, security-scan	Versioniertes Artefakt-Bundle: Vorverarbeitung, Konfiguration, Abhängigkeitsbeschränkungen, Schema-Validierung, sicheres Laden und PII-sichere Logs	Artefakt, Sicherheit, Inferenzvertrag
MLE-08	Online-Serving oder Batch-Scoring mit Feedback-Erfassung ausliefern	api-design, backend-patterns, e2e-testing, browser-qa, accessibility	Vorhersage-Endpunkt oder Batch-Job: Antwort-Envelope, Timeout, Batching, Fallback, Modellversion, Konfidenz, Feedback-Protokollierung und Produktablauf-Tests	Serving, Batch-Inferenz, Fallback, Benutzerworkflow
MLE-09	Ein Modell mit Shadow-Traffic, Canary, A/B-Test oder Rollback ausrollen	canary-watch, dashboard-builder, verification-loop, performance-optimizer	Rollout-Plan: Traffic-Aufteilung, Dashboards, p95-Latenz, Kosten, Qualitäts-Gates, Rollback-Artefakt und Rollback-Trigger	Bereitstellung, Canary, Rollback
MLE-10	Ein Produktionsmodell nach dem Launch betreiben, debuggen und aktualisieren	silent-failure-hunter, dashboard-builder, mle-reviewer, doc-updater, github-ops	Beobachtungsbuch und Aktualisierungsplan: Drift-Prüfungen, verzögerte Label-Gesundheit, Alarmverantwortliche, Runbook-Updates, Retrain-Kriterien und PR-Nachweise	Überwachung, Incident Response, Retraining

Iteration Compact

Verdichten Sie die Arbeit vor dem Berühren von Modellcode in ein überprüfbares Artefakt. Es sollte kurz genug für eine PR-Beschreibung sein und präzise genug, dass ein anderer Ingenieur die Abwägungen hinterfragen kann.

Ziel:
Wer kümmert sich:
Entscheidungsinhaber:
Vom Modell geänderte Benutzer- oder Systemaktion:
Erfolgsmetrik:
Schutzmetriken:
Fehlerbudget:
Inakzeptable Fehler:
Akzeptable Fehler:
Annahmen:
Einschränkungen:
Labels und Daten-Snapshot:
Baseline:
Kandidatensignale:
Schwellenwert- oder Konfigurationsplan:
Evaluierungs-Slices:
Bekannte Risiken:
Nächstes Experiment:
Rollback oder Fallback:

Dieses Compact ist das MLE-Äquivalent einer starken SWE-Entwurfsnotiz. Es verhindert, dass das Team eine Metrik optimiert, der niemand vertraut, Features hinzufügt, die den tatsächlichen Fehlermodus nicht adressieren, oder Komplexität ohne Rollback ausliefert.

Entscheidungsschleife

Verwenden Sie diese Schleife immer dann, wenn die Aufgabe mehrdeutig, folgenreich oder metriklastig ist:

1. Beginnen Sie mit der Entscheidung, nicht dem Modell. Benennen Sie die Aktion, die das nachgelagerte Verhalten ändert.
2. Benennen Sie, wer sich kümmert und warum. Verschiedene Stakeholder zahlen unterschiedliche Kosten für Falsch-Positive, Falsch-Negative, Latenz, Rechenaufwand, Intransparenz oder verpasste Chancen.
3. Wandeln Sie Mehrdeutigkeit in Hypothesen um. Fragen Sie, welches Signal Ergebnisse trennen würde, welche Beweise es widerlegen würden und welche einfache Baseline schwer zu schlagen sein sollte.
4. Recherchieren Sie Vorarbeiten oder ein nahegelegenes bekanntes Problem, bevor Sie ein maßgeschneidertes System erfinden.
5. Bewerten Sie Optionen mit (Wahrscheinlichkeit, Konfidenz) x (Kosten, Schweregrad, Wichtigkeit, Auswirkung).
6. Berücksichtigen Sie adversarielles Verhalten, Anreize, selektive Offenlegung, Verteilungsverschiebung und Feedback-Schleifen.
7. Bevorzugen Sie die einfachste Änderung, die den wichtigsten Fehler reduziert. Einfachheit ist nicht Faulheit; sie ist ein Weg, um Fehler zu minimieren und gleichzeitig die Iterationsgeschwindigkeit zu erhalten.
8. Halten Sie die Entscheidung, die Beweise, das Gegenargument und den nächsten umkehrbaren Schritt fest.

Metrik- und Fehlerökonomie

Wählen Sie Metriken basierend auf Fehlerkosten, nicht aus Gewohnheit:

• Verwenden Sie früh eine Confusion-Matrix, damit das Team konkrete Falsch-Positive und Falsch-Negative diskutieren kann, anstatt abstrakte Genauigkeit.
• Bevorzugen Sie Precision, wenn die Kosten einer falsch-positiven Entscheidung dominieren.
• Bevorzugen Sie Recall, wenn die Kosten einer verpassten Positiven dominieren.
• Verwenden Sie F1 nur, wenn der Precision/Recall-Kompromiss wirklich ausgewogen und erklärbar ist.
• Verwenden Sie AUC oder Ranking-Metriken, wenn die Ordnungsqualität wichtiger ist als ein einzelner Schwellenwert.
• Verfolgen Sie Latenz, Durchsatz, Speicher und Kosten als erstklassige Metriken, da sie die realisierbare Modellkomplexität formen.
• Vergleichen Sie mit einer Baseline und dem aktuellen Produktionsmodell, bevor Sie einen Offline-Gewinn feiern.
• Behandeln Sie Echtzeit-Feedbacksignale als verzögerte Labels mit Verzerrung, Nachlauf und Abdeckungslücken; behandeln Sie sie nicht ohne Analyse als Grundwahrheit.

Jede Metrikwahl sollte angeben, welchen Fehler sie billiger macht, welchen Fehler sie wahrscheinlicher macht und wer diese Kosten trägt.

Daten- und Feature-Hypothesen

Features sollten aus einer Trennungstheorie stammen:

• Text, kategoriale Felder, numerische Verläufe, Graphbeziehungen, Aktualität, Häufigkeit und Aggregate sind Kandidaten-Signalfamilien, keine automatischen Features.
• Geben Sie für jede Feature-Familie an, warum sie Ergebnisse trennen sollte und wie sie zukünftige Informationen durchsickern lassen könnte.
• Erwägen Sie bei verrauschten Labels Adjudikation, Label-Konfidenz, weiche Ziele oder Konfidenzgewichtung.
• Vergleichen Sie bei Klassenungleichgewicht gewichteten Verlust, Resampling, Schwellenwertverschiebung und kalibrierte Entscheidungsregeln.
• Entscheiden Sie bei fehlenden Werten, ob Abwesenheit informativ, imputierbar oder ein Grund zur Enthaltung ist.
• Entscheiden Sie bei Ausreißern, ob Sie sie clippen, bucketen, untersuchen oder als seltene, aber wichtige Signale bewahren sollen.
• Überprüfen Sie bei korrelierten Features, ob sie redundant, instabil oder Proxy für einen nicht verfügbaren zukünftigen Zustand sind.

Fügen Sie keine Modellkomplexität hinzu, bis die Fehleranalyse zeigt, dass die Baseline aus einem Grund versagt, den zusätzliches Signal oder Kapazität plausibel beheben kann.

Fehleranalyseschleife

Nach jeder Baseline, jedem Trainingslauf, jeder Schwellenwertänderung oder Konfigurationsänderung:

1. Teilen Sie Fehler auf in: Falsch-Positive, Falsch-Negative, Enthaltungen, Fälle mit niedriger Konfidenz und Systemfehler.
2. Clustern Sie Fehler nach gemeinsamen Merkmalen: Sprache, Entitätstyp, Quelle, Zeit, Geografie, Gerät, Dünnbesetzung, Aktualität, Feature-Frische, Label-Quelle oder Modellversion.
3. Trennen Sie Modellfehler von Datenfehlern …

… (gekürzt zur Übersetzung)