Les wikis LLM sont trop complexes.

Les Wikis pour LLM sont trop complexes — J'ai remplacé le mien par un compilateur Python pur

Les grands modèles de langage (LLM) sont des outils puissants pour générer du texte, répondre à des questions et aider au codage. Mais depuis un an, une tendance curieuse a émergé : les développeurs se sont mis à construire des « wikis pour LLM » — des bases de connaissances massives et complexes conçues pour fournir du contexte aux modèles. Ces wikis impliquent souvent des bases de données vectorielles, des pipelines d'embedding, des piles de génération augmentée par récupération (RAG) et des clusters Kubernetes. L'ironie ? La majeure partie de cette complexité est inutile pour un usage personnel ou en petite équipe.

Je suis moi-même tombé dans le piège. Après avoir passé des semaines à configurer ChromaDB, à déployer un serveur FastAPI et à câbler LangChain, j'ai réalisé que mon installation était fragile, lente et disproportionnée par rapport à ce dont j'avais réellement besoin : un moyen simple de stocker et de récupérer des faits structurés pour un LLM lors de l'inférence. J'ai donc tout abandonné et construit un compilateur Python pur qui lit des fichiers Markdown plats et produit une base de connaissances légère et interrogeable. Pas de bases de données, pas d'embeddings, pas de Docker. Juste Python, un dossier de notes et quelques centaines de lignes de code.

Voici pourquoi les wikis pour LLM sont trop complexes, et comment remplacer le vôtre par une solution plus simple, plus rapide et plus maintenable.

Le problème des wikis pour LLM

Les wikis pour LLM promettent de résoudre un vrai problème : les LLM ont des fenêtres de contexte limitées et aucune mémoire intégrée pour vos données spécifiques. Vous construisez donc un système qui prétraite vos documents, les stocke sous forme de vecteurs et récupère les passages les plus pertinents lorsque vous posez une question. Cette approche fonctionne, mais elle introduit une complexité inutile pour la plupart des cas d'usage.

Pourquoi la plupart des équipes n'ont pas besoin de bases de données vectorielles

Les bases de données vectorielles comme Pinecone, Weaviate ou Qdrant sont conçues pour la recherche de similarité à grande échelle sur des millions de documents. Si vous gérez un chatbot de support client pour une entreprise mondiale, oui, vous en avez besoin. Mais pour un wiki personnel avec quelques centaines de notes, une base de données vectorielle revient à utiliser un train de marchandises pour transporter un sac à dos. La complexité de la configuration des embeddings, de la gestion des index et du réglage de la taille des passages dépasse souvent les bénéfices.

Les coûts cachés des pipelines RAG

La génération augmentée par récupération ajoute de la latence, des coûts et des points de défaillance. Chaque requête nécessite : 1. L'embedding de votre question 2. La recherche dans l'index vectoriel 3. La récupération des k meilleurs passages 4. Leur transmission au LLM avec votre prompt

Si une étape échoue (timeout réseau, erreur du modèle d'embedding), votre LLM n'obtient aucun contexte. Et si vos passages sont mal choisis, le LLM pourrait les ignorer complètement. J'ai vu des pipelines RAG où la seule étape de récupération prenait 2 à 3 secondes — inacceptable pour une utilisation interactive.

Quand la simplicité l'emporte

Pour la plupart des individus, des petites équipes ou des outils internes, le besoin réel est plus simple : donner au LLM un ensemble choisi de faits pertinents pour la tâche en cours. Vous n'avez pas besoin de recherche sémantique quand vous savez déjà ce que vous voulez demander. Vous avez besoin d'un moyen d'organiser vos connaissances pour que le LLM puisse y accéder sans système de récupération complexe.

Une approche plus simple : la compilation Python pur

Au lieu de construire un système de récupération, j'ai construit un compilateur. L'idée est simple : écrivez vos connaissances sous forme de fichiers Markdown structurés dans un dossier. Le compilateur lit tous les fichiers, extrait les sections et les métadonnées, et génère un seul fichier texte compressé que vous pouvez injecter directement dans un prompt LLM. Pas de bases de données, pas de modèles d'embedding, pas de services externes.

Comment ça fonctionne

Le compilateur fait quatre choses : 1. Il scanne un dossier à la recherche de fichiers `.md` 2. Il analyse chaque fichier en sections (en utilisant les titres comme clés) 3. Il combine le tout dans un format texte plat et compressé 4. Il produit un seul fichier qui tient dans la fenêtre de contexte de votre LLM

Vous pouvez ensuite ajouter ces connaissances compilées à vos prompts. Par exemple :

Vous êtes un assistant utile. Voici la base de connaissances pertinente :
--- DÉBUT DES CONNAISSANCES ---
[sortie compilée ici]
--- FIN DES CONNAISSANCES ---
Répondez à la question de l'utilisateur en vous basant uniquement sur ces connaissances.

Pourquoi ça fonctionne

Cette approche fonctionne parce que la plupart des wikis personnels sont suffisamment petits pour tenir dans une seule fenêtre de contexte de LLM. GPT-4 Turbo supporte 128 000 tokens — assez pour une base de connaissances de la taille d'un livre. Même avec des modèles plus petits, vous pouvez compresser agressivement : supprimez le formatage, raccourcissez les noms de variables et utilisez des abréviations. Le compromis est que vous perdez la recherche sémantique, mais pour des faits structurés (documentation d'API, notes de configuration, directives de projet), la récupération exacte par titre est souvent suffisante.

Prérequis

Avant de plonger dans le code, voici ce dont vous avez besoin :

• **Python 3.10+** (pour le pattern matching structurel et les indications de type)
• **Un dossier de fichiers Markdown** — vos notes, docs ou wiki existants
• **Aucune dépendance externe** — nous utilisons uniquement la bibliothèque standard

C'est tout. Pas de Docker, pas de bases de données, pas de services cloud.

Installation étape par étape

1. Créez la structure du projet

Créez d'abord un dossier pour votre compilateur :

mkdir ~/llm-compiler
cd ~/llm-compiler
mkdir connaissances

Placez vos fichiers Markdown dans le dossier `connaissances`. Par exemple, créez un fichier appelé `reference-api.md` :

# Référence API

## Authentification
Utilisez un jeton Bearer dans l'en-tête Authorization.

## Points d'accès
### GET /utilisateurs
Renvoie la liste des utilisateurs. Nécessite le rôle admin.

### POST /utilisateurs
Crée un nouvel utilisateur. Corps : { "nom": string, "email": string }

2. Écrivez le script du compilateur

Créez un fichier nommé `compiler_connaissances.py` :

#!/usr/bin/env python3
"""Compile un dossier de fichiers Markdown en une seule base de connaissances compressée."""

import argparse
import os
import re
from pathlib import Path
from typing import Dict, List

def analyser_fichier_markdown(chemin: Path) -> Dict[str, str]:
    """Analyse un fichier Markdown en sections indexées par titre."""
    with open(chemin, 'r', encoding='utf-8') as f:
        contenu = f.read()
    
    sections: Dict[str, str] = {}
    titre_courant = "GENERAL"
    lignes_courantes: List[str] = []
    
    for ligne in contenu.splitlines():
        correspondance_titre = re.match(r'^(#{1,6})\s+(.+)', ligne)
        if correspondance_titre:
            if lignes_courantes:
                sections[titre_courant] = '\n'.join(lignes_courantes).strip()
            titre_courant = correspondance_titre.group(2).strip()
            lignes_courantes = []
        else:
            # Ignorer les lignes vides au début d'une section
            if ligne.strip() or lignes_courantes:
                lignes_courantes.append(ligne)
    
    if lignes_courantes:
        sections[titre_courant] = '\n'.join(lignes_courantes).strip()
    
    return sections

def compiler_connaissances(dossier_connaissances: Path) -> str:
    """Compile tous les fichiers Markdown en une seule chaîne compressée."""
    parties_compilees: List[str] = []
    
    for fichier_md in sorted(dossier_connaissances.glob("*.md")):
        sections = analyser_fichier_markdown(fichier_md)
        nom_fichier = fichier_md.stem
        
        # Ajouter un en-tête de fichier
        parties_compilees.append(f"## FICHIER : {nom_fichier}")
        
        for titre, corps in sections.items():
            # Compresser : supprimer les espaces superflus, raccourcir les titres
            corps_compresse = re.sub(r'\s+', ' ', corps).strip()
            titre_court = titre.replace(' ', '_').lower()[:40]
            parties_compilees.append(f"[{titre_court}] {corps_compresse}")
    
    return '\n'.join(parties_compilees)

def main():
    analyseur = argparse.ArgumentParser(
        description="Compile une base de connaissances Markdown pour les prompts LLM"
    )
    analyseur.add_argument(
        "--entree", "-e",
        default="./connaissances",
        help="Dossier contenant les fichiers Markdown (défaut : ./connaissances)"
    )
    analyseur.add_argument(
        "--sortie", "-s",
        default=None,
        help="Chemin du fichier de sortie (défaut : affichage sur la sortie standard)"
    )
    args = analyseur.parse_args()
    
    dossier_connaissances = Path(args.entree)
    if not dossier_connaissances.exists():
        print(f"Erreur : Le dossier {dossier_connaissances} n'existe pas")
        return 1
    
    compile = compiler_connaissances(dossier_connaissances)
    
    if args.sortie:
        with open(args.sortie, 'w', encoding='utf-8') as f:
            f.write(compile)
        print(f"Connaissances compilées écrites dans {args.sortie}")
    else:
        print(compile)
    
    return 0

if __name__ == "__main__":
    exit(main())

3. Rendez-le exécutable

chmod +x compiler_connaissances.py

Exemples d'utilisation

Compilation de base

Exécutez le compilateur sur votre dossier de connaissances :

python compiler_connaissances.py --entree ./connaissances

Sortie :

## FICHIER : reference-api
[authentification] Utilisez un jeton Bearer dans l'en-tête Authorization.
[points_d_acces] ### GET /utilisateurs Renvoie la liste des utilisateurs. Nécessite le rôle admin. ### POST /utilisateurs Crée un nouvel utilisateur. Corps : { "nom": string, "email": string }

Sauvegarder dans un fichier pour réutilisation

python compiler_connaissances.py --entree ./connaissances --sortie kb_compilee.txt

Utiliser les connaissances compilées dans un prompt

Vous pouvez maintenant ajouter ce texte compilé à n'importe quel prompt LLM. Voici un exemple Python utilisant l'API OpenAI :

import openai

with open("kb_compilee.txt", "r") as f:
    base_connaissances = f.read()

prompt_systeme = f"""Vous êtes un assistant utile avec accès à une base de connaissances.
Utilisez les connaissances suivantes pour répondre aux questions. Si vous ne trouvez pas la réponse, dites-le.

--- DÉBUT DES CONNAISSANCES ---
{base_connaissances}
--- FIN DES CONNAISSANCES ---"""

reponse = openai.ChatCompletion.create(
    model="gpt-4-turbo",
    messages=[
        {"role": "system", "content": prompt_systeme},
        {"role": "user", "content": "Comment m'authentifier à l'API ?"}
    ]
)

print(reponse.choices[0].message.content)

Sortie attendue :

Pour vous authentifier à l'API, utilisez un jeton Bearer dans l'en-tête Authorization.

Avancé : Auto-compilation avant chaque session

Ajoutez ceci à votre configuration shell (`.bashrc` ou `.zshrc`) pour compiler automatiquement votre base de connaissances avant de démarrer une nouvelle session LLM :

alias compile-kb='python ~/llm-compiler/compiler_connaissances.py --entree ~/llm-compiler/connaissances --sortie ~/llm-compiler/kb_compilee.txt'

Exécutez ensuite `compile-kb` avant d'ouvrir votre interface LLM.

Quand cette approche montre ses limites

Aucune solution n'est parfaite. Ce compilateur Python pur a des limites :

• **Grandes bases de connaissances** — Si vous avez des dizaines de milliers de pages, vous dépasserez les limites de contexte. Dans ce cas, vous avez besoin d'un système de récupération.
• **Connaissances dynamiques** — Si vos connaissances changent fréquemment, vous devez recompiler. Pour une documentation statique, c'est acceptable.
• **Recherche sémantique** — Vous ne pouvez pas poser des questions floues comme « c'était quoi ce truc sur la limitation de débit ? » Vous devez connaître le titre de la section ou parcourir la sortie compilée.

Pour ces cas, envisagez des approches hybrides : utilisez ce compilateur pour vos connaissances de base stables, et ajoutez une recherche par mots-clés simple (avec `difflib` ou `re` de Python) pour la récupération de secours.

Conclusion

Les wikis pour LLM sont trop complexes pour la plupart des cas d'usage personnels ou en petite équipe. La complexité des bases de données vectorielles, des pipelines d'embedding et des piles RAG ajoute souvent plus de problèmes qu'elle n'en résout. En construisant un compilateur Python pur qui transforme vos notes Markdown en un format compressé prêt pour les prompts, vous gagnez :

• **Simplicité** — Aucune dépendance au-delà de la bibliothèque standard de Python
• **Vitesse** — La compilation prend des millisecondes, pas des secondes
• **Contrôle** — Vous savez exactement ce qui entre dans vos prompts
• **Maintenabilité** — Vos connaissances sont simplement des fichiers Markdown, faciles à éditer avec n'importe quel éditeur de texte

Cette approche ne remplacera pas les systèmes de gestion des connaissances à l'échelle des entreprises. Mais pour les individus, les petites équipes et tous ceux qui en ont assez de déboguer des conteneurs Docker pour un wiki personnel, c'est une alternative libératrice. Commencez avec un dossier de fichiers Markdown. Ajoutez un compilateur. Sautez la base de données. Votre LLM ne verra pas la différence — et vous dormirez mieux la nuit.

*Pour en savoir plus sur les bonnes pratiques des LLM et les architectures simples, consultez le blog d'OpenAI News, le blog Google AI et le blog Microsoft AI. La tendance générale au minimalisme dans les outils d'IA est bien documentée dans ces sources.*