Comprendre les benchmarks¶
À lire avant les tableaux de scores. Ce chapitre explique pourquoi un nombre comme « 88,3 % sur Terminal-Bench 2.1 » n'est pas comparable à un autre nombre sans précautions.
Ce qu'un score de benchmark mesure réellement¶
Un score est le produit d'au moins six facteurs, dont le modèle n'est qu'un :
Changer n'importe lequel peut faire varier le résultat de plusieurs points.
Facteur 1 : le harnais¶
Le facteur le plus sous-estimé
Un modèle agentique ne travaille jamais seul. Le harnais décide de la boucle d'interaction, du format des outils, de la gestion du contexte, de la politique de reprise sur erreur.
Le même modèle avec deux harnais différents peut varier de 10 points.
Le rapport Kimi K3 en donne une démonstration involontaire mais parlante, sur son propre banc interne :
| Modèle | Harnais | Kimi Code Bench 2.0 |
|---|---|---|
| Kimi K3 | Claude Code | 73,7 |
| Kimi K3 | Kimi Code | 72,9 |
| GPT-5.5 | Kimi Code | 66,0 |
| GPT-5.5 | Codex | 69,0 |
| GPT-5.6 Sol | Codex | 64,8 |
Ce que ce tableau montre
- Kimi K3 fait mieux avec Claude Code qu'avec son propre harnais.
- GPT-5.5 fait 3 points de mieux avec Codex qu'avec Kimi Code.
- GPT-5.6 Sol fait moins bien que GPT-5.5 sur ce banc.
Chaque modèle est avantagé par le harnais pour lequel il a été entraîné. Comparer des scores obtenus sous harnais différents n'est pas une comparaison de modèles.
Sur DeepSWE, le rapport note d'ailleurs que Kimi K3 obtient 67,5 dans son protocole mais 67,3 avec le harnais mini-SWE-agent du classement officiel. Sur Terminal-Bench 2.1, il rapporte « le meilleur score parmi les harnais, pour tous les modèles » — ce qui est cohérent entre modèles, mais optimiste dans l'absolu.
La critique tierce sur ce point
Une analyse de NxCode relève que les résultats de codage de K3 mélangent au moins trois configurations de harnais (Kimi Code, Claude Code, mini-SWE-agent), et conclut que le score de 88,3 sur Terminal-Bench nécessite « une trace publique et une reproduction sous harnais commun avant de devenir un fait comparatif propre ».
Facteur 2 : l'effort de raisonnement¶
Toutes les évaluations de Kimi K3 sont conduites à effort max. C'est le
réglage le plus performant et le plus cher.
L'implication
Les scores publiés ne représentent pas l'expérience d'un utilisateur qui
emploierait high ou low — et le rapport ne publie aucune mesure
systématique de la dégradation entre niveaux, hors une mention sur Kimi Code
Bench.
Même remarque pour les concurrents : GPT-5.5 est évalué en xhigh, un réglage
encore supérieur à son high.
Facteur 3 : l'échantillonnage et le nombre d'exécutions¶
À température 1,0, deux exécutions identiques donnent des résultats différents. Le rapport gère cela de façon inégale :
| Banc | Protocole |
|---|---|
| Vision (général) | Moyenne sur 3 exécutions |
| ZeroBench-main | 5 exécutions (pass@5), selon le protocole officiel |
| PostTrainBench | Moyenne sur 3 exécutions |
| La plupart des autres | Non précisé |
Pourquoi c'est un problème
Sur un banc de 500 tâches, l'écart-type d'une exécution unique peut facilement atteindre 1 à 2 points. Or le rapport présente des écarts de 0,2 point comme significatifs :
on CorpFin v2 and OSWorld-Verified, it finishes just 0.2 points behind Claude Fable 5 (71.6 % vs. 71.8 % and 84.8 % vs. 85.0 %).
Ces écarts sont très probablement dans le bruit. Ni intervalle de confiance ni nombre d'exécutions ne sont donnés pour ces bancs.
Facteur 4 : la version du banc et le matériel¶
Le rapport est inhabituellement transparent ici, ce qui est à porter à son crédit — mais révèle l'ampleur des ajustements :
| Banc | Ajustement déclaré |
|---|---|
| SWE-Marathon | Branche recalibrée pour H20 des tâches officielles, au 9 juillet 2026, avant la version v1.1 finale. Images Docker, portes de performance et oracles de référence recalibrés pour H20 ; validateurs de correction inchangés |
| PostTrainBench | Évalué sur H20 au lieu des H100 du protocole officiel |
| FrontierSWE | Scores de dominance recalculés depuis les scores bruts, au 16 juillet 2026 |
| MCP-Atlas | Sous-ensemble public de 500 tâches, limite de 100 tours, juge Gemini 3.1 Pro |
| AutomationBench | Sous-ensemble public de 600 tâches |
| BrowseComp | Compaction de contexte déclenchée à 300 K |
Sur la recalibration H20
Les H20 sont les GPU NVIDIA conformes aux restrictions d'exportation vers la Chine, nettement moins performants que les H100. Recalibrer les portes de performance d'un banc de noyaux GPU pour ce matériel est méthodologiquement nécessaire — mais cela rend les scores non directement comparables à ceux obtenus sur H100.
Le rapport le déclare, ce qui est correct. Le lecteur doit en tenir compte.
Facteur 5 : la contamination¶
Le problème invisible
Si un banc est publié avant la date de coupure des données d'entraînement, ses réponses peuvent se trouver dans le corpus. Le modèle ne résout pas le problème : il s'en souvient.
Le rapport Kimi K3 ne mentionne aucune analyse de contamination, et ne donne pas de date de coupure de ses données. C'est une lacune commune à presque tous les rapports de modèles.
Facteur 6 : la sélection des bancs et des concurrents¶
Le rapport évalue sur une quarantaine de bancs publics, ce qui est substantiel et limite le risque de cueillette sélective.
Mais deux choix restent des choix :
- quels bancs figurent dans la suite ;
- quels concurrents y figurent. Notablement, Gemini n'apparaît nulle part dans les comparaisons de Kimi K3, alors que Gemini 3.1 Pro est utilisé comme juge sur MCP-Atlas.
Le cas particulier des scores Elo¶
GDPval-AA v2, AA-Briefcase, WebDev Arena et Text Arena rapportent des Elo, pas des pourcentages.
Ce qu'il faut savoir sur un Elo
- Un Elo n'a pas de sens absolu : seuls les écarts comptent.
- Il dérive à mesure que de nouveaux matchs s'accumulent — le rapport le reconnaît : Elo-style scores drift as additional matches accumulate.
- Un écart de 50 Elo correspond à environ 57 % de victoires, soit une supériorité réelle mais modérée.
Sur GDPval-AA v2, Kimi K3 est à 1 686 contre 1 747 pour Claude Fable 5, soit 61 Elo — environ 59 % de victoires pour Fable 5. Ce n'est pas une domination.
Comment lire les tableaux de la suite¶
Une grille de lecture en cinq questions
- Quel harnais ? Si différent entre modèles, la comparaison est faible.
- Combien d'exécutions ? Si non précisé, un écart < 2 points n'est pas significatif.
- Qui a produit la mesure ? Moonshot, ou un tiers ?
- Le banc a-t-il été modifié ? Matériel, sous-ensemble, juge.
- L'écart est-il grand ? En dessous de 2 points, prudence ; au-dessus de 5, c'est probablement réel.
Vérification de compréhension¶
Pourquoi le rapport signale-t-il les « fallbacks » de Claude Fable 5 ?
Un fallback signifie que le modèle a refusé ou dégradé sa réponse, et que le système est retombé sur un comportement de secours. Sur SWE-Marathon, cela concerne 35 % des tâches. Signaler ce chiffre est honnête — mais sert aussi à suggérer que le score de 35,0 de Fable 5, inférieur aux 42,0 de K3, est en partie dû à des refus plutôt qu'à une incapacité.
Les deux lectures sont valables. Le lecteur doit tenir les deux.
Quel serait le protocole idéal pour comparer deux modèles agentiques ?
Même harnais, même invite système, même nombre d'exécutions (≥ 5), mêmes conditions matérielles, intervalles de confiance publiés, traces d'exécution disponibles, et évaluation menée par un tiers sans intérêt dans le résultat. Aucun rapport de constructeur ne remplit ces conditions — d'où l'importance des évaluations tierces.
Chapitre suivant : Résultats publics