Google OKF, Hermes et Gbrain : les dossiers en tant que graphes de connaissances.

L’idée de « LLM-Wiki » d’Andrej Karpathy, un LLM capable de lire et d’écrire des wikis Markdown pour travailler de manière autonome, a suscité beaucoup de curiosité. Des individus et de petites équipes commencent à l’essayer. Lorsque l’on confie du travail à une IA, la partie difficile n’est souvent pas le modèle lui-même, mais plutôt la manière de lui fournir les informations de base nécessaires.

Si l’on lui demande de résumer les données des commandes du mois dernier, elle ne pourra pas y répondre correctement à moins de savoir quels tableaux contiennent ces données, ce que signifient les colonnes et comment les tableaux sont reliés entre eux. Le format Open Knowledge (OKF) vise à combler ce type de lacune. Son principal ennemi est le cloisonnement de l’information, et non l’échelle.

Les connaissances internes telles que les schémas de tables, les définitions de métriques, les guides d’intervention et les chemins de jonction des systèmes se trouvent dans des catalogues de métadonnées, des wikis, des commentaires de code ainsi que dans la mémoire des personnes expérimentées. Chaque nouveau projet d’agent commence par collecter et réapprendre ce contexte à partir de zéro. Google Cloud qualifie ce phénomène dans ses écrits sur OKF de « problème de compilation du contexte ».

Pour quoi OKF est utile

Beaucoup de ce dont a besoin un agent est spécifique à l’entreprise : les définitions de tables, la manière dont les métriques sont calculées, les procédures opérationnelles, les spécifications API. Ces éléments sont dispersés. OKF vise à les compiler en fichiers Markdown que Git peut gérer, afin que les agents et les collaborateurs puissent s’appuyer sur un ensemble cohérent plutôt que de devoir rechercher à nouveau à partir de zéro à chaque fois. Un index.md ainsi que des fichiers de concepts liés constituent alors la source navigable.

En notant le contexte tout en travaillant avec l’IA, vous accumulez des éléments que vous pouvez réutiliser. Cela diffère de l’habitude de remplir un prompt à chaque session.

Comment les agents l’utilisent

Appeler un modèle ne suffit que rarement pour obtenir une précision pratique. Les agents ont besoin du contexte métier, des définitions de données appropriées ainsi que des décisions antérieures. OKF leur offre un endroit bien organisé où chercher ces éléments avant qu’ils ne trouvent une réponse.

OKF, MCP et RAG

Plusieurs technologies liées aux agents sont confondues avec OKF. Leurs fonctions sont différentes.

• OKF contient des connaissances écrites à l’avance : définitions, contrats, guides d’opération.
• MCP relie les agents à des outils et systèmes en temps réel pendant l’exécution.
• RAG récupère des passages pertinents à partir de grandes bases de données non structurées au moment de la requête.

Ils ne sont pas des concurrents. La définition des utilisateurs actifs hebdomadaires peut être gérée par OKF, tandis que la requête réelle de BigQuery est exécutée via MCP. Les bundles OKF peuvent également faire l’objet de recherches au sein d’un index RAG. La question pratique est de déterminer quels domaines vous couvrez déjà et où se situent les lacunes.

Hermes, Wiki LLM et Gbrain

Une approche consiste à exécuter un environnement d’agent tel que Hermes avec Wiki LLM disponible par défaut, puis à ajouter Gbrain en tant que couche de mémoire. Gbrain, open source créé par Garry Tan, stocke des informations que les agents peuvent réutiliser ultérieurement. Il s’agit davantage d’une mémoire externe pour les LLM que d’un wiki destiné aux humains, dans l’esprit de l’idée LLM-Wiki de Karpathy. Les éléments enregistrés sont intégrés de manière à permettre, lors des recherches ultérieures, de trouver des contextes passés semantiquement liés : décisions similaires, contraintes commerciales connexes, etc., et non seulement des correspondances exactes par mots-clés.

Lorsque l’environnement est prêt, la configuration de Gbrain ainsi que les vérifications associées peuvent être automatisées au sein d’Hermes, y compris l’intégration des paramètres de configuration. Des packs de compétences optionnels permettent d’élargir les capacités de l’agent.

Une procédure de déploiement typique place l’agent sur un VPS derrière un proxy inversé afin qu’il soit accessible de n’importe où, puis confirme le premier lancement sur le tableau de bord. Par la suite, le travail consiste moins à installer des logiciels qu’à alimenter le wiki et la mémoire en contextes réels.

À quoi ressemble un bundle OKF en pratique

Un bundle est un répertoire contenant des fichiers Markdown avec du frontmatter YAML. Chaque fichier représente un concept : un tableau, une métrique, une API, un guide de procédures. Le frontmatter contient les champs qui doivent être consultables, tels que le type, le titre, la description, les étiquettes et les timestamps. Le corps du fichier contient le texte, les formules et les exemples que les utilisateurs et les modèles lisent réellement. Les liens entre fichiers transforment ce répertoire en un graphe, et non seulement en un arbre, permettant ainsi à un agent de passer d’une métrique à son tableau source, puis à un guide d’incidents.

Comme le format se compose de fichiers simples, le même bundle peut être stocké dans Git, envoyé sous forme de tarball ou hébergé sur un serveur statique. Les demandes de pull deviennent ainsi le processus d’évaluation des connaissances. Les historiques et les responsabilités indiquent qui a modifié la formule de churn et quand. Aucun SDK propriétaire ne se met entre l’ingénieur et le contenu ; cat suffit pour examiner un concept.

Cette simplicité est intentionnelle. Les notes de conception de Google insistent sur un contrat minimaliste : un champ de type est uniquement requis, et les producteurs décident du reste. Les humains peuvent créer des bundles manuellement. Les pipelines d’exportation peuvent les générer à partir de catalogues existants. Un agent peut écrire un concept que un autre agent consommera par la suite. Le format constitue le contrat ; les outils de chaque côté restent interchangeables.

Mettre Hermes et Gbrain au travail

Lorsque Hermes est en fonctionnement, le cycle quotidien ressemble davantage au travail de connaissance qu’à celui lié à l’infrastructure. On y ajoute des notes, des décisions et des définitions dans la couche wiki. Gbrain les intégre et les rend recherchables selon leur sens. Lorsque l’agent se retrouve confronté à une question similaire, il peut consulter ces contextes antérieurs plutôt que de partir d’une demande vierge.

Quelques habitudes rendent ce cycle utile. Écrivez les définitions comme si un inconnu allait les lire dans six mois. Préférez un concept par fichier afin que la récupération des informations reste efficace. Créez des liens entre les concepts apparentés plutôt que de dupliquer du texte. Lorsqu’une décision change, mettez à jour le concept plutôt que de laisser une note contradictoire ailleurs. Traitez le wiki comme un produit, et non comme un dépôt aléatoire.

Des packs de compétences optionnels autour de Gbrain élargissent les capacités de l’agent sans modifier le modèle de mémoire de base. La propriété importante est que la mémoire et les outils restent séparés : la mémoire contient ce qui est connu ; les outils se connectent aux systèmes en temps réel lorsque des actions sont nécessaires. Cette séparation reflète la distinction entre OKF et MCP décrite précédemment.

Choisir un point de départ

Si votre équipe dispose déjà d’une wiki bien tenue contenant des métriques et des schémas, la convertir en un ensemble de type OKF constitue une première étape naturelle. Si le problème principal est que « les agents ne peuvent pas accéder à nos bases de données », un serveur MCP placé en amont de ces systèmes pourrait être la solution prioritaire. Si le problème réside dans le fait que « les réponses se trouvent noyées dans les archives de Slack », un index RAG basé sur les conversations et les tickets pourrait être la solution adaptée. De nombreuses équipes souhaitent finalement disposer des trois solutions, mais commencer par résoudre le problème le plus criant permet de garder le projet réaliste.

Quelle que soit votre choix, mesurez si les agents cessent de poser les mêmes questions de clarification. C’est un meilleur indicateur de succès que le nombre de fichiers dans l’ensemble.

Avant que les connaissances ne soient organisées

En examinant OKF, une limite devient évidente : OKF et RAG sont utiles une fois que les connaissances sont organisées. Avant cela, le contexte pertinent reste caché dans les notes de réunion, les journaux de chat, les doutes et les discussions inachevées. Des formats comme OKF interviennent après que les connaissances ont été sélectionnées avec soin. Les éléments qui renvoient à la source originale apparaissent plutôt avant cela. Plutôt que de fournir au modèle une réponse prête, on lui donne un chemin pour retourner au contexte initial.

À long terme, ce ne seront pas seulement les modèles et les prompts qui compteront ; la manière dont les informations sont stockées et présentées à l’IA sera tout aussi importante.