Texto-a-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 de texto-a-SQL en 34 modelos de lenguaje grandes (LLMs) para evaluar su rendimiento en la generación de comandos SQL:

Errores comunes en LLM-generados SQL

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

Lógica de unión incorrecta

Los modelos a menudo tuvieron dificultades para identificar e implementar correctamente las operaciones `JOIN` necesarias entre tablas, a veces omitiéndolas por completo o haciendo un uso incorrecto de subconsultas menos óptimas.

El LLM no pudo unir correctamente las tablas `frpm` y `schools` usando el `CDSCode`. También alucinó nombres de columnas (`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 se involucran múltiples tablas.

Errores de agregación y agrupación

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

El LLM identificó correctamente que la frase "promedio más alto" 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 = 'Active'.

Esto destaca un fallo común de LLM: ejecutar correctamente una instrucción principal y obvia (calcular un promedio) mientras se pasa por alto 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 lograron incluir las cláusulas `WHERE` necesarias o seleccionar las columnas incorrectas 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 con la tabla `schools` para recuperarlo.

Estos errores a menudo se deben a un análisis incompleto de la solicitud del usuario o a 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, ocurrieron errores de sintaxis directos, como el uso de alias de tabla incorrectos o la producción de declaraciones SQL incompletas, que impiden la ejecución de la consulta.

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 las convenciones específicas de la base de datos.

Por qué algunos LLMs son mejores en SQL

Varias cosas clave determinan qué tan bien un LLM (LLM) puede convertir una pregunta simple en inglés 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 al 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 de SQL

• Los modelos pueden recibir entrenamiento adicional específicamente enfocado en tareas de texto-a-SQL. Este "ajuste fino" les ayuda a entender las estructuras de bases de datos y las reglas SQL de manera más efectiva que los modelos entrenados solo 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.
• Entendiendo el mapa de la base de datos (Esquema): Algunos LLMs son mejores conectando 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 LLMs generan SQL: Una mirada paso a paso

Para ver 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 es impulsado por una técnica llamada Generación Aumentada por Recuperación (RAG).

Etapa 1: 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 de propietario y una solicitud para generar 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.

Etapa 2: Recuperación del 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 lo recupera en tiempo real.

1. Recuperación: La pregunta del usuario se usa para buscar en una base de datos vectorial que almacena información de esquema. La búsqueda encuentra y recupera los detalles de esquema más relevantes, como las definiciones para 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 RAG asegura que el modelo reciba solo la información de esquema necesaria, haciendo su tarea más enfocada y eficiente.

Etapa 3: Razonamiento y construcción de consulta

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

Monólogo interno del LLM:

1. Objetivo: El usuario quiere un conteo, así que comenzaré con SELECT COUNT(...).
2. Condiciones:
   • "...disposición de propietario..." -> El esquema de la tabla disp tiene una columna type. Necesito una cláusula WHERE para type = 'OWNER'.
   • "...estado de cuenta para ser generado 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.

Etapa 4: Generación del 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 del entrenamiento: La comprensión central del modelo de la sintaxis y funciones SQL.

Este proceso explica por qué ocurren errores. Si el esquema recuperado es ambiguo o un término en la pregunta no se mapea limpiamente, el LLM debe hacer una suposición educada, lo que puede llevar a los errores que analizamos anteriormente.

¿Qué es texto-a-SQL?

Texto-a-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 texto-a-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 empresarial pero pueden no sentirse cómodos escribiendo sintaxis SQL desde cero.

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

• "Muestra 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 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.

Donde texto-a-SQL es útil hoy

Texto-a-SQL funciona razonablemente bien para:

• Generar consultas borrador 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 que usuarios no técnicos accedan a datos simples a través de esquemas predefinidos.
• Ayudar a usuarios de SQL reduciendo la necesidad de escribir consultas repetitivas.

En estos casos, texto-a-SQL funciona como una herramienta de IA asistiva en lugar de un sistema autónomo. La revisión humana sigue siendo parte del flujo de trabajo, especialmente cuando importa la corrección.

¿Cómo funciona texto-a-SQL?

Los sistemas modernos de texto-a-SQL dependen de modelos de lenguaje grandes entrenados en pares de preguntas en lenguaje natural y consultas SQL. Estos modelos aprenden patrones que conectan el lenguaje cotidiano con 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á pidiendo (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 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
• Entender 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 aumenta el número de tablas o cuando los nombres de las columnas no coinciden estrechamente con cómo los usuarios describen los datos en preguntas de lenguaje natural.

Construcción de consulta SQL

Una vez que se identifican la intención y los elementos del 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, usando la condición de unión incorrecta o la agregación.

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 ser incorrecta de maneras sutiles.

Limitaciones y riesgos prácticos

A pesar de las puntuaciones sólidas en las referencias, el uso en el mundo real expone varias limitaciones que no pueden ignorarse.

Fiabilidad y corrección

Incluso los modelos de mejor rendimiento fallan al producir SQL correcto para una parte significativa de consultas complejas. Una tasa de error del 20% o más significa:

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

Esto es particularmente riesgoso en informes, pronósticos o sistemas de apoyo a la decisión, 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 aguas abajo
• La responsabilidad se vuelve poco clara cuando las decisiones dependen de salidas generadas por IA

Texto-a-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 bruscamente. Los modelos luchan 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 referencias como BIRD-SQL destacan que las consultas complejas siguen siendo el punto de falla principal, 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 hay 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 texto-a-SQL introducen riesgos de acceso adicionales:

• Los usuarios pueden consultar tablas sensibles sin entender 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, texto-a-SQL puede debilitar las prácticas de gobernanza existentes.

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 de referencia para texto-a-SQL

Esta referencia comparte su marco de evaluación con nuestra referencia 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 referencias utilizan el mismo subconjunto de 500 preguntas de BIRD-SQL¹ , pipeline agéntico, recuperación de esquema respaldada por ChromaDB y evaluación LLM-como-Juez con Claude 4 Sonnet. La métrica reportada aquí, tasa de generación de comandos SQL correctos, es el porcentaje de preguntas donde el modelo tanto enruteó a la base de datos correcta como generó una consulta SQL semánticamente correcta. Todos los modelos fueron evaluados bajo condiciones zero-shot idénticas con temperatura 0 y sin indicaciones específicas del dominio.

Lectura adicional

Explora otras referencias de RAG, como:

• Modelos de Embedding: OpenAI vs Gemini vs Cohere
• Mejor Base de Datos Vectorial para RAG: Qdrant vs Weaviate vs Pinecone
• RAG Híbrido: Aumentando la precisión de RAG
• Referencia de RAG agéntico: enrutamiento multi-base de datos y generación de consultas
• Top 10 modelos de embedding multilingües para RAG

Registro de cambios

20 de abril de 2026

Agregado 1 nuevo modelo a la referencia:

• Anthropic: Claude Opus 4.7 (anthropic/claude-opus-4.7)

20 de febrero de 2026

Agregados 2 nuevos modelos a la referencia:

• Google: Gemini 3.1 Pro Preview (google/gemini-3.1-pro-preview)
• Anthropic: Claude Sonnet 4.6 (anthropic/claude-sonnet-4.6)

10 de febrero de 2026

Agregados 2 nuevos modelos a la referencia:

• Claude Opus 4.6 (anthropic/claude-opus-4.6)
• Kimi K2.5 (moonshotai/kimi-k2.5)

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