Hyperparamètres : ce que vous réglez, ce qu’il apprend

Un hyperparamètre est un réglage que vous choisissez avant l’entraînement, pour contrôler la façon dont le modèle apprend. Un paramètre est ce que le modèle, lui, découvre dans les données.

L’analogie tient debout jusqu’au bout, ce qui est rare :

Vous réglez la température et la durée. Vous ne réglez pas le goût : il résulte de tout le reste. Et un four à 250 °C pendant une heure ne produit pas un gâteau différent, il produit un gâteau raté.

Le test qui tranche tous les cas

Une seule question à poser devant n’importe quelle valeur :

Est-ce que cette valeur est calculée à partir des données, ou est-ce que je l’ai écrite moi-même ?

Calculée par l’entraînement, c’est un paramètre. Écrite par vous avant, c’est un hyperparamètre. Il n’y a pas de cas ambigu.

Prenons la régression la plus simple :

y = ax + b

Le modèle cherche a et b — ce sont ses paramètres, et vous ne les choisissez jamais. Vous choisissez en revanche comment il les cherche : un taux d’apprentissage de 0,01, cent époques. Ce sont les hyperparamètres.

Les deux flèches qui entrent dans l’entraînement sont de nature différente : l’une apporte le monde, l’autre vos décisions. Le modèle sort de là avec des paramètres que personne n’a écrits.

La règle qui se vérifie dans le code

En scikit-learn, la distinction est visible à l’œil nu, et c’est le moyen le plus rapide de ne plus jamais les confondre.

from sklearn.ensemble import RandomForestClassifier

modele = RandomForestClassifier(
    n_estimators=300,   # hyperparamètre
    max_depth=10,       # hyperparamètre
    min_samples_leaf=5, # hyperparamètre
)

modele.fit(X_train, y_train)  # c'est ici que le modèle apprend

modele.feature_importances_   # paramètre appris
modele.estimators_            # paramètres appris : les arbres eux-memes

Ce qui se passe dans le constructeur est un hyperparamètre. Ce qui apparaît après fit, avec un tiret bas final, est appris. Ce tiret bas n’est pas un hasard : c’est une convention documentée de la bibliothèque, qui marque précisément les attributs issus de l’entraînement.

Sur notre régression :

from sklearn.linear_model import LinearRegression

reg = LinearRegression().fit(X_train, y_train)

reg.coef_       # le « a »
reg.intercept_  # le « b »

Deux valeurs, deux tirets bas, aucune décision de votre part.

Les trois familles, plutôt qu’une liste

Retenir vingt noms d’hyperparamètres ne sert à rien. Retenir à quoi ils servent permet de deviner le rôle de ceux qu’on n’a jamais vus.

La capacité — combien le modèle a le droit d’être compliqué. max_depth, le nombre de couches, le nombre de neurones, le degré d’un polynôme. Trop de capacité et le modèle apprend le bruit ; pas assez et il rate la structure. C’est exactement le compromis biais-variance.

L’optimisation — comment la recherche se déroule. Le taux d’apprentissage, la taille de lot, le nombre d’époques, l’algorithme d’optimisation. Ces réglages ne changent pas ce que le modèle peut représenter, seulement sa capacité à le trouver.

La régularisation — combien on bride le modèle pour qu’il généralise. alpha d’une régression pénalisée, le dropout, min_samples_leaf, la décroissance des poids. C’est de la capacité qu’on retire volontairement.

Devant un hyperparamètre inconnu, la question devient donc : rend-il le modèle plus expressif, change-t-il la façon de chercher, ou le bride-t-il ? Les trois réponses possibles couvrent presque tout.

Ceux qui comptent vraiment

Tous les hyperparamètres ne se valent pas, et l’écart est énorme. Quelques repères qui font gagner des heures.

Forêt aléatoire : presque rien à régler. Ajouter des arbres ne provoque pas de surapprentissage — l’erreur se stabilise et n’augmente pas. Il faut donc « assez d’arbres », un seuil au-delà duquel on ne paie que du temps de calcul. Le seul réglage qui change réellement le résultat est le nombre de variables candidates par coupure, et accessoirement la taille minimale des feuilles sur des données bruitées.

Gradient boosting : deux réglages liés. Ici, ajouter des arbres finit par surapprendre, contrairement à la forêt. Et le taux d’apprentissage et le nombre d’arbres se compensent : diviser le premier par deux demande à peu près de doubler le second. On fixe donc un taux d’apprentissage faible, et on laisse l’arrêt anticipé décider du nombre d’arbres. La différence de tempérament entre ces deux familles est détaillée dans forêt aléatoire ou gradient boosting.

Réseau de neurones : le taux d’apprentissage d’abord. C’est le réglage le plus important de tous, et de loin. Trop grand, la perte oscille ou explose ; trop petit, l’entraînement n’avance pas dans le temps imparti. Comment le choisir mérite sa propre discussion, comme la taille de lot — dont l’effet est souvent surestimé, sauf sur la mémoire disponible.

Régression pénalisée : l’intensité de la pénalité. Un seul réglage sérieux, sur une échelle logarithmique.

Une règle générale se dégage : tout ce qui est un taux ou une intensité se cherche sur une échelle logarithmique, jamais linéaire. Chercher entre 0,001 et 0,1 par pas de 0,001 gaspille l’essentiel du budget dans une zone où plus rien ne change.

Trois valeurs qui n’en sont pas

C’est la source de confusion suivante, et elle a des conséquences.

random_state n’est pas un hyperparamètre. C’est une graine de générateur aléatoire, dont le rôle est la reproductibilité. Chercher la graine qui donne le meilleur score est une façon très efficace de se tromper soi-même : on sélectionne du bruit, et rien ne survit sur des données nouvelles. Si le score varie beaucoup selon la graine, ce n’est pas une invitation à choisir la bonne — c’est le signe que l’évaluation est trop fragile pour conclure.

n_jobs, verbose, device ne sont pas des hyperparamètres. Ils changent la vitesse, la trace affichée, le matériel utilisé. Le modèle obtenu est le même. Ce sont des réglages d’exécution, qui partagent seulement l’emplacement dans le code — ce qui affaiblit un peu la règle du constructeur énoncée plus haut, et il vaut mieux le savoir.

Le seuil de décision n’est pas un hyperparamètre d’entraînement. Le fameux 0,5 qui transforme une probabilité en oui ou non se choisit après, en fonction du coût des erreurs, sans réentraîner quoi que ce soit. Le mettre dans une recherche d’hyperparamètres est du gaspillage : c’est une décision distincte, qui se prend sur une courbe.

Ce que de mauvais réglages produisent

L’enchaînement redouté :

Réglage inadapté
       ↓
Apprentissage manqué
       ↓
Mauvaises prédictions

Sauf qu’il se manifeste de deux façons opposées, et que la confusion entre les deux fait perdre le plus de temps :

Le diagnostic ne se lit pas sur un score, mais sur l’écart entre les deux. Un modèle excellent à l’entraînement et médiocre en validation surapprend, et ajouter de la capacité aggravera les choses. Deux erreurs élevées ensemble décrivent l’inverse. C’est le sujet du surapprentissage et de sa détection.

Où s’arrêter

Le réglage des hyperparamètres est agréable — il donne l’impression d’avancer, il se mesure, il s’automatise. C’est précisément pourquoi il faut savoir sa place dans l’ordre des priorités.

1. Les données. Une étiquette fausse, un doublon, un découpage qui fuit. Aucun réglage ne rattrape cela, et un réglage effectué sur un protocole cassé produit un chiffre sans signification.
2. Les variables. Une information pertinente en plus rapporte presque toujours plus que le meilleur réglage possible.
3. La famille de modèle. Passer d’une régression linéaire à un gradient boosting sur des données tabulaires change davantage le résultat que n’importe quelle recherche.
4. Les hyperparamètres. En dernier, et le gain typique se compte en points de pourcentage, pas en facteurs.

Deux conséquences pratiques. D’abord, les valeurs par défaut des bibliothèques modernes sont des points de départ honnêtes : elles ont été choisies sur de nombreux jeux de données, et elles battent souvent un réglage fait à la main sans méthode. Ensuite, un modèle de référence entraîné avec les valeurs par défaut est la première chose à produire, parce qu’il donne l’échelle de ce qu’un réglage peut espérer gagner.

Quand vient le moment de chercher pour de bon — recherche aléatoire plutôt qu’exhaustive, protocole d’évaluation, échelles à utiliser —, la méthode complète est détaillée dans comment régler ses hyperparamètres. Le principe non négociable : la recherche porte sur le pipeline entier, préparation comprise, et le score final se lit sur des données qu’elle n’a jamais vues.

Ce qu’il faut retenir

Un hyperparamètre est un bouton de réglage. Un paramètre est ce que le modèle a compris.

Hyperparamètres = choisis par vous, avant
Paramètres      = appris par le modèle, pendant

Trois réflexes suffisent au quotidien. Repérer le tiret bas final, qui signale toujours quelque chose d’appris. Classer un réglage inconnu dans l’une des trois familles — capacité, optimisation, régularisation — pour deviner son effet. Et se rappeler que régler intervient en dernier, après les données, les variables et le choix du modèle.

Deux suites, selon où vous en êtes. Pour ne pas perdre la trace des réglages essayés et de ce qu’ils ont donné, le suivi des expériences. Et une fois le modèle réglé et déployé, une question qui n’a pas la même réponse : quand faut-il le réentraîner, et sur quelles données ?