Le problème avec le RAG classique
La plupart des systèmes RAG (Retrieval Augmented Generation) fonctionnent ainsi :
- Vous uploadez des documents
- Ils sont découpés en chunks et vectorisés
- À chaque question, le LLM récupère les chunks pertinents
- Il génère une réponse à partir de ces fragments
Le problème ? Le LLM redécouvre tout depuis zéro à chaque fois. Pas d'accumulation. Pas de synthèse progressive.
Demandez "Comment X se connecte à Y en tenant compte de Z ?" et le LLM doit :
- Retrouver les fragments pertinents dans 5 documents différents
- Reconstituer le contexte
- Faire les connexions
- Générer la réponse
Et la prochaine fois que vous posez une question similaire ? Il recommence tout.
La révélation de Karpathy : Le Wiki LLM
Andrej Karpathy (ex-directeur AI chez Tesla et OpenAI) a récemment partagé une approche différente :
"Au lieu de simplement récupérer depuis des documents bruts au moment de la requête, le LLM construit et maintient incrémentalement un wiki persistant — une collection structurée et interconnectée de fichiers markdown."
Le pipeline en 5 étapes
L'architecture complète ressemble à ça :
MAIN PIPELINE (de gauche à droite) :
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ SOURCES │─────▶│ raw/ │─────▶│ WIKI │─────▶│ Q&A Agent │─────▶│ OUTPUT │
│ │ index│ │ LLM │ │ query│ │render│ │
│ articles │ │ unprocessed │ │ .md KB │ │ complex Q │ │ markdown │
│ papers │ │ files │ │ summaries │ │ against │ │ slides │
│ repos │ │ stored as-is│ │ backlinks │ │ full wiki │ │ plots │
│ datasets │ │ local images│ │ concepts │ │ no RAG │ │ │
│ images │ │ │ │ auto-index │ │ needed │ │ │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
│ ▲
│ │ filed back
│ │ knowledge
│ │ compounds
└────┘
SUPPORT LAYER (outils connectés au wiki) :
- Logseq : IDE frontend pour visualiser raw + wiki, graphe de connaissance
- Lint + Heal : Détecte incohérences (liens cassés, pages orphelines) et propose des corrections (créer pages manquantes, réparer liens)
- CLI Tools : Primitives utilisées par Claude Code (grep, read, glob) + outils optionnels avancés (qmd pour recherche sémantique, Web UI, MCP servers - voir section dédiée plus loin)
Les trois couches
1. Raw Sources : Vos documents sources, jamais modifiés par l'IA. C'est votre source de vérité.
- Articles, papers, repos, datasets
- Images et diagrammes
- Notes de podcasts, vidéos
- Structure :
pages/,journals/,assets/
2. Le Wiki : L'IA possède entièrement cette couche (~100 articles / ~400K mots pour un wiki mature).
- Fichiers
.mdavec propriétés Logseq natives - Summaries avec backlinks
- Concept categories
- Auto-maintained index
- Structure :
wiki/[thème]/[page].md
3. Le Schema : Skills Claude Code qui définissent :
- Format des pages wiki (propriétés Logseq)
- Workflows (setup, ingest, update, query, lint)
- Primitives de lecture optimisées
- Gestion du manifest et du log
- Structure :
.claude/skills/logseq-*/SKILL.md
Pourquoi ça marche ?
La partie pénible d'une base de connaissance n'est pas la lecture ou la réflexion — c'est la maintenance.
- Mettre à jour les références croisées
- Garder les résumés à jour
- Noter quand de nouvelles données contredisent les anciennes
- Maintenir la cohérence sur des dizaines de pages
Les humains abandonnent les wikis parce que le coût de maintenance croît plus vite que la valeur.
Les LLM ne s'ennuient jamais. Ils peuvent lire et modifier 15 fichiers en une passe sans problème. Le wiki reste maintenu parce que le coût de maintenance est proche de zéro.
Pourquoi Logseq dans cet article ?
Le concept de Wiki LLM fonctionne avec n'importe quel outil de notes : Obsidian, Logseq, Notion, voire des fichiers markdown simples.
Cet article utilise Logseq simplement parce que c'est l'outil que j'utilise au quotidien. Le gist original de Karpathy utilise Obsidian, et il existe une excellente implémentation pour Obsidian (obsidian-wiki) dont on s'inspire ici.
L'important n'est pas l'outil, c'est le concept : un wiki markdown maintenu par un LLM qui s'enrichit au fil du temps.
Quelques particularités de Logseq utilisées dans cette implémentation :
-
Graphe de connaissance natif : chaque
[[lien]]crée automatiquement un backlink -
Références de blocs :
((block-id))pour traçabilité granulaire — et c'est plus qu'une question de style. La structure outliner de Logseq découpe chaque page en blocs hiérarchiques (parent/enfant). Le wiki peut ainsi citer un paragraphe précis d'une source plutôt qu'une page entière. Lors d'une requête, Claude n'a pas besoin de relire 50 lignes pour retrouver l'information : il grep l'identifiant de bloc, lit uniquement ce bloc et ses enfants directs. Résultat : un graphe de connaissance plus granulaire, des citations plus précises, et une consommation de tokens réduite à chaque interrogation. -
Propriétés :
title::,summary::,sources::(équivalent du frontmatter YAML) -
Journal quotidien : structure
journals/YYYY-MM-DD.mdpar défaut - Queries Datalog : vues dynamiques sur la connaissance
Visualisation du graphe de connaissance : le wiki au centre avec toutes les pages interconnectées
Mais vous pouvez adapter ce système à votre outil préféré en modifiant les skills Claude Code pour qu'ils utilisent la syntaxe de votre outil.
Architecture technique détaillée
Avant de plonger dans l'installation, comprenez l'architecture système. Le wiki repose sur 9 skills Claude Code orchestrés autour d'un manifest JSON et d'un log markdown.
Le système de tracking : manifest + log + hashing
wiki/_manifest.json — État du wiki
{
"version": 1,
"created_at": "2026-04-10T10:00:00Z",
"last_ingest": "2026-04-10T15:30:00Z",
"stats": {
"total_sources_ingested": 47,
"total_pages_created": 123
},
"sources": {
"pages/kubernetes.md": {
"ingested_at": "2026-04-10T15:30:00Z",
"content_hash": "a8f5f167f44f4964e6c998dee827110c284a0dd2",
"pages_created": ["wiki/kubris/kubernetes-3488"],
"pages_updated": ["wiki/kubris/_index"]
}
}
}
Le hash SHA-256 : Chaque source a un hash de son contenu. Lors d'un update, Claude recalcule le hash. Si identique → skip (pas de changement). Si différent → source modifiée, on réingère.
wiki/_log.md — Journal des opérations
## Log
- [2026-04-10T10:00:00Z] SETUP — initialisation du wiki, 5 thèmes détectés
- [2026-04-10T15:30:00Z] INGEST — 47 sources ingérées, 123 pages créées
- [2026-04-10T16:15:00Z] UPDATE — 3 sources modifiées, 8 pages mises à jour
- [2026-04-11T09:00:00Z] LINT — 2 liens cassés détectés, 1 page orpheline
- [2026-04-11T09:05:00Z] CROSS-LINK — 45 liens ajoutés
Append-only, parseable avec des outils Unix standard :
grep "^- \[" wiki/_log.md | tail -5 # Les 5 dernières opérations
Les 9 skills Claude Code
Les skills sont des fichiers SKILL.md dans .claude/skills/logseq-*/. Claude les invoque selon le contexte.
| Skill | Trigger | Fonction principale |
|---|---|---|
| logseq-llm-wiki | Fondation | Définit syntaxe Logseq (title::, [[liens]], ((block-refs))), format wiki, primitives optimisées (Grep avant Read), structure manifest + log |
| logseq-setup | "initialise mon wiki" | Détecte thèmes, crée structure wiki/ avec _master-index.md, _log.md, _manifest.json
|
| logseq-ingest | "ingère mon vault" | Inventorie sources, distille pages/journaux/assets en pages wiki, met à jour index/manifest/log. Modes append (skip si hash inchangé) ou full |
| logseq-update | "mets à jour" | Compare hash sources vs manifest, traite modifiées/nouvelles (merge intelligent), signale supprimées |
| logseq-query | Questions utilisateur | Grep sur wiki d'abord, puis pages/journaux si besoin, lecture ciblée, réponse avec citations [[]]
|
| logseq-status | "statut de mon wiki" | Dashboard : stats sources/wiki, delta (modifiées/nouvelles), suggestions d'actions |
| logseq-lint | "vérifie mon wiki" | Détecte liens cassés, pages orphelines, sources supprimées, propriétés manquantes, tâches NOW orphelines |
| logseq-rebuild | "rebuild" | Archive wiki/ vers _archive/DATE/, réinitialise manifest/log, propose re-ingest (confirmation obligatoire) |
| logseq-cross-linker | "tisse les liens" | Détecte mentions non linkées, ajoute [[]], vérifie bidirectionnalité, enrichit le graphe de connaissance |
Le Core Insight
"You never write the wiki. The LLM writes everything. You just steer — every answer compounds."
Vous ne touchez jamais wiki/ manuellement. Vous :
- Ajoutez des sources dans
pages/oujournals/ - Posez des questions
- Demandez des updates, des lints, des cross-links
Claude écrit, maintient, enrichit. Chaque réponse améliore le wiki. Compounding knowledge.
Cas d'usage réels
Voyons quelques scénarios concrets d'utilisation du système.
1. Recherche académique
Contexte : Doctorant en ML, lit 5-10 papers par semaine.
Structure Logseq :
pages/
papers-2026/
attention-is-all-you-need.md
llama-3-paper.md
...
journals/
2026-04-10.md # Notes de lecture quotidiennes
wiki/
ml/
transformers.md
attention-mechanism.md
positional-encoding.md
_master-index.md
Workflow :
- Lit un paper, prend des notes dans
journals/ - Fin de semaine :
Claude, mets à jour mon wiki - Claude extrait concepts, enrichit pages existantes
- Demande synthèse :
Quelle est l'évolution de l'attention de 2017 à 2024 ? - Claude génère une page de synthèse avec timeline
2. Self-improvement et journalisation
Contexte : Pratique la tenue d’un journal quotidien pour favoriser ton développement personnel.
Structure :
journals/
2024-01-01.md # 365 jours de journal
...
2024-12-31.md
wiki/
personal-growth/
productivity-patterns.md
decision-frameworks.md
learning-insights.md
Workflow :
- Journal quotidien dans Logseq (habitudes, réflexions, décisions)
- Tous les mois :
Claude, distille mes journaux du mois dernier - Claude identifie patterns récurrents, crée pages thématiques
- Fin d'année :
Quels sont mes 5 apprentissages majeurs ?
3. Veille technologique
Contexte : Développeur qui suit 20+ blogs tech.
Structure :
pages/
articles/
kubernetes-best-practices.md
rust-async-guide.md
...
wiki/
kubris/
kubernetes.md
helm.md
rust/
async-programming.md
Workflow :
- Clippe articles web vers Logseq (extension Logseq Web Clipper)
- Chaque semaine :
Claude, ingère les nouveaux articles - Demande connections :
Comment Rust async se compare à Go goroutines ? - Cross-link automatique entre concepts
4. Lecture de livres
Contexte : Lit des livres techniques chapitre par chapitre.
Structure :
pages/
books/
designing-data-intensive-applications.md # Notes par chapitre
journals/
2026-04-10.md # "Terminé chapitre 5 sur replication"
wiki/
databases/
replication.md
consistency.md
cap-theorem.md
Workflow :
- Notes de lecture dans
pages/books/ - À la fin de chaque partie :
Claude, distille les chapitres 1-5 - Claude crée pages de concepts avec citations précises
- Fin du livre :
Génère un graphe des concepts du livre
Inspiration : le projet Obsidian Wiki
Le projet obsidian-wiki d'Ar9av est une excellente implémentation du concept Wiki LLM pour Obsidian. Cette approche Logseq s'en inspire largement en adaptant :
- La structure des skills : même logique (setup, ingest, update, query, lint)
- Le système de tracking : manifest JSON + log markdown
- Les primitives optimisées : Grep avant Read pour minimiser les tokens
- La philosophie : le LLM écrit tout, vous ne faites que guider
La principale différence est l'adaptation à la syntaxe et aux fonctionnalités natives de Logseq (propriétés :: au lieu de YAML frontmatter, block-refs ((id)), queries Datalog, etc.).
Si vous utilisez Obsidian, je vous recommande fortement le projet obsidian-wiki original. Si vous utilisez Logseq, suivez cette approche. Le concept reste le même : un wiki markdown enrichi et maintenu par un LLM.
Métriques de succès
Comment savoir si votre wiki fonctionne ?
Quantitatif
| Métrique | Mauvais | Moyen | Bon | Excellent |
|---|---|---|---|---|
| Densité de liens | < 1 | 1-2 | 2-4 | > 4 |
| Taux d'orphelins | > 20% | 10-20% | 5-10% | < 5% |
| Sources par concept | < 1.5 | 1.5-2.5 | 2.5-4 | > 4 |
| Temps de réponse* | > 5min | 2-5min | 30s-2min | < 30s |
| Taux de contradiction | > 10% | 5-10% | 2-5% | < 2% |
* Pour une question typique nécessitant ≥3 sources
Qualitatif
- Serendipité : Découvrez-vous des connexions inattendues en naviguant ?
- Confiance : Faites-vous confiance aux réponses du wiki ?
- Accumulation : Sentez-vous que votre connaissance s'accumule ?
- Maintenance : Le wiki reste-t-il cohérent sans effort manuel ?
Conclusion
Le pattern "Wiki LLM" de Karpathy transforme le RAG passif en base de connaissance vivante :
- Accumulation : Chaque source enrichit définitivement le wiki
- Synthèse : Les connexions sont compilées, pas redécouvertes
- Maintenance zéro : L'IA fait le bookkeeping pénible
- Compounding : La valeur croît exponentiellement
Avec Logseq et Claude Code, vous avez un système qui devient un second cerveau — non seulement il stocke l'information, mais il la structure, la connecte, la synthétise, et évolue avec vous.
"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
— Andrej Karpathy
Ou dans notre cas :
"Logseq est l'IDE ; Claude est le programmeur ; votre connaissance est le codebase."
Prêt à passer à l'action ? Consultez l'article suivant : Guide pratique : Implémenter votre Wiki LLM avec Logseq et Claude Code qui paraitra la semaine prochaine ;).
Top comments (0)