@ml-pipeline-architectPipeline ML production : data, training, deploy, drift
Maifady est un plugin Claude Code 100% gratuit avec 30 agents IA — @ml-pipeline-architect design ta pipeline ML production stage par stage : ingestion → features → training → eval (avec slice analysis) → deploy (shadow → canary → full) → inference → monitoring drift. Et il flag les anti-patterns MLOps qui font péter les modèles en prod.
Le problème qu'il résout
Tu as un modèle XGBoost qui marche bien en notebook. Tu veux le mettre en prod pour faire de la prédiction churn quotidienne. Mais tu n'as jamais fait de MLOps : tu ne sais pas comment versionner les modèles, comment monitorer la drift, comment rollback si le nouveau modèle est moins bon.
@ml-pipeline-architect te donne l'architecture stage par stage, avec stack technique recommandée selon ton niveau de complexité.
Comment il bosse
- Tu décris : volume, batch vs online, données source, équipe, cloud, contraintes.
- Il propose architecture par stage : ingestion (schema validation, freshness SLA), features (store ou compute), training (reproducible, seeds, deps pinned), eval (offline + slice analysis), deploy (shadow → canary → full), inference (batch/online/streaming), monitoring (data drift, prediction drift, performance).
- Choix critiques : batch vs online, feature store oui/non, model registry, retraining cadence.
- Anti-patterns flaggés : training-serving skew, no versioning, no rollback plan, notebook in production, wrong metric.
Exemple concret
Tu tapes
›@ml-pipeline-architect architecture XGBoost pour churn : - 50k clients, inférence batch quotidienne - Données Postgres - Cloud AWS - Équipe : 1 DS + 2 backend devs (zéro MLOps)
Tu obtiens
Architecture stage par stage : ingestion (Airflow daily, schema check), features (compute-on-fly pour démarrer, feature store quand 3+ modèles), training (SageMaker training jobs, MLflow tracking), eval (AUC + slice per cohort), deploy (shadow → canary 10% → 100%), inference (batch quotidien, prédictions en S3 puis Postgres), monitoring (data drift via KS test hebdo, AUC tracking, business metric retention). Plus 3 risques #1 : training-serving skew (utiliser le même feature code), no rollback plan, no drift detection.
Pourquoi tu vas l'aimer
Stage par stage
Pas un blob "fais du MLOps". Chaque stage a un choix justifié et une stack recommandée.
Monitoring drift
Data drift (input change), prediction drift (output change), performance drift (perte d'accuracy). Les 3 incluses.
Rollback obligatoire
Garde toujours N-1 deployable. Si v2 misbehaves, retour à v1 en 1 minute.
Anti-patterns flaggés
Training-serving skew, notebook en prod, optim du mauvais metric — détectés et évités.
Quand l'utiliser
✅ Idéal pour
- Premier modèle ML en prod
- Audit d'une pipeline existante
- Migration de modèle batch vers online
- Scaling : 1 modèle → 5+ modèles (besoin feature store)
⚠️ Pas adapté quand
- Pure prompting LLM → @prompt-engineer
- Notebook one-shot pour exploration — pas besoin de MLOps
Combine avec ces agents
Questions fréquentes
Feature store oui ou non ?
Oui si : plusieurs modèles partagent des features, offline/online parity importante, équipe > 5 ML engineers. Sinon : compute-on-fly avec le même code train/serve.
Quelle fréquence de retraining ?
Selon drift : monthly par défaut pour churn, weekly si données changent vite, trigger-based si drift monitoring en place. Online learning seulement pour cas spécifiques (très complexe à debug).