168 points par GN⁺ 2026-04-05 | 15 commentaires | Partager sur WhatsApp
  • Andrej Karpathy a récemment expliqué qu’il dépensait désormais plus de tokens pour construire un dépôt de connaissances personnel que pour coder, et a publié un fichier guide d’idées pour générer ce wiki basé sur des LLM
  • Il suffit de transmettre ce fichier à un agent, qui génère ensuite le wiki de lui-même et en guide l’usage
  • Au lieu d’un modèle RAG qui réextrait l’information depuis les sources à chaque requête, le système repose sur un wiki persistant où le LLM rédige et maintient directement le wiki, ce qui permet une accumulation progressive des connaissances
  • Le wiki reste ouvert dans des outils comme Obsidian, tandis que le LLM édite et met à jour les fichiers Markdown en temps réel ; l’utilisateur se concentre sur le sourcing et les questions
  • Lorsqu’une nouvelle source est ajoutée, le LLM la lit puis l’intègre au wiki existant avec des références croisées ; le traitement d’une seule source peut mettre à jour 10 à 15 pages du wiki
  • Applicable à tous les domaines où les connaissances s’accumulent dans le temps : santé et objectifs personnels, recherche, notes de lecture, wiki interne d’équipe, etc.
  • En ramenant à presque zéro le coût de tenue à jour qui constituait le principal frein à la maintenance d’un wiki, le LLM résout un problème pour lequel beaucoup finissaient par abandonner

Idée clé

  • La plupart des usages documentaires des LLM reposent sur le RAG (Retrieval-Augmented Generation) : on téléverse une collection de fichiers, puis le LLM recherche les extraits pertinents au moment de la requête pour générer une réponse
    • NotebookLM, le téléversement de fichiers dans ChatGPT, et la plupart des systèmes RAG fonctionnent ainsi
    • Les connaissances sont réextraites à chaque fois, sans accumulation de savoir
  • L’approche de LLM-Wiki est différente : au lieu que le LLM cherche directement dans les sources, il construit et maintient progressivement un wiki persistant
    • Lorsqu’une nouvelle source est ajoutée, le LLM la lit, en extrait les informations clés et les intègre au wiki existant
    • Mise à jour des pages d’entités, révision des résumés thématiques, signalement des contradictions avec les affirmations existantes, renforcement de la synthèse
  • Le wiki devient un artefact persistant à accumulation composée : les références croisées sont déjà en place, les contradictions déjà signalées, la synthèse déjà intégrée
  • Exemple d’usage concret : un agent LLM ouvert d’un côté, Obsidian de l’autre, avec visualisation en temps réel des modifications apportées par le LLM
    • Obsidian = IDE, LLM = programmeur, wiki = base de code

Domaines d’application

  • Personnel : suivi des objectifs, de la santé, de la psychologie, du développement personnel — rassembler journaux, articles et notes de podcasts pour construire un historique structuré de soi
  • Recherche : construire sur plusieurs semaines ou mois un wiki complet portant une thèse évolutive, à partir de lectures d’articles, de papiers et de rapports
  • Lecture : organiser chapitre par chapitre avec des pages pour les personnages, les thèmes et les arcs narratifs — un lecteur individuel peut créer des milliers de pages interconnectées, à la manière de Tolkien Gateway
  • Business / équipe : constituer un wiki interne maintenu par LLM à partir de fils Slack, transcriptions de réunions, documents projet et appels clients
  • Aussi applicable à l’analyse concurrentielle, la due diligence, la planification de voyage, les notes de cours, l’exploration approfondie de loisirs et à tout domaine où les connaissances s’accumulent

Architecture (3 couches)

  • Sources brutes (Raw sources) : collection de documents source sélectionnés — articles, papiers, images, fichiers de données
    • Immuables : le LLM les lit mais ne les modifie pas
    • Cette couche constitue la source de vérité (source of truth)
  • Le wiki (The wiki) : répertoire de fichiers Markdown générés par le LLM — résumés, pages d’entités, pages de concepts, comparaisons, aperçus, synthèses
    • Le LLM contrôle entièrement cette couche : création de pages, mise à jour lors de l’ajout de sources, maintenance des références croisées
    • L’utilisateur lit, le LLM écrit
  • Le schéma (The schema) : document de configuration qui indique au LLM la structure du wiki, les conventions et le workflow (CLAUDE.md pour Claude Code, AGENTS.md pour Codex)
    • Fichier de configuration clé qui transforme le LLM, d’un simple chatbot, en gestionnaire de wiki systématique
    • Il évolue avec le temps, conjointement entre l’utilisateur et le LLM

Opérations principales

  • Ingest : ajouter une nouvelle source à la collection brute et demander au LLM de la traiter
    • Le LLM lit la source → discute du contenu principal → rédige une page de résumé dans le wiki → met à jour l’index → met à jour les pages d’entités et de concepts liées → ajoute une entrée au journal
    • Une seule source peut affecter 10 à 15 pages du wiki
    • On peut traiter les sources une par une avec supervision, ou réduire l’intervention humaine pour fonctionner par lots
  • Query : poser une question au wiki ; le LLM trouve les pages pertinentes et synthétise une réponse avec citations
    • La réponse peut prendre des formes variées : page Markdown, tableau comparatif, slide deck (Marp), graphique (matplotlib), canvas, etc.
    • Une bonne réponse peut être réenregistrée comme nouvelle page du wiki — l’exploration elle-même enrichit la base de connaissances
  • Lint : demander périodiquement au LLM de vérifier l’état du wiki
    • Points de contrôle : contradictions entre pages, affirmations obsolètes remplacées par des sources plus récentes, pages orphelines sans liens entrants, concepts importants sans page dédiée, références croisées manquantes, lacunes de données pouvant être comblées par recherche web

Indexation et journalisation

  • index.md : fichier centré sur le contenu — catalogue toutes les pages du wiki avec liens, résumé d’une ligne et métadonnées
    • Pour répondre à une requête, le LLM lit d’abord l’index puis explore les pages pertinentes
    • Fonctionne bien à l’échelle de ~100 sources et plusieurs centaines de pages sans infrastructure RAG basée sur des embeddings
  • log.md : enregistrement chronologique — consigne dans l’ordre les traitements d’ingest, les requêtes et les passages de lint
    • Si chaque entrée suit un préfixe cohérent, elle peut être parsée avec des outils Unix
      • Exemple : ## [2026-04-02] ingest | Article Titlegrep "^## \[" log.md | tail -5 pour afficher les 5 dernières entrées

Outils CLI optionnels

  • Quand le wiki grandit, on peut créer de petits outils pour permettre au LLM de fonctionner plus efficacement
  • qmd : moteur de recherche local pour fichiers Markdown — recherche hybride BM25/vecteur et reranking par LLM, le tout en local sur l’appareil
    • Prend en charge une CLI (sur laquelle le LLM peut faire un shell out) et un serveur MCP (que le LLM peut utiliser comme outil natif)
  • Pour un petit volume, le fichier d’index suffit ; selon les besoins, on peut aussi faire écrire par le LLM un simple script de recherche

Conseils et usage des outils

  • Obsidian Web Clipper : extension navigateur qui convertit des articles web en Markdown — utile pour ajouter rapidement des sources à la collection brute
  • Stockage local des images : dans Obsidian Settings → Files and links, on peut définir le dossier des pièces jointes, puis enregistrer des images sur disque local via un raccourci
    • Le LLM ne peut pas lire d’un seul coup un Markdown contenant des images inline ; il lit donc d’abord le texte puis examine les images séparément
  • Vue graphe d’Obsidian : idéale pour comprendre la forme générale du wiki — relations, pages hub, pages orphelines
  • Marp : format de slide deck basé sur Markdown — disponible via plugin Obsidian, permet de générer directement des présentations à partir du contenu du wiki
  • Dataview : plugin Obsidian qui exécute des requêtes sur le frontmatter des pages — si le LLM ajoute du frontmatter YAML (tags, dates, nombre de sources), il devient possible de générer des tableaux et listes dynamiques
  • Le wiki est un dépôt git de fichiers Markdown — historique des versions, branching et collaboration inclus gratuitement

Pourquoi ça fonctionne

  • Le principal obstacle à la maintenance d’une base de connaissances n’est ni la lecture ni la réflexion, mais la tenue à jour (bookkeeping) : actualiser les références croisées, mettre à jour les résumés, signaler les contradictions, maintenir la cohérence sur des dizaines de pages
  • Si les gens abandonnent leurs wikis, c’est parce que la charge de maintenance augmente plus vite que la valeur produite
  • Le LLM ne s’ennuie pas, n’oublie pas de mettre à jour les références croisées et peut traiter 15 fichiers à la fois → le coût de maintenance tend presque vers zéro
  • L’idée est intellectuellement liée au Memex (1945) de Vannevar Bush : un dépôt de connaissances personnel, activement organisé, où les liens entre documents ont autant de valeur que les documents eux-mêmes
    • Le LLM prend en charge la question que Bush n’avait pas résolue : « qui assure la maintenance ? »

Nature de ce document

  • Ce document est volontairement abstrait — l’objectif est de transmettre l’idée elle-même, pas une implémentation particulière
  • Les détails comme la structure des répertoires, les conventions du schéma, les formats de page ou les outils varient selon le domaine, les préférences et le LLM
  • Tous les composants sont optionnels et modulaires — on utilise ce dont on a besoin, et on ignore le reste
  • Il est recommandé de le partager avec un agent LLM puis de concrétiser ensemble une version adaptée à ses propres besoins

15 commentaires

 
xguru 2026-04-05

L’utilisation de ceci a donné Farzapedia : une Wikipedia personnelle créée à partir de 2 500 entrées de journal, notes et messages

  • En utilisant un LLM, 2 500 éléments issus d’un journal, d’Apple Notes et de conversations iMessage ont été fournis en entrée pour générer automatiquement 400 articles wiki détaillés
  • Le contenu inclut des amis, des startups, des domaines de recherche d’intérêt, des anime préférés et même leur influence, le tout interconnecté par des backlinks
  • Le wiki n’a pas été conçu pour une consultation personnelle, mais comme une base de connaissances destinée à être exploitée par des agents, avec une structure de fichiers et des backlinks faciles à crawler pour eux
  • Claude Code est relié au wiki et utilise index.md comme point d’entrée ; lors d’une requête, l’agent parcourt lui-même les pages nécessaires
  • Exemple d’usage : lors du travail sur une nouvelle landing page, si on demande « en t’appuyant sur les images et films qui m’ont récemment inspiré, donne-moi des idées de copy et de design », l’agent peut répondre en combinant un document « philosophie » fondé sur un documentaire Studio Ghibli, un document « concurrents » contenant des captures d’écran de landing pages d’entreprises YC, et même des images d’objets dérivés des Beatles des années 1970 mises de côté
  • Un système similaire basé sur le RAG avait été construit il y a un an, mais les performances n’étaient pas bonnes ; l’approche où l’agent explore directement le système de fichiers s’est révélée bien plus efficace
  • Lorsqu’un nouvel élément est ajouté (article, image d’inspiration, note de réunion, etc.), le système met automatiquement à jour 2 ou 3 documents existants liés ou crée un nouveau document

Les 4 avantages de la personnalisation basée sur un LLM Wiki selon Karpathy

  • Il cite la Farzapedia ci-dessus comme un bon exemple concret du tweet sur les LLM Wiki et résume en 4 points les avantages de cette approche par rapport aux méthodes classiques de personnalisation de l’IA, censées « s’améliorer toutes seules à mesure qu’on les utilise »
  • Explicite (Explicit) : le résultat de la mémoire existe clairement sous forme de wiki, et il est possible de vérifier et gérer directement ce que l’IA sait ou ne sait pas — la connaissance n’est pas enfouie dans un système opaque, elle existe sous une forme visible
  • Vos données (Yours) : les données sont stockées sur l’ordinateur local plutôt que dans le système d’un fournisseur d’IA donné, sans être enfermées dans un format impossible à extraire, ce qui permet de garder un contrôle total sur l’information
  • Le fichier avant l’app (File over app) : la mémoire est constituée d’une collection de fichiers dans des formats génériques comme le Markdown ou les images, compatibles avec divers outils et CLI — l’agent peut exploiter toute la boîte à outils Unix, et l’ensemble peut être consulté via l’interface de son choix, comme Obsidian
  • Liberté de choix de l’IA (BYOAI) : il est possible de connecter librement l’IA de son choix — Claude, Codex, OpenCode, etc. — et, en principe, même de fine-tuner une IA open source sur ce wiki afin de ne pas seulement référencer les données, mais d’intégrer directement les connaissances personnelles dans les poids du modèle
  • Cette méthode n’est pas la plus simple et nécessite de gérer des répertoires de fichiers, mais les agents peuvent aider sur une grande partie de ce processus
  • Il insiste sur le fait que « la maîtrise des agents (agent proficiency) est une compétence clé du XXIe siècle » et recommande d’essayer soi-même ces outils capables d’exécuter des tâches sur ordinateur à partir d’instructions en anglais
 
dkmin 2026-04-05

Merci pour le partage. Je l’ai testé, et c’est impressionnant.
On peut s’attendre à ce que la communauté propose encore des méthodes plus abouties.

 
kurthong 2026-04-06

Je l’ai aussi implémenté. J’ai ajouté quelques éléments pour pouvoir relier le vault Obsidian à une sauvegarde GitHub lorsqu’on utilise plusieurs matériels. J’ai aussi créé et intégré des parseurs pour Codex et Gemini. https://github.com/hang-in/seCall

 
kuthia 2026-04-08

C'est soigné.

 
trpgfox 2026-04-07

Waouh, même en lisant le corps de l’article, j’étais perdu, mais en consultant ce dépôt Git, je commence à voir la voie. Merci beaucoup.

 
kurthong 2026-04-06

Comme bm25 est peu performant pour la recherche en coréen, j’ai également mis en place un garde-fou capable de bien rechercher en coréen séparément.

 
GN⁺ 2026-04-05
Avis Hacker News
  • Cette approche semble mener au final à un model collapse
    D’après cet article de Nature, plus les LLM rédigent des documents, plus ils réécrivent l’information exacte existante de façon moins concise, avec une dégradation cumulative de la qualité
    Je suis surpris que Karpathy ne voie pas le problème. J’ai l’impression que les extrémistes de l’IA ont perdu une forme de « bon sens »
    Quand on a davantage envie de mettre en avant une « sauce secrète que j’ai écrite moi-même » que le résultat produit par un LLM, il faut se demander pourquoi

    • Cet article ne parle pas d’entraîner un LLM, mais d’utiliser un modèle déjà entraîné (ChatGPT ou Claude, par exemple) pour rédiger un wiki personnel
    • Le commentaire de Karpathy a disparu après avoir été signalé, mais c’était essentiellement un long paragraphe moqueur écrit par Claude et collé tel quel
      Sa manière de réagir est décevante. Ça me rappelle l’idée que « si on ne peut pas parler de façon humaine, mieux vaut ne rien dire »
      On dirait que beaucoup de gens très intelligents voient un « fantôme dans la machine » et perdent leur sensibilité humaine
      L’article d’Ezra Klein, « I Saw Something New in San Francisco », décrit bien ce phénomène
    • J’ai fait une expérience pour créer un fichier HTML auto-mis à jour, et avec des prompts simples comme dans ce dépôt, ça fonctionnait étonnamment bien sans boucle
    • D’après mon expérience, un LLM n’arrive déjà pas à maintenir correctement un simple claude.md. Alors un wiki entier, c’est encore moins envisageable
  • Je construis quelque chose de similaire avec une approche centrée sur la gestion
    J’associe la mémoire de tout l’espace de travail à des tâches ou des projets, avec un contrôle en temps réel via une interface SPA
    On peut voir le projet hmem
    J’ai essayé de faire passer le modèle en mode recherche pour qu’il organise ses connaissances internes, mais au final c’est devenu confus, comme une soupe de LLM
    Sur les projets de code, ce qui a le mieux marché, c’était des exigences claires, des améliorations itératives et du code bien documenté. Quand la mémoire devient trop volumineuse, les erreurs augmentent au contraire

  • Au fond, ça ressemble surtout à une manière de repousser le problème
    Pour maintenir le wiki, le LLM doit relire le wiki à chaque fois au lieu des sources originales, et des erreurs de second ordre s’accumulent dans le processus
    À terme, dès qu’on aura des modèles de nouvelle génération avec 10M de contexte ou 1000 tps, ce genre d’approche risque de devenir inutile

    • Il existe déjà des modèles avec 1M de contexte, mais la perte de mémoire commence vers 200k–300k tokens. Même avec 10M de contexte, la limite fondamentale restera la même
    • J’ai moi-même construit un système basé sur Obsidian avec une couche de schéma structurée par-dessus
      Cette couche intermédiaire est très utile pour capturer l’intention de conception et repérer l’écart avec l’implémentation réelle
      Je pense qu’un système totalement autonome et auto-référentiel n’a pas de valeur. La vraie valeur est dans une structure où l’humain peut intervenir en disant « ça doit fonctionner comme ceci »
      Au final, ces expériences sont intéressantes, mais sans réelle utilité pratique. Les fournisseurs de grands modèles progressent tellement vite qu’à ce stade, il vaut mieux utiliser quelque chose de simple et basique
    • L’argument « la prochaine génération de modèles résoudra tout » est peut-être vrai, mais si on y croit trop, on finit par ne plus rien construire du tout
    • L’objectif n’est pas de conserver tout le contexte, mais de créer une mémoire interrogeable. Une sorte de data lake pour les idées
    • Pour l’instant, ça sert à résumer quelques articles intéressants, mais à l’avenir cela pourrait devenir un outil de condensation des connaissances capable de compresser tout un domaine en quelques textes
  • Cette idée rappelle l’essai de 1960 de Licklider, « Man-Computer Symbiosis »
    On y retrouve le concept d’amplification de l’intelligence : l’humain fixe les objectifs, l’ordinateur transforme les hypothèses en modèles pour les vérifier et prend en charge les calculs itératifs
    Voir le texte original

    • Il avait déjà anticipé le concept d’écran collaboratif. Il imaginait une interaction où l’ordinateur reconnaît un graphe dessiné à la main par une personne et l’affiche immédiatement sous une forme raffinée
  • Une liste de systèmes mettant en œuvre des idées proches se trouve ici
    J’utilise une base de connaissances pilotée par LLM appelée commonplace
    Le système est conçu pour que le LLM puisse lire et exécuter la théorie elle-même, de sorte que la théorie devienne le runtime
    C’est encore brut, mais pour moi ça fonctionne bien

  • J’ai créé un outil similaire, mais dédié aux bases de code
    llmdoc détecte les changements de fichiers par hash et les met en cache sous forme de résumés produits par un LLM, un actif unique décrivant chaque fichier
    C’est accessible en CLI et ça améliore fortement la vitesse d’exploration du code

  • C’est en pratique une architecture RAG
    Il n’y a pas de base vectorielle, mais le principe est similaire : on crée un index de liens sémantiques et une structure hiérarchique pour faciliter la recherche
    Je développe le projet atomic, une base de connaissances IA qui applique des idées proches de la synthèse de wiki

    • Le RAG ne nécessite pas forcément des embeddings. Une simple recherche grep peut suffire
    • Pour une base de connaissances personnelle, la combinaison Multimodal KB + Agentic RAG me paraît adaptée
      Par exemple, DocMason extrait les diagrammes de fichiers PPT ou Excel pour que des agents comme Codex puissent les analyser
    • Ce n’est pas juste « du RAG ». Ici, le LLM rédige et maintient directement le wiki, crée les backlinks et vérifie les incohérences
      On est plus proche de la synthèse de connaissances que de la recherche. C’est un peu comme si le LLM gérait lui-même son Zettelkasten
      Le projet est intéressant, je vais clairement y jeter un œil
    • Ça aurait peut-être été bien de commencer par dire « j’ai quelques interrogations » à propos de ce type d’application
      Je réfléchis moi aussi depuis longtemps au concept de LLM-WIKI, mais l’OP semble être allé beaucoup plus loin. J’espère vraiment que ça deviendra un vrai second cerveau
    • En réalité, c’est assez proche du fichier de custom instructions de Copilot
      Comme dans la documentation copilot-instructions.md, il s’agit d’une structure qui contient des consignes auxquelles le LLM peut se référer
  • J’ai tenté quelque chose de similaire sur un projet en entreprise
    Comme j’étais moins concentré à cause d’un burn-out et d’une situation d’aidance familiale, j’ai délégué une grande partie du travail à des workflows multi-agents
    Tout tourne autour d’un wiki Markdown basé sur Obsidian, mais au final ça crée une nouvelle forme de dette technique — comme si une partie de mon cerveau était vide
    Malgré tout, ce workflow de wiki est tellement addictif qu’il est difficile d’arrêter

    • J’ai moi aussi peur de perdre la capacité à réfléchir en profondeur
    • Tu ne fais pas forcément mal les choses. C’est juste qu’au-delà d’un certain niveau de complexité, les agents n’arrivent plus à maintenir le wiki, et les développeurs non plus n’arrivent plus à comprendre l’ensemble
    • La vraie valeur de la documentation n’est pas le résultat final, mais la clarification de la pensée pendant le processus d’écriture
      Même si un LLM produit un excellent résultat, dans un wiki personnel, le processus compte davantage
    • Pour retrouver du temps de réflexion, je recommande d’avoir un hobby hors ligne
      Moi, je vais marcher sans téléphone ou je nage pour faire le vide. La fatigue physique et la fatigue mentale sont de nature différente, et ça aide
  • Je suis content de voir ce type d’approche gagner en attention
    Mais dès qu’on mélange des documents avec des données structurées (éléments de travail, ADR, etc.), le Markdown seul devient difficile à interroger
    L’approche AGENTS.md contourne cela en apprenant au LLM les conventions de dossiers, mais quand les données deviennent complexes, on atteint vite ses limites
    C’est pourquoi je développe Binder
    Les données sont stockées dans une base structurée, puis rendues sous forme de Markdown synchronisé dans les deux sens
    Un LSP fournit l’autocomplétion et la validation, et les agents ou scripts accèdent aux mêmes données via CLI ou MCP

  • J’ai créé AS Notes pour VS Code
    On peut voir ça sur asnotes.io
    L’idée est d’intégrer les fonctions d’un système de gestion des connaissances personnelles dans VS Code, afin de pouvoir écrire, relier et mettre à jour facilement du Markdown et des wikilinks
    Il y a aussi le rendu de mermaid et de LaTeX
    De cette manière, on peut préserver durablement en Markdown les résultats des conversations avec l’IA, et j’ai l’impression d’en tirer bien plus de valeur qu’avec un simple Copilot

 
stadia 2026-04-05

Après avoir simplement initialisé le vault de base, lui avoir fait lire ce seul fichier et expliqué que je voulais concrétiser cette idée, j’ai défini l’ossature générale avec la compétence de brainstorming de superpowers, puis j’ai même terminé la configuration de CLAUDE.md et du plugin Obsidian.

 
sudoeng 2026-04-06

L’idée même de l’utiliser comme une sorte de dépôt de connaissances personnel me paraît aussi intéressante.
En revanche, je ne sais pas encore vraiment si l’IA pourra gérer un contexte de wiki qui s’accumule de plus en plus.

 
kurthong 2026-04-06

Dans les grandes lignes, il s’agit de rechercher les conversations passées, donc si l’on organise bien les questions de structuration, cela me semble être une bonne idée. En pratique, j’ai aussi trouvé que cela m’avait beaucoup aidé pour organiser mes projets.

 
huturufu 2026-04-05

Ce que je voulais implémenter dans openclaw est sorti. Je vais le récupérer et l’utiliser.

 
junghan0611 2026-04-06

Enfin, on en arrive à ce sujet. Je cultive depuis longtemps un jardin autour de ce thème et je construis des harnais, donc c’est une nouvelle qui me réjouit beaucoup. Le savoir-faire du professeur Karpathy est intéressant. Pour le PKM lui-même, plus que la difficulté technique, il me semble que l’essentiel est la manière dont chacun accumule et structure cela sur le long terme, puis le partage avec une intelligence étrangère, afin que l’humain oriente peu à peu un modèle de coévolution mutuelle. En d’autres termes, la question nous revient-elle à nouveau, à nous les humains ? Les humains sont-ils prêts à être avec nous ? Il n’y a pas vraiment de bonne réponse, et chacun devra l’accumuler à partir de ses propres questions. J’ai hâte de voir la suite. Merci à GeekNews pour cette actualité.

 
calvinsnax 2026-04-06

Il ne faut pas avoir de préjugés, mais... quand je vois ce genre de commentaires, ça me fait un drôle d’effet.

 
passerby 2026-04-06

Pourquoi commentez-vous avec un bot ?

 
hmmhmmhm 2026-04-07

C'est un bot ? Une intelligence extraterrestre (???)