OpenProblemBench : GPT-6-Astra résout 14% des problèmes ouverts de mathématiques et de physique

Le benchmark OpenProblemBench vérifie si les modèles de langage sont capables de faire progresser des problèmes dont la science ne connaît pas encore la réponse. Il rassemble 82 problèmes non résolus tirés de la littérature en mathématiques et en physique théorique. GPT-6-Astra obtient le meilleur résultat : la part moyenne de problèmes jugés résolus par les juges s'élève à 14,0%. Les modèles ouverts full-size atteignent 5,5–6,7%, les modèles allégés Flash 2,4–3,7%. Au total, sept configurations ont été comparées.

Comment fonctionne le test

La plupart des benchmarks courants reposent sur des réponses connues : le modèle trouve la clé, ou non. Ici, il n'y a pas de clé par définition, puisque les problèmes sont ouverts. Pour chacun, les auteurs fournissent le contexte de recherche, les hypothèses et les avancées déjà connues, soit tout ce dont un chercheur a besoin pour s'attaquer à la question.

Pour que le résultat reste vérifiable, les auteurs ont sélectionné des problèmes dont les énoncés mathématiques ou les calculs décisifs se prêtent à une vérification relativement claire. Il n'existe pas pour autant de solutions de référence. Chaque réponse est évaluée indépendamment par quatre modèles-juges selon trois critères : exactitude, exhaustivité et degré d'avancée.

Paramètres clés :

• 82 problèmes non résolus tirés de la littérature en mathématiques et en physique théorique ;
• 4 modèles évaluateurs indépendants, qui travaillent sans solutions de référence ;
• 7 configurations testées ;
• GPT-6-Astra : 14,0% de part moyenne de solutions jugées valides ;
• modèles ouverts full-size : 5,5–6,7% ;
• modèles Flash : 2,4–3,7%.

L'écart est net. Le leader obtient environ deux fois le score des meilleurs modèles ouverts, et plusieurs fois celui de la classe Flash.

Ce qui distingue les meilleures réponses

Les auteurs ont examiné des cas individuels et relient les réussites à trois caractéristiques.

La première : un changement de représentation du problème. Le modèle performant reformule la question sous une forme plus facile à attaquer, au lieu de s'acharner sur l'énoncé initial.

La deuxième : des arguments généraux, qui dépassent un ensemble fini d'observations. Une vérification sur quelques cas ou une expérience numérique semblent convaincantes, mais ne constituent pas une preuve. Une réponse qui construit un raisonnement valable pour toute une classe d'objets a, par nature, bien plus de valeur.

La troisième : la démonstration des étapes nécessaires pour achever la solution. Les réponses faibles s'arrêtent souvent à l'idée et laissent le lemme clé sans justification. Les juges notent ces travaux sévèrement sur le critère d'exhaustivité.

Comment lire ces chiffres

Il faut les assortir de réserves. L'indicateur s'appelle « judged solve rate » : il s'agit d'une évaluation par des modèles-juges, et non d'une solution confirmée. Le résumé de l'étude ne dit rien d'une vérification de chaque réponse par des mathématiciens professionnels. Par ailleurs, le jeu de problèmes est biaisé en faveur de questions aux énoncés vérifiables : les 14% ne peuvent donc pas être extrapolés à l'ensemble des questions ouvertes de la science. Ce chiffre mesure un échantillon sélectionné à dessein.

Voici la conclusion pratique pour les équipes qui choisissent des modèles pour un travail de recherche. Premièrement, l'écart entre le modèle phare et les modèles ouverts full-size est ici substantiel : pour les tâches impliquant des démonstrations, économiser sur la classe du modèle se paie en qualité. Les modèles Flash sont à réserver au travail préparatoire : recherche bibliographique, reformulations, vérification de calculs isolés.

Deuxièmement, si vous construisez un pipeline avec un chercheur IA, prévoyez une vérification indépendante. Un modèle-juge sans solution de référence peut se tromper, et c'est une vérification formelle ou un expert qui reste le filtre final. Troisièmement, les trois caractéristiques des bonnes réponses indiquent comment rédiger les requêtes : demandez de changer la formulation, exigez un argument général plutôt que des exemples, et réclamez séparément la démonstration de chaque étape. OpenProblemBench vaut comme banc de mesure : il montre où les modèles sont déjà utiles aux co-auteurs et où ils restent faibles.