Hyperparamètres : epochs, learning rate, batch size
Mis à jour le 28 juillet 2026
Le rôle des hyperparamètres
Vos données décrivent ce que le modèle doit apprendre ; les hyperparamètres décrivent comment il l’apprend. Par défaut, OpenAI choisit automatiquement des valeurs raisonnables à partir de la taille de votre dataset, et pour un premier job c’est le bon réflexe. Mais quand un modèle sort décevant alors que le corpus est propre, c’est presque toujours ici que se joue la différence, et les ajuster manuellement peut significativement améliorer les résultats.
Le nombre d’epochs
Un epoch correspond à un passage complet sur l’ensemble de vos données d’entraînement. Plus vous faites d’epochs, plus le modèle voit chaque exemple, et plus il en retient les détails. Avec trop peu d’epochs, le modèle n’a pas assez appris : c’est le sous-apprentissage, et vos réponses ressemblent encore à celles du modèle de base. Avec trop d’epochs, il mémorise les exemples au lieu de généraliser : c’est le surapprentissage, et le modèle récite vos cent réponses d’entraînement dès qu’une question s’en approche vaguement, tout en s’effondrant sur les formulations inédites.
job = client.fine_tuning.jobs.create(
training_file=training_file.id,
model="gpt-5.6-luna",
hyperparameters={
"n_epochs": 3
}
)
Le bon réglage dépend directement du volume dont vous disposez : moins vous avez d’exemples, plus il faut repasser dessus pour que le signal s’imprime.
| Taille du dataset | Epochs recommandés | Raison |
|---|---|---|
| 50-100 exemples | 4-8 | Peu de données, besoin de plus de passages |
| 100-500 exemples | 2-4 | Bon équilibre apprentissage/généralisation |
| 500+ exemples | 1-2 | Assez de données, risque de surapprentissage |
Le learning rate multiplier
Le learning rate contrôle l’amplitude des ajustements appliqués aux poids du modèle à chaque étape d’entraînement. Réglé trop haut, le modèle corrige trop fort à chaque pas, oscille autour de la bonne réponse et ne converge pas ; réglé trop bas, il apprend très lentement, voire pas du tout, et vous obtenez au bout de l’entraînement un modèle presque identique à celui de départ.
job = client.fine_tuning.jobs.create(
training_file=training_file.id,
model="gpt-5.6-luna",
hyperparameters={
"learning_rate_multiplier": 1.8
}
)
La valeur par défaut est calculée automatiquement par OpenAI en fonction de la taille de votre dataset. En pratique, la plage 1.0-2.0 correspond à ce comportement par défaut et convient à la plupart des cas. Descendre entre 0.5 et 1.0 rend l’apprentissage plus prudent, ce qui est utile sur un petit dataset où quelques exemples atypiques pourraient tirer le modèle trop loin. Monter au-delà de 2.0 donne un apprentissage agressif, à réserver aux situations où vous avez constaté que le modèle ne bougeait pas assez — et à vérifier immédiatement sur la validation loss.
Le batch size
Le batch size détermine le nombre d’exemples traités ensemble avant de mettre à jour les poids du modèle. Un petit batch produit des mises à jour fréquentes : l’apprentissage est plus bruité, chaque exemple pesant lourd dans la correction, mais aussi plus réactif. Un grand batch moyenne davantage d’exemples avant chaque correction, ce qui donne des mises à jour moins fréquentes et un apprentissage plus stable — c’est le levier à actionner quand vos courbes tremblent sans raison apparente.
job = client.fine_tuning.jobs.create(
training_file=training_file.id,
model="gpt-5.6-luna",
hyperparameters={
"batch_size": 4
}
)
Rien ne vous oblige à les régler séparément : les trois paramètres se passent dans le même dictionnaire.
job = client.fine_tuning.jobs.create(
training_file=training_file.id,
validation_file=validation_file.id,
model="gpt-5.6-luna",
suffix="optimise-v2",
hyperparameters={
"n_epochs": 3,
"learning_rate_multiplier": 1.5,
"batch_size": 4
}
)
Une méthode d’optimisation
L’erreur classique consiste à modifier les trois valeurs d’un coup, à constater une amélioration, et à ne plus savoir laquelle l’a produite. Procédez dans cet ordre :
- Premier run : laissez les valeurs par défaut (auto)
- Analysez la loss : si la training loss descend mais la validation loss remonte, vous surapprenez
- Ajustez un paramètre à la fois : ne changez jamais tout en même temps
- Documentez chaque run : notez les hyperparamètres et les résultats
Ce carnet de bord n’est pas une formalité. Au troisième ou quatrième run, un tableau qui associe un identifiant de job, les hyperparamètres utilisés et le résultat observé vaut mieux que votre mémoire. Voici comment lire les symptômes les plus courants.
| Symptôme observé | Correction à tenter |
|---|---|
| Training loss ne descend pas | Augmenter le learning rate ou le nombre d’epochs |
| Validation loss remonte | Réduire le nombre d’epochs, augmenter le batch size |
| Résultats instables | Réduire le learning rate |
| Modèle trop similaire au modèle de base | Augmenter le nombre d’epochs |
La valeur « auto »
Si vous ne spécifiez pas un hyperparamètre, OpenAI choisit automatiquement une valeur optimale. Vous n’êtes donc jamais obligé de tout renseigner : fixez ce que vous voulez maîtriser, laissez le reste au réglage automatique. C’est souvent le meilleur point de départ, et cela vous donne une référence à laquelle comparer vos ajustements ultérieurs.
# Seul n_epochs est fixé, le reste est auto
job = client.fine_tuning.jobs.create(
training_file=training_file.id,
model="gpt-5.6-luna",
hyperparameters={
"n_epochs": 3
# learning_rate_multiplier et batch_size seront auto
}
)
Points clés à retenir
- Commencez toujours avec les valeurs par défaut (auto) avant d’ajuster
n_epochs: ajustez en premier, en fonction de la taille de vos donnéeslearning_rate_multiplier: ajustez si la convergence est trop lente ou trop instablebatch_size: ajustez si l’entraînement est bruité- Ne changez qu’un hyperparamètre à la fois pour comprendre son impact
- Utilisez toujours un fichier de validation pour détecter le surapprentissage