HLE

HLE se situe à l’opposé de BrowseComp sur le spectre de la recherche. Ses questions ont été rédigées par des experts du domaine pour être sans ambiguïté mais extrêmement difficiles, de sorte que le score de référence d’un modèle dépend principalement de ce qu’il sait déjà. L’ajout de la recherche web pose une autre question : quelle quantité de connaissances de niveau expert une configuration de recherche peut-elle récupérer à la demande ?

Nous l’exécutons en gardant le même modèle, car cela permet d’isoler les variables que les utilisateurs d’OpenRouter contrôlent réellement. Il s’agit du moteur qui traite les recherches, de l’exécution de la recherche en tant qu’outil serveur ou extension, et du nombre de tours d’agent autorisés dans la boucle. Ces paramètres sont précisément ceux que vous pouvez définir dans une requête aujourd’hui.

Ces scores comparent des configurations de recherche, et non des produits d’agents. Le modèle lit uniquement des extraits de résultats de recherche, sans récupération de pages complètes ni outils de code, de sorte que les valeurs absolues sont inférieures à celles des classements d’agents publiés, qui autorisent les deux. Comparez les configurations plutôt que les niveaux bruts.

Comme HLE repose sur l’expertise plutôt que sur la profondeur de navigation, les différences entre configurations de recherche sont plus faibles ici que sur BrowseComp : de nombreuses questions obtiennent la même réponse (correcte ou non) quel que soit le budget. Les écarts entre moteurs dont les intervalles de confiance se chevauchent sont considérés ici comme non tranchés, et non comme une preuve d’égalité. Le coût d’une configuration est aussi réel que son score, alors examinez conjointement la qualité et l’efficacité.

Nous utilisons le sous-ensemble textuel du jeu de données public (les questions multimodales sont exclues), les scores ne sont donc pas directement comparables à ceux des classements HLE complets. Les questions sont publiques, ce qui signifie que la mémorisation peut gonfler les scores absolus au fil du temps ; les différences entre configurations de recherche restent pertinentes, car toutes les configurations utilisent le même modèle.

Chaque tâche est une question accompagnée d’une courte réponse de référence. Le modèle répond dans un format fixe (explication, réponse exacte, niveau de confiance déclaré), et un modèle juge évalue si la réponse extraite est sémantiquement équivalente à la référence — la même méthode d’évaluation de l’équivalence des réponses que celle utilisée par BrowseComp. La note est binaire, sans points partiels, et les tâches échouées ou refusées obtiennent zéro.

reward = judge(extracted_answer ≡ reference_answer)   // ∈ {0, 1}
judge  = gpt-4.1 at temperature 0, strict json_schema verdict
empty or refused answers skip the judge and score 0

Une configuration de recherche comprend un modèle, un moteur de recherche, un format de requête et un budget de recherche maximal. Les scores sont pondérés par le nombre de questions de chaque exécution vérifiée ; les petits tests de bon fonctionnement sont exclus.

Les exécutions ont lieu sur Kepler, le harness d’évaluation comparative d’OpenRouter, sur des points de terminaison de production. Les configurations d’outil serveur définissent un budget d’appels d’outil par requête pour l’ outil serveur de recherche web. Les configurations d’extension effectuent une seule recherche de la question avant l’inférence avec l’ extension de recherche web. Les moteurs utilisent les mêmes configurations par défaut que celles qui traitent le trafic de production.

Chaque exécution conserve le modèle exact, le moteur, le format de requête, le budget de recherche, le coût et les données de télémétrie temporelle disponibles. Les configurations manquantes restent absentes du tableau comparatif, et absent or zero telemetry is not treated as free or instantaneous performance.