Le RAG Obsidian de Karpathy a Tué Ma Base de Données Vectorielle

Le RAG Obsidian de Karpathy a Tué Ma Base de Données Vectorielle

J'étais en plein milieu d'un pipeline RAG traditionnel quand Andrej Karpathy a posté quelque chose sur X qui m'a fait remettre en question chaque décision architecturale des six derniers mois.

Pas de base de données vectorielle. Pas d'embeddings. Pas de stratégie de chunking. Pas de seuils de similarité à régler. Juste des fichiers markdown, une structure de dossiers, et un LLM qui agit à la fois comme bibliothécaire et auteur.

Ma première réaction a été le scepticisme. J'ai construit des systèmes RAG. J'ai debuggé des échecs de retrieval, lutté avec les paramètres de chunk overlap, et regardé des documents parfaitement pertinents se faire enterrer par des scores de similarité cosinus qui n'avaient aucun sens. L'idée que vous pouviez sauter toute cette infrastructure et obtenir de meilleurs résultats pour une base de connaissances personnelle ressemblait à quelqu'un disant que vous pouviez dépasser une voiture en marchant — dans la bonne direction.

Puis je l'ai construit. Et la métaphore de marcher dans la bonne direction s'est avérée inconfortablement juste.

Le système de Karpathy — qu'il appelle "LLM Knowledge Bases" — fonctionne parce qu'il exploite quelque chose que la plupart des architectes RAG négligent : pour des datasets de moins d'environ 400 000 mots (à peu près 100 articles substantiels), une structure markdown bien organisée avec des résumés et des fichiers d'index donne au LLM plus de contexte utile que la recherche vectorielle ne pourrait jamais. Le modèle ne récupère pas des fragments. Il navigue dans un graphe de connaissances qu'il a lui-même construit, suivant des liens qu'il a lui-même créés, lisant des résumés qu'il a lui-même écrits.

Cette distinction — le LLM comme auteur de la structure de connaissances, pas seulement un consommateur de chunks récupérés — change tout dans la façon dont le système performe. Et c'est la partie que la plupart des couvertures de l'approche de Karpathy enterrent sous le titre.

Pourquoi le RAG Traditionnel Échoue à l'Échelle à Laquelle la Plupart des Gens Travaillent Réellement

Voici quelque chose que personne dans l'écosystème RAG ne veut admettre : pour 90% des développeurs individuels et petites équipes, le RAG traditionnel est une surenchère qui dégrade activement les résultats.

Je ne parle pas de recherche entreprise à travers des millions de documents. C'est un problème différent avec des contraintes différentes. Je parle du développeur qui a 50-200 articles favoris, une poignée de papers de recherche, de la documentation de repos, et une pile croissante de notes sur lesquelles il veut qu'un LLM raisonne.

Pour ce cas d'usage — qui décrit la plupart d'entre nous — le pipeline RAG traditionnel introduit trois problèmes que les systèmes markdown-first n'ont tout simplement pas.

Le problème du chunking. Chaque système RAG découpe les documents en chunks. La taille du chunk est un compromis : trop petit et vous perdez du contexte, trop grand et vous gaspillez des tokens sur du texte non pertinent. Il n'y a pas de taille de chunk universellement correcte, et le mauvais choix dégrade silencieusement chaque requête. J'ai passé des après-midi entiers à ajuster les pourcentages d'overlap de chunks, et la vérité honnête est que ça ressemblait toujours à une négociation avec le système plutôt qu'à une configuration.

Le problème du bruit de retrieval. La recherche par similarité vectorielle retourne les chunks mathématiquement les plus similaires, pas les plus utiles. J'ai eu des requêtes où les top-5 chunks récupérés venaient tous de la même section du même document — cinq paragraphes légèrement différents disant presque la même chose — tandis que l'insight réellement pertinent d'un autre document se trouvait en position 47 des résultats. Pertinence et similarité ne sont pas la même chose, et la recherche vectorielle optimise pour la mauvaise.

Le problème de la boîte noire. Avec une base de données vectorielle, on ne peut pas facilement voir ce qu'il y a dedans. On ne peut pas parcourir sa base de connaissances comme on parcourt un dossier. On ne peut pas vérifier manuellement si un document a été correctement indexé. On ne peut pas repérer les lacunes dans la couverture en scannant une liste. Les données disparaissent dans des embeddings, et on n'interagit avec elles qu'à travers des requêtes qui peuvent ou non faire remonter ce dont on a besoin.

Le système de Karpathy contourne les trois. Pas de chunking — le LLM lit des résumés structurés et suit des liens vers des documents complets si nécessaire. Pas de similarité vectorielle — le LLM navigue dans un index qu'il a construit et comprend. Pas de boîte noire — chaque morceau de connaissance vit dans un fichier markdown lisible qu'on peut ouvrir dans n'importe quel éditeur de texte.

Le trade-off ? Ça ne passe pas à l'échelle pour des millions de documents. Mais si votre base de connaissances se mesure en centaines d'articles plutôt qu'en millions, ce trade-off est l'une des meilleures affaires en IA en ce moment.

Comment la Base de Connaissances LLM de Karpathy Fonctionne Réellement

Le 3 avril 2026, Karpathy a publié un GitHub gist appelé llm-wiki qui expose l'architecture complète. Le système a trois couches, et comprendre comment elles interagissent est la clé pour le faire fonctionner.

Couche 1 : Le Coffre-Fort Raw

Tout commence dans un dossier raw/ à l'intérieur d'un vault Obsidian. C'est la zone de staging — un dépôt pour tout ce que vous voulez que le LLM finisse par connaître. Articles découpés du web. Papers de recherche PDF. Documentation de dépôts. Captures d'écran. Extraits de code. Transcriptions de podcasts.

Le dossier raw a une règle : rien dedans n'a besoin d'être organisé. Vous y jetez des choses, et le LLM les organise plus tard. C'est plus important qu'il n'y paraît. La plupart des systèmes de gestion des connaissances échouent parce que la friction d'ingestion est trop élevée — vous devez taguer des choses, catégoriser des choses, ranger des choses au bon endroit. Avec l'approche de Karpathy, l'ingestion est aussi simple que glisser un fichier dans un dossier.

Pour les articles web, Karpathy utilise l'Obsidian Web Clipper — une extension Chrome qui convertit n'importe quelle page web en fichier markdown et le dépose directement dans votre dossier raw. Un clic. L'article est dans votre système, images comprises.

En parlant d'images : Obsidian ne gère pas automatiquement les images inline des pages web découpées. Vous avez besoin du plugin communautaire "Local Images Plus", qui télécharge les images distantes et les stocke localement dans le vault. Sans ce plugin, vos articles découpés auront des liens d'images cassés une fois hors ligne — et le LLM ne pourra pas référencer du contenu visuel via ses capacités de vision.

Couche 2 : Le Wiki Compilé

C'est là que le système de Karpathy diverge de toute autre approche de gestion des connaissances que j'ai vue.

Au lieu d'indexer les documents raw pour le retrieval, le LLM les lit et écrit de nouveaux documents. Il compile le matériau brut en un wiki structuré — des articles style encyclopédie sur les concepts fondamentaux, des résumés de documents sources, et des backlinks explicites entre idées liées.

Le wiki vit dans un dossier wiki/, parallèle à raw/. À l'intérieur, vous trouverez :

• Un index maître (index.md) — un seul fichier markdown listant chaque wiki créé, avec de brèves descriptions et des liens. C'est le point de départ du LLM pour toute requête. Il lit l'index maître, identifie quel wiki est pertinent, puis navigue vers l'index propre et les articles de ce wiki.

• Des dossiers de sous-wiki — chaque sujet obtient son propre dossier avec son propre index.md et un ensemble d'articles compilés. Un wiki sur les "architectures transformer" pourrait contenir des articles sur les mécanismes d'attention, l'encodage positionnel et les lois de mise à l'échelle, tous interconnectés.

• Des backlinks et références croisées — le LLM crée des [[liens style wiki]] entre concepts liés à travers différents wikis. Ceux-ci ne sont pas décoratifs. Ils forment la structure de navigation que le LLM utilise pour répondre aux requêtes couvrant plusieurs sujets.

L'étape de compilation est où le LLM prouve sa valeur. Il ne copie pas du texte de documents raw vers des articles wiki. Il synthétise — identifiant les concepts fondamentaux, écrivant des explications claires, notant les contradictions entre sources, et construisant un réseau de connexions qu'aucune base de données vectorielle ne pourrait répliquer.

Voici à quoi ressemble un prompt de compilation en pratique. Vous dirigez votre agent LLM (Karpathy utilise Claude Code) vers le dossier raw et dites quelque chose comme :

Lis les fichiers dans raw/ qui concernent [sujet].
Crée un nouveau wiki dans wiki/[nom-du-sujet]/ avec :
1. Un index.md listant tous les articles de ce wiki
2. Des articles individuels pour chaque concept majeur
3. Des backlinks vers des wikis liés si pertinent
4. Mets à jour le master wiki/index.md pour inclure ce nouveau wiki

Le LLM fait la recherche, écrit les articles, construit les liens et met à jour les index. Vous vérifiez le résultat dans l'interface d'Obsidian — propre, navigable, lisible par un humain.

Couche 3 : L'Interface de Requête

Quand vous posez une question au LLM sur votre base de connaissances, il ne cherche pas dans les documents raw. Il suit un chemin structuré :

1. Lit le master wiki/index.md pour identifier les wikis pertinents
2. Ouvre l'index.md du wiki pertinent pour trouver des articles spécifiques
3. Lit ces articles (qui contiennent du savoir synthétisé plus des références sources)
4. Suit les backlinks vers des concepts liés si la question couvre plusieurs sujets
5. Retourne une réponse ancrée dans le wiki compilé, citant des articles spécifiques

C'est plus proche de la façon dont un chercheur humain travaille que tout ce que la recherche vectorielle offre. Un chercheur ne scanne pas chaque document d'une bibliothèque pour des correspondances de mots-clés. Il vérifie l'index, trouve la bonne section, lit les articles pertinents et suit les références vers du matériel connexe.

La différence de performance est réelle. Pour le dataset de Karpathy d'environ 100 articles et 400 000 mots, l'approche de navigation wiki a donné des réponses plus cohérentes et mieux sourcées qu'un pipeline RAG traditionnel — parce que le LLM raisonnait sur des connaissances structurées qu'il avait déjà synthétisées, plutôt que d'essayer de donner du sens à des chunks récupérés en temps réel.

Mise en Place Depuis Zéro : Le Guide Complet

J'ai reconstruit le système de Karpathy sur ma propre machine en moins d'une heure. Voici chaque étape, y compris celles que la plupart des guides omettent.

Étape 1 : Installer Obsidian et créer la structure du vault.

Téléchargez Obsidian depuis obsidian.md. C'est gratuit pour un usage personnel. Créez un nouveau vault — Obsidian vous demandera de choisir un dossier. J'ai nommé le mien vault et l'ai mis dans mon répertoire home, mais l'emplacement n'a pas d'importance.

À l'intérieur du vault, créez deux dossiers :

vault/
  raw/
  wiki/

C'est toute la structure de fichiers pour commencer. Le dossier wiki sera rempli au fur et à mesure que vous compilez.

Étape 2 : Installer le Web Clipper.

Allez sur obsidian.md/clipper et installez l'extension Chrome. Dans les paramètres du clipper, définissez l'emplacement de sauvegarde par défaut sur votre dossier raw/. Maintenant, n'importe quel article web est à un clic de votre base de connaissances.

Testez immédiatement. Découpez un article que vous vouliez lire. Ouvrez Obsidian et confirmez que le fichier markdown est apparu dans raw/. Si les images ne s'affichent pas, vous avez besoin de l'étape 3.

Étape 3 : Installer Local Images Plus.

Dans Obsidian, allez dans Paramètres > Plugins Communautaires > Parcourir. Cherchez "Local Images Plus" et installez-le. Activez le plugin, puis configurez-le pour télécharger les images dans un sous-dossier de votre vault (j'utilise vault/assets/images/).

Après avoir activé ce plugin, découpez à nouveau un article web. Les images devraient maintenant se télécharger localement et s'afficher correctement dans le mode aperçu d'Obsidian. C'est particulièrement crucial si vous découpez des articles techniques avec des diagrammes, des schémas d'architecture ou des captures de code — le contexte visuel compte, et les LLMs modernes avec des capacités de vision peuvent réellement lire ces images.

Étape 4 : Remplir votre dossier raw.

C'est la partie amusante. Commencez à déverser du contenu dans raw/. Quelques sources qui fonctionnent bien :

• Posts de blog techniques que vous avez mis en favoris (utilisez le Web Clipper)
• Papers de recherche (sauvegarder en PDF ou convertir en markdown)
• READMEs de repos GitHub (copier le markdown directement)
• Vos propres notes, plans et documentation de projets
• Transcriptions de conférences
• Numéros de newsletters que vous avez sauvegardés

Ne les organisez pas. Ne les renommez pas. Ne les taguez pas. Mettez-les juste dans le dossier. Le LLM s'occupe de l'organisation à l'étape suivante.

J'ai commencé avec 63 articles sur les architectures d'agents IA — un mélange de posts de blog, papers et mes propres notes de projet. Le total atteignait environ 180 000 mots de matériau brut.

Étape 5 : Créer votre première compilation wiki.

C'est ici que vous faites intervenir votre agent LLM. Si vous utilisez Claude Code (que je recommande pour ce flux de travail car il gère nativement les opérations de fichiers), naviguez vers le répertoire de votre vault et exécutez un prompt de compilation.

Voici le prompt que j'ai utilisé pour mon premier wiki :

Examine les fichiers dans raw/ qui traitent des architectures d'agents IA,
des systèmes multi-agents ou des patterns d'orchestration d'agents.

Crée un wiki dans wiki/ai-agent-architectures/ avec :
- Un index.md listant chaque article du wiki avec une description d'une ligne
- Des articles individuels pour les concepts majeurs (au minimum : patterns
  d'orchestration, patterns d'utilisation d'outils, architectures de mémoire,
  communication multi-agents)
- Chaque article doit synthétiser des informations de multiples sources raw
- Inclure des [[backlinks]] vers des concepts liés au sein du wiki
- À la fin de chaque article, lister les fichiers sources raw utilisés
- Créer wiki/index.md (l'index maître) s'il n'existe pas,
  et y ajouter ce wiki

Claude Code a parcouru les fichiers raw pertinents, identifié les concepts clés et généré un wiki de 11 articles, un index complet et des références croisées entre eux. Le processus entier a pris environ quatre minutes.

La qualité du résultat m'a surpris. Ce n'était pas un simple résumé — c'était une synthèse véritable. Un article sur les "Architectures de Mémoire pour Agents IA" a tiré des insights de sept sources raw différentes, les a organisés dans un framework cohérent, et a noté où deux des sources se contredisaient sur la question de la persistance de mémoire à long terme.

Étape 6 : Configurer l'index maître.

Après votre première compilation, wiki/index.md devrait exister. Ouvrez-le dans Obsidian et vérifiez qu'il a l'air correct. Au fur et à mesure que vous créez plus de wikis, ce fichier devient le point d'entrée du LLM — la table des matières de toute votre base de connaissances.

Un index maître sain ressemble à ceci :

# Index de la Base de Connaissances

## Wikis

### Architectures d'Agents IA
Patterns d'orchestration, utilisation d'outils, systèmes de mémoire et
frameworks de communication multi-agents.
→ [[ai-agent-architectures/index]]

### Lois de Mise à l'Échelle des Transformers
Compute d'entraînement, nombre de paramètres, besoins en données et
capacités émergentes selon les tailles de modèle.
→ [[transformer-scaling/index]]

Étape 7 : Interroger votre base de connaissances.

Maintenant vient la récompense. Quand vous voulez poser une question à votre base de connaissances, vous dites à Claude Code de commencer par l'index maître :

Lis wiki/index.md pour t'orienter sur ce qui est disponible dans ma
base de connaissances. Puis réponds à cette question en utilisant les
articles wiki pertinents : [ta question ici]

Le LLM lit l'index, identifie le wiki pertinent, navigue vers les articles spécifiques et vous donne une réponse fondée sur vos connaissances compilées — avec des références à des articles spécifiques que vous pouvez vérifier.

Astuce : ajoutez un changelog.md à la racine de votre vault. Chaque fois que vous compilez un nouveau wiki ou en mettez un à jour, notez la date et ce qui a changé. Karpathy recommande un format de préfixe cohérent comme ## [2026-04-05] ingest | Titre de l'Article pour que le journal soit analysable avec des outils unix standard. Cela vous donne (ainsi qu'au LLM) une timeline de l'évolution de la base de connaissances.

Ce Que Cela Fait Bien Que le RAG Traditionnel Fait Mal

Après avoir fait tourner les deux systèmes en parallèle pendant une semaine — mon ancien pipeline RAG basé sur les vecteurs sur le même dataset à côté du wiki style Karpathy — j'ai remarqué trois avantages spécifiques qui ne sont pas évidents tant qu'on n'a pas utilisé les deux.

L'avantage de la synthèse. Quand j'ai demandé à mon système vector RAG « Quels sont les trade-offs entre l'orchestration d'agents centralisée et décentralisée ? », il a retourné cinq chunks de trois documents différents. Les chunks étaient pertinents, mais j'ai dû les synthétiser mentalement moi-même. Le système wiki avait déjà fait cette synthèse pendant la compilation. L'article sur les patterns d'orchestration présentait les trade-offs dans une comparaison structurée, puisant dans les mêmes documents sources mais les présentant comme un argument cohérent plutôt que des fragments.

L'avantage de la découverte. La structure de backlinks du wiki fait émerger des connexions que vous n'avez pas demandées. Quand j'ai interrogé le système wiki sur les architectures de mémoire, la réponse référençait un backlink vers un concept dans le wiki « patterns d'utilisation d'outils » que je n'avais pas connecté mentalement. Le backlink existait parce que le LLM, pendant la compilation, avait remarqué que le problème de persistance de mémoire chez les agents est structurellement similaire au problème de gestion d'état dans les chaînes d'outils. La recherche vectorielle ne trouve pas ces connexions parce qu'elles ne sont pas lexicalement similaires — elles sont conceptuellement liées à un niveau qui requiert de la compréhension, pas du matching.

L'avantage de la transparence. Quand le système wiki me donne une réponse, je peux ouvrir les articles sources dans Obsidian et les lire moi-même. Je peux voir ce que le LLM a synthétisé, je peux vérifier si la synthèse est exacte, je peux la corriger si elle est fausse. Avec le vector RAG, j'obtiens des chunks et des scores de similarité. Debugger pourquoi le système a donné une mauvaise réponse signifie fouiller dans les embeddings et les logs de retrieval. Avec le système wiki, j'ouvre un fichier markdown et je lis. La surface de debug est du texte lisible par un humain.

Si vous préférez que quelqu'un construise un système complet de base de connaissances LLM personnalisé pour votre flux de travail de recherche spécifique, j'accepte exactement ce type de projets d'infrastructure IA. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

Les Limitations Honnêtes — Où Cette Approche Atteint Ses Limites

Je vous rendrais un mauvais service si je n'exposais pas les limites clairement. Le système de Karpathy est brillant pour son cas d'usage prévu, mais il a de vraies contraintes qui comptent.

Plafond d'échelle. Cette approche fonctionne pour environ 100-400 articles (jusqu'à environ 400 000 mots de matériau brut). Au-delà, le LLM commence à avoir du mal à maintenir des index cohérents et le temps de compilation croît considérablement. Si vous traitez des milliers de documents, vous avez besoin d'un RAG traditionnel ou d'une approche hybride. Le point d'équilibre dépend de la fenêtre de contexte de votre LLM — avec le contexte de 1M tokens d'Opus 4.6, vous pouvez aller au-delà des estimations originales de Karpathy, mais il y a toujours un plafond pratique.

Coût de compilation. Chaque fois que vous ajoutez du matériau significatif, vous devez recompiler le wiki concerné. Cela signifie des appels LLM, ce qui signifie des tokens, ce qui signifie de l'argent. Pour un projet hobby, c'est négligeable. Pour une base de connaissances continuellement mise à jour avec une ingestion quotidienne, les coûts de compilation s'accumulent. J'ai trouvé que le batching — accumuler le matériau brut pendant une semaine puis compiler une fois — maintient les coûts raisonnables.

Pas de retrieval en temps réel. Le wiki est un instantané. Si vous avez découpé un article il y a dix minutes mais n'avez pas recompilé le wiki pertinent, le LLM n'en saura rien lors d'une requête. Vous pouvez le pointer vers le dossier raw directement pour les ajouts récents, mais c'est une étape manuelle. Les systèmes RAG traditionnels indexent les nouveaux documents en quelques secondes après l'ingestion.

Conception mono-utilisateur. C'est fondamentalement un système de gestion des connaissances personnel. Il n'y a pas de contrôle d'accès multi-utilisateurs, pas de protections pour l'édition concurrente, pas d'historique de versions au-delà de ce que git fournit. Pour les équipes, il faudrait superposer une infrastructure de collaboration — à ce stade, vous seriez peut-être mieux servi par un système RAG dédié.

Dépendance au LLM. La qualité de votre wiki est directement liée à la qualité du LLM qui fait la compilation. J'ai testé cela avec des modèles plus petits et les résultats sont nettement plus faibles — la synthèse est plus superficielle, les références croisées sont moins perspicaces, et l'organisation de l'index est moins intuitive. Vous voulez un modèle de frontière pour l'étape de compilation. Pour les requêtes, un modèle plus petit peut souvent suffire car il navigue simplement dans un wiki bien structuré.

Ce ne sont pas des dealbreakers. Ce sont des limites de conception. Karpathy a construit ce système pour un profil spécifique — un chercheur ou développeur individuel gérant une base de connaissances personnelle de taille modérée — et dans ces limites, ça fonctionne mieux que tout ce que j'ai essayé.

Ce Que Je Ferais Différemment Après Une Semaine d'Utilisation

Ma première compilation wiki était bâclée. Pas parce que le LLM a fait du mauvais travail, mais parce que je lui ai donné trop de matériau brut d'un coup sans limite thématique claire. J'ai pointé Claude Code vers 63 articles et dit « fais un wiki sur les agents IA ». Le résultat était tentaculaire — 11 articles couvrant tout, du prompt engineering à la coordination multi-agents en passant par le tool calling, avec des backlinks connectant des concepts liés seulement dans le sens le plus large.

La deuxième fois, j'ai été plus chirurgical. J'ai groupé mes fichiers raw en clusters thématiques approximatifs avant la compilation : 18 articles sur les patterns d'orchestration dans un lot, 12 sur les architectures de mémoire dans un autre, 15 sur l'utilisation d'outils dans un troisième. Chacun est devenu son propre wiki avec son propre index focalisé. Les références croisées entre wikis étaient plus significatives parce que chaque wiki avait une portée claire.

C'est ma plus grande leçon pratique : compilez étroit, liez large. Chaque wiki devrait couvrir un sujet serré. Les connexions entre wikis émergent naturellement via les backlinks, et ces connexions sont plus précieuses quand elles relient des domaines véritablement distincts plutôt que de lier des paragraphes adjacents dans le même sujet étalé.

Deuxième leçon : revoyez la première compilation de chaque wiki manuellement. Le LLM fait occasionnellement des choix structurels que vous ne feriez pas — groupant des concepts différemment de ce que vous attendiez, ou créant des articles à une granularité qui ne correspond pas à votre façon de penser le sujet. Un passage de revue et restructuration de 10 minutes après la première compilation vous épargne l'aggravation de problèmes structurels au fur et à mesure que le wiki grandit.

Troisième leçon : votre dossier raw va devenir bordélique, et c'est très bien. J'ai commencé en essayant d'organiser les fichiers raw en sous-dossiers par type de source. C'était de l'effort gaspillé. Le LLM se fiche que vos fichiers raw soient organisés. Il les lit tous, extrait ce qui est pertinent et ignore le reste. Laissez le wiki être votre couche organisée. Laissez raw être votre tiroir fourre-tout.

Je construis des systèmes de gestion des connaissances personnels avec Obsidian depuis un moment — si vous avez lu mon guide sur transformer Obsidian et Claude Code en un second cerveau, vous reconnaîtrez certains de ces patterns. Mais l'approche de compilation de Karpathy va plus loin. Ma configuration originale utilisait Obsidian principalement comme source de contexte — pointer le LLM vers des fichiers markdown et le laisser lire. L'insight de Karpathy est que le LLM devrait aussi écrire la structure de connaissances, pas seulement la consommer.

Où Cela Se Situe dans le Paysage RAG de 2026

Le timing du post de Karpathy n'était pas accidentel. Nous sommes à un point d'inflexion où les outils pour construire des systèmes de connaissances se sont bifurqués en deux camps.

Camp un : plateformes RAG lourdes avec bases de données vectorielles, pipelines d'embedding, modèles de reranking et stratégies de retrieval complexes. Elles sont construites spécifiquement pour l'échelle entreprise — des millions de documents, des milliers de requêtes concurrentes, des exigences strictes de latence. Elles fonctionnent. Mais elles sont chères à construire, chères à maintenir, et excessives pour quiconque dont la collection de documents tient dans un dossier.

Camp deux : ce que Karpathy appelle « LLM Knowledge Bases ». Des fichiers markdown, des index structurés, des wikis compilés par LLM. Zéro infrastructure au-delà d'un éditeur de texte et d'une API LLM. Elles sont construites spécifiquement pour les chercheurs individuels, développeurs et petites équipes dont la base de connaissances se mesure en centaines d'articles, pas en millions.

L'erreur que la plupart font est d'utiliser des outils du camp un pour des problèmes du camp deux. J'ai vu des développeurs solo monter des instances Pinecone pour gérer 40 documents. Ce n'est pas de l'ingénierie, c'est de l'architecture guidée par le CV. Le bon outil pour une base de connaissances de 40 documents est un dossier de fichiers markdown et un LLM intelligent.

Si vos besoins dépassent ce que l'approche markdown-first gère, vous pouvez toujours migrer. Les fichiers raw sont du texte brut. Les wikis sont du texte brut. Il n'y a pas de format propriétaire, pas de vendor lock-in, pas de cauchemar de migration. Vous prenez vos fichiers markdown et les injectez dans le système vers lequel vous évoluez.

C'est peut-être l'aspect le plus sous-estimé du design de Karpathy : il optimise pour le chemin de sortie, pas seulement le chemin d'entrée. Chaque morceau de connaissance dans le système est stocké dans le format le plus portable possible. Si Obsidian disparaît demain, vos fichiers fonctionnent toujours dans VS Code, Notion, Bear ou tout autre éditeur markdown. Si vous dépassez le système, votre contenu déménage avec vous.

Si vous utilisez déjà Obsidian avec Claude Code pour la mémoire persistante — quelque chose que j'ai couvert en profondeur dans mon post sur pourquoi Obsidian a corrigé la plus grande faiblesse de Claude Code — l'approche de compilation wiki de Karpathy est l'étape naturelle suivante. Vous stockez déjà du contexte en markdown. Maintenant, laissez le LLM organiser ce contexte en quelque chose à travers lequel il peut naviguer intelligemment.

Le Changement Qui Compte Plus Que les Détails Techniques

Je reviens sans cesse à une seule distinction qui fait que l'approche de Karpathy se sent fondamentalement différente du RAG traditionnel.

Dans un système RAG traditionnel, le LLM est un consommateur. Il reçoit des chunks, les lit et génère une réponse. La structure de connaissances — les embeddings, l'index, la logique de retrieval — est construite par l'infrastructure d'ingénierie, pas par le modèle lui-même.

Dans le système de Karpathy, le LLM est à la fois architecte et résident. Il construit la structure de connaissances pendant la compilation. Il écrit les résumés, crée les liens, organise l'index. Puis, pendant les requêtes, il navigue dans une maison qu'il a lui-même conçue. Il sait où sont les choses parce qu'il les y a mises.

Ce n'est pas une distinction technique mineure. C'est un paradigme différent pour la façon dont nous pensons les LLMs et la connaissance.

La plus grande partie de la communauté IA en 2026 est focalisée sur rendre le retrieval plus intelligent — de meilleurs embeddings, un meilleur reranking, une meilleure sélection de chunks. Karpathy pose une question fondamentalement différente : et si nous arrêtions de traiter le LLM comme un moteur de recherche et commencions à le traiter comme un bibliothécaire chercheur ? Pas un qui trouve des livres sur demande, mais un qui a déjà lu chaque livre de la collection, écrit des résumés de chacun, créé un catalogue de références croisées, et peut vous mener directement à l'étagère dont vous avez besoin.

Cette question va compter de plus en plus à mesure que les fenêtres de contexte continuent de grandir. Avec Opus 4.6 gérant 1 million de tokens, la quantité de connaissances qu'un LLM peut naviguer à travers des index structurés — sans aucune recherche vectorielle — est déjà pratique pour la plupart des cas d'usage personnels et de petites équipes. Et les fenêtres de contexte ne font que grandir.

Ma base de données vectorielle ne va nulle part. J'en ai encore besoin pour le système RAG de production que j'ai construit pour l'archive de 2 millions de documents d'un client. Mais pour ma base de connaissances personnelle ? Pour la recherche que je fais sur les agents IA, les articles que je lis, les idées que je collectionne ? La base de données vectorielle est débranchée. Le vault Obsidian est ouvert. Et pour la première fois, ma base de connaissances ressemble à quelque chose que je peux réellement parcourir, pas juste interroger.

Commencez avec 20 articles sur un sujet que vous recherchez activement. Découpez-les dans raw. Lancez une compilation. Posez une question au wiki. Voyez ce qu'il connecte. La mise en place prend une heure. Le moment où il fait émerger une connexion entre deux idées que vous n'aviez pas liées vous-même — c'est là que vous comprendrez pourquoi Karpathy a construit cela au lieu de recourir à une autre base de données vectorielle.

Questions Fréquemment Posées

Le système RAG Obsidian de Karpathy nécessite-t-il des compétences en programmation ?

Un minimum de programmation est nécessaire. Le système utilise Obsidian (gratuit, graphique) pour l'interface et un agent LLM comme Claude Code pour la compilation wiki. Vous écrivez des prompts en langage naturel, pas du code. Un confort de base avec la ligne de commande aide mais n'est pas strictement requis.

Combien de documents le système wiki Obsidian peut-il gérer ?

L'approche de Karpathy fonctionne bien pour environ 100-400 articles totalisant jusqu'à 400 000 mots. Au-delà, les temps de compilation augmentent et la cohérence de l'index se dégrade. Pour de plus grandes collections, une approche hybride ou un pipeline RAG traditionnel est plus approprié.

Puis-je utiliser GPT ou d'autres LLMs au lieu de Claude Code pour la compilation wiki ?

Oui. Le gist GitHub de Karpathy mentionne explicitement la compatibilité avec OpenAI Codex, Claude Code et d'autres agents LLM. La qualité de compilation dépend de la capacité de raisonnement du modèle — les modèles de frontière produisent une synthèse et des références croisées nettement meilleures que les modèles plus petits.

Que se passe-t-il si Obsidian n'est plus maintenu ?

Rien ne casse. Chaque fichier du système est du markdown brut stocké localement sur votre machine. Vous pouvez ouvrir toute la base de connaissances dans VS Code, Notion, Bear ou n'importe quel éditeur de texte. Il n'y a zéro vendor lock-in par conception.

En quoi est-ce différent de simplement mettre des fichiers dans un dossier et utiliser ChatGPT ?

La différence critique est l'étape de compilation. Des fichiers raw déversés dans un chat donnent au LLM du contexte non structuré. Le système de Karpathy fait compiler ces fichiers par le LLM en articles wiki structurés avec des index, des résumés et des références croisées — créant une structure de connaissances navigable plutôt qu'un tas de documents.

Travaillons Ensemble

Vous cherchez à construire des systèmes IA, automatiser des flux de travail ou faire évoluer votre infrastructure tech ? Ce serait avec plaisir.

• Fiverr (constructions sur mesure & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io