Text-to-SQL

Text-to-SQL es la capacidad de un sistema para convertir una pregunta hecha en lenguaje natural (por ejemplo, "¿cuánto vendimos en Córdoba el mes pasado?") en una consulta SQL válida que la base de datos puede ejecutar y responder. En lugar de escribir la sentencia técnica (un SELECT con sumas, filtros y condiciones por provincia), el usuario pregunta como hablaría con un colega y el sistema arma el código por debajo.

Hoy esta traducción la hace un modelo de lenguaje grande (LLM) que entiende tanto la intención de la pregunta como la estructura de las tablas. Es la pieza que está detrás del BI conversacional y de los asistentes que dejan "conversar con tus datos". En la plataforma de analítica Metrix, Text-to-SQL es lo que conecta una pregunta de negocio con la base de datos para devolver una cifra o un gráfico, sin que el usuario abra una herramienta técnica.

La clave no es solo generar SQL que "corra", sino generar SQL correcto: que apunte a las tablas y columnas reales, respete las relaciones y devuelva exactamente lo que la persona quiso preguntar.

Cómo funciona por dentro

Cuando alguien escribe una pregunta, el sistema no la manda "cruda" al modelo. Primero le da contexto del esquema: qué tablas existen, qué columnas tiene cada una, los tipos de dato y cómo se relacionan (por ejemplo, que la columna de cliente de la tabla de pedidos apunta al identificador de la tabla de clientes). Con ese contexto y la pregunta, el modelo redacta la consulta SQL. Luego, un buen sistema valida esa consulta antes de ejecutarla: revisa que las tablas y columnas existan, que la sintaxis sea correcta y, a veces, corre una versión de prueba para detectar errores. Recién entonces ejecuta la consulta y muestra el resultado.

Los sistemas serios agregan una capa semántica entre la pregunta y la base. Esa capa define el negocio en términos humanos: qué significa "ingreso neto", qué cuenta como "cliente activo", cómo se calcula el "margen". Sin ella, el modelo tiene que adivinar la lógica de negocio mirando nombres de columnas, y ahí es donde aparecen los errores. Con ella, "ventas del trimestre" siempre se traduce de la misma forma, sin importar quién pregunte.

Por qué importa para el negocio

El cuello de botella clásico del análisis de datos no es la falta de datos, es la dependencia del área técnica. La gerenta de ventas necesita un número, abre un ticket al equipo de datos, espera dos días, recibe el reporte, descubre que faltaba un filtro y vuelve a pedir. Text-to-SQL rompe ese ciclo: habilita el self-service analytics real, donde quien necesita el dato lo obtiene en segundos, escribiendo en su idioma. El analista deja de ser un traductor de pedidos y se dedica a problemas más complejos.

Un ejemplo concreto en Argentina: una distribuidora de Consumo Masivo con cientos de SKUs y ventas por canal. El jefe de trade pregunta "¿qué productos cayeron más de 20% en el canal tradicional versus el mes anterior?". Antes eso era una consulta de varias líneas con joins y subconsultas. Con Text-to-SQL, escribe la frase, el sistema arma el SQL contra las tablas de ventas, lo ejecuta y devuelve la lista. La velocidad de decisión cambia por completo.

Errores comunes y límites

• Confundir Text-to-SQL con un buscador: no busca texto, genera código que se ejecuta sobre datos estructurados. La calidad depende de qué tan bien definidas estén las tablas.
• Esperar que adivine la lógica de negocio: si "facturación" se calcula distinto en finanzas que en ventas, el modelo no lo sabe a menos que se lo definas en la capa semántica.
• Saltarse la validación: sin un paso que verifique la consulta antes de correrla, el sistema puede inventar columnas que no existen, una forma de alucinación.
• No restringir permisos: el SQL generado debe correr con los mismos permisos que tendría el usuario; nunca darle acceso total a la base.

En qué se diferencia del BI conversacional y de RAG

Estos tres términos se cruzan, pero no son lo mismo. Esta tabla los separa:

En resumen: Text-to-SQL es el motor, el BI conversacional es el producto que lo usa, y el RAG resuelve un problema distinto (preguntas sobre documentos, no sobre tablas). Para un dato numérico exacto de la base, querés Text-to-SQL bien implementado, con su esquema claro, su capa semántica y su paso de validación.