Kodik explique pourquoi les benchmarks publics des modèles de langage sont trompeurs

Le débat sur le meilleur LLM est depuis longtemps devenu une course aux sorties tapageuses et aux beaux tableaux, mais Kodik rappelle qu'un benchmark public ne garantit presque rien à lui seul. Un modèle qui obtient plus de points sur un jeu de tâches populaire n'est pas forcément plus performant dans un produit réel, surtout dans un éditeur de code, où comptent non seulement les connaissances, mais aussi la stabilité, la précision des modifications et la capacité à mener une tâche jusqu'à un résultat fonctionnel.

Le principal reproche de l'équipe aux métriques du secteur est qu'elles deviennent trop facilement des cibles d'optimisation. Les créateurs de modèles savent parfaitement quels tests le marché commente et y adaptent inévitablement l'entraînement, le post-entraînement et le système d'évaluation. Résultat : un écart de quelques pourcents passe souvent pour un grand bond technologique, alors qu'en pratique il peut simplement traduire une meilleure adaptation à un format de questions précis.

Autre problème : beaucoup de benchmarks testent une compétence étroite. Certains privilégient l'érudition académique, d'autres les casse-tête logiques, d'autres encore les réponses courtes dans un gabarit figé. Le scénario d'un utilisateur réel se réduit presque jamais à l'un de ces modes.

Pour Kodik, ce n'est pas une querelle théorique. L'entreprise développe un éditeur de code IA : elle doit donc comprendre comment un modèle se comporte dans un vrai processus de développement. Un bon système ne doit pas seulement connaître la syntaxe ou deviner la bonne réponse d'un test.

Il doit comprendre le contexte d'un fichier, modifier le code avec soin, ne pas casser la logique voisine, suivre les instructions et reproduire un résultat stable sur des tâches similaires. Outre la qualité, des facteurs opérationnels entrent en jeu : le prix d'une requête, la latence, la propension du modèle à effectuer des actions superflues et sa prévisibilité globale en production. Se contenter de classements externes ne suffit donc pas à l'équipe.

C'est pourquoi Kodik a construit son propre KodikBenchmark interne. D'après le document, sa logique est plus proche de l'exploitation réelle que d'une olympiade abstraite pour modèles. Plutôt que de demander « qui est le plus intelligent », l'équipe cherche à vérifier qui est le plus utile sur une tâche précise : édition de code, instructions en plusieurs étapes, travail avec le contexte et maintien de la justesse après modification. Cette approche évalue l'aptitude pratique du modèle, et non une unique belle réponse.

Le test interne permet aussi de regarder au-delà de la moyenne et d'examiner la stabilité : à quelle fréquence le modèle réussit, où il se trompe de façon systématique et si l'on peut s'y fier dans un scénario répétitif au sein du produit.

Il faut aussi souligner que les auteurs n'opposent pas leur benchmark à toute l'industrie : ils montrent plutôt les limites des classements universels. Les tests publics servent de repère, surtout au début de la sélection, mais répondent mal à la question de savoir quel modèle convient à votre cas précis. Sur un jeu de tâches, ce sera le modèle au bon raisonnement qui s'imposera ; sur un autre, celui qui suit mieux les instructions ; sur un troisième, un système moins cher et plus rapide, avec un « plafond intellectuel » un peu plus bas.

Le document de Kodik met précisément en lumière cette bifurcation : le leader du classement général n'est pas obligé d'être le leader sur une tâche produit.

La conclusion pratique est simple : l'époque de la foi aveugle dans les benchmarks touche à sa fin, et les entreprises qui intègrent des LLM dans des produits réels devront bâtir leur propre système d'évaluation. Plus un test est proche du scénario de production, plus ses résultats sont utiles pour choisir un modèle, router les requêtes et contrôler la qualité après les mises à jour. L'exemple de Kodik montre qu'une approche mûre de l'IA aujourd'hui ne consiste pas à courir après la sortie la plus bruyante, mais à vérifier calmement le comportement du modèle là où l'on compte gagner de l'argent ou bâtir l'expérience utilisateur.