📖 Manuel

ML Experiment Tracker

Guide complet pour le suivi structuré d'expériences de machine learning, le versioning de modèles et la comparaison systématique des métriques.

Workflow

1. Choisir et configurer la plateforme de tracking

• Évaluer les options disponibles : MLflow (open-source, auto-hébergé), Weights & Biases (SaaS), Neptune, ClearML
• Installer et configurer le serveur de tracking (MLflow Tracking Server, W&B workspace)
• Définir la structure des projets et des espaces de travail
• Configurer l'authentification et les droits d'accès pour l'équipe
• Intégrer le tracking dans le pipeline CI/CD existant

2. Structurer les expériences

• Définir une convention de nommage claire pour les expériences (projet/tâche/variante)
• Organiser les runs par groupes logiques (exploration, ablation, production)
• Créer des tags standardisés pour faciliter le filtrage (dataset_version, model_type, technique)
• Définir les métadonnées obligatoires à enregistrer pour chaque run
• Documenter l'objectif et l'hypothèse de chaque expérience avant de la lancer

3. Logger les paramètres et hyperparamètres

• Enregistrer automatiquement tous les hyperparamètres (learning rate, batch size, epochs, architecture)
• Logger la configuration complète du modèle (nombre de couches, dimensions, activation)
• Capturer les paramètres du dataset (version, taille, splits, prétraitement appliqué)
• Enregistrer l'environnement d'exécution (GPU, RAM, versions des librairies, seed)
• Utiliser le logging automatique quand disponible (mlflow.autolog(), wandb.watch())

4. Suivre les métriques en temps réel

• Définir les métriques principales (loss, accuracy, F1, BLEU, etc.) et secondaires
• Logger les métriques à chaque step/epoch pour visualiser les courbes d'apprentissage
• Configurer des alertes sur les métriques anormales (divergence, NaN, plateau)
• Enregistrer les métriques de ressources (utilisation GPU, mémoire, temps d'entraînement)
• Logger les métriques custom spécifiques au domaine métier

5. Versionner les artefacts

• Sauvegarder les checkpoints du modèle avec leurs métriques associées
• Versionner les datasets utilisés (lien vers DVC, hash du fichier)
• Stocker les fichiers de configuration et les scripts d'entraînement
• Enregistrer les graphiques et visualisations (courbes ROC, matrices de confusion, samples de prédictions)
• Archiver les logs d'entraînement complets pour le débogage

6. Comparer et analyser les résultats

• Utiliser les tableaux comparatifs pour mettre en regard les runs
• Créer des visualisations parallèles (parallel coordinates, scatter plots)
• Identifier les hyperparamètres ayant le plus d'impact (importance analysis)
• Documenter les conclusions et les insights tirés de chaque comparaison
• Générer des rapports automatiques pour les revues d'expériences

7. Gérer le Model Registry

• Promouvoir les meilleurs modèles dans le registry avec un statut (staging, production, archived)
• Associer chaque version du modèle à son run d'entraînement complet
• Documenter les changements entre versions (model card, changelog)
• Configurer des validations automatiques avant la promotion en production
• Maintenir un historique complet des modèles déployés

8. Automatiser et industrialiser

• Créer des templates de runs pour standardiser les nouvelles expériences
• Mettre en place des sweeps/grid search automatisés avec logging intégré
• Configurer des pipelines de réentraînement automatique avec tracking
• Intégrer le tracking dans les notebooks Jupyter pour l'exploration
• Former l'équipe aux bonnes pratiques de tracking

Rules

1. Logger avant de lancer : Configurer le tracking complet avant de démarrer l'entraînement. Un run sans logs est un run perdu. Il est impossible de recréer les conditions exactes d'une expérience après coup.

1. Un run = une configuration : Chaque modification d'hyperparamètre, de dataset ou de code doit correspondre à un nouveau run. Ne jamais écraser un run existant, même en cas d'erreur.

1. Métriques reproductibles : Toujours fixer et enregistrer le random seed, la version exacte des librairies et le hash du code. Deux runs avec les mêmes paramètres doivent produire des résultats identiques (ou quasi-identiques sur GPU).

1. Nommer et taguer systématiquement : Un run sans nom descriptif ni tags est inutilisable pour la comparaison future. Appliquer la convention de nommage de l'équipe sans exception.

1. Nettoyer régulièrement : Archiver ou supprimer les runs exploratoires obsolètes. Un espace de tracking encombré ralentit la recherche et masque les résultats importants.