Kontextsets – Übersicht

Mit Kontextsets in Knowledge Catalog können Sie Datenschemas, semantische Definitionen und validierte Abfragemuster in begrenzten, domainspezifischen Wissenscontainern bündeln. Dieses gezielte Fachwissen bildet die Grundlage für autonome KI-Anwendungen wie Gemini Enterprise und benutzerdefinierte Agenten, damit sie mit hoher Präzision arbeiten können.

Dieses Dokument richtet sich an Datenarchitekten, Governance-Leiter und KI-Entwickler, die verstehen möchten, wie Kontext-Sets das Domainwissen für KI-Agenten strukturieren.

Was ist ein Kontextset?

Ein Kontextsatz ist eine spezielle Eintragsgruppe im Knowledge Catalog (ein logischer Container für Metadatensätze), die eine eigenständige Sammlung semantischer Informationen und Daten-Asset-Referenzen für bestimmte analytische Bereiche und KI-Agenten enthält.

In diesem Container wird das Wissen in Einträgen organisiert, die einzelne Geschäftskonzepte, Dokumente oder Daten-Assets darstellen. Diese Einträge werden mit Aspekten angereichert. Das sind modulare Metadatenattribute, in denen spezifische Details wie Geschäftsbegriffe, SQL-Vorlagen und Markdown-Dokumentation gespeichert werden.

Anstatt Agenten zu zwingen, einen gesamten Unternehmenskatalog zu durchsuchen, was zu Latenz führt, Prompt-Tokens verschwendet und das Risiko von halluzinierten Antworten birgt, richten Kontextgruppen hermetische, domänenspezifische Wissenscontainer ein, die Agenten mit hoher Präzision konsultieren können.

Da Kontextgruppen als administrative Container fungieren, können Sie Metadaten nach Projektinhaberschaft organisieren und IAM-Zugriffssteuerungsrichtlinien (Identity and Access Management) auf alle gebündelten Einträge gleichzeitig anwenden, ohne Berechtigungen einzeln konfigurieren zu müssen. Weitere Informationen zu Eintraggruppen, Einträgen und Aspekten finden Sie unter Metadatenverwaltung.

Anforderungen an die Fundierung von KI-Agenten

Wenn Unternehmen autonome KI-Agenten (wie Gemini Enterprise, Antigravity und benutzerdefinierte Agenten aus dem Agent Development Kit) bereitstellen, um Datenworkflows zu orchestrieren und Analysen zu generieren, benötigen die Agenten eine zuverlässige Fundierung:

  • Semantische Definitionen: Was bedeutet eine bestimmte Spalte oder ein bestimmter Messwert in geschäftlicher Hinsicht?
  • Validierte Abfragemuster: Wie haben Domainexperten diese Tabellen erfolgreich abgefragt und zusammengeführt?
  • Betriebsregeln: Welche Geschäftsrichtlinien, Ausnahmekriterien und Standardarbeitsanweisungen (SOPs) gelten für diese Daten?

Das folgende Architekturdiagramm zeigt, wie die vier logischen Namenskonventionen innerhalb der Grenzen der Eintraggruppe zusammenarbeiten, um nachgelagerte KI-Anwendungen zu fundieren:

Die vier Namenskonventionen innerhalb einer Kontextgrenze, die die Suche von KI-Agenten einschränken.
Abbildung 1. Die vier ausgewählten Namenskonventionen innerhalb einer Kontextsatz-Eintragsgruppe.

Ein Kontext-Set erfordert nicht unbedingt jeden Eintragstyp, um zu funktionieren. Wir empfehlen jedoch, Ihre Einträge nach den folgenden logischen Namenskonventionen zu organisieren. Durch die Verwendung dieser Namenskonventionen können Menschen und autonome Agenten Wissen konsistent finden und interpretieren:

Namensmuster Eintragstyp Beschreibung und Zweck Angehängte Aspekte
Geschäftskonzepte concepts_<id> generic Begriffe aus dem Unternehmensglossar, Messwertdefinitionen, Akronyme und Berechnungsformeln. glossary-term-aspect, contacts.
Dokumente documents_<path> document Narrativer Kontext, Standardarbeitsverfahren (SOPs), Onboarding-Wikis und Verweise auf externe Dokumentation. Document, overview (RTF-Markdown und Links).
Abfragevorlagen query-templates_<path> query-template Vorab validierte, parametrisierte SQL-Abfragevorlagen, hochfrequente Join-Logik und Ausführungsmuster. query-template (enthält Felder wie Quellen, Absicht, nlQuery, Parameter und Abfrage).
Semantische Modelle semantic-models_<id> semantic-model, semantic-entity, semantic-metric Formale relationale Modelle, Entitätsdefinitionen, dimensionale Hierarchien und Messwerte. semantic-model, semantic-entity, semantic-metric.

Geschäftskonzepte

Ein Eintrag für ein Geschäftskonzept (Eintrag vom Typ „generic“ mit der Namenskonvention concepts_*) definiert standardisierte Geschäftsterminologie, Domainmesswerte, Akronyme und Berechnungsformeln (glossary-term-aspect).

Zu den wichtigsten Funktionen gehören:

  • Terminologieabgleich: Beseitigt Unklarheiten bei der Terminologie in Geschäftsbereichen und Analyseteams.
  • KPI-Formeln: Enthält mathematische Formeln und Logik für domainspezifische Leistungskennzahlen (KPIs).
  • Organisatorische Inhaberschaft: Legt eine klare organisatorische Inhaberschaft durch angehängte Governance-Aspekte (contacts) fest.

In einem E-Commerce-Kontextset gibt ein Eintrag unter concepts_net_items_sold beispielsweise die genaue Berechnung der verkauften Nettoeinheiten an. Wenn ein KI-Agent einen Prompt erhält, in dem nach „netto verkauften Artikeln“ gefragt wird, greift er auf den Konzepteintrag zurück, um die verifizierte Berechnung anzuwenden, anstatt SQL-Logik zu erfinden.

Beispiel für eine Ressourcendarstellung:

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."

Dokumente

In einem Dokumenteintrag (Eintrag vom Typ „Dokument“ mit der Namenskonvention documents_*) werden beschreibende und prozedurale Kontexte in strukturiertem Markdown (Document, overview) gespeichert.

Zu den wichtigsten Funktionen gehören:

  • Standardarbeitsanweisungen (SOPs): Erfasst SOPs, Runbook-Checklisten und Onboarding-Leitfäden direkt im Katalog.
  • Compliance-Richtlinien: Dokumentiert Compliance-Richtlinien, regulatorische Einschränkungen (z. B. DSGVO- oder HIPAA-Verarbeitungsregeln) und Ausnahmekriterien.
  • Externe Referenz-Wikis: Verweist über Quell-URI-Zeiger (overview-Links) auf externe, dynamische Wikis (z. B. Google-Dokumente, Atlassian Confluence, Notion oder GitHub).

Ein Kontextset für Bekleidung enthält beispielsweise documents_return_policy_rules, um Agenten anzuweisen, wie sie abgeschlossene Verkäufe und beim Transport beschädigte Artikel bei der Berechnung der Standardrückgaberaten ausschließen.

Beispiel für eine Ressourcendarstellung:

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..."

Abfragevorlagen

Ein Abfragevorlageneintrag (Eintrag vom Typ query-template mit der Namenskonvention query-templates_*) enthält von Menschen geprüfte, parametrisierte SQL-Abfragen, die gängigen analytischen Intents in natürlicher Sprache zugeordnet sind (mit dem Aspekt query-template).

Zu den wichtigsten Funktionen gehören:

  • Vorab validierte Abfragen: Speichert vorab validierte Join-Pfade, Filterbedingungen und Aggregationsmuster für häufig gestellte Geschäftsfragen.
  • Laufzeitparametrisierung: Unterstützt die Ersetzung von Laufzeitparametern (z. B. @start_date, @region und @limit) für die dynamische Agentenausführung.
  • Fehlervermeidung: Verhindert halluzinierte Tabellenverknüpfungen und Syntaxfehler im SQL-Dialekt.

Wenn ein KI-Agent beispielsweise eine Frage zu den leistungsstärksten Konten beantworten muss, gleicht er query-templates_sales_top_accounts_by_arr ab und ersetzt den angeforderten Datumsbereich in der verifizierten SQL-Vorlage.

Beispiel für eine Ressourcendarstellung:

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"

Semantische Modelle

Einträge für semantische Modelle (mit den Eintragstypen semantic-model, semantic-entity und semantic-metric und der Namenskonvention semantic-models_*) formalisieren relationale Strukturen, dimensionale Hierarchien und Aggregationsmesswerte über normalisierte Tabellen hinweg.

Zu den wichtigsten Funktionen gehören:

  • Relationale Definition: Definiert Primärschlüssel, Fremdschlüssel und Join-Kardinalitäten (z. B. 1:n- oder n:n-Beziehungen).

  • Zuordnung von Geschäftsdimensionen: Ordnet zugrunde liegende Rohspalten Geschäftsdimensionen, Zeitintervallen und wiederverwendbaren Messwerten zu.

  • Anleitung für KI-Agenten: Leitet autonome KI-Agenten beim Erstellen komplexer analytischer Abfragen über mehrere Tabellen hinweg an, wenn keine genaue Abfragevorlage vorhanden ist.

  • Abstraktion der zugrunde liegenden Komplexität: Im Gegensatz zu rohen Schema-Join-Eintragslinks, die nur mechanische Tabellenverbindungen im Quelldatensatz dokumentieren, arbeiten semantische Modelle auf der logischen Geschäftsebene, um zu verhindern, dass der KI-Agent falsche ER-Diagramm-Traversierungen halluziniert.

In einem Kontextset für Bekleidung wird beispielsweise semantic-models_apparel_sales_model verwendet, um zu definieren, wie warehouses, shipments und line_items über Fakten- und Dimensionstabellen im Sternschema verknüpft werden.

Beispiel für eine Ressourcendarstellung:

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"

Beispiel: Kontext für einen Online-Bekleidungsshop

Sehen wir uns an, wie die vier Namenskonventionen zusammenarbeiten. Ein Online-Bekleidungshändler stellt einen KI-Assistenten für die Merchandiser des Geschäfts bereit. Ohne begrenzten Kontext könnte der Agent Roh-Staging-Tabellen abfragen oder beliebte Artikel falsch zählen, weil er Kundenretouren nicht abzieht.

Um den Agenten zu fundieren, erstellt ein Data Steward ein Kontextset mit dem Namen 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)

Wie ein KI-Agent einen Prompt löst

Wenn ein Merchandiser den Agenten fragt: „Was waren unsere fünf meistverkauften Winterjackenstile, ausgenommen beschädigte Rücksendungen?“, löst der Agent den Prompt über den festgelegten Kontext auf:

  1. Abfragevorlagensuche: Der Agent prüft query-templates_* und gleicht query-templates_top_categories_by_season ab, wobei @season = 'Winter' und @limit = 5 ersetzt werden.

  2. Konzeptüberprüfung: Der Agent prüft concepts_net_items_sold und concepts_bestseller, um zu bestätigen, dass zurückgegebene Artikel von der Gesamtbestellmenge abgezogen werden müssen.

  3. SOP-Regel erzwingen: Der Agent liest documents_return_policy_rules und fügt die Filterbedingung WHERE return_reason != 'DAMAGED_IN_TRANSIT' hinzu.

  4. Schema- und Join-Validierung: Der Agent verwendet semantic-models_apparel_sales_model und die verknüpften @bigquery-Tabellen, um store.orders, store.products und store.returns mithilfe verifizierter Fremdschlüssel zu verknüpfen, und führt die SQL-Abfrage aus.

Architekturfunktionen

Kontextsätze bieten mehrere wichtige Funktionen für Unternehmensdatenumgebungen:

  • Hermetische Ausführungsgrenzen: Durch die Begrenzung des Kontexts auf eine ausgewählte Gruppe von Assets und semantischen Einträgen arbeiten KI-Agenten in einer hermetischen Sandbox. Dadurch werden irrelevante Katalogdaten eliminiert, deterministische Bewertungen ermöglicht und die Tokennutzung minimiert.

  • Schneller Upload und Bulk-Indexierung: Teams können Sätze von Konzepten, Abfragen und Dokumenten als einen einzigen atomaren Vorgang hochladen und indexieren. So können Sie sie in CI/CD-Pipelines (Continuous Integration und Continuous Deployment) einbinden.

  • Zero-Copy-Paketierung: Kontext legt Paketmetadaten und Beziehungen fest, ohne den zugrunde liegenden Datenspeicher zu kopieren oder zu verschieben. Dadurch werden redundante Speicherkosten und Verzögerungen bei der Datensynchronisierung vermieden.

Beratungsmuster für KI-Agenten

Nachgelagerte Agenten nutzen Kontextsets über das Model Context Protocol (MCP) oder direkte Knowledge Catalog APIs. Weitere Informationen finden Sie unter Datenkontext mit den Catalog APIs abrufen. Um die Antwortlatenz zu optimieren und den Tokenverbrauch zu minimieren, folgen Agenten einer dreistufigen Konsultationshierarchie:

  1. Abgleich von Abfragevorlagen: Der Agent sucht in query-templates_*. Wenn eine verifizierte Vorlage dem Intent des Nutzers entspricht, parametrisiert der Agent die Abfrage und führt sie direkt aus. Dies bietet die schnellste Antwort mit einem Risiko von nahezu null für Abfragefehler.

  2. Semantisches Modell zusammenstellen: Wenn keine Abfragevorlage übereinstimmt, wertet der Agent semantic-models_* aus, um Entitätsbeziehungen zu verstehen und eine SQL-Anweisung mit mehreren Tabellen zu erstellen.

  3. Dokument- und Konzeptberatung: Bei unklaren Grenzfällen (z. B. Fristen für das Geschäftsjahr oder Ausschlüsse von Streitfällen) liest der Agent concepts_* und documents_*, um Geschäftsregeln anzuwenden.

Kontext in generativen KI-Anwendungen nutzen

Anwendungen mit generativer KI verwenden kuratierte Kontextsets, um die Semantik von Unternehmensdomains zu verstehen, komplexe Schemas zu verarbeiten und zuverlässigen SQL-Code ohne Halluzinationen zu generieren. Anwendungen nutzen diese Kontextgruppen in der Regel über zwei primäre Muster:

  • Dynamische Kontexterkennung: In konversationellen oder Self-Service-Analyseumgebungen stellen Nutzer Ad-hoc-Fragen in natürlicher Sprache. Die Anwendung wertet die Absicht des Nutzers dynamisch aus, um den relevantesten Kontextsatz aus dem Knowledge Catalog zu identifizieren und abzurufen. Das abgerufene Domainwissen wird dann in den aktiven Prompt eingefügt.

  • Vorkonfigurierte Kontextgruppen: Für dedizierte KI-Agentenanwendungen können Sie den KI-Agenten mit einem expliziten Verweis auf eine Kontextgruppe vorkonfigurieren, indem Sie den Ressourcen-URI angeben. Durch das Binden eines dedizierten Kontextsets wird eine deterministische Fundierung ermöglicht. So wird sichergestellt, dass bei allen Interaktionen zertifizierte Geschäftsdefinitionen ohne Laufzeit-Suchaufwand verwendet werden. Der Agent übernimmt automatisch Qualitätsverbesserungen, da wiederkehrende Anreicherungsworkflows den Kontext im Laufe der Zeit verfeinern.

    Um diese Anreicherungs- und selbstlernenden Funktionen zu optimieren, empfehlen wir, in der Gemini Enterprise-Anwendung ein Gemini 3.8 Flash- oder ein neueres Modell anzugeben. Weitere Informationen zu den Schritten für die Modellauswahl finden Sie im Abschnitt „Agenten mit dem Flow Builder erstellen“ unter Agenten in Agent Studio entwerfen.

Kontextgruppen im Vergleich zu ähnlichen Konstrukten

Wenn Sie das richtige Metadatenkonstrukt für Ihre Architektur auswählen möchten, lesen Sie, wie sich Knowledge Catalog-Kontextsets im Vergleich zu ähnlichen Plattformfunktionen verhalten.

Kontextsets im Vergleich zu Kontextdiagrammen

Der Kontextgraph und die Kontextsets sind zwei separate Konstrukte mit unterschiedlichen Rollen in der Knowledge Studio-Architektur:

  • Kontextdiagramm: Die umfassende semantische Live-Topologie in Ihrer Organisation. Es verknüpft zugrunde liegende Daten-Assets, Begriffe aus dem Unternehmensglossar und Interaktions-Traces. Sie können diesen offenen Graphen interaktiv in der Explore-Oberfläche erkunden und durchlaufen.

  • Kontextset: Eine begrenzte, regionale und kuratierte Verpackungseinheit. Dabei wird eine bestimmte Teilmenge des Domainwissens extrahiert und hermetisch in einer Eintragsgruppe (type="context-set") verpackt, damit nachgelagerte KI-Agenten sie über das Model Context Protocol (MCP) abfragen können. Ein Kontextset fungiert als zusammenhängender, hochdichter Untergraphen innerhalb des größeren Kontextgraphen.

Knowledge Catalog-Kontextsets im Vergleich zu Datenbank-Kontextsets

Sowohl Knowledge Catalog als auch operative Datenbanken von Google Cloudverwenden den Begriff Kontextsatz, um sich auf ausgewählte Informationen zu beziehen, die als Grundlage für generative KI-Modelle dienen.

Beide Varianten haben dieselbe zugrunde liegende Architektur. Sie werden nativ als Knowledge Catalog-Kontextsätze (erweiterbare Eintraggruppen mit type="context-set") gespeichert und verwenden Standard-Knowledge Catalog APIs. Sie richten sich jedoch an unterschiedliche Ebenen des Unternehmensdatenstacks:

  • Datenbankkontextsätze (QueryData): Entwickelt für operative, transaktionale Datenbanken (wie AlloyDB for PostgreSQL, Cloud SQL und Spanner). Diese Kontextsets sind stark für SQL-Konfigurationen optimiert. Sie bündeln Golden Query-Vorlagen, Schemametadaten und Filterfacetten, die von einem dedizierten Kontext-Engineering-Agenten ausgewertet werden, um die Übersetzung von natürlicher Sprache in SQL (NL2SQL) in operativen Laufzeiten zu verbessern.
  • Knowledge Catalog-Kontextsätze (Knowledge Studio): Entwickelt für analytische Datenbestände (z. B. BigQuery, Data Lakehouses und Knowledge Catalog-Datenprodukte). Diese Kontextsets bündeln umfassenderes, multimodales Wissen über mehrere Namenskonventionen hinweg, einschließlich Geschäftskonzepten, Markdown-Dokumentationswikis und semantischen Modellen. Sie werden mithilfe von Anreicherungsworkflows in Knowledge Studio kuratiert und über das Model Context Protocol (MCP) an nachgelagerte Analyse-Agents weitergegeben.

Kontextsätze im Vergleich zu Datenprodukten

Wenn Sie wissen, wie Kontext-Sets mit Datenprodukten von Knowledge Catalog interagieren, können Sie klare Grenzen für die Daten- und KI-Governance festlegen:

  • Datenprodukte verwalten die zugrunde liegenden Ressourcen: Datenprodukte bündeln konkrete Ressourcen wie BigQuery-Tabellen, Buckets und Streams auf sichere Weise und bilden eine primäre Einheit für die Datenweitergabe, Datenverträge und die Zugriffssteuerung auf Datenebene.

  • Kontext-Sets bündeln die Semantik von Konversationen: Kontext-Sets gewähren keinen Datenzugriff, sondern bündeln Domänenwissen wie Konzepte, Abfragevorlagen und Dokumente, die von KI-Agenten und Menschen benötigt werden, um die Daten zu verstehen. Data Stewards können einen Kontextsatz mit einem Datenprodukt verknüpfen, indem sie ihn in den additional_context-Referenzen des Produkts deklarieren.

Sicherheit und Governance für Unternehmen

Kontextsätze lassen sich in die Sicherheits- und Governance-Einstellungen von Google Cloud einbinden, um sensible Unternehmensmetadaten zu schützen:

  • IAM-Rollen für Kontextgruppen: Da Kontextgruppen häufig vertrauliche semantische Informationen enthalten, unterliegt der Zugriff IAM-Rollen, die direkt auf die context-set-Eintragsgruppe angewendet werden. So können Sie kuratiertes Wissen nach geografischer Region und Domaininhaberschaft organisieren und Domain-Stewards Änderungsberechtigungen sowie KI-Agenten Leseberechtigungen erteilen. Zum Erstellen einer Kontextgruppe benötigen Sie die IAM-Berechtigung dataplex.entryGroups.setIamPolicy. Diese Berechtigung ist erforderlich, damit Ihnen beim Erstellen des Kontextsets automatisch Inhaberberechtigungen gewährt werden. Sie können diese Berechtigung über vordefinierte Rollen wie Dataplex Catalog Admin (roles/dataplex.catalogAdmin) oder Dataplex Entry Group Owner (roles/dataplex.entryGroupOwner) erhalten.

  • Sicherheit der zugrunde liegenden Daten ohne Kopieren: Wenn Sie einem KI-Agenten Zugriff auf einen Kontextsatz gewähren, kann er semantische Metadaten und Abfragevorlagen lesen. Die Zugriffssteuerung für die zugrunde liegenden Tabellen wird jedoch nicht umgangen. Wenn Sie eine SQL-Abfrage für BigQuery ausführen oder Dateien in Cloud Storage lesen möchten, muss die Identität, die die Abfrage ausführt, die erforderlichen IAM-Berechtigungen auf Datenebene für diese zugrunde liegenden Ressourcen haben.

  • Human-in-the-Loop-Governance: Wenn autonome Knowledge Studio-Anreicherungsaufgaben neue Konzepte, SOPs oder Abfragevorlagen aus Betriebsprotokollen extrahieren, werden die Vorschläge als überprüfbare Änderungsanfragen bereitgestellt. Data Stewards prüfen Diff-Vergleiche und Bewertungsergebnisse, bevor sie Änderungen an einem Produktionskontextset genehmigen. Weitere Informationen zur Überprüfung von Angeboten finden Sie unter Anfragen verwalten.

  • Nutzerverwaltete Ausführungsidentität: Automatisierte Anreicherungsaufgaben, die Kontextsets füllen, werden unter einem nutzerverwalteten Dienstkonto ausgeführt, dessen Identität der Dataplex-Dienst-Agent über die Rolle Ersteller von Dienstkonto-Tokens (roles/iam.serviceAccountTokenCreator) übernimmt.

Umfang und Grenzen der Vorabversion

In der Vorabversion gelten für Kontextgruppen die folgenden Einschränkungen:

  • Regionaler Bereich: Globale Kontextgruppen, die mit regionalen Daten-Assets verknüpft sind, werden nicht unterstützt. Ein Kontextset muss mit den regionalen Grenzen der Assets übereinstimmen, die es enthält.

  • Oberflächen für Erstellung und Nutzung: Sie können Kontextgruppen über den Knowledge Studio-Container in der Google Cloud Console erstellen und sie so logisch von Standard-Administratoreintragsgruppen in Knowledge Catalog trennen. Sie können Kontextgruppen automatisch über Knowledge Studio-Anreicherungsworkflows füllen. Nachgelagerte KI-Agenten können Kontextsets programmatisch über die Knowledge Catalog APIs (ListEntries und LookupEntry) und das Model Context Protocol (MCP) finden und abfragen. Weitere Informationen finden Sie unter MCP-Server.

  • Abrechnung: Knowledge Catalog berechnet keine separate eigenständige SKU für das Erstellen von Kontextset-Eintragsgruppen.

  • Gemeinsame Kontingente: Da Kontextgruppen im Grunde spezialisierte Eintragsgruppen (type="context-set") sind, verbrauchen und teilen sie dieselben Ressourcenkontingente wie Standard-Eintragsgruppen in Knowledge Catalog.

Nächste Schritte

Konzept

Hier erfahren Sie, wie Sie umfangreichen Datenkontext orchestrieren, Kontextsets erstellen und KI-Agenten mithilfe von Knowledge Studio-Schnittstellen fundieren.

Aufgabe

Mit dem visuellen Canvas in Knowledge Studio können Sie mit Ihren Daten chatten und semantische Beziehungen nachverfolgen.

Konzept

Nachvollziehen, wie Einträge, Eintraggruppen und Aspekte die strukturelle Grundlage von Kontextgruppen bilden.

Konzept

Kontextsätze und umfangreiche Metadaten für nachgelagerte generative KI-Agenten über MCP bereitstellen.

Aufgabe

Kontextsets für das Reasoning mit generativer KI programmatisch mit den APIs „ListEntries“ und „LookupEntry“ erkennen und abrufen.

Aufgabe

Informationen zum Erstellen, Ansehen, Bearbeiten und Löschen von Kontextgruppen in der , um Domainwissen zu organisieren.