Retrouver la preuve derrière chaque résultat.

Distinguer campagne, configuration et exécution

Une campagne porte une question, par exemple comparer une référence à une adaptation. Une configuration décrit les choix techniques. Un run est une tentative d’exécution de cette configuration, avec une graine, un début, une fin et un statut. Deux tentatives identiques gardent donc deux identifiants, même si la seconde remplace un essai interrompu.

Ajoutez un identifiant d’évaluation lorsque le même artefact est évalué sur plusieurs jeux ou avec une nouvelle métrique. Cela évite de confondre un nouveau modèle avec une nouvelle lecture du modèle existant. Reliez la tentative de reprise à celle qui l’a précédée et au checkpoint chargé.

MLflow organise également le suivi autour des runs, paramètres, métriques et artefacts. Cette distinction est utile même dans un dossier de fichiers simple. Vous pouvez l’appliquer avec votre outil habituel ; aucune plateforme de suivi particulière n’est nécessaire pour commencer.

Sources techniques : MLflow — runs, paramètres, métriques et artefacts

Écrire le manifeste réellement exécuté

Conservez les paramètres résolus après application des valeurs par défaut et des arguments de lancement. Le fichier de configuration d’origine peut omettre un batch par défaut ou une option modifiée à l’exécution. Enregistrez ce qui a été effectivement utilisé, avec une copie du code ou une révision immuable et l’état des modifications non enregistrées.

Le manifeste relie aussi versions du modèle et du tokenizer, environnement logiciel, GPU effectivement utilisé, précision, données, seeds et définition des métriques. Il décrit l’essai, sans devenir un tutoriel d’installation. Inscrivez les unités : secondes, octets, tokens, points ou proportion sur 0 à 1 selon la mesure.

Au démarrage, le statut est en cours ; à la fin, il devient terminé, échoué ou interrompu selon ce que vous avez constaté. Ne complétez pas après coup une version oubliée par celle actuellement installée. Marquez l’information inconnue et limitez la conclusion qui en dépend.

Identifier les données au-delà d’un nom de dossier

Un chemin comme donnees/final ne désigne pas une version stable. Conservez l’inventaire des fichiers ou des exemples, les splits et la procédure de transformation. Si vous corrigez des labels ou filtrez des lignes, créez une nouvelle version et gardez la relation avec la précédente. Le score ancien doit continuer à pointer vers ses données anciennes.

Hugging Face Datasets associe des fingerprints à l’état d’un jeu et à ses transformations pour gérer le cache. Ce mécanisme est utile, mais il faut conserver aussi l’origine des données et le prétraitement. Une transformation non hachable peut notamment conduire à un fingerprint aléatoire : l’identifiant de cache ne remplace pas à lui seul votre dossier de provenance.

Pour les artefacts figés, ajoutez taille et empreinte de fichier. Un digest SHA-256 calculé avant et après une copie permet de vérifier que les octets correspondent à la référence conservée. Il ne prouve ni la qualité des labels, ni les droits d’usage, ni l’absence de fuite entre les splits.

Sources techniques : Hugging Face Datasets — fingerprints et transformations · Python 3.14 — empreintes de fichiers avec hashlib

Relier métriques, prédictions et artefacts

Une ligne de métrique devrait identifier le run, l’artefact évalué, le jeu d’évaluation, la version de la métrique et son périmètre. Précisez si la valeur concerne un checkpoint intermédiaire, le modèle final ou un sous-groupe. Une courbe ne suffit pas si l’on ne sait plus quel fichier correspond au point retenu.

Conservez les prédictions avec leur identifiant d’entrée, leur statut et les informations nécessaires à l’évaluation. Les références attendues peuvent rester dans un fichier séparé versionné. Pour une sortie structurée, distinguez résultat brut, résultat parsé et verdict : corriger le parsing ne doit pas écraser la sortie initiale.

MLflow permet de relier des métriques à des modèles et à des données. Avec des fichiers, appliquez le même principe par des identifiants explicites. Gardez un inventaire lisible des artefacts : poids ou adaptateur, paramètres de génération, sorties, rapport d’évaluation et note de décision. Ne supposez pas qu’une capture d’écran remplace ces fichiers.

Sources techniques : MLflow — relier métriques, modèles et jeux de données

Exemple : six runs et un doublon qui cache un manque

Considérons un exemple de classement à deux configurations et trois graines. Il produit six runs prévus. Chacun doit prédire les mêmes 300 identifiants d’évaluation : le dossier complet attend donc 6 × 300 = 1 800 couples uniques (run_id, input_id). Ce calcul décrit un inventaire attendu, pas une expérience réellement exécutée.

Supposons qu’un fichier contienne 300 lignes, mais que l’identifiant doc-042 soit présent deux fois et doc-117 absent. Le total des lignes paraît correct ; il n’y a pourtant que 299 identifiants uniques. Ce run échoue au contrôle de couverture jusqu’à ce que l’anomalie soit expliquée et corrigée.

Si chaque run est ensuite évalué sur le corpus complet et sur son sous-groupe de textes longs, vous obtenez douze lignes de métrique pour une métrique donnée. Cela reste six runs, pas douze entraînements indépendants. La clé d’évaluation doit inclure le périmètre pour conserver cette distinction.

Fermer le dossier avec une décision lisible

Avant de déclarer un run terminé, contrôlez présence et ouverture des fichiers, correspondance des identifiants, métriques recalculables et statut de chaque erreur. Une tentative techniquement terminée peut rester rejetée pour qualité insuffisante. Gardez ces deux états séparés.

La note de décision rassemble la question, les variantes comparées, le critère annoncé, les résultats retenus et les raisons d’exclusion. Citez les run_id et les chemins d’artefacts plutôt que « le dernier modèle ». Ajoutez les limites : peu de répétitions, sous-groupe insuffisant, version non retrouvée ou comparaison devenue impossible.

Une correction ultérieure doit laisser une trace : nouvelle évaluation, nouveau rapport et raison du changement. Conservez l’ancienne conclusion comme version historique identifiée, sans la laisser apparaître comme décision actuelle. Vérifiez enfin que la copie exportée s’ouvre depuis son dossier de destination.

Éviter la collecte inutile et les promesses de reproduction

Collectez les champs nécessaires à la preuve, pas toutes les variables d’environnement ni l’historique du terminal. Une configuration ou une URL peut contenir un jeton ; préparez une version partageable sans secrets et gardez les données qui doivent rester privées dans leur emplacement autorisé. Les identifiants techniques d’essai n’ont pas besoin d’inclure un nom de personne.

Un dossier complet améliore la possibilité de refaire et comprendre une expérience. Il ne garantit pas une égalité numérique entre plateformes ou versions : PyTorch documente ces limites de reproductibilité. Distinguez retrouver le protocole, recharger l’artefact et reproduire exactement les nombres.

Le carnet IteraGPU peut conserver vos objectifs, paramètres et décisions, avec les références utiles. Il ne lance pas les runs ni ne collecte automatiquement les fichiers ou la télémétrie. Utilisez-le comme index de votre raisonnement et conservez le dossier d’artefacts dans vos propres sauvegardes.

Sources techniques : PyTorch 2.14 — limites de reproductibilité entre environnements

Questions pratiques