Karpathy LLM Wiki peut-il remplacer le RAG personnel ?

Un Karpathy LLM Wiki peut remplacer le RAG quand votre base personnelle tient dans la fenêtre de contexte du modèle. L’idée est simple : garder vos notes en texte brut, les versionner, puis les donner au LLM. Moins d’infrastructure, moins de pertes, plus de continuité.

Pourquoi vos recherches IA se perdent ?

Parce que l’usage ponctuel de l’IA produit des réponses utiles, mais rarement une mémoire exploitable.

Traiter un LLM comme un moteur de recherche aide à résoudre une question maintenant : résumer un article, écrire une requête SQL, comparer deux librairies Python, trouver une explication. Un LLM, pour Large Language Model, est un grand modèle de langage entraîné à prédire et générer du texte à partir d’un contexte donné. Le problème arrive après. Une bonne réponse reste souvent coincée dans une conversation isolée, avec un titre vague, une date oubliée et aucun lien clair avec vos recherches précédentes.

Résultat : La connaissance ne s’accumule pas. Elle se répète. Vous redemandez la même chose, vous comparez mal deux réponses obtenues à trois semaines d’écart, vous perdez les nuances, les sources, les décisions et les tests déjà faits. Ce n’est pas grave pour une question simple. C’est coûteux pour un projet, une veille technique ou un apprentissage long.

Le principe du Karpathy LLM Wiki consiste à garder une base personnelle en fichiers texte lisibles, par exemple en .txt ou en .md, puis à l’alimenter au fil des recherches. Le bénéfice ne se limite pas au stockage de notes. L’intérêt est de créer une mémoire cumulative que le modèle peut relire pour raisonner avec l’historique complet : ce qui a été testé, pourquoi une option a été écartée, quelles sources ont servi, quelles conclusions restent fragiles.

Ce pattern fonctionne surtout pour les contenus que vous voulez retrouver, enrichir et réutiliser :

• Notes de veille IA avec modèles testés, limites observées et liens sources.
• Documentation d’un projet data avec schémas, métriques, décisions de pipeline et conventions.
• Journal de décisions produit avec hypothèses, arbitrages et raisons du choix final.
• Synthèses d’articles scientifiques avec méthode, résultats, limites et citations.
• Prompts testés avec sorties obtenues, variantes et critères d’évaluation.

Les grands contextes rendent cette approche plus crédible. Anthropic documente jusqu’à 200 000 tokens de contexte pour les modèles Claude 3 et Claude 3.5, ce qui permet de relire de longs ensembles de texte dans une même session. OpenAI rappelle aussi qu’un token représente approximativement quatre caractères, ou trois quarts d’un mot en anglais, avec prudence selon la langue et le contenu. Autrement dit, la taille du contexte compte, mais la qualité de votre mémoire textuelle compte autant.

La vraie question devient donc simple : Est-ce que vous voulez une application de notes de plus, ou un wiki personnel portable que votre IA peut relire, comparer et enrichir avec vous ?

Qu’est-ce qu’un vrai wiki personnel ?

Un vrai wiki personnel n’est pas une application. C’est une base de fichiers simples, lisibles sans outil propriétaire, faciles à déplacer et faciles à transmettre à un LLM, c’est-à-dire un grand modèle de langage comme ChatGPT, Claude ou Gemini.

Une application de notes peut être excellente. Elle capture vite, classe proprement, synchronise entre appareils et retrouve une information en quelques secondes. Le problème arrive quand votre connaissance dépend trop de cette application : format fermé, export incomplet, interface obligatoire, synchronisation propriétaire, ou contenus difficiles à concaténer proprement pour les donner à un modèle.

Un wiki personnel orienté LLM part d’un choix plus sobre : du texte brut. Des fichiers .txt ou .md, des dossiers simples, des titres explicites, quelques conventions minimales. Markdown est une syntaxe légère qui permet de structurer du texte avec des titres, listes et liens tout en restant lisible comme du texte normal.

Git ajoute une couche utile sans transformer le système en usine à gaz. Git est un système de gestion de versions très utilisé par les développeurs. Il permet de garder l’historique, comparer les changements, revenir en arrière après une mauvaise modification et synchroniser la même base sur plusieurs machines.

Une structure suffisante ressemble souvent à ceci :

• Un dossier par grand domaine : Projets, Clients, Santé, Finance, Recherche.
• Un fichier par sujet stable : Assurance-habitation.md, Stratégie-contenu.md, Serveur-maison.md.
• Un fichier journal pour les décisions, avec une date et un contexte.
• Un fichier index optionnel pour lister les documents importants.

Critère	Application de notes	Wiki texte brut
Portabilité	Dépend souvent de l’export fourni	Copiable comme n’importe quel dossier
Lisibilité	Parfois liée à l’interface	Lisible dans n’importe quel éditeur de texte
Versioning	Variable selon l’outil	Simple avec Git
Dépendance fournisseur	Souvent réelle	Faible
Ingestion par LLM	Parfois pénible à exporter proprement	Facile à concaténer et à transmettre
Durabilité	Liée à la survie du produit	Liée à des formats standards

Le but n’est pas de construire une cathédrale documentaire. Il s’agit d’obtenir une base durable, portable et concaténable. Quand cette base reste simple et de taille raisonnable, l’infrastructure de recherche vectorielle d’un RAG devient parfois disproportionnée.

Pourquoi le texte brut peut battre le RAG ?

À petite échelle, le texte brut a un avantage très simple : il évite de construire une usine quand un fichier bien structuré suffit. Si toute votre base tient dans la fenêtre de contexte du modèle, envoyer directement les contenus pertinents peut être plus fiable qu’un pipeline RAG complet.

Le RAG, pour Retrieval-Augmented Generation, consiste à rechercher des passages pertinents dans une base documentaire avant de les transmettre au LLM, c’est-à-dire au modèle de langage, pour générer une réponse. La méthode est solide et bien documentée, notamment depuis l’article de Lewis et al., 2020, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.

Un pipeline RAG demande plusieurs briques techniques :

• Découpage en chunks : Les documents sont coupés en fragments plus petits, souvent quelques centaines de mots.
• Embeddings : Chaque fragment est transformé en vecteur numérique, une représentation mathématique du sens du texte.
• Base vectorielle : Des outils comme Pinecone, Weaviate ou Chroma stockent ces vecteurs pour retrouver les textes proches sémantiquement.
• Recherche et sélection : Le système récupère les fragments jugés les plus proches de la question.
• Génération : Le LLM reçoit ces fragments et produit la réponse.

Le problème, dans une base personnelle, vient souvent des détails. Un mauvais découpage peut séparer une idée de son contexte. Un passage important peut ne pas être récupéré. Deux chunks voisins peuvent contenir ensemble la réponse, mais être traités séparément. À cela s’ajoutent la latence, le coût de plusieurs appels, la maintenance de l’index et la réindexation après chaque modification de fichier.

RAG personnel	Recherche préalable, embeddings, base vectorielle, index à maintenir.
Karpathy LLM Wiki	Concaténation des fichiers utiles, envoi au modèle, question directe.

Avec l’approche Karpathy LLM Wiki, la logique devient presque brutale : concaténer les fichiers pertinents, ou toute la base si elle est petite, puis poser la question au modèle. Une base de 50 000 à 100 000 mots peut souvent rester compatible avec des fenêtres de contexte de 128 000 à 200 000 tokens, selon la langue, le format et le modèle. En revanche, une base de plusieurs millions de mots impose presque toujours une recherche préalable.

Il reste une limite importante. L’étude de Liu et al., 2023, Lost in the Middle, montre que les modèles utilisent parfois moins bien l’information placée au milieu d’un long contexte. Le texte brut ne supprime donc pas le besoin de structurer : titres clairs, ordre logique, résumés, sections courtes. Mais il supprime une grande partie de la complexité technique. Et cette différence devient vite un argument économique et opérationnel.

Quand le RAG redevient-il nécessaire ?

Le RAG redevient nécessaire quand le volume, la fréquence de mise à jour, les droits d’accès ou les usages multi-utilisateurs dépassent ce qu’un simple contexte long peut gérer proprement.

La règle pragmatique tient en une phrase : utilisez le texte brut tant que la base reste personnelle, lisible, raisonnable en taille et assez stable ; envisagez le RAG quand le corpus devient massif, mouvant ou collectif.

Le RAG, pour Retrieval-Augmented Generation, consiste à rechercher d’abord les passages utiles dans une base documentaire, puis à les fournir au modèle pour générer une réponse. Cette approche garde un vrai avantage dans plusieurs cas concrets :

• Des millions de mots, impossibles ou trop coûteux à injecter entièrement dans une fenêtre de contexte.
• Des documents métiers nombreux, avec des versions, des doublons, des formats et des propriétaires différents.
• Une documentation client ou une base support qui change tous les jours.
• Des droits d’accès par équipe, par client ou par rôle, qu’il faut respecter avant même d’interroger le modèle.
• Un besoin de recherche rapide sur un corpus large, sans relire toute la base à chaque question.
• Une traçabilité fine des sources, passage par passage, pour savoir exactement d’où vient une réponse.

Le sujet n’est donc pas de déclarer le RAG inutile. Le sujet est de ne pas l’imposer à une base personnelle qui n’en a pas besoin.

Avec un RAG, il faut souvent au moins quatre briques : une étape d’embedding, c’est-à-dire la transformation des textes en vecteurs numériques ; une base vectorielle pour les stocker ; une étape de retrieval, donc de recherche des passages pertinents ; puis une génération par le modèle. Avec un wiki en contexte long, un seul appel d’inférence peut suffire si la base tient dans la fenêtre du modèle. Le coût réel reste à calculer au cas par cas : prix API, volume de tokens, modèle choisi, cache éventuel et fréquence d’usage changent complètement l’équation.

Situation	Approche conseillée	Pourquoi
Base personnelle de moins de 100 000 mots	Texte brut en contexte long	La simplicité gagne souvent : moins d’infrastructure, moins de bugs, moins de maintenance.
Base projet de quelques centaines de milliers de mots	Contexte long ou RAG léger	Le choix dépend de la stabilité du corpus, du coût des appels et du besoin de recherche précise.
Base entreprise de millions de mots	RAG	Le volume impose une sélection des passages avant génération.
Données avec droits d’accès fins	RAG avec contrôle d’accès	La recherche doit filtrer les documents autorisés avant de les envoyer au modèle.
Besoin de réponse sourcée à grande échelle	RAG structuré	La citation des passages devient plus fiable et plus contrôlable.

Dès qu’on mise sur une grande fenêtre de contexte, le choix du modèle devient central : taille réellement exploitable, qualité de raisonnement sur long document, coût et latence ne se valent pas d’un modèle à l’autre.

Pourquoi Claude convient bien à ce pattern ?

Claude colle bien au pattern “LLM Wiki” parce qu’il accepte de longs contextes et se comporte plutôt bien sur l’analyse de documents volumineux. L’idée est simple : au lieu de construire tout de suite un RAG, vous donnez au modèle un wiki propre, structuré, puis vous lui demandez de raisonner dessus.

Une fenêtre de contexte désigne la quantité de texte que le modèle peut prendre en compte dans une requête. Elle inclut vos instructions, les documents fournis, l’historique éventuel et la réponse générée. Plus elle est grande, plus vous pouvez charger de notes, décisions, extraits de code, comptes rendus ou spécifications dans une seule interaction.

Modèle	Capacité publiée
Claude 3 et Claude 3.5	Anthropic indique 200 000 tokens dans sa documentation officielle.
GPT-4 Turbo	OpenAI a communiqué une fenêtre de 128 000 tokens.
Gemini 1.5 Pro	Google a présenté jusqu’à 1 million de tokens, et jusqu’à 2 millions dans certains accès et annonces développeurs.

Ces chiffres sont des capacités publiées par les fournisseurs, pas une garantie que le modèle exploitera parfaitement chaque information sur toute la longueur. Le point dur n’est pas seulement de “faire rentrer” le wiki. Le modèle doit aussi retrouver la bonne information et l’utiliser correctement.

Le problème est connu sous le nom Lost in the Middle. Liu et al., 2023 ont montré que les modèles peuvent mieux utiliser les informations placées au début et à la fin du contexte que celles perdues au milieu. En pratique, un gros fichier mal structuré peut donc rester difficile à exploiter, même avec 200 000 tokens.

Pour réduire ce risque, quelques règles simples changent beaucoup le résultat :

• Placez un index au début du fichier ou du corpus.
• Utilisez des titres explicites et stables.
• Gardez des sections courtes, avec une idée principale par section.
• Ajoutez des résumés par dossier ou par thème.
• Adoptez des conventions de noms claires pour les fichiers.
• Rappelez les décisions clés en haut des documents importants.

La méthode opérationnelle tient en cinq étapes : nettoyer les fichiers, créer un index, concaténer toute la base ou seulement un sous-ensemble utile, donner une consigne claire au LLM, puis demander une réponse avec citations de fichiers ou de sections.

Prompt utilisateur : Réponds uniquement à partir du wiki fourni ci-dessous. Si une information manque, indique clairement que tu ne peux pas conclure. Signale les incertitudes, distingue les faits des hypothèses, et cite systématiquement les noms de fichiers ou les sections utilisées pour répondre.

Au fond, Claude rend ce pattern confortable parce qu’il repousse le moment où un RAG devient nécessaire. Mais le meilleur système personnel reste souvent celui que vous maintenez réellement, sans pipeline fragile ni complexité inutile.

Et si votre meilleure base IA était juste du texte ?

Le Karpathy LLM Wiki ne remplace pas tous les systèmes RAG. Il remet surtout les priorités dans le bon ordre. Pour une base personnelle, des fichiers .txt ou .md bien structurés, versionnés avec Git et envoyés à un LLM à long contexte peuvent suffire. Vous évitez les embeddings, la base vectorielle, le chunking et les erreurs de récupération inutiles. Le RAG garde sa place pour les corpus massifs, collectifs ou soumis à des droits fins. Mais si votre objectif est de capitaliser vos recherches, décisions et apprentissages, cette approche vous donne une mémoire IA portable, durable et beaucoup plus simple à maintenir.

FAQ

• Qu’est-ce que le Karpathy LLM Wiki pattern ?
  C’est une façon de construire une base de connaissances personnelle avec des fichiers texte simples, comme .txt ou .md, puis de les fournir directement à un LLM capable de gérer un long contexte. L’objectif est de garder une mémoire portable, lisible et durable, sans dépendre d’une base vectorielle ou d’une chaîne RAG.
• Quelle différence entre un wiki texte brut et une application de notes ?
  Une application de notes privilégie souvent l’interface, la capture rapide et la synchronisation. Un wiki en texte brut privilégie la portabilité : les fichiers restent lisibles partout, faciles à sauvegarder, versionner avec Git et concaténer pour être envoyés à un modèle d’IA.
• Le texte brut est-il vraiment meilleur que le RAG ?
  Pour une base personnelle de taille raisonnable, il peut être plus simple et plus fiable. Le RAG reste utile pour de très grands corpus, mais il ajoute du découpage, des embeddings, une base vectorielle, une étape de recherche et de la maintenance. Si tout tient dans la fenêtre de contexte du LLM, cette complexité n’est pas toujours nécessaire.
• Quelle taille de base peut tenir dans un LLM à long contexte ?
  Cela dépend de la langue, du format des fichiers et du modèle. À titre d’ordre de grandeur, une base de 50 000 à 100 000 mots peut souvent être compatible avec des fenêtres de 128 000 à 200 000 tokens. Il faut toutefois compter les instructions, les séparateurs, les noms de fichiers et la réponse générée.
• Pourquoi Claude est souvent cité pour ce type de wiki ?
  Claude est souvent cité parce qu’Anthropic propose des modèles avec une fenêtre de contexte de 200 000 tokens, adaptée à l’analyse de longs documents. Cela permet de charger une base personnelle complète ou un gros sous-ensemble. Il faut malgré tout structurer les fichiers, car les longs contextes peuvent poser des problèmes de repérage de l’information.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les processus métier et le SEO/GEO. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer une base de connaissance IA, automatiser vos workflows ou rendre vos données vraiment exploitables, contactez-moi.