Karpathy LLM Wiki peut-il remplacer le RAG ?

Pour une base personnelle raisonnable, le Karpathy LLM Wiki peut remplacer un RAG. L’idée est simple : garder vos notes en texte brut, les charger dans un LLM à grand contexte, puis interroger l’ensemble sans pipeline technique inutile.

Pourquoi traiter ses notes comme une wiki ?

Une wiki personnelle sert à conserver une connaissance durable, portable et réutilisable par un LLM, au lieu de disperser des réponses IA dans des conversations perdues.

Le problème vient souvent de notre manière d’utiliser l’IA. Beaucoup s’en servent comme d’un moteur de recherche ponctuel : une question, une réponse, puis on ferme l’onglet. La fois suivante, il faut reformuler le contexte, retrouver les mêmes hypothèses, refaire les mêmes arbitrages. Rien ne s’accumule vraiment.

Cette pratique coûte cher en cohérence. Une décision produit, une recherche marché, une analyse client ou une règle métier devrait pouvoir resservir. Si chaque conversation reste isolée, votre connaissance personnelle ne progresse pas. Vous avez des réponses, mais pas de mémoire de travail.

Le Karpathy LLM Wiki pattern désigne une méthode simple : maintenir une base de connaissances personnelle en fichiers texte ou Markdown, puis fournir ces fichiers directement au modèle via sa fenêtre de contexte. Un LLM, ou grand modèle de langage, est un modèle capable de lire, résumer et générer du texte. La fenêtre de contexte correspond à la quantité de texte qu’il peut prendre en compte dans une requête.

Ce n’est pas un outil précis. C’est une façon d’organiser vos notes pour qu’elles soient lisibles par vous, mais aussi exploitables par un modèle. Le Markdown est un format texte léger : des titres, des listes, des liens, sans dépendre d’une application complexe. Git est un système d’historique des fichiers : il permet de suivre les modifications, revenir en arrière et sauvegarder proprement.

La différence se voit vite :

• Une note isolée aide sur le moment, mais se perd facilement.
• Une application de notes centralise mieux, mais peut enfermer vos données dans un format propriétaire.
• Une wiki texte portable repose sur des fichiers plats, lisibles partout, sauvegardables, versionnables avec Git et faciles à concaténer pour un LLM.

/wiki
  notes-projets.md
  décisions-business.md
  apprentissages-ia.md
  clients.md
  idées-contenus.md

Cette simplicité est précisément sa force. Un humain peut parcourir ces fichiers sans interface spéciale. Un modèle peut les lire d’un bloc, repérer les relations et répondre avec votre contexte réel.

Format	Avantage	Limite
Conversation IA	Rapide pour explorer une question	Connaissance dispersée et difficile à réutiliser
Application de notes classique	Pratique pour capturer et classer	Dépendance possible à un outil ou format propriétaire
Wiki texte portable	Lisible, versionnable, sauvegardable et exploitable par un LLM	Demande une discipline minimale d’organisation

Quand le texte brut suffit-il mieux que le RAG ?

Le texte brut suffit mieux que le RAG quand la base personnelle tient dans la fenêtre de contexte du modèle.

La fenêtre de contexte, c’est la quantité de texte qu’un LLM peut lire en une seule requête. Si votre wiki personnel, vos notes ou votre documentation font 50 000 à 100 000 mots, il devient souvent plus simple de tout charger directement plutôt que de construire une usine RAG.

RAG signifie Retrieval-Augmented Generation, ou génération augmentée par récupération. Le principe est simple : le système découpe vos documents, transforme chaque morceau en représentation numérique, stocke ces représentations dans une base spécialisée, récupère les passages jugés pertinents, puis les envoie au LLM avec votre question.

Les composants sont utiles, mais ils ajoutent de la complexité :

• Chunking : Découpage des documents en morceaux plus petits, souvent quelques centaines ou milliers de tokens.
• Embeddings : Représentation numérique du sens d’un texte, sous forme de vecteur.
• Base vectorielle : Moteur de recherche sémantique capable de retrouver des textes proches par le sens, pas seulement par mots-clés.
• Retrieval : Étape de récupération des passages supposés utiles avant génération de la réponse.

À l’échelle entreprise, le RAG reste très pertinent. Une base documentaire peut contenir des millions de mots, changer chaque jour, mélanger SharePoint, Notion, Google Drive, Confluence ou GitHub, et imposer des droits d’accès différents selon les équipes. Dans ce cas, charger tout le corpus dans le prompt n’a aucun sens.

Mais pour une base personnelle, le RAG est souvent surdimensionné. Anthropic indique une fenêtre de contexte de 200 000 tokens pour Claude 3.5 Sonnet et Claude 3 Opus. OpenAI a annoncé 128 000 tokens pour GPT-4 Turbo. Google a présenté Gemini 1.5 Pro avec une fenêtre allant jusqu’à 1 million de tokens en préversion, puis 2 millions pour certains usages développeurs.

Attention aux tokens. Un token ne correspond pas exactement à un mot. Selon la documentation OpenAI, en anglais, 1 token représente souvent environ 4 caractères. En français, il faut rester prudent : les accents, apostrophes et formes grammaticales peuvent modifier le découpage. Le plus fiable reste de tester votre corpus avec un tokenizer avant de décider.

Ma règle simple : si tout tient dans le contexte, chargez le texte complet. Si la base dépasse largement le contexte, change souvent ou exige des droits d’accès complexes, envisagez le RAG.

Quels problèmes le RAG ajoute-t-il à petite échelle ?

À petite échelle, RAG ajoute surtout des points de panne, des coûts et de la maintenance qui ne sont pas toujours justifiés.

RAG, pour Retrieval-Augmented Generation, consiste à chercher des passages dans une base documentaire avant de les donner au modèle de langage, ou LLM pour Large Language Model. Sur le papier, c’est propre. Dans la pratique, même un petit projet doit choisir un modèle d’embeddings, créer une base vectorielle comme Pinecone, Weaviate ou Chroma, définir une stratégie de découpage, indexer les documents, gérer les mises à jour, surveiller les coûts d’API et mesurer la qualité de récupération.

Le découpage est souvent le premier piège. Un passage utile peut être séparé de son contexte. Une décision peut être coupée de sa justification. Une note peut perdre son sens parce que le paragraphe précédent expliquait le “pourquoi”. Le modèle ne raisonne pas sur votre base complète. Il raisonne uniquement sur les morceaux effectivement fournis dans le prompt.

Le deuxième risque est la récupération incomplète. Si le moteur vectoriel ne remonte pas le bon passage, le LLM répond sans l’information nécessaire, même si elle existe quelque part dans la base. C’est le problème classique de précision et de rappel en recherche d’information : récupérer peu de bruit, mais surtout ne pas rater les bons documents.

L’argument d’efficacité est simple. Avec RAG, il faut au minimum une étape d’indexation ou d’embeddings, puis une étape de génération. Avec le pattern Karpathy LLM Wiki, une seule requête peut suffire : le modèle reçoit toute la base utile, sous forme de texte, et raisonne directement dessus.

Le texte brut n’est pas magique pour autant. Il faut des notes propres, des titres explicites, une organisation minimale, une limite de taille surveillée et une attention au coût des longs contextes.

Critère	RAG	Karpathy LLM Wiki
Infrastructure	Base vectorielle, embeddings, pipeline d’indexation	Fichiers texte ou wiki structuré
Coût	Embeddings, stockage, requêtes de recherche et génération	Surtout coût du contexte envoyé au LLM
Risque de perte de contexte	Élevé si le découpage ou la récupération échoue	Plus faible si toute la base utile tient dans le contexte
Maintenance	Mises à jour d’index, monitoring, évaluation	Nettoyage et organisation des notes
Portabilité	Dépend d’outils spécialisés	Très portable, souvent de simples fichiers
Cas d’usage idéal	Gros volumes, bases dynamiques, recherche fine	Petite base stable, notes personnelles, documentation projet

Pourquoi Claude est-il adapté à ce pattern ?

Claude est adapté à ce pattern parce qu’il combine une grande fenêtre de contexte et de bonnes capacités de lecture de documents longs. Une fenêtre de contexte désigne la quantité de texte qu’un modèle peut recevoir et utiliser dans une requête, en comptant les instructions, les documents fournis, l’historique éventuel et la réponse générée. Plus cette fenêtre est grande, plus vous pouvez charger directement de notes, de pages ou de fichiers sans passer par une recherche vectorielle classique.

Anthropic documente des modèles Claude 3 et Claude 3.5 avec 200 000 tokens de contexte. Un token est un morceau de texte, souvent proche d’un mot court ou d’une partie de mot. OpenAI a annoncé GPT-4 Turbo avec 128 000 tokens. Google a communiqué sur Gemini 1.5 Pro avec des contextes très longs, jusqu’à 1 million puis 2 millions de tokens selon les environnements. Le point important n’est donc pas que Claude soit le seul capable de le faire, mais qu’il fait partie des modèles publics solides pour ce type d’usage.

Il faut quand même connaître une limite : le problème du lost in the middle. Des chercheurs de Stanford, UC Berkeley et Samaya AI ont montré, dans l’article Lost in the Middle: How Language Models Use Long Contexts publié en 2023, que les modèles exploitent parfois moins bien une information placée au milieu d’un long contexte. Ce n’est pas un blocage. C’est une contrainte de conception.

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

• Placer les consignes et la question au début de la requête.
• Ajouter un sommaire des notes chargées.
• Structurer les documents avec des titres clairs et stables.
• Répéter les éléments critiques dans une section de synthèse.
• Demander au modèle de citer les fichiers ou sections utilisés.

Un prompt utilisateur peut rester très simple :

<p>Vous êtes un assistant chargé de répondre à partir d’une base de notes interne.</p>
<ul>
  <li>Rôle : analyser les notes fournies et répondre de façon factuelle.</li>
  <li>Contexte chargé : toutes les notes ci-dessous appartiennent à ma base documentaire.</li>
  <li>Règle : ne répondez qu’à partir des notes fournies.</li>
  <li>Sources : citez les fichiers ou sections utilisés.</li>
  <li>Incertitude : signalez clairement les zones non couvertes par les notes.</li>
</ul>

Claude n’est donc pas obligatoire. Ce pattern fonctionne avec tout LLM capable de gérer correctement un long contexte, mais Claude devient un choix naturel lorsque votre base tient dans ses limites.

Comment construire sa base Karpathy LLM Wiki ?

Construire une base Karpathy LLM Wiki consiste à écrire des fichiers texte propres, les organiser simplement, puis les fournir au modèle quand on veut raisonner dessus. L’idée est volontairement moins sophistiquée qu’un RAG, ou Retrieval-Augmented Generation, qui récupère automatiquement des morceaux de documents avant de répondre.

Je partirais d’un dossier unique, en Markdown, parce que ce format reste lisible par un humain et facile à traiter par un script. La structure peut rester très simple :

00-index.md	Liste les fichiers, les sujets couverts et les règles de lecture.
01-principes.md	Décrit les convictions, contraintes, définitions et choix stables.
02-projets.md	Regroupe les projets actifs, leurs objectifs, leurs statuts et leurs dépendances.
03-decisions.md	Trace les décisions importantes avec une date, un contexte et une justification.
04-recherches.md	Stocke les notes de lecture, benchmarks, sources et résultats d’analyse.
05-prompts.md	Centralise les prompts utiles, leurs cas d’usage et leurs limites.

Chaque fichier doit avoir des titres explicites, des paragraphes courts et des décisions datées. Des tags simples peuvent aider, par exemple #client, #architecture ou #risque, mais ils ne doivent pas remplacer une bonne organisation. Je versionne le dossier avec Git quand c’est possible, sinon je prévois une sauvegarde régulière. Git permet de suivre l’historique des modifications et de revenir à une version précédente.

Pour préparer la base pour un LLM, ou Large Language Model, je peux concaténer les fichiers et coller le résultat dans Claude, ChatGPT ou un autre modèle avec une grande fenêtre de contexte. Un token correspond approximativement à un morceau de mot ; la limite de contexte désigne la quantité totale de texte que le modèle peut lire en une fois.

from pathlib import Path

# Dossier contenant les fichiers Markdown
folder = Path("karpathy-wiki")

# Fichier de sortie
output = Path("knowledge-base.txt")

parts = []

# Lecture des fichiers .md dans l'ordre alphabétique
for file in sorted(folder.glob("*.md")):
    content = file.read_text(encoding="utf-8")
    parts.append(f"\n\n===== {file.name} =====\n\n{content}")

# Assemblage dans un seul fichier texte
output.write_text("".join(parts), encoding="utf-8")

print(f"Base générée : {output}")

Le prompt d’interrogation doit cadrer le modèle. Par exemple : « Utilise uniquement la base fournie. Cite les sections pertinentes. Distingue clairement les faits, les hypothèses et les recommandations. Si une information manque, dis-le. Termine par une réponse actionnable avec les prochaines étapes. »

Cette approche doit s’arrêter quand la base atteint plusieurs millions de mots, quand les accès doivent être personnalisés par utilisateur, quand les données changent en continu ou quand il faut interroger des sources hétérogènes en production. Dans ces cas, un RAG ou une architecture hybride redevient pertinent.

Checklist opérationnelle :

• Format texte simple, idéalement Markdown.
• Index clair dans 00-index.md.
• Fichiers courts, mais cohérents par thème.
• Décisions importantes datées.
• Sauvegarde ou versionnement Git.
• Test de taille de contexte avant usage.
• Prompt standard pour interroger la base.
• Revue mensuelle pour supprimer, corriger et consolider.

Alors, faut-il vraiment installer un RAG ?

Le Karpathy LLM Wiki pattern remet une idée simple au centre : pour une base personnelle, le meilleur système est souvent celui que vous pouvez lire, sauvegarder, versionner et donner directement à un LLM. RAG reste utile pour les gros corpus, les usages entreprise et les contraintes d’accès complexes. Mais si vos notes tiennent dans une grande fenêtre de contexte, le texte brut réduit la maintenance, les coûts et les risques de récupération incomplète. En structurant vos fichiers Markdown et vos prompts, vous obtenez une base durable, interrogeable et indépendante des outils. Le bénéfice est clair : vous capitalisez mieux votre connaissance, sans sur-ingénierie.

FAQ

• Qu’est-ce que le Karpathy LLM Wiki pattern ?
  C’est une méthode qui consiste à garder une base de connaissances personnelle en texte brut, souvent en Markdown, puis à la fournir directement à un grand modèle de langage. L’objectif est d’éviter une architecture RAG quand la base tient déjà dans la fenêtre de contexte du modèle.
• Quelle est la différence entre une wiki personnelle et une application de notes ?
  Une wiki personnelle privilégie la portabilité : fichiers texte lisibles partout, sauvegardables, versionnables et faciles à concaténer. Une application de notes peut être pratique, mais elle enferme parfois les contenus dans un format ou un écosystème moins durable.
• Pourquoi éviter RAG pour une petite base personnelle ?
  RAG ajoute un modèle d’embeddings, une base vectorielle, du découpage de documents, une étape de récupération et de la maintenance. Pour une base de taille modérée, charger tout le texte dans le contexte du LLM peut être plus simple et plus fiable.
• À partir de quand RAG redevient-il nécessaire ?
  RAG redevient pertinent quand le corpus ne tient plus dans le contexte du modèle, par exemple avec des millions de mots, des documents très nombreux, des droits d’accès complexes ou des données qui changent en permanence.
• Claude est-il obligatoire pour utiliser ce pattern ?
  Claude n’est pas obligatoire. Il est bien adapté grâce à sa grande fenêtre de contexte, documentée à 200 000 tokens pour plusieurs modèles Claude 3 et 3.5. D’autres modèles à long contexte peuvent aussi convenir, selon la taille de la base et la qualité de lecture attendue.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA, le SEO et le GEO. J’ai travaillé pour des organisations comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos données, vos connaissances ou vos workflows IA sans ajouter de complexité inutile, contactez-moi.