Pragmatisches RAG: Testen von Googles Open Knowledge Format (OKF)

Wenn Sie KI-Agenten in eine echte Codebasis integriert haben, sind Sie wahrscheinlich an die Grenzen der einfachen Vektorsuche gestoßen.

Sie bitten einen Agenten, einen API-Endpunkt zu refaktorieren, und er ruft den Funktionskörper über die Vektorsuche ab. Dabei fehlen jedoch das Datenbankschema, die Authentifizierungs-Middleware und das Bereitstellungs-Handbuch, da sie im Einbettungsraum nicht genügend semantische Überlappung aufwiesen.

Der Agent scheitert, weil er in einem Kontextvakuum arbeitet.

Um dieses Problem der „Kontextzusammenstellung“ zu lösen, hat Google Cloud die Open Knowledge Format (OKF) Spezifikation veröffentlicht. Es ist ein herstellerneutraler Standard, um ein Verzeichnis von Textdateien in einen semantischen Wissensgraphen umzuwandeln, den KI-Agenten rekursiv navigieren können.

Hier ist meine praktische Erfahrung mit der Implementierung.

Das Konzept: Was ist OKF?

OKF formalisiert das, was viele Plattformteams ohnehin schon getan haben: Die Strukturierung der internen Dokumentation als Verzeichnisstruktur aus reinen Markdown-Dateien mit YAML-Frontmatter.

Anstatt proprietäre Graphdatenbanken oder komplexe Vektorindizierungs-Pipelines einzuführen, basiert OKF auf zwei Webstandards:

YAML-Frontmatter für Metadaten auf Dateiebene (Deklaration, was eine Datei ist).
Standard-Markdown-Links zur Deklaration von Beziehungen zwischen Dateien.

Indem Sie Dateien direkt im Text verlinken, verwandeln Sie Ihre Dokumentation in einen Wissensgraphen. Jeder Agent, der eine Datei analysiert, kann diesen Links folgen wie ein Webcrawler.

Ein konkretes Beispiel

In einem Repository für ein UI-Komponentenbibliothek oder ein Designsystem könnte die OKF-Wissensdatenbank so strukturiert sein:

/knowledge-base
  ├── components/
  │   └── interactive-modal.md
  ├── compliance/
  │   └── wcag-checklist.md
  └── tokens/
      └── theme-palette.md

Jede dieser Dateien beginnt mit einem minimalen Frontmatter-Block. Die Spezifikation ist schlank; das einzige erforderliche Feld ist type.

Hier ist der YAML-Header für interactive-modal.md:

---
type: "ui-component"
title: "Interactive Modal Dialog"
description: "Accessibility-compliant overlay specification supporting dynamic focus trapping and theme tokens."
timestamp: "2026-07-06T12:00:00Z"
tags: ["react", "wcag", "accessibility", "design-system"]
---

Und im Markdown-Inhalt definieren wir Beziehungen über relative Links:

The Modal component manages overlays and traps keyboard focus internally. 
For semantic HTML and ARIA attribute rules, refer to the [WCAG AA Compliance Checklist](../compliance/wcag-checklist.md).
To style backdrop filters and component states, import design tokens from the [Theme Palette Config](../tokens/theme-palette.md).

Wie Agenten den Graphen durchlaufen

Traditionelles RAG sucht nach Schlüsselwörtern oder Vektoren, ruft die besten 5 Abschnitte ab und fügt sie in den Prompt ein.

OKF ermöglicht eine traversierende RAG-Strategie:

Auswahl des Einstiegspunkts: Der Agent findet das erste Dokument (z. B. interactive-modal.md).
Rekursives Parsen: Der Agent liest den Header und extrahiert alle relativen Links.
Kontextzusammenstellung: Der Agent lädt rekursiv die verlinkten Dateien (WCAG-Richtlinien und Design-Tokens), um den vollständigen Kontext aufzubauen, bevor er React-Code schreibt.

Fazit: Lohnt es sich?

Die Vorteile:

Kein Vendor-Lock-in: Es ist nur Markdown.
Git-kompatible Versionierung: Dokumentations-Updates laufen über Standard-Pull-Requests.
Agenten-Unabhängigkeit: Agenten benötigen nur einen Markdown-Parser.

Die Nachteile:

Kaputte Links: relative Links können brechen. Sie sollten einen Linter in Ihrer CI-Pipeline verwenden.
Wartungsaufwand: Entwickler müssen YAML-Header und Links aktuell halten.