Open-Endedness Bench : ce que l’on peut affirmer et ce qui reste à vérifier

L’idée est pertinente, mais les éléments concrets ne sont pas confirmés

Évaluer un agent à partir de sa réponse finale peut être insuffisant lorsqu’il travaille sur une tâche ouverte. Dans ce type de situation, il n’existe pas nécessairement de solution unique à laquelle comparer le résultat : la manière dont l’agent y est parvenu compte également, tout comme les tests qu’il a effectués et sa capacité à changer de direction face à des éléments contradictoires. C’est le besoin auquel répondrait la proposition appelée Open-Endedness Bench (OEB), présentée dans les éléments éditoriaux reçus comme une méthode d’examen des journaux d’exécution des agents.

Toutefois, les documents disponibles pour cette vérification ne permettent pas de confirmer le préprint cité, son contenu ni l’existence de ressources complémentaires. L’article original, les consignes d’évaluation, les traces, le code et les résultats reproductibles ne sont pas non plus fournis. Il est donc impossible de présenter comme des faits les critères qu’OEB appliquerait, les agents qui auraient été évalués ou les scores qu’ils auraient obtenus. La proposition peut être évoquée comme une idée qui reste à vérifier, et non comme un benchmark validé.

Cette distinction est importante : expliquer pourquoi il pourrait être pertinent de mesurer le processus de recherche ne revient pas à démontrer qu’une méthode donnée le mesure de manière fiable. Dans cet article, les questions relatives aux hypothèses, aux expériences et aux révisions sont présentées comme des points à examiner pour évaluer ce type de méthode, et non comme des caractéristiques confirmées d’OEB.

Ce qu’il faudrait observer dans un journal de recherche

Une évaluation du processus ne peut pas se limiter à une succession de messages bien formulés. Pour examiner le raisonnement opérationnel d’un agent, le journal devrait permettre de distinguer ce que le système a proposé, les actions qu’il a réellement exécutées et les résultats qu’il a obtenus. Sans cette séparation, un récit rédigé après coup pourrait décrire des expériences plausibles sans prouver qu’elles ont eu lieu.

Il faudrait également pouvoir reconstituer le lien entre une hypothèse et un test. Par exemple, si l’agent avance qu’un changement de configuration améliorera un résultat, le journal devrait indiquer la configuration testée, les conditions de comparaison, le résultat observé et la décision prise ensuite. Il ne suffit pas que ces éléments figurent quelque part : ils doivent se rapporter à la même question et conserver assez de contexte pour qu’une autre personne puisse examiner l’interprétation.

La révision des hypothèses constitue un autre signal potentiel. Un agent qui maintient une explication malgré des résultats incompatibles pourrait ignorer des éléments pertinents ; un agent qui modifie sa conclusion devrait montrer quelle observation a motivé ce changement. Mais un journal isolé ne permet pas automatiquement de déterminer si la révision était raisonnable. Il faut des critères explicites, une définition des éléments considérés comme pertinents et, si des évaluateurs humains interviennent, des informations sur la comparaison de leurs jugements.

Ces conditions sont des exigences à rechercher dans tout benchmark consacré à la recherche automatisée. Il n’est pas possible de les attribuer à OEB tant qu’un article vérifiable ne décrit pas son protocole.

La réponse finale et le processus sont deux objets d’évaluation distincts

Les benchmarks portant sur des tâches fermées peuvent comparer une sortie à une réponse attendue ou à un résultat vérifiable. Dans le cas d’une recherche ouverte, la qualité ne se réduit pas toujours à l’exactitude d’une réponse : elle peut également dépendre du choix des expériences, de l’interprétation de données incomplètes et de la capacité à réviser une explication. Cela ne rend pas les métriques de résultat final inutiles ; cela signifie qu’elles répondent à une autre question.

À titre de contexte limité, OpenAI décrit SWE-bench Verified comme un sous-ensemble de SWE-bench validé par des personnes afin d’évaluer plus fiablement la capacité des modèles à résoudre des problèmes logiciels. Cet exemple illustre que la validation des tâches et des résultats peut faire partie de la conception d’un benchmark. Il ne démontre toutefois pas qu’un système évalue la recherche ouverte ni qu’il mesure la qualité des hypothèses d’un agent.

Pour évaluer une proposition comme OEB, il faudrait connaître au minimum les tâches incluses, les agents comparés, les unités notées et la manière dont sont établies les références de qualité. Il faudrait aussi savoir si les scores ont été validés par des évaluateurs humains, si leur degré d’accord a été mesuré et si la méthode a été testée avec des journaux trompeurs, incomplets ou rédigés sans exécution réelle d’actions. Sans ces détails, un éventuel score ne peut pas être interprété comme une preuve de rigueur scientifique.

Ce qui manque pour évaluer la proposition

La publication d’un préprint ne serait que la première étape de l’évaluation de la proposition. Pour vérifier les affirmations méthodologiques, il faudrait disposer de ressources permettant de reproduire l’évaluation : description des tâches, grilles de notation, exemples de journaux, consignes destinées aux évaluateurs et résultats détaillés. L’accès au code et aux traces originales permettrait également de vérifier si les scores dépendent du format du journal ou de choix propres à l’équipe de recherche.

Une évaluation indépendante devrait examiner à la fois la validité et la robustesse. La validité signifie que les scores reflètent bien le processus qu’ils sont censés mesurer, et non, par exemple, la longueur du journal ou la fluidité de sa rédaction. La robustesse suppose de vérifier si les conclusions se maintiennent avec d’autres agents, d’autres tâches et d’autres évaluateurs. Si la méthode fait appel à des annotations humaines, il serait aussi important de connaître le degré d’accord et les cas de désaccord, et pas seulement une moyenne globale.

La page institutionnelle d’OpenAI consacrée à SWE-bench Verified fournit des éléments de contexte sur un benchmark différent et sa validation humaine ; elle ne prouve pas qu’OEB ait fait l’objet d’une évaluation équivalente. De même, un travail portant sur un autre benchmark d’agents ne confirme ni les données ni la conception d’OEB. La proximité thématique entre plusieurs projets ne remplace pas une source primaire sur l’étude examinée.

Conclusion : ne pas confondre une proposition plausible avec un résultat établi

La question posée par Open-Endedness Bench — comment évaluer ce qu’un agent fait pendant une recherche, en plus de sa réponse finale — est pertinente pour les tâches qui ne disposent pas d’une solution de référence évidente. Cependant, les sources vérifiées fournies ne permettent pas de confirmer l’existence du préprint cité sous ce titre, ni de décrire de manière responsable sa méthode ou ses résultats. Rien ne permet non plus d’affirmer quels agents ont été évalués, quels scores ils ont obtenus ou si leurs traces et leurs outils sont disponibles.

La conclusion pratique reste donc provisoire : avant de considérer OEB comme un benchmark opérationnel, il faut retrouver et examiner sa source primaire et ses ressources. D’ici là, la démarche rigoureuse consiste à distinguer la motivation générale — évaluer les hypothèses, les tests et les révisions — des affirmations spécifiques sur la méthode. Cette prudence ne remet pas en cause l’idée ; elle évite de lui attribuer des résultats qui ne sont pas encore étayés.

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.