Descripción general de los conjuntos de contexto

Los conjuntos de contexto de Knowledge Catalog te permiten empaquetar esquemas de datos, definiciones semánticas y patrones de consulta validados en contenedores de conocimiento limitados y específicos del dominio. Este conocimiento de dominio específico fundamenta de forma confiable las aplicaciones de IA autónomas, como Gemini Enterprise y los agentes personalizados, para que puedan operar con alta precisión.

Este documento está dirigido a arquitectos de datos, líderes de administración y, también, ingenieros de IA que deseen comprender cómo los conjuntos de contexto estructuran el conocimiento del dominio para los agentes de IA.

¿Qué es un conjunto de contexto?

Un conjunto de contexto es un grupo de entradas especializado de Knowledge Catalog (un contenedor lógico para registros de metadatos) que empaqueta una colección independiente de información semántica y referencias de recursos de datos para dominios analíticos y agentes de IA específicos.

Dentro de este contenedor, el conocimiento se organiza en entradas, que representan conceptos empresariales, documentos o recursos de datos individuales. Estas entradas se enriquecen con aspectos, que son atributos de metadatos modulares que almacenan detalles específicos, como términos empresariales, plantillas de SQL y documentación de Markdown.

En lugar de obligar a los agentes a buscar en todo un catálogo empresarial, lo que introduce latencia, desperdicia tokens de instrucciones y genera respuestas con alucinaciones, los conjuntos de contexto establecen contenedores de conocimiento herméticos y con alcance de dominio que los agentes pueden consultar con alta precisión.

Debido a que los conjuntos de contexto actúan como contenedores administrativos, puedes organizar los metadatos por propiedad del proyecto y aplicar políticas de control de acceso de Identity and Access Management (IAM) en todas las entradas agrupadas a la vez sin configurar los permisos de forma individual. Para obtener más información sobre los grupos de entradas, las entradas y los aspectos, consulta Acerca de la administración de metadatos.

Requisitos de fundamentación de los agentes de IA

A medida que las organizaciones implementan agentes de IA autónomos (como Gemini Enterprise, Antigravity y agentes personalizados del kit de desarrollo de agentes) para organizar los flujos de trabajo de datos y generar estadísticas, los agentes requieren una fundamentación confiable:

  • Definiciones semánticas: ¿Qué significa una columna o métrica específica en términos empresariales?
  • Patrones de consulta validados: ¿Cómo consultaron y unieron estas tablas los expertos en el dominio?
  • Reglas operativas: ¿Qué políticas empresariales, criterios de excepción y procedimientos operativos estándar (SOP) rigen estos datos?

En el siguiente diagrama de arquitectura, se ilustra cómo funcionan juntas las cuatro convenciones de nombres lógicas principales dentro del límite del grupo de entradas para fundamentar las aplicaciones de IA downstream:

Las cuatro convenciones de nombres dentro de un límite de conjunto de contexto que restringen las búsquedas de los agentes de IA.
Figura 1: Las cuatro convenciones de nombres seleccionadas dentro de un límite de grupo de entradas de conjunto de contexto.

Si bien un conjunto de contexto no requiere estrictamente que todos los tipos de entradas funcionen, te recomendamos que organices tus entradas con las siguientes convenciones de nombres lógicas. El uso de estas convenciones de nombres ayuda a garantizar que los humanos y los agentes autónomos puedan descubrir e interpretar el conocimiento de forma coherente:

Patrón de nombres Tipo de entrada Descripción y propósito Aspectos adjuntos
Conceptos comerciales concepts_<id> generic Términos del glosario empresarial, definiciones de métricas, acrónimos y fórmulas de cálculo. glossary-term-aspect, contacts.
Documentos documents_<path> document Contexto narrativo, procedimientos operativos estándar (SOP), wikis de incorporación y punteros a documentación externa. Document, overview (Markdown de texto enriquecido y vínculos).
Plantillas de consulta query-templates_<path> query-template Plantillas de consulta en SQL parametrizadas y validadas previamente, lógica de unión de alta frecuencia y patrones de ejecución. query-template (incluye campos como sources, intent, nlQuery, parameters y query).
Modelos semánticos semantic-models_<id> semantic-model, semantic-entity, semantic-metric Modelos relacionales formales, definiciones de entidades, jerarquías dimensionales y medidas. semantic-model, semantic-entity, semantic-metric.

Conceptos comerciales

Una entrada de concepto empresarial (entrada de tipo genérico que usa la convención de nombres concepts_*) define la terminología empresarial estandarizada, las métricas de dominio, las siglas y las fórmulas de cálculo (glossary-term-aspect).

Las siguientes son algunas de las funciones clave:

  • Alineación de la terminología: Elimina la ambigüedad de la terminología en las unidades de negocio y los equipos de análisis.
  • Fórmulas de KPI: Proporciona fórmulas matemáticas y lógica para los indicadores clave de rendimiento (KPI) específicos del dominio.
  • Propiedad de la organización: Establece una propiedad clara de la organización a través de aspectos de administración adjuntos (contacts).

Por ejemplo, dentro de un conjunto de contexto de comercio electrónico, una entrada en concepts_net_items_sold especifica el cálculo exacto de las unidades netas vendidas. Cuando un agente recibe una instrucción en la que se solicitan los "artículos netos vendidos", consulta la entrada del concepto para aplicar el cálculo verificado en lugar de inventar la lógica de SQL.

Representación de recursos de ejemplo:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/concepts_net_items_sold
entryType: generic
aspects:
  dataplex-types.global.glossary-term-aspect:
    definition: "Calculates the absolute number of items sold minus customer returns in a given time period."

Documentos

Una entrada de documento (entrada de tipo documento que usa la convención de nombres documents_*) almacena el contexto narrativo y de procedimiento en Markdown estructurado (Document, overview).

Las siguientes son algunas de las funciones clave:

  • Procedimientos operativos estándar (SOP): Captura los SOP, las listas de tareas de runbooks y las guías de incorporación directamente en el catálogo.
  • Políticas de cumplimiento: Documenta las políticas de cumplimiento, las restricciones reglamentarias (como las reglas de manejo del RGPD o la HIPAA) y los criterios de excepción.
  • Wikis de referencia externa: Hace referencia a wikis activas externas (como documentos de Google, Atlassian Confluence, Notion o GitHub) a través de punteros de URI de origen (vínculos de overview).

Por ejemplo, un conjunto de contexto de indumentaria incluye documents_return_policy_rules para indicarles a los agentes cómo excluir las ventas finalizadas y los artículos dañados en tránsito cuando se calculan las tasas de devolución estándar.

Representación de recursos de ejemplo:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/documents_return_policy_rules
entryType: document
aspects:
  dataplex-types.global.overview:
    content: "## Return Policy Rules\nItems marked FINAL_SALE or DAMAGED_IN_TRANSIT are excluded from return rates..."

Plantillas de consulta

Una entrada de plantilla de consulta (entrada de tipo query-template que usa la convención de nombres query-templates_*) contiene consultas en SQL parametrizadas y verificadas por humanos asignadas a intents analíticos comunes de lenguaje natural (con el aspecto query-template).

Las siguientes son algunas de las funciones clave:

  • Consultas previamente validadas: Almacena rutas de unión, condiciones de filtro y patrones de agregación previamente validados para preguntas empresariales de alta frecuencia.
  • Parametrización del entorno de ejecución: Admite la sustitución de parámetros del entorno de ejecución (como @start_date, @region y @limit) para la ejecución dinámica de agentes.
  • Prevención de errores: Evita uniones de tablas alucinadas y errores de sintaxis del dialecto de SQL.

Por ejemplo, cuando un agente necesita responder una pregunta sobre las cuentas con mejor rendimiento, coincide con query-templates_sales_top_accounts_by_arr y sustituye el rango de fechas solicitado en la plantilla de SQL verificada.

Representación de recursos de ejemplo:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/query-templates_top_categories_by_season
entryType: query-template
aspects:
  dataplex-types.global.query-template:
    intent: "Which e-commerce product categories performed best this season?"
    query: "SELECT category, SUM(revenue) FROM sales WHERE season = @season GROUP BY category ORDER BY 2 DESC LIMIT @limit"
    parameters:
      -   name: "season"
        type: "STRING"
      -   name: "limit"
        type: "INTEGER"

Modelos semánticos

Las entradas del modelo semántico (con los tipos de entrada semantic-model, semantic-entity y semantic-metric con la convención de nombres semantic-models_*) formalizan las estructuras relacionales, las jerarquías dimensionales y las medidas de agregación en las tablas normalizadas.

Las siguientes son algunas de las funciones clave:

  • Definición relacional: Define las claves primarias, las claves externas y las cardinalidades de unión (como las relaciones de uno a varios o de varios a varios).

  • Asignación de dimensiones de la empresa: Asigna columnas subyacentes sin procesar a dimensiones de la empresa, niveles de detalle de tiempo y mediciones reutilizables.

  • Orientación para agentes: Guía a los agentes autónomos cuando ensamblan consultas analíticas complejas de varias tablas cuando no existe una plantilla de consulta exacta.

  • Abstracción de la complejidad subyacente: A diferencia de los vínculos de entrada de unión de esquemas sin procesar que solo documentan las conexiones mecánicas de las tablas en el conjunto de datos de origen, los modelos semánticos operan en la capa empresarial lógica para evitar que el agente de IA alucine con recorridos incorrectos del diagrama de ER.

Por ejemplo, un conjunto de contexto de indumentaria usa semantic-models_apparel_sales_model para definir cómo se unen warehouses, shipments y line_items en las tablas de hechos y dimensiones del esquema de estrella.

Representación de recursos de ejemplo:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/semantic-models_apparel_sales_model
entryType: semantic-model
aspects:
  dataplex-types.global.semantic-model:
    entities:
      -   name: "products"
      -   name: "orders"
    relationships:
      -   sourceEntity: "orders"
        foreignKey: "product_id"
        targetEntity: "products"
        primaryKey: "id"
        type: "MANY_TO_ONE"

Ejemplo: Conjunto de contexto de una tienda de ropa en línea

Para mostrar cómo funcionan juntas las cuatro convenciones de nombres, considera un comercio minorista de ropa en línea que implementa un asistente de IA para los comerciantes de la tienda. Sin un contexto limitado, el agente podría consultar tablas de etapa de pruebas sin procesar o contar de forma incorrecta los artículos populares, ya que no restaría las devoluciones de los clientes.

Para fundamentar el agente, un administrador de datos crea un conjunto de contexto llamado online-apparel-store:


EntryGroup: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store
(EntryGroup.type = "context-set")
│
├── concepts_* (Business concepts)
│   ├── concepts_net_items_sold
│   │     Formula: SUM(orders.quantity) - SUM(returns.quantity)
│   └── concepts_bestseller
│         Definition: Any clothing item with >= 500 net units sold within a 30-day window
│
├── documents_* (Documents and SOPs)
│   ├── documents_return_policy_rules
│   │     Markdown SOP: Exclude items marked 'FINAL_SALE' or 'DAMAGED_IN_TRANSIT' from standard return rates
│   └── documents_size_chart_guide
│         Markdown guide: Sizing conversions across US, UK, and EU clothing labels
│
├── query-templates_* (Golden SQL queries)
│   └── query-templates_top_categories_by_season
│         Verified SQL template with parameters: @season, @limit
│
└── semantic-models_* (Semantic models)
    └── semantic-models_apparel_sales_model
          Join keys: orders.product_id = products.product_id (many-to-one)
                     orders.order_id = returns.order_id (one-to-many)

Cómo un agente resuelve una instrucción

Cuando un comerciante le pregunta al agente: "¿Cuáles fueron nuestros 5 estilos de chaquetas de invierno más vendidos, sin incluir las devoluciones por daños?", el agente resuelve la instrucción a través del conjunto de contexto:

  1. Búsqueda de plantillas de consulta: El agente verifica query-templates_* y coincide con query-templates_top_categories_by_season, sustituyendo @season = 'Winter' y @limit = 5.

  2. Verificación de conceptos: El agente inspecciona concepts_net_items_sold y concepts_bestseller para confirmar que los artículos devueltos se deben restar de las cantidades totales de los pedidos.

  3. Aplicación de la regla de SOP: El agente lee documents_return_policy_rules y agrega la condición de filtro WHERE return_reason != 'DAMAGED_IN_TRANSIT'.

  4. Validación de esquemas y uniones: Con semantic-models_apparel_sales_model y las tablas @bigquery vinculadas, el agente une store.orders, store.products y store.returns con claves externas verificadas y ejecuta la consulta en SQL.

Capacidades de arquitectura

Los conjuntos de contexto proporcionan varias capacidades principales para los entornos de datos empresariales:

  • Límites de ejecución herméticos: Cuando se vincula el contexto a un conjunto seleccionado de recursos y entradas semánticas, los agentes operan dentro de una zona de pruebas hermética. Esto elimina el ruido extraño del catálogo, ayuda a garantizar evaluaciones determinísticas y minimiza el uso de tokens.

  • Carga rápida e indexación masiva: Los equipos pueden subir e indexar conjuntos de conceptos, consultas y documentos como una sola operación atómica, lo que te permite integrar con canalizaciones de integración y de implementación continuas (CI/CD).

  • Empaquetado sin copia: Context establece los metadatos y las relaciones de los paquetes sin copiar ni mover el almacenamiento de datos subyacente, lo que evita costos de almacenamiento redundantes y retrasos en la sincronización de datos.

Patrones de consulta de agentes

Los agentes downstream consumen conjuntos de contexto a través del Protocolo de contexto del modelo (MCP) o las APIs directas de Knowledge Catalog. Para obtener más información, consulta Recupera el contexto de los datos con las APIs de Catalog. Para optimizar la latencia de respuesta y minimizar el consumo de tokens, los agentes siguen una jerarquía de consulta de tres niveles:

  1. Coincidencia de plantillas de consultas: El agente busca query-templates_*. Si una plantilla verificada coincide con el intent del usuario, el agente parametriza la consulta y la ejecuta directamente. Esto proporciona la respuesta más rápida con un riesgo casi nulo de error de consulta.

  2. Ensamblaje del modelo semántico: Si no coincide ninguna plantilla de consulta, el agente evalúa semantic-models_* para comprender las relaciones entre entidades y construir una instrucción de SQL de varias tablas.

  3. Consulta de documentos y conceptos: Para casos extremos ambiguos (como límites de calendario fiscal o exclusiones de disputas), el agente lee concepts_* y documents_* para aplicar reglas empresariales.

Consumo de contexto en aplicaciones de IA generativa

Las aplicaciones de IA generativa usan conjuntos de contexto seleccionados para comprender la semántica del dominio empresarial, navegar por esquemas complejos y generar SQL confiable sin alucinaciones. Por lo general, las aplicaciones consumen estos conjuntos de contexto a través de dos patrones principales:

  • Descubrimiento dinámico de contexto: En los entornos de análisis conversacionales o de autoservicio, los usuarios hacen preguntas ad hoc en lenguaje natural. La aplicación evalúa de forma dinámica la intención del usuario para identificar y recuperar el conjunto de contexto más relevante de Knowledge Catalog, lo que inserta el conocimiento del dominio recuperado en la instrucción activa.

  • Conjuntos de contexto preconfigurados: Para las aplicaciones de agentes dedicados, puedes preconfigurar el agente con una referencia explícita al conjunto de contexto proporcionando su URI de recurso. Vincular un conjunto de contexto dedicado proporciona una base determinística, lo que garantiza que todas las interacciones usen definiciones empresariales certificadas sin sobrecarga de búsqueda en el entorno de ejecución. El agente hereda automáticamente las mejoras de calidad a medida que los flujos de trabajo de enriquecimiento recurrentes perfeccionan el conjunto de contexto con el tiempo.

    Para optimizar estas capacidades de enriquecimiento y autoaprendizaje, te recomendamos que especifiques un modelo de Gemini 3.8 Flash o posterior en la aplicación de Gemini Enterprise. Para obtener más información sobre los pasos de selección del modelo, consulta la sección "Crea un agente con el compilador de flujos" en Diseña agentes en Agent Studio.

Cómo se comparan los conjuntos de contexto con las construcciones relacionadas

Para elegir la construcción de metadatos adecuada para tu arquitectura, lee cómo se comparan los conjuntos de información contextual de Knowledge Catalog con las capacidades relacionadas de la plataforma.

Comparación entre conjuntos de contextos y gráficos de contexto

El gráfico de contexto y los conjuntos de contexto son dos construcciones independientes con funciones distintas en la arquitectura de Knowledge Studio:

  • Grafo de contexto: Es la topología semántica integral y en vivo de tu organización. Vincula los recursos de datos subyacentes, los términos del glosario empresarial y los registros de interacción. Explora y recorre este gráfico abierto de forma interactiva en la interfaz de exploración.

  • Conjunto de contexto: Es una unidad de empaquetado limitada, regional y seleccionada. Extrae y empaqueta de forma hermética un subconjunto específico de conocimiento del dominio en un grupo de entradas (type="context-set") para que los agentes de IA downstream realicen consultas a través del Protocolo de contexto del modelo (MCP). Un conjunto de contextos actúa como un subgrafo cohesivo y de alta densidad dentro del grafo de contexto más amplio.

Comparación entre los conjuntos de información contextual de Knowledge Catalog y los de bases de datos

Tanto Knowledge Catalog como las bases de datos operativas de Google Cloud usan el término conjunto de contexto para referirse a la información seleccionada que fundamenta los modelos de IA generativa.

Si bien ambas variantes comparten la misma arquitectura subyacente, se almacenan de forma nativa como conjuntos de contexto de Knowledge Catalog (grupos de entradas extensibles con type="context-set") y usan APIs estándar de Knowledge Catalog, se orientan a diferentes capas de la pila de datos empresariales:

  • Conjuntos de contexto de bases de datos (QueryData): Se crearon para entregar bases de datos operativas y transaccionales (como AlloyDB para PostgreSQL, Cloud SQL y Spanner). Estos conjuntos de contexto están muy optimizados para las configuraciones de SQL. Agrupan plantillas de consultas de referencia, metadatos de esquemas y facetas de filtrado que un agente de ingeniería de contexto dedicado evalúa para mejorar la traducción de lenguaje natural a SQL (NL2SQL) en entornos de ejecución operativos.
  • Conjuntos de contexto de Knowledge Catalog (Knowledge Studio): Se crearon para entregar patrimonios de datos analíticos (como BigQuery, almacenes de data lakes y productos de datos de Knowledge Catalog). Estos conjuntos de contexto empaquetan conocimientos multimodales más amplios en varias convenciones de nombres, incluidos conceptos empresariales, wikis de documentación de Markdown y modelos semánticos. Se seleccionan con los flujos de trabajo de enriquecimiento de Knowledge Studio y se entregan a los agentes analíticos downstream a través del Protocolo de contexto del modelo (MCP).

Comparación entre conjuntos de contexto y productos de datos

Comprender cómo interactúan los conjuntos de contexto con los productos de datos de Knowledge Catalog te ayuda a establecer límites claros de administración de datos y de IA:

  • Los productos de datos administran los recursos subyacentes: Los productos de datos agrupan de forma segura recursos concretos, como tablas, buckets y transmisiones de BigQuery, lo que establece una unidad principal para el uso compartido de datos, los contratos de datos y el control de acceso al plano de datos.

  • Los conjuntos de contexto agrupan la semántica conversacional: Los conjuntos de contexto no otorgan acceso a los datos, sino que agrupan el conocimiento del dominio, como los conceptos, las plantillas de consultas y los documentos que necesitan los agentes de IA y los humanos para comprender los datos. Los administradores de datos pueden vincular un conjunto de contexto a un producto de datos declarándolo en las referencias additional_context del producto.

Seguridad y administración empresarial

Los conjuntos de contexto se integran en los controles de seguridad y administración de Google Cloud para ayudar a proteger los metadatos empresariales sensibles:

  • Roles de IAM de conjuntos de contexto: Debido a que los conjuntos de contexto suelen contener información semántica sensible, el acceso se rige por roles de IAM aplicados directamente al grupo de entradas context-set. Esto te permite organizar el conocimiento seleccionado por región geográfica y propiedad del dominio, otorgar permisos de modificación a los administradores de dominios y permisos de lectura a los agentes de IA que consumen. Para crear un conjunto de contexto, debes tener el permiso de IAM dataplex.entryGroups.setIamPolicy. Este permiso es necesario para otorgarte automáticamente permisos de propietario durante la creación del conjunto de contexto. Puedes obtener este permiso a través de roles predefinidos, como los roles de administrador del catálogo de Dataplex (roles/dataplex.catalogAdmin) o propietario del grupo de entradas de Dataplex (roles/dataplex.entryGroupOwner).

  • Seguridad de los datos subyacentes sin copia: Otorgar acceso a un agente a un conjunto de contexto le permite leer metadatos semánticos y plantillas de consulta, pero no omite los controles de acceso en las tablas subyacentes. Para ejecutar una consulta en SQL en BigQuery o leer archivos en Cloud Storage, la identidad que ejecuta la consulta debe tener los permisos de IAM del plano de datos necesarios en esos recursos subyacentes.

  • Gobernanza con intervención humana: Cuando las tareas de enriquecimiento autónomas de Knowledge Studio extraen conceptos, SOP o plantillas de consultas nuevos de los registros operativos, las propuestas se organizan como solicitudes de cambio que se pueden revisar. Los administradores de datos inspeccionan las comparaciones de diferencias y las puntuaciones de evaluación antes de aprobar los cambios en un conjunto de contexto de producción. Para obtener más información sobre la revisión de propuestas, consulta Administra solicitudes.

  • Identidad de ejecución administrada por el usuario: Las tareas de enriquecimiento automatizadas que propagan conjuntos de contexto se ejecutan con una cuenta de servicio administrada por el usuario que el agente de servicio de Dataplex suplanta a través del rol de creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator).

Obtén una vista previa del alcance y los límites

Durante la versión preliminar, los conjuntos de contexto operan dentro de los siguientes límites:

  • Permiso regional: No se admiten los conjuntos de contexto global vinculados a recursos de datos regionales. Un conjunto de contexto debe alinearse con los límites regionales de los recursos que empaqueta.

  • Interfaces de creación y consumo: Puedes crear conjuntos de contexto a través del contenedor de Knowledge Studio en la consola de Google Cloud , lo que los mantiene lógicamente distintos de los grupos de entradas administrativas estándar de Knowledge Catalog. Puedes propagar conjuntos de contexto automáticamente a través de los flujos de trabajo de enriquecimiento de Knowledge Studio. Los agentes de IA downstream pueden descubrir y consultar conjuntos de contexto de forma programática con las APIs de Knowledge Catalog (ListEntries y LookupEntry) y el Protocolo de contexto del modelo (MCP). Para obtener más información, consulta Acerca de los servidores de MCP.

  • Facturación: Knowledge Catalog no cobra un SKU independiente por crear grupos de entradas de conjuntos de información contextual.

  • Cuotas compartidas: Debido a que los conjuntos de contexto son, en esencia, grupos de entradas especializados (type="context-set"), consumen y comparten las mismas cuotas de recursos que los grupos de entradas estándar de Knowledge Catalog.

¿Qué sigue?

Concepto

Aprende a organizar el contexto de datos enriquecidos, crear conjuntos de contexto y fundamentar agentes de IA con las interfaces de Knowledge Studio.

Tarea

Usa el lienzo visual de Knowledge Studio para chatear con tus datos y rastrear relaciones semánticas.

Concepto

Comprender cómo las entradas, los grupos de entradas y los aspectos forman la base estructural de los conjuntos de contexto

Concepto

Exponer conjuntos de contexto y metadatos enriquecidos a agentes de IA generativa downstream con el MCP

Tarea

Descubre y recupera de manera programática conjuntos de información contextual para el razonamiento de la IA generativa con las APIs `ListEntries` y `LookupEntry`.

Tarea

Aprende a crear, ver, editar y borrar conjuntos de contexto en para organizar el conocimiento del dominio.