Logo GCP con Eduardo

GCP con Eduardo

De 15 Días a 15 Segundos: Arquitectura de Agentes de Datos con BigQuery y LLMs
✦ Guía Técnica & Arquitectura

De 15 Días de Burocracia a 15 Segundos de Inteligencia: Agentes de Datos con BigQuery

El ciclo tradicional de Business Intelligence está roto: tickets en Jira, 50 líneas de SQL manual, exports a CSV y semanas de reuniones antes de tomar una decisión con datos ya obsoletos. Descubre cómo diseñamos una arquitectura multi-agente en Google Cloud para transformar equipos de datos saturados en arquitectos de inteligencia en tiempo real.

Lo que aprenderás en esta guía
Desacoplar al ingeniero de datos como traductor humano entre el negocio y el DW.
Orquestación de agentes con Vertex AI, ADK y BigQuery Conversational API.
Generación y ejecución segura de código Python para análisis y gráficos en streaming.
Mitigación de riesgos FinOps, control de esquemas y sandboxing en producción.
Google Cloud Platform Google BigQuery Vertex AI Gemini 2.5 Flash Agent Development Kit (ADK) Python Code Execution Engine

El Antipatrón del "Ping-Pong de la Muerte" en los Equipos de Datos

En la mayoría de organizaciones, el flujo de respuesta analítica para eventos críticos (como un informe post-Black Friday o el análisis de una caída repentina de facturación) sufre una fricción burocrática insostenible:

  1. Día 1: El equipo de marketing o dirección abre un ticket solicitando métricas de canales y productos.
  2. Día 2: El ingeniero de datos limpia fuentes desconectadas y adapta esquemas modificados.
  3. Día 3: Se envía un archivo Excel o CSV tras escribir manualmente 50 líneas de SQL.
  4. Día 4: El área de negocio solicita excluir devoluciones o agregar una columna adicional. El código vuelve a reescribirse.
  5. Día 5: Negocio solicita comparar los números contra el año anterior. El ciclo se reinicia.

El resultado: 15 días desperdiciados para obtener una respuesta que el negocio necesitaba en 15 minutos. El ingeniero de datos no aporta valor arquitectónico (actúa como un simple robot traductor entre SQL y personas), y el analista de negocio se frustra tomando decisiones basadas en datos desfasados.

Matriz de Decisión Arquitectónica: BI Tradicional vs. Agentes Autónomos

La solución no es copiar y pegar extractos de datos en interfaces de chat comerciales. Requiere integrar modelos de lenguaje con la infraestructura analítica empresarial mediante herramientas de solo lectura, gobernanza y ejecución de código:

Dimensión Flujo Tradicional (Tickets + SQL) Text-to-SQL Básico (Naive RAG) Arquitectura Multi-Agente (ADK + BigQuery)
Tiempo de Respuesta 3 a 15 días laborables 30 a 60 segundos 2 a 15 segundos
Capacidad Analítica Estática (consultas prefijadas) Limitada a SELECT simple Generación SQL + Scripting Python + Visualización
Consistencia de Esquemas Alta (controlada por humanos) Baja (alucinaciones de columnas) Alta (vía Data Source References en BigQuery)
Riesgo FinOps Controlado pero con alto coste humano Alto (posibles full table scans) Controlado (metadatos acotados + particionamiento)
Experiencia de Usuario Burocrática y asíncrona Texto plano no estructurado Conversacional interactiva con gráficos dinámicos
⚠️ Error Crítico: Text-to-SQL directo sin Capa Semántica ni Sandbox

Entregar el esquema DDL completo de un Data Warehouse masivo a un LLM en un prompt sin control provoca dos fallos graves: 1) Alucinación de uniones (JOINs) y métricas al no contar con definiciones canónicas de negocio, y 2) Consultas descontroladas de coste millonario al consultar tablas de billones de filas sin filtrar por las columnas particionadas (`partition_date`). La arquitectura debe delegar el contexto a conectores nativos de analítica conversacional con permisos acotados.

Implementación Práctica: Orquestación Multi-Agente con ADK y BigQuery

A continuación se detalla la implementación modular del agente analítico en Python. El sistema se compone de tres elementos esenciales:

  • Data Sources References: Mapeo canónico de tablas de dimensiones (dim_customers, dim_products, dim_marketing_campaigns) y tablas de hechos (fact_sales, fact_inventory, fact_reviews).
  • BigQuery Conversational Tool: Módulo que traduce lenguaje natural a SQL optimizado contra las tablas referenciadas.
  • Visualization & Routing Agents: Agentes especializados que interpretan los resultados y ejecutan código Python en un sandbox de Vertex AI para renderizar gráficos instantáneos.
import os
from google.cloud import bigquery
from google.adk.agents import Agent, Tool
from google.adk.code_executors import VertexCodeInterpreterExecutor
from google.adk.tools.plugins.bigquery_analytics import (
    BigQueryAgentAnalyticsPlugin,
    BigQueryAgentAnalyticsConfig
)
from google.adk.models import GoogleGenAIModel

# ==========================================
# 1. CONFIGURACIÓN DE ENTORNO Y RECURSOS GCP
# ==========================================
PROJECT_ID = os.getenv("GOOGLE_CLOUD_PROJECT", "data-agent-production")
LOCATION = os.getenv("GOOGLE_CLOUD_LOCATION", "us-central1")
DATASET_ID = os.getenv("BQ_DATASET", "business_dw")

# Modelo de inferencia optimizado para reasoning rápido y bajo coste
model = GoogleGenAIModel(
    model_name="gemini-2.5-flash",
    project_id=PROJECT_ID,
    location=LOCATION
)

# ==========================================
# 2. DEFINICIÓN DE LA CAPA SEMÁNTICA BIGQUERY
# ==========================================
bq_plugin = BigQueryAgentAnalyticsPlugin(
    BigQueryAgentAnalyticsConfig(
        project_id=PROJECT_ID,
        dataset_id=DATASET_ID,
        # Referencias explícitas para evitar escaneo ciego de metadatos
        table_references=[
            f"{PROJECT_ID}.{DATASET_ID}.dim_customers",
            f"{PROJECT_ID}.{DATASET_ID}.dim_products",
            f"{PROJECT_ID}.{DATASET_ID}.dim_marketing_campaigns",
            f"{PROJECT_ID}.{DATASET_ID}.fact_marketing_daily",
            f"{PROJECT_ID}.{DATASET_ID}.fact_transaction_items"
        ]
    )
)

# ==========================================
# 3. AGENTE ANALÍTICO Y GENERADOR DE SQL
# ==========================================
data_agent = Agent(
    name="DataAgent",
    model=model,
    instruction="""
    Eres un analista de datos Senior en BigQuery.
    Tu objetivo es responder consultas de negocio generando y ejecutando SQL optimizado.
    Reglas mandatorias:
    1. Filtra siempre por particiones temporales cuando consultes tablas 'fact_*'.
    2. Realiza agregaciones explícitas y usa GROUP BY en dimensiones requeridas.
    3. Devuelve los resultados en una estructura JSON clara con columnas canónicas.
    """,
    tools=[bq_plugin.get_conversational_tool()]
)

# ==========================================
# 4. AGENTE DE VISUALIZACIÓN Y CÓDIGO
# ==========================================
visualization_agent = Agent(
    name="VisualizationAgent",
    model=model,
    instruction="""
    Eres un experto en Data Visualization con Python.
    Recibes datos analíticos estructurados y generas código con Matplotlib o Seaborn.
    El código debe:
    1. Cargar los datos recibidos en un Pandas DataFrame.
    2. Crear gráficos legibles con títulos claros y etiquetas en ejes.
    3. Exportar o renderizar el gráfico sin requerir librerías externas adicionales.
    """,
    code_executor=VertexCodeInterpreterExecutor(
        project_id=PROJECT_ID,
        location=LOCATION
    )
)

# ==========================================
# 5. AGENTE ORQUESTADOR (ROUTER PRINCIPAL)
# ==========================================
root_agent = Agent(
    name="RootAgent",
    model=model,
    instruction="""
    Orquesta las solicitudes del usuario de negocio.
    Flujo de trabajo:
    1. Si la pregunta requiere datos del DW, invoca a 'DataAgent'.
    2. Si el usuario solicita un gráfico o comparativa visual de los datos obtenidos, 
       delega la tarea a 'VisualizationAgent'.
    3. Resume las conclusiones clave en formato ejecutivo con métricas de negocio.
    """,
    sub_agents=[data_agent, visualization_agent]
)

# Ejemplo de invocación del flujo
if __name__ == "__main__":
    prompt = "¿Cuáles son los 5 canales de marketing con mayor Lifetime Value (CLTV) y su tasa de conversión?"
    response = root_agent.run(prompt)
    print(response.content)

Patrones de Diseño y Mejores Prácticas Empresariales

Para llevar este tipo de agentes a producción en entornos regulados o con grandes volúmenes de datos, es imprescindible aplicar tres principios de diseño:

1. Desacoplamiento de Roles de Agente (Separation of Concerns)

No intentes que un único prompt resuelva la generación de SQL, el análisis matemático y el ploteo visual. Al dividir el sistema en un Data Agent (especializado en semántica de datos y consultas BQ), un Visualization Agent (con acceso a un intérprete de Python seguro) y un Root Agent (orquestador conversacional), se reducen drásticamente los errores y se facilita el testing unitario de cada componente.

2. Ejecución Segura en Sandbox (Zero Trust Code Execution)

El código Python generado dinámicamente por el LLM para manipular dataframes nunca debe ejecutarse directamente en el servidor de la aplicación. Utiliza entornos aislados como el Code Interpreter de Vertex AI o contenedores efímeros de Cloud Run sin salida a internet no autorizada.

3. Gobernanza y Linaje de Datos

Todo el acceso a BigQuery debe regirse mediante cuentas de servicio IAM de privilegios mínimos (roles/bigquery.dataViewer y roles/bigquery.jobUser) sobre vistas autorizadas o conjuntos de datos específicos, impidiendo que el agente acceda a tablas PII o realice mutaciones en los esquemas (DML/DDL destructivo).

Framework de Implementación en 5 Pasos para Empresas

  1. Auditoría de Esquemas Canónicos: Documentar y estandarizar las tablas de dimensiones y hechos en BigQuery Data Catalog con descripciones precisas de columnas.
  2. Creación de Vistas Analíticas Curadas: Crear vistas que unifiquen métricas clave (evitando JOINs complejos en tiempo de prompt) y expongan particiones claras.
  3. Despliegue del Middleware de Agentes (ADK): Configurar el backend en Cloud Run con autenticación federada y políticas de cuotas de tokens.
  4. Habilitación de Intérprete de Código: Conectar el agente de visualización con Vertex AI Code Interpreter para generación de gráficos bajo demanda.
  5. Rollout por Fases con Golden Datasets: Evaluar las respuestas del agente frente a 100 consultas SQL históricas validadas por el equipo de datos antes de abrir el acceso a los usuarios de negocio.
Preguntas Frecuentes de Arquitectura
¿Por qué no usar simplemente Text-to-SQL directo con un prompt estándar?
El Text-to-SQL básico falla en esquemas empresariales complejos porque carece de contexto semántico, validación de sintaxis para BigQuery, manejo seguro de agregaciones y límites FinOps. Una arquitectura multi-agente orquesta la introspección de esquemas, la validación del SQL y la ejecución segura de scripts Python para análisis visuales avanzados sin alucinaciones de nombres de tablas ni full table scans innecesarios.
¿Cómo previene esta arquitectura costes descontrolados en BigQuery?
La integración se realiza a través de capas semánticas intermedias y APIs de analítica conversacional con permisos acotados IAM, pre-filtrando referencias por tablas optimizadas (particionadas y clusterizadas), evitando la ejecución de comodines SELECT * y aplicando límites presupuestarios por consulta mediante cuotas en GCP.
¿Cómo interactúa el usuario de negocio con los datos sin comprometer la seguridad?
El usuario envía solicitudes en lenguaje natural mediante interfaces controladas (como Agent Development Kit UI). El agente orquestador rutea la consulta, invoca herramientas de solo lectura parametrizadas, procesa los dataframes en un intérprete aislado de código Python en sandbox y retorna métricas y visualizaciones sin exponer credenciales de producción ni acceso directo de escritura al Data Warehouse.