La mémoire qui apprend : Karpathy défie le RAG avec une base de connaissances évolutive

Il y a un moment que toute personne ayant travaillé intensément avec un modèle linguistique connaît bien : le reset. Vous êtes en train de construire quelque chose de complexe, peut-être une architecture logicielle élaborée ou une recherche croisant des dizaines de sources, et le modèle a tout compris, il suit le fil, répond avec une précision chirurgicale. Puis la session se termine, ou vous atteignez la limite de contexte, et l'IA oublie tout. Elle repart de zéro. Vous devez lui réexpliquer qui vous êtes, ce que vous faites, quelles décisions vous avez prises ensemble. C'est comme le film « Memento » de Christopher Nolan, où le protagoniste doit se tatouer les informations sur le corps parce que sa mémoire à court terme ne fonctionne pas : brutal, redondant et profondément frustrant.

Andrej Karpathy, ancien directeur de l'IA chez Tesla et cofondateur d'OpenAI, aujourd'hui engagé dans un projet indépendant, a décrit ce problème exactement en ces termes, et le 2 avril 2026, il a publié sur X une proposition pour le résoudre. Le post est devenu viral avec plus de 16 millions de vues, et le GitHub Gist d'approfondissement a dépassé les 5 000 stars en quelques jours. Il n'annonçait ni un nouveau modèle ni un benchmark. Il décrivait un changement dans la façon dont il utilise lui-même les modèles linguistiques, un changement qui a déclenché un débat technique passionné et, comme souvent, quelques simplifications excessives.

Qu'est-ce que le RAG, et pourquoi est-il devenu la méthode dominante

Avant de comprendre ce que propose Karpathy, il vaut la peine d'expliquer ce qu'est le RAG, car au cours des trois dernières années, il est devenu l'approche standard pour donner aux modèles linguistiques l'accès à des connaissances externes, et parce qu'il comporte certains problèmes structurels que tout le monde ne nomme pas explicitement.

Retrieval-Augmented Generation signifie, littéralement, génération augmentée par la récupération. Dans un système RAG standard, les documents sont découpés en fragments arbitraires appelés « chunks », convertis en vecteurs mathématiques appelés embeddings, et stockés dans une base de données spécialisée. Lorsque l'utilisateur pose une question, le système effectue une « recherche par similitude » pour trouver les fragments les plus pertinents et les insère dans le contexte du modèle.

Le mécanisme fonctionne, et fonctionne bien dans de nombreux scénarios. Mais il apporte avec lui certaines caractéristiques qui, dans certains contextes, deviennent des problèmes. Le premier est la nature fondamentalement stateless du système : chaque interrogation repart de zéro, cherchant à nouveau parmi les sources, sans que rien ne s'accumule au fil du temps. Il n'y a pas de mémoire des élaborations passées, pas d'accumulation de connaissances. Le deuxième problème concerne la qualité de la récupération : découper un document en morceaux et chercher par similitude vectorielle fonctionne bien lorsque la réponse se trouve dans un ou deux fragments contigus, mais devient imprécis lorsqu'une question nécessite de synthétiser des idées réparties sur des dizaines de sources différentes. Le troisième, souvent sous-estimé, est la complexité infrastructurelle : bases de données vectorielles, pipelines d'embeddings, systèmes d'indexation, tout cela a un coût en termes de latence, de maintenance et d'opacité. Les vecteurs ne sont lisibles par aucun être humain, ce qui rend difficile de comprendre pourquoi le système a récupéré certains fragments plutôt que d'autres.

Comment fonctionne la machine à mémoire

La proposition de Karpathy part d'une question différente : au lieu de chercher à chaque fois, que se passerait-il si l'IA construisait une connaissance structurée à l'avance, puis la consultait directement ?

Karpathy a publié sur GitHub Gist la description d'un système à trois dossiers qui permet à un modèle de compiler et de maintenir une base de connaissances sans base de données vectorielle. L'architecture est délibérément simple. Le premier dossier, raw/, contient le matériel brut : PDF, notes, articles web, dépôts GitHub, jeux de données. Le deuxième, wiki/, héberge les articles compilés par le modèle, un par concept ou sujet. Le troisième est un fichier index.md, une carte globale de tous les articles, dimensionnée pour tenir dans la fenêtre de contexte du modèle.

Karpathy utilise l'Obsidian Web Clipper pour convertir les contenus web en fichiers Markdown, en s'assurant que les images sont également sauvegardées localement afin que le modèle puisse les référencer grâce à ses capacités de vision.

L'étape centrale, celle qui différencie l'approche d'une simple archive, est la compilation. Au lieu d'indexer les fichiers, le modèle les « compile » : il lit les données brutes et écrit un wiki structuré, générant des résumés, identifiant les concepts clés, produisant des articles de style encyclopédique et, point fondamental, créant des backlinks entre idées liées.

Le système n'est pas statique : Karpathy décrit des cycles périodiques de « linting », où le modèle scanne le wiki à la recherche d'incohérences, de données manquantes ou de nouvelles connexions possibles. Le système se comporte comme une base de connaissances vivante qui s'auto-répare. Les requêtes effectuées sur le système sont archivées dans le wiki lui-même, de sorte que chaque exploration s'accumule : les réponses, les graphiques, les analyses sont insérés dans la base de connaissances, qui croît de manière cumulative.

À quelle échelle tout cela fonctionne-t-il ? Karpathy a précisé qu'il opère actuellement avec environ 100 articles et 400 000 mots de matériel source, et qu'à cette dimension, la capacité du modèle à naviguer à travers les résumés et les fichiers d'index est plus que suffisante. Une analyse menée par MindStudio a révélé que cette approche peut réduire la consommation de jetons jusqu'à 95 % par rapport au chargement intégral des documents dans le contexte, un avantage qui s'amenuise par rapport à des pipelines RAG optimisés.

Le post de Karpathy s'inscrit dans une séquence précise de sa réflexion sur l'interaction homme-IA : après le « vibe coding » de février 2025, où l'utilisateur accepte le code généré sans le réviser ligne par ligne, et l'ingénierie agentique de janvier 2026, où les humains orchestrent des agents au lieu d'écrire du code directement, les LLM Knowledge Bases représentent la troisième phase : l'IA gère la connaissance, pas seulement le code. L'humain devient conservateur, pas écrivain. Capture d'écran tirée du profil X d'Andrej Karpathy

L'avantage de la lisibilité

L'un des aspects les plus concrets de la proposition, et souvent celui qui convainc le plus facilement ceux qui viennent d'expériences de RAG d'entreprise, concerne la transparence. En traitant les fichiers Markdown comme source de vérité, Karpathy évite le problème de la « boîte noire » des vecteurs d'embeddings. Chaque affirmation du modèle peut être rattachée à un fichier .md spécifique qu'un être humain peut lire, modifier ou supprimer.

Cette caractéristique a des implications pratiques non négligeables. Dans un système RAG, lorsque le modèle renvoie une réponse erronée ou partielle, retracer l'origine du problème nécessite de comprendre quels fragments ont été récupérés, comment ils ont été segmentés, et pourquoi la recherche par similitude a privilégié certains vecteurs plutôt que d'autres. Dans un wiki Markdown bien structuré, l'erreur est visible : il y a un article mal écrit, un backlink manquant, une information pas à jour. C'est un problème éditorial, pas un problème d'algèbre linéaire.

L'architecture est délibérément construite sur Markdown comme standard ouvert et indépendant des outils. Si Obsidian devait disparaître ou changer ses conditions de licence, la base de connaissances resterait un répertoire de fichiers en texte simple que n'importe quel éditeur peut ouvrir. C'est une forme de souveraineté sur ses propres données que les solutions d'entreprise ont tendance à ne pas offrir.

Lex Fridman a confirmé utiliser un système similaire, en ajoutant une couche de visualisation dynamique : il génère du HTML avec JavaScript pour trier et filtrer les données, et construit des mini-bases de connaissances temporaires focalisées sur un thème spécifique à charger en mode vocal pendant ses courses de 10-15 kilomètres. Ce « wiki éphémère » préfigure une direction intéressante : on ne chatte pas avec une IA, on génère une équipe d'agents pour construire un environnement de recherche personnalisé pour une tâche spécifique, qui se dissout ensuite.

Il y a aussi une implication à long terme que Karpathy ne mentionne qu'en passant mais qui mérite d'être nommée. Au fur et à mesure que le wiki est répétitivement « linté » (révision automatisée) et affiné, il devient une représentation de plus en plus propre du domaine : dédoublonnée (l'information n'apparaît qu'une seule fois), liée par des références croisées, écrite dans un style cohérent. À ce stade, la base de connaissances devient un candidat comme données d'entraînement : au lieu de faire continuellement du prompting sur un grand modèle général avec le wiki, une équipe pourrait faire du fine-tuning d'un modèle plus petit sur ce corpus soigné, encodant la base de connaissances dans les poids du modèle et transformant une archive personnelle ou départementale en une intelligence spécialisée privée.

Où le RAG résiste

Le récit du « RAG est mort » qui a circulé sur les réseaux sociaux dans les jours suivant le post de Karpathy est exactement le type de simplification qui fait des dégâts. Le RAG n'est pas mort, et il existe des contextes précis où il reste la bonne approche, souvent la seule praticable.

La première limite de la proposition de Karpathy est explicitée par Karpathy lui-même : l'échelle. Lorsque le nombre d'articles dépasse quelques centaines, ou que les sources dépassent des millions de mots, l'index lui-même devient trop grand pour tenir dans la fenêtre de contexte, et la récupération redevient nécessaire. L'approche est explicitement positionnée pour un usage personnel et au sein de petites équipes, pas pour des archives documentaires à l'échelle d'une entreprise. Une entreprise avec des millions de documents, des systèmes hérités hétérogènes, des exigences de conformité strictes et des centaines d'utilisateurs simultanés a besoin de quelque chose de plus robuste qu'un répertoire de fichiers Markdown.

La deuxième limite concerne la fraîcheur des données. Le RAG est particulièrement adapté lorsque les sources changent fréquemment et que l'on ne peut pas se permettre de « recompiler » la connaissance à chaque fois. Un assistant pour le support client qui doit répondre en utilisant la documentation à jour d'un produit en constante évolution, ou un système d'analyse financière qui doit intégrer des nouvelles de marché en temps réel, a besoin d'une récupération dynamique, pas d'un wiki mis à jour périodiquement.

Le troisième problème, peut-être le plus insidieux, est ce que l'on appelle dans les commentaires du GitHub Gist le « memory drift » (dérive de la mémoire). Avec la croissance de la base de connaissances, comment gère-t-on la dérive sémantique, ce phénomène par lequel le sens d'un terme, d'un concept ou d'une affirmation se déplace graduellement au fil du temps, à chaque réécriture ou synthèse, s'éloignant de l'intention originale sans que personne ne s'en aperçoive explicitement, et comment évite-t-on que les informations contradictoires ne s'accumulent ?

Chaque fois que le modèle réécrit ou synthétise un article, il y a un risque : si la synthèse est imprécise, ou si deux sources contradictoires sont intégrées de manière incohérente, l'erreur entre dans la base et se propage. Dans le RAG, un document erroné reste isolé dans le corpus et peut être corrigé ou supprimé. Dans un wiki compilé par l'IA, l'erreur peut avoir été reformulée et distribuée dans plusieurs articles liés, rendant la correction beaucoup plus compliquée.

Certaines propositions dans la communauté suggèrent d'intégrer le système avec SQLite, BM25 et TREESEARCH pour mieux gérer la croissance du corpus, et plusieurs commentateurs soulignent que les êtres humains doivent rester dans la boucle pour gérer le contexte de la connaissance préparé par l'IA et prévenir les dérives et les incohérences.

Il y a ensuite la question de la provenance des sources. Un wiki bien formaté est transparent dans sa structure mais pas nécessairement dans l'origine des affirmations. Sans un système rigoureux de citations internes qui trace chaque affirmation jusqu'au document source original, on obtient de la lisibilité sans vérifiabilité, une distinction qui, dans des contextes réglementés, médicaux ou juridiques, fait une différence substantielle.

Hybride ou confrontation ?

Comme l'a écrit un analyste dans un commentaire du Gist, le LLM Wiki est essentiellement une implémentation manuelle et traçable du Graph RAG : chaque affirmation renvoie aux sources, les relations sont explicites, la structure est lisible par les humains. C'est un point qui clarifie beaucoup de choses : les deux approches ne sont pas des opposés philosophiques, ce sont des solutions d'ingénierie optimisées pour des contextes différents, et la frontière entre elles est plus perméable que ne le suggère le débat en ligne.

Certaines équipes essaient déjà de combler le fossé avec des architectures multi-agents : une conception « Swarm Knowledge Base » porte le workflow de Karpathy à l'échelle d'un système de 10 agents orchestrés par une couche de contrôle, ajoutant des modèles superviseurs pour protéger le wiki partagé des hallucinations qui se cumulent. Un modèle focalisé sur l'évaluation, utilisé comme « quality gate », évalue et valide les brouillons de pages avant qu'ils n'entrent dans la base de connaissances active.

L'avenir le plus plausible n'est pas la victoire de l'un des deux paradigmes sur l'autre. C'est une architecture stratifiée où un wiki structuré et compilé gère la connaissance de domaine stable, mise à jour avec des cycles périodiques supervisés par des humains, tandis que la récupération dynamique intervient pour les sources live, les données fraîches et les corpus qui changent trop rapidement pour être compilés. La mémoire structurée comme fondations, la récupération comme fenêtre sur le monde extérieur, la révision humaine comme contrôle qualité qu'aucun système automatique ne peut encore remplacer complètement.

Dans le Gist, Karpathy note que son utilisation des jetons s'est déplacée de la génération de code vers la gestion de la connaissance structurée, une note apparemment marginale qui signale en réalité un changement de priorité dans l'usage réel des modèles avancés. La gestion des connaissances est en train de devenir le centre de gravité du travail avec les modèles linguistiques, et non plus la génération de code.

La vraie question n'est pas de savoir si Karpathy « bat » le RAG. Elle est de savoir quelle architecture maximise la fiabilité, l'évolutivité et la valeur opérationnelle dans le contexte spécifique où elle opère. Pour un chercheur indépendant, une petite équipe qui construit une documentation technique interne, ou un travailleur du savoir qui veut que son assistant IA cesse d'avoir des amnésies à chaque session, la proposition de Karpathy est concrète, applicable dès aujourd'hui, et résout un problème réel. Pour une entreprise avec des millions de documents, des données qui changent toutes les heures et des exigences de gouvernance strictes, le RAG dans sa forme évoluée, peut-être enrichi par des éléments de la proposition de Karpathy, reste la seule option praticable.

Pour les équipes qui se demandent s'il faut adopter cette approche ou investir dans un pipeline RAG complet, la réponse honnête est : commencez par ceci, et passez au RAG seulement lorsque la fenêtre de contexte devient un véritable goulot d'étranglement, pas un problème hypothétique. Vous serez probablement surpris de voir jusqu'où le Markdown structuré peut vous mener. Ce n'est pas la fin du RAG. C'est le début d'une conversation plus sophistiquée sur la façon dont les systèmes d'IA gèrent la mémoire dans le temps, une conversation que, jusqu'à il y a deux semaines, presque personne n'avait de la bonne manière.