Flux de Travail en Ingénierie Machine Learning

Workflow d'Ingénierie Machine Learning

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

Quand l'activer

• Planification ou révision d'une fonctionnalité ML de production, d'une mise à jour de modèle, d'un système de classement, d'un moteur de recommandation, d'un classifieur, d'un workflow d'embeddings ou d'un pipeline de prévision
• Conversion d'un notebook en 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 rollback
• Débogage d'échecs causés par la dérive des données, la fuite d'étiquettes, des caractéristiques obsolètes, une inadéquation des artefacts ou une logique d'entraînement et de service incohérente
• Ajout de surveillance de modèle, de déploiement canari, de trafic fantôme ou de contrôles de qualité post-déploiement

Calibration du périmètre

Utilisez uniquement les voies qui correspondent au système que vous avez devant vous. Ce skill est utile pour le classement, la recherche, les recommandations, les classifieurs, les prévisions, les embeddings, les workflows LLM, la détection d'anomalies et l'analyse par lots, mais il ne doit pas imposer une seule architecture à tous ces cas.

• Ne présumez pas que chaque modèle a des étiquettes supervisées, un service en ligne, un 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 quand un contrat de données, une baseline, un script d'évaluation et une note de rollback suffisent à rendre 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.

Skills associés

• 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 périphériques et les boucles d'entraînement
• eval-harness et ai-regression-testing pour les portes de promotion et les contrôles de régression assistés par agent
• database-migrations, postgres-patterns et clickhouse-io pour les surfaces de stockage de données et 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 l'ingénierie ML comme distincte du génie logiciel. La plupart des workflows SWE 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 agent de base 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 de modélisation en contrats 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 caractéristiques, 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 rollback
tdd-workflow / python-testing	Tester les transformations de caractéristiques, la logique de partitionnement, les calculs de métriques, le chargement d'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 : fuite, reproductibilité, promotion et surveillance
build-fix / pr-test-analyzer	Diagnostiquer les CI cassées, les évaluations instables, les fixtures manquantes et les échecs 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 portes de promotion et le comportement de rollback
eval-harness / verification-loop	Transformer les métriques hors ligne, les contrôles de tranches, les budgets de latence et les exercices de rollback en portes répétables
ai-regression-testing	Conserver chaque bug de production comme une régression : caractéristique manquante, étiquette obsolète, mauvais artefact, dérive de schéma ou inadéquation 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 caractéristiques, les journaux de prédiction, les métriques d'expériences 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 rollback
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, les jeux de données et les journaux pour 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 repli
benchmark / performance-optimizer	Mesurer le débit, la latence p95, la mémoire, l'utilisation 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/embedding par qualité, latence et budget plutôt que par défaut vers le plus grand modèle
documentation-lookup / search-first	Vérifier le comportement actuel de la bibliothèque pour le service de modèle, les feature stores, les bases de données vectorielles et les outils d'évaluation avant de coder
git-workflow / github-ops / opensource-pipeline	Préparer les changements MLE pour la révision avec un périmètre clair, artefacts générés exclus et preuves de test reproductibles
strategic-compact / dmux-workflows	Diviser le long travail ML 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 bon workflow MLE doit 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 rationalisé	Résultat attendu	Voies du pipeline couvertes
MLE-01	Cadrer une capacité ambiguë de prédiction, classement, recommandation, classifieur, embedding ou prévision	product-capability, plan, architecture-decision-records, mle-workflow	Compact d'itération nommant qui se soucie, décideur, métrique de succès, erreurs inacceptables, hypothèses, contraintes et première expérience	contrat produit, perte des parties prenantes, risque, déploiement
MLE-02	Définir les objectifs 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 métrique avec granularité d'entité, timing d'étiquette, confiance d'étiquette, timing de caractéristique, jointures point-in-time, politique de partitionnement et instantané de jeu de données	contrat de données, conception métrique, fuite, reproductibilité
MLE-03	Construire un modèle de base et un chemin de score 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 et le déterminisme du score	baseline, scoring, test, parité de service
MLE-04	Générer des caractéristiques à partir d'hypothèses sur ce qui sépare les résultats	python-patterns, pytorch-patterns, docker-patterns, deployment-patterns	Plan de caractéristiques et module de transformation couvrant la source du signal, les valeurs manquantes, les outliers, les corrélations, les vérifications de fuite et l'équivalence entraînement/service	pipeline de caractéristiques, fuite, entraînement, artefacts
MLE-05	Ajuster les seuils, configurations et la complexité du modèle sous contraintes de compromis	eval-harness, ai-regression-testing, quality-gate, test-coverage	Rapport seuil/config comparant précision, rappel, F1, AUC, calibration, tranches de groupe, latence, coût, complexité et 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 regroupement d'erreurs pour faux positifs, faux négatifs, étiquettes ambiguës, caractéristiques obsolètes, signaux manquants et traces de bugs avec leçons apprises	analyse d'erreur, trace de bug, itération, régression
MLE-07	Empaqueter un artefact de modèle pour l'inférence par lots ou en ligne	api-design, backend-patterns, security-review, security-scan	Paquet 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	Livrer un service en ligne ou un scoring par lots avec capture de feedback	api-design, backend-patterns, e2e-testing, browser-qa, accessibility	Point de terminaison de prédiction ou job par lots avec enveloppe de réponse, timeout, batch, repli, version de modèle, confiance, journalisation de feedback et tests de flux produit	service, inférence par lots, repli, workflow utilisateur
MLE-09	Déployer un modèle avec trafic fantôme, canari, test A/B ou rollback	canary-watch, dashboard-builder, verification-loop, performance-optimizer	Plan de déploiement nommant la répartition du trafic, tableaux de bord, latence p95, coût, garde-fous de qualité, artefact de rollback et déclencheur de rollback	déploiement, canari, rollback
MLE-10	Exploiter, déboguer et mettre à jour 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 de mise à jour avec vérifications de dérive, santé des étiquettes différées, propriétaires d'alertes, mises à jour des runbooks, 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, compressez le travail en un 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 se soucie :
Décideur :
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 :
Rollback ou repli :

Ce compact est l'équivalent MLE d'une bonne note de conception SWE. Il empêche l'équipe d'optimiser une métrique que personne ne fie, d'ajouter des caractéristiques qui ne corrigent pas le vrai mode d'erreur, ou de livrer de la complexité sans rollback.

Cerveau de décision

Utilisez cette boucle chaque fois que la tâche est ambiguë, à fort impact ou lourde en métriques :

1. Commencez par la décision, pas par le modèle. Nommez l'action qui modifie le comportement aval.
2. Nommez qui se 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 simple baseline devrait être difficile à battre.
4. Recherchez l'art antérieur ou un problème connu proche avant d'inventer un système sur mesure.
5. Évaluez les choix avec (probabilité, confiance) x (coût, gravité, importance, impact).
6. Considérez le comportement adverse, 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, la preuve, 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 d'échec, pas par habitude :

• Utilisez une matrice de confusion tôt pour que l'équipe puisse discuter de faux positifs et faux négatifs concrets au lieu 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 F1 uniquement lorsque le compromis précision/rappel est véritablement équilibré et explicable.
• Utilisez AUC ou des métriques de classement lorsque la qualité de l'ordre importe plus 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é de modèle réalisable.
• Comparez-vous à 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 un biais, un retard et des lacunes de couverture ; ne les traitez pas comme une vérité de 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 en absorbe le coût.

Hypothèses sur les données et les caractéristiques

Les caractéristiques doivent découler d'une théorie de 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 candidates, pas des caractéristiques automatiques.
• Pour chaque famille de caractéristiques, énoncez pourquoi elle devrait séparer les résultats et comment elle pourrait fuiter des informations futures.
• Pour les étiquettes bruitées, envisagez une adjudication, une confiance d'étiquette, des cibles douces ou une 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 outliers, décidez de les couper, les regrouper, les étudier, ou les conserver comme signal rare mais important.
• Pour les caractéristiques corrélées, vérifiez si elles sont redondantes, instables ou des proxys 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, cycle d'entraînement, changement de seuil ou changement de configuration :

1. Répartissez les erreurs en faux positifs, faux négatifs, abstentions, cas de faible confiance et défaillances système.
2. Regroupez les erreurs par traits partagés : langue, type d'entité, source, temps, géographie, appareil, rareté, récence, fraîcheur de caractéristique, source d'étiquette ou version de modèle.
3. Séparez les erreurs du modèle des bugs de données. Une erreur de modèle donne une prochaine expérience ; un bug de données donne un correctif et un test de régression.
4. Tracez chaque cluster d'erreur vers son coût pour une partie prenante spécifique. Si aucun acteur humain n'en souffre, il peut ne pas nécessiter d'action.
5. Priorisez les clusters par fréquence, sévérité du coût et probabilité qu'une meilleure caractéristique, un meilleur seuil ou plus de données les résolve.
6. Transformez un cluster d'erreur en une expérience falsifiable avec un résultat mesurable, un gain attendu et un résultat nul acceptable.

Conception de l'évaluation

Concevez l'évaluation pour juger le modèle là où il sera utilisé :

• Évaluez sur les données de production réelles, pas seulement sur les splits hors ligne. Le décalage par rapport à la distribution de production efface les gains hors ligne.
• Validez sur la distribution de trafic que le modèle recevra réellement après le déploiement, en tenant compte de la sélection de la population.
• Testez la cohérence des schémas et des transformations entre l'entraînement, l'évaluation hors ligne et le service en ligne. Les désaccords sont une source majeure de dégradation silencieuse.
• Mesurez les métriques sur des sous-groupes définis, pas seulement sur des moyennes globales. La « grande précision moyenne » masque les tranches qui échouent presque tout le temps.
• Prévoyez la latence et le coût comme des contraintes dures lors des évaluations hors ligne. Un modèle qui ne peut pas être servi dans le budget de latence ou de coût n'est pas un modèle gagnant.
• Validez le comportement de repli. Savoir quand s'abstenir est une caractéristique, pas un bug. Documentez et testez les règles d'abstention.
• Exécutez l'évaluation dans un environnement qui ressemble à la production : mêmes contraintes de mémoire, de réseau, de concurrence et de dépendances.
• Vérifiez la dérive de données entre les jeux d'entraînement et de production comme une vérification obligatoire, pas une réflexion après coup.

Économie des artefacts

Les artefacts de modèle sont des dépendances de production versionnées avec la même gravité que les bibliothèques partagées :

• Enregistrez les artefacts avec un hachage de contenu, une configuration d'entraînement, un lien vers le jeu de données d'entraînement et un manifeste de dépendance.
• Chargez les artefacts en lecture seule, avec des contrôles d'intégrité de schéma à l'exécution et une isolation de version explicite dans les chemins de service.
• Incluez un artefact de rollback chaque fois que vous déployez un nouveau modèle. Le plan de déploiement doit indiquer ce qui déclenche le rollback et où se trouve l'artefact de repli.
• Ne faites pas confiance aux blobs sérialisés. Validez le schéma, les métadonnées et la compatibilité des dépendances au chargement pour détecter des artefacts corrompus ou obsolètes avant qu'ils ne causent une panne.
• Enregistrez chaque version d'artefact dans un journal immuable avec un horodatage, un commit source, des métriques d'évaluation et un propriétaire. Ne supprimez jamais d'artefacts déployés.

Conception du service

Concevez le service d'inférence avant le déploiement, en anticipant l'échec :

• Définissez l'enveloppe de réponse de l'API avec le nom du modèle, la version, le score, la confiance, les avertissements, la caractéristique de repli activée, le temps de traitement et les champs spécifiques au domaine en texte brut ou structuré.
• Implémentez des délais d'attente, la mise en lot, le regroupement de requêtes et la limitation de débit comme des fonctionnalités de base, pas des réflexions après coup.
• Diffusez les prédictions à un magasin de journaux structuré étiqueté par modèle, version, horodatage et partition de trafic pour une analyse différée.
• Diffusez les retours (actions utilisateur réelles) au même magasin de journaux avec une clé de corrélation qui lie la prédiction au résultat observé.
• Gérez les montées de trafic, les caractéristiques manquantes et les pannes en aval sans planter. La prédiction de repli en cas d'incertitude est un comportement documenté.
• Testez le chemin de service sous charge avant le déploiement avec un volume proche de la production.

Conception du déploiement et du rollback

Déployez comme si vous alliez certainement devoir revenir en arrière :

• Chaque déploiement de modèle nécessite un plan de déploiement nommant la répartition du trafic, les tableaux de bord de surveillance, la période d'observation et les conditions de rollback.
• Utilisez le trafic fantôme, le canari ou les tests A/B pour réduire l'exposition initiale tout en collectant des métriques de qualité en ligne.
• Exigez des preuves automatisées que le nouveau modèle respecte les seuils de qualité sur les données de production avant de promouvoir le canari.
• Liez le déclencheur de rollback à des métriques opérationnelles (latence p95, utilisation mémoire) et à des métriques de qualité (baisse de précision, augmentation du taux de repli). Un changement doit être inversé automatiquement ou via un seul bouton.
• Conservez l'artefact de rollback dans le même inventaire déployable que le nouveau modèle. Le chemin de rollback doit être testé avant le déploiement.

Surveillance et réponse aux incidents

Surveillez les modèles en production comme s'ils étaient vivants et imprévisibles :

• Mesurez la dérive de distribution des caractéristiques d'entrée, la fraîcheur des étiquettes et l'intégrité des prédictions par rapport aux schémas connus.
• Enregistrez chaque prédiction, caractéristique d'entrée, version de modèle et partition de trafic pour les analyses post-hoc et les enquêtes sur les incidents.
• Collectez les retours différés (étiquettes réelles) dès qu'ils deviennent disponibles. Comparez les résultats différés avec les prédictions hors ligne et en ligne.
• Mettez en œuvre des alertes sur la dérive des prédictions, la chute de confiance, les taux de repli, la latence, le coût et le volume. Chaque alerte doit avoir un propriétaire et un runbook.
• Exécutez des exercices de rollback comme vous exécutez des exercices d'incendie. La capacité à rollback rapidement est plus importante que la capacité à lancer parfaitement du premier coup.
• Conservez un journal d'observation : ce qui a changé, pourquoi, quel était le résultat attendu, quel était le résultat réel, et ce qui a été appris.

Contrats de données

Formalisez les contrats de données avant l'implémentation du modèle :

• Définissez la granularité de l'entité (utilisateur, élément, session, événement) et comment les entités sont liées dans le temps.
• Définissez le timing des étiquettes : quand les étiquettes deviennent disponibles, comment les différés sont gérés et ce qui constitue une vérité de terrain provisoire vs confirmée.
• Définissez le timing des caractéristiques : quelles caractéristiques sont disponibles au moment de la prédiction, quelles caractéristiques sont calculées après coup (fuite) et comment les jointures point-in-time sont appliquées.
• Définissez la politique de partitionnement : quelle est l'unité de partitionnement (par exemple, horodatage, ID utilisateur), comment les lignes sont affectées à l'entraînement, à la validation et au test, et comment la fuite est empêchée entre les ensembles.
• Versionnez les instantanés de données afin que chaque cycle d'entraînement corresponde à un ensemble de données reproductible, pas à un état variable de la base de données de production.

Itération orientée par les coûts

Faites un compromis explicite sur ce qui vaut le coup d'être optimisé :

• Chaque caractéristique, expérience et changement de configuration a un coût : temps d'ingénierie, latence, coût de calcul, complexité de la base de code et dette d'inférence future. Faites un compromis explicite.
• Préférez les changements qui éliminent des classes d'erreurs entières plutôt que ceux qui déplacent lentement la moyenne d'une métrique. Un correctif qui supprime tous les faux positifs pour une tranche vaut plus qu'une amélioration de 0,01 de AUC.
• Réduisez le coût des erreurs inacceptables à zéro même si cela augmente les erreurs acceptables. La pire erreur est celle que vous avez dit ne jamais se produire.
• Terminez par une observation. Si l'expérience n'a pas réduit le coût de l'erreur d'un montant mesurable, ne l'industrialisez pas ; supprimez-la ou notez pourquoi réessayer plus tard.

Enregistrez la prochaine expérience avant de passer à une nouvelle tâche. Un lien vers le résultat d'une expérience qui pourrait fonctionner est plus utile qu'un brouillon de PR pour une fonctionnalité qui ne corrige pas la bonne erreur.

Rappel des modes de défaillance do not

Ces modes de défaillance doivent déclencher une révision explicite avant de continuer :

• Ne faites pas d'optimisation de seuil sur les données de test. Validez les seuils sur une période de validation distincte.
• Ne faites pas de sélection de caractéristiques basée sur la performance d'un ensemble de test unique. Utilisez la validation croisée ou des ensembles de validation répétés.
• Ne faites pas de normalisation ou de transformation qui dépend de statistiques globales de l'ensemble d'entraînement sans les enregistrer comme partie de l'artefact du modèle.
• Ne faites pas de boucle de retour où les prédictions du modèle influencent les futures étiquettes d'entraînement sans un décalage, une randomisation ou une correction de biais.
• Ne faites pas d'ingénierie de caractéristiques qui utilise des informations indisponibles au moment de la prédiction. Validez avec l'équipe de service de production.
• Ne faites pas de suivi d'expériences uniquement sur les métriques hors ligne. Validez que les gains hors ligne se généralisent aux données de production.
• Ne déployez pas un modèle sans un artefact de rollback vérifié et un plan de déploiement documentant le déclencheur et la procédure de rollback.

Intégration avec cognition et dmux-workflows

• En phase d'investigation : search-first suivi de repo-scan ou code-tour pour localiser les chemins ML existants
• Avant d'écrire du code de modèle : product-capability pour cadrer le travail, puis plan pour le structurer en phases
• À chaque porte de promotion : eval-harness ou ai-regression-testing comme vérification automatisée
• Pour le partage de contexte et le pairing : strategic-compact suivi de dmux-workflows pour diviser le travail en flux parallèles
• En phase d'incident ou de dégradation silencieuse : silent-failure-hunter pour tracer le serveur aux caractéristiques en passant par la version du modèle

Architecture de mémoire du système

Ce skill interagit avec la mémoire du système comme suit :

Type	Utilisation
Plan de tâche en cours	Stocke le compact d'itération courant, la porte de promotion active et l'état de rollback
Référence de projet	Artefacts passés, journaux d'évaluation et journaux d'observation pour référence
Connaissances du domaine	Contrats de données, hypothèses de caractéristiques et liens d'art antérieur

Modes de défaillance et garde-fous

Mode de défaillance	Déclencheur	Garde-fou
Fuite de données	Caractéristique utilisant des informations futures	Politique de partitionnement qui interdit l'utilisation de données post-timestamp de l'étiquette
Dérive de caractéristiques	Distribution de caractéristiques diffère entre entraînement et service	Vérification de dérive comme porte obligatoire avant le déploiement
Incohérence de l'artefact	Artefact enregistré diffère du code d'entraînement	Hachage de contenu et validation de schéma à chaque charge de l'artefact
Inflation de métriques hors ligne	Métriques hors ligne ne se généralisant pas à la production	Évaluation sur les données de production comme porte de promotion
Dégradation silencieuse	Changement de performances non détecté avant qu'il n'affecte les utilisateurs	Surveillance en ligne avec seuils d'alerte et boucle de rollback
Coût d'inférence imprévu	Taille du modèle ou complexité de l'inférence dépasse le budget	Budget de latence et de coût comme contrainte d'évaluation dure

Vue d'ensemble des commandes principales

Ce skill n'introduit pas de nouvelles commandes. Au lieu de cela, il mappe chaque activité ML à des surfaces SWE ECC existantes. La section « Réutiliser la surface SWE » ci-dessus est la table de correspondance principale pour ce mappage.

Le comportement de l'agent est modifié comme suit :

• plan doit inclure les phases de contrat de données, d'évaluation, de service et de surveillance
• code-reviewer doit vérifier la fuite, la reproductibilité, la promotion et les risques de surveillance en plus de la qualité du code
• quality-gate doit exiger des preuves automatisées pour les portes de promotion du modèle, pas seulement la couverture de test de code
• silent-failure-hunter doit tracer les dégradations en ligne jusqu'aux artefacts de modèle et aux versions de caractéristiques
• dashboard-builder doit inclure des panneaux de dérive, de version de modèle, de latence et d'étiquette différée