DeepSearchQA

Trouver un fait et trouver tous les faits sont deux problèmes de recherche différents. Une seule requête chanceuse peut suffire à trouver une réponse à BrowseComp ; une réponse à DeepSearchQA doit être assemblée au fil des recherches, l’agent suivant ce qu’il a trouvé et ce qui manque encore. Cette exigence de couverture sollicite une autre partie de la pile de recherche : la diversité des résultats et la déduplication comptent autant que le classement.

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 autorisés dans la boucle de l’agent. Ces paramètres sont exactement 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 des pages complètes ni outils de code, de sorte que les valeurs absolues restent inférieures à celles des classements d’agents publiés, qui autorisent les deux. Comparez les configurations plutôt que les niveaux bruts.

La notation tout ou rien rend cette suite stricte : omettre un élément d’une liste donne le même score que les omettre tous, ce qui explique les scores faibles et le bruit dans les petits écarts entre moteurs. Les intervalles de confiance qui se chevauchent sont ici considérés comme non concluants, et non comme une preuve d’égalité. Le coût d’une configuration est aussi réel que son score, il faut donc considérer ensemble la qualité et l’efficacité.

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 significatives, car toutes utilisent le même modèle.

Chaque tâche consiste en une question accompagnée d’une liste de référence des éléments de réponse attendus. Un modèle évaluateur vérifie la réponse par rapport à chaque élément attendu et signale également les réponses excessives — les éléments affirmés dans la réponse qui ne figurent pas dans la référence. Une tâche n’est correcte que si le modèle évaluateur retrouve tous les éléments attendus et ne relève aucune réponse excessive. La note est binaire, sans points partiels, et les tâches échouées ou refusées obtiennent zéro.

reward = all_expected_parts_found ∧ no_excessive_answers   // ∈ {0, 1}
judge  = gemini-2.5-flash, strict json_schema completeness 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.