LLM Wiki de Karpathy : pré-digérer ses sources plutôt que les réinterroger

Le réflexe par défaut, quand on veut qu’un LLM travaille sur un corpus personnel, c’est d’envoyer le même PDF, le même dump Notion, le même dossier de mails à chaque conversation. À chaque fois, le modèle relit, résume mentalement, perd la moitié des liens transverses, et facture des tokens pour reconstruire ce qu’il avait déjà compris hier. La proposition de Karpathy dans son gist llm-wiki.md est de retourner ce flux : le LLM digère vos sources une fois dans un wiki Markdown structuré, puis travaille à partir de ce wiki, pas des fichiers bruts.

C’est un déplacement modeste sur le papier, et un changement de modèle mental une fois qu’on y est. La mémoire cesse d’être un transit pour devenir un artefact que l’on accumule.

Trois dossiers, pas dix

L’architecture tient en trois choses :

raw/, les sources immuables. PDF, articles, transcripts, captures, notes. Le LLM les lit, ne les modifie jamais. C’est la couche de vérité brute.
wiki/, la couche que le LLM possède entièrement, comme le formule Karpathy : “the LLM owns this layer entirely”. Pages d’entités, pages de concepts, comparaisons, synthèses. Toute en Markdown, avec des liens internes.
Un fichier schéma, un CLAUDE.md (ou équivalent) qui dit comment le wiki est structuré, quelles conventions le LLM doit respecter, quels workflows il doit suivre. C’est ce qui transforme un chatbot générique en mainteneur discipliné.

À ça s’ajoutent deux fichiers qui font le squelette du wiki : index.md (catalogue thématique, mis à jour à chaque ingestion) et log.md (journal chronologique append-only, lignes du type ## [2026-04-02] ingest | Titre de l'article). Banal et puissant : on a une chronologie et un sommaire, sans rien construire à la main.

Ingest, query, lint

Trois opérations couvrent le cycle de vie, et c’est intentionnellement court.

Ingest. Une source à la fois. Le LLM la lit, en discute les points saillants avec moi, écrit une page de synthèse, met à jour les pages d’entités touchées et l’index, et ajoute une ligne dans log.md. Une heure d’article devient un nœud dans une toile de pages déjà existantes.

Query. On pose une question au LLM. Il cherche dans le wiki, synthétise une réponse avec des citations vers les pages concernées. Karpathy ajoute une phrase importante : “Good answers can be filed back into the wiki.” La réponse devient elle-même un actif, pas un message perdu dans un fil.

Lint. Périodiquement, le LLM se met en posture de vérificateur : contradictions entre pages, claims devenus obsolètes, pages orphelines, liens manquants. C’est la maintenance qu’aucun humain ne fait dans son Notion personnel, et que le modèle fait avec une obstination ennuyeuse.

Le levier est dans le fichier schéma

C’est le détail qui distingue ce système d’un dump RAG mal nommé.

La partie ennuyeuse d’entretenir une base de connaissances n’est pas la lecture ni la pensée, c’est la tenue de livre.

Le fichier CLAUDE.md (ou AGENTS.md) du wiki encode ces règles de tenue de livre : quels templates pour quels types de documents, quelles métadonnées sont obligatoires, comment résoudre les conflits, quel ton garder. C’est exactement le même rôle que dans un projet Claude Code bien tenu, sauf qu’ici le projet, c’est votre cerveau secondaire.

C’est aussi pour ça que la qualité du wiki dépend plus du schéma que du modèle. Un schéma flou produit un wiki diffus. Un schéma précis, “chaque entité a une section Histoire, une section Liens, une section Controverses”, produit un wiki qui se relit.

Ce qui me plaît : la mémoire est un artefact

J’ai écrit la semaine dernière que la fragmentation mémoire entre agents est un choix. Le wiki layer en est une réponse opérationnelle. Le wiki est un artefact local, versionnable, lisible sans agent, partageable entre Claude Code, Codex, et n’importe quel autre client MCP qui sait ouvrir un dossier.

C’est aussi ce qui le distingue des fichiers mémoire d’un agent en cours de session : ces derniers sont du contexte de travail court terme. Le wiki est l’index long terme. Les deux couches cohabitent ; elles ne se remplacent pas.

Et il y a un effet boule de neige que la formulation de Karpathy capte bien : la connaissance compose, au lieu d’être re-dérivée à chaque question. Trois mois d’ingestions soigneuses produisent un actif que dix re-relectures de PDF ne produiront jamais.

Ce qui me retient : qui arbitre les contradictions

Le point faible structurel est l’opération lint. Quand le LLM trouve une contradiction entre deux pages, il peut la flagger, mais il ne peut pas la résoudre sans biais. Il choisira la version la plus récente, ou la plus alignée avec le reste du wiki, ce qui n’est pas la même chose que la version la plus vraie. Si vous ingérez une source erronée tôt, sa version finit par s’imposer comme la forme attendue.

Deux disciplines minimes répondent à ça : marquer chaque page de la provenance (quelle source raw/, quelle date d’ingestion) et conserver une trace dans log.md des révisions qui contredisent une version antérieure. C’est la même logique que dans n’importe quel système d’information sérieux, savoir d’où vient un fait est plus important que le fait lui-même.

Karpathy résume le partage humain/machine d’une formule juste :

The human’s job is to curate sources, direct the analysis, ask good questions. The LLM’s job is everything else.

L’arbitrage est l’une des choses qui restent à l’humain. Le reste, la lecture, la rédaction, le linkage, l’entretien, peut s’externaliser sans regret.

Si cela vous a parlé, vous aimerez Mémoire partagée entre agents IA : la fragmentation est un choix et Fichiers mémoire : donner à ton agent un cerveau de travail à court terme. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.