Analyse de benchmark
HumanEval a mesuré si l'IA savait coder. Il ne s'est jamais demandé si le code était un vrai travail
Les 164 problèmes de complétion de fonctions de HumanEval sont devenus le test standard des capacités de codage de l'IA, mais la mémorisation et son champ d'action étroit ont laissé un large fossé entre la réussite du benchmark et la gestion d'une base de code réelle, un fossé que SWE-bench a été conçu pour exposer.

HumanEval demande à un modèle de compléter une fonction Python à partir d'une docstring, puis vérifie le résultat par rapport à des tests unitaires. C'est une configuration propre : 164 problèmes, réussite/échec sans ambiguïté, aucun correcteur humain nécessaire. C'est cette propreté qui en a fait le point de référence pour les affirmations « ce modèle sait coder » tout au long de la première vague de LLMs générateurs de code.
C'est aussi pourquoi il a cessé d'être utile. Les problèmes sont courts, autonomes et suffisamment anciens pour avoir été copiés, discutés et résolus dans des dépôts publics des milliers de fois. La recherche sur la mémorisation des modèles de code a trouvé une relation directe entre la taille du modèle et la capacité à reproduire des solutions connues textuellement, le même schéma de contamination qui a compromis MMLU et GSM8K, mais appliqué au code plutôt qu'à des connaissances générales. Un modèle peut réussir HumanEval en ayant mémorisé des variantes proches de ces 164 problèmes exacts, sans que cette compétence ne se transfère à une seule ligne de code qu'il n'a jamais vue auparavant.
Le vrai fossé : fonctions jouets contre dépôts réels
Le problème plus profond n'est pas la contamination, cependant. C'est la portée. Les problèmes HumanEval sont le genre de choses que l'on verrait dans un premier entretien de codage : écrire une fonction qui inverse une chaîne, écrire une fonction qui vérifie si un nombre est premier. Écrire du logiciel professionnellement ne ressemble en rien à cela. Cela signifie comprendre une base de code existante, tracer un bug à travers plusieurs fichiers, respecter une API conçue par quelqu'un d'autre, et ne pas casser des tests que vous n'avez pas écrits.
SWE-bench a été conçu pour combler exactement ce fossé, en évaluant les modèles sur de vrais problèmes GitHub au lieu de fonctions synthétiques. Les résultats n'ont pas été tendres avec le récit de l'ère HumanEval. Les modèles qui semblaient solides sur l'achèvement de fonctions isolées ont vu leurs taux de réussite s'effondrer une fois qu'on leur a demandé de résoudre un ticket réel dans un dépôt réel, en particulier sur des bases de code privées et récemment créées où la mémorisation ne peut pas aider. Là où les meilleurs modèles atteignent 70 % à 95 % sur les problèmes publics et validés de SWE-bench, la même catégorie de modèles chute à environ 23 % sur les dépôts privés de SWE-bench Pro, et encore plus bas sur son ensemble de test confidentiel. Cet effondrement est la véritable histoire que HumanEval n'a jamais été conçu pour raconter.
À quoi HumanEval sert encore
En tant que test de fumée de cinq minutes, il fonctionne toujours : si un modèle ne peut pas compléter une fonction d'inversion de chaîne, quelque chose ne va pas gravement. Mais comme preuve qu'un modèle peut être digne de confiance avec une base de code de production, il n'a jamais mesuré ce que tout le monde supposait qu'il mesurait. Le changement de cap de l'industrie vers SWE-bench, et vers des benchmarks agentiques qui testent l'utilisation d'outils et l'édition multi-fichiers plutôt que l'achèvement d'une seule fonction, est une admission tacite que HumanEval répondait à une question beaucoup plus étroite que celle que les gens posaient.
L'essentiel de la tech en 3 minutes chaque matin
Un email, chaque jour ouvré, avec ce qui compte vraiment en IA et en tech.