Comment utiliser le Karpathy LLM Wiki pattern ?

Le Karpathy LLM Wiki pattern consiste à donner tout votre wiki personnel en texte brut à un LLM à long contexte, plutôt que de construire un RAG. L’intérêt est simple : moins d’outils, moins de pertes, plus de continuité dans vos recherches.

Quel problème résout ce pattern ?

Le Karpathy LLM Wiki pattern résout surtout le problème de la connaissance éphémère produite par les échanges ponctuels avec l’IA.

Beaucoup d’utilisateurs interrogent un LLM comme un moteur de recherche amélioré. Ils posent une question, copient parfois un bout de réponse, puis passent à autre chose. Le problème arrive quelques jours plus tard : le raisonnement utile, les hypothèses, les arbitrages et les liens avec d’autres sujets ont disparu dans un historique difficile à exploiter.

Un LLM, pour Large Language Model, est un modèle capable de lire, résumer, relier et produire du texte. Il peut aider à clarifier une idée, comparer des options, reformuler une procédure ou analyser un document. Mais si chaque échange reste isolé, la valeur produite s’évapore.

Les conséquences sont très concrètes :

• Vous reposez plusieurs fois les mêmes questions, avec des réponses parfois différentes.
• Vous capitalisez mal sur vos recherches, car les bonnes explications restent dans des conversations séparées.
• Vous n’avez pas de mémoire structurée de vos décisions, définitions, procédures ou analyses.
• Vous dépendez de l’historique d’un outil, souvent peu pratique à rechercher, exporter ou relire.

L’idée centrale du pattern est simple : garder le savoir dans un wiki personnel, composé de fichiers texte ou Markdown, puis fournir ce corpus complet au modèle lors des requêtes importantes. Markdown est un format texte léger qui permet d’écrire des titres, listes, liens et blocs de code sans dépendre d’un logiciel complexe.

Ce wiki peut contenir plusieurs types d’informations utiles :

• Des notes de recherche et synthèses de lecture.
• Des décisions prises, avec leur contexte et leurs raisons.
• Des définitions internes, procédures et modes opératoires.
• Des comptes rendus de réunions ou d’expériences.
• Des idées, analyses concurrentielles et prompts validés.

Ce pattern n’a rien de magique. C’est une discipline de gestion de connaissance : écrire, ranger, relire, enrichir. Le LLM devient plus utile parce qu’il travaille avec votre contexte réel, pas seulement avec une question isolée.

Avant de comparer cette approche au RAG, Retrieval-Augmented Generation, c’est-à-dire la génération augmentée par recherche documentaire, il faut comprendre un point clé : un wiki plat n’est pas une simple application de notes. C’est une base de contexte portable, lisible par vous, et directement exploitable par un modèle.

Pourquoi un wiki plutôt qu’une note app ?

Un wiki personnel en texte brut est préférable ici parce qu’il reste lisible, portable, versionnable et facilement transmissible à un LLM. Un LLM, ou grand modèle de langage, comme Claude, ChatGPT ou Gemini, travaille mieux avec des contenus simples, explicites et faciles à copier.

Une application de notes peut être excellente pour capturer vite une idée, une réunion ou un extrait de page web. Le problème arrive plus tard. Elle dépend souvent d’une interface, d’une base de données interne, d’un format propriétaire, d’une synchronisation cloud ou d’un export qui ne restitue pas toujours correctement les liens, les pièces jointes ou la structure.

Le texte brut désigne des fichiers simples, comme .txt ou .md, lisibles par n’importe quel éditeur. Markdown est une syntaxe légère qui permet d’ajouter des titres, des listes ou des liens dans un fichier texte, sans dépendre d’une application spécifique. C’est important pour la pérennité : un fichier texte ouvert aujourd’hui a de fortes chances d’être encore lisible dans dix ou vingt ans.

Opérationnellement, un dossier de fichiers Markdown se manipule très facilement. Il peut être sauvegardé, recherché, concaténé, envoyé à Claude, versionné avec Git et modifié avec des outils standards. Git est un système qui garde l’historique des modifications. Il permet de revenir en arrière, de comparer deux versions ou de comprendre comment une base de connaissance a évolué.

Une structure simple suffit souvent pour démarrer :

wiki/
  recherche/
    2026-01-15-llm-context-window.md
  projets/
    2026-01-20-refonte-site-v1.md
  clients/
    client-acme-notes.md
  procedures/
    sauvegarde-wiki-v1.md
  glossaire/
    rag.md
    embeddings.md

Une convention sobre évite le chaos. J’utilise généralement une date, un sujet clair, puis une version si nécessaire. Par exemple : 2026-01-20-refonte-site-v1.md. Ce nom reste lisible par moi, par un script et par un LLM.

Critère	Application de notes	Wiki texte brut	Base documentaire complexe
Portabilité	Moyenne, souvent liée à un export.	Très forte, fichiers .txt ou .md.	Variable, dépend de la plateforme.
Durabilité	Dépend de l’éditeur et du format.	Très bonne, formats ouverts et simples.	Bonne si bien administrée, fragile sinon.
Facilité d’usage avec un LLM	Correcte, mais l’export peut gêner.	Excellente, contenu copiable et concaténable.	Souvent lourde, avec accès et permissions.
Maintenance	Faible au début, dépendance ensuite.	Faible, outils simples et automatisables.	Élevée, gouvernance et administration nécessaires.

Pourquoi éviter le RAG à petite échelle ?

À l’échelle d’une base personnelle raisonnable, le texte intégral peut être plus simple et plus fiable qu’un pipeline RAG.

RAG signifie Retrieval-Augmented Generation, ou génération augmentée par récupération. Le principe est simple : on découpe les documents en morceaux, on transforme ces morceaux en vecteurs numériques appelés embeddings, on les stocke dans une base vectorielle, puis on récupère les passages jugés proches de la question avant de les envoyer au modèle de langage.

Le RAG est une vraie solution pour de grands corpus. L’article de Lewis et al., publié en 2020 sous le titre Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, a popularisé cette approche pour combiner recherche documentaire et génération de texte. Mais ce cadre répond surtout à un problème précis : le corpus est trop grand pour être donné entièrement au modèle.

À petite échelle, cette architecture ajoute vite plus de surface de panne que de valeur. Un pipeline RAG comporte plusieurs choix techniques, et chacun peut dégrader la réponse finale.

• Stratégie de chunking : Un mauvais découpage peut séparer une idée de son contexte, par exemple une définition dans un paragraphe et sa limite dans le suivant.
• Modèle d’embeddings : Les embeddings compressent le sens dans des vecteurs, mais cette représentation peut rater une nuance importante.
• Base vectorielle : Elle doit être créée, mise à jour, sauvegardée et parfois resynchronisée avec les documents source.
• Recherche et classement : Une recherche vectorielle peut récupérer des passages proches en apparence, mais oublier le passage vraiment utile.
• Coût et dépendance : Les embeddings ajoutent un coût, une latence et souvent une dépendance à une API externe.

Pour une base personnelle de 50 000 à 100 000 mots, il est souvent possible de transmettre directement le contenu à un modèle à long contexte. Dans ce cas, le modèle lit toute la matière disponible au lieu de dépendre d’une étape de récupération qui peut se tromper. Un système RAG imposerait alors une chaîne technique plus lourde pour un gain parfois faible.

Il ne faut pas en déduire que le texte intégral coûte toujours moins cher. Le coût dépend du modèle utilisé, du prix des tokens, de la fréquence des requêtes et de la taille exacte du corpus. Mais pour une base limitée, la simplicité opérationnelle compte beaucoup.

Cette simplicité dépend toutefois d’un point clé : la capacité réelle du modèle à exploiter correctement un long contexte.

Pourquoi Claude est adapté à ce cas ?

Claude est adapté à ce pattern parce que certains modèles de la famille Claude acceptent de très longues fenêtres de contexte, jusqu’à 200 000 tokens selon la documentation Anthropic. Dans un usage type “LLM Wiki” popularisé par Andrej Karpathy, cette propriété change beaucoup de choses : le modèle peut lire une grande partie de votre base personnelle avant de répondre.

La fenêtre de contexte désigne la quantité maximale de texte que le modèle peut traiter dans une requête, entrée et sortie comprises selon les modèles. Un token est une unité de texte utilisée par le modèle, souvent plus courte qu’un mot. En anglais, 100 000 tokens représentent environ 75 000 mots à titre indicatif, mais le ratio varie selon la langue, la ponctuation, le code et le contenu.

Cette capacité modifie l’architecture. Quand toute votre base personnelle tient dans le contexte, il devient possible de remplacer le couple recherche vectorielle plus génération, souvent appelé RAG pour Retrieval-Augmented Generation, par un seul appel au modèle. Le modèle voit alors vos notes anciennes, vos définitions, vos décisions passées et vos contradictions éventuelles en même temps, sans dépendre d’un moteur de recherche sémantique qui peut oublier un document important.

Cette simplicité ne supprime pas les limites. Il existe un phénomène appelé lost in the middle : certains modèles exploitent moins bien les informations placées au milieu d’un très long contexte. L’étude “Lost in the Middle” de Liu et al., publiée en 2023, montre que les performances peuvent varier selon la position de l’information dans le contexte. Autrement dit, une grande fenêtre ne suffit pas ; il faut aussi une bonne capacité d’attention et de raisonnement sur contexte long.

Pour obtenir de meilleurs résultats, quelques règles pratiques aident beaucoup :

• Placer un sommaire au début du corpus.
• Ajouter des titres explicites dans chaque fichier.
• Regrouper les documents par thème.
• Éviter les doublons et les notes obsolètes.
• Maintenir un fichier index avec les sources importantes.
• Demander au modèle de citer les fichiers ou sections utilisés quand c’est possible.

Les conditions de réussite restent simples, mais elles doivent être respectées.

Condition	Pourquoi c’est important
Corpus de taille modérée	La base doit tenir dans la fenêtre de contexte disponible.
Fichiers propres	Le modèle raisonne mieux sur des informations cohérentes.
Contexte long	Les notes utiles peuvent être lues en une seule requête.
Structure claire	Les titres, thèmes et index réduisent le risque d’oubli.
Contrôle humain	Les réponses doivent rester vérifiées, surtout sur les décisions importantes.

Quand faut-il revenir au RAG ?

Il faut revenir au RAG lorsque le corpus devient trop volumineux, trop dynamique ou trop distribué pour être chargé intégralement dans le contexte du modèle.

Le Karpathy LLM Wiki pattern fonctionne très bien tant que votre base de connaissance reste simple : quelques fichiers texte ou Markdown, une structure lisible, peu de mises à jour, peu de droits d’accès à gérer. La fenêtre de contexte, c’est la quantité maximale de texte qu’un modèle peut lire en une seule requête. Même avec des modèles capables d’accepter de très longs contextes, envoyer des centaines de milliers de mots à chaque question coûte cher, augmente la latence et finit souvent par dégrader la précision.

Ses limites arrivent vite dans les environnements d’entreprise :

• Coût élevé des très longues requêtes, car la facturation dépend souvent du nombre de tokens, c’est-à-dire des morceaux de texte traités par le modèle.
• Latence plus forte, puisque le modèle doit relire un gros volume de contenu à chaque appel.
• Limite de contexte, même si elle recule avec les nouveaux modèles.
• Redondance entre fichiers, qui ajoute du bruit et peut produire des réponses contradictoires.
• Difficulté à traiter des millions de mots de façon fiable.
• Besoin d’autorisations fines selon les équipes, les clients ou les rôles.
• Données métiers stockées dans plusieurs systèmes : CRM, tickets, intranet, catalogue, logs, bases documentaires.
• Mises à jour très fréquentes, qui rendent le wiki local difficile à maintenir.

Le RAG, pour Retrieval-Augmented Generation, consiste à rechercher d’abord les passages utiles, puis à les fournir au modèle pour générer la réponse. Il reste pertinent pour la documentation produit massive, le support client, les bases juridiques, les intranets, les tickets, les CRM, les catalogues, les logs ou les politiques internes. Dans ces cas, la récupération ciblée évite d’envoyer tout le corpus à chaque question et permet de filtrer les résultats selon les droits d’accès.

La règle de décision est simple. Si la base tient dans la fenêtre de contexte, évolue lentement et appartient à une personne ou une petite équipe, je privilégie le wiki texte brut. Si elle dépasse largement cette fenêtre, change souvent, nécessite des permissions ou demande une recherche à grande échelle, j’envisage le RAG.

La meilleure approche reste progressive. Commencez avec un dossier Markdown, mesurez la taille en mots ou en tokens, testez plusieurs questions réelles, puis vérifiez la qualité des réponses. Passez au RAG seulement quand le besoin est démontré. Le bon choix business, c’est de ne pas industrialiser trop tôt une architecture inutile.

Situation	Approche recommandée	Raison
Base courte, stable, détenue par une petite équipe.	Wiki texte brut.	Simple, rapide, peu coûteux à maintenir.
Corpus massif ou supérieur à la fenêtre de contexte.	RAG.	Recherche ciblée au lieu d’envoyer tout le contenu.
Données avec permissions, sources multiples ou mises à jour fréquentes.	RAG.	Filtrage par droits, indexation et synchronisation plus adaptées.

Alors, faut-il vraiment simplifier votre base de connaissance ?

Le Karpathy LLM Wiki pattern rappelle une chose utile : la meilleure architecture est parfois un dossier de fichiers propres. Pour une base personnelle de taille raisonnable, le texte brut ou Markdown, chargé dans un LLM à long contexte comme Claude, évite beaucoup de complexité : embeddings, base vectorielle, chunking et récupération. Le RAG garde sa place dès que le corpus devient massif, dynamique ou soumis à des droits d’accès. Mon conseil : commencez simple, structurez vos notes, testez sur vos vrais usages, puis complexifiez seulement si nécessaire. Le bénéfice pour vous : une connaissance plus durable, exploitable et moins dépendante des outils.

FAQ

• Qu’est-ce que le Karpathy LLM Wiki pattern ?
  C’est une méthode qui consiste à conserver une base de connaissance personnelle en fichiers texte ou Markdown, puis à fournir tout ce contenu à un LLM disposant d’une longue fenêtre de contexte. L’objectif est de capitaliser vos recherches sans construire une architecture RAG complexe.
• Pourquoi utiliser du Markdown plutôt qu’une application de notes ?
  Le Markdown reste lisible sans outil propriétaire, facile à sauvegarder, versionner et envoyer à un modèle IA. Une application de notes peut être pratique, mais elle ajoute souvent une dépendance à un format, une interface ou un export.
• Le Karpathy LLM Wiki pattern remplace-t-il le RAG ?
  Il peut remplacer le RAG pour une base personnelle de taille modérée. En revanche, le RAG reste pertinent pour les très grands corpus, les bases d’entreprise, les contenus très dynamiques ou les systèmes avec gestion fine des droits d’accès.
• Pourquoi Claude est souvent cité pour cette approche ?
  Claude est souvent cité parce que certains modèles Claude acceptent de longues fenêtres de contexte, jusqu’à 200 000 tokens selon Anthropic. Cela permet de transmettre une grande quantité de notes dans une seule requête, à condition que le corpus reste bien structuré.
• Quelle taille de base de connaissance peut-on gérer ainsi ?
  Une base personnelle de 50 000 à 100 000 mots peut souvent entrer dans une fenêtre de contexte longue, selon le modèle et la langue. Au-delà, surtout avec des millions de mots, il faut envisager une approche RAG ou hybride.

 

 

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 dans les process business et le SEO/GEO. J’ai travaillé pour 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 vos données, vos automatisations ou vos usages IA sans ajouter de complexité inutile, contactez-moi.