BrowseComp

Les questions de BrowseComp ciblent une réponse unique et vérifiable derrière plusieurs niveaux d’indirection, comme une personne décrite par des fragments de carrière ou un événement identifié par des contraintes croisées. Une seule recherche suffit rarement ; l’agent doit formuler des hypothèses, chercher, écarter des pistes et changer de direction. Cela en fait notre outil le plus précis pour mesurer l’apport d’une configuration de recherche : le même modèle obtient un score plusieurs fois supérieur avec un budget agentique complet qu’avec une seule recherche avant l’inférence.

Nous l’exécutons en gardant le modèle fixe, car cela permet d’isoler les variables que les utilisateurs d’OpenRouter contrôlent réellement. Il s’agit du moteur qui effectue les recherches, de l’exécution de la recherche sous forme d’outil serveur ou de plugin, et du nombre de tours d’agent autorisés dans la boucle. Ces paramètres sont exactement ceux que vous pouvez définir sur 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 des résultats de recherche, sans récupération de pages complètes ni outils de code, si bien que les chiffres absolus sont inférieurs à ceux des classements d’agents publiés, qui autorisent les deux. Comparez les configurations plutôt que les niveaux bruts.

Les plages de confiance qui se chevauchent sont considérées ici comme non concluantes, et non comme une preuve d’égalité. Le coût doit être pris en compte au même titre que la qualité lorsqu’une configuration est légèrement meilleure et beaucoup plus chère.

Le jeu de données est distribué sous forme chiffrée avec une chaîne sentinelle pour éviter son inclusion dans les corpus d’entraînement, mais les questions sont publiques ; l’évaluation dépend d’une recherche en direct en plusieurs étapes, qu’il est difficile de contourner par la mémorisation.

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. « 1988 à 1996 » correspond à « 1988-96 » ; une entité différente constitue un échec. 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.