Load less, remember more
On this page
Andrey Karpathy a publié il y a quelques jours un gist décrivant un concept qu'il appelle le « LLM Wiki ». En gros, une base de connaissances où le LLM maintient un wiki persistant et structuré entre l'utilisateur et les sources brutes, au lieu de tout redécouvrir from scratch à chaque requête. Quelque chose de familier...
Même schéma que ce qu'on a construit par-dessus nos CLAUDE.md pour nos repos. Même schéma que ce qu'Anthropic utilise dans des centaines de skills Claude Code en interne.
Le wiki de Karpathy
Le gist décrit trois couches. Les sources brutes vivent dans un corpus immuable. Le wiki est un dossier de pages markdown générées par le LLM : résumés, pages d'entités, pages de concepts, références croisées. Une table des matières (CLAUDE.md, AGENTS.md) explique au LLM comment le wiki est structuré et ce qu'il faut faire quand de nouvelles sources arrivent ou quand on lui pose des questions.
Trois opérations les lient.
- Ingest : une source arrive → le LLM la lit → écrit un résumé → met à jour les pages concernées → ajoute une entrée au log.
- Query : on pose une question → le LLM lit l'index → trouve les pages pertinentes → synthétise une réponse avec citations.
- Lint : vérification périodique → signale contradictions, affirmations obsolètes, pages orphelines.
Karpathy positionne le tout face au RAG :
Le wiki accumule. Il capitalise. Il persiste.
Si ça marche, note Karpathy, c'est parce que la partie pénible de maintenir une base de connaissances n'est pas la lecture ou la réflexion. C'est le bookkeeping : actualiser les références croisées, maintenir les résumés à jour, noter où de nouvelles données contredisent les anciennes. Les humains abandonnent leurs wikis parce que la charge de maintenance augmente plus vite que la valeur. Les LLM ne se lassent pas et peuvent éditer 15 fichiers en une seule passe. Le wiki reste à jour parce que la maintenance devient quasi gratuite.
Map-as-you-go
Les exemples de Karpathy sont surtout personnels et orientés recherche : wikis pour accompagner une lecture, suivi d'objectifs, deep dives de plusieurs semaines sur un sujet. Je suis étonné que la codebase ne soit pas dans la liste ! C'est précisément là qu'on l'applique chez Wisetax : règles métier, architecture cross-repo, conventions d'appel d'API, pipelines ETL par source.
Une codebase s'y prête naturellement. Le tribal knowledge s'accumule au fil des années : pourquoi tel modèle d'embeddings a battu tel autre sur notre corpus, quelles sources juridiques se chunkent par structure et lesquelles par paragraphe, quel mode de défaillance nous a forcés à mettre un wrapper de retry autour d'un appel d'API précis. Ce savoir n'est pas dans le code lui-même. Il vit dans des descriptions de PR éparpillées, des discussions Slack, des tickets Notion, les leçons non écrites qu'on garde en tête. Le wiki/knowledge layer contient tout ça.
En pratique, la plupart de ce qu'on synthétise pendant les sessions finit par atterrir dans ce wiki, avec Claude qui met à jour les fichiers manuellement ou via des hooks au fil de la session. Récemment, j'ai demandé à Claude d'analyser les sessions récentes de tous nos repos et de signaler les informations qu'on aurait oublié de consigner dans le knowledge layer. Une catégorie y échappait régulièrement : la trace des contraintes, c'est-à-dire les alternatives qu'on a envisagées et écartées, et pourquoi. Le raisonnement derrière les choix faits est systématiquement sauvegardé ; celui des choix rejetés, pas toujours (note pour moi-même : à voir si cette information mérite toujours d'être stockée).
Meta s'est aussi attaqué à sa codebase, à une autre échelle. Plus de 4K fichiers répartis sur quatre repos et trois langages, avec des agents IA produisant du code qui compilait mais qui était subtilement faux, ratant les conventions non écrites que chaque équipe avait en tête. Ils ont construit un pre-compute engine : une cinquantaine d'agents lisant chaque fichier en une seule passe, produisant 59 fichiers de contexte concis (chacun condense les conventions et pièges d'un domaine), chargés uniquement quand nécessaire. Tout le pipeline cartographié d'un seul coup.
Je pense que l'approche de Meta serait un peu overkill dans notre cas (bien que je sois curieux de lancer un processus similaire mais simplifié). Pour l'instant, on a une codebase produit qui ship tous les jours et pas besoin d'un mapping total en one-shot. Notre approche, c'est du map-as-you-go. Chaque nouvelle feature/fix laisse le knowledge layer un peu plus riche qu'il ne l'était.
Les deux approches captent des choses différentes. Une passe one-shot cartographie toute la codebase, y compris les zones que personne n'a touchées depuis des mois. Map-as-you-go ne capture que ce qu'on a vraiment visité. Le reste demeure dans l'ombre jusqu'à ce qu'on y passe et qu'on l'éclaire. Le fog-of-war à l'ancienne des jeux de stratégie, mais pour le code.
Ok, ça laisse des angles morts. Mais ça s'auto-corrige. La prochaine fois que quelqu'un travaille dans une zone non-cartographiée, le wiki s'enrichit à cet endroit. Et surtout, ce wiki avance avec le travail qu'on ship, sans effort de mapping séparé.
Espace et temps
D'un exemple à l'autre, les points de départ diffèrent. Le wiki de Karpathy pour la connaissance personnelle, les skills d'Anthropic pour le contexte des outils, le pre-compute de Meta pour les conventions de pipeline, notre map-as-you-go pour une codebase qui ship quotidiennement. Sous la surface, les deux mêmes mécanismes reviennent. Divulgation progressive (spatial) : un router léger en surface, des pages plus en profondeur chargées à la demande. On évite d'exploser la fenêtre de contexte quand seule une portion du corpus est pertinente. Compounding (temporel) : ne pas laisser le modèle redécouvrir ce qu'il avait déjà appris à la session précédente. Le persister, pour que la prochaine session soit mieux équipée.
Les deux vont ensemble. La divulgation progressive rend le compounding utilisable à grande échelle, puisque le corpus peut grandir alors qu'on ne charge que la portion pertinente. Le compounding rend la divulgation progressive intéressante à construire, puisque sinon le modèle redécouvre tout à chaque session.
Chaque approche articule les deux différemment. Karpathy utilise un fichier d'index comme router et le wiki comme compound. Anthropic utilise les descriptions de skills comme router et le catalogue de skills comme compound. Meta utilise des références opt-in comme router et les 59 fichiers de contexte comme compound. De notre côté, une table des matières dans CLAUDE.md qui pointe vers chaque fichier de knowledge avec un one-liner.
Quatre approches, même schéma : load less, remember more. L'articulation dépend de votre outil.