Back to Blog
BlogApril 3, 20261

Comment Andrej Karpathy Utilise les LLMs pour Construire des Bases de Connaissances Personnelles Dynamiques dans Obsidian

Comment Andrej Karpathy Utilise les LLMs pour Construire des Bases de Connaissances Personnelles Dynamiques dans Obsidian

Principaux enseignements

  • Le système d'Andrej Karpathy ingère des documents bruts (articles, publications, dépôts, images) dans un répertoire raw/, puis utilise des LLM pour les compiler progressivement en un wiki Markdown structuré, avec résumés, rétroliens, articles conceptuels et interconnexions.
  • Obsidian sert de frontend léger pour visualiser les données brutes, le wiki compilé et les sorties générées comme des diapositives Marp ou des graphiques Matplotlib, le LLM s'occupant de presque toute l'écriture et la maintenance.
  • À grande échelle (~100 articles, ~400K mots), des requêtes complexes sont traitées avec une dépendance minime au RAG ; le LLM maintient automatiquement les index et résumés pour une récupération de contexte efficace.
  • Le linting via des contrôles de santé par LLM identifie les incohérences, impute les données manquantes, suggère des connexions et propose de nouveaux articles, garantissant l'intégrité des données.
  • Les sorties vont au-delà du texte pour inclure du Markdown rendu, des diapositives, des visualisations ou du HTML dynamique, souvent réintégrés dans le wiki pour capitaliser la connaissance au fil du temps.
  • L'adoption par la communauté souligne des extensions comme la séparation des agents pour le contrôle de la contamination, des données synthétiques pour le fine-tuning, et des wikis éphémères générés par requête.

Le passage du code à la manipulation des connaissances

L'analyse montre un changement fondamental dans l'allocation des tokens : les derniers LLM de pointe excellent davantage dans la synthèse de connaissances que dans la pure génération de code. Karpathy rapporte qu'une grande partie de son débit de tokens manipule désormais des connaissances structurées stockées sous forme de fichiers Markdown et d'images, plutôt que des sorties terminales éphémères.

Ce flux de travail transforme la consommation passive de recherche en une base de connaissances active et auto-améliorante. Les sources brutes s'accumulent dans un répertoire dédié. Un LLM les "compile" ensuite progressivement — en générant des résumés, en catégorisant le contenu en concepts, en rédigeant des articles liés, et en établissant des rétroliens.

Les benchmarks de systèmes personnels similaires indiquent qu'une fois qu'un wiki atteint une masse critique, la complexité des requêtes augmente considérablement sans augmentation proportionnelle de la surcharge de récupération.

Processus d'ingestion et de compilation des données

Le pipeline commence par une collecte ciblée :

  • Gestion des sources : Les articles de recherche, publications, dépôts GitHub, jeux de données et images atterrissent dans raw/. Le contenu web est converti en Markdown via Obsidian Web Clipper, les images étant téléchargées localement pour une référence directe par le LLM.
  • Compilation incrémentale : Les LLM traitent initialement les nouveaux documents un par un, puis utilisent la reconnaissance de motifs pour gagner en efficacité. Des instructions comme "intègre ce nouveau doc à notre wiki" déclenchent la catégorisation, la synthèse et le lien.
  • Création de la structure : Le wiki résultant présente :
    • Des résumés par document
    • Des articles au niveau conceptuel
    • Des rétroliens bidirectionnels
    • Une organisation basée sur les répertoires

Les retours de la communauté suggèrent que le traitement par lots ou les pipelines multi-étapes améliorent les décisions de répertoire pour les ingestions plus importantes, bien que Karpathy maintienne les premières étapes avec un humain dans la boucle pour la qualité.

Obsidian comme interface idéale

Obsidian fonctionne comme un "IDE" minimal pour le système :

  • Visualisations simultanées des sources brutes, du wiki compilé et des graphiques.
  • Des extensions comme Marp permettent le rendu de diapositives directement depuis le Markdown généré par les LLM.
  • Les vues en graphe et la navigation par backlinks révèlent des connexions émergentes.

Les experts notent que la base locale-first en Markdown d'Obsidian minimise le verrouillage tout en supportant des outils personnalisés. Des alternatives comme VS Code avec des extensions Markdown existent, mais l'écosystème d'Obsidian accélère l'exploration visuelle et interactive.

Des stratégies de séparation émergent dans les implémentations communautaires : maintenir un coffre-fort personnel à fort signal aux côtés d'un coffre-fort "désordonné" destiné aux agents pour éviter la contamination par le contenu généré.

Questions-réponses avancées et génération de sorties

Une fois mis à l'échelle, le wiki supporte des requêtes sophistiquées :

  • Les LLM naviguent dans le corpus complet, en s'appuyant sur des index et des résumés auto-maintenus.
  • À environ 400 000 mots, les fenêtres de contexte gèrent efficacement des clusters liés sans recourir massivement au RAG vectoriel.
  • Les sorties s'adaptent aux besoins : rapports en Markdown, diaporamas Marp, figures Matplotlib, voire du HTML/JS dynamique pour des filtrages et visualisations interactifs.

Les artefacts générés alimentent souvent le wiki en retour, créant une boucle cumulative où les explorations enrichissent les futures requêtes. Lex Fridman et d'autres rapportent des configurations similaires pour la recherche podcast ou les interactions vocales en déplacement via des mini-wikis temporaires.

Vérification et maintenance pilotées par LLM

Une fonctionnalité remarquable est l'automatisation des "contrôles de santé" :

  • Détecter des affirmations incohérentes entre des sources ingérées à des semaines d'intervalle.
  • Combler les lacunes avec des outils de recherche web.
  • Identifier des connexions novatrices et des articles candidats.
  • Suggérer des questions de suivi pour approfondir la couverture.

Cela transforme le wiki d'un dépôt statique en un partenaire de recherche vivant. Les risques liés aux données obsolètes augmentent avec la croissance ; des audits versionnés et des mises à jour incrémentielles atténuent la dérive plus efficacement qu'une ingestion unique.

Outils émergents et explorations futures

Les utilisateurs étendent le noyau avec :

  • Des CLIs personnalisés ou des moteurs de recherche naïfs fournis aux LLM comme outils.
  • La génération de données synthétiques couplée à du fine-tuning pour intégrer la connaissance du wiki dans les poids du modèle.
  • La génération de wikis éphémères : une seule requête engendre une base de connaissance complète, vérifiée et itérée avant le rapport final—bien au-delà d'un simple décodage.

Les diagrammes architecturaux partagés dans la communauté visualisent les étapes, de l'ingestion à la compilation, la requête et l'enrichissement. Les produits qui comblent ce fossé pour les non-développeurs représentent une opportunité évidente, car chaque organisation maintient des données non structurées "brutes/" en attente de compilation.

Les comparaisons avec les PKM traditionnels (gestion de connaissances personnelle) soulignent les avantages : l'automatisation par LLM réduit la curation manuelle de 80 à 90 % dans les domaines de recherche actifs, tandis que les backlinks et les graphes font émerger des insights que les humains pourraient manquer.

Défis et Bonnes Pratiques

  • Gestion de l'Échelle : Les résumés peuvent devenir obsolètes ; priorisez les différences récentes et les audits.
  • Contrôle de la Contamination : Isolez le contenu généré par l'agent jusqu'à vérification.
  • Adoption Progressive : Commencez petit, laissez les modèles émerger avant une autonomie complète.
  • Simplicité des Outils : Des répertoires Markdown plats avec des schémas AGENTS.md suffisent ; la sur-ingénierie retarde la création de valeur.

Conseil actionnable : Commencez avec un sujet de recherche. Collectez 10-20 sources, incitez un LLM à compiler le wiki initial, puis itérez les requêtes et le linting. Mesurez la valeur par la profondeur des requêtes et le temps économisé par rapport à la recherche/prise de notes traditionnelle.

Conclusion

Le workflow de base de connaissances alimentée par LLM d'Andrej Karpathy représente une évolution pratique dans la façon dont les chercheurs et les praticiens interagissent avec l'information. En déléguant la compilation, la maintenance et la synthèse à des modèles compétents tout en conservant Obsidian pour une interaction intuitive, les utilisateurs atteignent une compréhension plus profonde avec moins de friction.

Cette approche s'amplifie avec le temps : chaque requête renforce la base, chaque passe de linting améliore l'intégrité. À mesure que les modèles de pointe progressent, attendez-vous à des outils plus larges qui automatisent des wikis entièrement éphémères à partir de questions naturelles.

Implémentez une version minimale aujourd'hui—ingérez votre prochain lot de recherche et laissez un LLM construire les fondations. Le passage de la consommation des connaissances à leur cultivation active pourrait redéfinir l'intelligence personnelle et organisationnelle à l'ère agentique.

Commencez petit, itérez sans relâche, et observez votre wiki personnel évoluer en un véritable multiplicateur intellectuel.

Share this article