«Consultar datos con una frase» suena sencillo, pero llevarlo a producción implica resolver muchos problemas: definiciones de negocio inconsistentes, esquemas de tablas complejos, SQL generado por el modelo que puede consultar mal, permisos que no deben cruzarse y resultados que todavía tienen que ser explicables. El núcleo de una API de análisis de datos con IA no es que el modelo «sepa escribir SQL», sino que traduzca de forma estable preguntas en lenguaje natural a datos e informes fiables.
Este artículo presenta un plan de implementación empresarial que cubre arquitectura, diseño de esquemas, prompts, validación, permisos, pruebas de precisión y costos.
Nota: las bases de datos, las plataformas de BI y las interfaces de modelos varían. Este artículo usa como ejemplo la combinación habitual de «base de datos de solo lectura + interfaz de chat compatible con OpenAI»; los modelos y precios se rigen por los precios de los modelos de este sitio.
1. Arquitectura general
Conviene dividir el flujo en pasos observables:
Pregunta en lenguaje natural
→ Identificación de intención (consulta / explicación / aclaración)
→ Recuperación de esquema (tablas, columnas, métricas, ejemplos)
→ Generación de SQL
→ Validación estática + inyección de permisos
→ Ejecución de solo lectura (tiempo de espera, límite de filas)
→ Validación del resultado
→ Configuración de gráfico + interpretación textual
Principios clave:
- El modelo no se conecta directamente a la base de datos de producción, solo a una réplica de lectura o al almacén de datos.
- Los permisos se inyectan en el servidor; no dependen de las instrucciones del prompt.
- Cada paso deja registro: pregunta, tablas recuperadas, SQL generado, tiempo de ejecución y filas devueltas.
- Si algo falla, se da al usuario una explicación comprensible, no el error en bruto de la base de datos.
2. El diseño del esquema importa más que el modelo
El modelo no sabe cómo define tu empresa «usuario activo» o «pedido válido». Ese conocimiento hay que dárselo de forma explícita.
Se recomienda mantener una «ficha de esquema» por tabla:
| Campo | Ejemplo de contenido |
|---|---|
| Nombre de tabla | dwd_order |
| Significado de negocio | Detalle de pedidos; una fila por producto pedido |
| Clave primaria / granularidad | order_id + sku_id |
| Columnas habituales | Fecha del pedido, importe pagado, estado, canal |
| Definición de métrica | Importe pagado = importe realmente abonado, sin reembolsos |
| Tablas relacionadas | Usuarios, productos, canales |
| Advertencias | No usar create_time en lugar de la fecha de pago |
| Pregunta de ejemplo | Importe pagado por canal en los últimos 30 días |
Además de las fichas, prepara:
- Sinónimos de negocio: GMV, volumen de negocio e importe de transacciones apuntan a la misma métrica.
- Un diccionario de métricas: definición, numerador y denominador, criterio temporal y retraso de los datos.
- Algunos ejemplos de «pregunta → SQL» que cubran las consultas habituales.
- Las rutas de join entre tablas, para que el modelo no tenga que adivinar las claves de relación.
La recuperación de esquema puede combinar palabras clave y recuperación vectorial para poner en contexto las 5 a 10 tablas y definiciones de métricas más relevantes. Meter el esquema completo es caro y además introduce ruido.
3. Cómo escribir el prompt
El objetivo del prompt es «restringir», no «animar a improvisar». Una plantilla útil:
Eres un asistente de análisis de datos empresariales. A partir del esquema y las definiciones de métricas proporcionados, convierte la pregunta del usuario en SQL.
Requisitos:
1. Genera una sola sentencia SELECT; prohíbe INSERT/UPDATE/DELETE/DDL.
2. Usa solo las tablas y columnas proporcionadas; no inventes campos.
3. Las métricas se rigen por el "diccionario de métricas" y debes explicarlas en assumptions.
4. Si el rango temporal no está claro, usa por defecto los últimos 30 días e indícalo.
5. Si la pregunta es ambigua, devuelve primero clarifying_question; no adivines.
6. Salida JSON: {"sql": "", "assumptions": [], "clarifying_question": null}
Algunos detalles:
- Pide al modelo que haga explícitas sus suposiciones para que el negocio pueda comprobar la definición.
- Deja claro que debe «aclarar antes de consultar»; esto reduce de forma notable las respuestas que no vienen al caso.
- Para «interanual / intermensual / porcentaje» proporciona fórmulas concretas; no dejes que el modelo improvise.
- En conversaciones multiturno, conserva la métrica y el rango temporal del turno anterior, pero no conserves SQL caducado.
4. Validación de SQL y barreras de ejecución
Generar el SQL es solo el principio. Antes de ejecutarlo hay que superar al menos cinco comprobaciones:
- Análisis sintáctico: usar un parser de SQL y rechazar múltiples sentencias.
- Tipo de sentencia: permitir solo SELECT; prohibir escrituras y procedimientos almacenados.
- Lista blanca de objetos: tablas y columnas deben estar en la lista autorizada.
- Inyección de permisos: añadir automáticamente filtros de inquilino, departamento y región.
- Control de costos: añadir rango temporal, LIMIT, tiempo de espera y límite de datos escaneados.
En la capa de ejecución se recomienda una cuenta independiente de solo lectura, conectada a una réplica, con:
- Tiempo de espera de consulta, por ejemplo 30 segundos.
- Número máximo de filas devueltas, por ejemplo 1000.
- EXPLAIN previo en tablas grandes para estimar el volumen escaneado.
- Como máximo 1 o 2 reintentos, devolviendo el error de la base de datos al modelo para que corrija.
- Caché de resultados para preguntas idénticas, con una clave que incluya el ámbito de permisos del usuario.
5. Permisos: el modelo no sustituye al sistema de permisos
El accidente más habitual en el análisis conversacional es que «un usuario ve datos que no debería ver». Lo correcto es reutilizar el modelo de permisos del BI o del almacén de datos:
- Nivel de conjunto de datos: a qué tablas puede acceder el usuario.
- Nivel de fila: filtrar por inquilino, departamento y región.
- Nivel de columna: enmascarar u ocultar teléfonos, documentos de identidad, precios de costo y campos similares.
- Nivel de métrica: autorización separada para métricas sensibles.
- Nivel de sesión: borrar contexto y caché al cambiar de usuario.
El modelo solo genera la intención de consulta; los permisos los impone el servidor en la capa externa del SQL o en la capa de vistas. Registra en el log la pregunta original, el SQL final, el ejecutor y el número de filas devueltas para facilitar la auditoría. Autoriza la exportación por separado, para evitar que «poder consultar» signifique «poder descargar en bloque».
6. Del resultado al gráfico
Un resultado de consulta no es un informe. Se recomienda pedir al modelo «configuración de gráfico + conclusión textual» en lugar de generar directamente una imagen:
| Forma de los datos | Gráfico recomendado |
|---|---|
| Serie temporal | Gráfico de líneas |
| Comparación de categorías | Gráfico de barras |
| Proporción | Gráfico circular o barras apiladas |
| Correlación | Diagrama de dispersión |
| Métrica única | Tarjeta de indicador |
La conclusión textual debe incluir: definición, rango temporal, cifras clave y puntos anómalos. Por ejemplo: «En los últimos 30 días, el importe pagado cayó un 8% intermensual, sobre todo por el canal del este de China», con un detalle enlazable. No basta con decir «los datos se comportan bien».
7. Cómo medir la precisión
Prepara entre 100 y 300 preguntas de negocio reales, estratificadas por dificultad:
- Consultas de una sola tabla y agregaciones.
- Joins entre varias tablas.
- Interanual, intermensual y porcentajes.
- Preguntas ambiguas que requieren aclaración.
- Preguntas sin datos o sin permisos.
La evaluación no debe limitarse a si el SQL se parece al esperado, sino a si el resultado de la ejecución coincide. Conviene registrar:
| Métrica | Descripción |
|---|---|
| Precisión de ejecución | El resultado coincide con la respuesta estándar humana |
| Tasa de aclaración | Si las preguntas ambiguas reciben una repregunta correcta |
| Tasa de bloqueo de accesos indebidos | Si se rechazan las solicitudes sin permiso |
| Explicabilidad de fallos | Si los errores se traducen a un lenguaje comprensible |
| Latencia media | Desde la pregunta hasta el gráfico |
Haz una regresión cada semana y vuelve a ejecutarla obligatoriamente cuando cambie el modelo o el esquema. Al principio, mantén un modo de «confirmación manual del SQL» y abre la ejecución automática cuando el sistema se estabilice.
8. Costos y rendimiento
El costo del análisis de datos con IA proviene de tres bloques: recuperación de esquema, generación de SQL e interpretación del resultado.
- Usa recuperación vectorial para reducir el contexto y enviar solo las tablas relevantes.
- Emplea un modelo pequeño para identificar intenciones y resolver consultas simples; reserva el modelo potente para las complejas.
- Cachea las preguntas frecuentes y los resultados del mismo ámbito de permisos.
- Para interpretar el resultado, envía solo datos agregados, no el detalle completo.
- Resume los esquemas largos para no enviar el DDL completo en cada llamada.
Fórmula de estimación:
Costo por consulta =
tokens de contexto de esquema × precio de entrada
+ tokens de salida del SQL × precio de salida
+ tokens de interpretación × precio
+ costo de ejecución en la base de datos
Los precios unitarios concretos se rigen por los precios de los modelos; el costo de la base de datos se calcula aparte, sobre todo en escaneos de tablas grandes.
9. Fallos habituales y cómo tratarlos
| Síntoma | Causa habitual | Tratamiento |
|---|---|---|
| La columna no existe | Esquema no recuperado o campo inventado | Validación contra lista blanca + devolver el error y reintentar |
| Definición inconsistente | Falta la definición de la métrica | Completar el diccionario y exigir suposiciones explícitas |
| El join multiplica filas | Clave de relación o granularidad incorrecta | Proporcionar rutas de join y validar el número de filas |
| Rango temporal erróneo | Zona horaria o valor por defecto poco claro | Unificar la zona horaria y explicitar el rango por defecto |
| Acceso fuera de permisos | Confiar solo en el prompt | Inyectar filtros obligatorios en el servidor |
| Respuesta que no viene al caso | Pregunta ambigua | Aclarar antes de consultar |
Preguntas frecuentes
¿La IA de análisis de datos sustituirá al BI?
No. Es más adecuada para «preguntas puntuales, obtención rápida de datos y explicación de informes»; los informes fijos y complejos siguen correspondiendo al BI.
¿Hay que entregar todo el esquema de la base de datos al modelo?
No. Con recuperación de esquema solo se envían las tablas y métricas relevantes, lo que reduce costo y también usos incorrectos.
¿Se puede ejecutar directamente el SQL que genera el modelo?
No se recomienda. Debe pasar por las cuatro validaciones de sintaxis, lista blanca, permisos y costo, y ejecutarse sobre una réplica de solo lectura.
¿Qué precisión se puede alcanzar?
Depende de la calidad del esquema, la complejidad de las preguntas y el criterio de evaluación. Establece primero una línea base con preguntas reales y mejora semana a semana; no uses preguntas de demostración como representación del conjunto.
¿Cómo empieza un equipo pequeño?
Elige un dominio, por ejemplo ventas u operaciones, organiza de 10 a 20 tablas y un diccionario de métricas, crea un conjunto de 50 preguntas y después decide si ampliar.
Próximos pasos
El éxito del análisis de datos con IA depende en un ochenta por ciento del esquema, las definiciones de métricas y el diseño de permisos, no de los parámetros del modelo. Empieza con una prueba de concepto en un dominio y recorre el ciclo completo «pregunta — validación — ejecución — gráfico — explicación» antes de ampliar. Si necesitas un punto de entrada unificado de modelos y gestión de uso, puedes registrarte en ZSQH AI Gateway; los modelos y precios se rigen por los precios de los modelos.
Lecturas relacionadas:
