DeepSearchQA

Encontrar un dato y encontrar todos los datos son problemas de búsqueda distintos. Una sola consulta afortunada puede dar con una respuesta de BrowseComp; una respuesta de DeepSearchQA debe elaborarse a partir de varias búsquedas, mientras el agente lleva un seguimiento de lo que ha encontrado y de lo que aún falta. Esa exigencia de cobertura pone a prueba otra parte de la infraestructura de búsqueda: la amplitud de los resultados y la deduplicación importan tanto como la clasificación.

Lo ejecutamos manteniendo fijo el modelo porque así se aíslan las variables que los usuarios de OpenRouter realmente controlan. Estas son qué motor realiza las búsquedas, si la búsqueda se ejecuta como herramienta del servidor o como plugin, y cuántos turnos del agente se permiten en el bucle. Esos parámetros son exactamente los que puede configurar hoy en una solicitud.

Estas puntuaciones comparan configuraciones de búsqueda, no productos de agentes. El modelo solo lee fragmentos de los resultados de búsqueda, sin recuperar páginas completas ni utilizar herramientas de código, por lo que las cifras absolutas quedan por debajo de las clasificaciones publicadas de agentes, que permiten ambas cosas. Compare las configuraciones en lugar de los valores absolutos.

La calificación de todo o nada hace que esta batería sea estricta: omitir un elemento de la lista recibe la misma puntuación que omitirlos todos, por lo que las puntuaciones son bajas y las pequeñas diferencias entre motores presentan ruido. Aquí, los intervalos de confianza superpuestos se consideran no concluyentes, no una prueba de igualdad. El costo de una configuración es tan real como su puntuación, así que evalúe la calidad y la eficiencia conjuntamente.

Las preguntas son públicas, lo que significa que la memorización puede inflar las puntuaciones absolutas con el tiempo; las diferencias entre las configuraciones de búsqueda siguen siendo significativas porque todas las configuraciones comparten el mismo modelo.

Cada tarea es una pregunta con una lista de referencia de los componentes esperados de la respuesta. Un modelo evaluador comprueba la respuesta con respecto a cada componente esperado y también señala las respuestas excesivas: componentes que la respuesta afirma y que no están en la referencia. Una tarea solo es correcta cuando el evaluador encuentra todos los componentes esperados y no encuentra respuestas excesivas. La calificación es binaria, sin puntuación parcial, y las tareas fallidas o rechazadas reciben cero puntos.

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

Una configuración de búsqueda consta de un modelo, un motor de búsqueda, un formato de solicitud y un presupuesto máximo de búsqueda. Las puntuaciones se ponderan por el número de preguntas de cada ejecución verificada; se excluyen las pruebas básicas pequeñas.

Las ejecuciones se realizan en Kepler, el harness de evaluación comparativa de OpenRouter, contra endpoints de producción. Las configuraciones de herramientas de servidor establecen un presupuesto de llamadas a herramientas por solicitud para la herramienta de servidor de búsqueda web. Las configuraciones de plugins realizan una búsqueda de la pregunta antes de la inferencia con el plugin de búsqueda web. Los motores utilizan las mismas configuraciones predeterminadas que atienden el tráfico de producción.

Cada ejecución conserva su modelo exacto, motor, formato de solicitud, presupuesto de búsqueda, coste y telemetría de tiempos disponible. Las configuraciones ausentes siguen ausentes en la tabla comparativa, y absent or zero telemetry is not treated as free or instantaneous performance.