En mi último artículo, Muchas empresas utilizan la IA. Pocos saben cómo construir una plataforma de datos empresariales nativa de IA. Hablé sobre cómo integrar la IA en las plataformas de datos empresariales. También compartí problemas comunes en la práctica con respecto a las aplicaciones de IA en los flujos de trabajo de ingeniería de datos y cómo resolverlos. En ese artículo, expliqué tres elementos clave de una arquitectura práctica de IA empresarial: agentes de datos, control de calidad impulsado por IA y gobernanza de IA.
Para profundizar en los datos de los agentes, creé una demostración llamada Avocado Sales Analytics Agent. En este artículo, recorreré el proceso completo de construcción paso a paso.
¿Qué es un agente de datos?
Un agente de datos es una interfaz conversacional impulsada por IA que permite a los usuarios empresariales hacer preguntas en un lenguaje sencillo y recibir respuestas precisas consultando los datos almacenados en un almacén de datos.
En lugar de esperar a que los analistas de datos escriban consultas SQL complejas y generen informes, los usuarios pueden simplemente escribir: "¿A cuánto ascendió el TPV total en el sudeste asiático el año pasado?" y obtenga una respuesta inmediata como “60 mil millones de dólares”.
Elegir el enfoque correcto
Hay dos formas de crear un agente de datos. El primer enfoque es construir desde cero con marcos de orquestación de código abierto como LangGraph/LangChain, CrewAI y LlamaIndex. Con este enfoque, usted tiene control total sobre las estructuras de memoria del agente, reglas estrictas de lógica de negocios y ciclos complejos de ejecución de múltiples agentes.
Para los principiantes, el segundo enfoque de implementar un agente de datos dentro de plataformas de datos en la nube es más práctico y rápido de implementar. Hoy en día, la mayoría de las principales plataformas de datos en la nube ofrecen agentes de datos nativos y listos para usar. Por ejemplo, Snowflake ofrece agentes Snowflake Cortex, que son canales de agentes de código bajo completamente alojados dentro de Snowflake y permiten a los usuarios hacer preguntas en lenguaje natural directamente a través de almacenes de datos empresariales seguros a través de Snowflake Intelligence. Databricks Genie es la herramienta administrada de inteligencia de datos conversacionales dentro del ecosistema de Databricks. Microsoft Fabric Ecosystem tiene Fabric Data Agents que admiten conexiones de datos directas a lagos, almacenes, bases de datos KQL y modelos semánticos de Power BI.
Para crear la demostración del Avocado Sales Analytics Agent, elegí Google Cloud Platform (BigQuery) porque brinda acceso completo a sus funciones de Conversational Analytics durante la prueba gratuita y se puede configurar fácilmente usando una cuenta personal de Google. Para los datos de origen, utilicé el conjunto de datos de precios de aguacate de Kaggle. El conjunto de datos fue publicado por Justin Kiggins utilizando datos del Hass Avocado Board y está disponible bajo la licencia CC BY 4.0.
Construyendo un agente de datos sin código
BigQuery de Google Cloud proporciona la API de análisis conversacional, que nos permite crear agentes de datos conversacionales sobre conjuntos de datos de BigQuery. Antes de crear el agente de datos, el primer paso es descargar el archivo csv de Avocado Prices de Kaggle y subirlo a BigQuery. Después de cargar el conjunto de datos, es muy importante comprender el esquema de datos de las tablas que se utilizan para crear el agente porque el agente necesita comprender el modelo de datos, incluidos los nombres de las tablas, los nombres de las columnas, los tipos de datos, las relaciones y los significados comerciales. Debe comprender los datos a fondo antes de "enseñar" al agente cómo analizarlos correctamente.
El siguiente paso es construir el agente de datos. Puede navegar a BigQuery-> Agente, hacer clic en "Crear agente" y luego ingresar el nombre y la descripción del agente antes de seleccionar su conjunto de datos como fuente de conocimiento.
Las instrucciones son la parte más crítica porque guían a la IA para consultar los datos correctamente, evitar errores y dar respuestas precisas.
Estos son los principios para escribir buenas instrucciones:
Sea claro: utilice un lenguaje sencillo y preciso. No utilice frases duras o vagas. Dé ejemplos: muestre al agente cómo son las buenas consultas y respuestas. Establecer límites: especificar lo que el agente debe y no debe hacer. Defina el rol: describa claramente quién es el agente y quiénes son los usuarios.
A continuación se muestra el ejemplo de las instrucciones que escribí para los datos del aguacate.
El agente tiene acceso a una tabla principal de BigQuery para responder preguntas sobre precios y ventas de aguacate. Todas las respuestas deben derivarse consultando esta tabla: A. Definiciones de la tabla y de las columnas principales: Clave principal: int64_field_0 (identificador de fila implícito) Columnas clave: Fecha (DATE): La semana de los datos de ventas región (STRING): región de EE. UU. donde se produjeron las ventas (incluye ciudades, por ejemplo, Albany, Atlanta, California, Chicago, etc., regiones, por ejemplo, Oeste y USTotal) tipo (STRING): tipo de aguacate, ya sea "convencional" o año "orgánico" (INTEGER): Año de los datos Precio Promedio (FLOAT): Precio promedio de un solo aguacate en USD Volumen Total (FLOAT): Volumen total de aguacates vendidos Total Bolsas (FLOAT): Número total de bolsas de aguacate vendidas Bolsas Pequeñas (FLOAT): Volumen de ventas de bolsas pequeñas (en unidades) Bolsas Grandes (FLOAT): Volumen de ventas de bolsas grandes (en unidades) Bolsas XLarge (FLOAT): Volumen de ventas de bolsas extra grandes (en unidades) 4046 (FLOAT): Volumen de ventas por PLU 4046 (aguacates pequeños) 4225 (FLOAT): Volumen de ventas para PLU 4225 (aguacates grandes) 4770 (FLOAT): Volumen de ventas para PLU 4770 (aguacates extra grandes) B. Reglas de cálculo de métricas Cuando un usuario solicita una métrica, use estas reglas SQL: Ingresos totales por ventas (USD) SUM(Volumen total * Precio promedio) Precio promedio ponderado SUM(Volumen total * Precio promedio) / SUM(Volumen Total): Este es el precio promedio por aguacate, ponderado por el volumen de ventas. Total de aguacates individuales vendidos SUM(Volumen total) Total de bolsas vendidas SUM(Total de bolsas) Desglose del tamaño de la bolsa SUM(Bolsas pequeñas), SUM(Bolsas grandes), SUM(Bolsas extragrandes) Volumen específico de PLU SUM(4046), SUM(4225), SUM(4770) C. Reglas de manejo de fechas Utilice siempre la columna Fecha para filtrar y agrupar según el tiempo. Para consultas del "último año", utilice el año calendario anterior según los datos actuales. "último mes" o "último trimestre", calcule en función de la última fecha de los datos Al agrupar por tiempo: Semanal: Agrupar por fecha Mensual: Agrupar por DATE_TRUNC(Fecha, MES) Trimestral: Agrupar por DATE_TRUNC(Fecha, TRIMESTRE) Anual: Agrupar por año D. Consultas (Preguntas de ejemplo) Aquí hay preguntas de ejemplo y sus consultas SQL correspondientes para guiar al agente: 1.Lenguaje natural: "¿Cuántas bolsas totales de aguacates se vendieron en Chicago en 2017?" SQL: SELECCIONE SUM(Total de bolsas) como total_bags FROM avocado_data WHERE región = 'Chicago' AND año = 2017 2. Lenguaje natural: "¿Cuál fue el precio promedio del aguacate en California en 2017?" SQL: SELECCIONE SUMA(Volumen total * Precio promedio) / SUMA(Volumen total) como precio_promedio ponderado DESDE precios_aguacate DONDE región = 'California' Y año = 2017 E. Notas sobre la calidad de los datos Los datos incluyen tipos de aguacate tanto convencionales como orgánicos. Es fundamental distinguir entre "volumen" (aguacates individuales) y "bolsas". Si un usuario pregunta por “ventas totales”, aclarar si se refiere a unidades (aguacates) o bolsas. Si no está claro, suele ser más seguro denunciar ambas cosas o pedir una aclaración. Para cualquier cálculo de precios, utilice siempre la fórmula del promedio ponderado (SUM(Volumen total * Precio promedio) / SUM(Volumen total)) al agregar varios registros. F. Errores comunes que se deben evitar NO utilice AVG (Precio promedio) para cálculos de precios agregados. Utilice siempre la fórmula del promedio ponderado. No confunda Volumen Total (aguacates individuales) con Bolsas Totales. Al comparar regiones, asegúrese de utilizar el mismo período de tiempo. Para comparaciones orgánicas versus convencionales, incluya siempre el tipo en la cláusula GROUP BY. G. Nota sobre la calidad de los datos geográficos La columna de región contiene varios niveles geográficos superpuestos (ciudades, regiones estatales y "TotalUS"). NO sume ni agregue datos de estos diferentes tipos de regiones. Una consulta como SUM(Volumen total) GROUP BY región producirá un resultado, pero la suma de todas las regiones no será igual a un total significativo debido a la superposición de datos. Cuando un usuario haga una pregunta, trate la región como un filtro único y categórico (por ejemplo, WHERE región = 'California'). Si un usuario solicita un "total nacional", utilice la región específica 'TotalUS' (por ejemplo, WHERE región = 'TotalUS'). Esta es la única manera correcta de obtener un agregado nacional. Nunca intente sumar valores de diferentes regiones para crear un nuevo total. Esto conducirá a resultados inexactos debido a la jerarquía superpuesta.
Para ayudar al agente a mejorar la comprensión de los datos y las mejores prácticas para consultarlos, el siguiente paso es escribir las consultas verificadas. Las consultas verificadas enseñan al agente cómo generar SQL correcto y responder preguntas de manera consistente.
La captura de pantalla anterior muestra un ejemplo de una consulta verificada. Le guió al agente sobre cómo calcular el precio promedio del aguacate en California en 2017. Sin esta consulta verificada, el agente haría un promedio simple del Precio Promedio, lo cual es incorrecto.
Construyendo la aplicación de chat
Para los usuarios que no tienen acceso a BigQuery, la solución más sencilla es crear una aplicación Flask liviana que se comunique con la API de análisis conversacional. La aplicación está construida con el micromarco Flask en Python.
avocado-agent-app/ ├── app.py ├── requisitos.txt ├── .env ├── clave-cuenta-servicio.json └── plantillas/ └── index.html
Configuración del entorno
Al crear la aplicación, debe almacenar sus credenciales en un archivo .env. Debe especificar el punto final de la API con LOCATION e identificar dónde se creó el agente con AGENT_LOCATION. A continuación se muestra la plantilla para crear un archivo .env.
GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json PROJECT_ID=project-avocado-xxxxxx LOCATION=global AGENT_LOCATION=us AGENT_ID=agent_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Autenticación
Cuando la aplicación llama a la API de análisis conversacional, debe autenticarse con la clave de la cuenta de servicio en Google para que Google pueda verificar la firma de la clave y verificar los permisos asociados. Con una clave válida, Google puede otorgar a la aplicación acceso a recursos como tablas de BigQuery y el agente. Puede crear una nueva clave en IAM y Administrador de Google Cloud Console y descargar el archivo JSON.
Inicialización del agente y flujo de chat
Ahora puede configurar la conexión entre la aplicación y la API de análisis conversacional de Google Cloud mediante la inicialización del agente. Durante esta fase, debes importar la biblioteca de Google Cloud, crear un objeto de cliente que pueda comunicarse con la API y definir la ruta del agente.
desde google.cloud import geminidataanalytics client = geminidataanalytics.DataChatServiceClient() def get_agent_path(): return f"projects/{PROJECT_ID}/locations/{AGENT_LOCATION}/dataAgents/{AGENT_ID}"
Luego, puede crear una sesión de chat que recuerde el contexto de varias preguntas. Una conversación es como un contenedor que contiene todo el historial del chat, el contexto del agente y el estado actual de la interacción.
conversación = geminidataanalytics.Conversación( agentes=[ruta_agente] ) recurso_conversación = cliente.create_conversación( padre=f"proyectos/{PROJECT_ID}/ubicaciones/{LOCATION}", conversación=conversación )
La interacción principal es enviar la pregunta del usuario al agente y recibir la respuesta.
convo_ref = geminidataanalytics.ConversationReference() convo_ref.conversation = id_conversación convo_ref.data_agent_context.data_agent = ruta_agente chat_request = geminidataanalytics.ChatRequest( parent=f"proyectos/{PROJECT_ID}/ubicaciones/{LOCATION}", mensajes=[geminidataanalytics.Message( mensaje_usuario={'texto': mensaje_usuario} )], referencia_conversación=convo_ref, ) respuestas =[]para respuesta en client.chat(chat_request): if hasattr(respuesta, 'texto') y respuesta.texto: respuestas.append(respuesta.texto)
Filtrado de respuestas
De forma predeterminada, la API devuelve razonamiento intermedio como respuestas system_message. Por ejemplo, cuando envié la pregunta "¿Cuál es el volumen total vendido en Albany en 2015?" al agente. En lugar de mostrar la respuesta final, devolvió todo su proceso de pensamiento, incluidos los mensajes del sistema y los pasos intermedios.
marca de tiempo { segundos: 1785482359 nanos: 260881000 } system_message { texto { partes: "Analizando contexto" partes: "Contexto recuperado para 1 tabla". text_type: THOUGHT } } timestamp { segundos: 1785482363 nanos: 449760000 } system_message { text { parts: "Respondiendo a la consulta "Volumen total de Albany 2015"" parts: "Muy bien, el usuario quiere saber el volumen total de algo vendido en Albany durante 2015. Mi primer paso es identificar la fuente de datos relevante y columnas. Tengo acceso a una tabla llamada `project-avocado-xxxxxx.avocado_data.avocado`. Al mirar el esquema (o recordarlo de experiencias anteriores), veo una columna llamada `Total Volume` que es de tipo FLOAT.
Para solucionar este problema, debe filtrar los mensajes con text_type == 1 (PENSAMIENTO) y conservar solo los mensajes con text_type == 2 (FINAL_RESPONSE).
Subí el código completo en GitHub. El repositorio contiene los siguientes archivos clave:
app.py: la aplicación Flask completa con todas las rutas templates/index.html: la interfaz de chat con un diseño limpio y fácil de usar requisitos.txt: todas las dependencias de Python
Flujo de trabajo completo
El flujo completo para Avocado Sales Analytics Agent es:
┌──────────────────────────────── ─────────────────────────────────┐ │ EL USUARIO HACE UNA PREGUNTA │ │ "¿Cuál es el volumen total en │ │ Albany en 2015?" │ └─────────────────────────────┬── ─────────────────────────────────┘ │ ▼ ┌──────────────────────────────── ─────────────────────────────────┐ │ 1. INICIALIZACIÓN DEL AGENTE (Configuración) │ │ – El cliente se conecta a la API de Google Cloud │ │ – Se construye la ruta del agente │ └─────────────────────────────┬── ─────────────────────────────────┘ │ ▼ ┌──────────────────────────────── ─────────────────────────────────┐ │ 2. GESTIÓN DE LA CONVERSACIÓN (Sesión) │ │ ┌──────────────────────────── ─────────────────────────────┐ │ │ │ ¿Es esta una nueva conversación? │ │ │ │ ├─ SÍ → Crear nueva conversación, obtener ID │ │ │ │ └─ NO → Usar ID de conversación existente │ │ │ └──────────────────────────── ─────────────────────────────┘ │ └─────────────────────────────┬── ─────────────────────────────────┘ │ ▼ ┌──────────────────────────────── ─────────────────────────────────┐ │ 3. ENVIAR SOLICITUD DE CHAT (Ejecución) │ │ – Paquete: pregunta + ID de conversación + ruta del agente │ │ – Enviar a la API de Google │ │ ┌──────────────────────────── ─────────────────────────────┐ │ │ │ Procesamiento de Google (detrás de escena): │ │ │ │ ├─ Analizar pregunta → Comprender la intención │ │ │ │ ├─ Generar SQL → SELECT SUM(`Total Volume`) … │ │ │ │ ├─ Ejecutar consulta → Ejecutar contra BigQuery │ │ │ │ └─ Formatear respuesta → "4.029.896,43" │ │ │ └──────────────────────────── ─────────────────────────────┘ │ └─────────────────────────────┬── ─────────────────────────────────┘ │ ▼ ┌──────────────────────────────── ─────────────────────────────────┐ │ MOSTRAR RESPUESTA AL USUARIO │ │ "El volumen total en Albany en 2015 │ │ fue de 4.029.896,43 aguacates individuales". │ └──────────────────────────────── ─────────────────────────────────┘
Pensamientos finales
Los agentes de datos son muy útiles para reducir la carga de trabajo de los equipos de datos, mejorar la productividad organizacional y cerrar de manera efectiva la brecha entre los usuarios comerciales y los equipos de datos.
El agente de Avocado Sales Analytics puede completar el siguiente flujo de trabajo:
Analizar las preguntas en lenguaje natural -> Generar la consulta SQL adecuada -> Ejecutar la consulta en BigQuery -> Devolver una respuesta en inglés simple con los datos
limitaciones en las siguientes áreas:
Mejor comprensión semántica de la terminología empresarial Contexto empresarial más rico a través de contenedores de contexto reutilizables Conversaciones más naturales y humanas Mejor soporte para preguntas analíticas complejas
En un artículo siguiente, le mostraré cómo utilizar el SDK para crear contenedores de contexto reutilizables que empaqueten reglas comerciales, definiciones y consultas doradas para escenarios más complejos.
¡Gracias por tu lectura!
¡Cómprame un café si te gusta este artículo!