Conversión de texto a SQL: Comparación de la precisión de LLM
Llevo 18 años utilizando SQL para el análisis de datos, desde mis inicios como consultor. Traducir preguntas en lenguaje natural a SQL hace que los datos sean más accesibles, permitiendo que cualquier persona, incluso sin conocimientos técnicos, trabaje directamente con bases de datos.
Utilizamos nuestra metodología de evaluación comparativa de texto a SQL en 34 modelos de lenguaje grandes (LLM, por sus siglas en inglés) para evaluar su rendimiento en la generación de comandos SQL:
Errores comunes en el SQL generado por LLM
Los modelos LLM suelen cometer 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 tenían dificultades para identificar e implementar correctamente las operaciones `JOIN` necesarias entre tablas, a veces omitándolas por completo o utilizando subconsultas menos óptimas.
El LLM no logró unir correctamente las tablas `frpm` y `schools` utilizando el `CDSCode`. Además, generó nombres de columna (`Charter`) y valores de filtro (`County = 'Fresno'`) erróneos .
Los errores en la lógica de unión alteran fundamentalmente el aspecto relacional de la consulta, lo que conlleva una recuperación de datos incompleta o incorrecta cuando intervienen varias tablas.
Errores de agregación y agrupación
Aplicar incorrectamente funciones de agregación (como `MAX`, `AVG`, `COUNT`, `SUM`) o cláusulas `GROUP BY` fue otro punto de fallo común, lo que dio lugar a resultados que no coincidían semánticamente con la intención del usuario.
El modelo LLM identificó correctamente que la frase " puntuación media más alta " requiere agrupar los datos por distrito (GROUP BY dname) y utilizar una función de agregación (AVG(AvgScrRead)). Esta parte de la lógica es correcta.
Sin embargo, el modelo LLM no incorporó un filtro crítico de la pregunta: la palabra " activo ". Para cumplir con este requisito, la consulta debía unir la tabla de puntuaciones SAT con la tabla de escuelas y luego filtrar los resultados con una cláusula WHERE T1.StatusType = 'Active'.
Esto pone de manifiesto un fallo común en LLM: ejecutar correctamente una instrucción primaria y obvia (calcular un promedio) sin cumplir una condición secundaria, igualmente importante (filtrar por estado). Esto evidencia una debilidad a la hora de sintetizar múltiples restricciones en una única consulta correcta.
Filtros faltantes o incorrectos
En ocasiones, los modelos no incluían las cláusulas `WHERE` necesarias o seleccionaban las columnas incorrectas en la instrucción `SELECT`, sin abordar completamente las restricciones o la información solicitada explícitamente en la solicitud.
El LLM identificó correctamente la lógica para encontrar la escuela (`ORDER BY NumGE1500 DESC LIMIT 1`), pero no seleccionó el número de teléfono solicitado y omitió la unión necesaria con la tabla `schools` para recuperarlo.
Estos errores suelen deberse a un análisis incompleto de la solicitud del usuario o a que no se asignan todas las partes de la solicitud a los componentes finales de la consulta SQL.
Errores de sintaxis
Además de los errores semánticos, se produjeron errores de sintaxis flagrantes, como el uso de alias de tabla incorrectos o la generación de sentencias SQL incompletas, lo que impide la ejecución de la consulta.
El LLM utilizó alias incorrectos (`accounts` en lugar de `account`) e incluyó una cadena literal incompleta (`'POPLATEK PO OBRATU…'`), lo que resultó en una sintaxis SQL no válida.
Estos problemas de sintaxis ponen de manifiesto las dificultades para generar código que se ajuste estrictamente a la gramática SQL y a las convenciones específicas de la base de datos.
Por qué algunos LLM son mejores en SQL
Varios factores clave determinan la eficacia con la que un Modelo de Lenguaje Grande (LLM, por sus siglas en inglés) puede convertir una pregunta en inglés sencillo en una consulta correcta para una base de datos SQL.
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 eficaz.
- Lo que aprendió: Los datos utilizados para entrenar el modelo LLM son esenciales. Si encuentra muchos ejemplos de preguntas vinculadas a respuestas SQL, especialmente aquellas que involucran operaciones complejas como uniones o cálculos (SUMA, PROMEDIO), 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 conversión de texto a SQL. Este ajuste fino les ayuda a comprender las estructuras de las bases de datos y las reglas SQL con mayor eficacia que los modelos entrenados únicamente con texto general. El entrenamiento con instrucciones específicas también resulta útil.
3. Habilidades de razonamiento y de mapeo de esquemas
- Razonamiento: ¿Qué tan bien puede el LLM determinar los pasos exactos necesarios a partir de una pregunta a veces vaga? Crear SQL a menudo requiere pasos lógicos .
- Comprender el mapa de la base de datos (esquema): algunos LLM son mejores para conectar los conceptos de la pregunta (como "clientes" o "ventas totales") con los nombres reales de las tablas y columnas en la base de datos, incluso si los nombres no son inmediatamente obvios.
Cómo los LLM generan SQL: Un análisis paso a paso
Para observar factores como el razonamiento y el mapeo de esquemas en acción, analicemos paso a paso el proceso que sigue un modelo para generar una consulta. Todo este flujo de trabajo se basa en una técnica denominada Generación Aumentada por Recuperación (RAG).
Etapa 1: Análisis inicial y selección de la base de datos.
Cuando se le presenta una pregunta, el LLM analiza primero 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 después de una transacción?"
- Acción de LLM: El modelo identifica palabras clave como “cuentas”, “disposición” y “transacción”. Concluye que la herramienta de base de datos
financiales la opción correcta sobre otras comocalifornia_schoolsosuperhero.
Etapa 2: Recuperación del esquema mediante RAG
Una vez que el modelo selecciona una herramienta, necesita que la base de datos "mapee" el esquema. Esta información no está memorizada; en cambio, el sistema RAG la recupera en tiempo real.
- Recuperación: La pregunta del usuario se utiliza 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 de las tablas
accountsydisp. - Ampliación: Este texto del esquema recuperado se inserta automáticamente en la pregunta junto con la pregunta original.
- Generación: El programa LLM ahora cuenta con todo el contexto necesario para continuar.
Este proceso RAG garantiza que el modelo reciba únicamente la información de esquema necesaria, lo que hace que su tarea sea más específica y eficiente.
Etapa 3: Razonamiento y construcción de consultas
Con la pregunta y el esquema proporcionado por RAG, el modelo asigna los conceptos de la solicitud del usuario a los nombres específicos de tablas y columnas que acaba de recibir.
El monólogo interno de LLM:
- Objetivo: El usuario quiere un recuento, así que empezaré con
SELECT COUNT(...). - Condiciones:
- “…disposición del propietario…” -> El esquema de la tabla
disptiene una columnatype. Necesito una cláusulaWHEREparatype = 'OWNER'. - “…declaración que se generará tras una transacción…” -> El esquema de la tabla
accountstiene una columnafrequency. El filtro debería serfrequency = 'POPLATEK PO OBRATU'.
- “…disposición del propietario…” -> El esquema de la tabla
- Uniones: La información está dividida entre las tablas
accountsydisp. El esquema muestra que están vinculadas poraccount_id, así que necesitoJOINunirlas.
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 este resultado depende de:
- Capacidad de razonamiento: La capacidad del modelo para conectar lógicamente la solicitud del usuario con el esquema proporcionado.
- Conocimientos de SQL adquiridos mediante formación: La comprensión básica que tiene el modelo de la sintaxis y las funciones de SQL.
Este proceso explica por qué se producen errores. Si el esquema recuperado es ambiguo o un término de la pregunta no se corresponde claramente, el LLM debe hacer una suposición fundamentada, lo que puede dar lugar a los errores que analizamos anteriormente.
¿Qué es la conversión de texto a SQL?
La conversión de texto a SQL es una tecnología de procesamiento del lenguaje natural que transforma el lenguaje cotidiano en una consulta SQL escrita en lenguaje de consulta estructurado. En lugar de escribir código SQL manualmente, el usuario formula una pregunta en lenguaje natural y el sistema genera una sentencia SQL que puede ejecutarse en una base de datos.
El objetivo principal de la conversión de texto a SQL es reducir la brecha entre la forma en que las personas conciben los datos y la forma en que las bases de datos requieren que se escriban las consultas. Esto es especialmente relevante para usuarios no técnicos y analistas de datos que comprenden el contexto empresarial, pero que quizás no se sientan cómodos escribiendo sintaxis SQL desde cero.
En un nivel básico, cuando un usuario hace una pregunta como por ejemplo:
- “Mostrar todos los clientes de Nueva York que realizaron compras el mes pasado.”
El sistema traduce esa solicitud en una consulta SQL generada que selecciona las columnas correctas, filtra las filas mediante restricciones de fecha y ubicación, y combina las tablas de la base de datos necesarias. La calidad del resultado 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 resulta útil hoy en día la conversión de texto a SQL.
La conversión de texto a SQL funciona razonablemente bien para:
- Genera borradores de consultas que los analistas de datos puedan revisar y ajustar.
- Respalda el análisis exploratorio de datos donde la velocidad importa más que la precisión.
- Permitir que los usuarios no técnicos accedan a datos sencillos mediante esquemas predefinidos.
- Ayudar a los usuarios de SQL reduciendo la necesidad de escribir consultas repetitivas.
En estos casos, la conversión de texto a SQL funciona como una herramienta de IA de apoyo, más que como un sistema autónomo. La revisión humana sigue formando parte del flujo de trabajo, especialmente cuando la precisión es fundamental.
¿Cómo funciona la conversión de texto a SQL?
Los sistemas modernos de conversión de texto a 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, los nombres de las tablas, las columnas y las 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 qué es lo que el usuario solicita (por ejemplo, totales, filtros, comparaciones).
- Extracción de condiciones relevantes como rangos de tiempo, ubicaciones o categorías.
- Interpretación de frases ambiguas que pueden requerir contexto empresarial.
Los errores en esta etapa suelen dar lugar a una consulta SQL que, aunque parezca correcta, responde a la pregunta equivocada.
Mapeo de esquemas
A continuación, el sistema asigna los términos de la pregunta al esquema de la base de datos. Esto incluye:
- Relacionar los conceptos de la pregunta con los nombres de las tablas y las columnas.
- Comprender las relaciones entre tablas
- Respetando los tipos de datos, como fechas, campos numéricos o categorías.
La elaboración de esquemas se vuelve más compleja a medida que aumenta el número de tablas o cuando los nombres de las columnas no coinciden con la forma en que los usuarios describen los datos en preguntas en lenguaje natural.
Construcción de consultas SQL
Una vez identificados los elementos de intención y esquema, el sistema construye la consulta SQL. Esto puede incluir:
- Seleccionar las tablas y columnas correctas.
- Agregar uniones en todas las tablas necesarias
- Aplicación de filtros, agregaciones y lógica de agrupación.
- Generación de código SQL sintácticamente válido para sistemas como MySQL o PostgreSQL.
En esta etapa, el sistema puede generar fácilmente código SQL válido pero lógicamente incorrecto, por ejemplo, al utilizar una condición de unión o una agregación errónea.
Validación y ejecución
Algunos sistemas incluyen capas de validación que verifican que la consulta SQL generada se pueda ejecutar y devolver resultados. Las herramientas más avanzadas pueden intentar una optimización limitada o realizar preguntas adicionales cuando la consulta es ambigua.
Sin embargo, la validación rara vez garantiza una respuesta correcta. Una consulta puede ejecutarse correctamente y aun así ser incorrecta en aspectos sutiles.
Limitaciones y riesgos prácticos
A pesar de los buenos resultados obtenidos en las pruebas de referencia, su uso en el mundo real pone de manifiesto varias limitaciones que no pueden ignorarse.
Fiabilidad y exactitud
Incluso los modelos de mayor rendimiento no logran generar SQL correcto para una parte significativa de las consultas complejas. Una tasa de error del 20 % o superior significa:
- Una de cada cinco consultas generadas puede arrojar resultados engañosos.
- Los errores suelen ser semánticos más que sintácticos.
- Las uniones, filtros o agregaciones incorrectas pueden pasar desapercibidas.
Esto resulta especialmente arriesgado en los sistemas de elaboración de informes, previsión o apoyo a la toma de decisiones, donde los usuarios dan por sentado que el resultado es correcto.
Dependencia de la supervisión humana
Dado el rendimiento actual, el código 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 correctamente.
- Los errores pueden propagarse a los paneles de control, los informes o los sistemas posteriores.
- La rendición de cuentas se vuelve confusa cuando las decisiones dependen de resultados generados por IA.
La conversión de texto a SQL no elimina la necesidad de tener conocimientos de SQL; simplemente cambia el lugar donde se aplican esos conocimientos.
Límite de complejidad
A medida que aumenta la complejidad de las consultas, el rendimiento disminuye drásticamente. Los modelos tienen dificultades con:
- Múltiples uniones entre varias 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.
Pruebas de rendimiento como BIRD-SQL ponen de manifiesto que las consultas complejas siguen siendo el principal punto de fallo, incluso para los modelos avanzados.
Variabilidad del modelo
Las diferencias de rendimiento entre los modelos son significativas. Algunos modelos de lenguaje funcionan razonablemente bien, mientras que otros fallan con frecuencia en el mismo conjunto de datos. Esto significa que:
- La selección del modelo tiene un impacto directo en la precisión.
- El ajuste fino y los datos de entrenamiento son importantes.
- Los modelos de propósito general pueden no funcionar bien sin la adaptación al dominio.
No existe una solución universal que funcione igual de bien en todas las bases de datos y casos de uso.
Gobernanza de datos y privacidad
Los sistemas de conversión de texto a 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, la conversión de texto a SQL puede debilitar las prácticas de gobernanza existentes.
Metodología de referencia para la conversión de texto a SQL
Este benchmark comparte su marco de evaluación con nuestro benchmark RAG basado en agentes , que describe en detalle la construcción del conjunto de datos, la arquitectura del agente, el desafío de la ambigüedad semántica y la rúbrica de puntuación completa.
Ambos benchmarks utilizan el mismo BIRD-SQL de 500 preguntas. 1 subconjunto, canalización de agentes, recuperación de esquema respaldada por ChromaDB y evaluación LLM como juez con Claude 4 Sonnet. La métrica aquí reportada, tasa de generación correcta de comandos SQL, 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 se evaluaron bajo condiciones idénticas de cero disparos con temperatura 0 y sin sugerencias específicas del dominio.
Lecturas adicionales
Explore otros puntos de referencia RAG, como:
- Modelos de incrustación: OpenAI vs Gemini vs Cohere
- Base de datos de vectores principal para RAG: Qdrant vs Weaviate vs Pinecone
- RAG híbrido: Mejorando la precisión del RAG
- Prueba de rendimiento Agentic RAG: enrutamiento y generación de consultas en múltiples bases de datos.
- Los 10 mejores modelos de incrustación multilingüe para RAG
Registro de cambios
20 de febrero de 2026
Se han añadido 2 nuevos modelos al conjunto de datos de referencia:
- Google: Vista previa de Gemini 3.1 Pro (google/gemini-3.1-pro-preview)
- Anthropic: Claude Sonnet 4.6 (antrópico/claude-sonnet-4.6)
10 de febrero de 2026
Se han añadido 2 nuevos modelos al conjunto de datos de referencia:
- Claude Opus 4.6 (antrópico/claude-opus-4.6)
- Kimi K2.5 (moonshotai/kimi-k2.5)
Preguntas frecuentes
Según nuestros hallazgos, no debería confiar plenamente en las consultas complejas generadas por los modelos LLM actuales sin validación. Si bien son útiles para la redacción y las solicitudes sencillas, incluso los modelos de alto rendimiento presentan tasas de error significativas (hasta un 20 % en tareas complejas). Revise y verifique siempre el SQL generado, especialmente para aplicaciones críticas.
Sí, muchos sistemas de gestión de lenguajes (LLM) tienen capacidades que van más allá de la simple generación de sentencias SELECT. A menudo pueden ayudar a comprender y sugerir modificaciones al código SQL existente, o incluso generar DDL (Lenguaje de Definición de Datos), como sentencias CREATE TABLE, a partir de descripciones, aunque la precisión en estas tareas también requiere verificación.
Proporcionar un contexto claro es fundamental. Asegúrese de que el LLM tenga acceso al esquema de la base de datos (nombres de tablas, nombres de columnas, relaciones). Indicar claramente el resultado deseado y, si es posible, proporcionar algunos ejemplos de consultas relevantes (mediante la técnica de "pocos ejemplos") para que el LLM aprenda, puede mejorar significativamente su capacidad para seleccionar las tablas correctas y construir consultas precisas.
Si bien los modelos de lógica de negocio (LLM) pueden abstraer algunas diferencias sintácticas menores entre dialectos de bases de datos, no resuelven por completo los problemas de compatibilidad de versiones. Aún pueden generar SQL específico para un dialecto (por ejemplo, PostgreSQL frente a MySQL) o no utilizar funciones compatibles con versiones anteriores, a menos que se les indique o capacite explícitamente para ello. La validación con la base de datos de destino sigue siendo importante.
Enlaces de referencia
Comentarios 1
Comparte tus ideas
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios.
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.