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 delimitados y específicos del dominio. Puedes usar estos contenedores para fundamentar aplicaciones de IA autónomas, como Gemini Enterprise y agentes personalizados, en conocimientos de dominio verificados.

Este documento está dirigido a arquitectos de datos, líderes de administración y de ingeniería de IA que desean comprender cómo los conjuntos de contexto estructuran el conocimiento del dominio para los agentes de IA. Para crear y propagar un conjunto de contexto de inmediato, consulta Administra conjuntos de contexto.

¿Qué es un conjunto de contexto?

Un conjunto de contexto es un grupo de entradas (type="context-set") especializado de Knowledge Catalog, que es un contenedor lógico para entradas de metadatos y documentos de conocimiento. Cada conjunto de contexto 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 individuales, recursos de datos o documentos, como lineamientos, instructivos y material de referencia. Estas entradas se enriquecen con aspectos, que son atributos de metadatos modulares que almacenan detalles específicos, como términos comerciales, plantillas de SQL y documentación de Markdown.

En el siguiente diagrama, se muestra cómo los agentes de IA consultan un conjunto de contexto, incluidos su índice raíz, las entradas de dominio, los aspectos y los recursos de datos a los que se hace referencia:

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 el riesgo de 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?

Cómo propagar un conjunto de contexto

Puedes propagar entradas en un conjunto de contexto ejecutando una tarea de enriquecimiento autónoma que analice tus esquemas, registros de consultas y señales de conocimiento. Para obtener más información, consulta Crea tareas de enriquecimiento.

Debido a que un conjunto de contexto es un grupo de entradas especializado (type="context-set"), también puedes crear y actualizar sus entradas de manera programática con Google Cloud CLI, las bibliotecas cliente o la API de Dataplex. Para obtener más información, consulta Administra entradas y transfiere fuentes personalizadas.

Tipos y estructura de los tipos de entrada del conjunto de contexto

Las entradas de un conjunto de contexto usan los tipos de entrada del sistema Documento (projects/dataplex-types/locations/global/entryTypes/document) o Plantilla de consulta (projects/dataplex-types/locations/global/entryTypes/query-template), los IDs de entrada jerárquicos y los aspectos de metadatos según el conocimiento que almacenan. En las siguientes secciones, se describen la estructura de las entradas y las categorías principales de entradas que fundamentan a los agentes de IA.

Estructura de entrada del agente de enriquecimiento automatizado

Cuando una tarea de enriquecimiento propaga un conjunto de contexto, el agente de enriquecimiento crea sus entradas generadas con el tipo de entrada del sistema Document (projects/dataplex-types/locations/global/entryTypes/document) con los aspectos document y overview obligatorios. El agente organiza estas entradas generadas en una jerarquía de divulgación progresiva con IDs de entrada separados por barras diagonales (/) y distingue el rol de cada entrada con el campo document.type:

En el siguiente diagrama, se ilustra cómo un conjunto de contexto enriquecido (thelook-context) organiza sus entradas en el índice raíz agents (context-set). Los niveles del directorio de navegación (knowledge-base-index) agrupan las entradas de contexto de la tabla (table-context con recuentos de consulta en SQL adjuntos) en assets/bigquery/cymbal-style/thelook/* y agrupan las guías de dominio (knowledge-base) y los términos empresariales (concept) en documents/*:

Además de las entradas de Document generadas por una tarea de enriquecimiento, un conjunto de contexto puede contener entradas independientes de Query Template (projects/dataplex-types/locations/global/entryTypes/query-template) creadas de forma programática a través de Google Cloud CLI, las bibliotecas cliente o la API de Dataplex. Cuando se ejecuta una tarea de enriquecimiento en un conjunto de contexto que contiene entradas de plantilla de consulta certificadas, el agente de enriquecimiento conserva esas entradas sin modificarlas ni borrarlas. Para obtener más información, consulta la sección Plantillas de consulta de este documento.

Recursos de datos

Una entrada de recurso de datos (document.type: "table-context" en assets/bigquery/PROJECT_ID/DATASET_ID/TABLE_ID) captura instrucciones específicas del dominio, advertencias de columnas, sugerencias de unión y ejemplos de SQL verificados para una tabla específica sin reemplazar la descripción de la tabla física en BigQuery. Cada entrada de recurso de datos se vincula a su recurso de catálogo de destino a través de un vínculo de entrada reference dirigido (projects/dataplex-types/locations/global/entryLinkTypes/reference).

Ejemplo de representación de recursos:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/assets/bigquery/cymbal-style/store/orders
entryType: projects/dataplex-types/locations/global/entryTypes/document
aspects:
  dataplex-types.global.document:
    type: "table-context"
  dataplex-types.global.overview:
    content: "## Orders table context\nJoin `store.orders` to `store.returns` on `order_id` when calculating net sales..."

Conceptos comerciales

Una entrada de concepto empresarial (document.type: "concept" en documents/concepts/CONCEPT_ID) define la terminología empresarial estandarizada, las métricas de dominio, los acrónimos y las fórmulas de cálculo.

Estas son algunas de las capacidades clave:

• Alineación de la terminología: Elimina la ambigüedad de la terminología en las unidades de negocio y los equipos analíticos.
• Fórmulas de KPI: Proporciona fórmulas matemáticas y lógica para los indicadores clave de rendimiento (KPI) específicos del dominio.
• Vinculación de recursos segmentados: Vincula a tablas relevantes con vínculos de entrada reference para que los agentes sepan dónde se aplica el concepto.

Por ejemplo, dentro de un conjunto de contexto de comercio electrónico, una entrada en documents/concepts/net-items-sold especifica el cálculo exacto de las unidades netas vendidas. Cuando un agente recibe un mensaje en el que se le pregunta por 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.

Ejemplo de representación de recursos:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/documents/concepts/net-items-sold
entryType: projects/dataplex-types/locations/global/entryTypes/document
aspects:
  dataplex-types.global.document:
    type: "concept"
  dataplex-types.global.overview:
    content: "Calculates the absolute number of items sold minus customer returns in a given time period."

Documentos y reglas de autoaprendizaje

Una entrada de documento (document.type: "knowledge-base" o "learning" en documents/*) almacena el contexto narrativo y de procedimiento en Markdown estructurado (aspectos document y overview).

Estas son algunas de las capacidades 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.
• Autoaprendizaje del agente: Captura reglas tácitas y desambiguaciones (documents/learnings/LEARNING_SLUG) extraídas de los registros de conversaciones de los agentes downstream.

Por ejemplo, un conjunto de contexto de indumentaria incluye documents/policies/return-policy-rules para indicar 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.

Ejemplo de representación de recursos:

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

Plantillas de consulta

También puedes adjuntar aspectos de queries a las entradas de recursos de datos o crear de forma programática entradas de plantilla de consulta (projects/dataplex-types/locations/global/entryTypes/query-template) dedicadas en un conjunto de contexto para almacenar consultas en SQL verificadas y parametrizadas asignadas a preguntas en lenguaje natural (aspecto dataplex-types.global.query-template).

Estas son algunas de las capacidades clave:

• Consultas validadas previamente: Almacena rutas de unión verificadas, condiciones de filtro y patrones de agregación asignados a un intent analítico y una pregunta de ejemplo en lenguaje natural (nlQuery).
• Parametrización del entorno de ejecución: Admite marcadores de posición de parámetros con tipo (como @season y @limit) con descripciones y valores de muestra (sampleValues) para la ejecución dinámica de agentes.
• Compatibilidad con varios motores: Especifica el sourceType de destino (como BIGQUERY, SPANNER, ALLOYDB, CLOUD_SQL o LOOKER) y el sourceDialect opcional (GOOGLE_SQL, POSTGRESQL, MYSQL o LOOKER_QUERY).

Ejemplo de representación de recursos:

name: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store/entries/queries/top-categories-by-season
entryType: projects/dataplex-types/locations/global/entryTypes/query-template
aspects:
  dataplex-types.global.query-template:
    intent: "Identify top-performing product categories by revenue for a given season."
    nlQuery: "Which ecommerce product categories performed best in winter?"
    query: "SELECT category, SUM(revenue) FROM store.orders WHERE fiscal_season = @season GROUP BY category ORDER BY 2 DESC LIMIT @limit"
    sourceType: "BIGQUERY"
    sourceDialect: "GOOGLE_SQL"
    parameters:
      - name: "season"
        type: "STRING"
        sampleValues:
          - "WINTER"
      - name: "limit"
        type: "NUMBER"
        sampleValues:
          - "5"

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

Para mostrar cómo funcionan juntas las entradas de un conjunto de contexto, 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 y enriquece un conjunto de contexto llamado online-apparel-store:

EntryGroup: projects/cymbal-style/locations/us-central1/entryGroups/online-apparel-store
(EntryGroup.type = "context-set")
│
├── agents (document.type = "context-set")
│     Root directory index for AI agents consulting the context set
│
├── assets/bigquery/cymbal-style/store/* (document.type = "table-context")
│   ├── assets/bigquery/cymbal-style/store/orders
│   │     Linked using entryLinkTypes/reference -> @bigquery .../tables/orders
│   ├── assets/bigquery/cymbal-style/store/products
│   │     Linked using entryLinkTypes/reference -> @bigquery .../tables/products
│   └── assets/bigquery/cymbal-style/store/returns
│         Linked using entryLinkTypes/reference -> @bigquery .../tables/returns
│
├── documents/concepts/* (document.type = "concept")
│   ├── documents/concepts/net-items-sold
│   │     Formula: SUM(orders.quantity) - SUM(returns.quantity)
│   └── documents/concepts/bestseller
│         Definition: Any clothing item with >= 500 net units sold within a 30-day window
│
├── documents/policies/* (document.type = "knowledge-base")
│   └── documents/policies/return-policy-rules
│         Markdown SOP: Exclude items marked 'FINAL_SALE' or 'DAMAGED_IN_TRANSIT' from standard return rates
│
└── documents/learnings/* (document.type = "learning")
    └── documents/learnings/winter-season-date-filter
          Learned rule: Filter winter season queries using fiscal_season = 'WINTER'

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. Índice raíz y búsqueda de conceptos: El agente lee el índice raíz agents y, luego, inspecciona documents/concepts/net-items-sold y documents/concepts/bestseller para confirmar que los artículos devueltos se deben restar de las cantidades totales de los pedidos.

2. Aplicación de SOP y aprendizaje: El agente lee documents/policies/return-policy-rules y documents/learnings/winter-season-date-filter, y agrega las condiciones de filtro WHERE return_reason != 'DAMAGED_IN_TRANSIT' y fiscal_season = 'WINTER'.

3. Contexto de la tabla y validación de la unión: Con las entradas de recursos de datos en assets/bigquery/cymbal-style/store/* y sus vínculos de entrada reference a las tablas @bigquery subyacentes, 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. Este límite elimina el ruido extraño del catálogo, ayuda a garantizar evaluaciones deterministas 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: Los conjuntos de contexto empaquetan los metadatos y las relaciones sin copiar ni mover el almacén 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 recursos de datos.

Para optimizar la latencia de respuesta y minimizar el consumo de tokens, los agentes siguen una jerarquía de consulta de divulgación progresiva:

1. Índice raíz y concordancia de búsquedas: El agente inspecciona el índice raíz agents y cualquier aspecto queries adjunto a las entradas de recursos de datos. Si un ejemplo de SQL verificado coincide con la intención del usuario, el agente adapta la consulta y la ejecuta directamente. Esta coincidencia proporciona una respuesta rápida con un riesgo mínimo de error de consulta.

2. Contexto de la tabla y ensamblado del esquema: Si no coincide ningún ejemplo de consulta exacto, el agente lee las entradas de recursos de datos (assets/*) y sus aspectos de schema para comprender las relaciones de las entidades y construir una sentencia de SQL de varias tablas.

3. Consulta de documentos y conceptos: Para casos extremos ambiguos (como los límites del calendario fiscal o las exclusiones de disputas), el agente lee las entradas de conceptos (documents/concepts/*), aprendizaje (documents/learnings/*) y base de conocimiento (documents/*) para aplicar las reglas empresariales. Si una definición de una entrada de conjunto de contexto entra en conflicto con una definición de un término del glosario empresarial, los agentes consumidores priorizan la definición del conjunto de contexto.

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 de contexto dinámico: 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 pertinente de Knowledge Catalog, lo que inserta el conocimiento del dominio recuperado en la instrucción activa.

  Para fundamentar una aplicación de Gemini Enterprise en el contexto de Knowledge Catalog, configura el conector de datos de BigQuery en el modo de consulta federada en tu aplicación de Gemini Enterprise y verifica que el botón de activación Habilitar Knowledge Catalog esté activado en la configuración del asistente de Gemini Enterprise. Para obtener más información, consulta Conéctate a BigQuery y Conéctate a Knowledge Catalog.

  Si los usuarios tienen acceso a varios proyectos de Google Cloud con tablas similares, especifica el ID del proyecto de destino y el nombre del conjunto de datos en una habilidad personalizada o en el campo Instrucciones adicionales del sistema del LLM de Gemini Enterprise para limitar las consultas al conjunto de datos previsto. Para obtener más información, consulta Configura el asistente.

• Conjuntos de información contextual preconfigurados: Para las aplicaciones de agentes dedicados, puedes preconfigurar el agente con una referencia explícita al conjunto de información contextual especificando el nombre del recurso del grupo de entradas (projects/PROJECT_ID/locations/LOCATION/entryGroups/CONTEXT_SET_ID) en las instrucciones del sistema o la configuración de herramientas del agente. Luego, el agente puede leer el índice raíz de entries/agents y recuperar entradas directamente de ese conjunto de contexto con ListEntries, LookupEntry o lookupContext sin la sobrecarga de la búsqueda de catálogo amplia. El agente hereda automáticamente las mejoras de calidad, ya que los flujos de trabajo de enriquecimiento recurrentes perfeccionan el conjunto de contexto con el tiempo.

  Para optimizar estas capacidades de enriquecimiento y autoaprendizaje, recomendamos especificar un modelo 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, compara 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 toda tu organización. Vincula los recursos de datos subyacentes, los términos del glosario empresarial y los registros de interacción. Puedes explorar y recorrer este grafo abierto de forma interactiva en Knowledge Studio. Para obtener más información, consulta Explora los recursos de datos en Knowledge Studio.

• Conjunto de contexto: Es una unidad de empaquetado limitada 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 lo consulten 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. Para obtener más información, consulta Acerca de los servidores de MCP en Knowledge Catalog.

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 variaciones 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 servir patrimonios de datos analíticos (como BigQuery, data lakehouse y productos de datos de Knowledge Catalog). Estos conjuntos de contexto empaquetan conocimientos más amplios y multimodales en varias categorías de entradas, incluidas las entradas de recursos de datos, los conceptos empresariales, las wikis de documentación de Markdown y las reglas de autoaprendizaje. Se seleccionan con los flujos de trabajo de enriquecimiento de Knowledge Studio y se entregan a los agentes analíticos posteriores 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 gobernanza de datos y de IA. Para obtener más información, consulta Acerca de los productos de datos.

• 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 dedicados que se aplican al proyecto o directamente al grupo de entradas context-set. Este control te permite organizar el conocimiento seleccionado por región geográfica y propiedad del dominio. Para obtener más información, consulta la sección Roles requeridos en Administra conjuntos de contexto.

• Seguridad de los datos subyacentes sin copia: Otorgar a un agente acceso 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 autónomas de enriquecimiento 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 Evalúa y aprueba propuestas de enriquecimiento.

• Identidad de ejecución administrada por el usuario: Las tareas de enriquecimiento automatizadas que completan los 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: Los conjuntos de contexto de una sola región (como us-central1) deben alinearse con la región de los recursos que empaquetan. Los conjuntos de contexto multirregionales (como us o eu) y global pueden hacer referencia a recursos en regiones compatibles. Cuando configuras una tarea de enriquecimiento para un conjunto de contexto multirregional o global, seleccionas una sola región de ejecución para la tarea.

• Una tarea de enriquecimiento por conjunto de contexto: Cada conjunto de contexto solo se puede enriquecer con una tarea de enriquecimiento.

• Referencias entre conjuntos de contexto: No se admite hacer referencia a un subconjunto de entradas de un conjunto de contexto dentro de otro conjunto de contexto.

• Interfaces de creación y consumo: Puedes crear y administrar conjuntos de contexto a través de Knowledge Studio en la consola de Google Cloud o de forma programática como grupos de entradas (type="context-set"). Los conjuntos de contexto se completan a través de los flujos de trabajo de enriquecimiento de Knowledge Studio o administrando las entradas de forma programática. 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 en Knowledge Catalog.

• 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. Para obtener más información, consulta Cuotas y límites.

Precios

Los conjuntos de información contextual se almacenan como grupos de entradas estándar de Knowledge Catalog, y entradas y aspectos personalizados. Un grupo de entradas de conjunto de contexto vacío o una solicitud de cambio de lote de enriquecimiento no aprobada no genera cargos por almacenamiento de metadatos. Cuando se crean entradas en un conjunto de contexto (por ejemplo, cuando apruebas una solicitud de cambio de enriquecimiento o creas entradas directamente), se aplican los cargos estándar de almacenamiento de metadatos de Knowledge Catalog al proyecto que aloja el grupo de entradas.

Durante la versión preliminar, la ejecución de tareas de enriquecimiento y la etapa de pruebas de las solicitudes de cambio por lotes no aprobadas se ofrecen sin cargo. Los cargos de uso estándar, incluidos el procesamiento de consultas de BigQuery y las lecturas y escrituras de etapa de pruebas de Cloud Storage, se aplican en tu proyecto cuando una tarea de enriquecimiento usa recursos opcionales administrados por el cliente, como buckets de Cloud Storage para indicadores de conocimiento o conjuntos de evaluación y tablas de seguimiento de análisis de agentes de BigQuery para el autoaprendizaje.

¿Qué sigue?