Accueil › Blog › LLM Wiki

📚 Knowledge Engineering

LLM Wiki : quand l'IA construit et maintient sa propre base de connaissances

L'évolution au-delà du RAG — guide complet avec démo interactive

Par l'équipe OutilsIA • avril 2026 • 18 min de lecture

« Le RAG, c'est demander à un bibliothécaire de chercher un passage dans 10 000 livres. Le LLM Wiki, c'est avoir un encyclopédiste qui a déjà lu tous les livres, structuré les connaissances, et vous donne la réponse depuis sa tête — avec les sources et les liens. »

Vous utilisez le RAG pour connecter vos LLM à vos documents ? Bien. Mais il y a un problème fondamental : le RAG cherche dans des documents bruts, non structurés. Il ne comprend pas les relations entre les concepts. Il répète les mêmes erreurs de récupération à chaque requête. Et il n'apprend jamais de ses erreurs.

Le LLM Wiki — un pattern décrit par Karpathy et formalisé par Yuchen Jin — renverse la logique. Au lieu de chercher à chaque question, le LLM compile, structure, cross-référence et maintient une base de connaissances vivante. Les humains curent et supervisent. Les agents consomment cette wiki comme contexte structuré.

C'est la chaîne d'évolution naturelle : RAG classique → Self-RAG → Agentic RAG → LLM Wiki. Dans ce guide complet, nous décortiquons le fonctionnement, les avantages, et comment construire votre propre LLM Wiki en local.

🚫 Le problème fondamental du RAG

Le RAG (Retrieval-Augmented Generation) est devenu le pattern standard pour connecter un LLM à des données privées. Mais après des mois d'utilisation en production, les limites deviennent évidentes :

🔎 Recherche dans le brut

Le RAG cherche dans des documents bruts, non structurés. Un PDF de 200 pages est découpé en chunks sans comprendre la logique interne du document. Les relations entre concepts sont perdues.

🔄 Pas de mémoire

Même question = même recherche vectorielle. Si le retriever a renvoyé un mauvais chunk hier, il renverra le même mauvais chunk aujourd'hui. Zéro apprentissage.

🔀 Chunks isolés

Chaque chunk est un îlot. Le RAG ne sait pas que le concept A du document 1 est lié au concept B du document 7. Pas de cross-référencement.

🕐 Mise à jour coûteuse

Nouveau document ? Il faut re-indexer, re-vectoriser, espérer que les embeddings captent les nuances. Processus manuel, fragile, sans vérification de cohérence.

💡 L'analogie

Le RAG, c'est comme avoir une bibliothèque immense mais sans catalogue, sans index, sans liens entre les ouvrages. Pour chaque question, un robot parcourt les étagères, attrape quelques pages qui semblent correspondre, et les donne au LLM en espérant que ça suffise.

Le LLM Wiki, c'est avoir un encyclopédiste qui a déjà lu tous les livres, rédigé des fiches structurées, tissé des liens entre les sujets, et met à jour ses notes à chaque nouveau livre.

📚 Qu'est-ce que le LLM Wiki ?

Le pattern LLM Wiki, décrit par Karpathy et formalisé par Yuchen Jin, transforme le rôle du LLM. Au lieu d'être un moteur de recherche (RAG), il devient un ingénieur de la connaissance qui construit et maintient une base structurée.

📋

Compiler

Lire et synthétiser des sources multiples en connaissances unifiées

📑

Structurer

Organiser en entrées wiki cohérentes avec métadonnées

🔗

Cross-référencer

Tisser des liens entre concepts et détecter les relations

🔄

Maintenir

Mettre à jour automatiquement avec chaque nouvelle source

🚀 Architecture du LLM Wiki

📃

Sources brutes

PDF, emails, APIs, bases de données, articles

→

🤖

Agent Wiki LLM

Lecture, extraction, structuration, cross-réf.

→

📚

Wiki vivante

Entrées structurées, liens, métadonnées

→

⚡

Agents consommateurs

Chatbot, analyse, décision, génération

Les humains curent, supervisent et font la réflexion de haut niveau

💡 Le principe clé

Au lieu de chercher à chaque requête dans des documents bruts (RAG), le LLM pré-compile la connaissance en une wiki structurée. Les agents qui répondent aux questions consomment cette wiki comme contexte — pas des chunks bruts. Résultat : réponses plus précises, plus cohérentes, plus rapides.

📈 La chaîne d'évolution : du RAG au LLM Wiki

Le LLM Wiki n'est pas apparu de nulle part. C'est l'aboutissement logique d'une évolution en 4 étapes. Chaque génération résout les problèmes de la précédente :

2023

RAG classique

2024

Self-RAG

2025

Agentic RAG

2026

LLM Wiki

Caractéristique	RAG classique	Self-RAG	Agentic RAG	LLM Wiki
Récupération	Recherche statique	Auto-évaluée	Raisonnement multi-étapes	Connaissance pré-compilée
Connaissance	Chunks bruts	Chunks bruts	Chunks + outils	Structurée, cross-référencée
Mises à jour	Re-indexation manuelle	Manuelle	Manuelle	Automatique par agent
Relations	✗	✗	Partiel	✓ Complet
Qualité réponses	~73%	~79%	~87%	92%+

Pour en savoir plus sur les étapes précédentes, consultez nos guides détaillés : RAG local avec Ollama, Agentic RAG, et meilleur modèle pour le RAG.

⚙️ Comment fonctionne le LLM Wiki — techniquement

Le processus se décompose en 6 étapes. Chacune peut être implémentée avec un LLM local via Ollama :

Lecture des sources

Le LLM lit les documents sources : PDF, pages web, bases de données, APIs. Pas de chunking aveugle — le modèle lit le document en entier ou par sections logiques.

# Étape 1 : Lecture des sources

import

ollama

def

read_source(file_path):
with open(file_path, 'r') as f:
content = f.read()

response = ollama.chat(
model='llama3.1:8b',
messages=[{
'role': 'system',
'content': 'Tu es un knowledge engineer. Extrais les concepts clés, entités et relations de ce document.'
}, {
'role': 'user',
'content': content
}]
)
return response['message']['content']

Extraction d'entités et relations

Le LLM identifie les concepts clés, les entités nommées, et surtout les relations entre eux. C'est la différence fondamentale avec le RAG : on ne stocke pas du texte, on stocke de la connaissance structurée.

# Étape 2 : Extraction structurée (JSON)

import

json

extraction_prompt = """
Extrais les informations suivantes en JSON :
{
"concepts": ["concept1", "concept2"],
"entities": [{"name": "X", "type": "person/org/tech"}],
"relations": [{"from": "A", "to": "B", "type": "uses/extends/contradicts"}],
"facts": ["fait vérifiable 1", "fait vérifiable 2"]
}"""

Création d'entrées wiki structurées

Chaque concept devient une entrée wiki en Markdown ou JSON, avec un format standard : titre, définition, sources, relations, date de dernière mise à jour.

# Étape 3 : Génération d'entrée wiki

def create_wiki_entry(concept, extracted_data):
entry = {
"title": concept,
"summary": "", # LLM génère
"details": "", # LLM génère
"related_to": [], # liens vers autres entrées
"sources": [], # documents sources
"created_at": datetime.now().isoformat(),
"updated_at": datetime.now().isoformat(),
"confidence": 0.0 # score de confiance
}
return entry

Cross-référencement automatique

Le LLM analyse l'ensemble des entrées et crée des liens : « Concept A est utilisé par Concept B », « Concept C contredit Concept D ». C'est là que la magie opère.

# Étape 4 : Cross-référencement

def crossreference(wiki_entries):
for entry in wiki_entries:
other_titles = [e['title'] for e in wiki_entries if e != entry]
prompt = f"Entrée: {entry['title']}\n"
prompt += f"Autres entrées: {other_titles}\n"
prompt += "Quels liens existent ? Format: [{from, to, relation}]"
links = llm_call(prompt)
entry['related_to'].extend(links)

Mises à jour périodiques

Quand une nouvelle source arrive, l'agent ne re-construit pas tout. Il lit la source, identifie les entrées concernées, et les met à jour ou en crée de nouvelles. Un cron job peut automatiser tout le processus.

# Étape 5 : Mise à jour incrémentale

def update_wiki(new_source, wiki):
extracted = extract_concepts(new_source)
for concept in extracted:
if concept in wiki:
# Mise à jour : fusionner nouvelles infos
wiki[concept] = merge_entry(wiki[concept], extracted[concept])
else:
# Nouvelle entrée
wiki[concept] = create_wiki_entry(concept, extracted[concept])
crossreference(wiki) # Re-tisser les liens

Agents consomment la wiki

Les agents qui répondent aux questions ne font plus de recherche vectorielle. Ils reçoivent les entrées wiki pertinentes comme contexte — structurées, cross-référencées, à jour.

# Étape 6 : Agent consommateur

def answer_question(question, wiki):
# Trouver les entrées pertinentes
relevant = find_relevant_entries(question, wiki)
# Inclure aussi les cross-refs
context = expand_with_crossrefs(relevant, wiki)
# Répondre avec le contexte structuré
return llm_call(question, context=context)

🎮 Démo interactive : le LLM Wiki en action

Voyez le processus de construction d'une wiki en temps réel. Cliquez sur le bouton pour lancer la simulation et observez l'agent compiler, structurer et cross-référencer.

Documents traités

0/15

Entrées wiki

Cross-références

Mises à jour

Progression

📃 Sources brutes

🤖 Agent Wiki en action

$ llm-wiki --build --sources ./docs/

📚 Wiki vivante

🎯 Applications concrètes du LLM Wiki

Le pattern LLM Wiki n'est pas théorique. Voici comment il est déjà utilisé en production dans différents domaines :

📈 Trading / Finance

Le LLM construit une wiki de stratégies de trading avec forces, faiblesses, corrélations et contextes de marché. Avant de muter une stratégie, l'agent consulte la wiki pour savoir ce qui a fonctionné dans des conditions similaires.

Strategy Arena utilise ce pattern pour documenter automatiquement des milliers de stratégies de trading — chaque stratégie a une fiche wiki avec ses métriques, ses forces, ses faiblesses, et ses liens avec d'autres stratégies apparentées.

⚖️ Juridique

Le LLM maintient une wiki de jurisprudence, cross-référencée par thème, juridiction, issue et date. Quand un nouveau jugement tombe, l'agent met à jour les entrées concernées et signale les contradictions avec les décisions antérieures. Un avocat peut interroger la wiki au lieu de chercher dans des milliers de pages.

🩺 Médical

Wiki vivante de symptômes, traitements, interactions médicamenteuses. Chaque nouveau papier de recherche est intégré automatiquement. Les cross-références révèlent des relations que le RAG simple ne détecterait jamais : « le médicament A, utilisé pour la pathologie B, a des interactions avec C, découvertes dans l'étude D ».

💻 Développement logiciel

Auto-documentation de codebase : le LLM lit le code, génère des entrées wiki pour chaque module, fonction et API, avec des liens entre les composants. Quand le code change, la documentation se met à jour automatiquement. Fini les README obsolètes. Consultez également notre guide Karpathy AutoResearch pour l'optimisation automatique de code.

🔬 Recherche scientifique

Synthétiser 200 articles de recherche en une wiki structurée : méthodes, résultats, contradictions, consensus, questions ouvertes. Un chercheur obtient en 10 minutes ce qui prendrait des semaines de revue de littérature.

🔗 LLM Wiki vs base de données vectorielle

Le LLM Wiki ne remplace pas forcément la base vectorielle — il la complète et la surpasse dans certains cas. Voici la différence fondamentale :

🔌 Base vectorielle (ChromaDB, Pinecone...)

« Trouve-moi les chunks similaires à cette requête »

• Recherche syntaxique (similarité vectorielle)
• Renvoie des chunks bruts sans contexte
• Pas de compréhension des relations
• Rapide et scalable
• Idéal pour les grandes collections non structurées

📚 LLM Wiki

« Voici ce que je sais sur X, lié à Y, mis à jour suite à Z »

• Connaissance sémantique (compréhension)
• Entrées structurées avec métadonnées
• Cross-références et relations explicites
• Plus lent à construire
• Idéal pour les domaines complexes et évolutifs

💡 La combinaison gagnante

Les deux approches se complètent parfaitement. Les entrées de la wiki peuvent être stockées dans une base vectorielle pour la recherche rapide. Le meilleur des deux mondes : la vitesse de la recherche vectorielle + la profondeur de la connaissance structurée. Consultez notre guide sur le meilleur modèle pour le RAG pour choisir votre socle.

🏠 Construire votre LLM Wiki en local

Tout le processus peut tourner 100% en local avec Ollama, Python et des fichiers Markdown. Zéro cloud, zéro coût API, vos données restent privées.

Prérequis

📦 Logiciel

• Python 3.10+
• Ollama installé et fonctionnel
• Modèle LLM : Llama 3.1 8B minimum
• pip install ollama pyyaml

📁 Structure

llm-wiki/
├─ sources/ # documents bruts
├─ wiki/ # entrées wiki (MD/JSON)
├─ wiki_builder.py # agent constructeur
├─ wiki_updater.py # agent de mise à jour
└─ wiki_query.py # interface de requête

Script complet : wiki_builder.py

#!/usr/bin/env python3

# wiki_builder.py — Construit une LLM Wiki à partir de sources

import os, json, glob

from datetime import datetime

import ollama

WIKI_DIR = "./wiki"

SOURCE_DIR = "./sources"

MODEL = "llama3.1:8b"

def extract_concepts(text):

"""Extraire concepts et relations d'un texte."""

response = ollama.chat(model=MODEL, messages=[

{"role": "system", "content": """Tu es un knowledge engineer.

Extrais les concepts clés en JSON :

{"concepts": [{"name": "X", "summary": "...",

"relations": [{"target": "Y", "type": "..."}]}]}"""},

{"role": "user", "content": text}

], format="json")

return json.loads(response["message"]["content"])

def build_wiki():

os.makedirs(WIKI_DIR, exist_ok=True)

for src in glob.glob(f"{SOURCE_DIR}/*"):

with open(src) as f:

data = extract_concepts(f.read())

for concept in data["concepts"]:

save_entry(concept, src)

crossreference_all()

def save_entry(concept, source):

slug = concept["name"].lower().replace(" ", "-")

path = f"{WIKI_DIR}/{slug}.json"

entry = {

"title": concept["name"],

"summary": concept["summary"],

"relations": concept.get("relations", []),

"sources": [source],

"updated_at": datetime.now().isoformat()

}

with open(path, "w") as f:

json.dump(entry, f, indent=2)

if __name__ == "__main__":

build_wiki()

Ce script utilise Ollama en local. Aucune donnée ne quitte votre machine.

Automatisation avec cron

Programmez la mise à jour automatique de votre wiki chaque nuit :

# crontab -e

# Mise à jour de la wiki chaque nuit à 3h

0 3 * * * cd /home/user/llm-wiki && python wiki_updater.py

# Cross-référencement complet chaque dimanche

0 4 * * 0 cd /home/user/llm-wiki && python wiki_builder.py --crossref-only

Votre wiki évolue pendant que vous dormez. Consultez notre guide Open WebUI + Ollama pour une interface graphique complète.

💻 Matériel recommandé

Le LLM Wiki est plus exigeant que le RAG classique : le modèle doit comprendre, structurer et raisonner, pas juste générer du texte. Un modèle plus gros produit de meilleures wikis. Vérifiez si votre PC actuel peut faire tourner l'IA locale.

Niveau	RAM	GPU	Modèle LLM	Qualité wiki	Prix GPU
Minimum	16 Go	N'importe quel GPU	Llama 3.1 8B	Correcte	~280 €
Recommandé	32 Go	RTX 4070 Ti Super (16 Go)	Mistral 22B, Llama 3.1 13B	Bonne	~750 €
Optimal	64 Go	RTX 4090 (24 Go)	Llama 3.1 70B (Q4), Qwen 72B	Excellente	~1800 €
Pro	128 Go	RTX 5090 (32 Go)	Llama 3.1 70B, Mixtral 8x22B	Maximale	~2200 €

Meilleur rapport qualité/prix

NVIDIA RTX 4070 Ti Super 16 Go

16 Go VRAM — idéale pour des modèles 13B-22B qui produisent des wikis de bonne qualité.

Voir sur Amazon →

Performance maximale

NVIDIA RTX 4090 24 Go

24 Go VRAM — modèles 70B pour la meilleure qualité de structuration et cross-référencement.

Voir sur Amazon →

💡 Pourquoi un modèle plus gros ? Contrairement au RAG où le LLM ne fait que reformuler des chunks, le LLM Wiki demande au modèle de comprendre, raisonner et structurer. Un modèle 70B produit des wikis significativement plus cohérentes qu'un 7B. C'est l'investissement le plus impactant.

🚀 Conclusion : l'avenir de la gestion des connaissances

Le LLM Wiki représente un changement de paradigme. Nous passons d'un monde où l'IA cherche dans nos documents à un monde où l'IA comprend, organise et maintient notre connaissance.

Hier

RAG classique

« Cherche dans mes docs »

Aujourd'hui

Agentic RAG

« Raisonne sur mes docs »

Demain (maintenant)

LLM Wiki

« Organise et maintient ma connaissance »

Pour commencer dès aujourd'hui :

1. Installez Ollama et téléchargez un modèle (llama3.1:8b minimum)
2. Créez la structure de dossiers (sources/ et wiki/)
3. Lancez le script wiki_builder.py sur vos premiers documents
4. Configurez le cron pour les mises à jour automatiques
5. Explorez la wiki avec Open WebUI pour une interface graphique

Questions fréquentes

Le RAG cherche des chunks de texte brut dans une base vectorielle à chaque requête — c'est de la recherche syntaxique. Le LLM Wiki, lui, pré-compile la connaissance : le LLM lit les sources, extrait les concepts, les structure en entrées wiki avec des métadonnées et des cross-références, et maintient le tout à jour automatiquement. Les agents qui répondent aux questions consomment cette connaissance structurée au lieu de chunks bruts, ce qui améliore la qualité des réponses de 73% (RAG) à 92%+ (LLM Wiki).

Oui, c'est même l'approche recommandée pour les données sensibles. Avec Ollama et un modèle comme Llama 3.1 8B (minimum 16 Go de RAM), vous pouvez construire une wiki complète 100% en local. Pour de meilleure qualité, un modèle 13B-22B sur une RTX 4070 Ti Super est idéal. Aucune donnée ne quitte votre machine.

Pour la construction de wiki, la taille du modèle compte plus que pour le RAG classique, car le LLM doit comprendre, structurer et raisonner. En local : Llama 3.1 8B est le minimum, Mistral 22B offre un bon compromis, et Llama 3.1 70B (quantifié Q4) donne les meilleurs résultats sur une RTX 4090. En API : Claude ou GPT-4 produisent d'excellentes wikis. Consultez notre comparatif des meilleurs modèles.

Il n'y a pas de limite théorique — la wiki grandit incrémentalement. En pratique, avec un modèle 8B en local, vous pouvez traiter des centaines de documents et gérer des wikis de plusieurs milliers d'entrées. Le cross-référencement devient plus coûteux en calcul au-delà de 5 000 entrées, mais des optimisations (cross-ref par batch, par domaine) permettent de scaler. Strategy Arena maintient une wiki de milliers de stratégies en production.