Quand une amélioration ML disparaît à la validation

En Machine Learning, obtenir une meilleure métrique est relativement facile.

Obtenir une amélioration qui résiste à une validation plus exigeante l’est beaucoup moins.

Une nouvelle feature, une architecture différente ou une nouvelle combinaison de modèles peut produire un résultat encourageant lors d’une première expérience :

Référence     : 35,7 %
Candidat      : 36,1 %
Écart         : +0,4 point

La tentation naturelle consiste alors à considérer le candidat comme meilleur.

Mais cette mesure ne répond qu’à une première question :

Le candidat a-t-il obtenu un meilleur résultat sur cet échantillon ?

Elle ne permet pas encore de savoir si l’écart observé est suffisamment stable, s’il apporte réellement une information supplémentaire ou s’il subsistera une fois le candidat réintégré dans le système complet.

Dans un système ML déjà mature, beaucoup d’expériences suivent ainsi un parcours moins spectaculaire :

Ce résultat n’est pas nécessairement un échec de l’expérimentation.

Éliminer une amélioration qui ne résiste pas à la validation fait précisément partie du processus permettant de ne pas dégrader le système de référence.

---

1. Une meilleure métrique n’est pas encore une amélioration

Supposons deux modèles évalués sur exactement la même période :

Modèle A : 35,7 %
Modèle B : 36,1 %

Il est parfaitement correct d’affirmer que B obtient une meilleure performance sur cet échantillon.

Il est beaucoup plus difficile d’affirmer :

B est un meilleur modèle.

Entre ces deux affirmations se trouve toute la question de la validation.

Une métrique est calculée sur un ensemble fini d’observations. Sa valeur dépend donc en partie des exemples présents dans cet ensemble.

Lorsque les différences entre modèles sont importantes, cette variabilité modifie rarement la conclusion.

Mais à mesure qu’un système progresse, les gains deviennent généralement plus faibles.

Les erreurs les plus évidentes ont déjà été corrigées, les features les plus informatives sont présentes et plusieurs familles de modèles ont souvent été explorées.

On finit alors par comparer des candidats séparés par quelques dixièmes de point.

À cette échelle, la variabilité de l’évaluation peut devenir comparable au gain recherché.

Un écart de +0,4 point doit donc être considéré comme une observation à tester, pas immédiatement comme une propriété du nouveau modèle.

---

2. Mesurer l’incertitude autour du gain

Lorsque deux modèles sont évalués sur les mêmes événements, l’information importante ne se trouve pas uniquement dans leurs métriques finales.

Elle se trouve également dans la manière dont leurs résultats diffèrent sur les mêmes observations.

Un événement particulièrement difficile peut dégrader simultanément les deux modèles. Ce qui nous intéresse n’est donc pas seulement sa difficulté, mais de savoir si l’un des deux systèmes le traite mieux que l’autre.

Pour chaque événement i, on peut considérer la différence :

Δᵢ = résultat_B(i) - résultat_A(i)

Cette comparaison appariée permet d’étudier directement l’avantage du candidat par rapport à la référence.

Une manière d’en mesurer la stabilité consiste ensuite à utiliser un bootstrap apparié.

Le principe consiste à rééchantillonner avec remise les événements du jeu d’évaluation. Pour chaque échantillon obtenu, les performances des deux modèles sont recalculées sur exactement les mêmes événements, puis leur différence est mesurée :

Δ = métrique(B) - métrique(A)

On obtient alors non plus une valeur unique, mais une distribution des gains.

Si cette distribution reste très majoritairement au-dessus de zéro, les différents rééchantillonnages conduisent généralement à la même conclusion.

Si elle traverse largement zéro, le résultat devient beaucoup plus dépendant de la composition de l’échantillon : certaines variantes donnent l’avantage au candidat, d’autres conduisent à une quasi-égalité, voire à un avantage de la référence.

Le résultat initial n’est pas faux.

C’est son interprétation comme amélioration suffisamment stable qui devient incertaine.

La différence est importante : constater que B a obtenu un meilleur score ne signifie pas encore que les données disponibles permettent d’établir avec suffisamment de robustesse qu’il est réellement meilleur.

---

3. Le processus de recherche peut lui-même biaiser la sélection

Un autre problème apparaît lorsque le même jeu d’évaluation est utilisé de manière répétée pour orienter les expériences.

Après chaque essai, le résultat influence naturellement la suite :

• conserver ou supprimer une feature ;
• abandonner une architecture ;
• modifier certains hyperparamètres ;
• explorer une combinaison qui semble prometteuse.

Aucune observation du jeu de test n’est nécessairement injectée dans l’entraînement.

Pourtant, au fil des expériences, les décisions prises dépendent de plus en plus des résultats observés sur ce jeu.

Supposons par exemple une succession d’expériences :

expérience 01 → aucun gain
expérience 02 → légère amélioration
expérience 03 → dégradation
expérience 04 → amélioration

Le résultat de l’expérience 04 ne constitue pas une observation indépendante de tout ce qui précède si les expériences 02 et 03 ont contribué à décider ce qui serait testé ensuite.

Le processus expérimental lui-même a progressivement utilisé le jeu d’évaluation comme source d’information.

Ce phénomène est différent d’un data leakage classique.

Le modèle n’a pas directement appris à partir des données du test.

C’est la recherche qui s’est progressivement adaptée aux particularités de ce jeu.

Plus cette boucle est répétée, moins le jeu concerné peut être considéré comme une mesure totalement indépendante des décisions ayant conduit au candidat final.

Une séparation stricte entre données utilisées pour orienter la recherche et données conservées pour une validation finale permet de limiter ce problème.

---

4. Multiplier les tests augmente le risque de faux positifs

Il existe un second problème, statistique cette fois, lorsqu’une campagne comporte plusieurs tests d’hypothèses.

Supposons que l’on teste 100 modifications et qu’en réalité aucune ne produise d’amélioration.

Chaque test possède malgré tout une certaine probabilité de conclure à tort qu’un effet existe.

Avec un seuil de significativité fixé à :

α = 0,05

on accepte pour un test isolé un risque de faux positif de 5 %.

Mais si ce même seuil est appliqué indépendamment à 100 hypothèses, le risque d’obtenir au moins un résultat déclaré significatif par hasard devient beaucoup plus important.

Les résultats pourraient par exemple contenir :

A → non significatif
B → non significatif
C → non significatif
D → significatif
E → non significatif
...

alors même qu’aucune des modifications testées n’a d’effet réel.

La correction de Bonferroni constitue une manière simple de contrôler ce risque à l’échelle de l’ensemble des tests.

Si l’on souhaite conserver un risque global α de 5 % pour m tests, le seuil individuel devient :

α_test = α / m

Pour 100 tests :

α_test = 0,05 / 100
       = 0,0005

Un résultat avec :

p = 0,01

serait significatif avec le seuil classique de 0,05, mais ne franchirait pas ici le seuil corrigé de 0,0005.

Bonferroni est volontairement conservateur : en réduisant fortement le risque de faux positifs, il augmente également la difficulté à détecter certains effets réels. Il ne constitue donc pas une règle universelle à appliquer mécaniquement à toute campagne d’expérimentation ML.

Il illustre cependant un principe statistique important : l’interprétation d’un test dépend aussi du nombre d’hypothèses testées dans la famille de comparaisons que l’on souhaite contrôler.

Ce problème est distinct du biais de sélection précédent.

• Dans un cas, les résultats passés influencent progressivement les expériences futures.
• Dans l’autre, plusieurs tests statistiques sont considérés simultanément et il faut contrôler le risque de faux positifs associé à leur multiplicité.

Les deux peuvent naturellement être présents dans une même démarche expérimentale, mais ils ne se corrigent pas de la même manière.

---

5. Une information pertinente peut être redondante

Une amélioration peut également disparaître pour une raison qui n’a rien de statistique : la nouvelle information est réelle, mais le système la connaît déjà sous une autre forme.

Une nouvelle feature peut ainsi présenter une relation mesurable avec la cible sans améliorer le modèle. Les variables déjà présentes peuvent capturer tout ou partie de la même information.

Il faut alors distinguer deux questions :

La variable contient-elle de l’information ?

et :

Contient-elle une information supplémentaire exploitable par rapport à ce que le modèle possède déjà ?

Ces deux questions ne sont pas équivalentes. Une feature peut être fortement liée à la cible et pourtant devenir presque inutile une fois conditionnée aux informations déjà accessibles au modèle.

Pour améliorer un système mature, la seconde question est généralement la plus importante.

Une feature ne doit donc pas seulement être évaluée pour le signal qu’elle contient, mais pour le signal supplémentaire qu’elle apporte au modèle.

Si les features existantes capturent déjà la même information, une nouvelle variable peut être pertinente lorsqu’elle est étudiée seule tout en n’apportant aucun gain une fois intégrée au modèle.

---

6. Un modèle différent ne produit pas nécessairement des erreurs différentes

Le même raisonnement s’applique lorsqu’on remplace une feature par une nouvelle famille de modèles.

Deux algorithmes très différents peuvent produire des performances proches parce qu’ils exploitent essentiellement les mêmes informations présentes dans les données.

Passer d’un gradient boosting à un réseau neuronal, par exemple, ne garantit donc pas que les erreurs deviennent réellement différentes.

Cette distinction devient particulièrement importante dans un ensemble de modèles.

Un nouveau candidat légèrement moins performant individuellement peut rester intéressant s’il réussit précisément sur des observations où les modèles existants échouent.

À l’inverse, un candidat légèrement meilleur isolément peut apporter très peu au système s’il reproduit presque exactement les mêmes décisions.

La comparaison peut alors porter sur :

• La corrélation des prédictions
• La corrélation des erreurs
• Les événements gagnés par l’un et perdus par l’autre
• Les victoires réellement uniques
• L’impact après combinaison avec les modèles existants

Une performance similaire accompagnée d’erreurs fortement corrélées et de très peu de victoires uniques indique que le changement d’architecture exploite probablement une grande partie du même signal.

La diversité utile n’est donc pas une propriété du nom de l’algorithme. Elle se mesure dans les comportements effectivement produits.

---

7. Un gain local peut disparaître dans le système complet

Cette question devient encore plus importante dans une architecture multi-niveaux.

Supposons :

L1_A ─┐
      ├──► L2 ─► L3
L1_B ─┘

Une nouvelle version de L1_A peut améliorer sa propre métrique. Mais cette amélioration ne garantit pas celle de la sortie finale.

Le niveau supérieur exploite déjà plusieurs signaux. Le gain local peut donc être :

• redondant avec un autre modèle
• déjà compensé par le niveau supérieur
• trop faible pour modifier la décision finale
• accompagné de nouvelles erreurs sur d’autres événements
• difficilement exploitable par les niveaux suivants

Il est ainsi possible qu’un candidat surpasse sa référence au niveau L1 sans produire d’amélioration au niveau du système complet, voire en dégradant légèrement sa sortie finale.

Le candidat n’était pas nécessairement mauvais. Son amélioration était simplement locale à un composant dont la métrique n’est pas l’objectif final du système.

Dans une architecture de stacking ou d’ensemble, l’évaluation doit donc être réalisée à plusieurs niveaux. La métrique locale permet de comprendre le comportement du composant.

Mais l’unité finale de comparaison reste le système dans lequel il sera réellement utilisé.

---

8. Un gain réel n’est pas nécessairement un gain utile

Supposons maintenant que le gain résiste aux validations précédentes. Il reste une dernière dimension : son coût.

Deux candidats peuvent produire exactement la même amélioration tout en ayant des conséquences opérationnelles très différentes :

	Candidat A	Candidat B
Gain	+0,3 point	+0,3 point
Modification	1 feature	1 famille de modèles
Entraînement	quasi inchangé	plus coûteux
Inférence	quasi inchangée	plus coûteux
Artefacts	inchangés ou limités	plusieurs artefacts supplémentaires

Sur la métrique observée, les deux améliorations semblent équivalentes. Opérationnellement, elles ne le sont pas.

Une modification peut introduire davantage de temps d’entraînement, une consommation mémoire supérieure, une inférence plus lente, de nouvelles dépendances, davantage d’artefacts à versionner ou encore de nouvelles possibilités de divergence entre entraînement et inférence.

La décision ne consiste donc plus seulement à demander :

Le candidat est-il meilleur ?

mais :

Le bénéfice obtenu justifie-t-il la complexité supplémentaire nécessaire pour l’obtenir ?

Une amélioration statistiquement crédible peut ainsi rester trop faible pour justifier une modification du système de référence.

---

9. Les expériences négatives permettent aussi d’avancer

Lorsqu’une expérience ne produit pas de gain exploitable, elle peut néanmoins réduire l’espace des hypothèses encore plausibles.

Le constat devient particulièrement intéressant lorsque plusieurs approches convergent :

nouvelle feature       → aucun gain robuste
nouveau modèle         → erreurs similaires
nouvelle architecture  → aucun gain système
nouvelle combinaison   → information redondante

Aucun nouveau modèle n’est promu.

Mais plusieurs informations ont été obtenues :

• le signal étudié est probablement déjà largement capturé
• la piste n’apporte pas la diversité recherchée
• les variantes proches ont moins de chances de produire un changement important
• poursuivre cette direction possède désormais une valeur attendue plus faible

Le résultat n’est alors plus simplement qu’une expérience n’a pas fonctionné.

Plusieurs expériences commencent à indiquer que cette famille d’hypothèses apporte peu d’information nouvelle au système actuel.

Une expérience négative peut donc produire une connaissance utile sur le système, même lorsqu’elle ne produit aucun nouvel artefact à déployer.

---

10. Savoir arrêter une piste fait partie de l’expérimentation

Il est facile de définir quand commencer une expérience. Il est plus difficile de déterminer quand arrêter une direction de recherche.

Une même idée peut produire presque indéfiniment de nouvelles variantes : différentes fenêtres temporelles, transformations, interactions, familles de modèles ou combinaisons. Chacune peut sembler suffisamment différente pour justifier un test supplémentaire.

Mais lorsque les expériences successives produisent systématiquement des gains faibles et incertains, des erreurs similaires et aucun impact mesurable sur le système complet, la probabilité que la variante suivante modifie radicalement la conclusion diminue. Continuer à explorer exactement le même signal produit alors des rendements décroissants.

Arrêter une piste ne signifie pas démontrer qu’elle ne pourra jamais produire d’amélioration. Cela signifie plus modestement :

Les résultats disponibles ne justifient plus d’allouer davantage de temps et de calcul à cette direction par rapport aux autres hypothèses possibles.

Cette décision fait elle-même partie du processus expérimental. Dans certains cas, la meilleure suite n’est donc pas un nouvel algorithme ou une nouvelle transformation.

Elle consiste à rechercher une information réellement absente du système actuel.

---

11. De la meilleure métrique à la promotion

Une amélioration candidate peut finalement être considérée comme une succession de niveaux de preuve.

Le premier résultat positif n’est donc pas la fin de l’évaluation.

Il en constitue le début.

Un candidat peut disparaître à chacune de ces étapes : gain trop instable, biais lié au processus de sélection, information déjà capturée, erreurs trop similaires à celles des modèles existants, absence de gain sur le système final ou coût disproportionné.

Toutes les modifications ne nécessitent évidemment pas le même niveau d’analyse.

Mais une règle générale apparaît :

Plus le gain observé est faible et plus la modification est coûteuse, plus les éléments nécessaires avant promotion doivent être solides.

Une meilleure métrique constitue ainsi une hypothèse d’amélioration. La validation détermine ensuite si cette hypothèse justifie réellement une modification du système.

La métrique initiale déclenche l’analyse.

Elle ne la termine pas.

---

12. Conclusion

Une amélioration observée lors d’une première expérience ne résiste pas toujours aux validations suivantes.

Le gain peut se révéler trop incertain, dépendre en partie du processus de sélection, correspondre à une information déjà capturée ou simplement disparaître lorsque la modification est réintégrée dans le système complet.

Ce résultat ne rend pas l’expérience inutile. Il permet au contraire de distinguer un gain observé ponctuellement, d’une amélioration suffisamment robuste pour modifier le système de référence.

À mesure qu’un système ML mûrit, cette distinction devient de plus en plus importante. Les gains faciles deviennent plus rares, les écarts entre candidats se réduisent et une part croissante des expériences aboutit naturellement à conserver l’existant.

Cela ne signifie pas que la recherche n’avance plus. Établir qu’une piste n’apporte pas d’information nouvelle, que son gain est trop fragile ou qu’il disparaît à l’échelle du système permet aussi de mieux comprendre ce qui reste réellement à améliorer.

L’objectif n’est donc pas de battre la référence à chaque expérience, mais de ne la remplacer que lorsqu’une amélioration résiste suffisamment à la validation pour justifier ce changement.