mle-workflow

Machine Learning Engineering Workflow (MLE-Workflow)

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

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 Prognosepipeline
• Konvertierung von Notebook-Code in eine wiederverwendbare Trainings-, Evaluierungs-, Batch-Inferenz- oder Online-Inferenz-Pipeline
• Entwurf von Modell-Promotion-Kriterien, Offline/Online-Evaluierungen, Experiment-Tracking oder Rollback-Pfaden
• Fehlersuche bei Ausfällen, die durch Data Drift, Label Leakage, veraltete Features, Artefaktinkonsistenzen oder inkonsistente Trainings- und Serving-Logik verursacht werden
• Hinzufügen von Modell-Monitoring, Canary-Rollout, Shadow-Traffic oder Qualitätschecks nach dem Deployment

Umfangskalibrierung

Verwenden Sie nur die Bereiche, die zum vorliegenden System passen. Dieser Skill ist nützlich für Ranking, Suche, Empfehlungen, Klassifikatoren, Prognosen, Embeddings, LLM-Workflows, Anomalieerkennung und Batch-Analysen, sollte aber nicht eine einzige Architektur auf alle erzwingen.

• Nehmen Sie nicht an, dass jedes Modell überwachte Labels, Online-Serving, ein Feature-Store, PyTorch, GPUs, manuelle Überprüfung, A/B-Tests oder Echtzeit-Feedback hat.
• Fügen Sie keine schwergewichtige MLOps-Infrastruktur hinzu, wenn ein Datenvertrag, eine Baseline, ein Eval-Skript und eine Rollback-Notiz die Änderung überprüfbar machen.
• Machen Sie Annahmen explizit, wenn dem Projekt Labels, verzögerte Ergebnisse, Slice-Definitionen, Produktionstraffic oder Monitoring-Verantwortung fehlen.
• Behandeln Sie Beispiele als austauschbare Gerüste. Ersetzen Sie Metriken, Serving-Modus, 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äte-Handling und Trainingsschleifen
• eval-harness und ai-regression-testing für Promotions-Gates und agentengestützte Regression-Checks
• 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 getrennt vom Software-Engineering. Die meisten ECC-SWE-Workflows lassen sich direkt auf ML-Systeme anwenden, oft mit strengeren Fehlermodi:

Die empfohlene minimal --with capability:machine-learning-Installation hält die Kern-Agentenoberfläche zusammen mit diesem Skill verfügbar. Für reine Skill- oder agentenbegrenzte Umgebungen kombinieren Sie skill:mle-workflow mit agent:mle-reviewer, sofern das Zielsystem Agents 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	Vorhandene Trainings-, Feature-, Serving-, Eval- und Monitoring-Pfade finden, bevor ein paralleler ML-Stack eingeführt wird
plan / feature-dev	Modelländerungen als Produktfähigkeiten mit Daten-, Eval-, Serving- und Rollback-Phasen abgrenzen
tdd-workflow / python-testing	Feature-Transformationen, Split-Logik, Metrikberechnungen, Artefakt-Ladung und Inferenz-Schemata vor der Implementierung testen
code-reviewer / mle-reviewer	Codequalität plus ML-spezifische Risiken wie Leakage, Reproduzierbarkeit, Promotion und Monitoring überprüfen
build-fix / pr-test-analyzer	Defekte CI, flaky Evals, fehlende Fixtures und umgebungsspezifische Modell- oder Abhängigkeitsfehler diagnostizieren
quality-gate / test-coverage	Automatisierte Nachweise für Transformationen, Metriken, Inferenzverträge, Promotions-Gates und Rollback-Verhalten verlangen
eval-harness / verification-loop	Offline-Metriken, Slice-Checks, Latenz-Budgets 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 Antwortenvelopes entwerfen
database-migrations / postgres-patterns / clickhouse-io	Labels, Feature-Snapshots, Vorhersageprotokolle, Experimentmetriken und Drift-Analysen versionieren
deployment-patterns / docker-patterns	Reproduzierbare Trainings- und Serving-Images mit Health-Checks, Ressourcenlimits und Rollback packen
canary-watch / dashboard-builder	Rollout-Gesundheit sichtbar machen mit Dashboards für Modellversion, Slice, 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 Produktflüsse 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 Neues Training messen
cost-aware-llm-pipeline / token-budget-advisor	LLM-/Embedding-Workloads nach Qualität, Latenz und Budget statt standardmäßig zum größten Modell routen
documentation-lookup / search-first	Aktuelles Bibliotheksverhalten für Model Serving, Feature Stores, Vektor-DBs und Eval-Tooling vor dem Codieren überprüfen
git-workflow / github-ops / opensource-pipeline	MLE-Änderungen für Reviews mit klarem Umfang, ausgeschlossenen generierten Artefakten und reproduzierbaren Testnachweisen verpacken
strategic-compact / dmux-workflows	Lange ML-Arbeit in parallele Tracks aufteilen: Datenvertrag, Eval-Harness, Serving-Pfad, Monitoring und Dokumentation

Zehn MLE-Aufgaben-Simulationen

Verwenden Sie diese Simulationen als Abdeckungschecks 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	Typische MLE-Aufgabe	Optimierter ECC-Pfad	Erforderliche Ausgabe	Pipeline-Bereiche abgedeckt
MLE-01	Eine mehrdeutige Vorhersage-, Ranking-, Recommender-, Klassifikator-, Embedding- oder Prognosefähigkeit einrahmen	product-capability, plan, architecture-decision-records, mle-workflow	Iteration Compact: Benennung der betroffenen Personen, Entscheidungsträger, 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ätskörnung, Label-Timing, Label-Konfidenz, Feature-Timing, Point-in-Time-Joins, Split-Richtlinie 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 Konfusionsmatrix, 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 Transformationsmodul mit Signalquelle, fehlenden Werten, Ausreißern, Korrelationen, Leakage-Checks und Trainings-/Serving-Äquivalenz	Feature-Pipeline, Leakage, Training, Artefakte
MLE-05	Schwellenwerte, Konfigurationen und Modellkomplexität unter Abwägungen optimieren	eval-harness, ai-regression-testing, quality-gate, test-coverage	Threshold-/Config-Bericht mit Vergleich von Precision, Recall, F1, AUC, Kalibrierung, Gruppen-Slices, Latenz, Kosten, Komplexität und akzeptablen Fehlerklassen	Evaluation, Threshold, Promotion, Regression
MLE-06	Fehleranalyse durchführen und Fehler in das nächste Experiment umwandeln	eval-harness, ai-regression-testing, mle-reviewer, silent-failure-hunter	Fehlercluster-Bericht für falsch positive, falsch negative, mehrdeutige Labels, veraltete Features, fehlende Signale und Bug-Traces mit festgehaltenen Erkenntnissen	Fehleranalyse, Bug-Trace, Iteration, Regression
MLE-07	Ein Modellartefakt für Batch- oder Online-Inferenz paketieren	api-design, backend-patterns, security-review, security-scan	Versioniertes Artefakt-Bundle mit Vorverarbeitung, Konfiguration, Abhängigkeitsbeschränkungen, Schema-Validierung, sicherem Laden und PII-sicheren 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 mit Antwortenvelope, Timeout, Batching, Fallback, Modellversion, Konfidenz, Feedback-Logging und Produktfluss-Tests	Serving, Batch-Inferenz, Fallback, Benutzer-Workflow
MLE-09	Ein Modell mit Shadow-Traffic, Canary, A/B-Test oder Rollback ausrollen	canary-watch, dashboard-builder, verification-loop, performance-optimizer	Rollout-Plan mit Benennung von Traffic-Teilung, Dashboards, p95-Latenz, Kosten, Qualitäts-Schutzmaßnahmen, Rollback-Artefakt und Rollback-Trigger	Deployment, 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 mit Drift-Checks, verzögerter Label-Gesundheit, Alarmverantwortlichen, Runbook-Updates, Retrain-Kriterien und PR-Nachweisen	Monitoring, Incident Response, Retraining

Iteration Compact

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

Ziel:
Betroffene:
Entscheidungsträger:
Vom Modell geänderte Benutzer- oder Systemaktion:
Erfolgsmetrik:
Schutzmetriken:
Fehlerbudget:
Inakzeptable Fehler:
Akzeptable Fehler:
Annahmen:
Einschränkungen:
Labels und Daten-Snapshot:
Baseline:
Kandidatensignale:
Threshold- oder Konfigurationsplan:
Eval-Slices:
Bekannte Risiken:
Nächstes Experiment:
Rollback oder Fallback:

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

Entscheidungs-Schleife

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

1. Beginnen Sie mit der Entscheidung, nicht dem Modell. Nennen Sie die Aktion, die das Verhalten nachgelagerter Systeme ändert.
2. Nennen Sie die Betroffenen und warum. Verschiedene Stakeholder tragen unterschiedliche Kosten für falsch positive, falsch negative Ergebnisse, Latenz, Rechenaufwand, Intransparenz oder verpasste Chancen.
3. Wandeln Sie Mehrdeutigkeit in Hypothesen um. Fragen Sie, welches Signal Ergebnisse trennen würde, welche Evidenz es widerlegen würde und welche einfache Baseline schwer zu schlagen sein sollte.
4. Recherchieren Sie zuvor bekannte Probleme oder ähnliche Arbeiten, 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 Rückkopplungsschleifen.
7. Bevorzugen Sie die einfachste Änderung, die den wichtigsten Fehler reduziert. Einfachheit ist nicht Faulheit; sie ist eine Möglichkeit, Fehler zu minimieren und gleichzeitig die Iterationsgeschwindigkeit zu erhalten.
8. Halten Sie die Entscheidung, Evidenz, Gegenargument und den nächsten reversiblen Schritt fest.

Metrik- und Fehlerökonomie

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

• Verwenden Sie frühzeitig eine Konfusionsmatrix, damit das Team konkrete falsch positive und falsch negative Ergebnisse anstelle abstrakter Genauigkeit diskutieren kann.
• Bevorzugen Sie Precision, wenn die Kosten einer falsch positiven Entscheidung dominieren.
• Bevorzugen Sie Recall, wenn die Kosten einer verpassten positiven Entscheidung dominieren.
• Verwenden Sie F1 nur, wenn der Precision/Recall-Tradeoff wirklich ausgewogen und erklärbar ist.
• Verwenden Sie AUC oder Ranking-Metriken, wenn die Bestellqualität wichtiger ist als ein einzelner Schwellenwert.
• Verfolgen Sie Latenz, Durchsatz, Speicher und Kosten als erstklassige Metriken, da sie die praktikable Modellkomplexität bestimmen.
• Vergleichen Sie mit einer Baseline und dem aktuellen Produktionsmodell, bevor Sie einen Offline-Gewinn feiern.
• Behandeln Sie reale Rückkopplungssignale als verzögerte Labels mit Verzerrung, Verzögerung und Abdeckungslücken; betrachten Sie sie nicht ohne Analyse als Grundwahrheit.

Jede Metrikwahl sollte angeben, welchen Fehler sie günstiger 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.
• Bei verrauschten Labels erwägen Sie Adjudikation, Label-Konfidenz, weiche Targets oder Konfidenzgewichtung.
• Bei Klassenungleichgewicht vergleichen Sie gewichteten Verlust, Resampling, Schwellenwertverschiebung und kalibrierte Entscheidungsregeln.
• Bei fehlenden Werten entscheiden Sie, ob Abwesenheit informativ, imputierbar oder ein Grund zur Enthaltung ist.
• Bei Ausreißern entscheiden Sie, ob Sie sie kürzen, bündeln, untersuchen oder als seltene, aber wichtige Signale bewahren.
• Bei korrelierten Features prüfen Sie, ob sie redundant, instabil oder Proxy für nicht verfügbare zukünftige Zustände 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.

Fehleranalyse-Schleife

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

1. Teilen Sie Fehler auf in falsch positiv, falsch negativ, Enthaltungen, Fälle geringer Konfidenz und Systemausfälle.
2. Gruppieren Sie Fehler nach gemeinsamen Merkmalen: Sprache, Entitätstyp, Quelle, Zeit, Geografie, Gerät, Seltenheit, Aktualität, Feature-Frische, Label-Quelle oder Modellversion.
3. Trennen Sie Modellfehler von Datenfehlern.