Six mois avec un LLM wiki : ce que les tutos sur Karpathy ne disent pas

01Ce que j’ai construit, concrètement

Karpathy a décrit le pattern dans un gist, pas dans un produit. Trois couches, trois opérations, volontairement minimal.

Les trois couches : des sources brutes immuables (articles, PDF, notes, transcripts, qu’on ne modifie jamais), un wiki markdown écrit et tenu par le modèle, une page par concept, et un schéma, le fichier de consignes qui dit au modèle comment écrire. Chez moi, un CLAUDE.md.

Les trois opérations : ingest, quand je balance une source et que le modèle la compile dans le wiki. Query, quand il répond depuis le wiki plutôt que de relire les sources. Lint, la passe de nettoyage des pages mortes, des doublons et des contradictions.

Rien de tout ça n’a coûté cher à monter. Un dossier, git, le modèle que j’utilise déjà. C’est pour ça que le pattern a autant circulé : la barrière est basse. Trop basse, j’y reviens. Volume réel : 97 pages, six mois d’usage quotidien. Un outil de travail, pas un labo de recherche.

02Le concept qui compte : compiler la connaissance, pas la rechercher

Si vous ne retenez qu’une chose, prenez celle-là.

Dans un RAG, vous retrouvez l’information à chaque question : vous découpez vos documents, vous les mettez dans un index vectoriel, et à chaque requête vous allez chercher les passages qui ressemblent le plus à la question. Le modèle lit et répond. La connaissance n’est jamais écrite, elle est recalculée à la volée, requête après requête.

Le LLM wiki fait l’inverse. La compilation de connaissance, au sens de Karpathy : le modèle transforme les sources en pages une fois, puis garde ces pages à jour. La formule du gist est limpide : la connaissance est compilée une fois puis maintenue à jour, plutôt que dérivée de nouveau à chaque question. Le tweet d’origine le disait plus sèchement : arrêtez de faire relire vos documents au modèle, faites-lui les compiler.

L’analogie utile est celle du source et du binaire : on compile une fois, on exécute autant de fois qu’on veut. Sauf qu’un binaire ne se réécrit pas tout seul. Un wiki, si. Vous avez un organisme qui se retouche. C’est sa force, et c’est aussi sa faiblesse.

03Pourquoi ça marche là où un RAG classique déçoit

J’ai utilisé les deux, et le RAG m’a rendu des services. Mais il a une limite que le wiki a fait tomber.

Un RAG vous rend des passages similaires. Le wiki vous rend une page écrite. La différence paraît cosmétique, elle ne l’est pas. Pour une relance de facture impayée, un RAG me sort les trois ou quatre endroits où mes documents en parlent, à moi de recoller les morceaux. Le wiki me sort une page unique, déjà synthétisée, qui dit ce qu’on fait, dans quel ordre, avec quelles exceptions. Quelqu’un a déjà digéré les sources. Parfois moi. Souvent le modèle.

Derrière, une ligne de partage que peu d’articles expliquent. La similarité sémantique, c’est l’index vectoriel : il rapproche des textes qui se ressemblent. La provenance, c’est le wiki : il relie des faits par des liens explicites que quelqu’un a posés. Un lien n’est pas une ressemblance, c’est une affirmation. L’index vectoriel ne sait pas dire ça. Le graphe de wikilinks, si. D’où le choix de certaines implémentations : le plugin Obsidian du pattern n’utilise ni découpage, ni embeddings, ni base vectorielle, il navigue dans le graphe de vos liens. Ça paraît fou quand on a l’habitude du RAG. Ça marche très bien sur quelques centaines de pages.

04Les limites que personne n’écrit

Voilà le cœur. Tout ce qui suit, je l’ai payé. Personne ne l’écrit, parce que les tutos s’arrêtent au moment où la démo marche.

Le coût ne disparaît pas, il se déplace

C’est le mensonge le plus répandu sur le pattern : on lit partout que le wiki économise des tokens. Vrai à la requête, faux au global. Une analyse technique le dit mieux que moi : le wiki ne supprime pas la facture, il la déplace vers la compilation. Et un piège que je n’avais pas vu venir : une fois le wiki gros, l’index qui sert à s’y repérer devient un objet lourd, qui monte dans les dizaines de milliers de tokens. Vous le portez à chaque session, même les jours où vous ne touchez à rien. La dépense n’est pas supprimée, elle est rendue discrète, et invisible dans les démos.

La sur-compression à l’ingest (et son cousin, le mauvais tri)

Le modèle qui compile est un résumeur. Et un résumeur, ça jette. C’est sa définition.

Il y a un papier qui quantifie ce gâchis, et c’est une claque : les faits critiques ressortent avec des scores autour de 2,14 à 2,32 là où le contexte brut, sans compilation, score 3,47. Le modèle ne se trompe pas visiblement, il sur-compresse. Il juge un détail secondaire, le tait, et ne vous prévient jamais. Le détail perdu est souvent celui qui comptait. J’ai retrouvé une page propre, lisible, convaincante et fausse, parce qu’il manquait la seule phrase qui disait que ça ne s’appliquait pas. Le wiki ne vous alerte pas sur ce qu’il a oublié de garder.

Et le principe « sources immuables » a un angle mort jumeau : il ne dit rien du tri. Un wiki compile ce que vous lui donnez. Une source approximative, un article à moitié faux, une note écrite un soir de fatigue : tout ça devient de la connaissance compilée, propre, bien rangée et durable. La sur-compression resserre l’idée fausse et lui donne une apparence solide. Le filtre humain en amont décide de la qualité du wiki, et cet amont n’est jamais montré. Les démos ingèrent des PDF bien choisis.

La boucle épistémique fermée

Le gist recommande une chose que je ne fais presque plus : filer les bonnes réponses dans le wiki. En théorie, du bonus. En pratique, c’est là que le système se referme. Une page écrite à partir d’une page écrite à partir d’une page. Chaque passe est lossy, tasse un peu plus, et aucune ne signale d’erreur. C’est ça, la boucle épistémique fermée : plus rien ne remonte à la source, tout remonte à une reformulation antérieure. Vous croyez lire un fait. Vous lisez la dernière impression d’un fait.

Ce qui me gêne, c’est que le gist vous y pousse et que la vulgarisation n’en parle jamais. J’ai tranché : ce qui entre dans mon wiki vient d’une source brute, pas d’une réponse de query. Moins pratique, un peu moins magique. La seule façon que j’ai trouvée de garder un ancrage.

La maintenance du schéma

Tous les guides disent la même chose : copiez le schéma et laissez l’IA faire. La charge réelle n’est jamais documentée. Et elle existe.

Le fichier de consignes ne se maintient pas tout seul. Quand une notion mérite sa propre page, quand elle doit rester un paragraphe : c’est du jugement humain. Si vous ne tranchez pas, le modèle tranche mal. Il crée trente pages d’une ligne, duplique un concept sous deux noms. J’y passe du temps chaque semaine. Pas des heures, mais chaque semaine, comme on tond une pelouse qui repousse. C’est le vrai coût caché, celui qu’aucun tuto ne met dans le tableau de départ.

Le wiki, c’est aussi votre point de fuite

Dernier angle. Un wiki, ce sont des fichiers markdown : du texte en clair, lisible par tous ceux qui ont accès au dossier. Et lu par un agent, souvent avec des droits larges. Quand on construit ça vite, on y met un peu de tout : une clé d’accès notée pour ne pas la perdre, une information interne. Le sujet est presque absent de la littérature, alors que la mémoire du système est aussi son point de fuite. Chez moi, la règle est bête : rien de sensible dans le wiki, sans exception. C’est la seule qui tienne sur la durée.

05Ce que ça donne passé l’échelle

Les analyses anglophones s’accordent sur des seuils : le pattern se tient jusqu’à environ 100 articles, quelques centaines de pages. Un retour cite le cap des 500 pages comme la zone où l’index cesse d’être une navigation fiable, la borne des 100 venant d’un template très utilisé.

Je suis à 97 pages, juste avant le seuil chaud. J’observe déjà la dérive : l’index grossit plus vite que le nombre de pages, le modèle trouve encore, mais un peu plus à côté. Rien de spectaculaire, et jamais visible dans une démo de dix minutes. Ma conviction, non prouvée : ces seuils ne sont pas techniques, ils sont d’entretien. Le wiki ne casse pas parce qu’il est trop gros, mais parce que personne ne fait le ménage assez vite.

06Ce que j’en garde, et ce que je ne referais pas

Là où c’est imbattable : une base de connaissance qui vit, avec des questions récurrentes et des liens entre les idées. Le wiki est le seul système que je connaisse où la connaissance s’améliore en s’accumulant. Un RAG se contente d’être interrogé. Le wiki se bonifie.

Ce que je ne referais pas : le lancer pour un usage jetable. Compiler a un coût en amont, qui ne s’amortit que si vous revenez dessus longtemps. Pour trois questions par mois, un RAG ou une simple recherche plein texte font mieux pour moins cher. Et je ne le laisserais jamais tourner sans revue humaine : le moment où on lâche la main, la boucle se referme.

Le pattern est une très bonne idée. Ce n’est pas un produit, ni un raccourci. C’est un élevage. Ça marche pour moi, avec ce volume et ce rythme. Ça ne veut pas dire que ça marchera pour vous, et méfiez-vous de quiconque vous dit le contraire après une démo de dix minutes.

FAQ

Qu’est-ce qu’un LLM wiki, en une phrase ?

Une base de connaissance en markdown que le modèle compile et tient à jour à partir de sources brutes, au lieu de rechercher dans les sources à chaque question.

LLM wiki ou RAG, lequel choisir ?

Le RAG pour retrouver des passages à la volée, à coût maîtrisé. Le wiki quand la connaissance doit s’accumuler et se relier dans le temps. Les deux ne s’excluent pas.

Combien de pages un LLM wiki peut-il tenir ?

La zone confortable se situe autour de 100 articles, quelques centaines de pages. Au-delà, l’index devient moins fiable. Le vrai facteur, plus que la taille, c’est la fréquence de l’entretien.