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

He confiado en SQL para el análisis de datos durante 18 años, comenzando en mis días como consultor. Traducir preguntas en lenguaje natural a SQL hace que los datos sean más accesibles, permitiendo a cualquiera, incluso a aquellos sin habilidades técnicas, trabajar directamente con bases de datos.

Utilizamos nuestra metodología de referencia text-to-SQL en más de 35 grandes modelos de lenguaje (LLMs) para evaluar su rendimiento en la generación de comandos SQL:

Errores comunes en LLM-generado SQL

LLMs a menudo cometen cuatro tipos de errores: uniones incorrectas, errores de agregación, filtros faltantes y errores de sintaxis.

Lógica de unión incorrecta

Los modelos a menudo tenían dificultades para identificar e implementar correctamente las operaciones `JOIN` necesarias entre tablas, a veces omitiéndolas por completo o utilizando subconsultas menos óptimas.

El LLM no logró unir correctamente las tablas `frpm` y `schools` usando el `CDSCode`. También alucinó nombres de columna (`Charter`) y valores de filtro (`County = ‘Fresno’`).

Los errores en la lógica de unión rompen fundamentalmente el aspecto relacional de la consulta, lo que lleva a una recuperación de datos incompleta o incorrecta cuando hay varias tablas involucradas.

Errores de agregación y agrupación

Aplicar funciones de agregación (como `MAX`, `AVG`, `COUNT`, `SUM`) o cláusulas `GROUP BY` incorrectamente era otro punto de fallo común, lo que daba lugar a resultados que no coincidían semánticamente con la intención del usuario.

El LLM identificó correctamente que la frase “puntuación media más alta” requiere agrupar los datos por distrito (GROUP BY dname) y usar una función de agregación (AVG(AvgScrRead)). Esta parte de la lógica es correcta.

Sin embargo, el LLM no logró incorporar un filtro crítico de la pregunta: la palabra “activo“. Para cumplir con este requisito, la consulta necesitaba unir la tabla satscores con la tabla schools y luego filtrar los resultados con una cláusula WHERE T1.StatusType = 'Activo'.

Esto destaca un fallo común de los LLM: ejecutar correctamente una instrucción principal y obvia (calcular un promedio) mientras se omite una condición secundaria pero igualmente importante (filtrar por estado). Esto muestra una debilidad en la síntesis de múltiples restricciones en una sola consulta correcta.

Filtros faltantes o incorrectos

Los modelos a veces no incluían las cláusulas `WHERE` necesarias o seleccionaban las columnas equivocadas en la declaración `SELECT`, no abordando completamente las restricciones o la información solicitada explícitamente en el prompt.

El LLM identificó correctamente la lógica para encontrar la escuela (`ORDER BY NumGE1500 DESC LIMIT 1`), pero no logró seleccionar el número de `Phone` solicitado y omitió la unión necesaria a la tabla `schools` para recuperarlo.

Estos errores a menudo provienen de un análisis incompleto de la solicitud del usuario o de la incapacidad de mapear todas las partes de la solicitud a los componentes finales de la consulta SQL.

Errores de sintaxis

Más allá de los errores semánticos, se produjeron errores de sintaxis directos, como el uso de alias de tabla incorrectos o la producción de declaraciones SQL incompletas, que impiden que la consulta se ejecute.

El LLM usó alias incorrectos (`accounts` en lugar de `account`) e incluyó un literal de cadena incompleto (`’POPLATEK PO OBRATU…’`), resultando en una sintaxis SQL inválida.

Estos problemas de sintaxis destacan los desafíos en la generación de código que se adhiere estrictamente a la gramática SQL y a las convenciones específicas de la base de datos.

Por qué algunos LLMs son mejores en SQL

Varios factores clave determinan qué tan bien un LLM (LLM) puede convertir una pregunta en inglés simple en una consulta de base de datos SQL correcta.

1. Tamaño del modelo y datos de entrenamiento

• Tamaño y diseño: Los modelos más grandes o aquellos construidos con estructuras específicas pueden manejar tareas complejas, como la generación de SQL, de manera más efectiva.
• Lo que aprendió: Los datos utilizados para entrenar el LLM son esenciales. Si ve muchos ejemplos de preguntas vinculadas a respuestas SQL, especialmente aquellas que involucran operaciones complejas como uniones o cálculos (SUM, AVG), es probable que tenga un mejor rendimiento.

2. Ajuste fino para tareas SQL

• Los modelos pueden recibir entrenamiento adicional específicamente enfocado en tareas de texto a SQL. Este “ajuste fino” les ayuda a comprender las estructuras de bases de datos y las reglas SQL de manera más efectiva que los modelos entrenados en texto general. El entrenamiento en instrucciones específicas también ayuda.

3. Capacidades de razonamiento y mapeo de esquemas

• Razonamiento: ¿Qué tan bien puede el LLM averiguar los pasos exactos necesarios a partir de una pregunta a veces vaga? Crear SQL a menudo requiere pasos lógicos.
• Comprensión del mapa de la base de datos (Esquema): Algunos LLMs son mejores para conectar conceptos en la pregunta (como “clientes” o “ventas totales”) con los nombres reales de tablas y columnas en la base de datos, incluso si los nombres no son inmediatamente obvios.

Cómo los LLMs generan SQL: Un vistazo paso a paso

Para ver los factores como “razonamiento” y “mapeo de esquemas” en acción, recorramos el proceso paso a paso que sigue un modelo para generar una consulta. Todo este flujo de trabajo está impulsado por una técnica llamada Generación Aumentada por Recuperación (RAG).

Análisis inicial y selección de base de datos

Cuando se presenta una pregunta, el LLM primero analiza la intención del usuario para seleccionar la herramienta de base de datos más relevante.

• Pregunta: “¿Cuántas cuentas tienen una disposición del propietario y una solicitud para que se genere un estado de cuenta al realizar una transacción?”
• Acción del LLM: El modelo identifica palabras clave como “cuentas”, “disposición” y “transacción”. Concluye que la herramienta de base de datos financial es la elección correcta sobre otras como california_schools o superhero.

Recuperando el esquema mediante RAG

Una vez que el modelo elige una herramienta, necesita el “mapa” de la base de datos, el esquema. No tiene esta información memorizada. En su lugar, el sistema RAG la recupera en tiempo real.

1. Recuperación: La pregunta del usuario se utiliza para buscar en una base de datos vectorial que almacena información del esquema. La búsqueda encuentra y recupera los detalles del esquema más relevantes, como las definiciones de las tablas accounts y disp.
2. Aumento: Este texto de esquema recuperado se inserta automáticamente en el prompt junto con la pregunta original.
3. Generación: El LLM ahora tiene todo el contexto que necesita para proceder.

Este proceso de RAG asegura que el modelo reciba la información del esquema necesaria, haciendo que su tarea sea más enfocada y eficiente.

Razonamiento y construcción de consultas

Con la pregunta y el esquema proporcionado por RAG, el modelo mapea los conceptos de la solicitud del usuario a los nombres específicos de tablas y columnas que acaba de recibir.

LLM’s monólogo interno:

1. Objetivo: El usuario quiere un recuento, así que empezaré con SELECT COUNT(...).
2. Condiciones:
   • “…disposición del propietario…” -> El esquema de la tabla disp tiene una columna type. Necesito una cláusula WHERE para type = 'OWNER'.
   • “…que se genere un estado de cuenta al realizar una transacción…” -> El esquema de la tabla accounts tiene una columna frequency. El filtro debe ser frequency = 'POPLATEK PO OBRATU'.
3. Uniones: La información está dividida entre las tablas accounts y disp. El esquema muestra que están vinculadas por account_id, así que necesito JOIN unirlas.

Generando el SQL final

Finalmente, el modelo ensambla estas piezas lógicas en una consulta SQL sintácticamente correcta. La calidad de esta salida depende de:

1. Capacidad de razonamiento: La capacidad del modelo para conectar lógicamente la solicitud del usuario con el esquema proporcionado.
2. Conocimiento de SQL a partir del entrenamiento: La comprensión central del modelo de la sintaxis y funciones de SQL.

Este proceso explica por qué ocurren los errores. Si el esquema recuperado es ambiguo o un término en la pregunta no se puede mapear claramente, el LLM debe hacer una conjetura fundamentada, lo que puede conducir a los errores que analizamos anteriormente.

¿Qué es text-to-SQL?

Text-to-SQL es una tecnología de procesamiento de lenguaje natural que convierte el lenguaje cotidiano en una consulta SQL escrita en lenguaje de consulta estructurado. En lugar de escribir manualmente código SQL, un usuario hace una pregunta en lenguaje natural y el sistema genera una declaración SQL que puede ejecutarse en una base de datos.

El propósito principal de text-to-SQL es reducir la brecha entre cómo las personas piensan sobre los datos y cómo las bases de datos requieren que se escriban las consultas. Esto es especialmente relevante para usuarios no técnicos y analistas de datos que entienden el contexto del negocio pero pueden no sentirse cómodos escribiendo sintaxis SQL desde cero.

En un nivel básico, cuando un usuario hace una pregunta como:

• “Mostrar todos los clientes de Nueva York que hicieron compras el mes pasado.”

El sistema traduce esa solicitud en una consulta SQL generada que selecciona las columnas correctas, filtra filas usando restricciones de fecha y ubicación, y une las tablas de la base de datos necesarias. La calidad de la salida depende de si el sistema puede generar consultas precisas que reflejen tanto la intención del usuario como el esquema de la base de datos.

Dónde text-to-SQL es útil hoy

Text-to-SQL funciona razonablemente bien para:

• Generar borradores de consultas que los analistas de datos pueden revisar y ajustar.
• Apoyar el análisis exploratorio de datos donde la velocidad importa más que la precisión.
• Permitir a usuarios no técnicos acceder a datos simples a través de esquemas predefinidos.
• Asistir a los usuarios de SQL reduciendo la necesidad de escribir consultas repetitivas.

En estos casos, text-to-SQL funciona como una herramienta de IA de asistencia en lugar de un sistema autónomo. La revisión humana sigue siendo parte del flujo de trabajo, especialmente cuando la exactitud es importante.

¿Cómo funciona text-to-SQL?

Los sistemas modernos de text-to-SQL se basan en grandes modelos de lenguaje entrenados con pares de preguntas en lenguaje natural y consultas SQL. Estos modelos aprenden patrones que conectan el lenguaje cotidiano con las estructuras SQL, nombres de tablas, columnas y relaciones. El proceso generalmente sigue una secuencia de pasos:

Comprensión del lenguaje natural

El sistema primero analiza la entrada del usuario para determinar la intención, las restricciones y las entidades. Este paso implica:

• Identificar lo que el usuario está preguntando (por ejemplo, totales, filtros, comparaciones)
• Extraer condiciones relevantes como rangos de tiempo, ubicaciones o categorías
• Interpretar frases ambiguas que pueden requerir contexto empresarial

Los errores en esta etapa a menudo conducen a una consulta SQL que parece correcta pero que responde a la pregunta equivocada.

Mapeo de esquemas

A continuación, el sistema mapea los términos de la pregunta al esquema de la base de datos. Esto incluye:

• Emparejar conceptos en la pregunta con nombres de tablas y columnas
• Comprender las relaciones entre tablas
• Respetar los tipos de datos, como fechas, campos numéricos o categorías

El mapeo de esquemas se vuelve más desafiante a medida que crece el número de tablas o cuando los nombres de las columnas no coinciden estrechamente con la forma en que los usuarios describen los datos en las preguntas en lenguaje natural.

Construcción de consultas SQL

Una vez que se identifican los elementos de intención y esquema, el sistema construye la consulta SQL. Esto puede implicar:

• Seleccionar las tablas y columnas correctas
• Agregar uniones a través de todas las tablas necesarias
• Aplicar filtros, agregaciones y lógica de agrupación
• Producir código SQL sintácticamente válido para sistemas como MySQL o PostgreSQL

En esta etapa, el sistema puede producir fácilmente SQL válido pero lógicamente incorrecto, por ejemplo, al usar una condición de unión o agregación incorrecta.

Validación y ejecución

Algunos sistemas incluyen capas de validación que verifican que la consulta SQL generada pueda ejecutarse y devolver resultados. Las herramientas más avanzadas pueden intentar una optimización limitada o hacer preguntas de seguimiento cuando la consulta es ambigua.

Sin embargo, la validación rara vez garantiza una respuesta correcta. Una consulta puede ejecutarse con éxito y aún así ser incorrecta de manera sutil.

Limitaciones y riesgos prácticos

A pesar de las buenas puntuaciones en las evaluaciones comparativas, el uso en el mundo real expone varias limitaciones que no pueden ignorarse.

Fiabilidad y corrección

Incluso los modelos de mejor rendimiento no logran producir SQL correcto para una proporción significativa de consultas complejas. Una tasa de error del 20% o superior significa:

• Una de cada cinco consultas generadas puede devolver resultados engañosos
• Los errores son a menudo semánticos en lugar de sintácticos
• Las uniones, filtros o agregaciones incorrectas pueden pasar desapercibidas

Esto es particularmente riesgoso en sistemas de informes, pronósticos o apoyo a la toma de decisiones, donde los usuarios asumen que la salida es correcta.

Dependencia de la supervisión humana

Dado el rendimiento actual, el SQL generado debe ser revisado por alguien que entienda SQL y la base de datos. Sin esta supervisión:

• Los usuarios pueden confiar en una consulta incorrecta porque se ejecuta con éxito
• Los errores pueden propagarse a paneles, informes o sistemas posteriores
• La responsabilidad se vuelve poco clara cuando las decisiones dependen de resultados generados por IA

Text-to-SQL no elimina la necesidad de experiencia en SQL; cambia dónde se aplica esa experiencia.

Techo de complejidad

A medida que aumenta la complejidad de la consulta, el rendimiento cae drásticamente. Los modelos tienen dificultades con:

• Múltiples uniones a través de muchas tablas
• Lógica anidada y subconsultas
• Cálculos específicos del dominio
• Consultas que requieren un conocimiento profundo del esquema de la base de datos

Las evaluaciones comparativas como BIRD-SQL destacan que las consultas complejas siguen siendo el principal punto de fallo, incluso para modelos avanzados.

Variabilidad del modelo

Las diferencias de rendimiento entre modelos son significativas. Algunos modelos de lenguaje funcionan razonablemente bien, mientras que otros fallan con frecuencia en el mismo conjunto de datos. Esto significa:

• La selección del modelo tiene un impacto directo en la precisión
• El ajuste fino y los datos de entrenamiento importan
• Los modelos de propósito general pueden no funcionar bien sin adaptación al dominio

No existe una solución universal que funcione igualmente bien en todas las bases de datos y casos de uso.

Gobernanza de datos y privacidad

Los sistemas de text-to-SQL introducen riesgos de acceso adicionales:

• Los usuarios pueden consultar tablas sensibles sin comprender las implicaciones
• El SQL generado puede exponer metadatos sobre el esquema de la base de datos
• Los controles de privacidad de datos deben aplicarse fuera del modelo de lenguaje

Sin controles de acceso sólidos, text-to-SQL puede debilitar las prácticas de gobernanza existentes.

Descubre más de nuestros análisis comparativos e insights basados en datos en la Búsqueda de Google.

Añadir como fuente preferida

Metodología de evaluación comparativa para text-to-SQL

Esta evaluación comparativa comparte su marco de evaluación con nuestro evaluación comparativa de RAG agéntico, que describe la construcción del conjunto de datos, la arquitectura del agente, el desafío de ambigüedad semántica y la rúbrica de puntuación completa en detalle.

Ambas evaluaciones comparativas utilizan el mismo subconjunto de 500 preguntas de BIRD-SQL¹ , pipeline agéntico, recuperación de esquemas respaldada por ChromaDB y evaluación LLM-as-Judge con Claude 4 Sonnet. La métrica reportada aquí, tasa de generación de comandos SQL correctos, es el porcentaje de preguntas en las que el modelo se dirigió a la base de datos correcta y generó una consulta SQL semánticamente correcta. Todos los modelos fueron evaluados en condiciones idénticas de zero-shot con temperatura 0 y sin pistas específicas del dominio.

Lectura adicional

Explore otras evaluaciones comparativas de RAG, como:

• Modelos de embedding: OpenAI vs Gemini vs Cohere
• Principales bases de datos vectoriales para RAG: Qdrant vs Weaviate vs Pinecone
• Híbrido RAG: Mejorando la precisión de RAG
• Agéntico RAG benchmark: enrutamiento multi-base de datos y generación de consultas
• Principales 10 modelos de embedding multilingües para 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{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{Text-to-SQL: Comparación de la precisión de LLM}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Recuperado el 17 de Julio de 2026}
}

Enlaces de referencia

1.

[2305.03111] Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs

Cem Dilmegani

Analista principal

Síguenos

Cem ha sido el analista principal de AIMultiple desde 2017. AIMultiple informa a cientos de miles de empresas (según similarWeb), incluyendo el 55% de las empresas Fortune 500 cada mes. El trabajo de Cem ha sido citado por importantes publicaciones globales como Business Insider, Forbes, Washington Post, firmas globales como Deloitte, HPE y ONG como el Foro Económico Mundial y organizaciones supranacionales como la Comisión Europea. Puede consultar más empresas y recursos de renombre que citan a AIMultiple. A lo largo de su carrera, Cem se desempeñó como consultor, comprador y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización. Lideró la estrategia y adquisición de tecnología de una empresa de telecomunicaciones, reportando directamente al CEO. Asimismo, lideró el crecimiento comercial de la empresa de tecnología avanzada Hypatos, que alcanzó ingresos recurrentes anuales de siete cifras y una valoración de nueve cifras partiendo de cero en tan solo dos años. El trabajo de Cem en Hypatos fue reseñado por importantes publicaciones tecnológicas como TechCrunch y Business Insider. Cem participa regularmente como ponente en conferencias internacionales de tecnología. Se graduó en ingeniería informática por la Universidad de Bogazici y posee un MBA de la Columbia Business School.

Ver perfil completo

Investigado por

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA en AIMultiple, donde se centra en la automatización inteligente, las GPU, los agentes de IA y los marcos de trabajo RAG.

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