Agentic RAG Benchmark: enrutamiento entre 11 bases de datos SQL

La precisión de enrutamiento es el porcentaje de preguntas puntuadas en las que el modelo menciona explícitamente la base de datos correcta en su respuesta final. El titular utiliza las 184 preguntas marcadas como difíciles tanto por nuestra prueba de similitud como por un jurado de tres LLMs. Las declaraciones explícitas faltantes no reciben crédito.

Hallazgos del enrutamiento de bases de datos

qwen3.8-max registró una precisión de enrutamiento del 83,2 % en una ejecución de $25,14

Qwen3.8-max respondió correctamente 153 de 184 preguntas difíciles de enrutamiento a un coste registrado de $25.14. claude-fable-5 respondió 151 a $121.55. Todas las 759 preguntas se completaron en ambas ejecuciones.

Esta diferencia de dos preguntas es menor que el movimiento medido en la repetición de qwen3.8-max. Los costes registrados dependen de la selección del proveedor y del uso de la caché, por lo que esta comparación no puede establecer una clasificación duradera de precio-rendimiento.

La precisión final de enrutamiento aumentó para Grok y Opus, pero bajó para Nova

Para claude-opus-5, la precisión en preguntas difíciles aumentó 25.0 puntos porcentuales entre su primera comprobación de base de datos y su declaración final. grok-4.5 ganó 38.0 puntos dentro de su propia ejecución. gpt-5.4-mini no registró ganancia, mientras que nova-lite-v1 perdió 14.0 puntos.

Cada cambio compara el inicio y el final de una ejecución. Las preguntas que tocaron varias bases de datos en el primer turno se excluyen porque no tienen una única primera elección.

Este recuento utiliza la primera base de datos en el orden de llamadas registrado, incluidos los primeros turnos de varias bases de datos. Los cambios en puntos porcentuales anteriores utilizan una única primera elección.

Por lo tanto, una llamada a la base de datos no garantiza una corrección útil. Lo que importa es si el modelo utiliza la información devuelta para llegar a la elección final correcta. Esta es una observación de las trayectorias registradas, sin una intervención separada que aísle el valor de las llamadas adicionales.

Resultados del enrutamiento de bases de datos

Los modelos aparecen en orden alfabético. La metodología identifica diferencias en el software utilizado para ejecutarlos. Estas condiciones importan al interpretar pequeñas diferencias de puntuación.

Los intervalos estiman la incertidumbre del muestreo de preguntas. Los costes registrados cubren los registros correctos de cada ejecución. Reflejan los proveedores y las condiciones de caché utilizados en el momento de la medición.

Modelos de decisión para el enrutamiento de bases de datos

Comparamos Jev, Kev-9B, Laya English y seis LLMs en 243 preguntas revisadas de las mismas 11 bases de datos. Cada modelo seleccionó una base de datos a partir de las descripciones proporcionadas.

Laya se ejecutó localmente en un Apple M4. Kev se ejecutó en un servicio A100 dedicado al que se accedía a través de un túnel SSH. Los demás modelos usaron APIs alojadas. La latencia incluye la solicitud completa del cliente entre las respuestas válidas. La precisión incluye cada pregunta intentada.

Jev seleccionó la base de datos correcta en 240 de 243 preguntas, en comparación con 123 de Laya English: 117 selecciones correctas más, una diferencia de 48.1 puntos porcentuales. Jev fue el modelo alojado más rápido por latencia mediana en esta ejecución. El despliegue local de Laya tuvo la latencia mediana más baja en general, junto con una precisión sustancialmente menor.

Kev-9B seleccionó 236 bases de datos correctamente, cuatro menos que Jev. Cinco de sus siete errores estuvieron relacionados con la base de datos de tarjetas de débito de combustible. Su respuesta mediana tardó 952 ms incluyendo la red y el túnel SSH. La mediana registrada por separado del servidor fue de 470 ms. Este despliegue en A100 usó FP32 y kernels de referencia. Su velocidad depende de esa configuración de servicio.

Gemini 3.8 Flash y Claude Opus 5 seleccionaron la base de datos correcta en todas las preguntas. Opus tardó 1.72 veces más en la mediana y su coste de API comunicado fue 7.58 veces el de Gemini para estas preguntas. La precisión fue igual para estos dos modelos en este conjunto.

El resultado de DeepSeek incluye 19 fallos de servicio o de salida: 16 respuestas HTTP 429, dos respuestas que rompieron el formato requerido de alias único y una que agotó el presupuesto de salida. Seleccionó la base de datos correcta en 211 de sus 224 respuestas válidas, o el 94,2 %. Contando todos los intentos se obtiene el 86,8 % que se muestra en el gráfico y la tabla.

Costes de enrutamiento: precios de API y estimaciones de hardware

Jev seleccionó la base de datos correcta en el 98,8 % de las preguntas con un coste de API de $0,0337 por cada 1.000 intentos de enrutamiento. Qwen3.8 Flash registró una precisión del 97,9 % a $0,0791, mientras que Gemini 3.8 Flash alcanzó el 100,0 % a $0.5337. Escalamos los costes a partir de la misma carga de trabajo de 243 preguntas, incluidas las respuestas incorrectas y excluidos los calentamientos. El coste de API de Jev fue aproximadamente 1/120 del de Claude Opus 5 para los mismos 243 intentos de enrutamiento.

La estimación de hardware de Laya fue de $0,0141 por cada 1.000 intentos con una precisión del 50,6 %. Kev alcanzó el 97,1 % a un coste estimado de $0.1250. Ambas estimaciones asumen que la máquina alquilada procesa solicitudes de forma continua. Con una utilización del 10 %, cada solicitud conlleva diez veces el coste de alquiler, lo que eleva a Laya a $0,1405 y a Kev a $1,2503 por cada 1.000 intentos.

Para los cinco LLMs con registros de cobro completos, dividimos los cargos de API comunicados entre 243 y multiplicamos por 1.000. Jev cobra $0,042 por millón de tokens de entrada, con tokens de salida gratuitos. Sus 194.882 tokens de entrada registrados costaron $0,008185 en 243 intentos, o $0,0337 por cada 1.000.¹

El coste de hardware por cada 1.000 intentos es igual al precio de alquiler por hora × los segundos medios de procesamiento × 1.000 ÷ (3.600 × utilización). Laya promedió 0.2006 segundos por solicitud en un Apple M4. Kev promedió 0.4734 segundos en el servidor A100, excluyendo la red y el retraso SSH. Aplicamos esos tiempos al hardware equivalente de los proveedores citados. El rendimiento y los totales de facturación en esos proveedores siguen sin medirse.

Para Kev, usamos $0,9508/hora por una A100 SXM de 80 GB en Vast.ai, la oferta bajo demanda equivalente más baja de nuestro GPU índice de precios de alquiler.

Para Laya, usamos el M4-S de Scaleway con 16 GB de memoria a €0.22/hora. La conversión utiliza el tipo del BCE del 22 de septiembre de $1,1463 por euro. Scaleway exige un alquiler mínimo de 24 horas, lo que hace que el alquiler mínimo sea de €5.28, o unos $6,05, incluso para un trabajo corto.²³⁴

La página del modelo de Laya no incluía ningún Hugging Face Inference Provider. Nuestra estimación cubre el alquiler de una máquina y la ejecución del modelo en ella. El tiempo de configuración, el almacenamiento, los extras de red, los impuestos y la mano de obra de operaciones están excluidos de ambas estimaciones de hardware.⁵

Cómo eligen una base de datos los modelos de decisión

Para Jev y Laya, la aplicación suministra el contexto, una pregunta y opciones con nombre y descripciones. Sus interfaces Choice devuelven una opción seleccionada, probabilidades sobre las opciones y una puntuación de confianza. El código de la aplicación decide qué hacer con ese resultado. Para el enrutamiento, las opciones son alias de bases de datos como db_03 y db_07.⁶⁵

Este formato facilita el uso de la salida en el código. Un modelo aún puede elegir la base de datos incorrecta. Una puntuación de confianza alta también necesita validación frente a la corrección observada antes de que una aplicación la use para omitir la revisión o activar un plan alternativo.

El checkpoint en inglés de Laya utiliza un codificador bidireccional ModernBERT con una cabeza de decisión que puntúa las opciones suministradas. Las descripciones de las opciones llegan con la solicitud, por lo que la aplicación puede cambiar sus opciones disponibles. Jev expone una API de Choice alojada. Su documentación sitúa el control del flujo de trabajo y las acciones en el código de la aplicación. La interfaz compartida no establece que los dos modelos tengan la misma arquitectura interna.⁵⁷

Kev-9B utiliza un adaptador LoRA y una cabeza de puntero sobre Qwen3.5-9B-Base. Puntúa las opciones suministradas y devuelve sus probabilidades sin generar texto de respuesta. Usamos su endpoint Choice compatible con la misma pregunta y las mismas descripciones de bases de datos.⁸

Condiciones que afectan a la selección de bases de datos

Las bases de datos similares redujeron la precisión de enrutamiento en unos 20 puntos

Probamos el método de selección de bases de datos en un experimento separado con 128 preguntas. Cada pregunta conservó su base de datos correcta, mientras que las otras 10 candidatas procedían de nuestro grupo seleccionado o de un sorteo aleatorio.

En el subconjunto difícil, claude-opus-4.8 obtuvo un 71,3 % con candidatas similares y un 92,0 % con candidatas aleatorias. gemini-3.5-flash obtuvo un 77,0 % y un 96,6 %. Ambas diferencias tuvieron valores p inferiores a 0.001 en pruebas emparejadas.

Este experimento utilizó descripciones y una respuesta de modelo por pregunta, sin el bucle de herramientas agéntico. Respalda la conclusión más limitada de que seleccionar candidatas similares dificulta la elección de base de datos. La brecha medida no debe presentarse como el efecto de la exploración agéntica.

Solo los nombres produjeron una precisión del 68,8 % y del 71,1 % en un estudio piloto

En otro estudio piloto de 128 preguntas, claude-opus-4.8 seleccionó la base de datos correcta el 68,8 % de las veces solo con los nombres. Su puntuación con nombres y descripciones fue del 67,2 %. gemini-3.5-flash obtuvo un 71,1 % con los nombres y un 75,0 % con el catálogo completo.

Nombres como california_schools y toxicology revelan el tema directamente. Para el benchmark principal, reemplazamos los nombres de las bases de datos por alias de db_01 a db_11. Las descripciones siguen explicando el dominio de cada base de datos y las respuestas de las herramientas exponen los nombres de sus tablas y columnas.

Fiabilidad de las comparaciones de enrutamiento y costes

Las ejecuciones repetidas cambiaron la precisión de enrutamiento entre 1.6 y 2.7 puntos

claude-opus-5 seleccionó la base de datos correcta en 156 de 184 preguntas difíciles en su primera ejecución y 151 en su repetición. Su precisión bajó del 84,8 % al 82,1 %. qwen3.8-max pasó de 153 respuestas correctas a 150, una disminución del 83,2 % al 81,5 %.

Ambas repeticiones usaron las mismas preguntas, anonimización, temperatura y configuración de proveedor que sus ejecuciones originales. qwen3.8-max cambió su respuesta en 13 preguntas difíciles aunque su total solo varió en tres. Las mejoras en algunas preguntas cancelaron errores en otras.

Estas repeticiones muestran que las pequeñas diferencias de puntuación pueden desaparecer en otra ejecución. Una repetición por modelo no puede establecer una distribución de resultados, y los otros 35 modelos no tienen medición repetida.

Los costes registrados dependen del proveedor y de la configuración de caché

El almacenamiento en caché de prompts reutiliza la entrada procesada previamente para reducir los costes facturados de entrada. La ejecución de claude-opus-5 costó $62,78, en comparación con un coste estimado de $105,54 a las tarifas de lista sin caché para el mismo uso registrado. Esa estimación implica un ahorro del 40,5 %. Es una comparación contable, sin una ejecución de precisión separada sin caché.

Agentic RAG y selección de bases de datos

Agentic RAG da al modelo control sobre las decisiones de recuperación. Puede elegir una fuente, inspeccionar la respuesta y hacer otra solicitud. Un RAG pipeline simple recupera contexto mediante una secuencia predeterminada antes de generar una respuesta.

Este benchmark prueba la selección de fuentes mediante herramientas de bases de datos SQL. No contiene un índice de documentos, pasajes recuperados ni una puntuación de fundamentación de la respuesta. Por lo tanto, los resultados describen una parte de un sistema de recuperación agéntico. La búsqueda documental se cubre por separado en nuestro benchmark de búsqueda agéntica.

Un modelo comienza con descripciones breves de bases de datos. Puede solicitar listas de tablas, inspeccionar columnas, ejecutar SQL y cambiar de base de datos. Su respuesta final contiene una elección de base de datos y una consulta. Nuestro benchmark de texto a SQL informa de la precisión de SQL y de dos puntuaciones de revisión complementarias.

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Metodología del benchmark de Agentic RAG

El conjunto de preguntas es un subconjunto congelado de BIRD-SQL, que empareja preguntas en lenguaje natural con consultas de referencia en SQL.⁹

Dos señales definen la dificultad. La prueba de similitud cuenta cuántos de los 20 vecinos más cercanos de una pregunta pertenecen a otras bases de datos. Tres LLMs evalúan si la pregunta resulta confusa entre bases de datos. La pertenencia al grupo más difícil requiere al menos cinco vecinos de otras bases de datos y una etiqueta de jurado confusa.

El enrutamiento utiliza la base de datos indicada en el campo explícito selected_database. Una ruta inferida del texto se excluye del titular. La corrección de SQL se puntúa por separado y no determina el crédito de enrutamiento.

El arnés es el software que presenta las herramientas y registra las respuestas del modelo. El panel principal contiene 36 ejecuciones de OpenRouter y una ejecución de Codex CLI. Entre las ejecuciones de API, 19 usaron v3, 15 usaron una versión anterior y dos combinaron registros de ambas versiones. En v3, una capa de recuperación analiza los formatos alternativos de llamada a herramientas admitidos. Para llama-4-maverick, la proporción registrada de formato no nativo fue del 97,9 %, por lo que ese resultado depende en gran medida del adaptador. minimax-m2.7 fue excluido porque no emitió las llamadas a herramientas de base de datos requeridas por la tarea.

GPT-6 Astra se ejecutó dentro de Codex CLI, cuyo identificador de arnés registrado es codex_cli_transcript_v1. Debido a que la configuración difiere, las diferencias de puntuación no pueden atribuirse solo al modelo. GPT-6 Astra completó las 759 preguntas. Seleccionó la base de datos correcta en 155 de 184 preguntas difíciles y registró una precisión de enrutamiento del 95,3 % en todo el conjunto. Su ejecución no informó de costes en dólares.

Benchmark de enrutamiento de modelos de decisión

El experimento de enrutamiento separado utilizó 243 preguntas sin cambios seleccionadas de 394 candidatas después de reservar 17 preguntas de desarrollo. El conjunto de consultas contenía 204 preguntas originalmente fáciles y 39 originalmente difíciles. Esas etiquetas de dificultad no se revalidaron para esta tarea y la selección no fue una evaluación ciega de exclusión.

Cuatro descripciones de bases de datos se corrigieron usando los esquemas de origen y el texto de las preguntas antes de recoger las predicciones medidas. Las otras siete conservaron sus descripciones compactas. Cada modelo recibió la misma pregunta, 11 alias y descripciones, y el mismo orden de opciones para esa pregunta. El SQL de referencia, las etiquetas de origen y la evidencia complementaria se omitieron. Jev y Laya usaron su interfaz nativa Choice. A los LLMs se les instruyó para que devolvieran un alias. Los modelos no tenían herramientas de bases de datos.

Ejecutamos Jev 1.13.0 a través de su API alojada y el checkpoint fijado de Laya English localmente con Apple M4 MPS, 16 GiB de memoria y cuatro hilos Torch. El límite de 404 tokens de contexto-cabeza y el límite de 48 tokens por opción de Laya no produjeron truncamiento de entrada. Seis LLMs se ejecutaron a través de OpenRouter con proveedores fijos y ajustes de razonamiento. El razonamiento solicitado fue bajo para Gemini 3.8 Flash, mínimo para Gemini 3.5 Flash Lite y alto para Opus. Se desactivó para DeepSeek, Qwen y Haiku. Cada modelo tuvo un calentamiento excluido, una solicitud en vuelo y sin reintentos. El orden de envío de los modelos rotaba entre preguntas.

Kev-9B se añadió el 22 de septiembre en una ejecución separada, preservando los ocho resultados originales. Sus 243 cargas de solicitud coincidieron exactamente con las entradas originales de Jev, incluido el orden de opciones. Fijamos la revisión de checkpoint 2629c06a y usamos una A100 SXM de 80 GB con FP32, atención SDPA y LoRA sin fusionar. El preprocesamiento de fechas y la caché de prefijo estaban desactivados. Tras comprobar la API en las 17 preguntas de desarrollo reservadas, ejecutamos un calentamiento excluido y 243 solicitudes en serie sin reintentos. El servicio estaba reservado para nuestro uso. Cada respuesta confirmó que la entrada completa se conservó. Los tiempos del servidor incluyen la tokenización y la inferencia sincronizada. El gráfico utiliza los tiempos del cliente, incluidos SSH y la sobrecarga de red.

La precisión divide las elecciones correctas y válidas entre todas las 243 preguntas planificadas, incluidos los fallos de servicio y de salida. La latencia mediana mide la solicitud completa no streaming del cliente entre las respuestas válidas, excluido el calentamiento. Los costes comunicados de LLM API cubren las solicitudes medidas. Los costes de hardware de Laya y de alquiler de Kev no se midieron, y la estimación de precio de lista de Jev es una base contable diferente. La comparación describe este conjunto curado y estas condiciones de despliegue. Los datos públicos de origen, las revisiones de las descripciones, el juicio de los revisores, las diferentes fechas de medición y la ausencia de repeticiones limitan la generalización.

Limitaciones

El subconjunto difícil se concentra en el comercio. Cuatro bases de datos aportan 171 de sus 184 preguntas, o el 92,9 %. Cinco de las 11 bases de datos no aportan ninguna. Esto respalda conclusiones sobre la elección entre bases de datos similares dentro de un dominio, con evidencia limitada para otras combinaciones de dominios.

Siete ejecuciones contienen menos de 759 registros puntuados tras errores del proveedor. Cinco también tienen menos de 184 registros de preguntas difíciles. Sus denominadores de la tabla muestran las preguntas que se completaron. Los registros faltantes se excluyen, lo que puede favorecer a un modelo si las preguntas omitidas eran más difíciles.

Los intervalos de Wilson cubren la incertidumbre de muestreo bajo un modelo a nivel de pregunta. Omiten la variación entre ejecuciones repetidas, la dependencia entre preguntas de la misma base de datos y la incertidumbre introducida por el arnés. Los cambios de proveedor y la recuperación de llamadas a herramientas también limitan las comparaciones entre ejecuciones.

Los datos públicos de benchmark pueden haber aparecido en el entrenamiento de los modelos. Los controles que usaron 138 paráfrasis validadas y 65 preguntas de nueva creación no encontraron una disminución de precisión en los modelos probados de menor coste. Su cobertura se limitó a seis y tres bases de datos, respectivamente. No resuelven la contaminación para todo el panel y ningún control usó bases de datos publicadas después de los cortes de entrenamiento de los modelos.

El truncamiento del esquema puede ocultar tablas útiles. En works_cycles, el límite de 4.000 caracteres deja visibles 26 de 66 tablas en el listado inicial del esquema. El modelo puede solicitar más detalles, pero la vista inicial está incompleta.

Lecturas adicionales

• Texto a SQL: comparación de la precisión de los LLM
• Frameworks de RAG: LangChain frente a LangGraph frente a LlamaIndex
• Mejores herramientas, frameworks y librerías de RAG
• Búsqueda agéntica en 2026: benchmark de 8 APIs de búsqueda para agentes

Cita este benchmark

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Agentic RAG Benchmark: enrutamiento entre 11 bases de datos SQL}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/agentic-rag}},
  note   = {AIMultiple. Recuperado el 25 de septiembre de 2026}
}

Registro de cambios

16 actualizaciones

Todas16General13Metodología3

202620252024

1. 11 de ago

   Se actualizó la sección '¿Qué hace que una pregunta sea difícil en este benchmark?' con nuevo contenido.

2. 11 de ago

   Se actualizó la metodología para aclarar cómo se distribuyen las preguntas más difíciles entre las bases de datos.

3. 7 de ago

   Se reemplazó la sección de metodología de evaluación comparativa de RAG Agentic con una nueva que cubre 36 LLM y 11 bases de datos.

4. 29 de jun

   Se agregaron nuevos modelos al benchmark: Claude Fable 5, Claude Opus 4.8, Gemini 3.5 Flash, Grok 4.3, Claude Opus 4.7.

5. 20 de feb

   Se actualizó la sección de metodología con nuevos detalles sobre el entorno de la base de datos, la arquitectura del agente y el proceso de evaluación.

6. 23 de ene

   Se añadió una sección sobre modelos de contexto largo frente a RAG agéntico.

7. 23 de ene

   Se eliminaron métricas agénticas adicionales de la metodología.

Enlaces de referencia

1.

Models - TypeSafe AI

Mintlify

2.

Apple Silicon Pricing | Scaleway

3.

Euro exchange rates charts

4.

Apple silicon M4 as-a-Service. Cloud Mac | Scaleway

5.

convaiinnovations/laya · Hugging Face

6.

Choice - TypeSafe AI

Mintlify

7.

How to build with TypeSafe - TypeSafe AI

Mintlify

8.

jaredpalmer/kev-9b · Hugging Face

9.

BIRD-bench

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA y científico de datos en AIMultiple. Diseña y ejecuta benchmarks prácticos para sistemas de IA y LLM.

Ver perfil completo

Sé el primero en comentar

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario