Artificial Analysis Search Index: metodología del benchmark de Search APIs
Descripción general
Search API Bench evalúa proveedores de búsqueda en un escenario de búsqueda agéntica.
El benchmark es una comparación por intercambio de proveedor. Cada muestra usa el mismo modelo de respuesta candidato y la misma tarea del benchmark, y solo varía el proveedor de búsqueda.
Evaluamos los resultados con un único modelo de respuesta, lo que nos permite medir la mejora que aporta cada proveedor de Search API.
A lo largo de esta página, un resultado es un proveedor de Search API combinado con el modelo de respuesta candidato fijo. Lo llamamos resultado de proveedor.
Métricas clave
Artificial Analysis Search Index
El ranking público se encabeza con una única puntuación combinada, el Artificial Analysis Search Index. Es la media con igual ponderación de la métrica de calidad principal de cada benchmark:
Notas sobre el cálculo:
- AA-Omniscience aporta la precisión, no su Omniscience Index ni su tasa de alucinación. La precisión es la señal más directamente comparable cuando un proveedor de búsqueda se combina con el modelo candidato.
- Todas las entradas usan las mismas constantes (que se describen más abajo), de modo que el índice aísla al proveedor de búsqueda.
Componentes del índice
| Evaluación | Ámbito | Tareas | Tipo de respuesta | Puntuación |
|---|---|---|---|---|
| DeepSearchQA | QA de investigación profunda (respuesta única y por conjunto) | 900‡ | Respuesta abierta / conjunto de respuestas | F1 evaluado por LLM sobre los elementos de la respuesta, pass@1 |
| AA-Omniscience | QA factual (corrección + calibración) | 600† | Respuesta abierta (se permite abstenerse) | Precisión evaluada por LLM, pass@1 |
| BrowseComp | QA difícil de búsqueda web | 200^ | Respuesta exacta breve | Precisión de respuesta exacta evaluada por LLM, pass@1 |
Los tres benchmarks usan GPT-5.6 Luna (medium) para la evaluación, cada uno con sus propias rúbricas.
‡ DeepSearchQA: la división pública de evaluación completa, de 900 filas.
† AA-Omniscience: 600 muestras privadas reservadas, equilibradas con 100 por dominio en 6 dominios.
^ BrowseComp: un subconjunto difícil de 200 muestras extraído del conjunto de evaluación de 1266 muestras.
Constantes
Todos los valores siguientes se mantienen fijos en todos los resultados de proveedor, de modo que el proveedor de búsqueda es la única variable de la comparación.
- Modelo de respuesta candidato: GPT-5.6 Luna (medium)
- Esfuerzo de razonamiento: Medium
- Temperatura: 0,6
- Máximo de tokens de salida: 127.999 tokens
- Modelo evaluador: GPT-5.6 Luna (medium), compartido por los tres benchmarks
- Presupuesto de turnos: 25 turnos del agente (t25)
- Llamadas a herramientas por muestra: Ilimitadas dentro del presupuesto de turnos
- Resultados de búsqueda mostrados: Hasta 10 resultados por búsqueda
- Herramientas de búsqueda:
web_searchyweb_fetchweb_search: envía la consulta del modelo candidato al proveedor de Search API correspondiente y devuelve su carga de respuesta nativa.web_fetch: obtiene una URL de un resultado de búsqueda y devuelve el contenido de la página (solo texto).
- Capa de extracción: Extractor solo de texto con un tiempo de espera de 15 segundos por página
- Formato de la carga de búsqueda: Nativo del proveedor; el modelo ve el cuerpo de respuesta original del proveedor
- Filtrado de contaminación: Activado, tal como se describe más abajo
- Flujo de trabajo del agente: Uno de estos dos:
- línea base sin búsqueda
model_only, o - bucle de agente de búsqueda Stirrup
- línea base sin búsqueda
Flujo de trabajo
Línea base de solo modelo
La muestra model_only hace una única llamada directa al modelo candidato con el prompt del benchmark y sin herramientas de búsqueda. Estima cuánto puede resolver el modelo candidato únicamente con su conocimiento interno o su razonamiento.
Una puntuación alta en model_only indica que la muestra del benchmark se puede responder sin información de búsqueda actualizada, mientras que una puntuación más baja en model_only facilita observar la mejora que aporta la búsqueda.
Bucle del agente de búsqueda
Las muestras con búsqueda usan un bucle de agente fijo orquestado por el entorno Stirrup de Artificial Analysis.
El entorno ofrece dos herramientas: web_search y web_fetch.
El proveedor de Search API bajo prueba alimenta la herramienta web_search, y el modelo candidato dispone de un total de 25 turnos con llamadas a herramientas ilimitadas para resolver la tarea.
Cuando el modelo considera que ha reunido información suficiente, llama a la herramienta finish para entregar su respuesta final. Si agota los 25 turnos sin llamar a finish, no se entrega ninguna respuesta y la tarea puntúa cero.
Un evaluador específico de cada benchmark puntúa la respuesta frente a datos de referencia ocultos.
Gestión de errores
Los errores recuperables se devuelven al modelo como una llamada a herramienta fallida y se mantienen en los resultados publicados. Entre ellos están:
- Tiempos de espera agotados o errores HTTP en las páginas web solicitadas
- El modelo solicita una URL que
web_searchno devolvió
Los errores fatales se reintentan hasta que tienen éxito, de modo que ningún resultado publicado contiene uno. Entre ellos están:
- Errores del proveedor de Search API (por ejemplo, 429, 5xx y tiempos de espera agotados)
Costo
Los costos se reportan como costo total del experimento y se desglosan en:
- Costo del modelo de respuesta candidato, incluidos todos los tokens de entrada, en caché, de razonamiento y de salida.
- Costo del proveedor de Search API.
- Nota: la línea base
model_onlyno tiene costo de proveedor de Search API.
- Nota: la línea base
Latencia
La latencia se reporta de varias formas:
- Tiempo de modelo por tarea. Tiempo medio derivado de extremo a extremo de los tokens de entrada, razonamiento y salida del modelo candidato por tarea.
- Tiempo de búsqueda por tarea. Tiempo medio medido dentro de
web_searchpor tarea. - Tiempo por tarea. Suma del tiempo de modelo por tarea y del tiempo de búsqueda por tarea.
- Tiempo por consulta de búsqueda. Latencia media de cada solicitud
web_searchindividual a lo largo de todo el benchmark.
Un proveedor puede ser rápido por llamada y aun así aportar más tiempo total si el modelo lo consulta con más frecuencia.
Filtrado de contaminación
El filtrado de contaminación elimina las filtraciones del benchmark conocidas y potenciales, junto con sus fuentes.
El filtrado se aplica dentro de ambas herramientas de búsqueda antes de que el modelo candidato vea salida alguna: los resultados de web_search se revisan por URL, título y fragmento, y el texto de página de web_fetch se revisa tras la extracción. Las entradas marcadas se descartan de la lista de resultados del proveedor sin alterar la forma de la respuesta.
Por ejemplo:
- Ubicaciones de fuentes conocidas. URL y conjuntos de datos donde se aloja originalmente el benchmark.
- Señales asociadas al texto del conjunto de datos. Cadenas canario conocidas en el material de origen.
Ajustes de las APIs de los proveedores de búsqueda
Cada proveedor usa un valor fijo de max_results=10 (o su equivalente). Todos los ajustes se mantienen en los valores predeterminados del proveedor, salvo los indicados a continuación.
| Resultado de proveedor | Documentación | Ajustes de la solicitud en el benchmark |
|---|---|---|
| Brave web | Brave Web Search API | q=agent query, result_filter=web |
| Brave LLM context | Brave LLM Context API | q=agent query, api=llm_context |
| Exa instant | Exa Search API | type=instant, contents={"highlights": True} |
| Exa fast | Exa Search API | type=fast, contents={"highlights": True} |
| Exa auto | Exa Search API | type=auto, contents={"highlights": True} |
| Firecrawl | Firecrawl Search API | scrape_format=none |
| Keenable pro | Keenable Search API | mode=pro |
| Keenable realtime | Keenable Search API | mode=realtime |
| Parallel turbo | Parallel Search API | mode=turbo |
| Parallel fast | Parallel Search API | mode=fast |
| Parallel basic | Parallel Search API | mode=basic |
| Parallel advanced | Parallel Search API | mode=advanced |
| Perplexity low | Perplexity Search API | search_context_size=low |
| Perplexity medium | Perplexity Search API | search_context_size=medium |
| Perplexity high | Perplexity Search API | search_context_size=high |
| Tavily basic | Tavily Search API | search_depth=basic |
| TinyFish web | TinyFish Search API | domain_type=web |
| You.com snippets | You.com Search API | safesearch=moderate |
| You.com highlights | You.com Search API | safesearch=moderate, extraction={"extraction_mode": "highlights"} |
Alcance de los benchmarks
DeepSearchQA
Un benchmark de QA al estilo de la investigación profunda, con filas de respuesta única y de conjunto de respuestas.
- Fuente: Google DeepSearchQA. Hugging Face. Artículo.
- Alcance de la muestra: división pública
evalcompleta, de 900 filas. - Métrica principal: F1.
BrowseComp
Un benchmark difícil de QA con búsqueda web.
- Fuente: OpenAI BrowseComp, distribuido con Simple Evals. Artículo.
- Alcance de la muestra: el panel de decisión
n200de 200 muestras, seleccionado como se describe en Componentes del índice. - Métrica principal: precisión.
AA-Omniscience
Un benchmark privado y reservado de QA factual centrado en la corrección y la calibración.
- Fuente: AA-Omniscience. Conjunto de datos público de referencia: AA-Omniscience-Public. Artículo.
- Alcance de la muestra: 600 muestras privadas, equilibradas con 100 filas por dominio en 6 dominios.
- Métrica principal: precisión.
Usamos la precisión en lugar del Omniscience Index o la tasa de alucinación. AA-Omniscience se diseñó para evaluar el conocimiento paramétrico y la capacidad de abstenerse cuando no hay contexto suficiente.
Cuando una herramienta de búsqueda aporta contexto, el modelo tiende a responder siempre, así que la precisión responde a esta pregunta: dado el contexto de búsqueda de un proveedor, ¿con qué exactitud responde el modelo?
Cómo interpretar los resultados
Search API Bench es una comparación con varios objetivos:
- ¿La búsqueda mejoró la respuesta frente a
model_only? - ¿Qué proveedor mejoró más la calidad?
- ¿Cuánto costó esa mejora?
- ¿Cuánta latencia añadió?
- ¿Las mejoras se mantienen en todos los benchmarks o son específicas de una familia de tareas?
El proveedor más adecuado para una tarea concreta puede no ser el de mayor puntuación. Para un caso de uso específico, conviene evaluar al proveedor de búsqueda ganador según:
- Mejora de calidad respecto a la línea base.
- Aumento de costo respecto a la línea base.
- Aumento de latencia respecto a la línea base.