HLE

HLE se sitúa en el extremo opuesto del espectro de búsqueda respecto a BrowseComp. Sus preguntas fueron redactadas por expertos en la materia para ser inequívocas pero extremadamente difíciles, por lo que la puntuación de referencia de un modelo depende principalmente de lo que ya sabe. Añadir búsqueda web lo convierte en una pregunta diferente: ¿cuánto conocimiento de nivel experto puede recuperar una configuración de búsqueda bajo demanda?

Lo ejecutamos manteniendo el modelo fijo porque eso aísla las variables que los usuarios de OpenRouter realmente controlan. Estas son qué motor gestiona 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 en una solicitud hoy.

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

Como HLE se basa en conocimientos especializados más que en la profundidad de navegación, las diferencias entre las configuraciones de búsqueda son menores aquí que en BrowseComp: muchas preguntas se responden (o se fallan) de la misma manera con cualquier presupuesto. Las diferencias entre motores con intervalos de confianza superpuestos se consideran aquí no concluyentes, no una prueba de igualdad. El coste de una configuración es tan real como su puntuación, por lo que debe evaluar la calidad y la eficiencia conjuntamente.

Utilizamos el subconjunto de solo texto del conjunto de datos público (se excluyen las preguntas multimodales), por lo que las puntuaciones no son directamente comparables con las clasificaciones de HLE completo. 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 respuesta de referencia breve. El modelo responde en un formato fijo (explicación, respuesta exacta, confianza declarada), y un modelo evaluador determina si la respuesta extraída es semánticamente equivalente a la de referencia: la misma evaluación de equivalencia de respuestas que utiliza BrowseComp. La calificación es binaria, sin puntuación parcial, y las tareas fallidas o rechazadas reciben una puntuación de cero.

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

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.