Pragmatische RAG: Google's Open Knowledge Format (OKF) testen
Vectoren zoeken alleen lost het probleem van contextassemblage voor AI-agenten niet op. Hier leest u hoe ik de documentatie van een repository heb gestructureerd als een navigeerbare markdown-graaf met behulp van de OKF-specificatie.

Als u AI-agenten in een echte codebase hebt geïntegreerd, bent u waarschijnlijk tegen de beperkingen van naïef zoeken naar vectoren aangelopen.
U vraagt een agent om een API-eindpunt te refactoren en deze haalt het functielichaam op via vectorzoekopdracht. Maar het mist het databaseschema, de authenticatie-middleware en het implementatiehandboek, omdat ze niet genoeg semantische overlap deelden.
De agent faalt omdat deze in een contextvacuüm werkt.
Om dit probleem van "contextassemblage" op te lossen, heeft Google Cloud de Open Knowledge Format (OKF) specificatie gepubliceerd. Het is een leveranciersneutrale standaard om een map met tekstbestanden om te zetten in een semantische kennisgraaf die AI-agenten recursief kunnen navigeren.
Hier is mijn praktische ervaring met de implementatie ervan.
Het concept: wat is OKF?
OKF formaliseert wat veel platformteams al deden: het structureren van interne documentatie als een schone directoryboom van pure Markdown-bestanden met YAML-frontmatter.
In plaats van het introduceren van complexe graafdatabases, vertrouwt OKF op twee webstandaarden:
- YAML Frontmatter voor metagegevens op bestandsniveau (declareren wat een bestand is).
- Standaard Markdown-links om relaties tussen bestanden te declareren.
Door bestanden direct in de tekst te koppelen, verandert u uw documentatie in een kennisgraaf. Elke agent die een bestand analyseert, kan deze links volgen als een webcrawler.
Het voorbeeld
In een repository voor een UI-componentenbibliotheek of een designsystem kunt u uw OKF-kennisdatabase als volgt structureren:
/knowledge-base
├── components/
│ └── interactive-modal.md
├── compliance/
│ └── wcag-checklist.md
└── tokens/
└── theme-palette.mdElk van deze bestanden begint met een minimaal frontmatter-blok. De specificatie is lichtgewicht; het enige vereiste veld is type.
Hier is de YAML-header voor 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"]
---En in de markdown-inhoud definiëren we relaties via relatieve 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).Hoe agenten de graaf navigeren
Traditionele RAG zoekt naar trefwoorden of vectoren, haalt de top 5 fragmenten op en dumpt ze in de prompt.
OKF maakt een navigatie-RAG-strategie mogelijk:
- Selectie van het toegangspunt: De agent vindt het eerste relevante document (bijv.
interactive-modal.md). - Recursief parsen: De agent analyseert het document en extraheert alle relatieve links.
- Contextassemblage: De agent laadt recursief de gekoppelde bestanden (WCAG-richtlijnen en ontwerptokens) om een volledige context op te bouwen voordat hij React-code schrijft.
Conclusie: is het de moeite waard?
De voordelen:
- Geen leveranciersvergrendeling: Het is gewoon Markdown.
- Git-compatibel versiebeheer: Documentatie-updates verlopen via standaard Pull Requests.
- Agentonafhankelijkheid: Agenten hebben alleen een standaard markdown-parser nodig.
De nadelen:
- Gebroken links: Relatieve links breken als bestanden worden verplaatst. Gebruik een linter in uw CI-pijplijn.
- Onderhoudskosten: Vereist de toezegming om headers en links bij te werken bij elke codewijziging.