Évaluation post-adaptation

Pourquoi ce chapitre est le plus utile

La courbe de perte qui décroît pendant l'entraînement ne dit rien de ce qui compte réellement : le modèle est-il meilleur sur la tâche visée, et n'a-t-il rien perdu ailleurs ? Un fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire peut afficher une perte d'entraînement excellente tout en produisant un modèle inutilisable en production, parce que la perte mesure l'ajustement statistique aux données d'entraînementdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, pas la qualité perçue par un utilisateur ni la préservation des capacités générales du modèle de base.

Ce chapitre s'appuie sur les données d'instruction et les mécanismes d'entraînement vus précédemment pour répondre à la question qui suit immédiatement un entraînement terminé : comment savoir, avec un niveau de confiance suffisant, si ce modèle mérite d'être déployé ? La réponse ne tient jamais en une seule métrique.

Ce que la perte d'entraînement ne mesure pas

La perte (loss) calculée pendant l'entraînement quantifie l'écart entre les prédictions du modèle et les tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire cibles du jeu d'entraînement, token par token. Une perte qui décroît régulièrement indique que le modèle apprend à reproduire les patterns présents dans ce jeu de données précis — rien de plus.

Cette mesure ne capture ni la qualité perçue d'une réponse, ni sa pertinence factuelle, ni le maintien des capacités générales du modèle sur des tâches absentes du jeu d'entraînement. Un modèle peut afficher une perte de validation excellente et pourtant régresser fortement sur du raisonnement mathématique, de la traduction ou du code — des compétences qui n'apparaissaient pas ou peu dans le jeu d'adaptation.

Une perte de validation basse garantit uniquement que le modèle a bien convergé sur la distribution du jeu de données utilisé. Elle ne renseigne ni sur le comportement du modèle hors de cette distribution, ni sur la satisfaction d'un utilisateur final. Aucune décision de mise en production ne devrait s'appuyer sur la seule courbe de perte.

L'évaluation post-adaptation répond à cette limite en introduisant des mesures indépendantes du processus d'entraînement, construites spécifiquement pour révéler ce que la perte ne voit pas.

Couche 1 : les benchmarks académiques pour détecter l'oubli catastrophique

Le fine-tuningaffinageIAPoursuite de l'entraînement d'un modèle existant sur des données propres à un usage. Il enseigne une manière de répondre, non des connaissances fiables — d'où la préférence pour le RAG en entreprise.Voir dans le glossaire modifie les poids du modèle, et cette modification n'est jamais parfaitement isolée à la tâche visée. Un réentraînement trop agressif — taux d'apprentissage trop élevé, trop d'époques, jeu de données trop étroit — peut dégrader des capacités générales que le modèle possédait avant l'adaptation. Ce phénomène porte un nom : l'oubli catastrophique (catastrophic forgetting).

Les benchmarks académiques standardisés servent de filet de sécurité contre cette dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire :

• MMLU (Massive Multitask Language Understanding) — connaissance générale et raisonnement sur 57 domaines, du droit à la médecine en passant par l'histoire
• GSM8K — problèmes mathématiques de niveau primaire à collège, sensibles à la dégradation du raisonnement séquentiel
• HellaSwag — complétion de phrases nécessitant du sens commun, révélatrice d'une perte de cohérence contextuelle
• HumanEval ou équivalents — génération de code, pertinent si le modèle de base était utilisé pour des tâches de développement

La méthode correcte consiste à exécuter ces benchmarks sur le modèle de base et sur le modèle fine-tuné, dans les mêmes conditions (mêmes prompts système, même format de sortie attendu, même méthode de notation), puis à comparer l'écart. Un score qui chute de plusieurs points sur un benchmark totalement indépendant de la tâche d'adaptation est un signal d'alerte, même si le modèle progresse par ailleurs sur la tâche visée.

Une légère baisse sur des benchmarks généraux, en échange d'un gain substantiel sur la tâche métier ciblée, peut rester un compromis acceptable — c'est précisément l'objet du fine-tuning que de spécialiser un modèle. Le seuil de tolérance dépend du périmètre réel d'usage : un modèle dédié à une tâche unique et fermée (classification, extraction) tolère une baisse plus large sur des capacités jamais sollicitées en production qu'un modèle conversationnel généraliste partiellement spécialisé.

Couche 2 : la suite d'évaluation métier

Aucun benchmark académique ne mesure ce pour quoi le fine-tuning a été entrepris. Un modèle adapté pour classer des tickets de support selon une taxonomie interne, ou pour produire des résumés de contrats dans un format précis, doit être évalué sur des cas représentatifs de cet usage exact — construits en interne, pas empruntés à une bibliothèque publique.

Construire cette suite suppose de réunir un jeu de testjeu de testIAPartie des données réservée à l'évaluation finale, à n'utiliser qu'une seule fois. Ajuster le modèle d'après ses résultats sur ce jeu lui ôte toute valeur de mesure indépendante.Voir dans le glossaire disjoint du jeu d'entraînement, idéalement extrait à part avant tout entraînement pour éviter toute fuite. Trois familles de métriques s'y combinent généralement :

• Métriques automatiques strictes — exactitude de classification, correspondance exacte de format, taux d'erreur de structure JSON. Rapides, reproductibles, mais aveugles à la nuance sémantique.
• LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire-juge — un modèle tiers (souvent plus puissant que le modèle évalué) note la réponse selon une grille de critères explicite (exactitude, complétude, ton, respect des consignes).
• Revue humaine sur échantillon — un sous-ensemble de sorties, généralement 50 à 200 cas selon le volume disponible, relufonction d'activationIAOpération non linéaire appliquée en sortie d'un neurone. Sans elle, empiler des couches serait inutile : une succession d'opérations linéaires reste équivalente à une seule.Voir dans le glossaire par une personne connaissant le métier, pour calibrer et détecter ce que les deux méthodes précédentes manquent.

Avant de généraliser un LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire-juge à l'ensemble du jeu de test, faites-le noter un sous-ensemble déjà évalué par un humain et mesurez l'accord entre les deux (taux de concordance ou corrélation). Un LLM-juge mal calibré — grille de notation ambiguë, biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire de position en faveur de la première réponse présentée, biais de longueur qui favorise les réponses plus verbeuses — produit un classement qui semble rigoureux mais ne reflète pas la qualité perçue réellement par un utilisateur final.

Les biais connus du LLM-juge

Le recours à un LLM comme évaluateur automatique s'est généralisé parce qu'il passe à l'échelle là où la revue humaine ne le permet pas. Il porte cependant des biais documentés qu'il faut neutraliser par construction :

• Biais de position — dans une comparaison A/B, le juge favorise légèrement la réponse présentée en premier ; la parade consiste à inverser l'ordre sur la moitié des cas.
• Biais de longueur — les réponses plus longues paraissent plus complètes à qualité égale ; une grille qui pénalise la verbosité inutile compense cet effet.
• Biais d'auto-préférence — un modèle juge note mieux les réponses stylistiquement proches de sa propre famille ; un juge d'une famille différente du modèle évalué réduit ce risque.
• Sensibilité au promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire du juge — une grille vague (« évalue de 1 à 10 ») produit des scores peu reproductibles ; des critères binaires ou une échelle ancrée par des exemples améliorent la cohérence.

Couche 3 : le jeu de non-régression

La troisième couche vérifie ce qui se passe en dehors du périmètre visé par le fine-tuning : le modèle continue-t-il de refuser les requêtes qu'il refusait avant, garde-t-il un ton cohérent sur des questions hors sujet, ne développe-t-il pas de biais de format qui casse des intégrations en aval ?

Ce jeu, souvent appelé golden set, rassemble des cas figés — comportements de sécurité, exemples de ton attendu, cas limites déjà rencontrés en production, formats d'entrée inhabituels — rejoués identiquement à chaque nouvelle version du modèle. Contrairement à la suite métier qui évolue avec les besoins, le golden set doit rester stable pour permettre une comparaison dans le temps.

Une équipe fine-tune un modèle pour produire des réponses plus concises sur des tickets de support. Le gain de concision est confirmé sur la suite métier. Le golden set révèle en parallèle que le modèle, devenu plus terse par habitude acquise pendant l'entraînement, tronque désormais certaines réponses à des questions de sécurité qui nécessitaient auparavant un développement complet — un comportement jamais présent dans le jeu d'entraînement mais induit par le style général appris. Sans golden set, cette régression serait passée inaperçue jusqu'à un incident en production.

Pièges statistiques dans la comparaison de modèles

Comparer deux modèles sur un score agrégé unique masque souvent des écarts qui ne sont pas statistiquement significatifs, en particulier sur des jeux de test de taille modeste.

• Taille d'échantillon insuffisante — un écart de deux points sur cent exemples n'est souvent pas distinguable du bruit d'échantillonnage ; un intervalle de confiance (bootstrap, par exemple) doit accompagner tout score comparatif.
• Contamination du jeu de test — si des exemples du jeu d'évaluation ont fuité, même partiellement, dans le jeu d'entraînement (doublons, reformulations proches), le score mesuré surestime la capacité de généralisation réelle.
• Sur-optimisation sur un jeu de validation réutilisé — ajuster les hyperparamètreshyperparamètreIARéglage choisi avant l'entraînement — vitesse d'apprentissage, taille du modèle, nombre d'itérations. Il se distingue des paramètres, ajustés automatiquement pendant l'entraînement.Voir dans le glossaire en observant systématiquement le même jeu de validation finit par le surajuster indirectement ; un jeu de test final, consulté une seule fois, reste nécessaire.
• Agrégation qui masque l'hétérogénéité — un score moyen stable peut recouvrir une amélioration marquée sur une sous-catégorie et une dégradation sur une autre ; une ventilation par catégorie de tâche est indispensable.

Deux modèles avec un score global identique peuvent avoir des profils d'erreur radicalement différents. Ventiler les résultats par type de requête, longueur d'entrée ou langue permet souvent d'identifier qu'un modèle excelle sur un sous-ensemble critique du trafic réel et échoue sur un autre, information perdue dans une moyenne unique.

Tableau comparatif des trois couches d'évaluation

Déploiement progressif et monitoring continu

Une évaluation hors ligne, aussi rigoureuse soit-elle, ne remplace pas l'observation en conditions réelles. Le trafic de production expose des distributions d'entrée que même un jeu de test soigné ne couvre pas intégralement.

La pratique la plus robuste consiste à déployer le modèle fine-tuné en canary : une fraction limitée du trafic (souvent 5 à 10 % au départ) lui est routée, en parallèle du modèle actuellement en production, avec un suivi des mêmes métriques que celles utilisées hors ligne — taux d'erreur de format, taux d'escalade humaine si applicable, signaux de satisfaction disponibles. La bascule complète n'intervient qu'après une période d'observation suffisante pour détecter des dérives à faible fréquence, invisibles sur un échantillon d'évaluation restreint.

Le déploiement d'un modèle fine-tuné devrait toujours prévoir un chemin de retour rapide vers la version précédente, sans dépendre d'un nouveau cycle d'entraînement : une régression détectée en production, même mineure en apparence, doit pouvoir être annulée en quelques minutes plutôt qu'en quelques jours.

Checklist avant de valider un modèle fine-tuné

• Les benchmarks académiques généraux ont été rejoués sur le modèle de base et le modèle fine-tuné, dans des conditions identiques
• La suite d'évaluation métier repose sur un jeu de test disjoint du jeu d'entraînement, sans fuite ni doublon proche
• Le LLM-juge utilisé, s'il y en a un, a été calibré contre un échantillon noté par un humain avant d'être généralisé
• Les biais connus du LLM-juge (position, longueur, auto-préférence) ont été neutralisés par construction du protocole
• Un golden set de non-régression, incluant des cas de sécurité et de format, a été rejoué intégralement
• Les écarts de score entre modèles s'accompagnent d'un intervalle de confiance, pas d'une seule valeur ponctuelle
• Les résultats ont été ventilés par catégorie de tâche, pas seulement présentés sous forme de score agrégé
• Un déploiement progressif (canary) et un chemin de rollback rapide sont prévus avant la bascule complète

Ce qu'il faut retenir avant le chapitre suivant

L'évaluation post-adaptation ne se résume jamais à une seule métrique : elle combine des benchmarks généraux pour surveiller l'oubli catastrophique, une suite métier pour quantifier le gain réellement recherché, et un jeu de non-régression pour garantir que le comportement hors périmètre reste stable. Chacune de ces couches répond à une question différente, et l'absence d'une seule d'entre elles laisse une zone aveugle susceptible de se transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire en incident de production. Le déploiement progressif avec monitoring continu complète ce dispositif hors ligne en exposant le modèle à une distribution de trafic qu'aucun jeu de test ne reproduit parfaitement. Le chapitre suivant s'appuie sur ces résultats d'évaluation pour aborder les stratégies de déploiement et de maintenance d'un modèle fine-tuné dans la durée.