Text-to-SQL: Comparación de la precisión de los LLM

Ejecutamos 36 modelos de lenguaje grandes sobre 759 preguntas de BIRD-SQL, cada modelo escribiendo SQL contra una base de datos que tenía que identificar por sí mismo entre 11 candidatas. Cada consulta analizable se ejecutó contra la base de datos real y su conjunto de resultados se comparó con el conjunto de resultados de la consulta de oro de BIRD. Las consultas faltantes, mal formadas o que fallaron en la ejecución se contabilizaron como fallos.

Cada ejecución fue a temperatura 0, sin ejemplos previos, y sin la pista de dominio de BIRD. Diecinueve de las 36 ejecuciones utilizaron la capa de recuperación de llamadas a herramientas descrita en la página de enrutamiento, que analiza llamadas a herramientas que el analizador estándar rechaza. Quince ejecuciones son anteriores a ella y dos se sitúan a caballo del cambio.

Métricas explicadas

Coincidencia de ejecución estricta. Coincidencia de ejecución sobre las preguntas que el modelo enrutó correctamente. Condicionar en la ruta correcta elimina los fallos directos por base de datos incorrecta, pero no aísla completamente la capacidad de SQL, porque cada modelo alcanza un subconjunto diferente de preguntas.

Limpio de oro. La misma medición pero eliminando del denominador las preguntas cuyo SQL de oro consideramos defectuoso. Esas preguntas no se puntúan como aciertos, se eliminan.

Adjudicado. El extremo superior. Un jurado ciego de tres modelos, extraídos de familias distintas a la del modelo bajo prueba, revisa cada respuesta que la comparación estricta rechazó, donde el modelo enrutó correctamente, el SQL se ejecuta y sus filas se solapan con las del oro en menos de la mitad. Decide si la consulta es una formulación diferente pero equivalente, si el oro está mal o si el modelo está mal. Se acreditan las respuestas equivalentes y los oros defectuosos.

Los tres parten del conjunto completo de 759 preguntas en lugar del subconjunto difícil, y ninguno utiliza 759 como denominador. Cada uno se mide sobre las preguntas que el modelo enrutó correctamente, y la columna limpio de oro elimina luego los oros marcados. El azar no se aplica a este eje, porque una consulta devuelve el conjunto de resultados de oro o no lo hace.

Hallazgos del benchmark de Text-to-SQL

Respuestas correctas con la forma equivocada le cuestan a un modelo 22.7 puntos

claude-sonnet-5 registra 0.311 en coincidencia de ejecución estricta, 33º de los 36 modelos y el más bajo de cualquier fila de Anthropic. Bajo adjudicación ciega la misma ejecución puntúa 0.710, 0.007 por debajo de qwen3.6-27b con 0.717.

La ganancia de 39.9 puntos se divide en dos. 154 de sus 679 preguntas puntuadas, 22.7 puntos, son respuestas que el jurado consideró equivalentes al oro pero con distinta forma. Otras 117, 17.2 puntos, son preguntas donde el jurado consideró que el propio oro estaba defectuoso. El estilo de respuesta explica la primera de esas dos, no la suma. El fallo del arnés no explica nada, porque la ejecución no registró consultas faltantes, un fallo y ninguna respuesta no recuperada.

Esas mismas 154 respuestas son el 34 % de los 453 fallos de sonnet-5 que llegaron a adjudicación. Formato equivalente significa que la consulta devuelve la información correcta con una proyección diferente, una columna extra, un orden de columnas distinto, o un recuento donde el oro devolvía las filas. La coincidencia de ejecución estricta puntúa eso como un fallo.

La tendencia se agrupa por familia de modelos y no por nivel de capacidad. Las familias que escriben proyecciones ricas pierden entre un cuarto y un tercio de sus fallos adjudicados de esta manera, con Claude del 25 al 34 %, Kimi del 24 al 34 %, la línea de razonamiento 5.x de OpenAI del 26 al 32 %, DeepSeek 31 %, MiniMax del 26 al 30 % y GLM-5.x 28 %. Los modelos que escriben con la forma del oro pierden mucho menos, con Google del 9 al 17 %, Llama 9 %, Mistral 18 %, Grok 19 % y los propios modelos pequeños de OpenAI del 19 al 20 %. Grok rompió nuestra primera explicación de este patrón. Se sitúa en el nivel de razonamiento y pierde un 19 %.

La medición adjudicada sitúa a sonnet-5 en el 17º, una diferencia de 16 posiciones.

El jurado encuentra que el 46 % de las respuestas rechazadas de un modelo no son errores del modelo

Tomamos 314 de las 346 respuestas que la comparación estricta rechazó para gemini-3.5-flash-lite en las preguntas que enrutó correctamente, aquellas cuyo SQL se ejecutó y cuyas filas se solapaban con las del oro en menos de la mitad, y las enviamos al jurado ciego de tres modelos con orden aleatorio. Esas 346 abarcan todos los niveles de dificultad y no solo los difíciles, por lo que coinciden con la población que cubren las columnas de SQL.

El jurado las dividió en cuatro categorías. Defecto de oro, donde el modelo tiene razón y la consulta de oro de BIRD es incorrecta, obtuvo 29.3 %. Formato equivalente obtuvo 16.6 %, error genuino del modelo 33.4 %, y ambiguo 20.7 %. Sumando las dos primeras, 144 de las 314 fallos adjudicados (46 %) no son errores del modelo. Esa proporción es sobre los 314 que llegaron al jurado, no sobre el total de 346 respuestas rechazadas. Las 32 que no se enviaron o bien fallaron en la ejecución o se solapaban demasiado con el oro para suponer un desacuerdo claro.

El nivel de exigencia del comparador no explica la brecha. Relajar la coincidencia en el orden de las columnas aporta 0.5 puntos, y el 92 % de los fallos se solapan con el resultado de oro en menos de 0.5. La adjudicación, en lugar de un comparador más laxo, sitúa a ese modelo en una horquilla de 0.606 a 0.687, frente a un estricto 0.464.

Los fallos que el jurado calificó como defecto de oro se concentran donde no llega ninguna corrección publicada, con un 33 % de los fallos de la partición de entrenamiento de este modelo frente a un 20 % de sus fallos de la partición de desarrollo. Ya habíamos agotado todas las correcciones deterministas disponibles. Volver a puntuar con la versión de desarrollo corregida por BIRD cambió 0 de 92 fallos de desarrollo, un conjunto de corrección externo cubrió 39 de ellos y cambió 1, y una auditoría de motores MySQL contra SQLite encontró 4 oros divergentes en todo el conjunto, en total aproximadamente un 1 % de los 314.

Nuestra auditoría con cinco modelos marca el 31.1 % de las consultas de oro de BIRD como defectuosas

Auditamos el propio oro. Cinco modelos punteros, uno por familia, calificaron todas las 759 consultas de oro frente a sus preguntas y esquemas. Ningún miembro del jurado vio nunca la salida de ningún modelo. El panel marcó 236 de 759 oros como defectuosos, el 31.1 %, con un coste de $20.55 y sin llamadas fallidas del jurado.

La tasa se divide por partición de BIRD, con 204 de 560 oros de entrenamiento (36 %) frente a 32 de 199 oros de desarrollo (16 %). Un panel independiente de tres modelos ejecutado anteriormente alcanzó el 29.1 %, y 207 de sus 221 marcas de defecto, el 94 %, son defectuosas en este. Sobre el total de 759 preguntas, los dos paneles coinciden en un 92.9 %.

Una estimación publicada cubre la partición de entrenamiento de BIRD, la auditoría de MotherDuck de 151 ejemplos, y sitúa la tasa en 32.5 %. Las auditorías revisadas por pares de BIRD cubren la partición de desarrollo por diseño explícito, por lo que los 151 ejemplos de MotherDuck constituyen la única comprobación externa sobre las 560 preguntas de entrenamiento de nuestro conjunto congelado, el 73.8 % del mismo.¹

Eliminar los oros defectuosos del denominador lleva al mejor escritor en estricto de 0.551 a 0.677, y las ganancias por modelo oscilan entre +4.5 y +13.3 puntos. El nivel superior mantiene su orden y los vecinos de la tabla intermedia se mueven hasta tres posiciones.

Un modelo de 27B ocupa el quinto lugar en precisión estricta de SQL

qwen3.6-27b registra 0.471 en estricto y 0.590 en limpio de oro, quinto en el panel por detrás de gemini-3-flash-preview (0.551 / 0.677), gemini-3.1-pro-preview (0.536 / 0.669), claude-fable-5 (0.531 / 0.655) y claude-opus-5 (0.523 / 0.643). Todas las filas de OpenAI, Kimi y DeepSeek registran una puntuación estricta más baja, y la ejecución costó $15.28.

La columna se mide sobre las rutas correctas de cada modelo, de modo que un enrutador más débil es calificado con una selección más fácil. qwen3.6-27b enruta 0.679, y la sección de limitaciones mide ese efecto con una correlación de 0.96 entre la precisión de enrutamiento y la dificultad del denominador.

El orden cambia cuando se utiliza el extremo superior del rango. Con las puntuaciones adjudicadas, qwen3.6-27b es decimocuarto con 0.717 mientras que claude-opus-5 lidera con 0.824.

La habilidad de enrutamiento y la habilidad de escritura de SQL son ejes separados

kimi-k3 enruta 0.832, por detrás de claude-opus-5 con 0.848 y al mismo nivel que qwen3.8-max, y escribe un 0.482 en limpio de oro de SQL frente al mejor del panel de 0.677. gemini-3-flash-preview lo invierte, enrutando 0.753 con ese mejor limpio de oro del panel en SQL. gpt-5.6-terra enruta con 0.772 y escribe 0.447.

Los dos ejes no se miden sobre el mismo denominador. Cada modelo escribe SQL para las preguntas que enrutó correctamente y no para otras, y los mejores enrutadores obtienen un conjunto más difícil, lo que reduce cualquier asociación medida entre los ejes.

La auditoría del oro y el jurado de adjudicación

Dos jurados realizaron dos trabajos diferentes.

El jurado de validez del oro califica las consultas de oro. Sus cinco miembros (claude-opus-4.8, gpt-5.6-sol, gemini-3.1-pro-preview, grok-4.5, deepseek-v4-pro) ven cada uno una pregunta, el SQL de oro y las listas de columnas de las tablas que toca esa consulta, y responden si el oro responde a la pregunta. Nunca se muestra la salida de ningún modelo. Sus veredictos están congelados en un archivo con hash y alimentan la columna de limpio de oro.

El jurado de adjudicación califica un fallo de un modelo específico. Tres modelos extraídos de familias diferentes a la del modelo bajo prueba ven la pregunta, la consulta y el resultado de oro, y la consulta y el resultado candidatos, con el orden aleatorio, y votan a cuál de las cuatro categorías pertenece el fallo. Se ejecuta por modelo a un coste de aproximadamente $6, y sus veredictos alimentan la columna adjudicada. La adjudicación en todo el panel de 36 modelos costó $208.81.

La columna adjudicada es un punto final optimista ajustado por adjudicación, no una verdad fundamental independiente. Puede equivocarse en ambos sentidos. Una respuesta ambigua que en realidad era correcta no recibe crédito, y un falso positivo del jurado acredita una que no lo era. Tres propiedades medidas acotan hasta dónde se puede forzar.

La revisión es asimétrica. Los fallos reciben una segunda mirada y los aciertos nunca, por lo que un error en el sentido de aprobación no puede detectarse. Los veredictos ambiguos, del 15 al 23 % según el modelo, nunca se acreditan, y los casi aciertos y las consultas que no se ejecutan siguen siendo fallos.

No elimina el suelo de los modelos débiles. Como control negativo adjudicamos nova-lite-v1, la fila más débil del panel. Su puntuación sube de 0.190 a 0.316 y se mantiene 0.150 por debajo de la siguiente fila. El suelo se mantiene en llama con 0.466, mistral con 0.509 y gpt-5.4-nano con 0.512.

La proporción de defectos de oro sigue la fortaleza del modelo con una correlación de rango de 0.906, medida en 33 modelos. Los fallos de gpt-5.6-sol son un 40 % defectos de oro y un 19 % errores genuinos, mientras que los de llama-4-maverick son un 13 % y un 50 %.

Veinticuatro de los 36 modelos se sitúan en o por encima de 0.68 en adjudicado.

Cómo funciona la generación de SQL en este benchmark

El modelo nunca recibe un esquema por adelantado. Elige una de 11 herramientas de base de datos, lee la lista de tablas que recibe, pide las columnas de una tabla cuando las necesita y puede ejecutar consultas exploratorias contra la base de datos que ha seleccionado antes de comprometerse. La salida del esquema está limitada a 4.000 caracteres y los resultados de las consultas a 50 filas.

La consulta final llega mediante una llamada de finalización obligatoria enviada sin herramientas, junto con la base de datos que el modelo declara. La puntuación ejecuta esa consulta y la consulta de oro de BIRD contra el mismo archivo de base de datos y compara los dos conjuntos de resultados, con un centinela NULL y un modo sensible al orden para las preguntas que especifican un orden.

La comparación es el paso estricto, y es donde una respuesta correcta puede puntuar como fallo. Una consulta que devuelve las mismas filas con una columna extra, en un orden de columnas diferente, o como un recuento donde el oro devolvía las filas, falla la comparación. Esa es la brecha que el jurado de adjudicación mide y no la que cerraría un comparador más laxo, que aporta 0.5 puntos.

Metodología del benchmark para text-to-SQL

Este benchmark comparte su infraestructura con el benchmark de RAG agéntico, que describe la selección de bases de datos, la taxonomía de dificultad, la anonimización, el bucle agéntico y el presupuesto de turnos en su totalidad. Ambas páginas informan sobre el mismo subconjunto congelado de 759 preguntas de BIRD-SQL, ejecutado sobre 11 bases de datos entre las que el modelo debe elegir, a temperatura 0 sin la pista de dominio. La página de enrutamiento recoge el eje de enrutamiento, y esta página recoge el eje de SQL.

Puntuación: coincidencia de ejecución. La consulta final del modelo y la consulta de oro de BIRD se ejecutan ambas contra la base de datos real y se comparan sus conjuntos de resultados, con un centinela NULL y un modo sensible al orden para consultas cuya pregunta especifica un orden. Denominador: preguntas que el modelo enrutó correctamente. Forma de presentación: un rango de tres valores, coincidencia de ejecución estricta, luego limpio de oro, luego adjudicado. Auditoría del oro: 5 familias punteras, un modelo cada una, 759 oros calificados, 236 marcados como defectuosos, congelados con hash. Adjudicación: 3 modelos por candidato, de familias disjuntas a la del modelo bajo prueba, ciego y con orden aleatorio. Panel: 36 modelos, una sola ejecución cada uno, $874.53 para las ejecuciones y $208.81 para la adjudicación.

Por qué ningún juez LLM juzga la corrección en el suelo. Medimos la alternativa antes de elegir. En 2.203 registros del benchmark predecesor, un juez LLM nunca falló una consulta que la ejecución aprobó, a ningún umbral. A ese juez se le mostraron ambos conjuntos de resultados, por lo que su veredicto no es independiente del resultado de la ejecución y el cero no establece que un juez no pueda ser más estricto. La ejecución permanece como suelo y el jurado aparece más arriba en el rango, donde su indulgencia es el objetivo.

Por qué se omite la pista. BIRD proporciona una pista de dominio con cada pregunta. Suministrarla vale de 6 a 9 puntos de coincidencia de ejecución, y también mueve la precisión de enrutamiento en 5.7 puntos, lo que la convierte en una filtración en el eje de enrutamiento. Por lo tanto, ambas páginas informan de la condición libre de pista, y los números de SQL aquí están por debajo de lo que los mismos modelos obtendrían en condiciones estándar de BIRD.

Precisión de SQL en todo el panel, de tres formas

Ordenado por la columna adjudicada. Seis filas se quedaron cortas de 759 registros tras dos pases de reintento, y las preguntas faltantes están ausentes de todos los denominadores en lugar de contabilizarse como fallos.

Limitaciones del eje de SQL

El oro es prestado y discutido. Nuestra cifra de 31.1 % de oros defectuosos es nuestro propio subconjunto auditado, no una verdad fundamental con múltiples anotadores. No hay un pase duplicado ciego, no hay cifra de acuerdo entre anotadores, y la verificación humana fue realizada por el propietario del benchmark en lugar de un anotador independiente. Los miembros del jurado vieron las listas de columnas de las tablas que toca la consulta de oro, por lo que un oro que consulte la tabla equivocada es indetectable desde esa vista y esos defectos se pasan por alto. El panel también puede marcar un oro que funciona, un error en la otra dirección. Ningún anotador independiente ha repetido el pase, por lo que el error residual no está medido en ningún sentido y la cifra no es un suelo.

La columna adjudicada es un instrumento de LLM, no una segunda verdad fundamental, y no es un límite superior estricto. Sus tres miembros del jurado son modelos, por lo que la columna hereda lo que un panel de modelos pueda equivocar sobre la equivalencia en SQL, y ningún humano releyó los veredictos.

El comparador se equivoca en ambos sentidos. El orden de columnas y el número de columnas causan falsos negativos, mientras que el plegado de mayúsculas y el redondeo de flotantes a seis cifras significativas causan falsos positivos. El error del comparador y el error de la consulta de oro son fuentes separadas de incertidumbre y pueden mover una puntuación en direcciones diferentes.

La coincidencia de ejecución estricta se mide sobre las propias preguntas correctamente enrutadas de cada modelo, y los mejores enrutadores obtienen un conjunto más difícil. La precisión de enrutamiento sigue la dificultad de las preguntas que llegan al denominador de SQL de un modelo. En los 36 modelos esa correlación es de 0.96 (Pearson, sobre el recuento medio de vecinos entre bases de datos), y de 0.97 frente a la proporción de preguntas más difíciles en ese denominador. En términos concretos, claude-opus-5 escribe SQL para 717 preguntas de las cuales el 21.8 % se encuentran entre las 184 más difíciles, mientras que nova-lite-v1 escribe SQL para 285 preguntas de las cuales el 7.7 % lo son. Un enrutador débil es calificado con una selección más fácil. Trate esta columna como un diagnóstico por modelo en lugar de una clasificación entre modelos, y lea las tres columnas como niveles. Para cerrar la brecha se necesita una ejecución con ruta oráculo, donde cada modelo escribe SQL para las mismas preguntas. Esa ejecución no se ha realizado.

Los intervalos de confianza solo cubren el ruido de muestreo. La tabla anterior imprime estimaciones puntuales, y los intervalos de Wilson para las columnas estricta y limpia de oro figuran en el CSV publicado junto a cada fila. Los intervalos recogen el ruido de muestreo de preguntas y no la incertidumbre de los jurados ni la de los marcadores de oro. Dos ejecuciones del panel repetidas en condiciones idénticas movieron la precisión de enrutamiento entre 1.6 y 2.7 puntos, y esta página no reporta ninguna medición repetida para las columnas de SQL.

Estos números son libres de pista por construcción, por lo que no son comparables con las puntuaciones del leaderboard de BIRD para los mismos modelos.

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

Lecturas adicionales

• Benchmark de RAG agéntico: Enrutamiento multibase de datos en 36 LLM
• Más de 200 benchmarks líderes de IA
• HALC-Bench: Benchmark de alucinación de LLM en recuperación de contexto largo
• +100 conjuntos de datos para modelos de ML e IA
• Mejores herramientas, frameworks y librerías de RAG

Preguntas frecuentes

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  = {{Text-to-SQL: Comparación de la precisión de los LLM}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Recuperado el 7 de Agosto de 2026}
}

Enlaces de referencia

1.

BIRD-bench

Ekrem Sarı

Investigador de IA

Síguenos

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

Ver perfil completo

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.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario

PFJ Rofgowski

Dec 10, 2025 at 20:04

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 .

Responder

Ekrem Sarı

Feb 10, 2026 at 08:46

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.

Responder