Preguntarle algo a tu base de datos
La calidad de la respuesta depende mucho más de a qué lo apuntas que de cómo formulas la pregunta.
Data Analyst se conecta a PostgreSQL, MySQL y otros, convierte una pregunta en lenguaje llano en SQL, la ejecuta y dibuja el resultado como gráfico de barras, líneas, tarta, área o dispersión. Guarda historial de consultas, te deja guardar las que repites y compartirlas con personas concretas.
La gente lo prueba, obtiene una respuesta equivocada y concluye que no funciona. Casi siempre el problema es el mismo, y no es el modelo.
Acota el esquema antes de preguntar
El explorador de esquema muestra tus tablas y cómo se relacionan. Úsalo para apuntar la pregunta a dos o tres tablas en lugar de a toda la base de datos.
Esto importa más que cualquier redacción. Un esquema con 90 tablas contiene cuatro cosas que podrían llamarse «ingresos», y el modelo tiene que adivinar cuál querías. Un esquema acotado a orders y order_items contiene una. La pregunta más estrecha es más barata, más rápida y correcta, en ese orden de importancia.
Di qué significan las palabras que usas
Tu base de datos no sabe qué entiende tu empresa por «cliente activo». Dilo: clientes con al menos un pedido en los últimos 90 días. Esa única aclaración elimina el tipo de respuesta equivocada más frecuente, que no es una consulta rota sino una consulta correcta que responde a otra pregunta.
Haz las preguntas compuestas de una vez, no por etapas. «Ingresos por región del Q3 y marca todo lo que esté más de un 15 % por debajo del plan» es una operación. Pedir ingresos, luego regiones y luego desviaciones son tres, cuesta el triple de tokens y la tercera respuesta suele ser peor porque el contexto se ha desviado.
Lee el SQL, al menos una vez
Data Analyst muestra la consulta que ha generado. Léela la primera vez que preguntes algo sobre lo que vayas a actuar.
Compruebas dos cosas: si une lo que esperabas y si el rango de fechas significa lo que crees. De ahí sale la respuesta equivocada con buena pinta. Un total que se desvía un 8 % porque un join descartó filas se ve exactamente igual que un total correcto.
Cuando una consulta esté bien, guárdala. La consulta guardada es la versión en la que confías, y ejecutarla el mes que viene no arrastra el riesgo de que una pregunta reformulada genere otro SQL.
El gráfico es un resumen, no el hallazgo
Elige el tipo de gráfico según la forma de la pregunta: línea para el cambio en el tiempo, barras para comparar categorías, dispersión cuando buscas una relación. Una tarta con nueve porciones no comunica nada y suele ser un gráfico de barras que se rindió.
Y cuando compartas un resultado, comparte la consulta guardada en lugar de una captura del gráfico. El gráfico es la foto de un momento; la consulta sigue respondiendo la pregunta el trimestre que viene.
Preguntas que la gente hace
¿Por qué me salió un número equivocado?
Normalmente la consulta respondió a una pregunta ligeramente distinta: un join que descartó filas, o un término ambiguo como «activo» que el esquema define de otra manera. Lee el SQL generado una vez y la causa suele ser evidente.
¿Cada pregunta consume tokens?
Sí, cada ejecución descuenta de tu saldo de IA, y por eso las preguntas compuestas ganan a preguntar por partes. Las consultas guardadas se reejecutan sin pedirle al modelo que las vuelva a escribir.
¿Puede un compañero ver un resultado sin acceso a la base de datos?
Sí. El compartir es por persona y con control de permisos, así que alguien puede ver la respuesta de una consulta guardada sin tener credenciales de la base de datos.
