L’équipe fondatrice d’OpenAI, et ancien directeur de l’IA chez Tesla, Andrej Karpathy, a publié sur X le workflow des « LLM Knowledge Bases ». Il explique comment, récemment, il a fait passer une grande partie de son volume de tokens de « manipulation de code » vers « manipulation de connaissances » : utiliser des LLM pour transformer des articles, des dossiers, des documents et des images dispersés en un wiki personnel auto-entretenu. L’ensemble du processus est déjà accumulé, dans ses propres projets de recherche : ~100 articles, ~400 000 mots, et l’écriture et la mise à jour sont faites entièrement par des LLM. Cet article récapitule l’setup complet de Karpathy et propose une checklist actionnable pour les développeurs qui veulent le reproduire.
Idée centrale : raw data → compilation par LLM → wiki → Q&A
La philosophie de conception de Karpathy peut se résumer en une phrase : « raw data entre, le LLM compile en wiki, le wiki est ensuite interrogé par le LLM, et les résultats de la requête sont réécrits dans le wiki ». La clé de l’ensemble du système est de faire passer le rôle humain de « prendre des notes » à « surveiller les notes écrites par le LLM ». Une base de connaissances n’est plus un Notion ou Roam Research maintenu manuellement, mais une collection de fichiers markdown automatiquement écrite et entretenue par un LLM.
Il décrit le fait qu’il modifie lui-même très rarement le wiki : l’écriture, l’ajout de liens, l’extraction de la structure, la vérification de la cohérence — tout est fait par le LLM. Ce mode « LLM pilote le contenu, humain supervise » est complètement différent de la manière dont la plupart des gens écrivent manuellement leur Obsidian/Notion : c’est le basculement central de ce workflow.
Step 1：Data Ingest — mettre toutes les données raw dans un dossier raw/
L’entrée de Karpathy est simple : créer un dossier raw/, y verser toutes les sources — PDF de thèses, articles de presse, repo de code, jeux de données, images, scripts de conférences. Le LLM utilise ensuite ce dossier comme entrée, et « compile » progressivement pour en sortir le wiki.
Il mentionne particulièrement deux outils :
Obsidian Web Clipper (extension) — transformer directement les articles web en fichiers .md et les stocker dans raw/
Hotkey personnalisé — télécharger les images pertinentes des pages web en local, afin que le LLM puisse les lire directement lors des références ultérieures
Conception clé : toutes les données externes existent sous forme « hors ligne, locale », pour éviter que, lors des requêtes ultérieures du LLM, il ne se bloque sur le problème « impossible de retrouver les liens sources ».
Step 2：Compilation du wiki par le LLM — génération automatique de catégories, d’articles et de backlinks
Une fois le dossier raw/ prêt, Karpathy « compile » incrémentalement (incrementally) un wiki — autrement dit, une arborescence de nombreux fichiers .md. Le LLM fait quatre choses :
Écrire des résumés pour toutes les données dans raw/
Classer les données en concepts
Écrire un article pour chaque concept
Créer des backlinks entre les articles
Ce processus est « incrémental » : les nouvelles données ajoutées à raw/ ne provoquent pas une recompilation complète ; le LLM ne met à jour que les parties du wiki affectées. Pour des thématiques de recherche accumulées sur la durée (le wiki de recherche de Karpathy fait déjà ~100 articles et ~400 000 mots), ce type de mise à jour incrémentale est bien plus pratique qu’une compilation massive unique.
Step 3：Utiliser Obsidian comme « front-end » IDE, avec des extensions comme Marp
Karpathy utilise Obsidian comme interface visuelle de ce système : il peut consulter en même temps raw/ , le wiki compilé, et des visualisations dérivées (slides, graphiques, etc.). Le gros avantage d’Obsidian, c’est qu’il s’agit lui-même d’un éditeur markdown : les fichiers .md écrits par le LLM sont donc naturellement compatibles, et il supporte les extensions (plugins).
Il mentionne particulièrement le plugin Marp — qui peut rendre le markdown directement au format de présentation, pour que le LLM ne produise pas seulement du texte, mais aussi des slides.
Step 4：Q&A — faire du wiki l’objet de requête du LLM
Quand le wiki de Karpathy atteint l’échelle « ~100 articles, ~400 000 mots », la capacité la plus intéressante apparaît : poser au LLM des questions arbitrairement complexes via un agent, qui ira lui-même chercher la réponse et citer les passages pertinents dans le wiki.
Au départ, il s’attendait à devoir utiliser un « RAG fancy » (recherche vectorielle, modèles d’embeddings, re-ranking, etc.) pour faire tourner une base de cette taille. Mais dans la pratique, il constate ceci : le LLM maintient lui-même des fichiers d’index et des résumés courts de chaque article ; lors des requêtes, il s’appuie sur ces index et résumés pour retrouver les passages pertinents. À l’échelle « ~400 000 mots », pas besoin d’un RAG trop complexe : ça fonctionne correctement.
Cette observation est cohérente avec le consensus industriel depuis 2024 : « base de vecteurs trop chaude, et dans beaucoup de cas, on n’en a pas besoin ». Tant que votre base de connaissances n’excède pas le million de mots, et que du markdown structuré + des index gérés par le LLM suffisent.
Step 5：Sorties — pas uniquement du texte, mais du markdown/slides/graphes
Une autre conception de Karpathy : il ne veut pas que le LLM renvoie seulement du texte dans le terminal, mais qu’il produise des sorties structurées — fichiers markdown, présentations Marp, graphiques matplotlib, données visualisées. Ces sorties sont consultables dans Obsidian.
Plus important encore : la boucle. Les résultats produits sont souvent « archivé » par Karpathy dans le wiki, ce qui renforce les requêtes futures. Il décrit « l’exploration et les requêtes s’accumulent toujours (add up) dans la base de connaissances » : c’est stateful, ça grandit, et c’est l’inverse du mode des conversations ChatGPT, où chaque fois on repart de zéro.
Step 6：Linting — auto-bilan par LLM, recherche de problèmes de cohérence et candidats de nouveaux articles
Karpathy fait passer le wiki sous un LLM pour des « checks » de santé, en traitant trois types de problèmes :
Détecter les incohérences des données (des descriptions contradictoires du même concept dans des chapitres différents)
Compléter les données manquantes via recherche sur le web
Trouver des liens trans-concepts intéressants, et recommander des candidats de nouveaux articles
Ce linting est la clé pour rendre le wiki « de plus en plus propre » avec le temps. Sans cela, le wiki compilé automatiquement accumule progressivement contradictions et bruit. Le LLM se débrouille bien sur cette tâche, et c’est, selon Karpathy, une des raisons pour lesquelles ce workflow peut durer.
Step 7：Outils supplémentaires faits maison — par exemple un moteur de recherche de wiki auto-hébergé
Karpathy mentionne qu’il a « vibe coded » un petit moteur de recherche, qui tourne sur son propre wiki. Il a deux usages : (1) lui-même l’utilise directement via une interface web ; (2) plus souvent, il passe ce moteur de recherche via une interface CLI, et le donne à un LLM comme outil, afin que le LLM puisse, lors de grandes requêtes, retrouver précisément les passages pertinents.
Ce pattern (un humain construit un CLI ; le LLM l’utilise comme outil) est au cœur des cadres d’agents comme Claude Code et OpenAI Codex : le LLM ne lit pas directement toutes les données, mais obtient le sous-ensemble dont il a besoin via des outils (CLI, moteur de recherche, système de fichiers, etc.).
Step 8：Directions futures — génération de données synthétiques, fine-tuning de modèles
Quand la taille du wiki devient suffisamment grande, Karpathy propose deux directions avancées :
Générer des données synthétiques (synthetic data) à partir du wiki — laisser le LLM produire automatiquement des paires Q&A, des articles d’enseignement, des exemples pour certains sujets
Fine-tuner un LLM dédié avec des données synthétiques — pour que ton LLM personnel « sache » ces données dans ses poids, au lieu de les lire uniquement dans la context window
Cette direction fait passer la base de connaissances de « mémoire externe » à « mémoire internalisée », et constitue l’étape suivante de l’IA personnalisée. Mais Karpathy reconnaît lui-même que cela demande davantage d’infrastructures, et que pour l’instant ça reste de l’exploration.
L’idée « Idea File » de Karpathy : partager la vision, pas le code
Après que ce post soit devenu viral, Karpathy a proposé un nouveau concept dans ses posts suivants : « idea file ». À l’ère des agents LLM, plutôt que de partager un code précis, il vaut mieux partager des « idées », pour que l’agent en fasse une personnalisation et construise quelque chose pour vous.
Il a mis les « idea file » des LLM Knowledge Bases de Karpathy dans un GitHub gist, en gardant volontairement tout abstrait, avec de la place pour que les agents de chacun puissent s’épanouir. Cela pourrait devenir un nouveau format de partage dans la communauté dev : pas un repo GitHub, pas un package npm, mais un « document de spécifications », conçu pour être lu par un LLM.
Recommandation d’implémentation : comment démarrer pour les lecteurs à Taïwan
Pour les développeurs taïwanais qui veulent reproduire ce système, voici un chemin d’entrée pragmatique :
Obsidian est un logiciel gratuit, compatible macOS/Windows/Linux, téléchargeable depuis le site officiel
L’extension Web Clipper peut être installée sur Chrome/Firefox/Edge
Côté LLM, vous pouvez choisir Claude Code (CLI), ChatGPT (API), ou Ollama local (si vous avez une carte graphique assez puissante)
Créer deux dossiers raw/ et wiki/ à côté de votre Obsidian vault, et ajouter en plus du .gitignore un contrôle de version (au cas où le LLM écrirait mal)
Commencer par un sujet de recherche que vous connaissez le mieux — par exemple « dynamique de conformité des exchanges crypto en 2026 », « architecture d’inférence LLM » — puis accumuler jusqu’à 30–50 articles : la capacité de Q&A s’améliorera nettement
Dans la dernière partie de son post, Karpathy dit : « Ici, il y a de la place pour construire un super nouveau produit, pas ce format où l’on assemble des scripts grossiers à la main. » Pour les builders, ce thread est à la fois une explication de workflow et un sujet de création d’entreprise : le marché des LLM qui génèrent automatiquement un wiki, avec aucun gagnant produit clairement établi.
Cet article, où Karpathy révèle en personne la méthode complète pour construire une base de connaissances personnelle avec un LLM, est apparu pour la première fois sur 鏈新聞 ABMedia.
