L’angle mort de l’évaluation des LLM : pourquoi ne regardons-nous que la « connaissance » et non le « comportement » ?
(dev.to/johnonlee)• L’évaluation des LLM en est encore au stade du « score au SAT » — MMLU, HumanEval et SWE-bench restent tous dans un paradigme de session unique et de réponse unique. Un véritable agent de code travaille sur plusieurs sessions, apprend de ses erreurs et lit les conventions existantes. Ce n’est pas une question de connaissance, mais de comportement.
• Quand nous recrutons des humains, nous regardons davantage « comment ils réfléchissent » que leurs notes — pourquoi ne faisons-nous pas la même chose pour l’évaluation des LLM ? Aujourd’hui, nous sommes bloqués à l’étape de la « vérification du GPA », où tous les modèles atteignent le 90e percentile.
• Même pour corriger le même bug, les approches peuvent être totalement différentes — le modèle A fait un grep en 30 secondes puis applique un patch (profil prototypage), le modèle B décompose en sous-tâches avant d’adopter une approche systématique (profil architecture), le modèle C apprend à partir de précédents dans le git log puis corrige (profil maintenance). Tous corrigent le bug. Le score est identique. L’adéquation au rôle, elle, est totalement différente.
• Proposition de 4 dimensions d’observation du comportement — Decomposition (décompose-t-il ou exécute-t-il immédiatement), Approach (cherche-t-il des patterns ou raisonne-t-il à partir des principes), Recovery (change-t-il de stratégie quand il est bloqué ou insiste-t-il), Consistency (adopte-t-il la même approche face à des problèmes similaires).
Évaluation de la connaissance vs évaluation du comportement
| Benchmark existant | Ce qu’il mesure | Ce qu’il manque |
|---|---|---|
| MMLU | Quantité de connaissances mémorisées | Jugement dans l’application, « conscience de ce qu’il ne sait pas » |
| HumanEval | Taux de réussite à la première tentative | Débogage, itération, processus d’adaptation |
| SWE-bench | Le patch passe ou non | Cheminement d’approche, compréhension de l’architecture, apprentissage intersession |
2026 : les vraies questions à poser
Maintenant que les agents de code ne sont plus des démos mais de véritables outils d’équipe, la question à poser n’est pas « combien de points ? » :
- « Quel modèle convient à la maintenance de legacy ? »
- « Quel style de débogage se prête bien au pair programming avec un junior ? »
- « Quel modèle présente le comportement le plus prévisible sur plusieurs semaines ? »
Ce sont des questions de role fit. Des questions de recrutement. Et nous continuons à y répondre avec des scores de SAT.
L’auteur ne présente pas ce cadre comme une version achevée. Il laisse explicitement ouvertes quatre hypothèses, avec une attitude de « corrigez-moi si je me trompe », afin de susciter la discussion dans les commentaires. L’article de Tang et al., « In-Situ Behavioral Evaluation for LLM Fairness », publié en avril 2026, va dans une direction similaire.
5 commentaires
En y repensant, l’examen du Suneung qui sert à évaluer les personnes ne juge finalement lui aussi que les connaissances, pas les comportements.
Je ne saurais pas si cela gardait un schéma constant, mais comme c’est différent à chaque utilisation… je ne savais vraiment pas comment l’évaluer.
Oui, tout à fait. Il n’y a pas de réponse unique, mais je pense qu’il vaut la peine d’examiner aussi cette piste. Aujourd’hui, on confie un travail à un seul modèle du début à la fin, mais j’ai l’impression que demain, on évoluera peut-être vers une approche où chaque modèle ne prendra en charge, à différentes étapes, que les domaines dans lesquels il excelle. Même si tout le monde étudie sérieusement et acquiert un niveau de connaissance assez comparable, les schémas de comportement peuvent créer des différences dans le résultat final.
Puisqu’il n’y a pas de réponse unique et que même les critères humains ne sont ni exacts ni peu coûteux en ressources, ne serait-il pas plus pertinent d’évaluer en fonction du volume de tokens et du niveau atteint ? Si on commence à intervenir jusqu’à la méthode, cela devient vraiment très compliqué...
Ce n’est pas faux, mais y a-t-il une réponse ? Même dans les recrutements réels, c’est difficile de quantifier ce genre de chose, donc on embauche aussi des gens, on les fait travailler, puis on les remercie parfois... un peu comme quand on utilise un modèle d’IA puis qu’on le remplace.