Évaluer un modèle fine-tuné : éviter l'overfitting

Un modèle fine-tuné qui atteint 98 % de précision sur son jeu d'entraînement n'est pas nécessairement bon. Il a peut-être juste appris par cœur. Évaluer un modèle fine-tuné correctement, c'est mesurer s'il a vraiment appris à généraliser — pas s'il mémorise. Et ça commence avant même le premier entraînement, par la constitution d'un golden eval set isolé.

Cet article couvre la méthode complète : comment structurer vos splits train/validation/test pour éviter la fuite de données, quelles métriques utiliser selon votre tâche, comment détecter l'overfitting et la régression des capacités générales, et quels outils concrets (RAGAS, DeepEval, LangFuse, lm-eval-harness, Weights & Biases) permettent de suivre tout ça sans y passer deux semaines.

Pourquoi la loss d'entraînement seule ne suffit pas

C'est l'erreur la plus répandue. On lance un fine-tuning, la loss descend régulièrement, et on déclare victoire. Sauf que la training loss mesure une seule chose : à quel point le modèle prédit correctement les tokens qu'il a déjà vus pendant l'entraînement. Ce n'est pas ce qui compte en production.

Ce qui compte, c'est la validation loss — la loss sur des exemples que le modèle n'a pas vus pendant l'entraînement. Et surtout, les métriques métier sur un jeu de test isolé : est-ce que le modèle classe correctement les tickets que vos équipes lui envoient aujourd'hui ? Est-ce qu'il extrait les bonnes entités sur de nouveaux documents ?

La training loss peut descendre indéfiniment si on entraîne assez longtemps. C'est précisément le signal d'overfitting : le modèle mémorise les exemples d'entraînement au lieu d'apprendre leurs patterns sous-jacents. En pratique, on surveille les deux courbes en parallèle avec Weights & Biases — dès que la validation loss remonte pendant que la training loss continue de descendre, on arrête.

Soyons honnêtes : il n'y a pas de projet de fine-tuning sérieux sans monitoring de ces deux courbes en temps réel. C'est 30 minutes de setup sur W&B, et ça évite des semaines de retours en arrière.

Constituer le golden eval set avant d'entraîner

Le golden eval set, c'est le jeu de données de référence qu'on constitue avant de toucher à l'entraînement, et qu'on ne modifie plus jamais. Son rôle : mesurer objectivement si le modèle s'améliore vraiment sur la tâche visée.

Pourquoi avant ? Parce que si on choisit les exemples de test après avoir vu les résultats, on biaise inconsciemment la sélection vers les cas que le modèle réussit. C'est humain, et c'est destructeur pour la validité de l'évaluation.

Quelques règles pratiques pour le construire :

• Représentativité. Les exemples doivent couvrir la distribution réelle de vos données en production — les cas fréquents, mais aussi les cas limites qui posent problème.
• Validation experte. Chaque exemple doit avoir une sortie attendue validée par un expert métier, pas générée automatiquement. Un golden eval set auto-généré n'est pas un golden eval set.
• Taille suffisante. Minimum 100 à 200 exemples pour une tâche de classification avec plusieurs classes. En dessous de 50, les métriques ont des intervalles de confiance trop larges pour être exploitables.
• Gel immédiat. Dès que le set est validé, plus personne n'y touche — même pour corriger ce qui semble être une erreur. Les corrections vont dans le jeu d'entraînement suivant.

Le golden eval set est aussi ce qui permet de comparer des versions successives du modèle sur une base stable. Sans lui, chaque itération repart d'une évaluation subjective "à l'œil". Pour en savoir plus sur la préparation des données en amont, notre guide sur la préparation du dataset de fine-tuning couvre ce sujet en détail.

Split train / validation / test : les pièges courants

Un fine-tuning bien conduit utilise trois ensembles distincts. La confusion entre leurs rôles est à l'origine de la plupart des erreurs d'évaluation qu'on rencontre.

• Train set : les données sur lesquelles le modèle apprend. Il peut les voir autant de fois que nécessaire.
• Validation set : les données utilisées pendant l'entraînement pour surveiller la loss de validation et décider quand arrêter (early stopping). Le modèle ne s'entraîne pas dessus, mais le processus d'entraînement s'y ajuste indirectement.
• Test set : le jeu de test final, qu'on n'ouvre qu'une seule fois — après avoir choisi la configuration finale du modèle. C'est là qu'on mesure les vraies performances.

Le piège le plus fréquent : utiliser le jeu de validation pour sélectionner le meilleur checkpoint, puis le réutiliser comme jeu de test final. À ce stade, la validation set est "contaminée" par toutes les décisions d'entraînement prises en la regardant. Les performances mesurées seront optimistes.

Autre piège : le data leakage entre les ensembles. Il ne suffit pas de s'assurer qu'aucun exemple n'est identique — il faut aussi dédupliquer sémantiquement. Sur des données textuelles, deux exemples peuvent être quasi-identiques avec des formulations légèrement différentes. Sur des données chronologiques (tickets de support, emails clients), un split temporel est presque toujours plus fiable qu'un split aléatoire : on entraîne sur le passé, on évalue sur le futur.

Métriques par type de tâche : ce qu'il faut mesurer

La métrique à utiliser dépend de la tâche. Voici le tableau de référence qu'on utilise sur nos projets.

Type de tâche	Métrique principale	Outil recommandé
Classification (classes équilibrées)	Accuracy, F1 macro	DeepEval, scikit-learn
Classification (classes déséquilibrées)	F1 weighted, ROC-AUC par classe	DeepEval, scikit-learn
Extraction d'entités (NER)	F1 token-level, exact match	DeepEval, seqeval
Extraction de données structurées	Exact match par champ, F1	DeepEval
Génération de texte (résumé, rédaction)	LLM-as-judge (GPT-4o / Claude)	LangFuse, DeepEval
Questions-réponses sur documents	Faithfulness, answer relevancy	RAGAS, DeepEval
Capacités générales (régression)	MMLU, ARC, Hellaswag	lm-eval-harness

Quelques précisions sur le LLM-as-judge : pour les tâches génératives où la sortie attendue n'est pas unique, demander à un LLM plus puissant de noter les sorties sur des critères définis (pertinence, fidélité aux faits, respect du style) est souvent plus fiable que ROUGE ou BLEU. LangFuse intègre ce mécanisme nativement et permet de stocker les évaluations, de les tracer et de les comparer entre versions.

Pour les pipelines qui combinent fine-tuning et RAG, RAGAS propose des métriques spécialisées — faithfulness (le modèle répond-il uniquement à partir des documents fournis ?), answer relevancy, context precision — qui mesurent la qualité du système complet, pas seulement du modèle fine-tuné.

Exact match vs F1 : quand utiliser lequel

L'exact match est strict : la sortie du modèle doit être identique à la référence. C'est adapté quand la sortie est courte et bien définie (un code produit, une catégorie précise, une date). Pour des extractions plus longues ou des réponses où plusieurs formulations correctes existent, le F1 token-level est plus juste — il récompense les correspondances partielles.

Sur les tâches d'extraction de données structurées (factures, contrats), on mesure l'exact match champ par champ. Un modèle qui extrait correctement le numéro de facture mais rate la date obtient un score par champ, pas un score global qui masquerait les erreurs.

LLM-as-judge : les limites à connaître

Le LLM-as-judge a un biais de position (il tend à préférer la première réponse présentée) et un biais de longueur (il préfère les réponses plus longues à qualité égale). Pour minimiser ces biais : présenter les réponses dans un ordre aléatoire, définir une grille de notation explicite avec des critères et des niveaux, et valider régulièrement un échantillon des jugements LLM avec un expert humain. L'accord humain-LLM doit dépasser 80 % pour que l'évaluation soit fiable.

Détecter l'overfitting et la régression des capacités générales

Les signaux d'overfitting à surveiller

Au-delà de la divergence training/validation loss, d'autres signaux méritent attention :

• Performances parfaites sur le train set, mauvaises sur le test set. Écart supérieur à 10-15 points de F1 entre les deux : signal fort d'overfitting.
• Sorties trop courtes ou trop formatées. Le modèle a sur-appris la structure exacte des exemples d'entraînement et les reproduit presque mécaniquement, même quand la question est différente.
• Performances qui s'effondrent sur des paraphrases. Si le modèle répond bien à "Quelle est la date de livraison ?" mais échoue sur "Quand est-ce que la commande arrive ?", il a mémorisé des formulations plutôt que compris la tâche.

Les remèdes classiques : réduire le nombre d'epochs, augmenter le dropout, réduire le learning rate, ou augmenter le jeu d'entraînement (data augmentation par paraphrase, par exemple). Parfois, le modèle de base est tout simplement trop petit pour la tâche — dans ce cas, le fine-tuning converge vite vers l'overfitting quel que soit le réglage.

Tester la régression des capacités générales

C'est la dimension qu'on oublie le plus souvent : un fine-tuning peut améliorer les performances sur la tâche cible tout en dégradant les capacités générales du modèle. C'est ce qu'on appelle le catastrophic forgetting — ou dans sa version atténuée, une régression partielle.

Concrètement : un modèle fine-tuné sur la classification d'emails peut se mettre à produire des réponses incohérentes quand on lui pose une question hors de sa tâche. En production, si le modèle est utilisé dans un contexte plus large (assistant interne, pipeline multi-étapes), ce genre de régression peut causer des erreurs silencieuses difficiles à diagnostiquer.

La solution : évaluer le modèle fine-tuné sur les benchmarks du modèle de base avant de déployer. lm-eval-harness (EleutherAI) permet de lancer en quelques lignes les benchmarks MMLU, ARC, Hellaswag et de comparer les scores avant/après fine-tuning. Une régression de plus de 5 points sur MMLU mérite investigation — elle indique que le fine-tuning a trop modifié les poids généraux du modèle.

LoRA et QLoRA limitent ce risque (les poids du modèle de base restent gelés), mais ne l'éliminent pas complètement. Notre guide sur LoRA et QLoRA pour le fine-tuning LLM détaille les paramètres (rang, alpha, dropout) qui jouent sur ce compromis.

Les pièges les plus fréquents en évaluation de fine-tuning

Quelques erreurs qu'on voit régulièrement et qu'il vaut mieux nommer clairement :

• Se fier à la loss seule. La validation loss descend → tout va bien. Non. On a vu des modèles avec une validation loss excellente et des performances métier catastrophiques sur des formulations légèrement différentes de celles du dataset.
• Un eval set trop petit. 20 exemples, c'est un test informel. Avec 20 exemples, une variation d'une bonne réponse change les métriques de 5 points. C'est du bruit, pas un signal.
• Juger à l'œil sans set figé. "On a testé quelques cas et ça a l'air bien" n'est pas une évaluation. Le problème : on teste inconsciemment les cas où on sait que le modèle fonctionne. L'eval set figé et préconstitué est là précisément pour éviter ce biais de sélection.
• Évaluer sans comparer au modèle de base. Si le modèle de base atteint déjà 85 % de F1 sur votre tâche avec du prompting, et que le modèle fine-tuné atteint 87 %, l'amélioration est marginale par rapport au coût. Il faut toujours avoir une baseline. Notre article sur l'évaluation générale d'un LLM couvre comment établir cette baseline.
• Ne pas tester la régression. Le modèle améliore la classification de tickets de 10 points. Et personne ne vérifie ce qu'il produit sur d'autres tâches. Deux mois plus tard, une anomalie en production difficile à relier au fine-tuning.

Pour aller plus loin

• Évaluer un LLM sur votre cas d'usage métier : l'évaluation générale et les benchmarks, avant même de commencer à fine-tuner.
• Top outils d'évaluation et d'observabilité LLM : comparatif complet de LangFuse, DeepEval, RAGAS, W&B et consorts.
• Préparer un dataset de fine-tuning LLM : comment constituer, nettoyer et valider vos données d'entraînement avant de lancer.
• Catastrophic forgetting en fine-tuning LLM : comprendre et limiter la régression des capacités générales.
• Guide LoRA et QLoRA pour le fine-tuning LLM : les paramètres qui font la différence sur la régression et la généralisation.
• Fine-tuning LLM en PME : quand ça vaut le coup : la décision en amont — fine-tuning vs RAG, budget, cas d'usage adaptés.
• Notre service d'expert en fine-tuning LLM et NLP : cadrage, entraînement, évaluation rigoureuse et déploiement.
• lm-eval-harness (EleutherAI) : la référence open source pour évaluer la régression sur les benchmarks généraux.
• Documentation RAGAS : métriques spécialisées pour les pipelines RAG alimentés par un modèle fine-tuné.

En résumé : évaluer sérieusement, pas se rassurer

Un fine-tuning bien conduit sans évaluation rigoureuse, c'est un modèle qu'on déploie en espérant. Et en production, espérer ne suffit pas.

Les points non négociables : golden eval set constitué avant l'entraînement, splits train/validation/test proprement isolés, métriques tâche-spécifiques en plus de la loss, test de régression sur les capacités générales. Et des outils — W&B pour les courbes d'entraînement, DeepEval ou LangFuse pour les métriques post-entraînement, lm-eval-harness pour la régression — pas un jugement à l'œil sur cinq exemples choisis.

La bonne nouvelle : ce travail d'évaluation n'est pas long si on s'y prend au bon moment. Constituer le golden eval set avant de lancer l'entraînement prend quelques heures. Le négliger en coûte des semaines.