Tenir un journal d'expériences utile pour votre premier projet d'IA

Voici une expérience courante en IA appliquée : vous lancez une expérience, obtenez un bon résultat, changez quelque chose, obtenez un moins bon résultat, et des semaines plus tard vous ne pouvez plus reconstruire ce qui a produit le bon résultat initial. Le modèle qui a obtenu 0,87 a disparu, remplacé par un modèle qui obtient 0,83, et vous n'avez aucun registre de ce qui différait. Ce n'est pas un problème de mémoire — c'est un problème de journalisation. Un journal d'expériences utile est une habitude peu coûteuse et à fort levier, et peu de gens en commencent un assez tôt.

Ce que doit contenir une entrée d'expérience

Chaque expérience est une ligne dans votre journal. Les champs minimum utiles sont : un nom ou numéro d'exécution unique, la date, la question à laquelle vous tentiez de répondre, le modèle exact et les hyperparamètres, le découpage des données utilisé (y compris les identifiants de découpage et les graines aléatoires), le prétraitement appliqué, les métriques sur la validation, et une note d'une ligne sur ce que vous avez appris. Incluez des références aux versions des données et du code, à l'environnement et à tout chemin d'artéfact pour qu'une exécution puisse être reproduite. Le champ « question » est celui que la plupart des gens omettent et celui qui compte le plus — il vous force à énoncer, avant de lancer, ce que vous espérez apprendre. « L'ajout des abonnés de l'artiste comme variable améliore-t-il la prédiction d'écoutes sur 14 jours ? » est une vraie expérience ; « essayer random forest » n'en est pas une. Pendant l'itération, journalisez les métriques de validation ; réservez l'ensemble de test à une seule évaluation finale, pas à chaque ligne.

Un exemple concret : une comparaison contrôlée

Imaginez un journal tenu dans un simple tableur. Ligne 1 : run-001, question « modèle de référence », modèle classe majoritaire, découpage 800/200, précision validation 80 %, note « modèle de référence à battre ». Ligne 2 : run-002, question « le tempo aide-t-il », modèle régression logistique avec tempo ajouté, même découpage et même graine, précision validation 81 %, note « le tempo ajoute un point ». Ligne 3 : run-003, question « le genre aide-t-il », même régression logistique avec genre one-hot ajouté, même découpage et même graine, précision validation 83 %, note « le genre ajoute deux points de plus ». Ligne 4 : run-004, question « une forêt aléatoire plus grande bat-elle la régression logistique », modèle forêt aléatoire 200 arbres, même découpage et même graine, précision validation 82,5 %, note « forêt légèrement pire ; plus de complexité, aucun gain — garder la régression logistique ». La clé est que chaque ligne change une seule chose dans la même famille de modèles, pour que le gain puisse être attribué à ce changement — encore faut-il décrire les différences observées en gardant en tête l'incertitude d'échantillonnage et de graine, car les petits écarts peuvent être du bruit. Gardez l'évaluation finale sur le test séparée de cette illustration 800/200 entraînement/validation. Quatre lignes, et l'histoire du projet est lisible des semaines plus tard : quelles variables ont aidé, quel modèle n'a pas aidé, et pourquoi.

Les erreurs courantes qui rendent les journaux inutiles

Une erreur est de ne journaliser que les réussites. Un journal sans les échecs ne peut pas vous apprendre ce qui ne fonctionne pas, ce qui est l'essentiel de ce qu'il vous faut savoir. Une autre est de journaliser les métriques sans la configuration : « précision 0,86 » signifie peu si vous n'avez pas enregistré quelles variables et quels hyperparamètres l'ont produite. Une troisième est de changer plus d'une chose entre les exécutions — si vous ajoutez le genre et changez de modèle simultanément et que le score bouge, vous ne pouvez pas dire quel changement en est la cause. La discipline d'un seul changement par exécution est ce qui rend un journal interprétable. Une quatrième est de compter sur la mémoire ou des cellules de carnet éparses plutôt que sur un registre unique et durable ; les carnets servent à l'exploration, pas à la mémoire. Enfin, ne journalisez pas de dossiers privés, de données personnelles ou de secrets dans un journal que vous comptez partager — limitez le journal à la configuration reproductible et aux métriques agrégées seulement.

Un exercice : journalisez vos trois prochaines exécutions

Avant vos trois prochaines expériences, notez la question, le changement unique que vous faites, et votre prédiction de ce qui va se passer. Après chaque exécution, enregistrez les métriques de validation réelles et si votre prédiction s'est vérifiée. La colonne prédiction est l'ingrédient secret : elle transforme le journal d'archive passif en outil actif pour calibrer votre propre intuition de ce qui fonctionne. Vous remarquerez rapidement quels types de changements vous surestimez ou sous-estimez systématiquement, ce qui est en soi un résultat précieux.

Outils contre discipline

Il existe de bons outils de suivi d'expériences, qui valent la peine d'être adoptés à mesure que les projets grandissent. Mais la valeur vient de la discipline de l'enregistrement, pas de l'outil. Un tableur tenu fidèlement bat un système de suivi sophistiqué utilisé de façon incohérente. Commencez par le format le plus simple qui capture les champs ci-dessus, et ne passez à un outil plus lourd que lorsque le tableur devient pénible à maintenir. Pour une vue plus large des pratiques de recherche reproductible, la documentation officielle de scikit-learn sur la validation croisée est une référence utile sur la façon dont l'évaluation devrait être structurée (scikit-learn : validation croisée).

Votre prochaine étape

Un journal d'expériences transforme une pile d'exécutions en une histoire lisible ; l'habitude suivante qui se combine avec lui est de versionner vos données et votre code ensemble, pour que chaque entrée pointe vers un état exact et reproductible. C'est le sujet d'un article ultérieur de cette série. Pour le parcours d'apprentissage structuré auquel ces habitudes appartiennent, voir les aperçus du programme d'IA appliquée ou le programme d'analyse de données.