Implémentation du LLM Wiki de Andrej Karpathy
Sommaire
Le problème du RAG classique
La plupart des applications RAG fonctionnent ainsi : on uploade des documents, le LLM récupère les chunks pertinents à chaque question et génère une réponse. Ça marche, mais le LLM redécouvre la connaissance from scratch à chaque requête. Rien ne s'accumule. Une question qui nécessite de synthétiser cinq documents oblige le LLM à retrouver et assembler les fragments à chaque fois. C'est le fonctionnement de NotebookLM, des uploads ChatGPT, et de la grande majorité des pipelines RAG.
L'idée : un wiki persistant
Andrej Karpathy (ex-Tesla, ex-OpenAI et, à l'heure où j'ecris, actuel Anthropic) propose une approche différente dans son article : plutôt que de récupérer des documents bruts à chaque requête, le LLM construit et maintient un wiki persistant, une collection de fichiers Markdown structurés et interconnectés. Quand un nouveau document arrive, le LLM ne se contente pas de l'indexer : il le lit, en extrait les informations clés et les intègre dans le wiki existant, met à jour les pages concernées, note les contradictions avec ce qui était déjà connu. La connaissance est compilée une fois et maintenue à jour, pas re-dérivée à chaque question. C'est d'ailleurs ainsi que fonctionne Claude Code.
Implémentation
Karpathy a volontairement publié des idées sans code : l'implémentation dépend du besoin. J'ai choisi de construire un agent dont l'objectif est de maintenir une base de connaissances sur mes projets immobiliers. Le backend est en FastAPI, le frontend en Next.js, et la base de documents en fichiers Markdown stockés localement. Pour visualiser le wiki et ses interconnexions, j'utilise Obsidian (qui lit nativement le Markdown et affiche les cross-references entre pages).
Structure du wiki
Deux approches sont possibles : laisser le LLM créer librement les pages, ou définir à l'avance les types d'entités. J'ai opté pour la seconde, en définissant 9 types d'entités liées à l'immobilier, fournis via le prompt système à l'agent d'exploration.
1. Bien
Une page par bien immobilier suivi.
2. Copropriété
Une page par copropriété.
3. Personne
Une personne physique : vendeur, notaire, agent, voisin.
4. Organisation
Agence, syndic, banque, administration.
5. Document
Une source structurée : DPE, AG, contrat, diagnostic.
6. Concept
Notion technique transversale rencontrée dans plusieurs sources. Ex : « Clause Airbnb dans un règlement de copropriété ».
7. Décision
Un choix acté avec contexte et date.
8. Risque
Un problème identifié avec niveau de criticité et statut.
9. Travaux
Des travaux planifiés, en cours ou réalisés.
Pipeline d'ingestion
A l'image du RAG, l'application s'articule en deux pipelines : un pipeline d'ingestion (offline) qui traite les documents entrants et met à jour le wiki, et un pipeline d'inférence (online) qui répond aux questions de l'utilisateur à partir du wiki compilé.
Ingestion des données
Les documents entrants (PDF, images, TXT) sont d'abord traités par Mistral Document AI via son API OCR, qui extrait le texte brut y compris depuis des scans ou des images. Le texte est ensuite transmis à un Agent d'exploration qui, grace a des outils, va explorer le wiki existant, identifier les pages liées, et produire un plan de modification du wiki (ex : créer une nouvelle page pou le bien X, modifier la section B du bien Y etc...
Pipeline d'inférence
Quand l'utilisateur pose une question, un second agent explore le wiki compilé : il lit les pages pertinentes et synthétise une réponse à partir de la connaissance
Perspectives
Plusieurs pistes d'amélioration sont envisagées pour rendre l'agent plus robuste et le wiki plus cohérent.
Outils d'exploration enrichis
Ajouter des outils de recherche plus fins à l'agent : regex pour des correspondances exactes sur des identifiants ou références, similarité cosine sur les embeddings pour retrouver les pages sémantiquement proches, et distance de Levenshtein pour tolérer les variations orthographiques sur les noms propres (vendeurs, notaires, adresses).
Outil de lint anti-doublons
Un outil de lint du wiki qui détecte automatiquement les pages doublons par similarité cosine : si deux pages dépassent un seuil de similarité, l'agent est invité à les fusionner ou à clarifier leur distinction. Cela garantit la cohérence du wiki sur la durée et évite la fragmentation de la connaissance.