Benchmark AIM-Text-to-SQL: Precisión 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 precisión de SQL es el porcentaje de consultas puntuadas que devuelven el resultado de referencia. Las rutas incorrectas y las referencias marcadas como defectuosas quedan excluidas. Una consulta de referencia es el SQL proporcionado como la respuesta esperada.
Cada modelo llega a 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 texto a SQL
Opus 5.5 registró 87,8 % de precisión SQL
claude-opus-5.5 coincidió con el resultado de referencia en 444 de 506 preguntas puntuadas. gemini-3.8-flash le siguió con 77,2 % (342 de 443), y luego claude-sonnet-5.5 con 73,8 % (368 de 499). Estos fueron los tres puntajes de precisión de SQL más altos en el panel de 74 modelos.
La puntuación excluye las elecciones incorrectas de base de datos y las referencias marcadas como defectuosas. Opus 5.5 se ejecutó mediante Claude Code. Gemini 3.8 Flash y Sonnet 5.5 usaron OpenRouter. La clasificación refleja tanto las condiciones de ejecución como las diferencias en las preguntas que cada modelo enrutó correctamente.
Tres variantes Pro obtuvieron puntuaciones por debajo de sus modelos base
gpt-6.1-sol-pro registró 63,6 % de precisión SQL, frente al 65,1 % de gpt-6.1-sol. gpt-6-sol-pro obtuvo 53,6 % frente al 53,8 % de gpt-6-sol. gpt-6-luna-pro obtuvo 44,2 % frente al 45,4 % de gpt-6-luna.
Los seis modelos usaron OpenRouter. Estas puntuaciones provienen de una ejecución por modelo y de subconjuntos diferentes de preguntas enrutadas correctamente. Se necesitarían ejecuciones repetidas sobre las mismas preguntas de SQL para evaluar si persisten las pequeñas diferencias.
Coste frente a precisión de SQL
El coste de ejecución cubre las respuestas de enrutamiento y SQL conservadas de la ejecución de benchmark de cada modelo. El objetivo era 759 preguntas. Siete ejecuciones tienen menos respuestas conservadas. Se excluyen los reintentos descartados, los pilotos y las llamadas del jurado. La precisión de SQL utiliza las preguntas enrutadas correctamente de cada modelo tras excluir las referencias marcadas como defectuosas.
gemini-3-flash-preview registró 67,7 % de precisión SQL con un coste de $7,67 por ejecución. gemini-3.8-flash alcanzó 77,2 % con $26.48. Opus 5.5 tiene una puntuación de 87,8 % emparejada con un coste estimado equivalente a API de $188.71.
Los 71 modelos 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, con el uso de caché registrado conservado. Estas estimaciones no miden el gasto real de suscripción.
Los costes incluyen la exploración de bases de datos, y las puntuaciones de SQL cubren subconjuntos de preguntas diferentes. Por lo tanto, esta comparación describe el coste y la precisión del flujo de trabajo de benchmark combinado. No se midieron los costes aislados de generación de SQL. El benchmark agéntico de RAG informa de la selección de bases de datos por separado.
Resultados de precisión de SQL
La revisión previa a la referencia mide la coincidencia exacta de resultados en todas las preguntas enrutadas correctamente. La revisión posterior de respuestas añade crédito por las respuestas aceptadas por el jurado. Ambas columnas de comparación usan el denominador original, mientras que la precisión de SQL excluye las referencias marcadas.
Condiciones que afectan a la precisión de SQL
Las pistas de BIRD aumentaron la precisión de Gemini Flash en 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 precisión de SQL subió del 67,5 % al 76,2 %. La precisión estricta, antes de la revisión de referencia, subió del 55,0 % al 61,6 %.
Este fue un experimento con un solo modelo. No establece una mejora común para el panel de 74 modelos. El panel principal retiene las pistas porque también pueden revelar qué base de datos seleccionar.
Los modelos llegaron a conjuntos diferentes de preguntas de SQL
Las elecciones de base de datos de cada modelo 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 %.
Sus porcentajes de SQL combinan, por tanto, el rendimiento al escribir consultas con la dificultad de los casos que llegaron a la puntuación. Una comparación controlada de SQL proporcionaría a cada modelo la base de datos correcta para las mismas preguntas. Ese experimento no se ha realizado.
La selección de preguntas también importa al comparar benchmarks de IA 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 modelos evaluaron cada consulta de referencia frente a su pregunta y la información de esquema disponible. No vieron ninguna respuesta candidata del modelo. Una mayoría de al menos tres marcó 236 referencias como defectuosas, es decir, el 31,1 % del conjunto.
Después de la auditoría, el responsable del benchmark revisó las marcas. Anotadores humanos independientes no han repetido esa revisión. Estos porcentajes describen el subconjunto auditado. No deben 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 puntuadas de forma estricta, es decir, el 31,1 %. Un jurado aceptó otras 154 respuestas como equivalentes a la referencia. Estas aportaron 22.7 puntos porcentuales.
Otras 117 respuestas recibieron crédito porque el jurado aceptó la consulta del modelo y rechazó la referencia. Esas aportaron 17.2 puntos. En conjunto, 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 texto a SQL
Questions and execution
BIRD-SQL proporciona preguntas en lenguaje natural, referencias SQL y contenidos de bases de datos.1 Usamos una selección congelada de 759 preguntas de 11 bases de datos, que cubren 560 ejemplos de entrenamiento y 199 ejemplos de desarrollo.
Los modelos 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 que contenía la base de datos elegida y la 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 faltantes, mal formadas o con error de ejecución no recibieron crédito estricto en preguntas elegibles y enrutadas correctamente.
Para las 46 ejecuciones de OpenRouter, solicitamos temperatura 0. Veintinueve usaron la capa v3 de recuperación de llamadas de herramientas, 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 usaron Claude Code. Las tres ejecuciones CLI utilizaron un esfuerzo de razonamiento medio. Las ejecuciones de GPT-6 Luna, Luna Pro, Sol y Sol Pro y GPT-5.2 usaron OpenRouter. Estas diferencias de ejecución impiden atribuir una brecha de puntuación únicamente al modelo.
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 incorporaciones de API completaron cada una todas las 759 preguntas tras reintentar solicitudes fallidas, conservando las respuestas correctas anteriores.
Puntuación de SQL
La puntuación principal excluye las preguntas marcadas tanto de su numerador como de su 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 la revisión el resultado:
Antes de la revisión de referencia, 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 independiente acepta una respuesta omitida elegible. Utiliza el mismo denominador que la puntuación estricta. Los archivos de resultados denominan a esta precisión adjudicada.
El tamaño de la muestra (n) es el número de preguntas puntuadas. 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 puntuadas de 679 a 468. Su precisión de SQL fue del 38,5 %.
La exclusión cambia ambos recuentos. La revisión de respuestas, en cambio, conserva el denominador original y añade crédito por las respuestas omitidas aceptadas.
Revisión de referencias y respuestas
Auditar las referencias y revisar las respuestas candidatas requieren 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 modelo que se estaba puntuando.
La adjudicación de respuestas utilizó tres jurados de familias de modelos diferentes a la del candidato. Las consultas de referencia y candidata aparecieron en posiciones A/B aleatorias 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. Los aciertos estrictos siguen aceptados, 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 corrección garantizada ni un límite superior garantizado sobre la precisión real.
Una omisión era apta para la adjudicación cuando la consulta candidata se ejecutaba y la superposición F1 entre sus filas de resultados y la referencia era inferior a 0.5. El 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 resultaron aptas para revisión. El jurado aceptó la candidata en 144 casos: 92 con la referencia rechazada y 52 con ambas respuestas aceptadas. Clasificó 105 como errores del modelo y dejó 65 ambiguos. Las otras 32 omisiones comprendieron 27 con mayor superposición de resultados y cinco errores de ejecución.
Los 144 casos aceptados son el 45,9 % de las omisiones revisadas, no de cada respuesta fallida.
Añadir como fuente preferidaLimitaciones
Los errores de referencia siguen siendo inciertos. La auditoría de cinco modelos inspeccionó columnas de tablas utilizadas por cada consulta de referencia, por lo que puede pasar por alto 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 de los LLM. Ninguna revisión humana independiente verificó todos los veredictos de adjudicación. En el control de nova-lite-v1, la precisión aumentó del 18,9 % bajo la puntuación estricta al 31,6 % después de 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 precisión del jurado.
La comparación estricta puede fallar en ambos sentidos. 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 coma 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 precisión 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, hint-free, con un requisito de enrutamiento de bases de datos. No son directamente comparables con la tabla de clasificación 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 precisión de SQL con 87,8 %, seguido de gemini-3.8-flash con 77,2 % y claude-sonnet-5.5 con 73,8 %.
Cada puntuación de SQL refleja las preguntas que ese modelo enrutó correctamente y las referencias conservadas después de la revisión. Una comparación controlada de SQL daría a cada modelo 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 de múltiples bases de datos
- Más de 800 benchmarks líderes de IA
- 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 = {{Benchmark AIM-Text-to-SQL: Precisión 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 API de búsqueda de vídeos: Bright Data vs YouTube
Detección de bots: 9 proveedores anti-bot comparados
Benchmark de recuperación ante desastres: Acronis vs Comet vs MSP360
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.