Aller au contenu

Comment évaluer un finetuning avant la mise en prod ?

Comment évaluer un finetuning avant la mise en prod ?

Évaluer un finetuning avant la prod revient à répondre à trois questions, pas une seule : est-ce que le modèle progresse vraiment sur la tâche visée, est-ce qu'il régresse ailleurs, et est-ce que l'écart mesuré est réel ou du bruit. Un finetuning qui gagne des points sur son propre jeu de test mais en perd sur des capacités qu'il maîtrisait déjà n'est pas un progrès. C'est un déplacement du problème, souvent invisible tant qu'on ne va pas le chercher.

Ce triptyque, tâche cible, canary set contre l'oubli catastrophique, holdout scellé, c'est ce qui sépare un finetuning qu'on peut shipper d'un finetuning qui a l'air bon dans le playground et qui déçoit en production.

J'ai déjà écrit sur le moment où finetuner devient pertinent, dans mon article sur comment entraîner un SLM et sur l'arbitrage entre RAG, finetuning et entraînement. Cet article couvre l'étape d'après, une fois que le finetuning est fait : comment savoir si vous avez le droit de le garder.

Pourquoi un finetuning qui semble réussi peut quand même être un mauvais choix

Un finetuning qui améliore la métrique qu'on surveille n'est pas automatiquement un bon finetuning. C'est le piège le plus courant, et il est rarement visible tant qu'on ne compare pas explicitement à la baseline.

OpenAI le formule directement dans son guide de bonnes pratiques de finetuning : ne pas shipper un modèle finetuné parce que les premiers exemples dans le playground ont l'air bons. La bonne méthode consiste à construire une baseline avant l'entraînement, rejouer exactement le même jeu d'évaluation après, et comparer le modèle finetuné au modèle de base et au meilleur prompt qu'on avait avant.

Ce qui casse silencieusement, c'est souvent hors du périmètre de la tâche qu'on vient de spécialiser. Un modèle finetuné pour classer des tickets de support peut perdre en route sa capacité à répondre correctement à une question générale, à respecter des consignes de sécurité, ou à raisonner sur un cas qui ressemble à sa nouvelle tâche sans en faire vraiment partie. Rien dans le score de la tâche cible ne le révèle.

Le triptyque d'évaluation : tâche cible, canary set, holdout scellé

Évaluer sérieusement un finetuning demande trois jeux de données différents, avec des rôles qui ne se recouvrent pas.

  • Le holdout de la tâche cible, un jeu d'exemples représentatifs de ce que le finetuning devait améliorer, jamais vu pendant l'entraînement. C'est lui qui mesure le progrès. Pour une tâche de classification, je regarde le F1 par classe et la matrice de confusion plutôt qu'une accuracy globale, exactement la discipline que je détaille dans mon article sur la classification d'intentions et la gestion de l'incertitude.
  • Le canary set, un petit jeu de cas que le modèle de base traitait déjà bien avant le finetuning, sur des capacités qui n'ont rien à voir avec la nouvelle tâche. Son seul rôle est de sonner l'alarme si le modèle a régressé ailleurs.
  • Le holdout scellé, la couche de sécurité finale. On le construit tôt, personne n'y touche, personne ne l'inspecte pendant les itérations, et on ne le fait tourner qu'une seule fois, juste avant la décision de shipper.

Ces trois jeux ne se substituent pas les uns aux autres. Un modèle peut très bien progresser sur son holdout de tâche et régresser sur le canary set. C'est précisément le scénario que ce triptyque est conçu pour attraper.

Détecter l'oubli catastrophique avant qu'il ne coûte cher en production

L'oubli catastrophique (catastrophic forgetting), c'est la dégradation de capacités déjà acquises pendant qu'un modèle en apprend une nouvelle. Ce n'est pas une hypothèse théorique, c'est mesuré. Une étude de 2023 (arXiv 2308.08747) l'observe systématiquement sur des modèles de 1 à 7 milliards de paramètres pendant un finetuning continu, et montre un résultat contre-intuitif : la sévérité de l'oubli augmente avec la taille du modèle finetuné, pas l'inverse. Un gros modèle ne protège pas automatiquement contre ce risque.

Pour le détecter avant qu'il ne se voie en production, le canary set doit couvrir au moins deux familles de cas :

  • Des capacités générales, mesurées avec un benchmark standard comme MMLU, qu'on peut faire tourner via des outils comme le lm-evaluation-harness d'EleutherAI. Ça donne un signal indépendant de votre tâche métier, comparable avant et après le finetuning.
  • Des cas tirés de vos propres logs de production, sur des requêtes que le modèle de base traitait bien avant, en dehors du périmètre exact de la nouvelle tâche. C'est souvent plus parlant qu'un benchmark générique, parce que c'est ce que vos utilisateurs demandent vraiment.

Le signal à chercher n'est pas binaire. Une petite baisse peut être acceptable si le gain sur la tâche cible est net, une grosse baisse sur une capacité que vos utilisateurs sollicitent tous les jours ne l'est jamais, même avec un gain spectaculaire ailleurs.

Le delta face à la baseline compte, pas le score absolu

Un score isolé ne veut rien dire. Ce qui compte, c'est l'écart entre le modèle finetuné et sa propre baseline, mesuré sur exactement les mêmes exemples, avec la même grille, le même juge et la même semaine d'évaluation.

Le guide de bonnes pratiques d'évaluation d'OpenAI insiste sur ce point : on construit l'évaluation avant même de lancer le finetuning, on la fait tourner sur la baseline, puis sur le modèle finetuné, et on compare. Sans cette symétrie, une amélioration apparente peut n'être qu'un artefact de deux mesures prises dans des conditions différentes.

Deux pièges reviennent souvent sur un petit jeu de test :

  • Un delta de quelques points sur cinquante exemples ressemble plus à du bruit de mesure qu'à un vrai signal. Plus le holdout est petit, plus il faut se méfier d'un gain marginal.
  • Le juge qui évalue doit rester le même des deux côtés. Comparer un score jugé par GPT-4o-mini sur la baseline à un score jugé par un autre modèle sur le finetuné n'a aucun sens, même si les deux chiffres semblent comparables.

Sur ce point, la même discipline que j'applique à l'évaluation d'un RAG s'applique ici : les assertions déterministes d'abord, gratuites et reproductibles, le juge LLM ensuite pour ce qu'un test déterministe ne peut pas capturer. On ne saute jamais l'étage du dessous.

Ship, itérer ou revenir à la baseline : la grille de décision

Une fois les trois mesures en main, la décision se lit directement sur les résultats, sans y ajouter d'intuition.

Résultat mesuré Décision
Gain net sur le holdout de tâche, canary set stable Ship
Gain net sur le holdout de tâche, canary set en légère baisse tolérable Ship avec monitoring renforcé sur les capacités touchées
Gain marginal ou dans le bruit sur le holdout Itérer sur les données d'entraînement avant de rejuger
Gain sur la tâche mais dégradation nette du canary set Revenir à la baseline, ou réentraîner avec des exemples de rappel des capacités perdues
Aucun gain net face à la baseline avec un bon prompt Revenir à la baseline, le finetuning n'était pas justifié 
graph TD
    A["Modèle finetuné prêt"] --> B{"Delta net sur le\nholdout de tâche ?"}
    B -- Non --> C["Itérer sur les données\nou revenir à la baseline"]
    B -- Oui --> D{"Canary set stable ?"}
    D -- Non --> E["Rollback ou réentraîner\navec exemples de rappel"]
    D -- Oui --> F["Ship + monitoring continu"]

Revenir à la baseline n'est jamais un échec du projet. C'est exactement la même logique que celle qui a mené au finetuning au départ : mesurer plutôt que supposer, et n'accepter que ce que la mesure confirme. Sur le projet de classification d'intentions que je décris dans mon article sur le finetuning d'un SLM pour classer des intentions, c'est ce même triptyque qui a tranché la décision, dans un sens comme dans l'autre.

Surveiller un modèle finetuné après le déploiement

La mise en prod n'est pas la fin de l'évaluation, c'est le début d'un cycle plus lent. Vos données de production dérivent, et le modèle de base sur lequel repose le finetuning finira par être remplacé par une nouvelle version, souvent meilleure hors de la boîte.

Rejouer le même canary set et le même holdout à intervalle régulier, par exemple à chaque mise à jour significative des données ou du modèle de base, permet de détecter une dérive avant qu'elle ne remonte dans les métriques métier. C'est la même discipline de mesure qu'au moment du ship, juste répétée dans le temps plutôt que déclenchée une seule fois.

FAQ sur l'évaluation d'un finetuning

Comment savoir si un finetuning a vraiment marché ? En comparant le modèle finetuné à sa baseline sur trois choses : un holdout scellé jamais vu pendant l'entraînement, un canary set pour détecter l'oubli catastrophique, et un delta chiffré plutôt qu'un score isolé. Le finetuning n'a marché que si les trois voyants sont au vert en même temps.

Qu'est-ce que l'oubli catastrophique (catastrophic forgetting) ? La dégradation de capacités déjà acquises pendant qu'un modèle en apprend une nouvelle. Une étude de 2023 (arXiv 2308.08747) le mesure sur des modèles de 1 à 7 milliards de paramètres et montre que la sévérité augmente avec la taille du modèle continuellement finetuné.

Combien d'exemples faut-il dans un holdout scellé ? Pas de chiffre magique, mais un holdout de moins d'une cinquantaine d'exemples donne souvent un delta qui ressemble à du bruit de mesure. Ce qui compte le plus, c'est l'étanchéité : aucun exemple ne doit avoir traîné dans les données d'entraînement.

Faut-il comparer le modèle finetuné avec des tests déterministes ou un juge LLM ? Les deux, dans l'ordre. Les assertions déterministes attrapent la majorité des régressions gratuitement. Le juge LLM intervient ensuite pour ce qu'un test déterministe ne capture pas, la qualité sémantique d'une réponse ouverte.

Quand faut-il revenir à la baseline après un finetuning décevant ? Dès que le delta n'est pas net sur le holdout, ou que le canary set montre une dégradation sur des capacités qui comptaient avant. Un gain de 3 points sur la tâche cible qui en coûte 8 ailleurs n'est pas un progrès.

C'est quoi concrètement un canary set ? Un petit jeu de cas que le modèle de base traitait déjà bien avant le finetuning, gardé de côté pour vérifier qu'il les traite toujours bien après. Il peut mélanger un benchmark générique type MMLU et des exemples tirés de vos propres logs de production.

Faut-il réévaluer un modèle finetuné après sa mise en production ? Oui, régulièrement. Vos données dérivent et le modèle de base peut être remplacé par une nouvelle version. Rejouer le même canary set et le même holdout à intervalle régulier permet de détecter une dérive avant qu'elle ne se voie dans les métriques métier.

Pour aller plus loin

Si mes articles vous intéressent, que vous avez des questions ou simplement envie de discuter de vos propres défis liés à l'IA, n'hésitez pas à m'écrire à anas@tensoria.fr, j'adore échanger sur ces sujets !

Vous avez un finetuning en cours et vous hésitez à le mettre en production ? Découvrez mon activité de conseil sur tensoria.fr.

Vous pouvez aussi réserver un créneau d'échange ou vous abonner à ma newsletter :)

À propos de moi

Je suis Anas Rabhi, consultant Data Scientist freelance. J'accompagne les entreprises dans leur stratégie et mise en œuvre de solutions d'IA (RAG, Agents, NLP).

Découvrez mes services sur tensoria.fr ou testez notre solution d'agents IA heeya.fr.