Évaluer un modèle sur ses propres tâches
L’unité expérimentale n’est pas le nom du modèle. C’est l’ensemble suivant :
poids + quantification + moteur d’exécution + template + politique de contexte
+ paramètres de génération + outils + cadre d’évaluation (harness) + matériel
Le résultat appartient à cette configuration complète. Pour comparer un facteur, comme la quantification, modifiez-le délibérément en gardant les autres réglages constants. Si plusieurs composants changent à la fois, vous ne pouvez pas isoler celui qui explique la différence.
La même méthode vaut pour les modèles accessibles par API : poids, quantification, moteur d’exécution et matériel sont remplacés par le fournisseur et l’identifiant complet du modèle, et tout le reste reste fixe. Choisir entre les modèles de deux fournisseurs se fait avec la même fiche d’exécution et les mêmes tâches que choisir entre Q4 et Q6 d’un même modèle.
Ce protocole compare des configurations complètes sur des tâches, sans refaire un classement global des modèles. Avant de chronométrer, distinguez les étapes d’inférence. Avant de fixer des seuils d’action, étudiez la calibration des probabilités. Si les tâches dépendent de preuves issues d’une recherche, utilisez l’évaluation de la recherche et de la génération pour distinguer les causes d’échec.
Figer une fiche d’exécution
Avant de commencer les tests, définissez et consignez explicitement les réglages suivants dans une fiche d’exécution :
model: organization/model (pour un modèle par API : fournisseur et identifiant complet renvoyé dans la réponse)
revision: commit immuable ou hash de l’artefact
artifact: nom de fichier exact et format de quantification
runtime: nom, version, backend, pilote
template: chat/raisonnement/analyseur d’appels d’outils
context: limite native, longueur demandée, type de cache KV
generation: temperature, top-p, longueur maximale de sortie, seed si pris en charge
effort: effort de raisonnement ou budget de réflexion, réglages des sous-agents
cache: cache de prompt/préfixe activé ou non, froid ou préchauffé
hardware: GPU, VRAM, RAM, stratégie de déport vers le CPU
harness: version, outils disponibles, permissions, budgets d’itération
Conservez cette fiche avec les résultats bruts et les exemples d’échec.
Niveaux d’évaluation
1. Tests d’intégration élémentaires
Écartez les défauts du template ou du serveur avant d’évaluer la qualité du modèle. La liste de contrôle comprend :
- Une conversation simple.
- Une sortie JSON exacte.
- Un appel d’outil valide accompagné d’un distracteur hostile.
- Un appel mal formé ou refusé.
- Des textes multilingues pertinents pour l’usage prévu.
- L’annulation.
- Un cas situé à la limite du contexte.
Exécutez le test d’appel d’outil avec un cache de prompt froid puis chaud. Un ticket llama.cpp ouvert le 23 septembre signale qu’avec tool_choice: "required", un serveur Qwen3-8B répondait parfois en texte brut, les échecs se concentrant sur les requêtes qui réutilisaient un préfixe de cache chaud ; cache désactivé, les mêmes requêtes appelaient l’outil. Il s’agit d’une reproduction par un seul utilisateur. Au 29 octobre, le ticket est toujours ouvert, sans réponse des mainteneurs, et un robot l’a marqué stale le 24 octobre ; mais il montre que l’état du cache a sa place dans la fiche d’exécution.
2. Rejeu de tâches personnelles
Choisissez 10 à 30 tâches représentatives assorties de critères d’acceptation externes.
- Tâches de programmation : correction de défauts, préservation d’une API sur plusieurs fichiers, diagnostic de tests, traitement d’une documentation inconnue, preuves insuffisantes et action hors périmètre.
- Travail documentaire : extraction avec citations, sources contradictoires, questions temporelles et abstention.
Quand l’acceptation doit être jugée par un autre modèle, vérifiez d’abord cet évaluateur sur des exemples étiquetés à la main, comme l’explique l’évaluation de la recherche et de la génération.
3. Comportement du système
Préchauffez le moteur d’exécution avant les mesures. Consignez ensuite :
- Le taux de résultats acceptés : la part des exécutions qui passent les critères d’acceptation écrits à l’avance pour chaque tâche.
- Le taux d’échec pondéré par la gravité : chaque échec reçoit un poids selon ses conséquences (casser des fichiers sans rapport pèse plus qu’une petite faute de format) ; on additionne les poids et on divise par le nombre d’exécutions.
- La latence médiane jusqu’au premier token et les valeurs dans la queue de distribution.
- La vitesse de décodage.
- La durée médiane de bout en bout et les valeurs dans la queue de distribution.
- Les pics de VRAM et de RAM.
- Le déport de calcul ou de données vers le CPU (offload).
- Le nombre de nouvelles tentatives.
- La validité des appels d’outils.
- Le nombre de modifications hors sujet.
- Le nombre d’interventions humaines.
Traitez l’effort de raisonnement comme un facteur à tester, pas comme un curseur qu’on pousse toujours vers le haut. Anthropic indique que Sonnet 5.5 obtient un score FrontierCode plus bas en effort Max qu’en Xhigh. En Max, il lançait plus souvent une revue de code répartie entre de nombreux sous-agents ; dans deux cas examinés par Cognition, entreprise de programmation par IA, cela a provoqué un dépassement de délai ou des modifications hors du périmètre. Les modèles locaux dotés d’un budget de réflexion peuvent échouer de la même façon ; comparez donc au moins deux niveaux à budget de temps égal.
Exemple de comparaison
Supposons que les versions Q4 et Q6 d’un même modèle 7B (des fichiers quantifiés qui stockent chaque poids sur environ 4 et 6 bits) soient chacune testées sur 20 tâches, chaque tâche étant répétée 3 fois :
La décision dépend du niveau de risque acceptable. Si les 6 exécutions acceptées de plus reflètent une vraie différence, elles peuvent justifier Q6 pour les opérations d’écriture, tandis que Q4 reste utile pour le tri en lecture seule.
Savoir si ces 6 exécutions sont une vraie différence dépend de l’incertitude : avec de petits échantillons, indiquez donc les effectifs et l’incertitude, pas seulement les pourcentages. Calculons-la pour ce tableau : 42/60 font 70 %, 48/60 font 80 %. Par l’approximation normale, les demi-largeurs des intervalles à 95 % pour 60 exécutions valent 1,96×√(0,7×0,3/60) ≈ 12 points et 1,96×√(0,8×0,2/60) ≈ 10 points, soit des intervalles d’environ 58 %–82 % et 70 %–90 %, qui se recouvrent largement. De plus, ces 60 exécutions ne sont que 20 tâches répétées 3 fois, et les trois exécutions d’une même tâche sont corrélées : les vrais intervalles sont encore plus larges. L’écart de 6 exécutions ne suffit pas pour conclure. Conservez les résultats par tâche pour vérifier qu’un gain ne vient pas d’une seule catégorie facile répétée plusieurs fois.
Tests de quantification et de contexte
Pour comparer des artefacts quantifiés, gardez le moteur d’exécution, le prompt et les paramètres de génération constants.
- Incluez des tests de modification exacte et d’appel d’outils : les moyennes des benchmarks linguistiques peuvent masquer une dégradation du format.
- Testez d’abord la longueur de contexte native, puis augmentez-la avec des distracteurs et des preuves placées à différents endroits.
Le même nom de modèle peut cacher un autre modèle
Avec une API, le nom écrit dans votre code ne désigne pas toujours le même modèle. Les pages de modèles d’OpenAI listent des instantanés datés sous chaque nom, et la page gpt-4o indique que les instantanés figent une version précise pour que performances et comportement restent constants. La vue d’ensemble des modèles d’Anthropic précise qu’à partir de la génération 4.6, chaque identifiant de modèle est lui-même un instantané figé, y compris les identifiants sans date ; pour les modèles antérieurs, l’alias n’est qu’un raccourci vers l’identifiant daté.
Consignez donc dans la fiche d’exécution l’identifiant complet que l’API renvoie réellement dans sa réponse, pas le nom court de votre code. Relancez les mêmes tâches dans trois cas : l’identifiant renvoyé change ; le fournisseur envoie un avis de dépréciation ou de migration ; une relance périodique montre une baisse nette du taux d’acceptation sur les mêmes tâches. Les prompts de vos propres utilisateurs s’éloignent aussi peu à peu des tâches choisies au départ : de temps en temps, ajoutez quelques nouvelles requêtes réelles à l’ensemble tenu à l’écart.
Benchmarks externes
lm-evaluation-harness, les évaluations de type HELM et les classements d’agents de programmation comme Terminal-Bench 4.0 fournissent des points de repère utiles ; choisir un agent de programmation IA consigne le classement d’octobre. Le classement polyglot d’Aider a été mis à jour pour la dernière fois le 2025-11-20 et ne contient aucun des modèles actuels : il ne sert plus que de référence historique. Aucun de ces benchmarks ne reproduit l’environnement d’un dépôt privé, les détails de la quantification locale, les permissions du cadre d’évaluation ou le coût des interventions humaines.
Avant d’utiliser un benchmark externe, vérifiez :
- La version des tâches.
- Le risque de contamination des données.
- L’adaptation des prompts.
- Le nombre d’échantillons.
- L’origine des scores : déclarés par le fournisseur ou reproduits indépendamment.
Biais et règle de décision
Ce à quoi une suite personnelle et une suite publique risquent chacune de trop s’adapter, et quelles tâches sont souvent surreprésentées, est détaillé dans juger les preuves dans les expériences d’IA. Pour ce protocole, cela revient à inclure des cas difficiles dont l’échec est connu et à ajouter régulièrement une nouvelle tâche tenue à l’écart de la mise au point (holdout).
Pour plusieurs configurations ou des examens répétés des résultats, Tests d’hypothèse, tailles d’effet et comparaisons multiples explique comment fixer à l’avance la famille de comparaisons et la règle d’arrêt.
Règle de décision : choisissez la plus petite configuration qui franchit le seuil de tâches défini à l’avance, avec une marge suffisante en VRAM et en mémoire globale, et un taux d’échecs graves acceptable. Recommencez l’évaluation après toute modification de la fiche d’exécution, pas seulement lorsqu’un nouveau classement paraît.
Le guide de l’interface en ligne de commande de lm-evaluation-harness explique la sélection des tâches, les limites d’échantillons, les fichiers de sortie et la journalisation des exemples individuels. La ligne de commande utilise désormais des sous-commandes : lm-eval run lance une évaluation, lm-eval ls liste les tâches et lm-eval validate vérifie les configurations de tâches ; l’ancienne forme sans sous-commande fonctionne toujours. Commencez avec --limit sur quelques exemples, ajoutez --output_path et --log_samples pour enregistrer les entrées et sorties de chaque exemple, et n’augmentez la taille qu’une fois les résultats vérifiables ; les résultats individuels aident à distinguer les erreurs de format des réponses incorrectes.