Text-to-SQL empresarial: qué es, cómo funciona y dónde falla
Text-to-SQL traduce una pregunta en español a una consulta SQL sobre las bases de la empresa. Acierta si hay una capa semántica; sin ella, responde otra cosa.
En resumen
- Text-to-SQL es la traducción automática de una pregunta en lenguaje natural a una consulta SQL ejecutable sobre las bases de datos de la empresa. No genera la respuesta: genera la consulta que la calcula.
- El desempeño en benchmarks académicos no predice el desempeño en una empresa: los benchmarks usan esquemas limpios y documentados, y un ERP en producción tiene nombres heredados, estados codificados y varios campos de fecha.
- El componente que determina el resultado no es el modelo sino la capa semántica: la descripción explícita de qué significa cada tabla, cómo se calcula cada métrica y qué reglas del negocio aplican.
- El modo de falla peligroso de text-to-SQL no es la consulta que da error, sino la consulta sintácticamente correcta que responde otra pregunta. Por eso la respuesta tiene que mostrar sobre qué se calculó.
- Text-to-SQL no responde preguntas sobre datos que no se registran, preguntas causales ni preguntas que dependen de información externa no integrada. Ese límite se declara antes de implementar.
Text-to-SQL empresarial es la traducción automática de una pregunta escrita en español a una consulta SQL que se ejecuta sobre las bases de datos de la empresa. No genera la respuesta: genera la consulta, y la cifra la calcula la base. Funciona cuando existe una capa semántica que explica qué significa cada tabla; sin ella, responde otra pregunta.
Es la pieza técnica que hace posible la analítica conversacional, y también la que genera más expectativas equivocadas. Entender qué hace exactamente ahorra la decepción de la tercera semana.
¿Qué es text-to-SQL?
Text-to-SQL es la traducción de una pregunta en lenguaje natural a una consulta ejecutable sobre una base de datos relacional. En la literatura académica también se lo llama NL2SQL. Alguien escribe «cuánto vendimos en el canal mayorista este trimestre contra el anterior» y el sistema produce el SQL que calcula esa cifra sobre el esquema real de la empresa.
Conviene subrayar lo que no hace, porque es donde se confunde con otra cosa: no genera la respuesta. La cifra la calcula el motor de base de datos ejecutando ese SQL contra los datos reales. El modelo de lenguaje participa en la traducción y después en la redacción del resultado, pero nunca produce el número.
Esa separación es la que vuelve aceptable la categoría donde una cifra inventada tiene consecuencias. Un asistente general que responde «las ventas del trimestre fueron de 4,2 millones» sin haber consultado nada es un riesgo. Un sistema que ejecutó una consulta y puede mostrar sobre qué la calculó es auditable.
¿Cómo funciona text-to-SQL en una empresa?
Un sistema text-to-SQL empresarial recorre cinco pasos entre la pregunta y la cifra:
- Conocer el esquema. Antes de la primera pregunta, el sistema recorre la estructura de las tablas expuestas —nombres, columnas, relaciones— y unas pocas filas de ejemplo por tabla para entender qué guarda cada columna. Así lo hace Igniten al conectar una base.
- Interpretar la pregunta. Qué métrica, qué entidad, qué período, qué comparación. Si hay dos lecturas razonables, repregunta.
- Aplicar permisos. La consulta se arma ya restringida a las tablas y columnas que la persona puede ver, no se filtra después.
- Generar y verificar la consulta. El modelo escribe el SQL apoyado en la capa semántica, y el sistema comprueba que sea de solo lectura antes de ejecutarlo.
- Ejecutar y redactar. La consulta corre con un tope de tiempo y de filas para no cargar la base, y el resultado vuelve con su tabla y su gráfico.
Ninguno de esos pasos requiere migrar datos: la consulta corre sobre la base del ERP, sobre una réplica o sobre un data warehouse si existe. Los motores habituales en empresas medianas —SQL Server, PostgreSQL, Oracle, MySQL— están en la lista de integraciones, cada uno con los permisos exactos que conviene conceder.
¿Por qué los benchmarks de text-to-SQL no predicen el resultado en una empresa?
Los benchmarks no predicen el resultado porque miden esquemas limpios, y el problema de una empresa es un esquema sucio. Existen conjuntos de prueba públicos, como Spider o BIRD, donde los modelos actuales alcanzan cifras de precisión que suenan a problema resuelto. No lo está.
Los esquemas de esos conjuntos tienen nombres de tablas descriptivos, columnas con significados evidentes y poca ambigüedad. Un ERP con doce años de operación no se parece a eso:
- Tablas con nombres heredados de un sistema anterior que nadie migró del todo.
- Columnas cuyo significado real solo conoce quien las creó, que ya no trabaja en la empresa.
- Estados codificados como números, con la tabla de referencia en un documento aparte o en la cabeza de alguien.
- Tres o cuatro campos de fecha por registro —creación, modificación, despacho, facturación— de los cuales solo uno es el correcto para el cálculo pedido.
- Filas de prueba, cargas duplicadas y correcciones manuales que ningún esquema declara.
Sobre ese esquema, un modelo excelente en benchmarks produce consultas sintácticamente impecables y semánticamente equivocadas. Esa es la falla más peligrosa de text-to-SQL: no da error, da un número.
¿Qué es la capa semántica y por qué es el verdadero proyecto?
La capa semántica es la descripción explícita, mantenida y versionada de qué significa cada tabla y cada campo, cómo se calcula cada métrica del negocio y qué reglas aplican. Es lo que separa un piloto que funciona de uno que se abandona, y en la práctica incluye cuatro cosas:
- Definiciones de métricas. Qué es exactamente «venta neta»: si descuenta devoluciones, si incluye impuestos, si cuenta al despachar o al facturar. Un KPI sin definición escrita es una fuente de discusión, no de información.
- Relaciones entre entidades. Cómo se une cliente con pedido con despacho, y cuál de las claves candidatas es la correcta.
- Reglas de exclusión. Qué filas no se cuentan nunca: pruebas, anulaciones, ajustes contables.
- Sinónimos del negocio. Que «mayorista», «canal M» y «distribuidores» son la misma cosa para quien pregunta.
Construir esto lleva tiempo y no es vistoso. Pero es la parte del trabajo que determina el resultado, y la única que sigue valiendo si mañana cambia el modelo, el proveedor o la plataforma. Las definiciones del negocio, escritas y ejecutables, son un activo de la empresa; el modelo es una dependencia reemplazable. Cuando esas definiciones están en disputa entre áreas, el trabajo previo es de gobernanza de datos, y es lo que se aborda en gobernanza de IA.
¿Cómo se controla el error en text-to-SQL?
El error se controla con cuatro mecanismos que no dependen de que el modelo acierte. Ninguna implementación seria trata la consulta generada como infalible:
| Control | Qué evita | Cómo se ve en la práctica |
|---|---|---|
| Mostrar sobre qué se calculó | Que un malentendido pase inadvertido | La respuesta indica período, filtros y definición usada |
| Repreguntar ante la ambigüedad | Que el sistema adivine en silencio | «¿Mes calendario o últimos 30 días?» |
| Restringir el alcance | Que un error toque lo que no debe | Solo lectura, solo las tablas del dominio habilitado |
| Registrar cada consulta | Que el patrón de fallas quede oculto | Quién preguntó, qué se ejecutó y cuándo |
El primero es el más importante. La mayoría de los errores que un usuario detecta los detecta leyendo que el sistema entendió «este mes» como los últimos treinta días cuando quería decir el mes calendario. El tercero no corrige errores de traducción, pero acota qué puede salir mal: aplica el principio de menor privilegio a la conexión, con un usuario de base de datos exclusivo y permiso solo sobre las tablas expuestas. Cómo configurarlo sin abrir el sistema está en cómo conectar el ERP a un agente de IA sin exponer datos sensibles.
¿Qué preguntas no puede responder text-to-SQL?
Text-to-SQL no puede responder tres clases de pregunta, y conviene decirlo antes de implementar y no durante la demostración.
Las que dependen de datos que no se registran. Si el motivo de una devolución nunca se capturó en un campo, ninguna consulta lo recupera. Es frecuente: la pregunta de negocio más importante suele apoyarse en el dato que nadie se ocupó de registrar. Detectar ese hueco es, por sí solo, un resultado valioso de un diagnóstico, y suele ser un problema de calidad de datos más que de tecnología.
Las causales. «¿Por qué cayó el margen?» no es una consulta, es un análisis. El sistema puede aportar las piezas —qué cambió, dónde, cuándo, correlacionado con qué—, pero la atribución causal sigue siendo trabajo humano, y presentarla como automática es venderle a la empresa una certeza que no existe.
Las que requieren información externa. Precios de la competencia, clima, indicadores macroeconómicos: si no están integrados, no están.
Tampoco es la herramienta para el seguimiento diario de las mismas cinco cifras: ese uso sigue siendo del tablero, como se explica en analítica conversacional vs. dashboards de BI.
¿Cuándo está lista una empresa para text-to-SQL?
Una empresa está lista para text-to-SQL cuando cumple tres condiciones, en este orden:
- Un dominio acotado con dueño. Un área, un conjunto de tablas, alguien que pueda decidir qué significa cada métrica.
- Definiciones acordadas para ese dominio. No para toda la empresa: para el dominio del primer caso de uso. Es alcanzable en semanas.
- Una pregunta de negocio real que hoy tarde demasiado. Si no la hay, el problema de la empresa no es el acceso a los datos.
Lo que no hace falta: un data warehouse, un equipo de datos ni haber terminado un proyecto de calidad de datos. Todo eso ayuda; nada de eso es condición de arranque. Lo que sí es condición es que las cifras existentes sean consistentes entre áreas.
El panorama completo de cómo esta pieza encaja en una implementación está en la guía de analítica conversacional. Text-to-SQL funcionando sobre una conversación real, con la cifra, la tabla y el gráfico, se puede ver en la plataforma de Igniten.