Comment savoir si votre modèle s’est vraiment amélioré?

Un chiffre plus élevé sur une seule exécution est une preuve faible. Les modèles s’entraînent à partir de points de départ aléatoires, les tests contiennent un nombre limité d’exemples et les gens ont tendance à cesser de regarder quand le score monte. Chacun de ces éléments peut vous offrir une « amélioration » qui disparaît au prochain essai.

Ce projet mesure directement quatre pièges, à l’aide des chiffres de scikit-learn et d’un ensemble de nombres purement aléatoires. Le script compagnon, 04_honest_testing.py, s’est exécuté ici en cinq secondes environ sur un Apple M5 Max avec deux fils de processeur. Pour tester les modèles de langage en particulier, y compris les bits par octet et les bancs d’essai, voyez comment savoir si un modèle de langage que vous avez entraîné est bon. Cet article couvre ce qui s’applique à tout modèle.

Piège 1 : la chance a l’air d’un progrès

Mêmes données, même recette, 20 graines aléatoires différentes. Entraînement sur 300 images de chiffres et test sur 300 autres :

Une « amélioration » de trois points peut donc apparaître sans aucun changement, sauf la graine. Avant de comparer deux idées, voyez de combien le score bouge quand rien d’autre ne change. Un changement plus petit que cette bande n’est pas encore une preuve.

Piège 2 : comparer des totaux plutôt que des exemples

Deux modèles testés sur les mêmes 300 images vous en disent plus que deux pourcentages. Comptez leurs désaccords.

import numpy as np

def compare(a_right, b_right, rounds=5000, seed=0):
    """a_right et b_right : tableaux de True/False, un par exemple de test."""
    rng, n = np.random.default_rng(seed), len(a_right)
    diffs = []
    for _ in range(rounds):
        i = rng.integers(0, n, n)                # rééchantillonner le jeu de test
        diffs.append(b_right[i].mean() - a_right[i].mean())
    return {"only_a": int((a_right & ~b_right).sum()),
            "only_b": int((b_right & ~a_right).sum()),
            "ci95": np.percentile(diffs, [2.5, 97.5]).round(4)}

C’est un bootstrap apparié : il réutilise le jeu de test bien des fois, tiré au hasard avec remise, pour voir à quel point la différence oscillerait avec un autre échantillon. Mesuré ici :

Le second résultat paraît nettement meilleur : 6 exemples contre 1. Pourtant, l’intervalle touche zéro. Un compte rendu honnête dit « probablement meilleur, et un test plus grand trancherait ». Seules sept images sur 300 distinguent les deux modèles. Tout repose sur ces sept-là, une bonne raison de les lire.

Piège 3 : le jeu de test s’use

Chaque fois que vous regardez un score de test et réagissez, une partie du jeu de test s’infiltre dans vos décisions. Pour le mesurer, le script a essayé 60 réglages sur un petit jeu d’entraînement, gardé celui qui obtenait le meilleur score sur un test de 60 images, puis vérifié ce gagnant sur 900 images fraîches. Il a répété l’opération 20 fois.

L’écart de 1,2 point est modeste ici, parce que ces réglages ne diffèrent pas énormément et que les chiffres sont faciles. Il grandit avec plus d’essais, des tests plus petits et des problèmes plus difficiles. Gardez trois piles : les données d’entraînement, un jeu de développement que vous pouvez consulter librement et un test final que vous ouvrez rarement. Si vous changez quoi que ce soit à cause du test final, il est devenu un jeu de développement.

Piège 4 : la fuite transforme le bruit en compétence

La fuite de données survient quand de l’information indisponible au moment de la prédiction entre dans la construction du modèle. C’est le résultat le plus spectaculaire du projet. Les données sont 100 lignes de 2 000 variables aléatoires avec des étiquettes aléatoires : rien ne peut être appris et la vraie compétence est de 50 %.

from sklearn.feature_selection import SelectKBest, f_classif
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import cross_val_score
from sklearn.pipeline import make_pipeline

# FAUX : choisir les variables avec toutes les lignes, celles de test comprises
chosen = SelectKBest(f_classif, k=20).fit(N, Y).transform(N)
leaky = cross_val_score(LogisticRegression(max_iter=500), chosen, Y, cv=5).mean()

# JUSTE : le choix des variables fait partie de l'entraînement, refait dans chaque partage
honest_model = make_pipeline(SelectKBest(f_classif, k=20), LogisticRegression(max_iter=500))
honest = cross_val_score(honest_model, N, Y, cv=5).mean()

Mêmes données, une ligne placée ailleurs, et un modèle inutile affiche 84 %. Formes courantes dans la vraie vie : la mise à l’échelle sur toutes les données, des quasi-doublons des deux côtés du partage et une variable qui n’existe qu’une fois le résultat connu, comme « remboursement émis » pour prédire les demandes de remboursement.

Deux vérifications peu coûteuses en attrapent beaucoup. Entraînez avec des étiquettes mélangées : un pipeline honnête doit tomber au niveau du hasard, et il a obtenu ici 8,67 % pour un hasard de 10 %. Et comparez avec une référence : toujours répondre le chiffre le plus courant a obtenu 10,33 % à ce test.

Que doit contenir une note de résultats pour qu’une autre personne puisse s’y fier?

Six lignes suffisent, et elles s’écrivent en quelques minutes :

La vraie valeur de la note est la discipline d’écrire la décision après les chiffres. Pour les outils que vous utilisez plutôt qu’entraînez, la même idée s’applique avec un petit ensemble de tâches réalistes. Un score faible est utile aussi, puisqu’il vous dit où regarder. Ce qui gaspille des mois, c’est un score élevé que vous ne pouvez pas expliquer.