Google révolutionne l'IA avec le Format de Connaissance Ouvert

Pourquoi les RAG traditionnels ont des limites

Au cours des dernières années, la Génération Augmentée par Récupération (RAG) est devenue l'approche standard pour fournir des connaissances externes aux Modèles de Langage de Grande Taille (LLM). Plutôt que de s'appuyer uniquement sur les données d'entraînement du modèle, le RAG récupère des informations pertinentes à partir de documents externes pendant l'inférence. Un pipeline typique ressemble à ceci :

Cette approche fonctionne remarquablement bien pour rechercher des millions de documents. En comparant la signification sémantique des embeddings plutôt que des mots-clés exacts, le RAG permet à un système d'IA de répondre à des questions en utilisant des informations qui n'ont jamais fait partie des données d'entraînement originales du modèle.

Cependant, il existe un compromis important. Avant qu'un document puisse être indexé, il doit d'abord être divisé en morceaux plus petits. Bien que cette fragmentation améliore l'efficacité de la récupération, elle brise également la structure originale du document. Les relations qui étaient naturellement connectées à l'intérieur d'un seul document deviennent distribuées sur plusieurs morceaux indépendants.

Considérons le protocole d'admission d'un hôpital :

Politique d'Admission des Patients

Les patients arrivant par le Service des Urgences doivent compléter un triage initial avant l'admission.

Exigences d'Admission

• Identification valide du patient
• Évaluation clinique initiale complétée
• Les cas d'urgence reçoivent une priorité immédiate

Enregistrement et Allocation de Lit

Les informations sur le patient sont enregistrées dans le système de Dossier de Santé Électronique (DSE) avant qu'un lit ne soit attribué. L'allocation des lits suit les directives d'Occupation des Lits maintenues par l'équipe des Opérations.

Un pipeline RAG typique peut diviser ce document en plusieurs morceaux plus petits avant l'indexation :

• Les patients arrivant par le Service des Urgences doivent compléter un triage initial.
• Exigences d'Admission :
  • Identification valide du patient
  • Évaluation clinique initiale
  • Les cas d'urgence reçoivent une priorité immédiate
• Les informations sur le patient sont enregistrées dans le DSE.
• L'allocation des lits suit les directives d'Occupation des Lits.

Visuellement, le processus ressemble à ceci :

Lorsque qu'un clinicien demande, "Quel est le processus d'admission des patients ?", la base de données vectorielle récupère les morceaux qui semblent les plus pertinents, mais les relations logiques entre la politique d'admission, le triage d'urgence, le système DSE et l'allocation des lits sont perdues. Le modèle doit les reconstruire à chaque requête. Ce n'est pas un défaut du RAG. Il reste l'une des meilleures techniques pour rechercher de grandes collections non structurées comme des PDF, des articles de recherche, des tickets de support et des archives historiques.

La connaissance organisationnelle organisée est différente. Les politiques, procédures, API et manuels ne sont pas seulement du texte, ce sont des concepts interconnectés. Reconstruire ces liens à partir de morceaux fragmentés à chaque requête ajoute une complexité inutile, et c'est exactement le problème que le Format de Connaissance Ouvert (OKF) a été conçu pour résoudre.

Qu'est-ce que le Format de Connaissance Ouvert (OKF) ?

Les idées derrière l'OKF n'ont pas été initiées par Google. Plus tôt en 2026, Andrej Karpathy a introduit le concept d'un Wiki LLM : au lieu de récupérer sans cesse des documents bruts, un agent IA maintient une base de connaissances organisée qu'il peut lire, mettre à jour et améliorer en continu. Son analogie a rapidement trouvé un écho dans la communauté IA :

• Obsidian est l'IDE.
• Le LLM est le programmeur.
• Le wiki est la base de code.

L'idée est simple. Les humains fournissent du matériel source comme de la documentation, des politiques, des schémas et des manuels, et l'agent les organise en un wiki structuré en écrivant des résumés, en connectant des concepts liés et en maintenant des liens. Ces relations deviennent partie intégrante de la base de connaissances au lieu d'être redécouvertes à chaque requête.

Google a transformé cette idée communautaire en une spécification ouverte. Plutôt que de proposer un autre cadre ou SDK, il a mis l'accent sur la normalisation de la connaissance elle-même. Le résultat est l'OKF, un format léger qui stocke la connaissance sous forme de fichiers Markdown ordinaires avec un minimum de métadonnées et des liens explicites entre les concepts.

Un ensemble OKF est simplement un répertoire de documents Markdown, chacun représentant un concept tel qu'une politique, une API, un département, un manuel, une table de base de données ou une métrique, connectés par des liens Markdown standard. Contrairement à une base de données vectorielle qui infère des relations par similitude d'embeddings, l'OKF les préserve explicitement, permettant à un agent de suivre des liens plutôt que de deviner.

Puisque tout est en texte brut, cela s'intègre dans les flux de travail des développeurs existants : versionné dans Git, examiné via des pull requests, et consultable avec des outils standards. Passons maintenant à la construction d'un ensemble à partir de zéro pour voir comment il est organisé.

Structure d'un Ensemble OKF

Maintenant que nous avons compris la motivation derrière l'OKF, examinons comment un ensemble OKF est réellement organisé. Au cœur, un ensemble OKF est simplement un répertoire de fichiers Markdown. Chaque fichier Markdown représente un concept, tel qu'une politique hospitalière, un département, une procédure, un système ou une métrique opérationnelle. Chaque concept contient des métadonnées légères suivies d'un contenu Markdown structuré. Les concepts connexes sont connectés à l'aide de liens Markdown standard, permettant à la fois aux humains et aux agents IA de naviguer naturellement dans la base de connaissances.

La spécification elle-même est intentionnellement minimale. Elle définit seulement quelques conventions et évite d'imposer une structure de répertoire rigide. Cela donne aux organisations la flexibilité d'organiser la connaissance de manière à mieux convenir à leur domaine tout en produisant des ensembles pouvant être compris par tout agent compatible avec l'OKF.

Un ensemble OKF typique contient les composants suivants :

• index.md : Sert de point d'entrée principal dans la base de connaissances. Il fournit un aperçu des concepts disponibles et aide les agents à naviguer dans l'ensemble.

• CHANGELOG.md (Optionnel) : Enregistre les modifications apportées à la base de connaissances au fil du temps, rendant les mises à jour transparentes et traçables.

• Fichiers de Concept (.md) : Chaque fichier Markdown représente un concept unique tel qu'une politique, une procédure, une API, un département, une métrique ou un système.

• YAML Front Matter : Stocke des métadonnées incluant le type de concept, le titre, la description, les tags, la propriété et l'horodatage de la dernière mise à jour.

• Liens explicites : Connectent des concepts liés, transformant la base de connaissances en un graphique navigable plutôt qu'en documents isolés.

Une Structure de Dossier OKF Typique

Bien que la spécification OKF ne mandate pas une mise en page de répertoire particulière, suivre une hiérarchie de dossiers cohérente rend la base de connaissances beaucoup plus facile à maintenir et à naviguer. Les mêmes principes organisationnels s'appliquent quel que soit le domaine.

Les exemples suivants montrent comment différentes organisations peuvent structurer leur connaissance tout en suivant les mêmes conventions OKF :

1. Base de Connaissances Hospitalière
2. Base de Connaissances en Ingénierie Logicielle
3. Base de Connaissances en Fabrication

Bien que ces exemples appartiennent à des industries complètement différentes, l'organisation sous-jacente reste remarquablement similaire. Chaque ensemble commence par un fichier index.md qui sert de point d'entrée, un CHANGELOG.md optionnel pour le suivi des révisions, et un ensemble de répertoires qui regroupent des concepts connexes.

Cette cohérence est l'une des plus grandes forces de l'OKF. Une fois qu'un agent IA comprend comment un ensemble OKF est organisé, il peut naviguer dans un autre ensemble construit en utilisant les mêmes conventions avec peu ou pas d'adaptation supplémentaire.

Construction d'un Ensemble OKF

Maintenant que nous avons exploré la structure globale d'un ensemble OKF, construisons-en un à partir de zéro.

Pour le reste de cet article, nous utiliserons un hôpital fictif appelé CityCare Hospital. Imaginons que nous construisons un assistant IA qui aide les médecins, les infirmières et les administrateurs hospitaliers à répondre à des questions opérationnelles. L'assistant doit comprendre les politiques d'admission, les procédures d'urgence, les départements hospitaliers, les systèmes internes et les métriques opérationnelles. Au lieu de stocker ces informations dans une base de données vectorielle, nous allons les organiser sous forme d'un ensemble OKF.

Nous commencerons par créer le répertoire racine.

Le fichier index.md agit comme point d'entrée pour les humains et les agents IA.

Connaissance de l'Hôpital CityCare