- La funcionalidad de Text-to-SQL basada en Gemini se usa en todo Google Cloud para aumentar la productividad de desarrolladores y usuarios no técnicos
- En entornos reales, es difícil generar SQL preciso debido a la falta de contexto de negocio, la dificultad para interpretar la intención del usuario y las diferencias entre dialectos de SQL
- Para resolver esto, Google incorpora técnicas como búsqueda inteligente de datos, aprendizaje basado en contexto y estratificación semántica
- Las limitaciones del propio modelo se superan con generación múltiple y selección de la mejor opción (self-consistency), validación seguida de re-prompting y entrenamiento por dialecto de SQL
- La evaluación y medición de mejoras incluye benchmarks propios y técnicas que usan al LLM como juez para aumentar la viabilidad en entornos reales
Techniques for improving text-to-SQL
De texto a SQL: el estado actual en Google Cloud
- Las organizaciones usan SQL para obtener insights de datos de forma rápida y precisa
- Gemini ofrece la funcionalidad de text-to-SQL, que genera SQL directamente a partir de lenguaje natural
- Esta función es útil no solo para desarrolladores, sino también para usuarios no técnicos
- Actualmente, esta función está disponible en BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI y otros productos
Principales desafíos de la tecnología Text-to-SQL
1. La dificultad de aportar contexto de negocio
- Para escribir SQL preciso, es necesario darle al LLM suficiente contexto sobre la estructura de la base de datos, el significado de las columnas y el contenido real de los datos
- El contexto incluye tanto información explícita (esquema, información de columnas, etc.) como información implícita (como el significado de negocio de ciertos datos)
- Seguir entrenando continuamente al LLM (fine-tuning) para adaptarlo a cambios en la estructura de la base de datos, transformaciones del dataset o modificaciones del esquema es, en la práctica, costoso
- Muchas veces el conocimiento de negocio o la información semántica no están bien organizados, y además convertirlos en datos de entrenamiento también resulta difícil
- Ejemplo: si un DBA no conoce el significado de
cat_id2 = 'Footwear' en la tabla pcat_extension, tampoco puede escribir un SQL para consultar ventas de calzado; del mismo modo, un LLM corre el riesgo de generar consultas incorrectas si le falta contexto
2. Problemas al interpretar la intención del usuario
- En comparación con SQL, las consultas en lenguaje natural suelen carecer de claridad
- Un analista de datos o ingeniero real puede hacer preguntas adicionales cuando una consulta es ambigua, pero un LLM tiende a responder de inmediato con base en la pregunta dada, lo que implica riesgo de información incorrecta (hallucination)
- En una pregunta como “¿Cuál es el zapato más vendido?”, no está claro el criterio de “más vendido” (cantidad de pedidos, ingresos, etc.) ni cuántos resultados se esperan
- Los usuarios con conocimientos técnicos pueden usar un SQL aproximado como punto de partida, pero para usuarios no especialistas es más importante contar con SQL que funcione correctamente
- Para funcionar bien, el LLM debe poder ofrecer preguntas de seguimiento, explicaciones de razonamiento y guías para el usuario que permitan identificar con más precisión la intención del usuario
3. Limitaciones generativas del LLM
- Los LLM son fuertes en tareas como resumen de documentos y extracción de información, pero tienen debilidades cuando se trata de sintaxis SQL precisa o funciones de SQL menos usadas
- La sintaxis cambia según el dialecto de SQL, y hasta diferencias menores exigen alta precisión
- Ejemplo: en BigQuery se usa
EXTRACT(MONTH FROM timestamp_column), mientras que en MySQL debe usarse MONTH(timestamp_column)
- Generar SQL de forma consistente cumpliendo especificaciones complejas no es una tarea sencilla para un LLM
Técnicas de Google Cloud para mejorar Text-to-SQL
Problema: esquema y contexto de negocio
- Búsqueda y ranking basados en significado
- Aprendizaje en contexto
- Muestreo y vinculación de datos
- Construcción de capas semánticas
- Análisis de patrones de uso e historial
Problema: interpretación de la intención del usuario
- Aclaración mediante LLM
- Identificación de entidades, verificación de información relacionada y generación de preguntas de seguimiento adecuadas
Problema: superar las limitaciones del LLM
- Self-consistency para generar múltiples consultas y luego elegir la mejor
- Validación y re-prompting
- Aprendizaje en contexto con ejemplos que incluyan dialectos de SQL
- Fine-tuning del modelo
Ejemplos clave de aplicación técnica
Modelos SQL-aware
- Gemini usa varias versiones ajustadas con fine-tuning para generar SQL de alta calidad
- Para asegurar precisión por dialecto de SQL, realiza mezcla de versiones de modelos y ajustes personalizados
Aclaración de preguntas del usuario (Disambiguation)
- Cuando la pregunta es ambigua, se generan preguntas de aclaración
- Ejemplo: "¿El zapato más vendido?" → “¿Se refiere a cantidad de pedidos o a ingresos?”
Búsqueda semántica y construcción de contexto
- Búsqueda vectorial basada en coincidencia semántica en múltiples etapas para identificar tablas y columnas relevantes
- El prompt se construye incluyendo historial de consultas del usuario, ejemplos de reglas de negocio, etc.
- El soporte para ventanas de contexto largas permite trabajar con esquemas de gran tamaño
Validación y regeneración
- Se detectan errores explícitos en las consultas generadas por el LLM mediante parsing, dry-run, etc.
- Si se detecta un error, se induce una corrección mediante re-prompting
Self-consistency
- En lugar de una sola consulta, se generan múltiples consultas de distintas maneras
- Si varios modelos recomiendan la misma consulta, mejora la precisión
Evaluación y medición de desempeño
- Los benchmarks existentes (como BIRD-bench) son útiles, pero tienen limitaciones para reflejar esquemas reales
- Google construyó su propio conjunto de benchmarks sintéticos
Estrategia de evaluación
- Cobertura de dialectos de SQL y funciones por motor: incluye no solo consultas, sino también DDL, DML y tareas administrativas
- Métricas de evaluación: respuesta del usuario, métricas offline y LLM-as-a-judge
- Evaluación continua: permite verificar rápidamente la efectividad de nuevos modelos y técnicas de prompting
Cierre
1 comentarios
Comentarios de Hacker News
Hay dudas sobre el objetivo final de convertir texto a SQL: si se trata de crear una herramienta de apoyo para analistas de datos, o de obtener insights de negocio sin pasar por un analista; si es lo segundo, entonces por más avanzado que sea, existe el problema de que una persona no especialista no puede juzgar la exactitud ni la suficiencia del SQL; preguntas como "¿por qué ayer las transacciones de comercio electrónico se quedaron en 80%?", "¿por qué está subiendo el costo de adquisición de clientes?", "¿por qué la campaña de Nueva York tuvo peor desempeño que la de San Francisco?" quedan fuera del alcance de text2sql
En la práctica parece más cercano al segundo objetivo, pero los resultados no cumplen las expectativas; en negocio quieren cambiar reportes al final, pero por falta de analistas no obtienen la información deseada a tiempo; se intenta resolver con “velocidad infinita”, pero en realidad el problema surge de no pensar lo suficiente en las métricas; los datos son complejos, el conocimiento del negocio está almacenado implícitamente afuera y la infraestructura de datos es insuficiente, así que el análisis toma mucho tiempo; los líderes inteligentes de analítica están aprovechando la ola de la IA para invertir en infraestructura base
Considero que esas preguntas no son problemas que de entrada puedan resolverse con SQL; SQL principalmente responde al "qué (what)", no al "por qué (why)"; el objetivo de text2sql es reducir el tiempo para que el analista resuelva más rápido el "qué" y así pueda enfocarse en el "por qué"
Es cierto, pero yo creo que el texto en lenguaje natural puede convertirse en una entrada universal para sistemas con LLM; text2sql puede servir como base de recuperación de información para construir respuestas a preguntas más complejas; a corto plazo es una función de asistencia laboral, pero a largo plazo el objetivo es sentar las bases para automatización, comparación de resultados e integración en flujos de trabajo más grandes; lo clave es preparar la base para responder este tipo de preguntas; todavía queda mucho por hacer
Cualquier algoritmo puede crearse y probarse si una persona puede hacer esa tarea; si tienes 10 analistas, todos tendrán distintos niveles de habilidad y comprensión de la base de datos y del negocio; la automatización ofrece un estándar que garantiza un nivel mínimo de capacidad y conocimiento; incluso un analista nuevo puede rendir mejor desde el inicio; desarrollar el sistema junto con expertos, probarlo y hacer que la IA interprete trade-offs, bugs y resultados esperados en comparación con los reales es un objetivo útil; automatizar la intuición o el ‘buen criterio’ es difícil, pero un experto de dominio puede llegar muy lejos si cuenta con una automatización bien diseñada y una noción razonable de qué resultados tienen sentido; no es perfecto, pero ese es mi objetivo
Compartieron su experiencia usando el modelo OpenAI 4o: en el prompt incluyen lineamientos de negocio, terminología de la industria y descripciones de tablas y llaves foráneas; así genera incluso consultas complejas con joins y devuelve resultados; el objetivo era entregar resultados a usuarios que no saben SQL, pero también muestran el SQL como referencia
La IA no necesita generar SQL perfecto; en mi caso, aunque la salida pueda validarse con código, no la copio y pego por el riesgo de diferencias semánticas sutiles; en cambio, si la IA me propone un enfoque, lo tomo como referencia y escribo yo mismo el SQL desde cero
Experiencia usando el Gemini más reciente en Google AI Studio: es impresionantemente bueno y revolucionario; los resultados de programación de Claude y ChatGPT se sienten como si vinieran de otro siglo; hace apenas un mes pensaba que Claude era increíble, pero ahora no sé cómo seguiría programando sin Google Gemini; Gemini AI Studio es un salto gigantesco para la programación
Me sorprende que más gente aún no reconozca este cambio; Claude también resuelve bien tareas pequeñas, pero cuando evoluciona a problemas complejos, Gemini está muy por delante; su capacidad de manejo de contexto es especialmente impresionante; no solo lo uso como agente de programación, también uso Gemini para lectura beta de un manuscrito de 85,000 palabras y recibo reportes de retroalimentación de nivel experto casi en tiempo real
Siento que esta semana desactivaron el modo de razonamiento en Gemini Pro gratuito; si logras evitar que se detenga justo antes de escribir código o que generalice demasiado, puede ser bastante útil; eso sí, Gemini tiende a escribir código de más; la forma en que más lo aprovecho es para exploración de diseño, sin quedar atrapado en la implementación; por ejemplo, en un caso de construir un servicio de suscripción con Stripe, pude recibir datos existentes contextualizados a mi stack y mi caso de uso, y cambiar la dirección del diseño antes de escribir una sola línea de código
La respuesta es “usar una semantic layer”; es la forma más efectiva de transmitir el contexto correcto y el punto óptimo para que intervenga una persona; si alguien define claramente todos los indicadores clave, el LLM puede usarlos en cualquier momento; por ejemplo, si se define MAU, el LLM genera consultas con base en esa definición; si escribes consultas en JSON en lugar de SQL, el LLM produce resultados mucho más consistentes; nosotros usamos cube, que es la mejor semantic layer open source; también hay opciones closed source en Naver; en mi empresa anterior escribimos un blog relacionado, pero ahora la empresa propietaria dejó de alojarlo
En el trabajo real es riesgoso usar IA para crear SQL; alguien que no sabe SQL puede escribir una consulta incorrecta y afectar gravemente al servidor; en nuestro equipo la base de datos es grande para el estándar de la mayoría de desarrolladores, aunque no realmente enorme; a veces incluso le pedimos a la IA que mejore consultas ya optimizadas y nunca ha dado una respuesta mejor; a veces la IA dice tonterías o hace sugerencias inútiles en la práctica; se siente como un loro tonto repitiendo cosas que oyó antes
Pienso que sería realmente útil que la IA pudiera convertir texto a expresiones regulares
De todas las herramientas de IA que he probado, la más decepcionante ha sido Gemini integrado en BigQuery; los nombres de columnas eran claros y las descripciones estaban bien hechas, pero no se acercó en absoluto a resolver el problema
El lenguaje en el que más consultas he escrito en mi vida es SQL; aunque le pida a una IA que escriba una consulta, me toma muchísimo más tiempo pulir el resultado que si la escribo yo mismo; aparte, me gustaría que existiera una función que realmente hiciera mucho más rápido escribir SQL; en el DSL de nuestra empresa hay un operador que hace joins automáticos con base en llaves foráneas y es comodísimo; la parte más tediosa de escribir SQL es tener que redactar manualmente 10, 20 o más joins; fuera de eso, lo demás no es tan difícil
Por experiencia, si las restricciones están claras y las llaves foráneas bien definidas, casi todo se resuelve; cada tabla debe tener restricciones claras para que la IA pueda entender con precisión toda la estructura de relaciones; SQL es una especificación muy precisa, pero justamente por eso, si las restricciones y llaves foráneas no están bien definidas, la IA no puede dar respuestas correctas
En todos los foundation models ya se ha vuelto bastante simple; si el esquema de tablas tiene buenos comentarios, pedir generación de consultas es sencillo
Si construyes scaffolding alrededor del modelo con la librería smolagents, se vuelve bastante práctico; también hay textos que dicen que text2sql parece simple como demo, pero aplicarlo en casos reales complejos es muy difícil
Step 1: el esquema tiene miles de tablas y casi no hay comentarios, Step 2...
De verdad creo que sí; a estas alturas ya no hay mucha magia; el DDL de creación de tablas es una descripción bastante exacta de las tablas, así que en realidad casi no hace falta más; si explicas con detalle la consulta que necesitas, casi cualquier LLM puede generarla fácilmente
En el post "Show HN: We open sourced our entire text-to-SQL product" (2024) se mencionan excelentes referencias como awesome-Text2SQL y Awesome-code-llm > Benchmarks > Text to SQL