La Révolution du "LLM Wiki" : Comment transformer l'IA en cerveau qui apprend vraiment

📋 Overview

• Type : Tutoriel / Lecture pratique (LECTURE/TUTORIAL)
• Sujet principal : Comment construire un "LLM Wiki" — une base de connaissances persistante que l'IA lit, structure et enrichit au fil du temps, contrairement aux approches classiques (RAG) qui repartent de zéro à chaque question.
• Intervenant : Jamie, de la chaîne Teachers Tech (présentateur unique, format tutoriel). Concept crédité à Andrej Karpathy (co-fondateur d'OpenAI, ancien directeur IA chez Tesla).

🎯 Core Purpose & Context

• Résoudre un problème structurel dans l'usage courant de l'IA : l'absence de mémoire cumulative. Chaque question sur des documents recommence à zéro (recherche, extraction, réponse), sans rien construire.
• Objectif du tutoriel : présenter le concept du LLM Wiki de Karpathy, expliquer pourquoi il est supérieur, et construire un exemple concret pas à pas (planification d'un voyage au Japon) accessible aux non-techniciens.

---

🧠 Key Concepts & Steps

Concepts fondamentaux

Le problème du RAG (Retrieval Augmented Generation)

• [00:01:21] Vous téléchargez des fichiers, posez une question, l'IA cherche, extrait des "chunks" pertinents et génère une réponse.
• Fonctionne pour les questions simples, mais aucune mémoire, aucune accumulation, rien ne se compose (compounds).
• Analogie du chercheur : avec le RAG, c'est comme si l'IA n'avait jamais lu vos articles — elle repart à neuf à chaque fois.

La solution de Karpathy : le LLM Wiki

• [00:02:44] L'IA lit vos documents une seule fois, en extrait les idées clés et les intègre dans un Wiki structuré (fichiers markdown interconnectés).
• À chaque nouvelle source : elle met à jour les pages existantes, crée de nouvelles pages, relie les idées, et signale les contradictions.
• La synthèse et les connexions sont déjà faites avant même que vous ne posiez une question.

La métaphore de Karpathy :

"Think of Obsidian as the IDE, the LLM as the programmer and the Wiki as the codebase." (Pensez à Obsidian comme l'IDE, au LLM comme le programmeur, et au Wiki comme la base de code.) Vous écrivez rarement le Wiki vous-même — l'IA le rédige et l'organise. Vous décidez quoi y mettre et quelles questions poser.

Les 3 couches du système

1. Couche 1 — Sources brutes (raw) : documents originaux (PDF, articles, notes). En lecture seule — l'IA les lit mais ne les modifie jamais. C'est la "source de vérité".
2. Couche 2 — Le Wiki : dossier de fichiers markdown créés/maintenus par l'IA (page d'index, pages de concepts, pages d'entités, comparaisons, tout interconnecté).
3. Couche 3 — Le Schéma : document de règles indiquant à l'IA comment structurer le Wiki. Avec Claude Code, c'est le fichier claude.md.

Figure 1 — Les trois couches du système LLM Wiki : des sources brutes immuables jusqu'au schéma de règles qui gouverne tout l'édifice.

📝 Guide pas à pas (Step-by-Step)

1. Installation d'Obsidian [00:04:55]

• Application gratuite de prise de notes en markdown, servant de visualiseur. Téléchargeable sur obsidian.md.
• Choisie pour sa vue en graphe (graph view) qui rend les connexions visuelles. Alternative : VS Code ou tout éditeur de texte.

2. Choix de l'agent IA [00:04:55]

• Jamie utilise Claude Code. Alternatives : OpenAI Codex, Cursor, ou tout outil capable de lire/écrire des fichiers.

3. Créer un Vault [00:05:43]

• Créer un nouveau "vault" (= dossier) nommé "LLM Wiki", sauvegardé dans Documents.

4. Structure des dossiers [00:06:55]

• raw : l'IA y lit mais ne modifie jamais.
• wiki : où l'IA construit et maintient toutes ses pages.
• templates (optionnel) : pour des formats de notes cohérents si créés manuellement. Inutile ici car Claude génère tout.

5. Créer le fichier schéma claude.md [00:07:44] — À placer à la racine du vault. Contenu :

• Purpose : le sujet du Wiki (ici : "planning a trip to Japan"). C'est la seule ligne à personnaliser pour démarrer.
• Folder structure : où sont les sources brutes, où va le Wiki.
• Ingest workflow : lire le document → extraire les concepts clés → créer/mettre à jour les pages → mettre à jour l'index → journaliser les changements.
• Page formatting rules : résumé en haut de chaque page, chaque affirmation référence sa source, liens vers les concepts liés.
• Question answering behavior : consulter le Wiki d'abord, citer les sources, signaler l'incertitude.

6. Installer le Web Clipper [00:10:29]

• Extension Chrome gratuite d'Obsidian qui convertit les articles web en fichiers markdown.

7. Ingérer la première source [00:11:23]

• Déposer un article (blog de voyage sur Tokyo) dans raw. Les PDF/textes fonctionnent aussi nativement.
• Pointer le répertoire de Claude Code vers le dossier configuré, puis lancer : "I just added a new source to the raw folder, please read it and update the Wiki."
• Résultat en ~3 minutes : pages structurées + connexions visibles dans la vue graphe.

8. Ajouter une deuxième source [00:10:00 / demo]

• Guide gastronomique du Japon. Claude ne crée pas seulement de nouvelles pages — il met à jour les pages de quartiers existantes. Le graphe gagne en nœuds et connexions.

9. Poser une question croisée

• Exemple : "Quel quartier choisir pour être proche de la meilleure nourriture et des grands temples ?"
• Claude ne cherche pas dans les articles bruts : il puise dans les pages Wiki (quartiers, nourriture, temples), connecte les points issus de sources différentes et cite les pages spécifiques.

10. "Linter" le Wiki [00:13:33]

• Comme un linter de code, demander : "Please lint the wiki."
• L'IA détecte : contradictions entre pages, affirmations obsolètes, pages orphelines (sans liens entrants), concepts mentionnés sans page dédiée.
• Le rapport signale les liens brisés et propose de corriger les problèmes de citation.

Figure 2 — RAG vs LLM Wiki : là où le RAG repart à zéro à chaque requête, le Wiki compose et accumule la valeur au fil du temps.

Figure 3 — La composition de valeur : chaque source ingérée renforce l'ensemble du réseau, créant des insights qu'aucun document isolé ne pouvait révéler.

Distinctions importantes : RAG vs LLM Wiki

RAG classique	LLM Wiki
Recherche à chaque question	Base pré-construite et persistante
Aucune mémoire / accumulation	La connaissance se compose dans le temps
Reconstruit les liens à chaque fois	Connexions et synthèse déjà faites
Documents bruts	Pages markdown structurées et interconnectées

---

🧭 Strategic Analysis & "Game Changers"

• Connexion cachée : Ce système transforme fondamentalement le rôle humain. Vous passez de "poseur de questions" à curateur/architecte de connaissances. La valeur ne réside plus dans les réponses ponctuelles, mais dans l'actif cumulatif que vous construisez — un actif que vous possédez.

• Le "So What?" : L'avantage réel n'est pas la commodité, c'est la composition de valeur (compounding). Comme les intérêts composés, chaque source ajoutée enrichit tout l'édifice. Après 100 articles, vous ne possédez pas 100 réponses — vous possédez un réseau de connaissances synthétisé qui rend visibles des insights qu'aucune source seule ne contenait.

• Souveraineté des données : Contrairement aux solutions cloud propriétaires, vos données restent sur votre machine, en texte brut que vous possédez. Aucun verrouillage propriétaire (vendor lock-in).

• Game Changer : Le concept que "la synthèse est faite à l'avance, pas au moment de la question". C'est une inversion de paradigme : au lieu de payer un coût cognitif/computationnel à chaque requête, vous l'investissez une fois lors de l'ingestion, et vous en récoltez les bénéfices indéfiniment. La détection de contradictions entre sources (le "flag") est particulièrement puissante pour la recherche rigoureuse.

📊 Detailed Breakdown

• [00:00:00] Introduction du problème : l'IA recommence tout à zéro à chaque question.
• [00:00:30] Présentation de Karpathy et de son idée du "LLM Wiki".
• [00:01:21] Explication du RAG et de sa limite fondamentale : pas de mémoire.
• [00:01:54] Analogie du chercheur ; introduction de la solution (lire une fois, construire un Wiki).
• [00:02:44] Fonctionnement de l'ingestion : mise à jour, création de pages, liens, détection de contradictions.
• [00:03:22] La métaphore Obsidian=IDE / LLM=programmeur / Wiki=codebase. Description de la Couche 1 (sources brutes en lecture seule).
• [00:04:10] Description des Couches 2 (Wiki markdown) et 3 (schéma claude.md).
• [00:04:55] Prérequis : Obsidian + agent IA (Claude Code).
• [00:05:43] Création du vault "LLM Wiki".
• [00:06:55] Création des dossiers raw, wiki, templates.
• [00:07:44] Création et explication du fichier schéma claude.md.
• [00:08:44–00:10:29] Détail des 5 sections du schéma (Purpose, Folder structure, Ingest workflow, Page formatting, Q&A behavior). Ajout du Web Clipper.
• [00:11:23] Ingestion de la première source (blog Tokyo), configuration du répertoire.
• [00:13:33+] Résultat visuel dans Obsidian, vue en graphe. Ajout de la 2e source (guide gastronomique) et mise à jour des pages.
• [démo] Question croisée démontrant la connexion multi-sources et les citations.
• [00:13:33] Fonction "lint" : rapport de santé du Wiki (orphelins, liens brisés, lacunes).
• [00:14:16] Cas d'usage : étudiants/chercheurs, enseignants, entreprises (onboarding), lecteurs curieux.
• [00:15:27] Limitations honnêtes du système.
• [00:16:50] Conclusion et ressources (template du schéma, guide débutant Claude Code).

Figure 4 — Les cinq enseignements essentiels du LLM Wiki, de la limite du RAG à la pratique du linting pour maintenir la qualité de la base de connaissances.

🔑 Key Takeaways

1. Le RAG est un plafond : il ne construit rien, chaque requête repart de zéro. Le LLM Wiki construit un actif persistant.
2. L'IA rédige, vous curatez : votre rôle est de décider quoi ingérer et quoi demander — pas d'écrire le Wiki.
3. Architecture en 3 couches simple : sources brutes (lecture seule) → Wiki markdown → schéma de règles.
4. Fonctionne mieux à échelle personnelle (~100 articles selon Karpathy) ; c'est gratuit, local, et vous possédez vos données.
5. Le "linting" maintient la santé du Wiki en détectant contradictions, pages orphelines et lacunes.

⚠️ Limitations reconnues

• Échelle personnelle : au-delà de milliers de pages, une infrastructure plus robuste est nécessaire.
• Garbage in, garbage out : la qualité dépend entièrement de la curation des sources.
• Nécessite un agent de code (Claude Code, Codex…) — Obsidian seul ne fait rien.
• L'IA peut se tromper : mauvaise catégorisation, connexions manquées → d'où l'utilité du linting, surtout au début.

❓ Unresolved Questions / Follow-up

• Comment le système se comporte-t-il concrètement au-delà de 100 articles ? Quelle infrastructure exacte serait requise ?
• Quel est le coût réel (tokens/API) d'ingestion et de maintenance à grande échelle ?
• Comment gérer les mises à jour de sources déjà ingérées qui deviennent obsolètes ?
• Fiabilité de la détection de contradictions : l'IA rate-t-elle des conflits subtils ?
• Comment versionner/sauvegarder le Wiki pour éviter les régressions lors des mises à jour par l'IA ?