Google publie Open Knowledge Format, un standard de partage des connaissances pour les agents IA

 (cloud.google.com)
5 points par GN⁺ 4 시간 전 | 2 commentaires | Partager sur WhatsApp
  • Spécification ouverte et neutre vis-à-vis des fournisseurs, permettant à plusieurs agents de consommer sans traduction des wikis rédigés par différents producteurs, et formalisant le pattern LLM-wiki dans un format portable et interopérable
  • OKF v0.1 représente les connaissances sous la forme d’un répertoire de fichiers Markdown avec front matter YAML, et fonctionne sans mécanismes de compression complexes, nouveau runtime ou SDK obligatoire
  • Les connaissances internes des organisations sont dispersées dans des systèmes fragmentés — catalogues de métadonnées, wikis, commentaires de code, ou même dans la tête de quelques ingénieurs seniors — si bien que les agents doivent à chaque fois reconstituer le même contexte depuis zéro
  • La réponse n’est pas un nouveau service de connaissance mais le format lui-même : n’importe qui peut produire sans SDK, consommer sans intégration, et gérer le tout avec le code dans le contrôle de version
  • Publié comme standard ouvert, sa valeur dépend de l’extension de l’écosystème de producteurs et de consommateurs

Contexte : un environnement de contexte fragmenté

  • Même si les foundation models progressent, leurs performances restent limitées, en particulier pour construire des systèmes d’agents, à cause du manque de contexte pertinent
    • Ils peuvent écrire du code, résumer des documents ou analyser des jeux de données, mais pour produire des résultats exacts et exploitables, ils ont besoin des bonnes informations
  • Les informations utilisées par les modèles dans une organisation sont pour l’essentiel des connaissances internes : schémas de tables, signification des métriques métier, runbooks d’incident, chemins de jointure entre deux systèmes, avis de dépréciation d’anciennes API, etc.
  • Exemples de systèmes où ces unités de connaissance sont dispersées
    • catalogues de métadonnées avec leur propre API
    • wikis, systèmes tiers, lecteurs partagés
    • commentaires de code, docstrings, cellules de notebook
    • la tête de quelques ingénieurs seniors
  • Pour répondre à une question comme « comment calcule-t-on les utilisateurs actifs hebdomadaires (WAU) à partir du flux d’événements ? », un agent doit assembler la réponse à partir de surfaces incompatibles entre elles
    • Chaque fournisseur propose son propre catalogue, son propre SDK, son propre schéma de graphe de connaissances, et les connaissances ne sont pas portables entre produits ni entre organisations
  • Résultat : chaque concepteur d’agent répète le même problème d’assemblage du contexte, les fournisseurs de catalogues réinventent le même modèle de données, et les connaissances restent enfermées dans la surface qui les a produites

La connaissance comme wiki vivant

  • Les équipes de développement passent d’une recherche répétée des mêmes faits dans les mêmes documents à un modèle où elles fournissent aux agents une bibliothèque Markdown partagée qui devient plus utile avec le temps
    • Les agents prennent en charge les tâches fastidieuses de lecture et de mise à jour de leurs propres fichiers, tandis que les équipes curatorialisent le contenu et le gèrent comme du code
  • Andrej Karpathy a proposé cette idée dans le gist LLM Wiki
    • Il explique que « les LLM ne s’ennuient pas, n’oublient pas de mettre à jour les références croisées et peuvent traiter 15 fichiers d’un coup »
    • Les tâches de bookkeeping qui poussent les humains à abandonner leur wiki personnel sont précisément le genre de travail dans lequel les LLM excellent
  • Le même pattern de wiki de connaissances réapparaît sous plusieurs noms
    • des vaults Obsidian connectés à des agents de code
    • des fichiers de convention de type AGENTS.md / CLAUDE.md
    • des dépôts d’artefacts index.md, log.md consultés par les agents avant de travailler
    • des dépôts internes d’équipes data de type « metadata as code »
  • Le pattern est puissant, mais chaque cas reste sur mesure
    • On retrouve des formes semblables — Markdown, front matter, liens croisés — sans qu’elles aient été conçues pour collaborer entre elles
    • Faute d’accord sur les champs que chaque document doit contenir ou sur la signification des noms de fichiers, les connaissances restent cloisonnées dans l’équipe d’origine et le travail est dupliqué à chaque nouvel agent

Ce qu’il faut, ce n’est pas un service mais un format

  • La réponse n’est pas un service de connaissance supplémentaire, mais un format pour représenter la connaissance, avec les exigences suivantes
    • que tout le monde puisse produire sans SDK
    • que tout le monde puisse consommer sans intégration
    • qu’elle reste intacte lors des déplacements entre systèmes, organisations et outils
    • qu’elle vive dans le contrôle de version aux côtés du code qu’elle décrit
    • qu’elle soit lisible par les humains et analysable par les agents, en utilisant les mêmes fichiers sans couche de traduction
  • OKF est conçu pour répondre à ces exigences

Fonctionnement d’OKF : un design qui tient sur un écran

  • Un bundle OKF est un répertoire de fichiers Markdown représentant des concepts, incluant tout ce qu’on veut décrire : tables, jeux de données, métriques, playbooks, runbooks, API, etc.
    • Chaque concept correspond à un fichier, et le chemin du fichier constitue l’identité du concept
    • Exemple de structure de répertoire : sous sales, des dossiers datasets, tables, metrics, ainsi que orders.md, customers.md, weekly_active_users.md, etc.
  • Chaque document de concept se compose d’un bloc YAML front matter pour les champs structurés et d’un corps Markdown pour le reste
    • Exemples de champs du front matter : type (BigQuery Table), title (Orders), description, resource (URL de console), tags ([sales, revenue]), timestamp (2026-05-28T14:30:00Z)
    • Le corps peut inclure un schéma (order_id, customer_id, leurs types et descriptions), des jointures (jointure avec customers via customer_id), etc.
  • Les concepts sont reliés entre eux par des liens Markdown ordinaires, transformant le répertoire en un graphe plus riche qu’une simple relation parent/enfant du système de fichiers
    • Le bundle peut inclure en option des fichiers index.md (divulgation progressive lors de l’exploration par les agents) et log.md (historique des changements)
  • L’intégralité de la spécification v0.1 tient sur une page, y compris les critères de conformité, les règles de liens croisés et quelques noms de fichiers réservés

Les trois principes de conception

  • Prescriptif au minimum

    • OKF n’impose qu’une seule chose à tous les concepts : le champ type
    • Le choix des types existants, des champs supplémentaires et des sections du corps est laissé au producteur
    • La spécification définit la surface d’interopérabilité, pas le modèle de contenu

  • Indépendance producteur/consommateur

    • L’entité qui écrit la connaissance et celle qui la consomme sont proprement séparées
    • Un agent IA peut consommer un bundle rédigé à la main par des humains ; un visualiseur peut explorer un bundle généré par un pipeline d’export de métadonnées ; un bundle synthétisé par un LLM peut être interrogé par un autre LLM
    • Le format fait office de contrat, et les outils à chaque extrémité peuvent être remplacés indépendamment

  • Un format, pas une plateforme

    • Aucune dépendance à un cloud, une base de données, un fournisseur de modèles ou un framework d’agents en particulier
    • Aucun compte propriétaire ni SDK n’est requis pour lire, écrire ou servir les données
    • La valeur d’un format de connaissance ne vient pas de son propriétaire, mais de combien d’acteurs l’utilisent ; c’est pourquoi il est publié comme standard ouvert

Ce qui est fourni avec la spécification

  • Pour concrétiser le format, des implémentations de référence sont publiées côté producteurs comme côté consommateurs
  • Enrichment agent : parcourt des jeux de données BigQuery, rédige un premier brouillon des documents de concepts OKF pour toutes les tables et vues, puis utilise un second passage LLM pour crawler la documentation officielle et enrichir chaque concept avec des citations, des schémas et des chemins de jointure
  • Visualiseur HTML statique : transforme n’importe quel bundle OKF en une vue graphe interactive autonome dans un seul fichier, sans backend, sans installation côté lecteur, et sans que les données quittent la page
  • Trois bundles d’exemple immédiatement explorables : les jeux de données publics GA4 e-commerce, Stack Overflow et Bitcoin, générés par l’agent de référence et commités dans le dépôt comme exemples vivants d’OKF conforme
  • Ces éléments sont volontairement des proofs of concept
    • L’agent montre une manière de produire de l’OKF, sans exiger un framework ou un LLM particulier
    • Le visualiseur montre une manière de consommer, sans imposer HTML ni vue en graphe
    • L’objectif est que l’écosystème de producteurs et de consommateurs croisse bien au-delà de ce qui est fourni

Perspectives

  • OKF v0.1 n’est pas un standard achevé mais un point de départ ; il évoluera à mesure que davantage de producteurs et de consommateurs apparaîtront et que l’on comprendra mieux comment représenter les connaissances réellement nécessaires aux agents
  • Qu’il s’agisse de construire un catalogue de connaissances, un pipeline d’enrichissement ou un wiki pour agents IA, il faut le publier en ouvert dès le premier jour pour que le format porte vraiment son nom
  • Actions recommandées
    • lire la spécification (elle est courte)
    • écrire des producteurs pour des systèmes sources, bases de données ou sites de documentation
    • écrire des consommateurs comme des visualiseurs, des index de recherche ou des agents capables de raisonner sur les bundles
    • appliquer l’implémentation de référence à ses propres données
    • ouvrir des issues, envoyer des PR, proposer des extensions (la spécification est versionnée et conçue pour évoluer de manière rétrocompatible)
  • Le dépôt, la spécification et les bundles d’exemple sont publiés sur GitHub, et Knowledge Catalog de Google Cloud a été mis à jour pour ingérer OKF et le servir aux agents
  • L’apport principal est le format lui-même ; les outils fournis servent à rendre ce format concret et à réduire le coût d’expérimentation, OKF étant conçu comme une lingua franca pour les futurs échanges de connaissances

À lire aussi

2 commentaires

 
leothelion 1 시간 전

On va dire que c’est le mieux qu’on puisse faire quand on n’a pas réussi à faire adopter .claude et .agent.
 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • J’aime la simplicité de cette spécification OKF, mais je ne suis pas convaincu qu’on puisse bien tout exprimer en « simple Markdown »
    Récemment, je me suis intéressé à la manière d’exprimer des concepts pour que l’IA puisse y contribuer efficacement et avec un bon rendement en tokens, et en général cela revient à chercher comment bien représenter quelque chose sous forme de texte séquentiel semi-structuré. Mais il ne faut pas sacrifier au passage l’expérience de représentation des connaissances côté humain
    Surtout si des rôles qui ne sont pas traditionnellement des développeurs doivent aussi contribuer, un « format de texte bizarre + git » risque de sembler bien pire que les outils actuels de rédaction et de visualisation
    J’ai hâte de voir comment vont émerger, dans les prochaines années, des standards pour représenter sémantiquement différents types de connaissances
    Parmi les exemples de réussite à prendre en compte, il y a DBML pour les schémas/E-R, LikeC4 pour l’architecture, ou encore des approches diagram-as-code comme Mermaid. Les LLM comprennent aussi plutôt bien ces formats, et on peut même les leur expliquer avec un court prompt EBNF. L’important, c’est qu’eux aussi ont une forme de visualisation agréable pour les humains, qu’on peut les insérer naturellement dans du Markdown via un code block juste à côté du langage naturel, et que les LLM peuvent aussi aider à écrire la grammaire
    Le plus difficile, ce sont des choses comme des feuilles de calcul complexes ou Miro, où la disposition spatiale et les couleurs portent un sens implicite. Je n’ai pas encore trouvé de bonne alternative
    Une tentative concrète dans le domaine du data engineering est https://equalexperts.github.io/satsuma-lang/ pour permettre à l’IA et aux humains de traiter ensemble les mappings source-cible et les transformations. C’est une représentation textuelle structurée et concise qui autorise le langage naturel, tout en fournissant une bonne visualisation ainsi que des outils LSP/grammaire, afin que les agents n’aient pas à découper de gros documents de manière inefficace en tokens pour raisonner sur la lignée, l’exhaustivité ou des sources non définies

    • OKF a l’air correct, mais reste lié à Markdown
      Un document Markdown peut devenir un document OKF en ajoutant type dans le YAML d’en-tête
      Je me demande à quoi ressemblerait un langage de graphe de connaissances qu’on pourrait utiliser dans la prose Markdown, dans des blocs de code Markdown, et partout où il y a des champs texte
      Dans le langage minimaliste https://ddot.it, on peut relier des fichiers hors de l’univers Markdown, des URL et même de simples labels. Comme OKF, ce n’est qu’un format
      Pour être transparent, c’est moi qui ai rédigé cette courte spécification
    • On ne peut pas bien représenter la connaissance sans un format de graphe montrant des relations étiquetées entre les entités
    • Markdown est le format de facto de l’interopérabilité entre LLM et humains
      Je suis d’accord sur le fait qu’on ne peut pas tout bien exprimer, mais ce n’est pas vraiment le sujet. Markdown semble gagner parce que c’est le plus petit dénominateur commun entre les humains et les modèles d’IA

  • Tous les dix ans, c’est amusant de revisiter les formats du Web sémantique RDF/OWL
    Un jour, l’une de ces années sera vraiment la bonne
    https://en.wikipedia.org/wiki/Semantic_Web

  • Il y avait plusieurs liens cassés dans l’article d’origine, donc je laisse le dépôt ici
    https://github.com/GoogleCloudPlatform/knowledge-catalog
    Spécification : https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

  • Si j’ai bien compris, comme nous ne pouvons pas voir au-delà de trois dimensions, cela ressemble fondamentalement davantage à un échafaudage pour les humains
    Si nous organisons les choses à peu près correctement, on peut espérer que les agents prendront le Markdown pour construire une infrastructure de graphe en mémoire ou le stocker dans Neo4j

  • Est-ce qu’une variante précise de Markdown, par exemple CommonMark, est spécifiée ?
    En parcourant juste les premières pages, je n’ai rien vu à ce sujet, alors que cela me semble assez important pour une spécification

  • Ce que Google a annoncé, au final, c’est du Markdown avec du YAML frontmatter. Merci de vos applaudissements. Et ils ont pondu une spécification de 15 KB pour ça
    Je serais moins sarcastique si tout le monde pouvait arrêter d’utiliser YAML à la mode « ah mince, j’ai raté une indentation »

  • Ayant vu beaucoup de PDF qu’il fallait « traduire » en Markdown, ça me semble être un choix étrange
    Je comprends que l’objectif principal soit de rendre cela facilement accessible à l’IA, mais si de toute façon on va entraîner des modèles dessus, pourquoi ne pas les entraîner sur un meilleur format ?
    Markdown est assez limité et, par exemple, ne peut même pas rendre des tableaux imbriqués. Si l’objectif de cet « open knowledge » est l’IA, je ne sais même pas s’il faut absolument utiliser un format que les humains ne liront pas réellement

  • J’aime bien l’approche. J’adore la structuration hiérarchique des connaissances
    À l’heure actuelle, je considère que les abstractions de gestion des connaissances de Claude sont presque toutes défaillantes. Cela devient évident quand on fait tourner plusieurs codeurs en parallèle ou qu’on doit créer plus de 1 000 skills. Exemple : https://news.ycombinator.com/item?id=48407998

  • Ça vaut le coup de jeter un œil à barrasindustries.com/okfind/
    C’est une idée de registre de bundles OKF