De la bonne réponse à la tâche accomplie : comment l’évaluation de l’IA a évolué

La question historique : que signifie évaluer une capacité de l’IA ?

Évaluer une capacité d’intelligence artificielle consiste à transformer une question générale — par exemple, un système comprend-il des instructions ou peut-il aider à résoudre des problèmes ? — en un test doté de tâches, de conditions et d’une règle permettant de juger les résultats. La note obtenue ne mesure pas la capacité dans l’absolu : elle résume les performances dans ces conditions précises.

Une réponse correcte à une question, une solution qui réussit des tests logiciels et une opération qui laisse une application dans l’état demandé constituent des éléments de preuve différents. On ne peut pas les considérer comme des unités interchangeables. Chacune fait apparaître certains succès et certains échecs, tout en laissant d’autres aspects de côté. L’histoire de l’évaluation peut donc se lire, en partie, comme une évolution de l’unité évaluée : d’abord des réponses à des exemples circonscrits, puis des ensembles de tâches plus variés et, dans certains benchmarks récents, des séquences d’actions exécutées dans des environnements.

Cette séquence constitue un cadre d’interprétation, pas une chronologie exhaustive ni une progression inévitable vers une meilleure mesure. Les travaux cités représentent des approches distinctes. Un benchmark fondé sur des réponses peut convenir à une question précise ; un benchmark interactif peut apporter des éléments plus directs sur l’exécution, mais il introduit aussi des dépendances à l’environnement et au protocole.

Première étape : des tâches circonscrites et des réponses faciles à noter

Dans une évaluation fondée sur un jeu de données, chaque exemple fournit une entrée et indique quelle sortie est considérée comme correcte, ou quel critère doit être appliqué. En compréhension du langage, l’entrée peut être une phrase ou une paire de phrases ; la sortie, une étiquette, une appréciation ou une réponse. Le résultat agrégé permet de comparer les systèmes évalués sur la même tâche et selon un protocole commun.

Cette conception présente des avantages pratiques. Les exemples peuvent être réutilisés, les résultats calculés de manière cohérente et les méthodes comparées sans demander aux systèmes de faire fonctionner une application entière. Si l’on cherche à savoir si un modèle distingue une relation sémantique particulière, une tâche de classification bien définie peut fournir des éléments utiles.

Mais l’unité évaluée reste étroite. Produire la bonne étiquette ne démontre pas que le système sait planifier plusieurs étapes, utiliser des outils, réagir à un changement inattendu ou mener une tâche à bien dans une interface. Une note agrégée n’indique pas non plus, à elle seule, où se concentrent les erreurs. La couverture des données, la formulation des questions et le choix de la métrique délimitent ce qu’il est possible d’en déduire.

La conclusion prudente est donc conditionnelle : le système a obtenu un certain résultat sur ces tâches, avec ces données et selon cette règle de notation. Pour étayer des affirmations plus larges sur les compétences générales, la robustesse ou l’utilité dans une situation réelle, il faut des évaluations supplémentaires.

Élargir le champ d’évaluation : GLUE et BIG-bench

Présenté en 2018, GLUE rassemble plusieurs tâches de compréhension du langage naturel au sein d’un benchmark multitâche et d’une plateforme d’analyse. Il déplace l’attention d’un test unique vers un ensemble de problèmes apparentés : on peut observer si un système obtient de bons résultats sur différentes tâches et synthétiser une partie de ces performances. La diversité des tâches rend plus difficile la réduction de l’évaluation à une seule compétence, sans toutefois éliminer les limites propres à chaque tâche ni transformer le résultat agrégé en mesure universelle.

BIG-bench a élargi encore davantage la variété des épreuves réunies. Au lieu de se concentrer sur une famille relativement circonscrite de problèmes linguistiques, il propose une vaste collection de tâches apportées par différents contributeurs, avec des objectifs et des modes d’évaluation variés. L’étude examine les performances de modèles de langage dans cette collection et la façon dont les résultats évoluent lorsque la taille des modèles change.

Le changement important ne consiste pas simplement à ajouter des exemples. Une collection hétérogène peut mettre à l’épreuve des capacités et des comportements différents, et révéler qu’un système performant sur une tâche ne l’est pas nécessairement sur une autre. En contrepartie, cette variété complique les comparaisons : les tâches peuvent avoir des formats, des métriques et des niveaux de difficulté distincts. Un chiffre agrégé donne une vue d’ensemble, mais peut masquer des écarts importants entre les différentes composantes.

Dans les deux cas, l’évaluation reste principalement un test de réponses à des tâches définies à l’avance. Un grand nombre de tâches ne revient pas à observer un agent travailler dans un environnement ouvert. L’élargissement améliore la couverture au sein de la collection ; il ne garantit ni que celle-ci représente tous les usages possibles ni qu’elle mesure une exécution prolongée.

Changer d’unité : résoudre un problème dans un dépôt

SWE-bench déplace l’unité d’évaluation vers une tâche de génie logiciel : résoudre des problèmes issus de dépôts GitHub réels. Au lieu d’évaluer uniquement une réponse textuelle à une question, le système doit travailler à partir du contexte d’un projet et proposer des modifications de code en réponse au problème décrit.

Le correctif peut être évalué à l’aide des tests du projet, notamment ceux qui concernent le problème signalé et ceux qui devraient continuer à réussir. On obtient ainsi des éléments plus concrets qu’une explication convaincante : on peut vérifier si la modification proposée fonctionne au regard des contrôles disponibles dans l’environnement du benchmark. Le vérificateur peut déterminer si le résultat satisfait ces tests ; cela ne revient pas à certifier que le correctif est la seule solution correcte, qu’il est bien conçu à tous égards ou qu’il est sûr pour tout déploiement.

Le système évalué ne se réduit pas nécessairement au modèle pris isolément. Selon la configuration, le résultat peut dépendre de la manière dont le dépôt est présenté, des outils disponibles pour consulter ou modifier les fichiers, du nombre de tentatives autorisées et de la procédure d’exécution des tests. Pour comparer des notes, il faut savoir quels composants sont inclus et si le protocole est resté constant.

L’évaluation porte toujours sur un ensemble défini de problèmes et de conditions d’exécution. Réussir un problème atteste donc d’un succès dans ce cas et selon les vérifications prévues, et non d’une capacité à résoudre n’importe quel problème logiciel. Un test sur dépôt rapproche l’épreuve d’une activité professionnelle concrète, mais ne couvre pas automatiquement les exigences produit, la collaboration, la maintenance à long terme ni les conséquences d’une modification en production.

Intégrer l’interaction et l’état : des tâches dans des environnements informatiques

OSWorld évalue des agents multimodaux sur des tâches ouvertes dans des environnements informatiques réels simulés. Au lieu de se limiter à produire une réponse à propos d’une application, un agent peut devoir observer l’interface et agir au moyen de commandes comme le clavier ou la souris pour atteindre l’état demandé. L’évaluation porte sur les tâches effectuées dans l’environnement, et pas seulement sur la qualité linguistique d’une description.

Cette évolution permet d’observer des dimensions qu’un test de réponses ne saisit pas directement : les actions ont-elles été exécutées, la séquence a-t-elle atteint le résultat prévu et l’état final satisfait-il une condition d’évaluation ? Elle rend aussi plus visible le lien entre perception, décision et action. Un système peut décrire correctement ce qu’il faudrait faire sans parvenir à le faire ; dans un environnement interactif, cette différence peut entrer dans le résultat.

L’exécution fournit un signal plus proche de la tâche opérationnelle, mais il faut toujours déterminer ce qui constitue une réussite. L’environnement, les applications, l’état initial, les instructions, les outils et le vérificateur font partie des conditions du test. Si l’évaluation compare des états à l’aide de règles automatisées, celles-ci peuvent vérifier des aspects précis du résultat sans nécessairement juger chaque détail de la qualité, de la sécurité ou de la pertinence de la trajectoire suivie.

Il faut également distinguer l’agent de son environnement. Une note obtenue avec certains outils et contrôles autorisés ne décrit pas automatiquement ce que ferait le modèle sans eux, avec une autre interface ou dans des conditions non prévues. Le résultat concerne le système et le protocole évalués, et non une capacité isolée de tous ces composants.

Ce qui change avec un environnement exécutable — et ce qui ne change pas

Le passage de réponses notées à des tâches exécutables élargit les éléments observables. Il peut montrer si le système produit une modification dans un dépôt ou une application, et pas seulement s’il rédige une solution plausible. C’est une différence importante lorsqu’on formule des affirmations sur sa capacité à agir. Cela ne transforme toutefois pas automatiquement un benchmark en mesure complète de l’utilité, de l’autonomie ou de la fiabilité.

Il est utile de distinguer quatre éléments. La tâche définit ce qui est demandé ; l’environnement détermine où et dans quelles conditions cela se déroule ; le vérificateur définit les résultats qu’il considère comme satisfaisants ; et le système évalué comprend les composants qui reçoivent la tâche et produisent les actions. Toute modification de l’un de ces éléments peut changer la difficulté ou le sens de la note. Comparer des résultats obtenus selon des protocoles différents sans tenir compte de ces changements risque d’attribuer au modèle ce qui relève, en partie, d’autres conditions.

La validité du vérificateur mérite une attention particulière. Un test automatisé peut être reproductible et utile, mais il ne vérifie que ce qu’il contrôle. Une suite de tests incomplète pourrait ne pas détecter un défaut qu’elle ne couvre pas ; une vérification de l’état final pourrait ne pas pénaliser une trajectoire inefficace si l’efficacité ne fait pas partie du critère. Ce sont des possibilités générales à examiner pour chaque benchmark, et non des défauts à attribuer à une évaluation particulière sans éléments à l’appui.

La reproductibilité dépend également de détails opérationnels : versions des logiciels, état initial, accès aux outils, temps alloué ou nombre de tentatives. La description de ces limites permet de mieux interpréter le résultat. Lorsque des détails manquent, la comparaison peut perdre en valeur informative ; il vaut alors mieux signaler l’incertitude que combler les lacunes par des suppositions.

Comment interpréter une note dans son contexte historique

Une note historique doit être replacée dans son contexte. Il faut d’abord identifier la version du benchmark et le protocole utilisés. Une même appellation peut désigner des ensembles de tâches, des métriques ou des configurations différents. Avant de comparer deux chiffres, il faut vérifier qu’ils correspondent à des épreuves suffisamment comparables.

La deuxième étape consiste à identifier l’unité évaluée. A-t-on noté une réponse, un ensemble de réponses, un correctif soumis à des tests ou une tâche accomplie dans une interface ? Cette différence détermine le type d’éléments fourni par le résultat. Un taux de réponses correctes et un taux de tâches accomplies ne sont pas des échelles équivalentes, même si les deux sont exprimés en pourcentage.

Il convient ensuite de distinguer le résultat agrégé de ses détails. Dans un ensemble multitâche, l’examen des performances tâche par tâche peut révéler des points forts et des faiblesses qui disparaissent dans la moyenne. Pour les évaluations interactives, il est utile de savoir quelles conditions d’exécution ont été maintenues et quels états le vérificateur a considérés comme satisfaisants. Lorsque les rapports le permettent, les résultats détaillés aident à éviter qu’un chiffre récapitulatif ne serve à formuler une affirmation plus large que ce qu’il autorise.

Enfin, une amélioration entre deux évaluations ne démontre pas, à elle seule, l’ampleur du progrès d’une capacité générale. Si le modèle, l’ensemble de tâches, les outils ou les règles de notation changent en même temps, il est impossible d’attribuer toute l’évolution à une seule cause sans analyse complémentaire. La comparaison est plus solide lorsque les conditions sont maintenues, ou lorsque les différences sont décrites avec précision.

Conclusion : choisir les éléments de preuve en fonction de l’affirmation

GLUE et BIG-bench illustrent deux manières d’élargir des évaluations centrées sur les réponses : réunir des tâches apparentées ou couvrir une collection plus diversifiée. SWE-bench et OSWorld illustrent des approches qui déplacent l’épreuve vers des résultats exécutés dans des dépôts et des environnements informatiques. Ce ne sont pas des étapes interchangeables d’un classement : elles répondent à des questions différentes et fournissent des types d’éléments différents.

Si l’affirmation porte sur des réponses à des tâches linguistiques, un jeu de données pertinent peut constituer un test utile. Pour savoir comment les performances se répartissent entre plusieurs tâches, il est important d’examiner une évaluation multitâche et ses résultats détaillés. Si l’affirmation concerne la modification d’un projet ou l’exécution d’actions dans une application, une évaluation exécutable peut apporter des éléments plus directs sur ces résultats opérationnels.

La règle finale est simple : interpréter la note à la lumière de l’épreuve qui l’a produite. Une évaluation plus proche de l’usage peut en apprendre davantage sur les actions et les états, mais elle ne mesure pas à elle seule tous les aspects d’un système utile, sûr ou fiable. Pour étayer de telles conclusions, il faut des protocoles transparents et des éléments complémentaires adaptés à chaque affirmation.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.