AIME 2024 : ce que mesure un pourcentage de réussite sur 30 problèmes et pourquoi deux résultats apparemment identiques peuvent ne pas être comparables

Que signifie exactement « AIME 2024 » ?

AIME 2024 est souvent présenté comme un benchmark unique de raisonnement mathématique, mais cette appellation condense plusieurs choix. Dans une implémentation d’évaluation documentée, le jeu réunit les problèmes d’AIME I et d’AIME II de cette année-là, soit trente items au total. Chaque problème attend une réponse numérique entière écrite sur trois chiffres, de 000 à 999. La correction peut être automatisée, car elle ne dépend ni d’une évaluation humaine de la rédaction ni d’une grille portant sur les étapes intermédiaires.

Cette composition importe dès le départ. Un résultat obtenu sur les trente problèmes ne repose pas sur la même base qu’un résultat calculé sur un seul examen de quinze problèmes. Il ne faut pas non plus supposer que deux jeux étiquetés « AIME 2024 » utilisent des énoncés, identifiants, adaptations de format ou clés de réponse identiques. Les harnais d’évaluation peuvent empaqueter les tâches et leurs extracteurs de manières différentes. L’étiquette du benchmark désigne une famille d’items ; elle ne certifie pas, à elle seule, un protocole commun.

Une lecture rigoureuse commence donc par transformer le titre en questions précises : AIME I, AIME II ou les deux ont-ils été évalués ; combien de problèmes ont été inclus ; et quelle implémentation a transformé la sortie textuelle en réponse notée ? Sans ces réponses, le pourcentage est une observation incomplète, non une comparaison établie.

Ce que mesure un score et ce qu’il laisse de côté

AIME 2024 fournit un signal utile sur la résolution de problèmes de compétition mathématique dont la réponse finale peut être vérifiée exactement. Le format réduit une source fréquente d’ambiguïté : si l’évaluateur obtient l’entier correct conformément à la règle définie, l’item est compté comme réussi ; sinon, il est compté comme erroné. Cette propriété rend l’épreuve attrayante pour exécuter de nombreuses évaluations de manière cohérente.

Toutefois, le score final n’observe pas directement l’ensemble du processus ayant conduit à la réponse. Un modèle peut produire un raisonnement correct, mais terminer par un format que l’extracteur ne reconnaît pas. Il peut également parvenir au bon entier par une chaîne d’étapes défectueuse que la correction exacte n’inspecte pas. Le benchmark note, par conception, la réponse finale récupérée par le harnais, et non la qualité d’une démonstration mathématique.

Il ne s’ensuit pas qu’un bon résultat soit dénué de valeur. Il indique une performance sur une tâche délimitée, composée de problèmes de style compétitif et de réponses entières vérifiables. En revanche, il ne permet pas à lui seul d’établir une capacité générale de raisonnement, l’aptitude à rédiger des preuves révisables, la précision dans des tâches professionnelles, la fiabilité dans des domaines où l’information est incomplète, ou la performance face à de nouvelles distributions de problèmes. Ces conclusions exigeraient des évaluations supplémentaires et une relation démontrée entre le test et le cas d’usage.

Il convient aussi de distinguer la compétence mathématique du produit. Un système utile à des analystes, scientifiques ou ingénieurs doit, selon le contexte, interpréter des exigences, expliciter ses hypothèses, utiliser des données externes de façon traçable, détecter l’incertitude et communiquer ses limites. Aucune de ces propriétés n’est pleinement mesurée par trente réponses entières.

La fiche minimale qui doit accompagner un résultat

Une affirmation publiable devrait permettre à une autre personne de reconstruire ce qui a été mesuré, même si elle ne peut pas reproduire tous les calculs. La première ligne de la fiche concerne le jeu : indiquer AIME I, AIME II ou les deux, le nombre de problèmes, ainsi que la source ou la version des énoncés. La deuxième concerne l’identité du système : nom exact du modèle, snapshot ou date, fournisseur et, le cas échéant, configuration de raisonnement.

Il faut ensuite déclarer le mode de génération. Cela inclut le prompt complet, ou une description suffisante de ses instructions de format, la température et les autres paramètres d’échantillonnage, le nombre maximal de tokens, les limites de temps, le nombre d’appels par problème, ainsi que toute interruption ou nouvelle tentative. Lorsque ces données manquent, le lecteur ne peut pas distinguer un résultat à un échantillon d’une recherche intensive parmi de nombreuses trajectoires.

La fiche doit aussi séparer le modèle de son environnement. Une calculatrice, l’exécution de code, la navigation, la récupération de documents ou d’autres outils étaient-ils disponibles ? Le système pouvait-il vérifier ses propres résultats ? Une procédure externe a-t-elle choisi la meilleure réponse ? Ces conditions peuvent être appropriées si elles reflètent l’usage prévu, mais elles doivent apparaître à côté du pourcentage et non rester cachées derrière le nom du modèle.

Enfin, il faut décrire le harnais. Une implémentation documentée d’AIME 2024 utilise un prompt de sortie de la forme « ANSWER: $ANSWER », une correction par correspondance exacte, ainsi que des modifications du scoreur liées à LaTeX et aux réponses vides. Ces détails montrent pourquoi le parseur n’est pas une question administrative : il décide quel texte devient un entier et quelle sortie est déclarée invalide. La politique appliquée aux réponses absentes, multiples, ambiguës et aux erreurs de format doit être explicite.

Une même exécution peut produire de nombreux chiffres différents

Le pass@1 répond à une question simple : avec un seul échantillon par problème, combien de réponses finales étaient correctes ? C’est généralement la lecture la plus proche d’une interaction unique, à condition que le prompt, la température, le budget et les outils soient également précisés. Cela ne constitue pas nécessairement le portrait d’une conversation réelle : le protocole peut inclure des instructions conçues spécifiquement pour le benchmark.

Le pass@k change la question. Au lieu d’une seule occasion, plusieurs réponses sont générées pour chaque problème, puis l’on demande si au moins l’une d’elles est correcte. Cette valeur peut servir à étudier le potentiel de recherche du système, mais elle augmente avec le nombre de tentatives et n’équivaut pas à la probabilité de réussite d’une réponse unique livrée à un utilisateur. Publier un pass@k sans indiquer la valeur de k empêche d’interpréter le chiffre.

Le vote majoritaire, ou consensus, génère plusieurs réponses et sélectionne celle qui reçoit le plus de soutien selon une règle définie. Il peut améliorer la stabilité lorsque plusieurs trajectoires convergent vers la même solution, mais il ne garantit pas la vérité : les tentatives peuvent partager la même erreur. Sa performance dépend du nombre d’échantillons, de la manière dont sont regroupées les réponses équivalentes et du traitement des formats impossibles à extraire.

Le reranking ajoute une autre composante : après avoir produit des candidats, un sélecteur en choisit un. Ce sélecteur peut être le modèle lui-même, un vérificateur, une heuristique, un outil ou un système différent. Un résultat avec reranking mesure donc un pipeline complet. Il ne doit pas être automatiquement attribué au seul modèle générateur. Une publication d’OpenAI distingue explicitement les résultats à un échantillon, le consensus avec des dizaines d’échantillons et le reranking avec un nombre bien plus élevé d’échantillons ; cette distinction est méthodologiquement essentielle.

Les outils introduisent une autre bifurcation. Une calculatrice ou un environnement de code peut réduire les erreurs arithmétiques ; une recherche externe peut apporter des informations absentes du prompt. Aucune de ces options n’est intrinsèquement illégitime, mais « avec outils » et « sans outils » répondent à des questions différentes. Les model cards qui publient les deux conditions offrent une référence plus informative qu’un chiffre unique.

Pourquoi un pourcentage apparemment identique ne correspond pas forcément au même nombre de réussites

Dans un jeu de trente problèmes, chaque réussite représente une part appréciable du total. Lorsqu’un pourcentage est communiqué avec des décimales, il peut provenir d’une seule exécution, de répétitions, d’une moyenne entre sous-ensembles ou d’une agrégation entre configurations. Dans un jeu de quinze problèmes, les sauts d’une exécution individuelle sont encore plus grands. Ainsi, une valeur telle que 80 % ne permet pas de déduire automatiquement un nombre entier de réussites, ni le nombre de problèmes évalués.

L’arrondi n’est qu’une partie du problème. Un fournisseur peut communiquer la moyenne de nombreuses exécutions ; un autre, le meilleur résultat d’une exécution ; un troisième, la moyenne de résultats par question après plusieurs échantillonnages. Ces choix peuvent être défendables à des fins différentes, mais ils doivent être nommés. Un chiffre sans dénominateur, dispersion ou procédure d’agrégation ne doit pas être interprété comme une mesure précise.

La comparabilité impose de maintenir constants, ou au minimum de déclarer, les éléments qui affectent la difficulté effective : jeu, version des énoncés, modèle, prompt, outils, génération, extraction et notation. Si l’un d’eux diffère, la comparaison peut rester indicative, mais elle ne doit pas être transformée sans précaution en classement de capacité.

Exposition antérieure, disponibilité publique et saturation

AIME 2024 doit aussi être analysé comme un jeu ayant été accessible publiquement. Des travaux sur l’évaluation de compétitions mathématiques non contaminées considèrent cette disponibilité comme un motif raisonnable de préoccupation : un modèle ou un système de récupération pourrait avoir été exposé à des problèmes, solutions, discussions ou variantes pendant son développement. Cela ne démontre pas qu’un modèle particulier a été entraîné sur ces items et ne permet pas d’attribuer tout bon résultat à la mémorisation.

La formulation prudente est conditionnelle. L’exposition antérieure constitue un risque de validité à déclarer lorsqu’il n’existe pas d’information suffisante sur les données d’entraînement, les données d’ajustement, la récupération et la date limite. L’absence de preuve publique d’exposition ne démontre pas non plus l’indépendance. Entre ces deux extrêmes, il y a de l’incertitude, non une conclusion automatique.

On peut demander à un fournisseur des éléments de preuve proportionnés : date limite des données, description des filtrages appliqués aux données d’évaluation, politique concernant les matériaux de compétition, date de disponibilité du modèle et détails de tout outil de récupération. S’il ne peut pas les fournir, le résultat peut rester un élément de contexte, mais avec une limite claire : il ne devrait pas servir de preuve unique de généralisation à des problèmes inédits.

La saturation a également une conséquence pratique. Plus un benchmark devient populaire, plus il est probable que prompts, solutions, stratégies et configurations d’évaluation circulent largement. Pour les décisions produit, il est préférable de traiter AIME 2024 comme un signal historique et de le compléter par une batterie privée, récente et représentative du travail réel, tout en respectant les politiques d’usage et de reproduction des matériaux de la compétition.

Comment utiliser AIME 2024 dans une décision produit

Pour un responsable technique, AIME 2024 peut servir de signal secondaire lors de la présélection de systèmes résolvant des problèmes mathématiques structurés. Son utilité est la plus grande lorsqu’il s’accompagne d’un protocole clair et qu’il est comparé à des résultats obtenus dans les mêmes conditions. Il ne convient pas de le transformer en seuil unique d’achat, de déploiement ou de sécurité.

L’évaluation complémentaire dépend du cas. Si le produit génère des analyses quantitatives, des tâches propres au contexte, avec données, unités, hypothèses et vérification des calculs, sont pertinentes. S’il doit expliquer des résultats, il faut évaluer la clarté, la traçabilité et la détection des erreurs, et pas seulement l’entier final. S’il fonctionne avec des outils, il faut mesurer le pipeline complet, y compris les autorisations, le coût, la latence, les défaillances des outils et la vérification. Si la préoccupation porte sur les connaissances expertes, un benchmark tel que GPQA Diamond peut apporter un signal différent, sans pour autant remplacer des tests du flux de travail spécifique.

Il est également important de séparer l’efficience du résultat. Deux systèmes d’exactitude similaire peuvent exiger des nombres très différents d’échantillons, de tokens, d’appels ou de temps. En production, ces différences influent sur le coût, la latence, la capacité et la prévisibilité. Un tableau de benchmarks dépourvu de budget d’inférence peut masquer une différence décisive pour le cas d’usage.

Les lecteurs qui comparent une fiche de DeepSeek-R1, une fiche de GPT-6 Astra ou d’autres modèles devraient appliquer la même discipline, sans déduire des conditions non publiées à partir d’une marque. Le nom commercial ne remplace pas le snapshot, et un chiffre attribué à une organisation ne remplace pas la documentation du protocole. L’index des benchmarks et la fiche spécifique d’AIME 2024 sont les lieux appropriés pour conserver ces conditions à côté de chaque résultat.

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.