Module 10 — Évaluation avant et après affinage

Un affinage sans évaluation soigneuse est une croyance, pas un résultat. Ce module explique comment mesurer honnêtement le gain d'un modèle affiné — sur la tâche visée et sur ce que le modèle savait déjà faire, ce dernier point étant celui que l'on oublie le plus souvent.

Le jeu de test tenu à l'écart

Le module 2 a réservé 10 % du jeu au test. Il faut maintenant tenir cette promesse : ce jeu n'a jamais été utilisé pendant l'entraînement, jamais été utilisé pour ajuster un hyperparamètre, jamais été regardé de près. Il est utilisé une seule fois, à la fin.

Cette discipline est la seule qui protège de l'illusion. Un modèle qui bat sa validation de deux points de perte peut ne rien gagner sur un test tenu à l'écart, parce que les choix d'hyperparamètres ont, sans qu'on s'en rende compte, sur-ajusté la validation. Le test est le juge de dernier ressort ; regardez-le, ajustez, regardez à nouveau, et vous n'avez plus de test.

Pour notre fil rouge — deux mille paires transcription vers compte rendu — le test compte deux cents exemples, découpés par identifiant de réunion (module 2) et conservés dans un fichier séparé versionné à part.

Trois types de métriques, pas une

Aucune métrique isolée ne dit tout sur un modèle de génération. Un tableau de bord d'évaluation en combine trois familles.

Métriques de format, automatiques

Pour un compte rendu structuré, la première chose à vérifier est que le format est respecté : les sections attendues sont présentes, les puces sont correctement formatées, les dates suivent la convention. Ces contrôles s'automatisent sans peine :

import re

def valider_format(texte):
    controles = {
        "section_decisions": bool(re.search(r"^## Decisions\b", texte, re.M)),
        "section_actions": bool(re.search(r"^## Points d'action\b", texte, re.M)),
        "puces_actions": bool(re.search(r"^- \[ \]", texte, re.M)),
        "date_iso": bool(re.search(r"\b\d{2}/\d{2}/\d{4}\b", texte)),
    }
    return controles

Cent pour cent de conformité est atteignable pour un modèle bien affiné, contre 30 à 60 % pour un modèle de base non affiné. Ce gain est le plus visible, et il est mesurable objectivement.

Métriques de contenu, semi-automatiques

Le contenu — les décisions extraites sont-elles réellement présentes dans la transcription ? — se mesure par des scores comme ROUGE-L, BLEU ou par la similarité cosinus entre plongements de la sortie et de la référence.

from evaluate import load

rouge = load("rouge")
scores = rouge.compute(predictions=predictions, references=references)
# scores["rougeL"] : recouvrement des sous-sequences plus longues

ROUGE-L — l'acronyme dévoile Recall-Oriented Understudy for Gisting Evaluation, variante à sous-séquence longue — mesure le recouvrement séquentiel entre la sortie du modèle et la référence humaine. Un gain de 0,05 à 0,15 est typique d'un affinage réussi sur cette tâche.

Attention aux limites : ces métriques punissent une reformulation légitime autant qu'une erreur factuelle. Elles indiquent une tendance, elles ne prononcent pas un verdict. Elles doivent être complétées par le troisième type.

Jugement humain en aveugle

L'évaluation qui compte vraiment est celle qu'un humain prononce sur la qualité perçue de la sortie. Elle doit être en aveugle — l'évaluateur ne sait pas quelle sortie vient du modèle de base et laquelle vient du modèle affiné — et elle doit porter sur un échantillon significatif — cinquante à cent paires suffisent pour un premier signal.

Le format le plus robuste est la comparaison par paires : on présente deux sorties à l'évaluateur pour la même entrée, il choisit laquelle est la meilleure, ou déclare l'égalité. Un modèle affiné qui bat le modèle de base sur 65 % des comparaisons, avec 15 % d'égalités et 20 % de défaites, est un modèle qui apporte une amélioration réelle et robuste.

Le piège des métriques qui montent tout le temps

Un affinage produit presque toujours des métriques qui montent sur le jeu de test — c'est ce pour quoi il a été entraîné. Cela ne prouve rien sur ce que le modèle a perdu au passage. Le module 3 a introduit l'oubli catastrophique ; il faut le mesurer.

La contre-mesure est d'évaluer le modèle affiné sur un jeu de capacités générales qui n'a rien à voir avec la tâche cible. Trois candidats de référence, gratuits et faciles à intégrer :

• MMLU — questions à choix multiples sur des dizaines de matières académiques ;
• HellaSwag — complétion de phrases plausibles ;
• ARC-Challenge — questionnement scientifique de niveau primaire à collège.

# Via lm-evaluation-harness
# pip install lm-eval

# lm_eval --model hf \
#   --model_args pretrained=./mistral-comptes-rendus-fusionne,dtype=bfloat16 \
#   --tasks mmlu,hellaswag,arc_challenge \
#   --batch_size 8

Un affinage sain montre une perte de 0,5 à 2 points sur ces jeux généralistes par rapport au modèle de base — signal que le modèle s'est spécialisé sans devenir stupide. Une perte supérieure à 5 points signale un affinage qui a trop tiré sur la corde : réduire le nombre d'époques, réduire le rang $r$, ou mélanger davantage d'exemples génériques dans le jeu d'entraînement.

La comparaison honnête, en un tableau

Voici ce à quoi ressemble un rapport d'évaluation utile pour notre fil rouge :

Métrique	Modèle de base	Modèle affiné	Écart
Format valide (%)	42	97	+55
ROUGE-L (contenu)	0,38	0,51	+0,13
Préférence humaine (vs base)	—	65 %	+65 pts
MMLU (5-shot)	0,614	0,598	-1,6 pts
HellaSwag	0,812	0,807	-0,5 pt
Latence par sortie (s)	4,1	4,1	0

Ce tableau raconte une histoire cohérente : la tâche visée est massivement améliorée, la qualité générale est très légèrement dégradée dans les limites acceptables, la latence n'a pas bougé. On peut déployer.

Ce qu'on regarde pour la prochaine itération

Une évaluation ne sert pas seulement à valider un modèle, elle sert à guider l'itération suivante. Trois questions à se poser à la lecture du tableau :

Sur quels sous-groupes le modèle échoue-t-il le plus ? Certains formats de réunion, certaines longueurs, certains domaines métier concentrent les erreurs. C'est là qu'il faut collecter ou générer davantage d'exemples pour la prochaine version.

Les échecs sont-ils de format ou de contenu ? Un modèle qui casse le format une fois sur vingt indique un jeu d'entraînement pas assez homogène. Un modèle qui invente des noms indique un défaut de contenu — souvent lié à des transcriptions bruitées non nettoyées.

La régression sur les capacités générales est-elle acceptable ? Si un cas d'usage annexe s'appuyait sur le modèle de base, un test dédié doit être ajouté à la prochaine évaluation.

Le test que vous n'avez pas fait

Le geste qui distingue le plus les affinages sérieux des amateurs : après avoir fait tourner toutes les métriques automatiques, prenez une heure pour lire à la main vingt sorties du modèle affiné et vingt du modèle de base. Cette heure trouve invariablement des motifs que les métriques n'ont pas remontés — une manie d'ajouter une conclusion, un préfixe qui échappe, un ton légèrement plus autoritaire. C'est le vrai jugement qui manque sinon.

En résumé

• Le jeu de test est tenu à l'écart, utilisé une seule fois ; le regarder plusieurs fois le rend inutile.
• Trois familles de métriques : format automatique, contenu semi-automatique (ROUGE, similarité), jugement humain en aveugle.
• Un affinage bien fait fait exploser les métriques de tâche et admet une légère régression (0,5 à 2 pts) sur les capacités générales.
• Le rapport final juxtapose gain de tâche et régression générale ; sans la seconde ligne, l'évaluation est incomplète.

Prochain arrêt : la récapitulation du cours et l'examen final.