AIM-Text-to-SQL Benchmark: exactitud de SQL en más de 70+ LLMs
We evaluated SQL answers from 70+ LLMs on a 759-question BIRD-SQL subset. Each model selected a database from 11 candidates, then produced a query.
La exactitud de SQL es el porcentaje de consultas evaluadas que devuelven el resultado de referencia. Las rutas incorrectas y las referencias marcadas como defectuosas se excluyen. Una consulta de referencia es el SQL proporcionado como respuesta esperada.
Cada model alcanza un conjunto diferente de preguntas de SQL porque la puntuación depende de sus elecciones de base de datos. Las diferencias en estos subconjuntos y en la configuración de ejecución limitan las comparaciones.
Hallazgos de Text-to-SQL
Opus 5.5 registró 87,8 % de SQL exactitud
claude-opus-5.5 coincidió con el resultado de referencia en 444 de 506 preguntas evaluadas. gemini-4-argon le siguió con un 78,6 % (407 de 518), seguido de gemini-3.8-flash con un 77,2 % (342 de 443). Estas fueron las tres puntuaciones de exactitud de SQL más altas en el panel de 76 models. Muse Wonder registró un 56,4 % (285 de 505).
La puntuación excluye las elecciones de base de datos incorrectas y las referencias marcadas como defectuosas. Opus 5.5 utilizó Claude Code. Gemini 4 Argon y Gemini 3.8 Flash utilizaron OpenRouter. La clasificación refleja tanto las condiciones de ejecución como las diferencias en las preguntas que cada model enrutó correctamente.
Tres variantes Pro obtuvieron puntuaciones inferiores a sus models base
gpt-6.1-sol-pro registró un 63,6 % de exactitud de SQL, en comparación con un 65,1 % para gpt-6.1-sol. gpt-6-sol-pro obtuvo un 53,6 % frente a un 53,8 % para gpt-6-sol. gpt-6-luna-pro obtuvo un 44,2 % frente a un 45,4 % para gpt-6-luna.
Los seis models utilizaron OpenRouter. Estas puntuaciones proceden de una ejecución por model y de diferentes subconjuntos de preguntas enrutadas correctamente. Se necesitarían ejecuciones repetidas con las mismas preguntas de SQL para evaluar si persisten las pequeñas diferencias.
Coste vs. exactitud de SQL
El coste de ejecución cubre las respuestas retenidas de enrutamiento y de SQL de la ejecución de benchmark de cada model. El objetivo era 759 preguntas. Siete ejecuciones tienen menos respuestas retenidas. Se excluyen las pruebas de humo separadas, los reintentos descartados y las llamadas del jurado. La exactitud de SQL utiliza las preguntas enrutadas correctamente de cada model tras excluir las referencias marcadas como defectuosas.
gemini-3-flash-preview registró un 67,7 % de exactitud de SQL a un coste de $7,67 por ejecución. gemini-3.8-flash alcanzó un 77,2 % a $26.48. La puntuación de Opus 5.5 del 87,8 % se asocia con un coste estimado equivalente de API de $188.71. Gemini 4 Argon alcanzó un 78,6 % a $41,41 en costes de ejecución retenidos. Muse Wonder alcanzó un 56,4 % a $77,44 en costes de ejecución retenidos.
Los 73 models de API utilizan costes medidos. Opus 5.5, Fable 5.1 y GPT-6 Astra tienen estimaciones etiquetadas por separado basadas en sus tokens de CLI registrados y en los precios de OpenRouter consultados el 1 de octubre de 2026, conservando el uso de caché registrado.
Los costes incluyen la exploración de bases de datos, y las puntuaciones de SQL cubren diferentes subconjuntos de preguntas. Por tanto, esta comparación describe el coste y la exactitud del flujo de trabajo combinado del benchmark. No se midieron los costes aislados de generación de SQL. El benchmark de RAG agéntico informa de la selección de bases de datos por separado.
Resultados de exactitud de SQL
Antes de la revisión de referencias, se mide la coincidencia exacta de resultados en todas las preguntas enrutadas correctamente. Después de la revisión de respuestas, se añade crédito por las respuestas aceptadas por el jurado. Ambas columnas de comparación utilizan el denominador original, mientras que la exactitud de SQL excluye las referencias marcadas.
Condiciones que afectan a la exactitud de SQL
Las pistas de BIRD aumentaron en Gemini Flash la exactitud de SQL en 8.7 puntos
Repetimos gemini-3-flash-preview con la evidencia complementaria de BIRD. En las preguntas enrutadas correctamente en ambas condiciones, la exactitud de SQL aumentó del 67,5 % al 76,2 %. La exactitud estricta, antes de la revisión de referencias, aumentó del 55,0 % al 61,6 %.
Este fue un experimento con un solo model. No establece una mejora común para el panel de 74 models. El panel principal omite las pistas porque también pueden revelar qué base de datos seleccionar.
Los models alcanzaron conjuntos diferentes de preguntas de SQL
Las elecciones de base de datos de cada model determinan qué preguntas llegan a la puntuación de SQL. Para claude-opus-5, el denominador estricto contiene 717 preguntas, incluidas 156 del grupo de enrutamiento más difícil. Para nova-lite-v1, contiene 285 preguntas, incluidas 22 de ese grupo. Las proporciones son 21,8 % y 7,7 %.
Por tanto, sus porcentajes de SQL combinan el rendimiento al escribir consultas con la dificultad de los casos que llegaron a la puntuación. Una comparación controlada de SQL suministraría a cada model la base de datos correcta para las mismas preguntas. Ese experimento no se ha ejecutado.
La selección de preguntas también importa al comparar IA benchmarks que proporcionan esquemas, pistas o presupuestos de herramientas diferentes.
Hallazgos de la revisión de referencias y respuestas
La auditoría de referencias marcó 236 de 759 consultas
Cinco models evaluaron cada consulta de referencia en relación con su pregunta y la información de esquema disponible. No vieron ninguna respuesta de model candidata. Una mayoría de al menos tres marcó 236 referencias como defectuosas, es decir, el 31,1 % del conjunto.
Tras la auditoría, el propietario del benchmark revisó las marcas. Anotadores humanos independientes no han repetido esa revisión. Estos porcentajes describen el subconjunto auditado. No deberían generalizarse a todo BIRD.
Las respuestas equivalentes añadieron 22.7 puntos a la puntuación de claude-sonnet-5
claude-sonnet-5 superó 211 de 679 preguntas evaluadas de forma estricta, es decir, el 31,1 %. Un jurado aceptó otras 154 respuestas como equivalentes a la referencia. Estas contribuyeron con 22.7 puntos porcentuales.
Otras 117 respuestas recibieron crédito porque el jurado aceptó la consulta del model y rechazó la referencia. Esas contribuyeron con 17.2 puntos. Together, las dos categorías elevaron la puntuación al 71,0 %, un aumento de 39.9 puntos.
Las respuestas equivalentes pueden devolver la información solicitada con una columna adicional o una proyección diferente. La comparación estricta puede rechazar ese resultado incluso cuando un revisor lo acepta como respuesta a la pregunta. Del aumento, 22.7 puntos proceden de las decisiones del jurado sobre estos casos. Los defectos de referencia representan los 17.2 puntos restantes.
Metodología del benchmark de Text-to-SQL
Questions and execution
BIRD-SQL proporciona preguntas en lenguaje natural, referencias de SQL y contenido de bases de datos.1 Utilizamos una selección congelada de 759 preguntas de 11 bases de datos, que cubren 560 ejemplos de train y 199 de dev.
Los models recibieron descripciones breves de bases de datos y herramientas para listar tablas, leer definiciones de columnas y ejecutar SQL. Cada pregunta permitía hasta nueve llamadas con herramientas y una respuesta final con la base de datos elegida y el SQL. El límite de vista previa del esquema era de 4.000 caracteres, y las vistas previas de consultas estaban limitadas a 50 filas.
La consulta candidata final y la referencia se ejecutaron contra el mismo archivo de base de datos. La puntuación estricta comparó sus resultados, incluido un modo sensible al orden para las preguntas que solicitan una respuesta ordenada. Las consultas candidatas ausentes, malformadas o con fallos de ejecución no recibieron crédito estricto en preguntas por lo demás elegibles y enrutadas correctamente.
Para las 46 ejecuciones de OpenRouter, solicitamos temperatura 0. Veintinueve utilizaron la capa de recuperación de llamadas a herramientas v3, 15 la precedieron y dos combinaron registros de ambas versiones. GPT-6 Astra se ejecutó mediante Codex CLI. Opus 5.5 y Fable 5.1 utilizaron Claude Code. Las tres ejecuciones de CLI utilizaron un esfuerzo de razonamiento medio. Las ejecuciones de GPT-6 Luna, Luna Pro, Sol y Sol Pro y de GPT-5.2 utilizaron OpenRouter. Estas diferencias de ejecución impiden atribuir una brecha de puntuación únicamente al model.
Siete ejecuciones completaron menos de 759 preguntas. Los registros faltantes están ausentes de los denominadores de puntuación. La tabla informa de los tamaños de muestra reales para las puntuaciones principal y complementarias. Las diez adiciones de API completaron cada una las 759 preguntas tras reintentos de solicitudes fallidas, conservando respuestas correctas anteriores.
Puntuación de SQL
La puntuación principal excluye las preguntas marcadas tanto del numerador como del denominador. Tres referencias marcadas como inciertas permanecen en el cálculo. Los archivos de resultados denominan a esta métrica ex_gold_clean.
Dos puntuaciones complementarias muestran cómo cambia el resultado la revisión:
Antes de la revisión de referencias, la puntuación estricta mide la coincidencia exacta de ejecución en todas las preguntas enrutadas correctamente. Incluye preguntas con referencias marcadas.
Después de la revisión de respuestas, la puntuación añade crédito cuando un jurado separado acepta una respuesta omitida elegible. Utiliza el mismo denominador que la puntuación estricta. Los archivos de resultados denominan a esta exactitud adjudicada.
El tamaño de la muestra (n) es el número de preguntas evaluadas. La puntuación principal utiliza un subconjunto más pequeño que las dos puntuaciones complementarias.
Para claude-sonnet-5, excluir las referencias marcadas redujo las respuestas aceptadas de 211 a 180 y las preguntas evaluadas de 679 a 468. Su exactitud de SQL fue del 38,5 %.
La exclusión cambia ambos recuentos. La revisión de respuestas, por el contrario, conserva el denominador original y añade crédito por las omisiones aceptadas.
Revisión de referencias y respuestas
Auditar referencias y revisar respuestas candidatas requiere entradas diferentes.
Los auditores de referencias fueron claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5 y deepseek-v4-pro. Las respuestas candidatas se ocultaron para mantener las marcas independientes del model que se estaba puntuando.
La adjudicación de respuestas utilizó tres jurados de familias de models diferentes a la del candidato. Las consultas de referencia y candidata aparecieron en posiciones A/B aleatorizadas sin etiquetas que revelaran sus funciones. Los casos ambiguos y los casos con votos válidos insuficientes no recibieron crédito adicional.
La cobertura de la revisión es asimétrica. Las aprobaciones estrictas permanecen aceptadas, mientras que las omisiones elegibles reciben otra evaluación. En consecuencia, la adjudicación puede conservar falsos positivos de la puntuación estricta y añadir falsos positivos propios. Es una estimación complementaria, sin exactitud garantizada ni un límite superior garantizado de la exactitud real.
Una omisión se calificaba para adjudicación cuando la consulta candidata se ejecutaba y el solapamiento F1 entre sus filas de resultados y la referencia era inferior a 0.5. F1 combina la proporción de filas candidatas encontradas en la referencia con la proporción de filas de referencia recuperadas por la candidata.
Por ejemplo, gemini-3.5-flash-lite tuvo 346 omisiones estrictas. De estas, 314 se calificaron para revisión. El jurado aceptó la candidata en 144 casos: 92 con una referencia rechazada y 52 con ambas respuestas aceptadas. Clasificó 105 como errores del model y dejó 65 ambiguos. Las otras 32 omisiones comprendieron 27 con mayor solapamiento de resultados y cinco fallos de ejecución.
Los 144 casos aceptados son el 45,9 % de las omisiones revisadas, no de todas las respuestas fallidas.
Añadir como fuente preferidaLimitaciones
Los errores de referencia siguen siendo inciertos. La auditoría de cinco models inspeccionó columnas de tablas utilizadas por cada consulta de referencia, por lo que puede omitir una respuesta ubicada en una tabla diferente. La auditoría también puede rechazar una referencia válida. Se necesita una revisión repetida por anotadores humanos independientes para estimar ambos tipos de error.
Los juicios del jurado dependen de la interpretación del LLM. Ninguna revisión humana independiente verificó todos los veredictos de adjudicación. En el control de nova-lite-v1, la exactitud aumentó del 18,9 % bajo puntuación estricta al 31,6 % tras la adjudicación, lo que muestra que la revisión no produjo automáticamente una puntuación alta. Ese control por sí solo no puede establecer la exactitud del jurado.
La comparación estricta puede fallar en ambas direcciones. Las columnas adicionales o un orden de columnas diferente pueden rechazar una respuesta útil. La normalización de mayúsculas y el redondeo de valores de punto flotante a seis cifras significativas pueden aceptar diferencias que importan.
Los intervalos de muestreo de preguntas están disponibles para las puntuaciones estrictas y la exactitud de SQL en la exportación de resultados. Omiten la incertidumbre de las etiquetas de referencia, el error del jurado y la variación entre ejecuciones repetidas de SQL. Aquí no se informa de ningún análisis repetido de SQL.
Estos son resultados para una carga de trabajo seleccionada, sin gratis pistas, con un requisito de enrutamiento de bases de datos. No son directamente comparables con la tabla de clasificación de BIRD. Los datos públicos de train también dejan un riesgo de solapamiento de datos de entrenamiento, como se analiza en el artículo de enrutamiento.
Conclusión
claude-opus-5.5 lideró la exactitud de SQL con un 87,8 %, seguido de gemini-4-argon con un 78,6 % y de gemini-3.8-flash con un 77,2 %.
Cada puntuación de SQL refleja las preguntas que ese model enrutó correctamente y las referencias retenidas tras la revisión. Una comparación controlada de SQL daría a cada model las mismas preguntas y la misma información de base de datos, con comprobaciones independientes de las etiquetas de referencia y de las decisiones del jurado.
Lecturas adicionales
- Benchmark agéntico de RAG: enrutamiento multibase de datos
- 800+ IA benchmarks líderes
- HALC-Bench: alucinación de LLM en el benchmark de recuperación de contexto largo
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 = {{AIM-Text-to-SQL Benchmark: exactitud de SQL en más de 70+ LLMs}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/text-to-sql}},
note = {AIMultiple. Recuperado el 1 de octubre de 2026}
}Resultados y marcas de tiempo de 1.4 mil puntos de datos. Descargue los datos resumidos que se muestran en los gráficos y las tablas de este artículo como un archivo ZIP que contiene 4 archivos CSV y un README.
¿Quieres los datos granulares que hay detrás? Únete a Premium
Registro de cambios
9 actualizacionesSustituidos los resultados del benchmark de texto a SQL por un panel de 36 modelos puntuado con coincidencia de ejecución strict, gold-clean y adjudicated.
Se añadió un registro de cambios a la sección de benchmark de RAG agéntico: enrutamiento multidatabase y generación de consultas.
Se reemplazó la sección de metodología con un resumen y una referencia a otro artículo.
Enlaces de referencia
Siguiente para leer
Benchmark de voz a texto: Deepgram vs. Whisper
Generación de texto con IA: Los 17 principales casos de uso y 5 estudios de caso
Benchmark de OCR: Precisión en la Extracción / Captura de Texto
Comentarios 1
Comparte tus ideas
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.
Curious, how much of the context engineering and specific prompting did you apply in your benchmarks. Or, was it to review the models only? I have found much higher return of correct and consistent responses. A higher fidelity. To do that, I needed to provide a most sophisticated prompt that fed the context window as the question was being asked. Not perfect, but better than those scores represented in this article when using the Grok 4.x .
Great point. This benchmark intentionally uses zero-shot, minimal prompting with temperature=0. No few-shot examples, no domain-specific instructions, no iterative refinement. The goal was to measure each model's baseline text-to-SQL capability. So your experience with Grok 4 getting higher fidelity through sophisticated context engineering is completely expected. A well-crafted prompt with detailed schema descriptions, few-shot examples, and domain-specific rules will improve any model's performance significantly. What this benchmark isolates is how well the model performs out-of-the-box when given only the raw question and retrieved schema, which helps compare the models' inherent SQL reasoning abilities on a level playing field. We'll make this clearer in the methodology section. Thanks for raising it.