Itérer : quand re-fine-tuner
Mis à jour le 28 juillet 2026
Le fine-tuning est un processus itératif
Votre premier fine-tuning sera rarement parfait. L’amélioration vient de cycles itératifs : analyser les erreurs, enrichir les données, relancer l’entraînement, réévaluer. Cette leçon vous apprend à identifier quand et comment itérer efficacement — et, tout aussi important, à reconnaître les situations où relancer un entraînement ne servirait à rien.
Analyser les erreurs avant de corriger
Le réflexe naturel après une évaluation décevante consiste à ajouter des exemples au hasard, en espérant que le volume règle le problème. C’est le meilleur moyen de dépenser un budget d’entraînement sans progresser. Commencez par ranger chaque échec dans une catégorie : une mauvaise mise en forme, un ton inapproprié, une information fausse, une réponse incomplète, un hors-sujet ou une invention pure. La distribution obtenue vous dit où porter l’effort, et elle réserve souvent une surprise — ce que vous preniez pour un problème de style se révèle un problème de complétude.
def analyser_erreurs(resultats: list[dict]) -> dict:
"""Catégorise les erreurs du modèle fine-tuné."""
categories = {
"format": [], # Mauvais format de réponse
"ton": [], # Ton inapproprié
"factuel": [], # Information incorrecte
"incomplet": [], # Réponse trop courte ou manque des éléments
"hors_sujet": [], # Ne répond pas à la question
"hallucination": [] # Invente des informations
}
for r in resultats:
if r.get("score", 5) < 3:
# Classifier l'erreur (peut être fait manuellement ou par LLM)
categorie = classifier_erreur(r)
categories[categorie].append(r)
print("Distribution des erreurs :")
for cat, erreurs in categories.items():
if erreurs:
print(f" {cat} : {len(erreurs)} cas")
return categories
Relisez ensuite les cas d’une même catégorie à la recherche d’un dénominateur commun. Posez-vous à chaque fois les mêmes questions : le modèle échoue-t-il sur un type de question particulier, les erreurs se concentrent-elles sur certains sujets, et le problème vient-il des données ou des hyperparamètres ? Des échecs dispersés sur tous les sujets mais toujours de même nature pointent vers un manque d’exemples ; des échecs concentrés sur un domaine pointent vers un trou de couverture ; et des réponses trop proches de vos exemples d’entraînement, quelles que soient les questions, signalent plutôt un surapprentissage à corriger côté epochs.
Reconnaître le moment d’itérer
Certains signaux appellent sans ambiguïté une nouvelle version, et à chacun correspond une réponse différente. Un modèle qui hallucine sur un sujet ne se corrige pas en lui montrant davantage de bonnes réponses sur ce sujet, mais en lui apprenant à refuser poliment quand il ne sait pas.
| Signal | Action |
|---|---|
| Erreurs de format récurrentes | Ajoutez plus d’exemples avec le bon format |
| Le modèle hallucine sur certains sujets | Ajoutez des exemples où il refuse poliment |
| Surapprentissage détecté | Réduisez les epochs, diversifiez les données |
| Nouveaux cas d’usage à couvrir | Ajoutez des exemples pour ces cas |
| Feedback utilisateur négatif ciblé | Transformez le feedback en exemples corrigés |
À l’inverse, plusieurs situations doivent vous retenir de relancer un entraînement. Quand les erreurs sont rares et non systématiques, un ajustement de prompt les traite plus vite et pour moins cher. Quand la plainte porte sur des latences ou des délais d’attente, le problème est dans votre infrastructure et aucun entraînement n’y changera rien. Quand vous n’avez récolté qu’une poignée de nouveaux exemples depuis la dernière version, le gain attendu ne couvrira pas le coût du run. Et quand un nouveau modèle de base devient disponible, testez-le d’abord tel quel : il arrive qu’il fasse seul, sans entraînement, ce que votre version précédente peinait à obtenir.
Enrichir plutôt que repartir de zéro
L’itération incrémentale consiste à ajouter des exemples ciblés à un jeu de données existant, sans toucher au reste. C’est l’opération la plus fréquente et la plus simple : vous chargez le fichier courant, vous y concaténez les nouveaux cas, vous réécrivez le tout au format JSONL. L’affichage final vous sert de contrôle — un total qui ne correspond pas à la somme attendue trahit un fichier mal lu ou des lignes perdues.
import json
def enrichir_dataset(
dataset_existant: str,
nouveaux_exemples: list[dict],
output: str
):
"""Ajoute de nouveaux exemples au dataset existant."""
# Charger les données existantes
with open(dataset_existant, "r") as f:
existants = [json.loads(l) for l in f]
# Fusionner
combines = existants + nouveaux_exemples
# Sauvegarder
with open(output, "w") as f:
for ex in combines:
f.write(json.dumps(ex, ensure_ascii=False) + "\n")
print(f"Dataset enrichi : {len(existants)} + {len(nouveaux_exemples)} = {len(combines)}")
L’itération corrective est plus intéressante encore, car elle transforme vos échecs en matière première. Chaque erreur repérée en production fournit une question réelle ; il vous reste à écrire la réponse que vous auriez voulu lire, et l’ensemble devient un exemple d’entraînement. Notez que la mauvaise réponse n’entre pas dans l’exemple final : elle sert à documenter le cas et à décider si la correction vaut la peine, mais le modèle n’apprend que de la bonne version.
def erreur_vers_exemple(
question: str,
mauvaise_reponse: str,
bonne_reponse: str,
system_msg: str
) -> dict:
"""Transforme une erreur en exemple d'entraînement."""
return {
"messages": [
{"role": "system", "content": system_msg},
{"role": "user", "content": question},
{"role": "assistant", "content": bonne_reponse}
]
}
# Transformer un lot d'erreurs
corrections = []
for erreur in erreurs_detectees:
correction = erreur_vers_exemple(
question=erreur["question"],
mauvaise_reponse=erreur["reponse_modele"],
bonne_reponse=erreur["reponse_corrigee"],
system_msg=PROMPT_SYSTEME
)
corrections.append(correction)
Le fine-tuning continu et sa limite
Rien ne vous empêche de fine-tuner un modèle déjà fine-tuné : il suffit de passer son identifiant complet dans le paramètre model à la place du nom du modèle de base. L’opération est tentante puisqu’elle ne réentraîne que sur les nouveautés.
# Fine-tuner à partir d'un modèle déjà fine-tuné
job_v2 = client.fine_tuning.jobs.create(
training_file=nouveau_fichier.id,
model="ft:gpt-5.6-luna:org::suffix-v1:xxxxxxxx", # modèle v1 comme base
suffix="mon-assistant-v2"
)
Attention : le fine-tuning continu accumule les biais. Après 2-3 itérations successives, il est souvent préférable de repartir du modèle de base avec un dataset complet et enrichi. Chaque couche amplifie les particularités de la précédente, y compris celles que vous n’aviez pas voulues, et le modèle finit par répondre avec une raideur que personne n’a explicitement enseignée.
Le cycle complet
Les étapes ci-dessous forment la boucle que vous répéterez à chaque version. Si vous attaquez les erreurs les plus fréquentes en premier, la version suivante affichera un gain mesurable sur votre jeu de test ; en les prenant dans le désordre, vous n’obtiendrez qu’une amélioration diffuse et impossible à défendre devant votre équipe.
Collecter les erreurs
Identifiez les cas où le modèle échoue en production ou en évaluation.
Catégoriser et prioriser
Classez les erreurs par type et traitez les plus fréquentes en premier.
Créer les exemples correctifs
Transformez chaque erreur en exemple d'entraînement avec la bonne réponse.
Relancer et réévaluer
Entraînez la nouvelle version et comparez-la avec la précédente sur le même jeu de test.
Documenter chaque itération
Au bout de quatre ou cinq versions, personne ne se souvient de ce qui distinguait la v2 de la v3 ni pourquoi la v4 a été abandonnée. Un enregistrement systématique de chaque run — la composition du jeu de données, l’origine des nouveaux exemples, les hyperparamètres, les résultats et la décision prise — vous rend ces informations le jour où une régression vous oblige à remonter le fil. Renseignez en particulier la provenance des nouveaux exemples : elle seule vous dira, des mois plus tard, si la dégradation vient d’un lot de données mal choisi.
iteration_log = {
"version": "v3",
"date": "2026-04-02",
"modele_base": "gpt-5.6-luna",
"dataset": {
"train": 350,
"validation": 45,
"nouveaux_exemples": 50,
"source_nouveaux": "erreurs production semaine 12"
},
"hyperparametres": {
"n_epochs": 3,
"learning_rate_multiplier": "auto",
"batch_size": "auto"
},
"résultats": {
"validation_loss": 0.42,
"precision_test": 0.91,
"csat_moyen": 4.3,
"amelioration_vs_v2": "+5% précision, +0.2 CSAT"
},
"decision": "Déployé en production le 2026-04-03"
}
Points clés à retenir
- Le fine-tuning est itératif — planifiez plusieurs cycles
- Catégorisez les erreurs avant de les corriger dans les données
- Transformez le feedback utilisateur en exemples d’entraînement
- Après 2-3 itérations successives, repartez du modèle de base
- Documentez chaque itération pour garder un historique clair