Zurück zum Journal
•6 Min. Lesezeit

Weiterentwicklung des Google Open Knowledge Format auf v0.2: Agenten-Vertrauen und Signale

Wie OKF v0.2 Agenten-Vertrauen, Provenienz, Vertrauensstufen, Veraltung und überprüfte Berechnungen in KI-Wissensgraphen umsetzt.

Google CloudAI AgentsRAGOKFBigQueryData Engineering
Weiterentwicklung des Google Open Knowledge Format auf v0.2: Agenten-Vertrauen und Signale

Als ich unsere erste Implementierung des Open Knowledge Format von Google in Implementing Google's Open Knowledge Format (OKF) in Practice dokumentierte, bestand das Hauptziel darin, die Kontextisolation für KI-Agenten zu lösen. Durch die Strukturierung einfacher Markdown-Dateien in einen navigierbaren, verknüpften Graphen mit YAML-Frontmatter konnten Agenten Dokumentationsbäume rekursiv durchlaufen, anstatt sich auf ungenaue Vektorsuchen zu verlassen.

OKF v0.1 schuf eine solide Basis: Standard-Markdown, leichtgewichtige YAML-Metadaten (type, title, description, tags) und explizite relative Links.

Als Plattformeinzelsysteme jedoch von menschlich verfasster Dokumentation zu autonomen Multi-Agenten-Systemen übergingen, entstand eine fundamentale Herausforderung: Wenn KI-Agenten über Nacht kontinuierlich Tausende von Wissenskonzepten schreiben und aktualisieren, wie können nachgelagerte Agenten oder Menschen diesem Korpus vertrauen?

Menschlich verfasste Dokumentation bietet eine implizite Vertrauensgarantie – ein Entwickler hat sie geschrieben und übernimmt die Verantwortung für ihre Richtigkeit. Wenn ein Agent autonom 10.000 Tabellendefinitionen, Metrikspezifikationen und Runbooks generiert, löst sich diese Garantie auf.

Um diese Herausforderung anzugehen, hat Google Cloud die Open Knowledge Format (OKF) v0.2 Spezifikation veröffentlicht. Dieses Update führt strukturierte Agenten-Vertrauenssignale und überprüfte Berechnungen (Attested Computations) direkt in den YAML-Frontmatter ein, ohne die Abwärtskompatibilität zu v0.1 zu beeinträchtigen.

Vom Beschreiben des Kontexts zum Entscheiden über Vertrauen

In OKF v0.1 beantworteten Frontmatter-Metadaten beschreibende Fragen: Was ist dieser Knoten, welche Tags beschreiben ihn und worauf verweist er?

OKF v0.2 führt Entscheidungsfelder (deciding fields) ein – Metadaten, die entwickelt wurden, um Ursprung, Aktualität und Autorität eines Knotens zu bewerten, bevor ein Agent Kontext-Token für das Lesen des Markdown-Bodys ausgibt.

Den vollständigen Text Tausender Dokumentationsknoten zu analysieren, um das Vertrauen zu bewerten, ist rechentechnisch teuer. Die Anhebung von Vertrauenssignalen in den Frontmatter ermöglicht es Agenten und deterministischen Systemen, unverifizierte, veraltete oder veraltete Konzepte während des Graphdurchlaufs kostengünstig herauszufiltern.

OKF Concept Frontmatter
├── Describing Fields (v0.1)  ──> type, title, description, resource, tags
└── Deciding Fields   (v0.2)  ──> generated, verified, status, stale_after, sources

Die 5 Kern-Vertrauenssignale in OKF v0.2

OKF v0.2 definiert fünf standardisierte Metadatenfamilien, die kritische Fragen zu jedem Wissenskonzept beantworten:

1. Provenienz (sources)

Anstatt eine willkürliche Vertrauensbewertung zuzuweisen, zeichnet OKF v0.2 rohe Provenienzsignale in einem sources-Array auf. Einträge können auf externe Dokumentation, relative Paketpfade oder Datenbankbereiche verweisen, angereichert mit Glaubwürdigkeitsmarkern (author, usage_count, last_modified).

Im Haupttext verweisen spezifische Aussagen über Standard-Markdown-Fußnoten auf diese Quellen (z. B. [^warehouse-schema]):

sources:
  - id: warehouse-schema
    resource: https://wiki.acme.internal/data/warehouse/schemas/sales
    title: Acme Retail Warehouse Schema
    author: team:data-platform
    usage_count: 1240
    last_modified: 2026-06-15
  - id: revenue-policy
    resource: policies/revenue-recognition.md
    title: Revenue Recognition Policy (FY2026)
    author: human:jsmith@acme
    last_modified: 2026-06-15

2. Vertrauensstufen (generated vs verified)

OKF v0.2 trennt explizit die Erstellung eines Konzepts von dessen Bestätigung:

  • generated: { by, at }: Zeichnet die erstellerische Entität (z. B. reference_agent/gemini-2.5-pro) und den Zeitstempel auf.
  • verified: [ { by, at } ]: Zeichnet unabhängige Prüfungen durch automatisierte Prozesse oder menschliche Freigaben auf.

Aus diesen Feldern leiten Konsumenten drei Vertrauensstufen (Trust Tiers) ab:

  1. Unverifiziert (Unverified): Der Schlüssel verified fehlt.
  2. Maschinell bestätigt (Machine-Confirmed): Strenge Überprüfung durch automatisierte Hintergrundwerkzeuge (z. B. nächtliche CI/CD-Linter).
  3. Menschlich geprüft (Human-Reviewed): Explizit von einer menschlichen Person freigegeben (z. B. human:kliu@acme).
generated: 
  by: reference_agent/gemini-2.5-pro
  at: 2026-06-30T14:00:00Z
verified:
  - by: human:jsmith@acme
    at: 2026-07-01T09:00:00Z

Eine Pipeline für Vorstandsberichte kann gezielt nach human-reviewed Metriken filtern, während eine Staging-Umgebung auch machine-confirmed Konzepte akzeptiert.

3. Aktualität (stale_after)

Anstelle relativer TTL-Dauern (z. B. "gültig für 30 Tage") verwendet OKF v0.2 ein absolutes ISO-8601-Datum (z. B. stale_after: 2026-12-31).

Relative TTLs hängen davon ab, wann ein Konzept abgerufen wurde, was zu nicht-deterministischem Agentenverhalten führt. Absolute Daten ermöglichen einfache Datumsvergleiche: Überschreitet der aktuelle Systemzeitstempel stale_after, wird das Konzept vor der Bereitstellung zur Neuüberprüfung markiert.

4. Lebenszyklus (status)

Konzepte durchlaufen explizite Lebenszyklus-Zustände: draft → stable → deprecated (Standard ist stable).

Wenn sich die Geschäftslogik weiterentwickelt – beispielsweise bei der Aktualisierung einer Kostenzuordnungsformel –, wird die vorherige Definition als status: deprecated markiert. Dies bewahrt die historische Abfragereproduzierbarkeit und verhindert gleichzeitig, dass Agenten veraltete Metriken auf neue Aufgaben anwenden:

type: Metric
title: Gross Margin (Legacy, pre-FY2026)
status: deprecated

Überprüfte Berechnungen: Verhindern von improvisierten Agenten-SQL-Abfragen

Provenienz und Verifizierung bestätigen, dass eine Metrikdefinition den Unternehmensrichtlinien entspricht. Wenn ein Agent jedoch eine Finanzmetrik meldet (z. B. den Jahresumsatz), bleibt ein gefährliches Fehlerszenario bestehen: Der Agent könnte seine eigene SQL-Abfrage improvisieren.

OKF v0.2 führt einen neuen Konzepttyp ein: Attested Computation. Er definiert sowohl die zulässige Berechnung als auch einen Mechanismus zur Überprüfung, ob die ausgeführte Abfrage der festgelegten Definition entspricht.

      ┌─────────────────────────────────────────────────────────┐
      │               Attested Computation Node                 │
      │  - runtime: bigquery                                    │
      │  - parameters: [year]                                   │
      │  - executor: skills/run-on-bq.md                        │
      │  - attester: attesters/sql_equality.py                  │
      └──────────────────────────┬──────────────────────────────┘
                                 │
                 1. Binds declared parameters
                 2. Executes sanctioned SQL
                                 ▼
                      ┌─────────────────────┐
                      │ Execution Receipt   │
                      │ - job_id            │
                      │ - executed_sql      │
                      │ - result            │
                      └──────────┬──────────┘
                                 │
                 3. Deterministic AST verification
                                 ▼
                      ┌─────────────────────┐
                      │  Attester Verdict   │
                      │  - OK / REJECTED    │
                      └─────────────────────┘

Produktionsbeispiel: BigQuery Umsatz-Überprüfung

Unten ist ein Attested Computation-Knoten nach OKF v0.2 für den BigQuery-Jahresumsatz dargestellt:

---
type: Attested Computation
title: Revenue for a Fiscal Year
runtime: bigquery
parameters:
  - { name: year, type: integer, required: true }
executor:
  resource: skills/run-on-bq.md
receipt: [job_id, executed_sql, result]
attester:
  resource: attesters/sql_equality.py
generated:
  by: reference_agent/gemini-2.5-pro
  at: 2026-06-30T14:00:00Z
verified:
  - by: human:jsmith@acme
    at: 2026-07-01T09:00:00Z
status: stable
stale_after: 2026-12-31
sources:
  - id: revenue-policy
    resource: policies/revenue-recognition.md
    title: Revenue Recognition Policy (FY2026)
    author: human:jsmith@acme
    last_modified: 2026-06-15
---

# Computation

```sql
SELECT
  SUM(
    CASE 
      WHEN o.currency = 'USD' THEN o.net_amount
      ELSE o.net_amount * fx.rate_to_usd
    END
  ) AS revenue_usd
FROM `acme.sales.orders` AS o
LEFT JOIN `acme.finance.fx_daily_rates` AS fx
  ON fx.currency = o.currency 
 AND fx.rate_date = DATE(o.order_ts)
WHERE o.order_status = 'delivered'
  AND DATE_DIFF(CURRENT_DATE(), DATE(o.order_ts), DAY) >= 30
  AND EXTRACT(YEAR FROM o.order_ts) = @year

Wie die Überprüfung abläuft

  1. Reine Parameterbindung: Der Agent ist darauf beschränkt, die deklarierten Parameter (@year) zu übergeben. Er kann den SQL-Text weder bearbeiten noch benutzerdefinierte WHERE-Klauseln hinzufügen.
  2. Ausführungsbeleg: Die Ausführungsschicht gibt einen signierten Beleg zurück, der job_id, executed_sql und result enthält.
  3. Deterministische Überprüfung: Ein externes Python-Skript (sql_equality.py) analysiert sowohl das Ziel-SQL als auch executed_sql in abstrakte Syntaxbäume (AST). Weichen Schlüsselwörter, Tabellen-JOINs oder Filterbedingungen ab, schlägt die Überprüfung fehl und das Ergebnis wird verworfen.

Abwärtskompatibilität und Migration

OKF v0.2 ist als vollständig additive und abwärtskompatible Version konzipiert. Bestehende v0.1-Pakete bleiben ohne Änderungen gültig.

Zu den wichtigsten Schema-Entwicklungen gehören:

  • timestamp wird durch generated.at ersetzt.
  • Zitierabschnitte in Markdown (# Citations) werden durch das strukturierte sources-Array im YAML-Frontmatter ersetzt.
  • In beiden Fällen greifen v0.2-Parser direkt auf v0.1-Felder zurück, wenn die neuen Schlüssel fehlen.
// OKF v0.2 Parser-Rückfallmuster
const creationTime = frontmatter.generated?.at ?? frontmatter.timestamp;
const documentSources = frontmatter.sources ?? parseLegacyCitations(markdownBody);

Fazit

Die OKF v0.2-Spezifikation von Google verwandelt einfache Markdown-Wissensdatenbanken in überprüfbare agentische Graphnetzwerke:

  1. Entscheiden statt Beschreiben: In den Frontmatter gehobene Metadaten ermöglichen eine kostengünstige Vertrauensfilterung vor dem Laden von Texten.
  2. Explizite Vertrauensstufen: Klare Trennung zwischen generated- und verified-Metadaten zur Offenlegung menschlicher Freigaben gegenüber automatischen Bestätigungen.
  3. Deterministische Aktualität: Absolute stale_after-Daten verhindern nicht-deterministische TTL-Auswertungen.
  4. Überprüfte Berechnungen: Die Kombination aus parametergebundener Ausführung und AST-Gleichheitsprüfern eliminiert SQL-Halluzinationen von Agenten.

Durch die Übernahme von OKF v0.2-Standards können Plattformeinzelsysteme autonome KI-Workflows sicher skalieren und gleichzeitig eine strenge Data Governance und Überprüfbarkeit gewährleisten.

Share this article