6. Proporciona consultas SQL verificadas

Uno de los mecanismos más potentes para mejorar un sistema NL→SQL consiste en proporcionar pares de pregunta y SQL que sabemos que son correctos.

Por ejemplo:

Pregunta

¿Cuáles fueron los cinco productos con mayores
ingresos netos durante el último trimestre?

Consulta verificada

SELECT
    p.product_name,
    SUM(s.net_sales_amount) AS net_revenue
FROM analytics.sales AS s
JOIN analytics.products AS p
    ON s.product_id = p.product_id
WHERE s.sale_date >= DATE_TRUNC('quarter', CURRENT_DATE) - INTERVAL '3 months'
  AND s.sale_date < DATE_TRUNC('quarter', CURRENT_DATE)
GROUP BY p.product_name
ORDER BY net_revenue DESC
LIMIT 5;

Estos ejemplos cumplen dos funciones.

Primero, muestran al sistema cómo se traducen conceptos de negocio a estructuras SQL. Segundo, proporcionan casos conocidos contra los que podemos evaluar nuevas versiones.

Snowflake incorpora consultas verificadas como mecanismo para mejorar la confianza y también las utiliza como base para evaluar la precisión de Cortex Analyst.

Databricks sigue una filosofía similar mediante consultas SQL de ejemplo y activos confiables configurados dentro de Genie.

7. Trata la generación de SQL como un sistema que necesita pruebas

Cambiar el modelo, modificar una descripción o añadir una tabla puede alterar las consultas generadas. Por eso necesitamos pruebas de regresión. Podemos construir un conjunto de preguntas como:

¿Cuántos clientes activos tenemos?

¿Cuál fue el ingreso neto del mes pasado?

¿Qué categoría tiene mayor margen?

¿Cuáles son los diez clientes con más compras?

¿Cómo evolucionaron las ventas interanuales?

Para cada pregunta almacenamos una consulta o un resultado esperado. Después evaluamos cada nueva versión del sistema.

No es necesario exigir que el SQL generado sea idéntico carácter por carácter. Dos consultas diferentes pueden producir correctamente el mismo resultado.

Lo importante es validar aspectos como:

• tablas utilizadas;
• relaciones;
• filtros;
• métricas;
• agregaciones;
• periodo temporal;
• resultado final.

La evaluación continua convierte el NL→SQL en ingeniería y no simplemente en prompting.

8. Introduce guardrails antes de ejecutar la consulta

Generar SQL y ejecutar SQL son dos problemas diferentes, aunque el sistema produzca una consulta válida, no deberíamos asumir automáticamente que es segura.

Una arquitectura sencilla puede funcionar así:

Pregunta del usuario
        ↓
Recuperación de contexto
        ↓
Generación SQL
        ↓
Validación
        ↓
Ejecución controlada
        ↓
Resultado

Entre generación y ejecución podemos introducir controles. Por ejemplo:

Solo lectura

El usuario destinado a análisis puede disponer únicamente de permisos SELECT.

De esta forma, incluso si el modelo genera accidentalmente:

DELETE FROM customers;

la base de datos rechazará la operación.

Lista de objetos permitidos

El asistente puede consultar únicamente determinadas vistas analíticas.

Límites

Podemos imponer límites de filas o tiempo de ejecución.

Análisis previo

Antes de ejecutar podemos comprobar:

• presencia de DELETE, UPDATE, DROP o ALTER;
• joins sin condiciones;
• consultas contra tablas prohibidas;
• estimaciones de coste excesivas.

Microsoft aplica una separación similar en sus experiencias Copilot: las respuestas generadas deben revisarse y las operaciones que pueden modificar datos requieren intervención o aprobación del usuario. La documentación también advierte expresamente de que las consultas generadas pueden ser inexactas.

9. Respeta los permisos del usuario

Un asistente no debería convertirse en una vía alternativa para saltarse el modelo de seguridad.

Si una persona no puede consultar salarios mediante SQL convencional, tampoco debería poder obtenerlos preguntando: ¿Cuál es el salario medio de cada empleado?

La ejecución debe realizarse con permisos equivalentes a los del usuario o mediante una política perfectamente controlada.

Databricks, por ejemplo, evalúa el acceso a los datos de Genie utilizando los permisos de Unity Catalog del usuario final.

El principio general es sencillo: la IA no sustituye el gobierno del dato; debe trabajar dentro de él.

10. Registra pregunta, SQL y resultado

Un sistema en producción necesita observabilidad. Como mínimo conviene registrar:

pregunta
contexto utilizado
SQL generado
tiempo de ejecución
error
usuario
feedback

Esto permite descubrir patrones. Quizá muchas consultas fallen cuando aparece la palabra “facturación”. Quizá una relación concreta produzca duplicados.

Quizá los usuarios utilicen un término que todavía no existe como sinónimo en la capa semántica.

Los errores dejan entonces de ser casos aislados y pasan a convertirse en información para mejorar el sistema.

Una arquitectura práctica

Una arquitectura razonable para un asistente SQL podría dividirse en cinco capas.

1. Datos físicos

Las tablas originales:

ERP
CRM
e-commerce
facturación
soporte

2. Modelo analítico

Vistas o tablas curadas:

customers
sales
products
calendar

3. Capa semántica

Aquí viven:

métricas
dimensiones
relaciones
definiciones
sinónimos
reglas de negocio

4. Sistema NL→SQL

El modelo recibe únicamente el contexto relevante y genera la consulta.

5. Validación y ejecución

Finalmente se aplican permisos, límites, comprobaciones y observabilidad.

La arquitectura sería:

Usuario
   ↓
Lenguaje natural
   ↓
Contexto + capa semántica
   ↓
LLM / agente SQL
   ↓
SQL generado
   ↓
Validador
   ↓
Motor SQL
   ↓
Resultado

La mayor parte de la fiabilidad no procede exclusivamente de la caja “LLM”. Procede de todo lo que la rodea.

Checklist para preparar SQL para IA

Antes de conectar un asistente de lenguaje natural a una base de datos, merece la pena revisar:

• ¿Las tablas tienen nombres comprensibles?
• ¿Las columnas expresan claramente qué representan?
• ¿Las claves primarias y foráneas están declaradas?
• ¿Las relaciones importantes están documentadas?
• ¿Las métricas de negocio tienen una única definición?
• ¿Existen vistas analíticas que oculten complejidad innecesaria?
• ¿Se han definido sinónimos del vocabulario utilizado por los usuarios?
• ¿Tenemos preguntas y consultas verificadas?
• ¿Existe un conjunto de pruebas de regresión?
• ¿El usuario de ejecución tiene permisos mínimos?
• ¿Las consultas generadas pasan por un validador?
• ¿Registramos errores y feedback?

Cuantas más respuestas sean afirmativas, menos dependerá el sistema de que el modelo “adivine”.

Conclusión

La llegada de la IA está obligándonos a mirar las bases de datos desde una perspectiva nueva. Durante años optimizamos esquemas para aplicaciones, desarrolladores y herramientas de BI.

Ahora tenemos un nuevo consumidor: los modelos de lenguaje. Y estos modelos funcionan mejor cuando el significado está explícito.

Un esquema limpio ayuda, las relaciones ayudan, las vistas ayudan.

Pero el verdadero salto aparece cuando añadimos una capa semántica con métricas, conceptos, sinónimos y ejemplos verificados, y posteriormente rodeamos la generación SQL de permisos, validación y evaluación.

Por eso, antes de buscar un modelo más grande para mejorar tu sistema NL→SQL, merece la pena hacer una pregunta diferente:

¿Entendería alguien nuevo en tu equipo lo que significa tu modelo de datos sin tener que preguntarte nada?

Si la respuesta es no, probablemente la IA tampoco.