Machine Learning : Comment structurer et suivre ses expérimentations ? (Méthode & Craft)

Développer un modèle de machine learning, c’est rarement un coup de chance. C’est souvent une longue série d’expérimentations, d’ajustements, de retours en arrière — jusqu’à ce qu’enfin, ça marche. Mais assez vite, une question se pose :

Comment suivre tout ce qu’on essaie ?

Et surtout, comment comparer objectivement les résultats de nos expérimentations sans s’y perdre ? Dans cette série, je propose de prendre du recul sur une pratique centrale mais souvent floue du machine learning : le suivi d’expérimentations.

Nous explorerons ensemble comment garder une trace claire, exploitable et utile de nos essais en machine learning, peu importe l’outil utilisé.

Ah, et cerise sur le gâteau : la série comportera des mises en situation

Mais avant de parler d’outils et de mise en pratique, ce premier article pose les bases : qu’est-ce qu’expérimenter en machine learning, et qu’est-ce que suivre signifie vraiment ?

Canalisez votre curiosité, suivez le fil, et bonne lecture !

1/ L’expérimentation et le Machine Learning

L’expérimentation est un aspect fondamental du machine learning, essentiellement en raison de sa nature probabiliste.
Mais avant toute chose, posons le décor : qu’entend-on par expérimentation ?
De manière générale, c’est une procédure qu’on suit pour tester une hypothèse, faire une découverte ou démontrer un fait connu.
Et ce principe s’applique partout : aussi bien dans un laboratoire que dans la vie quotidienne.
Quand un enfant veut savoir ce qui se passerait s’il jetait votre téléphone dans les toilettes, il expérimente (à ses risques et périls, et aux vôtres).
Quand on essaie plusieurs recettes de crêpes jusqu’à trouver celle qui nous correspond le mieux, on expérimente aussi.

En machine learning, c’est exactement la même logique : on fait varier un élément du processus d’entraînement (les données, les hyperparamètres, les features, etc.), voire le processus en lui-même, pour voir si cela répond à une question de départ.
Autrement dit : expérimenter en ML, c’est tester des hypothèses sur la manière dont un modèle apprend à représenter la réalité.

2/ Suivi d’expérimentations : pourquoi ?

2.1 Suivre, c’est noter

Suivre ses expérimentations en ML, c’est comme tenir un carnet de bord scientifique : noter ce qu’on a fait, pourquoi et ce que ça a donné.

Il s’agit de prendre des notes structurées sur chaque expérimentation, afin de pouvoir les analyser, les comparer et, surtout, en tirer des enseignements.
Par notes structurées, on entend une organisation permettant de comprendre rapidement :

• La problématique de départ (sélection de modèles, optimisation d’hyperparamètres, etc.)

• Le changement introduit lors d’une expérimentation

• Les résultats obtenus

Autrement dit, il s’agit de garder une trace claire des modifications effectuées et des résultats obtenus, dans leur contexte. On obtient ainsi un historique compréhensible de ce qui a été tenté — et de ses effets réels sur le modèle.

Exemple 1. Suivi d’expérimentations avec Google Sheets

Exemple 2. Suivi d’expérimentations avec MLFlow

Un tel historique évite de tourner en rond comme une boule à facettes — par exemple, en retestant une idée déjà explorée et rejetée sans s’en rendre compte.

Il facilite également la collaboration au sein d’une équipe.
Il incite enfin à aborder chaque expérimentation avec une intention claire, et donc à mieux comprendre ce qu’elle produit réellement.

2.2 Le suivi d’expérimentations : la pratique

En pratique, les outils permettant de suivre ses expérimentations vont du simple tableau Excel à des solutions spécialisées comme MLFlow, Weights & Biases ou DVC.

Mais il est important de garder ceci en tête :

Le suivi d’expérimentations est avant tout une pratique, pas une plateforme. Il s’agit d’une prise de notes structurée, délibérée, et reproductible — une pratique qui dépasse largement le cadre du machine learning.

D’un point de vue opérationnel, cette traçabilité facilite le diagnostic du comportement d’un modèle en production, et permet de reproduire précisément les conditions ayant conduit à un modèle donné, notamment lors du passage de l’exploration à l’industrialisation (dev, pré-prod, prod).
D’un point de vue pédagogique, c’est aussi un excellent moyen de comparer différentes approches, d’apprendre de ses essais, et de satisfaire sa curiosité. Un fidèle camarade de route, en somme !

Remarque : selon les outils utilisés (MLFlow, W&B, etc.), le terme “expérimentation” peut revêtir un sens légèrement différent de celui de cet article. Nous reviendrons dessus dans la suite de la série.

3/ Savoir ce qu’on suit

Une question, un suivi, une expérimentation, une hypothèse.

OK, maintenant qu’on sait pourquoi suivre, encore faut-il savoir quoi suivre !
Un suivi d’expérimentations peut rapidement devenir contre-productif lorsqu’il n’est pas correctement cadré. Trop d’expériences, trop de paramètres, trop de résultats… Et au final, peu de réponses exploitables.

La réalité, à mon sens, c’est qu’un bon suivi d’expérimentations commence par une bonne délimitation des expérimentations.
Qu’est-ce que j’entends par là ?
Même si vous étiez déjà concentrés, passez en concentration intégrale pour ce que je m’apprête à dire 👀
Délimiter une expérimentation, c’est décider ce qu’on fait varier pour répondre à une question précise. Ce choix est fondamental : c’est lui qui permet d’obtenir des résultats à la fois objectifs et interprétables.

Le machine learning étant, à l’origine, une discipline profondément scientifique, la méthode scientifique constitue un cadre naturellement adapté pour effectuer cette délimitation.

On peut ainsi structurer une expérimentation autour des étapes suivantes :

1. Poser une question
2. Effectuer une recherche de fond sur cette question (optionnel)
3. Définir des métriques permettant d’évaluer les réponses
4. Formuler et tester des hypothèses (expérimenter, pour les intimes)
5. Noter les résultats obtenus

Des allers-retours entre les étapes sont bien entendu possibles.

Tout commence par un point qui paraît simple mais qui conditionne absolument tout le reste.

Étape 1. Poser une question

Pour viser juste, il faut d’abord avoir une cible. Expérimenter avec une intention claire permet de canaliser les efforts et d’éviter de se disperser. On part donc d’une observation que l’on transforme en question.

Et j’irai même plus loin :

Une question = un suivi.

Toutes les expérimentations que vous menez ensuite ont un seul objectif : répondre à cette question.

Prenons un exemple concret.
« Vous gérez une chaîne de production automobile. Après l’assemblage de plusieurs véhicules, vous observez que certains contiennent des pièces défectueuses. Résultat : vous êtes parfois contraint de reconstruire des véhicules entiers, un processus coûteux en temps et en argent. »
Dans un éclair de sagesse digne d’Athéna, vous comprenez que si ces pièces défectueuses pouvaient être identifiées avant l’assemblage, il serait bien moins coûteux de les remplacer ou de les réparer.

Une question s’impose :
Peut-on détecter automatiquement les pièces défectueuses avant l’assemblage ?

Étape 2. Recherche de fond (optionnel)

Afin d’expérimenter sur des bases solides et répondre à la question, on évite autant que possible de partir de zéro. À cette étape, on va donc se renseigner !
Pour cela, on met à contribution toutes les ressources dont on dispose : experts métier, internet, les données, etc.
L’objectif est de déterminer un bon angle pour entamer la réponse à la question, ne pas répéter des erreurs du passé, voire poser une question différente qu’on pense plus pertinente. Cette étape coïncide généralement avec l’analyse exploratoire de données.

Remarque

Cette étape n’est pas toujours nécessaire, ou du moins implicite, notamment lorsque : 

• La question est déjà bien cadrée,
• On itère sur un problème déjà connu.

La question de départ nous sert de cadre dans notre recherche de fond. Néanmoins, je vous invite à garder un esprit ouvert tout au long de cette recherche. Les réponses, ou du moins les débuts de réponse, ne sont pas toujours là où on croit…Ceci dit, il peut arriver que vous trouviez directement une réponse à votre question de départ lors de cette investigation. Et donc le processus en resterait là. Mais bon, parce que je n’aime pas les histoires inachevées, je vais poursuivre l’exemple de tout à l’heure en partant du principe qu’on n’a pas trouvé de réponse immédiate :

Vous êtes data scientist et c’est à vous qu’on a confié la question posée précédemment.En échangeant avec les inspecteurs de composants automobiles et en explorant les données, vous avez découvert qu’au départ, l’inspection des pièces défectueuses était manuelle, et qu’ils se trompaient 40% du temps. Ceci était dû notamment à la fatigue des inspecteurs.

Pour les accompagner dans leur démarche, ils disposent donc actuellement d’un système de détection des pièces défectueuses basé sur des règles. Le système se trompe environ 30-35% du temps lors de ses prédictions. Cela dit, le rôle des inspecteurs a évolué vers un rôle de surveillance, de dernier rempart de vérification pour des prédictions ambigües, et de détection de défauts nouveaux pour alimenter les règles.

En parallèle, vous avez découvert qu’il existe des algorithmes de ML permettant de classer des images.

Alors vous vous demandez :

Peut-on entraîner un modèle de ML capable de faire mieux que la prédiction à base de règles ?

C’est généralement à cette étape que se précise la catégorie de problèmes de ML à résoudre : sélection de modèles, optimisation d’hyperparamètres, feature engineering, etc.

Étape 3. Décider quoi mesurer

Nous avons désormais des bases solides comme une baguette congelée sur notre question de départ ! Ce qui nous a même amené à affiner notre question voire la changer complètement. Il faut maintenant décider de métriques qui permettront d’évaluer des propositions de réponses à cette question.

Choisir des métriques cohérentes pour notre cas d’usage, c’est comme faire bouillir l’eau des pâtes : c’est incontournable. Les métriques choisies doivent être adaptées au cas d’usage en rapport avec l’expérimentation.

Revenons à l’exemple de tout à l’heure pour illustrer ces propos :

Supposons qu’après investigation, vous avez acquis la certitude que les pièces défectueuses étaient beaucoup moins fréquentes que les pièces en bon état (encore heureux). Dans cette situation :

D’une part, on souhaite au maximum ne pas laisser des pièces défectueuses passer inaperçues, quitte à quelques fois identifier à tort des pièces en bon état comme étant défectueuses. En d’autres termes, on peut être relativement cléments sur les fausses alertes.

Prévenir vaut mieux que guérir, sécurité sur la route avant tout, tout ça tout ça.

D’un autre côté, on ne veut pas non plus que le modèle se mette régulièrement à identifier des pièces comme défectueuses à tort et à travers juste parce qu’on ne veut pas en rater. Il n’aurait aucune valeur ajoutée dans ce cas.

Nous sommes cléments, mais pas déments !

Au cours de nos expérimentations, nous mesurerons donc :

• La précision : parce qu’elle nous donne une idée de la fréquence à laquelle le modèle prédit à tort qu’une pièce est défectueuse, de fausses alertes quoi !
• Le rappel : utile pour mesurer la capacité du modèle à identifier des pièces réellement défectueuses, et vérifier que la réduction des fausses alertes ne se fait pas à leur détriment (comme si le modèle avait “peur” de se tromper)

On cherchera à obtenir un certain équilibre entre ces deux métriques.

Par contre, mesurer la justesse (accuracy), qui est pourtant une métrique de classification assez répandue, n’est pas pertinent dans ce contexte parce que les pièces défectueuses sont beaucoup moins fréquentes que les pièces en bon état. Cela dit, la mesurer ne ferait pas de mal non plus.

C’est essentiel de garder à l’esprit que le but n’est pas de tout mesurer — seulement ce qui éclaire nos décisions.

Étape 4. Formuler et tester des hypothèses : expérimenter

Il est enfin temps de proposer des réponses à la question, et de les évaluer à l’aide des métriques que nous avons choisies.

Chaque proposition de réponse, qu’on appelle aussi hypothèse, est testée lors d’une expérimentation.

Une expérimentation = une hypothèse.

Une hypothèse peut être par exemple :

Les observations de pièces en bon état et de pièces défectueuses sont linéairement séparables.

Si une hypothèse s’avère fausse à la fin, ce n’est absolument pas grave ! C’est pour ça qu’on expérimente après tout. Elle servira de référence parce qu’elle permet de mieux comprendre les limites du modèle ou des données 🙂

D’ailleurs, la première hypothèse que l’on expérimente est généralement simple, parfois même trop simple pour être vraisemblable. Elle sert surtout de référence pour les expérimentations suivantes.

“Une expérimentation qui échoue est une expérimentation réussie” – Emmanuel-Lin Toulemonde & Sofia Calcagno (2024). Culture MLOps

Ensuite, idéalement, une expérimentation doit concerner un seul relativement petit changement, pour en isoler les effets. C’est important d’en tenir compte lorsque vous formulez des hypothèses. Les résultats dûs à ce changement sont ensuite notés et suivis afin d’assurer la reproductibilité et soutenir un développement itératif du modèle.

Pour bien délimiter une hypothèse, vous pouvez remarquer qu’elle est généralement caractérisée par 3 choses :

• Des sujets : l’aspect du processus d’entraînement qui vous intéresse et sur lequel vous souhaitez apprendre quelque chose

Ex. données d’entraînement, algorithme d’entraînement, hyper-paramètres d’un algorithme de machine learning donné, etc.

• Un traitement : le changement ou la modification appliqué(e) à une partie des sujets

Ex. Utiliser une architecture de réseaux de neurones différente, modifier la profondeur d’un arbre de décision, etc.

• Une condition de référence (souvent appelée groupe témoin dans d’autres contextes) : un modèle, un pipeline ou une approche non modifié servant de référence

C’est à nouveau l’heure de l’exemple !

Supposons qu’un modèle de régression linéaire ait déjà été entraîné sur nos données. Nous faisons actuellement l’hypothèse qu’un arbre de décision pourrait obtenir de meilleurs résultats.

On aurait la correspondance suivante :

Ce premier exemple illustre un changement de modèle.

Comme, mine de rien, je vous aime beaucoup, voici un second exemple : 

Supposons que nous travaillions sur un problème de détection de spams et que les meilleurs résultats aient été obtenus avec un modèle de k-NN. Cela nous a mené à une nouvelle question : “Quelle est la valeur optimale de k (nombre de voisins) pour entraîner un modèle de k-NN sur nos données ?”

Pour répondre à cette question, nous entamons un nouveau suivi d’expérimentations (une question, un suivi). Pour notre première expérimentation, l’hypothèse pourrait être par exemple : On peut trouver la valeur optimale de k entre 3 et 15 grâce à une recherche dans la grille (je parle de grid search, laissez-moi expérimenter des traductions 👀).

On aurait la correspondance suivante :

Ce second exemple illustre une optimisation d’hyper-paramètres (hyperparameter tuning).

Étape 5. Conclure de façon précise et quantifiée

Bien délimiter son expérimentation et définir des métriques cohérentes sont essentiels pour bien la commencer — mais il est tout aussi capital de soigner la manière dont on la termine.

Pour tirer le maximum d’une expérimentation, les conclusions doivent être objectives et mesurables.

Cela implique de les formuler de manière précise, et si possible quantifiée.

Par exemple, plutôt que de conclure :

La régression logistique semble donner de bons résultats sur les données.

On préférera une formulation comme :

La régression logistique atteint 90% de précision et 85% de rappel sur les données d’évaluation.

Définir clairement, mesurer rigoureusement : c’est ce double geste qui transforme une expérience en preuve — et une idée en savoir.

…Take away

La question qui nous a embarqués dans cet article est :

“Comment suivre ses expérimentations en ML sans s’y perdre ?”

À mon sens, répondre à cette question c’est commencer par répondre à une autre encore plus structurante : Comment définir sur quoi portent les expérimentations ?

4/ Comment définir sur quoi portent les expérimentations ?

Le machine learning étant une discipline fondamentalement scientifique, la réponse que je vous propose est fortement tirée de la méthode scientifique. En d’autres termes : 

• Délimiter le contexte de votre expérimentation grâce à votre but/question
• Se renseigner sur votre question par une recherche de fond et/ou une analyse exploratoire des données dont vous disposez
• Décider quoi mesurer a.k.a vos critères d’évaluation des propositions de réponse à votre question
• Formuler et tester des hypothèses a.k.a proposer des réponses et les évaluer
• Conclure de façon précise

Une fois ce cadre défini, il devient plus facile de repérer et contextualiser les informations que l’on veut tracer lors des expérimentations (hyperparamètres, métriques, etc.).

Le suivi d’expérimentations est avant tout une pratique, une façon de faire naturellement ancrée dans la culture fortement scientifique du Machine Learning. Les outils servent surtout à faciliter cette démarche.

L’art d’expérimenter, c’est l’art de construire de la connaissance. C’est s’aventurer, observer, questionner, faire des hypothèses, tester, découvrir, raisonner et progresser pas-à-pas. C’est comme vivre quoi 🙂

Dans le prochain article, nous mettrons ce cadre à l’épreuve à travers une première mise en situation concrète, volontairement simple, pour se concentrer sur la démarche expérimentale avant les outils.

Sur ce, prenez soin de vous et rendez-vous dans le prochain épisode !

5/ Pour aller plus loin

Concepts d’expérimentation

• https://www.simplypsychology.org/steps-of-the-scientific-method.html
• https://www.datacamp.com/resources/webinars/introduction-to-experiment-tracking
• Le cours Experimental Design in Python sur DataCamp

Concepts de Machine Learning

• Le cours Understanding Machine Learning sur DataCamp
• La formation Python Craft d’Arolla

Parce qu’écrire du code Python que vous pourrez relire, c’est aussi ça documenter vos expérimentations. D’ailleurs, d’après les rumeurs, le formateur aurait écrit cet article 😉