LLM Wiki de Karpathy : une base de connaissances locale

#LLM Wiki : le principe en deux minutes

Le 2 avril 2026, Andrej Karpathy décrit sur X la façon dont il se sert de modèles de langage pour constituer des bases de connaissances personnelles. Deux jours plus tard, il publie un gist intitulé « LLM Wiki », qu'il présente comme un patron pour construire ce type de base avec un LLM. Les deux textes sont courts et se lisent en dix minutes ; les liens figurent en fin de page.

Le gist part d'un constat : la plupart des usages qui mêlent LLM et documents ressemblent à du RAG. On dépose des fichiers, le système retrouve des extraits au moment de la question, le modèle rédige une réponse. Karpathy reconnaît que cela fonctionne, mais relève que le modèle redécouvre la connaissance à chaque question et que rien ne s'accumule. Une question qui oblige à croiser cinq documents demande de retrouver et de recoller les mêmes morceaux à chaque fois.

Le LLM Wiki déplace le travail en amont. Quand une nouvelle source arrive, le modèle ne se contente pas de l'indexer : il la lit, en extrait l'essentiel et l'intègre à un ensemble de pages Markdown reliées entre elles. Il met à jour les pages existantes, révise les synthèses et note les endroits où la nouvelle source contredit ce qui était écrit. Le gist parle d'un artefact persistant qui se bonifie avec le temps : les recoupements sont déjà faits quand la question arrive.

La répartition des rôles est nette dans le texte. L'humain choisit les sources, explore et pose les questions. Le modèle fait tout le reste : résumer, relier, classer, tenir les registres. Karpathy dit travailler avec l'agent ouvert d'un côté de l'écran et Obsidian de l'autre, et résume l'installation par une image : Obsidian est l'IDE, le LLM est le programmeur, le wiki est la base de code.

#Trois couches : sources, wiki, conventions

Le gist décrit une architecture en trois couches. Aucune ne demande d'outil particulier : ce sont des dossiers et des fichiers texte.

Les sources brutes

Votre collection de documents : articles, papiers de recherche, images, fichiers de données. Elles sont immuables : le modèle les lit et ne les modifie jamais. Ce sont elles, et non le wiki, qui font foi.

Le wiki

Un dossier de fichiers Markdown rédigés par le modèle : résumés de sources, pages d'entités, pages de concepts, comparaisons, synthèse d'ensemble. Cette couche appartient au modèle, qui crée les pages, les met à jour et entretient les liens. Vous lisez, il écrit.

Le fichier de conventions

Un document qui indique au modèle comment le wiki est structuré, quelles règles suivre et comment procéder pour ingérer une source, répondre à une question ou faire le ménage. Le gist cite CLAUDE.md pour Claude Code et AGENTS.md pour Codex. C'est ce fichier qui fait d'un agent généraliste un mainteneur de wiki discipliné.

Deux fichiers particuliers aident le modèle, et vous, à s'y retrouver. Le premier, index.md, est un catalogue : chaque page y figure avec un lien et un résumé d'une ligne, rangée par catégorie. Pour répondre à une question, le modèle lit d'abord l'index, puis ouvre les pages utiles. Le second, log.md, est un journal chronologique auquel on ne fait qu'ajouter : ingestions, questions, passes de vérification.

Le gist suggère de commencer chaque entrée du journal par un préfixe régulier, ce qui permet de le filtrer avec de simples outils Unix. L'exemple donné a cette forme :

## [2026-04-02] ingest | Article Title

#Trois opérations : ingérer, interroger, vérifier

Ingérer (ingest)

Vous déposez une source dans le dossier des sources brutes et demandez au modèle de la traiter. D'après le gist, il lit la source, discute des points clés avec vous, écrit une page de résumé, met à jour l'index ainsi que les pages d'entités et de concepts concernées, puis ajoute une entrée au journal. Karpathy indique qu'une seule source peut toucher 10 à 15 pages du wiki.

Interroger (query)

Vous posez une question. Le modèle cherche les pages pertinentes, les lit et rédige une réponse qui cite ses références. Le gist insiste sur un point : une bonne réponse peut être rangée dans le wiki comme nouvelle page, pour que vos explorations s'accumulent au lieu de disparaître dans l'historique d'une discussion.

Vérifier (lint)

De temps en temps, vous demandez au modèle un contrôle de santé du wiki : contradictions entre pages, affirmations dépassées par des sources plus récentes, pages orphelines sans lien entrant, concepts cités sans page dédiée, renvois manquants.

Pourquoi confier ce travail à un modèle ? L'argument du gist est simple : ce qui tue les wikis personnels n'est ni la lecture ni la réflexion, c'est la tenue des registres. Mettre à jour les renvois, garder les résumés à jour, relever les contradictions : la charge d'entretien grandit plus vite que la valeur du wiki, et on abandonne. Un modèle ne se lasse pas et peut modifier quinze fichiers en une passe. Karpathy rattache l'idée au Memex imaginé par Vannevar Bush en 1945.

#Prérequis pour un wiki tenu par un modèle local

Le gist ne suppose aucun fournisseur précis. Il lui faut un agent capable de lire et d'écrire des fichiers, piloté par un modèle. En local, cela donne les briques suivantes.

Ollama, à jour

Il sert le modèle sur http://localhost:11434. La commande ollama launch utilisée plus bas n'existe que dans les versions récentes. L'installation est traitée dans notre guide « Installer Ollama ».

Un agent avec accès aux fichiers

Une interface de discussion ne suffit pas : il faut un outil qui ouvre, crée et modifie des fichiers sur le disque. L'exemple ci-dessous utilise OpenCode, agent open source en terminal cité dans le gist, qui lit un fichier AGENTS.md placé à la racine du dossier.

Un modèle qui sait appeler des outils

Lire et écrire des fichiers passe par des appels d'outils. Choisissez un modèle qui affiche la capacité tools dans la bibliothèque Ollama. Notre guide « OpenCode + Ollama » en liste plusieurs, dont qwen3-coder:30b, devstral-small-2:24b et gpt-oss:20b.

De la mémoire pour le contexte

Repères en Q4_K_M pour les seuls poids : environ 5 Go pour 7 milliards de paramètres, 9 Go pour 14 milliards, 19 Go pour 32 milliards. La documentation d'Ollama demande au moins 64 000 tokens de contexte pour les agents, ce qui s'ajoute à ces chiffres.

Git

Le wiki n'est qu'un dossier de fichiers Markdown : le gist fait remarquer qu'en faire un dépôt git donne l'historique des versions sans rien ajouter.

Obsidian (facultatif)

Pour lire le wiki, suivre les liens et afficher le graphe des pages. N'importe quel éditeur Markdown convient ; Obsidian n'intervient pas dans la rédaction.

#Mise en place avec Ollama, pas à pas

Les commandes sont écrites pour macOS et Linux ; sous Windows, le plus simple est de passer par WSL. L'arborescence et le fichier de conventions sont des exemples à adapter : le gist précise que la structure des dossiers, les conventions et le format des pages dépendent de votre domaine et de votre modèle, et que tout y est facultatif et modulaire.

1. 01
   Créer le dossier et le dépôt

   Un dossier pour les sources brutes, un dossier pour les pages, un index, un journal, le tout sous git.
2. 02
   Écrire le fichier de conventions

   Un AGENTS.md à la racine qui décrit la structure, les règles d'écriture et les trois procédures : ingestion, question, vérification.
3. 03
   Lancer le modèle et l'agent

   Ollama sert un modèle capable d'appeler des outils, avec 64 000 tokens de contexte ; OpenCode s'ouvre dans le dossier du wiki.
4. 04
   Ingérer une première source

   Un seul document, traité sous vos yeux, relu puis enregistré dans git.
5. 05
   Interroger et ranger les réponses

   Les questions se posent au wiki ; les synthèses utiles deviennent des pages.
6. 06
   Vérifier régulièrement

   Une passe de contrôle qui liste les contradictions, les pages orphelines et les liens cassés.

#1. Créer le dossier et le dépôt

mkdir -p ~/wiki/raw
mkdir -p ~/wiki/wiki/sources ~/wiki/wiki/entites ~/wiki/wiki/concepts
cd ~/wiki
touch wiki/index.md wiki/log.md
git init

Le dossier raw/ recevra vos documents, le dossier wiki/ les pages rédigées par le modèle. Les noms sont libres, tant que la séparation entre les deux reste visible.

#2. Écrire le fichier de conventions

C'est la pièce qui compte le plus. Sans elle, l'agent improvise une structure différente à chaque session. Créez un fichier AGENTS.md à la racine de ~/wiki, par exemple sur cette base :

# Conventions du wiki

Tu es le mainteneur de ce wiki. Tu écris et tu mets à jour les pages.
L'humain choisit les sources et pose les questions.

## Structure
- raw/ : sources brutes. Lecture seule : ne jamais modifier, renommer ni supprimer.
- wiki/sources/ : une page de résumé par source.
- wiki/entites/ : une page par personne, organisation, outil ou produit.
- wiki/concepts/ : une page par notion.
- wiki/index.md : catalogue de toutes les pages (lien + résumé d'une ligne), par catégorie.
- wiki/log.md : journal chronologique, ajout seul.

## Règles d'écriture
- Noms de fichiers en minuscules, avec tirets, sans accents.
- Liens internes au format [[nom-de-page]].
- Chaque affirmation renvoie au fichier de raw/ dont elle vient.
- Si deux sources se contredisent, garder les deux versions et le signaler.
- Avant de créer une page, vérifier dans l'index qu'elle n'existe pas déjà.

## Ingestion
Quand on te demande d'ingérer un fichier de raw/ :
1. Lire la source en entier.
2. Présenter les points clés et attendre la validation.
3. Écrire la page de résumé dans wiki/sources/.
4. Mettre à jour ou créer les pages d'entités et de concepts concernées.
5. Mettre à jour wiki/index.md.
6. Ajouter une entrée à wiki/log.md : ## [AAAA-MM-JJ] ingest | Titre

## Question
1. Lire wiki/index.md, puis les pages utiles.
2. Répondre en citant les pages et les sources brutes.
3. Ne rien affirmer qui ne figure pas dans le wiki ; dire ce qui manque.
4. Si la réponse apporte une synthèse nouvelle, proposer de l'enregistrer comme page.

## Vérification
Signaler sans corriger d'office : contradictions, affirmations dépassées,
pages orphelines, concepts cités sans page, liens cassés.

Ce fichier est le nôtre, pas celui de Karpathy : le gist décrit le rôle du fichier de conventions sans en fournir de modèle, et recommande de le faire évoluer avec le modèle à mesure que vous voyez ce qui fonctionne dans votre domaine. Gardez-le court. L'agent le relit à chaque session, et chaque ligne occupe de la place dans le contexte.

#3. Lancer le modèle et l'agent

Téléchargez un modèle capable d'appeler des outils, puis ouvrez OpenCode dans le dossier du wiki. La commande ollama launch opencode démarre OpenCode avec un modèle servi par Ollama, à choisir dans le sélecteur. L'installation d'OpenCode elle-même est décrite dans notre guide « OpenCode + Ollama ».

# Un modèle généraliste avec appel d'outils (à adapter à votre mémoire)
ollama pull gpt-oss:20b

# Ouvrir l'agent dans le dossier du wiki
cd ~/wiki
ollama launch opencode

Reste le contexte. D'après la documentation d'Ollama, la fenêtre par défaut dépend de la VRAM (4 000 tokens en dessous de 24 Go, 32 000 entre 24 et 48 Go), alors que les agents en demandent au moins 64 000. La variable OLLAMA_CONTEXT_LENGTH la fixe au lancement du serveur ; si Ollama tourne déjà comme application ou comme service, réglez la valeur dans ses paramètres plutôt que de lancer un second serveur.

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Dans un autre terminal, une fois le modèle chargé :
ollama ps

La commande ollama ps indique si le modèle tient entièrement sur le GPU. S'il déborde sur le processeur, chaque ingestion devient très lente : prenez un modèle plus petit avant de rogner sur le contexte.

#4. Ingérer une première source

Déposez un premier document dans raw/, de préférence en Markdown ou en texte. Pour les pages web, le gist signale l'extension Obsidian Web Clipper, qui convertit un article en fichier Markdown. Donnez ensuite la consigne à l'agent :

Ingère raw/mon-premier-article.md en suivant AGENTS.md.
Présente-moi d'abord les points clés et attends ma validation avant d'écrire.

L'agent lit la source, propose ses points clés, puis crée et modifie les pages. Relisez le résultat avant d'aller plus loin : la page de résumé, les pages d'entités créées, l'index, le journal. Enregistrez ensuite l'état du wiki.

git status
git add -A
git commit -m "ingest: mon-premier-article"

#5. Interroger et ranger les réponses

Après quelques sources, posez vos questions à l'agent dans le même dossier. Demandez-lui explicitement de citer ses pages et ses sources, et de dire ce que le wiki ne contient pas.

D'après le wiki, qu'est-ce qui distingue l'approche A de l'approche B ?
Cite les pages et les sources brutes utilisées, et signale ce qui manque.
Si la réponse apporte une synthèse nouvelle, enregistre-la dans wiki/concepts/
puis mets à jour l'index et le journal.

#6. Vérifier régulièrement

Toutes les quelques ingestions, lancez une passe de vérification. Demandez une liste de problèmes avant toute correction : vous gardez la main sur ce qui est fusionné, renommé ou supprimé.

Fais une passe de vérification du wiki en suivant AGENTS.md.
Liste les problèmes trouvés, sans rien modifier pour l'instant.

Le journal se consulte sans agent. Avec le préfixe régulier des entrées, la commande donnée dans le gist affiche les dernières opérations (seul le chemin est adapté à notre arborescence) :

grep "^## \[" wiki/log.md | tail -5

#LLM Wiki ou RAG : ce que le patron ne remplace pas

Le gist oppose le wiki au RAG pour faire comprendre l'idée. Il ne dit pas que l'un remplace l'autre, et ce guide ne le dit pas non plus : les deux approches répondent à des situations différentes. Voici ce qui les sépare, sans chiffres, parce que nous n'avons pas de mesure à présenter.

Le moment du travail

Un RAG travaille à la question : il cherche des extraits, puis le modèle rédige. Le wiki travaille à l'ingestion : la synthèse est écrite une fois, puis relue à chaque question.

Ce qui est conservé

Un RAG conserve des extraits et leurs vecteurs, illisibles tels quels. Le wiki conserve des pages rédigées que vous pouvez lire, corriger et versionner.

L'infrastructure

Un RAG demande un modèle d'embeddings, une base vectorielle et une stratégie de découpage. Le wiki demande un dossier et un agent. Selon le gist, l'index suffit à une échelle modérée (de l'ordre d'une centaine de sources et de quelques centaines de pages) et évite de mettre en place une infrastructure de RAG à base d'embeddings.

La fidélité aux sources

Un RAG remet au modèle des passages originaux. Le wiki lui remet une reformulation écrite par un modèle, avec le risque d'erreur que cela comporte.

Le volume

Un RAG est conçu pour de grands corpus. Le wiki est borné par ce que le modèle peut lire en une fois : l'index, les pages utiles et la source doivent tenir dans la fenêtre de contexte.

Au-delà de l'échelle modérée, le gist réintroduit lui-même la recherche. Il cite qmd, un moteur de recherche local pour fichiers Markdown qui combine BM25, recherche vectorielle et reclassement par LLM, utilisable en ligne de commande ou comme serveur MCP. Un grand wiki finit donc par s'appuyer sur les briques d'un RAG, appliquées à des pages déjà synthétisées plutôt qu'aux documents bruts. Les deux approches se combinent plus qu'elles ne s'excluent.

En pratique, gardez un RAG classique quand le corpus est volumineux ou change sans cesse (documentation d'entreprise, tickets, contrats), quand la réponse doit reproduire le passage exact d'un document, ou quand plusieurs personnes aux droits différents interrogent la même base. Le LLM Wiki convient mieux à un sujet que l'on creuse pendant des semaines : veille, recherche, lecture d'un livre, préparation d'un dossier. Ce sont des usages que le gist cite lui-même.

#Limites à connaître, surtout en local

Les erreurs s'accumulent aussi

Une erreur de résumé écrite dans une page sera relue, citée et propagée aux pages suivantes. Dans un RAG, une mauvaise réponse disparaît avec la conversation ; dans un wiki, elle reste. C'est la raison d'être du renvoi systématique aux sources brutes et de la relecture des modifications.

Un modèle local a moins de marge

L'ingestion demande de suivre une longue consigne, de lire plusieurs fichiers et d'en modifier une dizaine sans en oublier. Les petits modèles tiennent en général moins bien ce genre de tâche longue que les grands modèles hébergés derrière les agents cités dans le gist. Jugez sur vos propres sources, en commençant petit.

La fenêtre de contexte borne tout

Une source très longue, un index qui a grossi et dix pages à relire ne tiennent pas toujours dans 64 000 tokens. Découpez les sources volumineuses par chapitre et gardez des pages courtes.

L'ingestion prend du temps

Chaque source déclenche une série de lectures et d'écritures. Sur une machine modeste, comptez sur un traitement source par source plutôt que sur l'import d'une bibliothèque entière en une soirée.

La structure dérive

Sans règles strictes, l'agent crée des doublons (la même entité sous deux noms) et des pages que rien ne relie. Les règles de nommage du fichier de conventions et la passe de vérification servent à cela.

#Astuces et dépannage

L'agent saute des étapes de l'ingestion

Le contexte est probablement trop court : la consigne sort de la fenêtre en cours de route. Vérifiez la valeur de OLLAMA_CONTEXT_LENGTH, raccourcissez AGENTS.md ou découpez la source.

L'agent décrit ce qu'il ferait, sans rien écrire

Le modèle gère mal l'appel d'outils. Prenez un modèle qui affiche la capacité tools dans la bibliothèque Ollama.

La même entité apparaît sous deux noms

Demandez une passe de vérification ciblée sur les doublons, validez les fusions une par une, puis ajoutez la règle de nommage qui manquait au fichier de conventions.

L'index devient trop long

Scindez-le par catégorie, avec un index principal qui renvoie vers des index secondaires, ou ajoutez un outil de recherche sur les fichiers Markdown, comme qmd que cite le gist.

Les réponses ignorent des pages existantes

L'index n'a pas été mis à jour lors d'une ingestion. Faites-le reconstruire à partir du contenu du dossier wiki/, puis vérifiez le journal.

#Des mises en œuvre prêtes à l'emploi

Vous n'êtes pas obligé de tout écrire à la main. Hermes Agent, l'agent open source de Nous Research, documente une skill intégrée nommée llm-wiki, rangée dans sa catégorie recherche, qui reprend ce patron. Si vous utilisez déjà cet agent avec Ollama, c'est un point de départ plus rapide ; la page de documentation, en lien ci-dessous, en décrit le fonctionnement. Le principe reste le même : lisez les conventions avant de leur confier vos sources.

#Sources

Tout ce qui est dit du patron vient du post et du gist d'Andrej Karpathy. Les réglages d'Ollama et d'OpenCode viennent de leur documentation, déjà citée dans notre guide « OpenCode + Ollama ». Relisez ces pages avant de coller une commande : ces outils évoluent vite.

https://x.com/karpathy/status/2039805659525644595

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

https://hermes-agent.nousresearch.com/docs/user-guide/skills/bundled/research/research-llm-wiki

https://docs.ollama.com/context-length

https://docs.ollama.com/integrations/opencode

#Pour aller plus loin

Le LLM Wiki se situe au croisement de plusieurs sujets déjà traités sur le site. Chacun de ces guides couvre ce que celui-ci laisse volontairement de côté.

RAG local : introduction

Embeddings, base vectorielle, découpage : le fonctionnement du RAG classique, à connaître pour savoir quand il reste le bon choix. https://quelllm.fr/guide/rag-local-introduction

Obsidian + LLM local

Brancher un modèle local sur un coffre Obsidian avec les plugins Copilot et Smart Connections, pour discuter avec des notes que vous écrivez vous-même. https://quelllm.fr/guide/obsidian-llm-local-ollama

NotebookLM en local

Les outils open source qui reproduisent les carnets de sources et les réponses citées, sans wiki intermédiaire. https://quelllm.fr/guide/notebooklm-local-alternative

Fine-tuning vs RAG

Karpathy évoque dans son post, comme piste d'exploration, l'affinage d'un modèle sur les données de sa base. Ce guide aide à décider si cela vaut l'effort. https://quelllm.fr/guide/fine-tuning-vs-rag-choisir

OpenCode + Ollama

L'installation de l'agent utilisé ici, le réglage du contexte et les permissions. https://quelllm.fr/guide/opencode-ollama-agent-terminal