La couche de connaissance IA : 127 pages, aucune base vectorielle, et ce que j'avais mal compris

Andrej Karpathy a publié un gist en avril 2026 décrivant un modèle de construction de bases de connaissances personnelles avec des LLM. Il a cumulé 99 000 favoris en une semaine. Plusieurs implémentations sont devenues open source en quelques jours. graphify a été livré en 48 heures et en a récolté 27 000 de plus. Ce modèle a trouvé un écho parce qu'il a nommé un problème familier : la plupart des agents manquent de mémoire persistante entre les sessions. Chaque conversation repart de zéro. Vous réexpliquez votre activité, vos objectifs, votre voix, votre contexte, et le résultat revient générique parce que le point de départ n'avait rien à quoi s'accrocher.

Une couche de connaissance est utilisée chez webvise pour la recherche et la documentation de projet. Voici ce qui en est ressorti.

Les agents oublient entre les sessions.

Le flux de travail IA standard est sans état. Vous ouvrez un chat, expliquez ce dont vous avez besoin, obtenez une réponse, fermez le chat. À la session suivante, même explication. Le contexte que vous aviez construit a disparu. La plupart des gens compensent en rédigeant des invites plus longues, en copiant-collant des documents de référence ou en téléchargeant des fichiers au début de chaque session. Cela fonctionne, mais ne passe pas à l'échelle. À un moment, la fenêtre de contexte se remplit, la qualité se dégrade, et vous passez plus de temps à préparer l'invite qu'à faire le travail.

La couche de connaissance résout cela au niveau de l'infrastructure. Plutôt que de bourrer de contexte chaque invite, vous donnez à l'agent accès à une base de connaissances persistante et structurée qu'il lit avant toute chose. L'agent connaît déjà votre activité, votre voix, vos projets, votre historique. Vous sautez la réexplication et passez directement au travail.

Trois couches, aucune base vectorielle

L'architecture se compose de trois parties :

• Sources brutes. Un dossier de documents immuables : articles, notes, transcriptions, PDF, enregistrements de réunions, recherches. L'agent les lit mais ne les modifie jamais. Ce sont votre source de vérité.
• Le wiki. Un répertoire de fichiers markdown générés par LLM avec des références croisées. Pages d'entités, pages de concepts, synthèses, comparaisons, playbooks. L'agent possède entièrement cette couche : il crée les pages, les met à jour à l'arrivée de nouvelles sources, entretient les références croisées et maintient la cohérence d'ensemble. Vous le lisez, l'agent l'écrit.
• Le schéma. Un document de configuration (CLAUDE.md, AGENTS.md ou équivalent) qui indique à l'agent comment le wiki est structuré, quelles conventions respecter et quels flux de travail exécuter. C'est ce qui transforme un LLM générique en mainteneur de wiki rigoureux.

Le wiki est un artefact compilé. L'agent ne redérive pas la connaissance à chaque requête : il compile une fois, crée les références croisées, et reste à jour. Lorsque vous ajoutez une nouvelle source, l'agent l'intègre dans le wiki existant en mettant à jour toutes les pages concernées. Lorsque vous posez une question, l'agent lit des pages pré-compilées plutôt que de fouiller dans les documents bruts.

Pourquoi cette approche surpasse RAG dans la plupart des cas

RAG redérive les réponses au moment de la requête en découpant les documents et en cherchant des fragments pertinents. L'approche par wiki compilé contourne entièrement cette étape. Le benchmark de graphify a mesuré 71,5 fois moins de tokens par requête dans leur comparaison publiée ; les résultats dépendent des caractéristiques du corpus et de la distribution des requêtes. Les mesures internes indiquent environ 1 000 tokens de contenu de coffre par requête, contre 3 000 tokens ou plus qu'un pipeline RAG typique injecte.

Une comparaison technique complète entre RAG et la récupération par index est disponible. En résumé : sur les charges de travail testées, l'approche par wiki compilé surpasse RAG en précision, en coût et en complexité opérationnelle. Aucune base vectorielle, aucun modèle d'embedding, aucune stratégie de découpage, aucun job de réindexation. Cinq commandes shell et un fichier d'index entretenu.

L'évolution s'est produite en trois phases : RAG one-shot de 2020 à 2023, RAG agentique avec récupération multi-hop de 2023 à 2024, puis ingénierie du contexte à partir de 2025, où l'agent construit lui-même son contexte à partir de plusieurs sources. La couche de connaissance est l'infrastructure de cette troisième phase. La plupart des équipes construisent encore pour la première.

Enseignements tirés de l'exploitation

Le wiki interne contient actuellement 127 pages structurées réparties en sept catégories : personnes, entreprises, concepts, playbooks, collections, synthèses et outils. Chaque page suit un modèle standard avec un frontmatter YAML, des références croisées via les wikilinks Obsidian et une attribution des sources. L'agent exécute six opérations définies : ingestion, mise à jour conversationnelle, requête, lint, enrichissement et réorganisation.

• Le fichier de schéma est tout le jeu. Tout le reste en découle. Un schéma bien rédigé produit un wiki rigoureux aux conventions cohérentes. Un schéma vague produit des hallucinations et de l'éparpillement. La version actuelle compte environ 200 lignes et couvre la structure des répertoires, le format des pages, les six opérations, les conventions de nommage et la gestion des contradictions. Plusieurs itérations ont été nécessaires pour l'affiner.
• La déduplication en premier prévient la prolifération de pages. La règle : avant de créer une nouvelle page, chercher dans le wiki existant les contenus qui se recoupent. Si une page existante couvre 60 % ou plus du même terrain, on enrichit cette page plutôt que d'en créer une nouvelle. Sans cette règle, le wiki se remplit de pages redondantes qui fragmentent la connaissance en morceaux inutilisables.
• Les requêtes s'accumulent dans la base de connaissances. Poser une bonne question et obtenir une réponse utile, puis archiver cette réponse comme nouvelle page wiki, permet à l'agent d'avoir une synthèse pré-compilée disponible la prochaine fois qu'une question connexe est posée. C'est l'effet cumulatif qui rend le système meilleur avec le temps, pas seulement plus grand.
• La qualité de l'ingestion dépend entièrement de la discipline. Déposer un article brut en disant « ingère ça » produit un résumé superficiel. Parcourir la source avec l'agent, discuter des points clés et indiquer ce qu'il faut souligner produit des pages qui restent utiles à mesure que le wiki grandit. Le flux de travail appliqué est strict : nettoyer le fichier brut, discuter des points essentiels, attendre la validation, puis extraire complètement.
• Le fichier d'index est le système de récupération. L'index racine de 22 lignes suffit. Chaque sous-répertoire possède son propre index listant chaque page avec une description en une ligne. L'agent lit l'index racine en environ 400 tokens, identifie le bon sous-répertoire, lit cet index, puis extrait les pages spécifiques dont il a besoin. La plupart des requêtes se terminent avec trois lectures et environ 1 000 tokens de contenu de coffre.

Le schéma est le fichier le plus important que vous écrirez

Karpathy l'appelle le schéma. Chez webvise, c'est CLAUDE.md. Certains frameworks le divisent en une couche de base de connaissances et une fondation de marque. Le nom est secondaire. Le fait opérationnel est que ce seul fichier contrôle le comportement de l'agent pour chaque session.

Un bon schéma définit :

• La structure des répertoires. Où vont les sources brutes, où vont les pages wiki, comment elles sont organisées en catégories.
• Le format des pages. Champs de frontmatter, structure des sections, règles d'attribution des sources, conventions de référencement croisé.
• Les opérations. Flux de travail pas à pas pour ingérer des sources, répondre à des requêtes, effectuer des contrôles de santé et entretenir le wiki dans la durée.
• Les portes qualité. Ce qui rend une page complète. Quand signaler une incertitude. Comment gérer des sources contradictoires. La règle que chaque affirmation doit être traçable jusqu'à une source.

Sans ces éléments, l'agent improvise : il crée des pages dans des emplacements aléatoires, utilise des formats incohérents, duplique du contenu entre les pages et dérive de vos conventions à chaque session. Le schéma prévient cette dérive. Il est traité comme du code de production : chaque modification est délibérée et testée contre une ingestion réelle.

Comment en construire une en 20 minutes

Pas besoin de 17 fichiers, d'un graphe de compétences de contenu ou d'un pipeline d'embedding personnalisé. Quatre éléments suffisent :

• Un coffre Obsidian avec deux dossiers. `raw/` pour les documents sources et `wiki/` pour les pages générées par l'agent. Ouvrez-le dans Obsidian pour la vue graphique et la navigation.
• Un fichier de schéma. Commencez par le gist de Karpathy. Adaptez la structure des répertoires et le format des pages à votre domaine. Restez sous 200 lignes pour commencer.
• Un agent LLM avec accès aux fichiers. Claude Code, OpenAI Codex ou tout agent capable de lire et d'écrire des fichiers markdown. Pointez-le vers le coffre. Il lit le schéma au démarrage.
• Votre première source. Déposez un article, un ensemble de notes ou un document dans `raw/`. Demandez à l'agent de l'ingérer. Observez-le créer des pages wiki, construire des références croisées et mettre à jour l'index.

C'est toute la boucle. Le système s'améliore chaque jour parce que chaque source ajoutée et chaque question posée enrichit le wiki. La première ingestion demande 10 minutes d'attention active. À la vingtième, l'agent connaît suffisamment votre domaine pour extraire et croiser les références avec un minimum de guidance.

Outillage optionnel à mesure que vous montez en charge : qmd de Tobi Lutke pour la recherche hybride locale avec BM25 et récupération vectorielle une fois que vous dépassez 300 pages. L'extension Obsidian Web Clipper pour ajouter rapidement des articles web dans votre dossier brut. Dataview pour exécuter des requêtes sur les frontmatters de pages. Git pour l'historique de version. Rien de tout cela n'est requis pour commencer.

Ce qui n'a pas d'importance

La majeure partie de la complexité que les gens associent aux systèmes de connaissance IA est de la surcharge pour des problèmes qu'ils n'ont pas encore. Une base vectorielle pour 200 documents, un modèle d'embedding personnalisé quand un index entretenu assure la récupération, un pipeline de réindexation quand ajouter un document revient à écrire un fichier, une stratégie de découpage quand la page est l'unité. Rien de tout cela n'est nécessaire à l'échelle à laquelle la plupart des entreprises opèrent.

Le modèle fonctionne parce que le markdown est simple et que les LLM excellent à le lire et à l'écrire. Le coût d'infrastructure est nul. Le coût de maintenance est faible parce que le LLM gère les mises à jour de l'index ; une revue humaine périodique reste recommandée pour la précision. Le seul vrai coût est la discipline nécessaire pour garder le schéma honnête et la qualité d'ingestion élevée. C'est un problème humain, pas un problème technologique.

Cas d'usage professionnels

La même architecture fonctionne à l'échelle d'une entreprise. Remplacez les notes personnelles par de la documentation client, des playbooks commerciaux, des guides d'onboarding et des SOP internes. Remplacez l'agent d'une seule personne par celui de chaque membre de l'équipe, tous connectés à une base de connaissances partagée.

Le modèle est identique : les sources brutes entrent, l'agent compile des pages structurées, les références croisées se construisent automatiquement, les humains valident. La différence est qu'une couche de connaissance partagée rend les nouveaux membres de l'équipe immédiatement productifs. Leur agent connaît déjà l'historique client, les conventions internes et le contexte du projet. Pas de rampe de six semaines, pas de connaissance tribale enfermée dans la tête de quelqu'un.

Karpathy l'appelle un LLM wiki. Eric Osiu l'appelle un cerveau partagé. Cody Schneider l'appelle un entrepôt de données. Le nom change, le modèle non : les agents ont besoin de connaissances compilées et structurées pour effectuer un travail utile. Sans contexte persistant, les invites fonctionnent sans la connaissance institutionnelle dont elles ont besoin.

webvise construit des couches de connaissance pour les entreprises qui souhaitent que leurs agents IA sachent réellement de quoi ils parlent. Si vous passez plus de temps à expliquer le contexte à vos outils qu'à en tirer de la valeur, c'est précisément le problème que cela résout. Prenez contact.