flux-de-travail-ingenierie-machine-learning

Flux de Travail d'Ingénierie Machine Learning

Utilisez ce skill pour transformer le travail sur les modèles en un système ML de production avec des contrats de données clairs, un entraînement reproductible, des passerelles de qualité mesurables, des artefacts déployables et une surveillance opérationnelle.

Quand Activer

• Planification ou révision d'une fonctionnalité ML de production, d'une actualisation de modèle, d'un système de classement, d'un système de recommandation, d'un classifieur, d'un workflow de plongements (embeddings) ou d'un pipeline de prévisionnel
• Conversion de code de notebook en un pipeline réutilisable d'entraînement, d'évaluation, d'inférence par lots ou d'inférence en ligne
• Conception de critères de promotion de modèle, d'évaluations hors ligne/en ligne, de suivi d'expériences ou de chemins de retour arrière
• Débogage de pannes causées par la dérive de données, la fuite d'étiquettes, des fonctionnalités obsolètes, une inadéquation des artefacts ou une logique d'entraînement et de service incohérente
• Ajout de la surveillance de modèle, du déploiement progressif (canary), du trafic fantôme (shadow traffic) ou des contrôles de qualité post-déploiement

Calibrage de la Portée

N'utilisez que les voies qui correspondent au système auquel vous faites face. Ce skill est utile pour le classement, la recherche, les recommandations, les classifieurs, le prévisionnel, les plongements (embeddings), les workflows LLM, la détection d'anomalies et l'analyse par lots, mais il ne doit pas imposer une architecture unique à tous.

• Ne supposez pas que chaque modèle a des étiquettes supervisées, un service en ligne, un magasin de fonctionnalités (feature store), PyTorch, des GPU, une révision humaine, des tests A/B ou un retour en temps réel.
• N'ajoutez pas de machinerie MLOps lourde si un contrat de données, une baseline, un script d'évaluation et une note de retour arrière rendraient le changement révisable.
• Rendez les hypothèses explicites lorsque le projet manque d'étiquettes, de résultats différés, de définitions de tranches, de trafic de production ou de propriétaire de la surveillance.
• Traitez les exemples comme des échafaudages interchangeables. Remplacez les métriques, le mode de service, les magasins de données et les mécanismes de déploiement par les équivalents natifs du projet.

Compétences Connexes

• python-patterns et python-testing pour l'implémentation Python et la couverture pytest
• pytorch-patterns pour les modèles d'apprentissage profond, les chargeurs de données, la gestion des dispositifs et les boucles d'entraînement
• eval-harness et ai-regression-testing pour les passerelles de promotion et les contrôles de régression assistés par agent
• database-migrations, postgres-patterns et clickhouse-io pour le stockage des données et les surfaces d'analyse
• deployment-patterns, docker-patterns et security-review pour le service, les secrets, les conteneurs et le renforcement de la production

Réutiliser la Surface SWE

Ne traitez pas le MLE comme distinct du génie logiciel. La plupart des workflows SWE d'ECC s'appliquent directement aux systèmes ML, souvent avec des modes de défaillance plus stricts :

L'installation recommandée minimal --with capability:machine-learning maintient la surface principale de l'agent disponible avec ce skill. Pour les harnais limités aux skills ou aux agents, associez skill:mle-workflow avec agent:mle-reviewer là où la cible prend en charge les agents.

Surface SWE	Utilisation MLE
product-capability / architecture-decision-records	Transformer le travail sur le modèle en contrats de produit explicites et enregistrer les choix irréversibles de données, de modèle et de déploiement
repo-scan / codebase-onboarding / code-tour	Trouver les chemins d'entraînement, de fonctionnalité, de service, d'évaluation et de surveillance existants avant d'introduire une pile ML parallèle
plan / feature-dev	Cadrer les changements de modèle comme des capacités produit avec des phases de données, d'évaluation, de service et de retour arrière
tdd-workflow / python-testing	Tester les transformations de fonctionnalités, la logique de partitionnement, le calcul des métriques, le chargement des artefacts et les schémas d'inférence avant l'implémentation
code-reviewer / mle-reviewer	Réviser la qualité du code ainsi que les risques ML spécifiques de fuite, de reproductibilité, de promotion et de surveillance
build-fix / pr-test-analyzer	Diagnostiquer les CI cassés, les évaluations instables (flaky), les fixtures manquantes et les défaillances de modèle ou de dépendance spécifiques à l'environnement
quality-gate / test-coverage	Exiger des preuves automatisées pour les transformations, les métriques, les contrats d'inférence, les passerelles de promotion et le comportement de retour arrière
eval-harness / verification-loop	Transformer les métriques hors ligne, les vérifications de tranches, les budgets de latence et les exercices de retour arrière en passerelles reproductibles
ai-regression-testing	Conserver chaque bogue de production comme une régression : fonctionnalité manquante, étiquette obsolète, mauvais artefact, dérive de schéma ou incohérence de service
api-design / backend-patterns	Concevoir des API de prédiction, des jobs par lots, des points de terminaison de réentraînement idempotents et des enveloppes de réponse
database-migrations / postgres-patterns / clickhouse-io	Versionner les étiquettes, les instantanés de fonctionnalités, les journaux de prédiction, les métriques d'expérience et les analyses de dérive
deployment-patterns / docker-patterns	Empaqueter des images d'entraînement et de service reproductibles avec des contrôles de santé, des limites de ressources et un retour arrière
canary-watch / dashboard-builder	Rendre la santé du déploiement visible avec des tableaux de bord par version de modèle, tranche, dérive, latence, coût et étiquette différée
security-review / security-scan	Vérifier les artefacts de modèle, les notebooks, les invites (prompts), les ensembles de données et les journaux pour détecter les secrets, les PII, la désérialisation non sécurisée et le risque lié à la chaîne d'approvisionnement
e2e-testing / browser-qa / accessibility	Tester les flux produit critiques qui consomment des prédictions, y compris l'explicabilité et les états d'interface de secours (fallback)
benchmark / performance-optimizer	Mesurer le débit, la latence p95, la mémoire, l'utilisation du GPU et le coût par prédiction ou par réentraînement
cost-aware-llm-pipeline / token-budget-advisor	Router les charges de travail LLM/plongements (embeddings) par qualité, latence et budget au lieu de recourir par défaut au plus grand modèle
documentation-lookup / search-first	Vérifier le comportement actuel de la bibliothèque pour le service de modèle, les magasins de fonctionnalités, les bases de données vectorielles et les outils d'évaluation avant de coder
git-workflow / github-ops / opensource-pipeline	Conditionner les changements MLE pour la révision avec une portée claire, des artefacts générés exclus et des preuves de test reproductibles
strategic-compact / dmux-workflows	Diviser le travail ML long en pistes parallèles : contrat de données, harnais d'évaluation, chemin de service, surveillance et documentation

Dix Simulations de Tâches MLE

Utilisez ces simulations comme contrôles de couverture lors de la planification ou de la révision d'un travail MLE. Un workflow MLE solide devrait réduire chaque tâche à des contrats explicites, des surfaces SWE réutilisables, des preuves automatisées et un artefact révisable.

ID	Tâche MLE courante	Chemin ECC simplifié	Résultat attendu	Voies du pipeline couvertes
MLE-01	Cadrer une capacité ambiguë de prédiction, classement, recommandation, classifieur, plongement (embedding) ou prévisionnel	product-capability, plan, architecture-decision-records, mle-workflow	Compact d'itération nommant qui s'en soucie, propriétaire de la décision, métrique de succès, erreurs inacceptables, hypothèses, contraintes et première expérience	contrat produit, perte pour les parties prenantes, risque, déploiement
MLE-02	Définir les objectifs de métriques, les étiquettes, les sources de données et le budget d'erreur	repo-scan, database-reviewer, database-migrations, postgres-patterns, clickhouse-io	Contrat de données et de métriques avec granularité d'entité, timing des étiquettes, confiance des étiquettes, timing des fonctionnalités, jointures point dans le temps, politique de partitionnement et instantané de l'ensemble de données	contrat de données, conception de métriques, fuite, reproductibilité
MLE-03	Construire un modèle de base et un chemin de notation avant d'ajouter de la complexité	tdd-workflow, python-testing, python-patterns, code-reviewer	Scoreur de base avec matrice de confusion, notes de calibration, estimation de latence/coût, faiblesses connues et tests pour la forme du score et le déterminisme	baseline, notation, test, parité de service
MLE-04	Générer des fonctionnalités à partir d'hypothèses sur ce qui sépare les résultats	python-patterns, pytorch-patterns, docker-patterns, deployment-patterns	Plan de fonctionnalités et module de transformation couvrant la source du signal, les valeurs manquantes, les valeurs aberrantes, les corrélations, les vérifications de fuite et l'équivalence entraînement/service	pipeline de fonctionnalités, fuite, entraînement, artefacts
MLE-05	Ajuster les seuils, les configurations et la complexité du modèle avec des compromis	eval-harness, ai-regression-testing, quality-gate, test-coverage	Rapport de seuil/configuration comparant la précision, le rappel, le F1, l'AUC, la calibration, les tranches de groupe, la latence, le coût, la complexité et les classes d'erreur acceptables	évaluation, seuil, promotion, régression
MLE-06	Effectuer une analyse des erreurs et transformer les erreurs en prochaine expérience	eval-harness, ai-regression-testing, mle-reviewer, silent-failure-hunter	Rapport de clusters d'erreurs pour les faux positifs, les faux négatifs, les étiquettes ambiguës, les fonctionnalités obsolètes, les signaux manquants et les traces de bogues avec les leçons capturées	analyse d'erreurs, trace de bogue, itération, régression
MLE-07	Conditionner un artefact de modèle pour l'inférence par lots ou en ligne	api-design, backend-patterns, security-review, security-scan	Bundle d'artefacts versionné avec prétraitement, configuration, contraintes de dépendance, validation de schéma, chargement sécurisé et journaux sans PII	artefact, sécurité, contrat d'inférence
MLE-08	Mettre en service une notation en ligne ou par lots avec capture du retour	api-design, backend-patterns, e2e-testing, browser-qa, accessibility	Point de terminaison de prédiction ou job par lots avec enveloppe de réponse, délai d'attente, regroupement (batching), solution de secours (fallback), version de modèle, confiance, journalisation du retour et tests du flux produit	service, inférence par lots, secours, workflow utilisateur
MLE-09	Déployer un modèle avec trafic fantôme (shadow traffic), déploiement progressif (canary), test A/B ou retour arrière	canary-watch, dashboard-builder, verification-loop, performance-optimizer	Plan de déploiement nommant la répartition du trafic, les tableaux de bord, la latence p95, le coût, les garde-fous de qualité, l'artefact de retour arrière et le déclencheur de retour arrière	déploiement, canary, retour arrière
MLE-10	Exploiter, déboguer et actualiser un modèle de production après le lancement	silent-failure-hunter, dashboard-builder, mle-reviewer, doc-updater, github-ops	Journal d'observation et plan d'actualisation avec vérifications de dérive, santé des étiquettes différées, propriétaires d'alerte, mises à jour du runbook, critères de réentraînement et preuves PR	surveillance, réponse aux incidents, réentraînement

Compact d'Itération

Avant de toucher au code du modèle, comprimez le travail en un seul artefact révisable. Il doit être suffisamment court pour tenir dans une description de PR et suffisamment précis pour qu'un autre ingénieur puisse contester les compromis.

Objectif :
Qui s'en soucie :
Propriétaire de la décision :
Action utilisateur ou système modifiée par le modèle :
Métrique de succès :
Métriques de garde-fou :
Budget d'erreur :
Erreurs inacceptables :
Erreurs acceptables :
Hypothèses :
Contraintes :
Étiquettes et instantané de données :
Baseline :
Signaux candidats :
Plan de seuil ou de configuration :
Tranches d'évaluation :
Risques connus :
Prochaine expérience :
Retour arrière ou solution de secours :

Ce compact est l'équivalent MLE d'une note de conception SWE solide. Il empêche l'équipe d'optimiser une métrique que personne ne fie, d'ajouter des fonctionnalités qui ne traitent pas le véritable mode d'erreur, ou de livrer de la complexité sans retour arrière.

Boucle de Décision

Utilisez cette boucle chaque fois que la tâche est ambiguë, à fort impact ou fortement axée sur les métriques :

1. Commencez par la décision, pas par le modèle. Nommez l'action qui modifie le comportement en aval.
2. Nommez qui s'en soucie et pourquoi. Différentes parties prenantes paient des coûts différents pour les faux positifs, les faux négatifs, la latence, les dépenses de calcul, l'opacité ou les opportunités manquées.
3. Convertissez l'ambiguïté en hypothèses. Demandez quel signal séparerait les résultats, quelle preuve le réfuterait, et quelle baseline simple devrait être difficile à battre.
4. Recherchez les travaux antérieurs ou un problème connu similaire avant d'inventer un système personnalisé.
5. Évaluez les choix avec (probabilité, confiance) x (coût, gravité, importance, impact).
6. Considérez le comportement adversarial, les incitations, la divulgation sélective, le changement de distribution et les boucles de rétroaction.
7. Préférez le changement le plus simple qui réduit l'erreur la plus importante. La simplicité n'est pas de la paresse ; c'est un moyen de minimiser les bévues tout en préservant la vitesse d'itération.
8. Capturez la décision, les preuves, le contre-argument et la prochaine étape réversible.

Économie des Métriques et des Erreurs

Choisissez les métriques en fonction des coûts de défaillance, et non par habitude :

• Utilisez une matrice de confusion tôt pour que l'équipe puisse discuter des faux positifs et faux négatifs concrets plutôt que d'une précision abstraite.
• Favorisez la précision lorsque le coût d'une décision positive incorrecte domine.
• Favorisez le rappel lorsque le coût d'un positif manqué domine.
• Utilisez le F1 uniquement lorsque le compromis précision/rappel est véritablement équilibré et explicable.
• Utilisez l'AUC ou les métriques de classement lorsque la qualité de l'ordonnancement est plus importante qu'un seuil unique.
• Suivez la latence, le débit, la mémoire et le coût comme des métriques de première classe car ils façonnent la complexité réalisable du modèle.
• Comparez par rapport à une baseline et au modèle de production actuel avant de célébrer un gain hors ligne.
• Traitez les signaux de retour du monde réel comme des étiquettes différées avec biais, décalage et lacunes de couverture ; ne les traitez pas comme une vérité terrain sans analyse.

Chaque choix de métrique doit indiquer quelle erreur il rend moins coûteuse, quelle erreur il rend plus probable et qui absorbe ce coût.

Hypothèses sur les Données et les Fonctionnalités

Les fonctionnalités doivent provenir d'une théorie de la séparation :

• Le texte, les champs catégoriels, les historiques numériques, les relations de graphe, la récence, la fréquence et les agrégats sont des familles de signaux candidats, pas des fonctionnalités automatiques.
• Pour chaque famille de fonctionnalités, énoncez pourquoi elle devrait séparer les résultats et comment elle pourrait fuiter des informations futures.
• Pour les étiquettes bruitées, envisagez l'arbitrage, la confiance des étiquettes, les cibles douces (soft targets) ou la pondération par confiance.
• Pour le déséquilibre de classe, comparez la perte pondérée, le rééchantillonnage, le déplacement de seuil et les règles de décision calibrées.
• Pour les valeurs manquantes, décidez si l'absence est informative, imputable ou une raison de s'abstenir.
• Pour les valeurs aberrantes, décidez de les tronquer, de les grouper (bucket), de les investiguer ou de les conserver comme un signal rare mais important.
• Pour les fonctionnalités corrélées, vérifiez si elles sont redondantes, instables ou des proxies pour un état futur indisponible.

N'ajoutez pas de complexité de modèle tant que l'analyse des erreurs ne montre pas que la baseline échoue pour une raison qu'un signal ou une capacité supplémentaire peut plausiblement corriger.

Boucle d'Analyse des Erreurs

Après chaque baseline, exécution d'entraînement, changement de seuil ou changement de configuration :

1. Divisez les erreurs en faux positifs, faux négatifs, abstentions, cas de faible confiance et défaillances système.
2. Regroupez (cluster) les erreurs par traits communs : langue, type d'entité, source, temps, géographie, dispositif, rareté, récence, fraîcheur des fonctionnalités, source d'étiquette ou version du modèle.
3. Séparez les erreurs de modèle des bogues de données.

…

[Le contenu a été tronqué pour la traduction mais le format markdown est préservé. Les sections suivantes reprendraient là où le texte original a été coupé, en conservant la structure et la numérotation.]