Évaluez les AI models sur le travail que vous prévoyez de mettre en production, et non sur un leaderboard conçu pour la tâche de quelqu’un d’autre. Un benchmark public peut identifier un bon candidat. Il ne peut pas vous dire si ce modèle exécutera votre workflow de manière fiable.
Audience : Intermédiaire — développeurs, équipes produit et acheteurs techniques qui choisissent un modèle pour une application réelle.
Pour évaluer des AI models sur du travail réel, donnez à chaque candidat les mêmes tâches représentatives, évaluez l’état obtenu plutôt que la formulation, répétez chaque tâche, mesurez la latence et le coût, puis définissez une gate de déploiement autour des échecs que vous ne pouvez pas accepter. Le modèle gagnant est l’option la moins chère qui franchit régulièrement ces gates. Ce n’est pas nécessairement le modèle qui obtient le score moyen le plus élevé.
À quelles questions un benchmark d’AI model doit-il répondre ?
Un benchmark utile doit répondre à une question opérationnelle :
Cette phrase fait ressortir six détails :
Les benchmarks publics maintiennent généralement une combinaison différente de ces variables. Les model cards et release notes restent utiles : elles réduisent la liste des candidats et révèlent les modalités prises en charge, les limites de contexte, les tarifs et les comportements de sécurité connus. Les releases de juillet 2026 illustrent cette distinction. OpenAI a publié des résultats généraux de capacité et de sécurité pour GPT-5.6, tandis que Google a documenté une utilisation de tokens et un prix inférieurs pour Gemini 3.6 Flash par rapport à son précédent modèle Flash. Ce sont des a priori utiles, pas des mesures de votre prompt, de vos outils, de vos données ou de votre error budget. (OpenAI, Google)
L’étude de cas NVIDIA NIM free AI API→ montre comment un workflow de traduction peut transformer le choix d’un modèle en débit et cohérence mesurables. Pour les candidats de coding, commencez par la comparaison ciblée des free AI coding agents→. Faites ensuite passer la décision dans votre propre jeu de tests.
Pourquoi un score moyen unique masque le risque de production
Trois benchmarks récents exposent le même problème dans des domaines différents.
Le crédit partiel peut masquer un échec de bout en bout
APEX-Accounting évalue les modèles sur 160 tâches comptables réparties entre dix entreprises synthétiques, à l’aide de spreadsheets, de PDFs et d’autres fichiers. Des experts-comptables ont rédigé les tâches et les critères de réussite. Les chercheurs ont exécuté neuf frontier models huit fois par tâche, produisant 11 520 trajectoires.
Le modèle le plus performant a atteint 56,4 % selon la métrique de crédit partiel de l’article, Mean Criteria@3. Pourtant, aucun modèle n’a dépassé 2,6 % sur Pass^8, qui demande si les huit tentatives d’une tâche ont toutes réussi. Le meilleur Pass@8, qui demande si au moins une des huit tentatives a réussi, était de 21,5 %. Quatre-vingt-treize des 160 tâches n’ont jamais été parfaitement accomplies par aucun modèle testé, lors d’aucune exécution. (APEX-Accounting)
Les auteurs ont mesuré des tâches comptables de clôture dans un environnement synthétique contrôlé. Ils n’ont pas couvert la fiscalité, l’audit, la consolidation, les opérations multi-entités ou multi-devises, ni le reporting externe. Le jeu de tâches a également été filtré selon la difficulté à l’aide de trois frontier models, ce qui peut réduire les scores ou favoriser certaines familles de modèles. La conclusion pratique est plus limitée que « l’AI ne peut pas faire de comptabilité » : un modèle peut satisfaire de nombreux contrôles individuels tout en restant trop incohérent pour un workflow multi-étapes sans supervision.
Une sortie valide peut tout de même ignorer la contrainte de l’utilisateur
TREK teste des agents de planification de voyages sur 800 tâches, face à une base de connaissances synthétique contenant 212 530 enregistrements. Son évaluateur vérifie les règles et l’état final de manière déterministe, plutôt que de demander à un autre language model de juger le plan.
L’agent testé le plus performant a accompli parfaitement 46,2 % des tâches réalisables. Il était exempt d’hallucinations dans 94,9 % des cas et exécutable dans 86,3 % des cas, mais ne satisfaisait toutes les contraintes utilisateur que dans 50,7 % des cas. Le système pouvait produire des plans plausibles et réservables tout en manquant une préférence implicite ou une exigence entre plusieurs étapes. (TREK)
TREK utilise un univers de voyage synthétique, exclut les prix et disponibilités en temps réel et rapporte une seule exécution par agent. Sa comparaison du raisonnement est une observation en paire unique, entre versions, plutôt qu’une ablation contrôlée et appariée. Elle démontre néanmoins une règle d’évaluation durable : vérifiez l’état final et chaque contrainte impérative. La fluidité n’est pas l’accomplissement de la tâche.
Le benchmark lui-même peut être défectueux
Un audit d’OpenAI portant sur le split public de 731 tâches de SWE-Bench Pro a révélé une deuxième source de fausse confiance : des données d’évaluation défectueuses. Un pipeline automatisé a signalé 27,4 % des tâches comme défectueuses, tandis qu’un processus d’annotation mené par cinq ingénieurs en a marqué 34,1 %. Les problèmes comprenaient des prompts sous-spécifiés, des tests trop stricts et des tests permettant à des solutions incomplètes de réussir. OpenAI a estimé qu’environ 30 % du benchmark était défectueux et a retiré sa recommandation précédente de l’utiliser. (OpenAI benchmark audit)
Un test difficile n’est utile que lorsqu’un résultat de référence connu comme correct le réussit et qu’un résultat incorrect échoue pour la bonne raison.
Comment évaluer des AI models en sept étapes
1. Définissez la décision avant le test
Écrivez la décision de production en une ligne :
Adaptez les chiffres à votre produit. Conservez la structure. Un benchmark sans règle de décision favorise le cherry-picking une fois les résultats obtenus.
Séparez les gates strictes des métriques d’optimisation :
Un modèle qui enfreint une gate stricte est éliminé même lorsque son score moyen est supérieur.
2. Construisez les tâches à partir du travail, pas d’une démo
Commencez par des exemples réels et désidentifiés lorsque leur utilisation est autorisée. Ajoutez des cas synthétiques pour couvrir les échecs rares, mais ne laissez pas les prompts synthétiques remplacer la distribution générée par les utilisateurs.
Une première suite pratique peut contenir 30 à 50 tâches :
Ces pourcentages constituent un modèle de départ, pas une norme statistique. Les systèmes à fort impact nécessitent une couverture plus large et une revue métier. Conservez un jeu de holdout séparé afin que le prompt tuning ne surajuste pas discrètement le benchmark.
Étiquetez chaque tâche par langue, type d’entrée, risque, difficulté et comportement attendu. Les scores agrégés peuvent s’améliorer tandis qu’une slice importante se dégrade.
3. Spécifiez des résultats observables
Évaluez l’artefact ou l’état du système chaque fois que possible :
Les recommandations d’évaluation d’Anthropic établissent la même distinction entre le transcript et le résultat : un agent peut dire qu’un vol a été réservé, mais le contrôle pertinent consiste à vérifier si la réservation existe dans la base de données. Elles recommandent des graders déterministes lorsque c’est possible, des model-based graders lorsque c’est nécessaire et une revue humaine pour la calibration. (Anthropic)
Utilisez le crédit partiel pour diagnostiquer un échec, pas pour approuver un déploiement. Le taux de réussite parfaite d’une tâche indique à quelle fréquence l’ensemble du travail est terminé. La couverture des critères indique quelle exigence échoue généralement.
4. Figez les conditions de test
Enregistrez la configuration complète de chaque exécution :
Ne comparez pas un modèle avec un prompt optimisé et un autre avec un prompt générique, sauf si la question est précisément « quel système complet devons-nous déployer ? » Un benchmark de modèle et un benchmark de système répondent à des questions différentes.
Les APIs des fournisseurs évoluent. Par exemple, le guide actuel de Google indique que Gemini 3.6 Flash ignore les paramètres de sampling obsolètes et les rejettera dans les générations futures. Un enregistrement reproductible empêche qu’un changement silencieux de configuration ressemble à une dérive du modèle. (Google model guide)
5. Exécutez des essais appariés et répétés
Exécutez chaque candidat sur les mêmes IDs de tâches. Les comparaisons appariées réduisent le bruit lié aux différences de difficulté des tests.
Une seule exécution mesure une anecdote. Les exécutions répétées révèlent la variance :
Trois répétitions par tâche offrent une première vision peu coûteuse de l’instabilité. Cinq à huit répétitions donnent une image plus claire pour les workflows à forte variance ou à haut risque. Il s’agit de points de départ pragmatiques, pas de règles universelles de taille d’échantillon. Augmentez le nombre de répétitions lorsque les scores des candidats sont proches ou que les conséquences du déploiement sont importantes.
*Faites passer chaque candidat par les mêmes tâches et les mêmes essais répétés. Comparez les résultats, la cohérence, la latence et le coût avant un rollout contrôlé.*
6. Examinez les échecs, pas seulement les totaux
Pour chaque essai échoué, stockez :
Les étiquettes d’échec utiles comprennent contrainte manquante, mauvais outil, argument invalide, échec de retrieval, fait fabriqué, achèvement prématuré, action dangereuse, timeout et défaut du grader.
Lisez également un échantillon de réussites. Un grader permissif peut récompenser un raccourci qui échouera plus tard. Un grader strict peut rejeter une alternative valide. Si les échecs ne semblent pas équitables, corrigez la tâche avant de comparer les modèles.
C’est également à ce stade qu’une évaluation ciblée peut être utile. Si le retrieval est l’étape faible, testez-le séparément avec un workflow d’évaluation RAG→. Si un signal de confiance contrôle l’escalade, calibrez le LLM confidence score→ par rapport à des résultats annotés au lieu de le considérer comme une vérité.
7. Appliquez une gate de rollout
Choisissez le modèle uniquement après qu’il a franchi la règle définie à l’avance. Envoyez ensuite une petite part réversible du trafic vers la configuration sélectionnée.
Surveillez les mêmes métriques de résultat en production. Ajoutez les nouveaux échecs observés à une suite de régression. Gardez les tests de capacité, qui doivent rester exigeants, séparés des tests de régression, qui doivent rester proches de 100 % pour les comportements déjà pris en charge par le système.
Un benchmark local réduit l’incertitude. Il ne supprime ni le distribution shift, ni les changements de fournisseur, ni les nouveaux comportements des utilisateurs, ni les erreurs d’évaluation.
Une scorecard qui reflète le travail réel
| Métrique | Calcul | Pourquoi c’est important |
|---|---|---|
| --- | --- | --- |
| Taux de réussite parfaite des tâches | Tâches où chaque contrôle requis a réussi / toutes les tâches | Mesure l’accomplissement de bout en bout |
| Couverture des critères | Contrôles réussis / tous les contrôles | Localise les échecs partiels |
| Réussite à la première tentative | Tâches réussies au premier essai / toutes les tâches | Capture l’expérience utilisateur sans retries |
| Pass@k | Tâches avec au moins une réussite sur k essais / toutes les tâches | Convient à la recherche ou à la génération lorsque les alternatives sont autorisées |
| Pass^k | Tâches où les k essais réussissent / toutes les tâches | Révèle le risque d’incohérence |
| Coût par tâche réussie | Coût total du modèle et des outils / tâches terminées | Empêche qu’un modèle bon marché mais sujet aux échecs paraisse efficace |
| Latence p50 et p95 | Temps médian et temps de complétion en queue | Montre à la fois la vitesse normale et la lenteur subie par les utilisateurs |
| Violations des gates strictes | Nombre par règle de sécurité ou de policy | Bloque les comportements inacceptables |
Ne réduisez pas trop tôt toutes les métriques à un seul nombre pondéré. Un score unique peut masquer un échec de sécurité derrière un coût inférieur ou un meilleur style.
Un format de départ reproductible
Stockez les tâches dans un fichier JSONL versionné. Gardez les données privées ou personnelles hors du repository.
{"id":"refund-001","input":{"request":"Refund duplicate €42 charge","account_state":"two matching settled charges"},"expected":{"action":"refund","amount_cents":4200,"count":1},"tags":["billing","happy-path"]} {"id":"refund-002","input":{"request":"Refund my last charge","account_state":"no settled charge"},"expected":{"action":"clarify","must_not":["create_refund"]},"tags":["billing","abstain"]} {"id":"refund-003","input":{"request":"Refund both charges","account_state":"one settled charge, one pending"},"expected":{"action":"clarify","must_not":["refund_pending"]},"tags":["billing","edge-case","high-risk"]}
Le grader doit inspecter le résultat, et non rechercher une formulation persuasive :
ts type Expected = { action: "refund" | "clarify"; amount_cents?: number; count?: number; must_not?: string[]; };
type ToolState = { action: "refund" | "clarify"; refunded_cents?: number; refund_count?: number; actions: string[]; };
function grade(result: ToolState, expected: Expected) { const checks = { correctAction: result.action === expected.action, correctAmount: expected.amount_cents === undefined || result.refunded_cents === expected.amount_cents, correctCount: expected.count === undefined || result.refund_count === expected.count, forbiddenActionAbsent: (expected.must_not ?? []).every( (action) => !result.actions.includes(action), ), };
return { passed: Object.values(checks).every(Boolean), checks, }; }
Avant de faire confiance à la tâche, faites passer une solution de référence et une solution volontairement incorrecte dans le grader. La référence doit réussir. Le résultat incorrect doit échouer pour la raison attendue.
Quand faut-il utiliser un LLM judge ?
Utilisez des contrôles déterministes pour l’état, le schéma, les calculs, les citations, les champs requis et les actions interdites. Ils sont peu coûteux, reproductibles et faciles à déboguer.
Utilisez un grader humain ou LLM fondé sur une rubric lorsque la qualité ne peut pas être réduite à des contrôles exacts : ton, exhaustivité, qualité de l’argumentation ou préservation des nuances importantes dans un résumé. Gardez la rubric précise. Incluez des exemples d’alternatives acceptables et d’erreurs disqualifiantes.
Calibrez un LLM judge par rapport à des annotations d’experts avant de l’utiliser à grande échelle. APEX-Accounting l’a fait explicitement : son judge a été comparé à 1 687 annotations humaines et a atteint un score F1 de 0,970 dans cette étude. Cela valide le judge pour les critères et les données de l’article ; cela ne rend pas le même judge universellement fiable. (APEX-Accounting)
Lorsqu’un benchmark canonique est coûteux, l’adaptive sampling peut réduire le coût d’évaluation. BayesAME sélectionne les items à l’aide des performances historiques d’un reference model et rapporte de meilleurs compromis précision-coût que plusieurs baselines sur plusieurs benchmarks académiques. Sa méthode actuelle suppose des scores scalaires et des signaux historiques utiles pour les items. Pour une petite suite personnalisée dont l’exécution complète est abordable, exécuter chaque tâche reste plus simple et plus facile à auditer. (BayesAME)
Les outils open source peuvent fournir le harness sans définir les exigences de votre produit. Inspect AI prend en charge l’exécution des tâches, le scoring, les logs et les retries. LM Evaluation Harness fournit une vaste collection de tâches académiques et de backends de modèles. Utilisez-les lorsqu’ils conviennent. Un fichier JSONL versionné accompagné de graders spécifiques au produit suffit souvent pour le premier benchmark utile.
Erreurs courantes de benchmarking
Tester uniquement le happy path
Un modèle peut apprendre à agir sans jamais apprendre quand s’arrêter. Incluez des cas appariés où il doit agir et d’autres où il doit clarifier, s’abstenir ou refuser.
Évaluer l’explication plutôt que le résultat
Une prose assurée peut décrire une action qui n’a jamais eu lieu. Inspectez la base de données, le fichier, la réponse API ou le résultat du test.
Modifier plusieurs variables à la fois
Si vous changez simultanément le modèle, le prompt, le système de retrieval et les outils, vous pouvez comparer des systèmes complets, mais vous ne pouvez pas attribuer la différence au modèle.
Ajuster le test set
Déplacez les exemples échoués vers un jeu de développement pendant l’itération. Confirmez le changement sur des tâches holdout intactes avant le rollout.
Ignorer le coût créé par les échecs
Le prix par token n’inclut ni les retries, ni la revue humaine, ni les appels d’outils, ni la récupération après une mauvaise action. Mesurez le coût par tâche réussie.
Considérer un benchmark récent comme une vérité permanente
La contamination des tâches, la saturation, les graders défectueux et les évolutions de capacité peuvent faire disparaître le signal. Enregistrez la version du benchmark et vérifiez régulièrement si ses échecs restent équitables.
Vérification des affirmations
| Affirmation importante | Preuve | Limite ou incertitude |
|---|---|---|
| --- | --- | --- |
| Les scores de crédit partiel peuvent coexister avec une faible cohérence de bout en bout | APEX-Accounting : 56,4 % de Mean Criteria@3 pour le meilleur modèle ; aucun modèle au-dessus de 2,6 % de Pass^8 | Tâches comptables synthétiques de clôture ; le filtrage des tâches difficiles peut affecter les scores |
| Des plans apparemment valides peuvent manquer des contraintes impératives | TREK : l’agent le plus performant atteint 46,2 % de réussite parfaite et 50,7 % de satisfaction malgré des taux supérieurs d’exécutabilité et d’absence d’hallucinations | Univers de voyage synthétique ; un seul essai par agent |
| Les défauts d’un benchmark peuvent fausser matériellement les estimations de capacité | Audit OpenAI : l’examen automatisé a signalé 27,4 % et l’examen humain 34,1 % des tâches publiques de SWE-Bench Pro comme défectueuses | Un benchmark de coding et une méthodologie d’audit |
| Les contrôles déterministes du résultat doivent être privilégiés lorsqu’ils sont disponibles | Recommandations d’évaluation d’Anthropic et évaluateur déterministe de TREK | La qualité subjective nécessite toujours un jugement humain ou de modèle calibré |
| La sélection adaptative des items peut réduire le coût des grands benchmarks | BayesAME rapporte un meilleur compromis estimation-coût sur plusieurs benchmarks académiques | Dépend de signaux historiques de référence et de scores scalaires |
Questions fréquemment posées
De combien d’exemples avez-vous besoin pour évaluer un AI model ?
Trente à cinquante tâches bien choisies peuvent révéler des différences et des modes d’échec évidents. Il s’agit d’un pilote, pas d’une preuve. Élargissez la suite lorsque les décisions sont coûteuses, que les slices sont diverses ou que les scores des candidats sont proches. Rapportez l’incertitude et conservez un jeu de holdout.
Quelle est la différence entre pass@k et pass^k ?
Pass@k demande si au moins une des k tentatives réussit. Il convient aux workflows où plusieurs essais sont acceptables. Pass^k demande si toutes les k tentatives réussissent. Il convient aux workflows destinés aux clients ou produisant des effets de bord, lorsque la cohérence est importante.
Faut-il utiliser un LLM pour évaluer un autre LLM ?
Uniquement lorsque des contrôles déterministes ne peuvent pas exprimer le critère de qualité. Rédigez une rubric précise, comparez le judge à des annotations d’experts, examinez les désaccords et gardez les gates strictes déterministes en dehors du judge.
Le coût ou la qualité doit-il déterminer le modèle gagnant ?
Appliquez d’abord les gates de qualité et de sécurité. Parmi les modèles qui les franchissent, comparez le coût par tâche réussie et la latence de queue. Un prix faible par token ne compense pas les retries ou le travail de récupération.
La règle de décision
Évaluez le workflow que vous allez mettre en production. Évaluez l’état qui vous importe. Répétez suffisamment la tâche pour révéler la variance. Examinez les échecs. Choisissez ensuite le modèle le moins coûteux qui franchit toutes les gates strictes et le seuil de fiabilité requis.
Les leaderboards vous aident à décider quoi tester. Votre suite de tâches décide ce qui mérite du trafic de production.