Haz un seguimiento de las decisiones del agente de IA con BigQuery Graph

1. Introducción

BigQuery Graph, BigQuery Conversational Analytics y el SDK de BigQuery Agent Analytics se encuentran actualmente en versión preliminar en Google Cloud. El complemento de análisis de agentes de BigQuery está disponible de forma general (GA). Los ejemplos de este codelab usan datos sintéticos.

A medida que los agentes autónomos de IA asumen más responsabilidades operativas (evaluar solicitudes de préstamos, administrar presupuestos de marketing, aprobar solicitudes de acceso), las organizaciones deben poder auditar y explicar sus decisiones. Reconstruir el contexto exacto, las alternativas consideradas y la justificación final de la decisión de un agente es fundamental para el cumplimiento, la administración de riesgos y la confianza operativa.

En este codelab, se usa el SDK de Analytics de BigQuery Agent para transformar los registros de eventos del agente sin procesar en un gráfico de contexto del agente, un gráfico consultable en BigQuery Graph de las decisiones del agente, según una programación, sin ninguna base de datos de gráficos externa ni canalización de ETL.

Términos clave

  • Agent Decision Trace: Es la evidencia a nivel de la decisión que se extrae de las propias ejecuciones de un agente: las opciones que consideró, los datos que consultó y el resultado que confirmó.
  • Gráfico de contexto del agente: Es el gráfico con tipos y consultable en BigQuery Graph en el que se materializan esos registros. Es la instancia con alcance del agente del concepto de gráfico de contexto de la industria (la capa duradera y vinculada al tiempo del contexto de decisión que los agentes producen y consumen); el calificador "Agente" lo limita a las ejecuciones de tus propios agentes en lugar de una capa de contexto en toda la empresa.

En este codelab, bqaa context-graph extrae los registros de decisiones del agente de tu agent_events y los materializa en un gráfico de contexto del agente que puedes consultar con GQL, siguiendo el patrón de la industria en el que los gráficos de contexto se compilan a partir de los registros de decisiones.

Flujo de trabajo del gráfico de contexto del agente: Los eventos de un agente del ADK fluyen a través del complemento de análisis de agentes de BigQuery hacia la tabla agent_events, el gráfico de contexto de bqaa extrae los registros de decisiones del agente en un gráfico de contexto del agente estructurado y tú lo consultas con GQL y Conversational Analytics.

Qué compilarás

  • Un gráfico de contexto del agente (con BigQuery Graph) que modela un flujo genérico de decisiones del agente: llega una solicitud, el agente sopesa las opciones y se confirma un resultado.
  • Una tabla agent_events completada con un corpus de eventos sintéticos.
  • Una ejecución de bqaa context-graph que funciona y que completa el gráfico a partir de esos eventos.
  • Es una consulta de GQL de estilo de auditoría que rastrea una sola decisión de extremo a extremo.

Qué aprenderás

  • Cómo el complemento de análisis de agentes de BigQuery escribe en agent_events
  • Cómo se define un gráfico de contexto con solo dos artefactos declarativos: un DDL de tabla y un esquema CREATE PROPERTY GRAPH
  • Cómo ejecutar bqaa context-graph en un gráfico de BigQuery
  • Cómo consultar un gráfico con GQL
  • Son las capacidades de nivel de producción que admite el SDK para las implementaciones empresariales.

Requisitos

  • Un proyecto de Google Cloud con facturación habilitada.
  • Rol de propietario o editor en ese proyecto Crearás un conjunto de datos de BigQuery y otorgarás IAM.
  • La CLI de gcloud instalada y autenticada, o acceso a Cloud Shell
  • Python 3.10 o una versión posterior
  • Conocimiento de BigQuery SQL No se requieren conocimientos de GQL.

Este codelab es para desarrolladores de todos los niveles, incluidos los que no conocen BigQuery Graph.

Los recursos creados en este codelab cuestan muy poco, y el paso final descompone todo para que no se te facture por un conjunto de datos inactivo.

Duración estimada: Completar este codelab lleva aproximadamente 35 minutos.

2. Antes de comenzar

Elige un proyecto y una región

Abre Cloud Shell o una terminal local:

export PROJECT_ID="your-project-id"
export REGION="us-central1"
export DATASET="agent_analytics_demo"
gcloud config set project "$PROJECT_ID"

La única variable DATASET contiene tanto la tabla agent_events sin procesar como las tablas de grafos materializadas. Usar un solo conjunto de datos mantiene el codelab simple. Las implementaciones de producción suelen dividir los eventos y los gráficos en conjuntos de datos separados para que IAM se pueda otorgar de forma limitada por conjunto de datos.

Habilite las API necesarias

Ejecuta el siguiente comando para habilitar las APIs que usa este codelab:

gcloud services enable \
    bigquery.googleapis.com \
    aiplatform.googleapis.com \
    --project="$PROJECT_ID"

Se requiere la API de aiplatform.googleapis.com porque la ruta de extracción predeterminada del SDK llama a la función AI.GENERATE de BigQuery. Si más adelante cambias a la extracción determinística con --extraction-mode=compiled-only, ya no necesitarás esta API.

Crea el conjunto de datos de BigQuery

Crea el conjunto de datos que contendrá la tabla agent_events sin procesar y las tablas de gráficos materializados:

bq --location=US mk --dataset "$PROJECT_ID:$DATASET"

Deberías ver un mensaje de éxito:

Dataset 'your-project-id:agent_analytics_demo' successfully created.

Si el conjunto de datos ya existe, el comando genera un error inofensivo. Déjalo en su lugar.

3. Cómo instalar el SDK

Configura un entorno virtual de Python y instala el SDK desde PyPI:

python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install bigquery-agent-analytics

El paquete bigquery-agent-analytics incorpora la biblioteca cliente de BigQuery, por lo que esta es la única instalación que necesitas para todo el codelab.

Verifica la instalación:

bqaa context-graph --help | head -8

Deberías ver el banner de la CLI.

Autenticar

Si estás en una estación de trabajo, haz lo siguiente:

gcloud auth login
gcloud auth application-default login

Los usuarios de Cloud Shell pueden omitir este paso, ya que las credenciales ya están configuradas.

4. Obtén los artefactos del codelab

El codelab solo necesita dos artefactos listos para usar: el DDL de la tabla (las tablas de gráficos físicos) y el esquema de gráfico de propiedades (CREATE PROPERTY GRAPH). No los crearás tú mismo; el codelab los usa tal como están, y el README en la carpeta de artefactos explica cómo adaptarlos a tu propio dominio de decisión.

El esquema del gráfico de propiedades es la única fuente de información sobre qué contiene el gráfico. Solo debes aplicarlo a BigQuery una vez, y, a partir de ese momento, el gráfico implementado en sí es el contrato. Cuando materializas, bqaa context-graph lee la definición del gráfico desde INFORMATION_SCHEMA.PROPERTY_GRAPHS de BigQuery (junto con los esquemas de las tablas a las que hace referencia) para determinar qué entidades y relaciones extraer y dónde escribirlas, por lo que nunca se pasa un archivo SQL al materializador.

Este codelab es independiente, por lo que no es necesario descargar nada. El siguiente comando escribe el DDL del gráfico de contexto en un directorio de trabajo. Su contenido es idéntico al de los artefactos incluidos en examples/context_graph/codelab/.

Crea el directorio de trabajo:

mkdir -p ~/context-graph-codelab
cd ~/context-graph-codelab

Escribe el DDL del gráfico de contexto (context_graph_ddl.sql). Los marcadores ${PROJECT_ID} / ${DATASET} se completan cuando aplicas el archivo en el siguiente paso.

cat > context_graph_ddl.sql <<'SQL'

-- Node and edge table DDL for the context-graph codelab.
--
-- `bqaa context-graph` writes into these tables on every run.
-- `session_id` and `extracted_at` are SDK metadata columns that
-- `bqaa context-graph` fills automatically; they are required on
-- every table behind the graph.
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.decision_request` (
  request_id STRING, request_text STRING, requested_at TIMESTAMP,
  session_id STRING, extracted_at TIMESTAMP
);
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.decision_option` (
  option_id STRING, option_label STRING, confidence FLOAT64,
  session_id STRING, extracted_at TIMESTAMP
);
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.decision_outcome` (
  outcome_id STRING, status STRING, rationale STRING, decided_at TIMESTAMP,
  session_id STRING, extracted_at TIMESTAMP
);
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.evaluates_option` (
  request_id STRING, option_id STRING,
  session_id STRING, extracted_at TIMESTAMP
);
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.resulted_in` (
  request_id STRING, outcome_id STRING,
  session_id STRING, extracted_at TIMESTAMP
);

-- Graph DDL for the context-graph codelab.
--
-- Models a generic agent decision flow:
--   DecisionRequest -> evaluatesOption -> DecisionOption
--   DecisionRequest -> resultedIn       -> DecisionOutcome
CREATE OR REPLACE PROPERTY GRAPH `${PROJECT_ID}.${DATASET}.agent_decisions_graph`
  NODE TABLES (
    `${PROJECT_ID}.${DATASET}.decision_request` AS decision_request
      KEY (request_id)
      LABEL DecisionRequest PROPERTIES (request_id, request_text, requested_at),
    `${PROJECT_ID}.${DATASET}.decision_option` AS decision_option
      KEY (option_id)
      LABEL DecisionOption PROPERTIES (option_id, option_label, confidence),
    `${PROJECT_ID}.${DATASET}.decision_outcome` AS decision_outcome
      KEY (outcome_id)
      LABEL DecisionOutcome PROPERTIES (outcome_id, status, rationale, decided_at)
  )
  EDGE TABLES (
    `${PROJECT_ID}.${DATASET}.evaluates_option` AS evaluates_option
      KEY (request_id, option_id)
      SOURCE KEY (request_id) REFERENCES decision_request (request_id)
      DESTINATION KEY (option_id) REFERENCES decision_option (option_id)
      LABEL evaluatesOption,
    `${PROJECT_ID}.${DATASET}.resulted_in` AS resulted_in
      KEY (request_id, outcome_id)
      SOURCE KEY (request_id) REFERENCES decision_request (request_id)
      DESTINATION KEY (outcome_id) REFERENCES decision_outcome (outcome_id)
      LABEL resultedIn
  );
SQL

Confirma que el archivo esté en su lugar:

ls

Deberías ver un archivo:

context_graph_ddl.sql

El flujo de decisiones que describen tiene tres tipos de nodos y dos bordes heterogéneos:

Esquema del gráfico para el codelab: Un nodo DecisionRequest se vincula a través de bordes evaluatesOption a los nodos DecisionOption que ponderó y a través de un borde resultedIn al DecisionOutcome confirmado.

DecisionRequest es la pregunta que recibió el agente. DecisionOption es una alternativa que consideró el agente. DecisionOutcome registra la elección confirmada y su justificación.

5. Aplica el esquema del gráfico de propiedades

bqaa context-graph escribe en tablas de BigQuery, por lo que deben existir antes de la primera ejecución. context_graph_ddl.sql primero crea las cinco tablas y, luego, el grafo de propiedades que las referencia (BigQuery rechaza un CREATE PROPERTY GRAPH que apunta a tablas que aún no existen), por lo que una sola aplicación configura todo:

envsubst < context_graph_ddl.sql | bq query --use_legacy_sql=false

Deberías ver cinco resultados de CREATE TABLE y un resultado de CREATE PROPERTY GRAPH. El DDL es idempotente, por lo que puedes volver a ejecutarlo de forma segura.

Ese es el único trabajo de esquema que realizas, y la única vez que se usan estos archivos SQL. Ahora BigQuery registra la definición de tu gráfico, y bqaa context-graph la lee de INFORMATION_SCHEMA.PROPERTY_GRAPHS por nombre. No hay un archivo separado para pasar al materializador, y lo que consultas con GQL y lo que se materializa nunca pueden separarse: son el mismo gráfico implementado.

6. Genera eventos de muestra del agente

En producción, el complemento de análisis de agentes de BigQuery capta eventos automáticamente a medida que se ejecuta tu agente de ADK. Este fragmento es solo para referencia. No lo ejecutes en este codelab:

from google.adk.plugins import BigQueryAgentAnalyticsPlugin

plugin = BigQueryAgentAnalyticsPlugin(
    project_id="your-project-id",
    dataset_id="agent_analytics_demo",
)
runner = Runner(agent=root_agent, plugins=[plugin])

En este codelab, usarás un pequeño generador de eventos sintéticos que escribe la misma forma de filas directamente en agent_events. Ejecútalo:

bqaa seed-events \
    --project-id "$PROJECT_ID" \
    --dataset-id "$DATASET" \
    --sessions 5

El comando imprime un informe en formato JSON. Para 5 sesiones, deberías ver "events_generated": 30, "events_inserted": 30 y "ok": true.

Obtén una vista previa del corpus de un vistazo (cuántas sesiones, cuántos eventos y el período que abarcan) en una sola fila:

bq query --use_legacy_sql=false \
    "SELECT COUNT(DISTINCT session_id) AS sessions, COUNT(*) AS events, MIN(timestamp) AS earliest_event, MAX(timestamp) AS latest_event FROM \`$PROJECT_ID.$DATASET.agent_events\`"

Para la ejecución predeterminada de 5 sesiones, se muestran 5 sesiones y 30 eventos que abarcan unos minutos. (Genera el siguiente escenario realista y la misma búsqueda informa alrededor de 100 sesiones en aproximadamente tres días).

Verifica que los eventos se hayan registrado:

bq query --use_legacy_sql=false \
    "SELECT event_type, COUNT(*) AS n FROM \`$PROJECT_ID.$DATASET.agent_events\` GROUP BY event_type ORDER BY n DESC"

Deberías ver 25 filas de TOOL_COMPLETED y 5 filas de AGENT_COMPLETED (cada sesión emite un submit_request, tres evaluate_option, un commit_outcome y un AGENT_COMPLETED de cierre, es decir, cinco eventos de la herramienta más un terminador del agente por sesión). Las filas de AGENT_COMPLETED son los terminadores de sesión en los que se basa bqaa context-graph para la detección de eventos terminales.

Opcional: Datos a escala realista

El corpus de 5 sesiones anterior es intencionalmente pequeño para que la primera ejecución sea rápida y económica. Cuando desees datos con forma de producción (varios agentes y usuarios distribuidos en varios días, con sesiones fallidas, huérfanas y truncadas), usa la situación decision-realistic. De forma predeterminada, se establece en 100 sesiones en un período de 72 horas. La ruta de acceso de la primera ejecución anterior no cambia.

bqaa seed-events \
    --project-id "$PROJECT_ID" \
    --dataset-id "$DATASET" \
    --scenario decision-realistic \
    --sessions 100 \
    --seed 42

El session_outcome_counts del informe JSON muestra la combinación, aproximadamente {"success": 70, "failed": 10, "orphaned": 10, "truncated": 10}.

Confirma la distribución de resultados clasificando cada sesión a partir de sus filas (huérfana = sin AGENT_COMPLETED; fallida = AGENT_COMPLETED con status = 'error'; truncada = cualquier fila con is_truncated = true; de lo contrario, exitosa). En un primer paso, se clasifica cada sesión y, luego, en un segundo paso, se agregan los datos por resultado:

bq query --use_legacy_sql=false \
    "WITH per_session AS (SELECT session_id, CASE WHEN COUNTIF(event_type = 'AGENT_COMPLETED') = 0 THEN 'orphaned' WHEN COUNTIF(event_type = 'AGENT_COMPLETED' AND status = 'error') > 0 THEN 'failed' WHEN COUNTIF(is_truncated) > 0 THEN 'truncated' ELSE 'success' END AS outcome FROM \`$PROJECT_ID.$DATASET.agent_events\` GROUP BY session_id) SELECT outcome, COUNT(*) AS sessions FROM per_session GROUP BY outcome ORDER BY outcome"

Deberías ver aproximadamente 70 éxitos, 10 errores, 10 huérfanos y 10 truncados (además de las 5 sesiones exitosas del corpus de la primera ejecución si lo inicializaste antes en el mismo conjunto de datos).

Las 10 sesiones huérfanas nunca emitieron AGENT_COMPLETED, por lo que la ejecución predeterminada de bqaa context-graph las omite (solo materializa las sesiones cerradas por eventos terminales). Para que aparezcan como session_orphaned en lugar de volver a intentarlo de forma silenciosa para siempre, agrega --max-session-age-hours cuando lo ejecutes. Consulta --max-session-age-hours en Llévalo a producción.

7. Materializa el gráfico de contexto

bqaa context-graph lee el agent_events sin procesar y, luego, deriva qué extraer directamente de tu gráfico implementado: lee la definición de CREATE PROPERTY GRAPH que aplicaste en Aplica el esquema del gráfico de propiedades desde el INFORMATION_SCHEMA.PROPERTY_GRAPHS de BigQuery, la une con los esquemas de las tablas a las que hace referencia, determina las entidades, las relaciones y los tipos de columnas, y propaga las tablas del gráfico. Apunta al gráfico implementado por nombre con --graph agent_decisions_graph. No hay ningún archivo SQL para pasar.

Ejecutar

bqaa context-graph de forma local:

bqaa context-graph \
    --project-id "$PROJECT_ID" \
    --dataset-id "$DATASET" \
    --graph agent_decisions_graph \
    --lookback-hours 24 \
    --format json

Deberías ver un informe JSON estructurado:

{
  "run_id": "...",
  "sessions_discovered": 5,
  "sessions_materialized": 5,
  "sessions_failed": 0,
  "rows_materialized": {
    "DecisionRequest": 5,
    "DecisionOption": 15,
    "DecisionOutcome": 5
  },
  "ok": true
}

ok: true indica que bqaa context-graph encontró cinco sesiones completadas, extrajo el flujo de decisiones de cada una a través de AI.GENERATE y escribió las filas correspondientes en las tablas del gráfico. La extracción determinística (--extraction-mode=compiled-only, que se explica a continuación) devuelve la misma forma del informe (los mismos campos, el mismo ok: true), solo que omite las llamadas AI.GENERATE.

Solución de problemas: Extracción vacía

Si ves ok: false con error_code = "empty_extraction", la causa más común es que la API de aiplatform.googleapis.com aún no se propagó o que a tu cuenta le falta roles/aiplatform.user. Espera un minuto y vuelve a intentarlo, o bien otorga el rol:

USER_EMAIL=$(gcloud auth list --filter=status:ACTIVE --format="value(account)")
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
    --member="user:$USER_EMAIL" --role="roles/aiplatform.user"

Luego, vuelve a ejecutar el comando bqaa context-graph anterior.

Verifica que el gráfico tenga filas:

bq query --use_legacy_sql=false \
    "SELECT COUNT(*) AS n FROM \`$PROJECT_ID.$DATASET.decision_request\`"

Deberías ver cinco filas. En las cinco sesiones, hay 25 nodos de gráficos en total: 5 DecisionRequest, 15 DecisionOption y 5 DecisionOutcome, unidos por 15 bordes evaluatesOption y 5 bordes resultedIn (una red de decisiones por sesión).

Dos formas de extraer decisiones de los eventos

bqaa context-graph ofrece dos rutas de extracción. Elige la que coincida con tu carga de trabajo:

  • Extracción predeterminada. El camino más fácil Usa AI.GENERATE de BigQuery para leer el contenido de los eventos y, luego, inferir entidades y relaciones. Funciona con cualquier forma de evento sin código adicional. Esto es lo que usa el codelab.
  • Extracción determinística (--extraction-mode=compiled-only): Es la ruta más económica y apta para auditorías. Usa un pequeño extractor de referencias de Python que escribes una vez para tu dominio. Sin llamadas a Vertex AI, sin cargos por token y con resultados totalmente reproducibles. Las implementaciones de producción eligen esta opción cuando la previsibilidad de los costos o la reproducibilidad estricta son importantes.

La guía de implementación del gráfico de contexto es la referencia para ambas rutas, incluidos los detalles de IAM y cómo crear un extractor de referencia.

8. Consulta el registro de la decisión

Con el gráfico completado, puedes responder la pregunta de auditoría directamente. Toma una concreta: "Para cada solicitud, ¿qué opciones consideró el agente y cómo las resolvió?" En GQL, se trata de un solo recorrido por la solicitud, sus opciones y su resultado.

Escribe la consulta en un archivo (traversal.sql). El marcador ${DATASET} se completa cuando ejecutas la consulta en el siguiente paso:

cat > traversal.sql <<'SQL'
SELECT *
FROM GRAPH_TABLE (
  ${DATASET}.agent_decisions_graph
  MATCH
    (req:DecisionRequest) -[eo:evaluatesOption]-> (opt:DecisionOption),
    (req)                 -[ri:resultedIn]->      (out:DecisionOutcome)
  COLUMNS (
    req.request_id   AS request,
    req.request_text AS question,
    opt.option_label AS considered,
    opt.confidence   AS score,
    out.status       AS outcome,
    out.rationale    AS rationale
  )
);
SQL

Ejecución:

envsubst < traversal.sql | bq query --use_legacy_sql=false --max_rows=20

Deberías ver quince filas: tres opciones por solicitud y cinco solicitudes. Cada fila muestra la solicitud, la opción que consideró el agente, su puntuación de confianza, el resultado final y la explicación.

Para obtener una visión completa de una sola decisión, filtra por request_id y obtén el conjunto de filas que necesita un equipo de auditoría: la pregunta que se recibió, las opciones que se ponderaron (con puntuaciones) y la justificación que se confirmó.

Visualiza el gráfico en BigQuery Studio

BigQuery Studio también puede renderizar el gráfico de forma visual. Abre BigQuery Studio en la consola de BigQuery, ejecuta la siguiente consulta de ruta y, luego, cambia el panel de resultados a la pestaña Gráfico para ver la Web de decisiones. Con el corpus a escala realista, obtienes un mapa visual de las solicitudes, las opciones y los resultados:

GRAPH agent_analytics_demo.agent_decisions_graph
MATCH p = (a)-[e]->(b)
RETURN TO_JSON(p) AS path_json

El gráfico de contexto materializado que se renderiza en la vista de gráfico de BigQuery Studio a partir de una consulta de ruta de GQL

Haz la misma pregunta en inglés sencillo.

No todos los lectores de auditoría escriben GQL. Con Conversational Analytics de BigQuery (vista previa), tu equipo de cumplimiento puede hacer el mismo tipo de pregunta en lenguaje natural y obtener una tarjeta de respuesta estructurada, sin sintaxis de consulta ni combinaciones que aprender.

Registra el agent_decisions_graph (junto con las tablas de agent_events y de decisión) como una fuente de datos de Conversational Analytics y, luego, haz la pregunta de auditoría directamente:

Pregunta de auditoría (en español sencillo): "¿Qué solicitudes nunca alcanzaron un resultado confirmado?"

El Análisis de conversaciones razona sobre el gráfico, escribe el código SQL por ti y responde en inglés sencillo con una tabla de respaldo. En este caso, se muestra que cada solicitud registrada alcanzó un resultado confirmado:

Análisis conversacional que responde la pregunta “¿Qué solicitudes nunca alcanzaron un resultado confirmado?” en el gráfico de contexto: Cada solicitud registrada alcanzó un resultado confirmado (las sesiones huérfanas no se materializan como nodos del gráfico).

La respuesta anterior refleja el corpus a escala realista del paso opcional datos a escala realista (90 solicitudes materializadas, todas confirmadas); tus números exactos dependen del corpus que inicializaste, y la ejecución predeterminada de 5 sesiones muestra cinco.

Consulta la documentación de Conversational Analytics para obtener información sobre la configuración.

9. Llévalo a producción

La ejecución local anterior usa el comportamiento predeterminado, que ya abarca los conceptos básicos para las implementaciones reales: cada ejecución deja un registro de auditoría (Cloud Logging estructurado más una fila por ejecución en una tabla de estado en tu conjunto de datos), los errores transitorios se reintentan automáticamente y el progreso solo avanza en las sesiones que se completaron correctamente, por lo que no hay registro duplicado.

Los controles de producción (extracción determinística [--extraction-mode=compiled-only], detección de sesiones atascadas [--max-session-age-hours], reproducción única de un período anterior [--backfill --from / --to, que se hace un seguimiento por separado de la actualización normal para que no interrumpa la programación en vivo] y delimitación por lotes por ejecución [--max-sessions]) son marcas opcionales que puedes usar cuando las necesites. La guía de implementación del gráfico de contexto documenta cada uno con la matriz completa de IAM y los programas recomendados.

10. Limpia

Desarma lo que creaste para que no se te facture por un conjunto de datos inactivo:

bq rm -r -f --dataset "$PROJECT_ID:$DATASET"

Ese único comando quita el conjunto de datos, los eventos del agente, las tablas de gráficos y la tabla de estado de forma conjunta.

11. Felicitaciones

¡Felicitaciones! Convertiste los registros de eventos sin procesar del agente en un gráfico de contexto del agente consultable y realizaste un seguimiento de una sola decisión de extremo a extremo, sin una base de datos de gráficos externa ni una canalización de ETL.

El mismo patrón se aplica en cualquier situación en la que un agente toma decisiones importantes: suscripción de crédito, autorización previa, cambios en el presupuesto de marketing, adquisiciones, servicio al cliente y TI interna. Para compilar tu propio gráfico de contexto del agente, copia los artefactos del codelab como punto de partida, adapta los dos archivos declarativos (DDL de la tabla y el esquema CREATE PROPERTY GRAPH) a tu dominio y aplícalos a BigQuery. bqaa context-graph --graph lee el gráfico implementado desde INFORMATION_SCHEMA y deriva el resto.

Qué aprendiste

  • Cómo crear un conjunto de datos de BigQuery y aplicar un esquema de grafo de propiedades que describa un dominio de decisión del agente
  • Cómo completar agent_events con un corpus de eventos sintéticos
  • Cómo ejecutar bqaa context-graph para extraer los registros de decisiones del agente en un gráfico de contexto del agente a partir de esos eventos, y leer la definición del gráfico desde INFORMATION_SCHEMA.
  • Cómo consultar el gráfico resultante en GQL y leer la respuesta de estilo de auditoría

Documentos de referencia