RAG pragmatique : Test du format de connaissances ouvertes (OKF) de Google

Si vous avez intégré des agents IA dans une base de code réelle, vous avez probablement atteint les limites de la recherche vectorielle naïve.

Vous demandez à un agent de refactoriser un point de terminaison d'API, et il récupère le corps de la fonction via une recherche vectorielle. Mais il lui manque le schéma de la base de données, le middleware d'authentification et le manuel de déploiement, car ils ne partageaient pas assez de similitudes sémantiques.

L'agent échoue car il fonctionne dans un vide contextuel.

Pour résoudre ce problème "d'assemblage de contexte", Google Cloud a publié la spécification Open Knowledge Format (OKF). Il s'agit d'un standard neutre pour convertir un répertoire de fichiers texte en un graphe de connaissances sémantiques navigable par les agents de manière récursive.

Voici mon retour d'expérience sur sa mise en œuvre.

Le concept : Qu'est-ce que l'OKF ?

L'OKF formalise ce que de nombreuses équipes de plateforme faisaient déjà : structurer la documentation interne sous forme d'arborescence de fichiers Markdown avec des en-têtes YAML.

Plutôt que d'introduire des bases de données de graphes complexes, l'OKF s'appuie sur deux standards du web :

YAML Frontmatter pour les métadonnées de fichier (déclarer ce qu'est le fichier).
Liens Markdown standard pour déclarer les relations entre les fichiers.

En liant les fichiers directement dans le texte, vous transformez votre documentation en un graphe de connaissances. Tout agent analysant un fichier peut suivre ces liens comme un robot d'indexation.

Un exemple concret

Dans un dépôt de bibliothèque de composants d'interface utilisateur, vous pourriez structurer votre base de connaissances OKF ainsi :

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

Chacun de ces fichiers commence par un en-tête minimal. La spécification est légère, le seul champ requis est type.

Voici l'en-tête YAML pour 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"]
---

Et dans le contenu markdown, nous définissons des relations via des liens relatifs :

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

Comment les agents parcourent le graphe

Le RAG traditionnel recherche des mots-clés ou des vecteurs, récupère les 5 meilleurs extraits et les intègre au prompt.

L'OKF permet une stratégie de RAG par parcours :

Sélection du point d'entrée : L'agent trouve le premier document pertinent (par exemple, interactive-modal.md).
Analyse récursive : L'agent analyse le document et extrait tous les liens relatifs.
Assemblage du contexte : L'agent charge récursivement les fichiers liés (les directives WCAG et les jetons de conception) pour créer un contexte complet avant d'écrire le code React.

Conclusion : Est-ce que cela en vaut la peine ?

Les avantages :

Pas de dépendance fournisseur : C'est simplement du Markdown.
Gestion des versions avec Git : Les mises à jour de la documentation passent par des Pull Requests standard.
Indépendance de l'agent : Les agents ont uniquement besoin d'un analyseur markdown standard.

Les inconvénients :

Liens brisés : Les liens se brisent si les fichiers sont déplacés. Utilisez un linter dans vos pipelines de CI.
Coût de maintenance : Nécessite l'engagement de mettre à jour les en-têtes et les liens à chaque modification du code.