Reproductibilité d'une expérience d'apprentissage automatique : graines, environnement, données et limites du déterminisme

Objectif

Rendre une exécution d'entraînement reproductible par une autre personne ou un autre agent, un autre jour, avec la même métrique là où la plateforme le permet, et rendre explicite chaque source de variation restante.

Prérequis

Un état de code figé (commit), un jeu de données avec une somme de contrôle ou un identifiant de version, et un fichier de verrouillage des dépendances pour l'environnement d'entraînement.

Étapes

1. Supprimer tout état aléatoire implicite. La page des pièges de scikit-learn indique que des résultats reproductibles d'une exécution à l'autre exigent de supprimer tout usage du random_state=None par défaut, et recommande de déclarer un seul état aléatoire en tête du programme et de le transmettre à chaque estimateur et à chaque découpeur ; elle déconseille de fixer la graine globale de NumPy. Pour le code NumPy, créer un Generator avec default_rng(seed), que la référence NumPy désigne comme le constructeur recommandé, et le transmettre de la même façon plutôt que d'appeler des fonctions aléatoires au niveau du module.
2. Pour les frameworks d'apprentissage profond, fixer la graine du générateur du framework (torch.manual_seed) et activer les algorithmes déterministes lorsqu'ils sont proposés. La note de PyTorch sur la reproductibilité indique que des résultats totalement reproductibles ne sont pas garantis d'une version, d'un commit ou d'une plateforme à l'autre, que les résultats CPU et GPU peuvent différer sous des graines identiques, et que les opérations déterministes sont souvent plus lentes ; consigner lesquels de ces réglages ont été utilisés.
3. Fixer les données : consigner la somme de contrôle du jeu de données et l'identifiant du découpage, et charger les lignes dans un ordre défini (trier par une clé stable avant de découper).
4. Figer l'environnement : fichier de verrouillage, version de Python, classe de matériel et, pour les GPU, versions du pilote et des bibliothèques ; construire une image de conteneur si l'environnement doit survivre à la machine.
5. Écrire la configuration (tous les hyperparamètres, graines, chemins, versions) dans un seul fichier que l'exécution lit et copie dans son répertoire de sortie.
6. Relancer l'expérience deux fois à partir d'un extrait propre (clean checkout) sur la même machine, et une fois sur une machine différente ; consigner si la métrique correspondait exactement, dans une tolérance, ou pas du tout, et quelle étape explique un éventuel écart.
7. Stocker les résultats avec la configuration et le commit de code ; rapporter la variation entre graines comme un intervalle plutôt que comme le chiffre d'une seule graine.

Résultat attendu

Un répertoire d'exécution qui contient tout le nécessaire pour répéter l'exécution, un énoncé de la façon exacte dont elle se répète, et des métriques comparables d'une exécution à l'autre parce que les graines et les données sont les mêmes.

Limites et base de vérification

Le déterminisme peut coûter en vitesse et n'est pas forcément disponible pour toutes les opérations. La documentation citée ne promet pas de reproductibilité bit à bit entre matériels différents. Le protocole est une proposition ; aucun taux de reproductibilité n'est revendiqué.