Les multi-agents consommaient beaucoup de tokens et perdaient souvent le contexte ? J’ai donc créé un LLM Wiki en adoptant une structure de « rédaction de journal ».

• Les systèmes multi-agents autonomes se multiplient ces derniers temps, mais quand on les fait tourner pour de vrai, ils consomment 5 à 10 fois plus de tokens et perdent souvent le contexte. J’ai donc structuré le multi-agent sur le modèle d’une rédaction de journal.
• Il existe cinq rôles d’agents, mais le seul agent pour lequel le LLM prend des décisions de lui-même est le desk (validation). Les autres relèvent soit de la rédaction, soit d’un contrôle Python basé sur des règles (lint), et non d’un LLM, soit de la coordination des tâches (orchestration).
• Comme dans le concept de LLM Wiki, le système lit les documents sources pour créer des pages source, en extrait des brouillons de personnes et de concepts, puis les regroupe et les empile en pages de synthèse par sujet, en pages de contradictions et en pages de synthèse globale. Le stockage se fait simplement sous forme de fichiers Markdown avec git, et les outils Python tournent tous en local. Il suffit de cloner le dépôt pour lancer immédiatement le graphe d’exemple, même sans clé API.
• L’exemple actuellement présent sur GitHub traite du débat « qu’est-ce que l’open source dans l’IA ? », mais le framework lui-même n’est pas lié à un sujet particulier.

---

Pourquoi ne pas avoir simplement lâché plusieurs agents en liberté

• Les retours de personnes qui ont vraiment fait tourner ce genre de systèmes en dépensant des milliers de dollars aboutissaient globalement à la même conclusion : énormément de tokens consommés, du contexte perdu au fil des échanges entre agents, et des tâches inachevées marquées comme terminées.
• J’ai donc privilégié des règles définies et l’isolation du contexte plutôt que de laisser les agents décider seuls. Même si j’utilise la métaphore de la rédaction, le seul LLM réellement libre de juger est le desk ; les autres ne font que des tâches prédéfinies.

Réponses anticipées aux objections probables

• Les documents vont enfler sans cesse et finir par devenir inutilisables : c’est à mon avis la crainte la plus réaliste. C’est pourquoi j’ai complètement séparé le rôle de rédaction et le desk chargé de décider si le résultat passe. Le desk ne voit que le livrable et les critères d’évaluation, pas l’intention de l’auteur. En plus de cela, un lint basé sur des règles filtre mécaniquement les documents qui gonflent, se dupliquent ou s’étirent sans direction. Je ne peux toutefois pas aller jusqu’à dire que le gonflement est « empêché ».
• À force d’éditer, les erreurs s’accumulent ; et si le système se corrige avec son propre feedback, il finit par répéter les mêmes schémas : c’est un soupçon qui accompagne toujours l’idée d’auto-amélioration, et je le trouve valable. Ainsi, lorsque les défauts que le desk repère de manière répétée sont réintégrés dans les guidelines, je remplace à chaque fois les cas d’échec utilisés pour la validation afin d’éviter qu’il ne s’habitue seulement aux mêmes questions de test (overfit). En quelque sorte, la vérification se fait toujours sur des cas jamais vus. Pour les pages de synthèse globale, j’ai aussi ajouté un contrôle qui compare les contenus afin de vérifier que des éléments provenant de sources différentes n’ont pas été amalgamés.
• Au fond, ce n’est pas juste du RAG dont on aurait remplacé manuellement les embeddings ? : si l’objectif est la recherche, c’est une remarque juste. La différence, c’est que le résultat n’est pas un index vectoriel, mais des documents reliés qu’un humain peut lire directement, et que les désaccords entre sources ne sont pas masqués mais exposés séparément dans des pages de contradictions. Le but n’est pas de réagréger les textes sources à chaque question, mais de conserver les jugements accumulés.

Un concept ancien : Memex

• Le projet a été conçu en gardant à l’esprit des idées comme le Memex de Vannevar Bush (une machine d’information reliée imaginée en 1945) et la « Man-Computer Symbiosis » de Licklider.
• J’y ai donc ajouté des trails (chemins associatifs) reliant les pages entre elles, ainsi qu’une fonction discover qui aide à trouver des connexions inattendues. Il ne s’agit pas seulement de générer automatiquement un index, mais de laisser des chemins qu’un humain peut suivre lui-même.

Points à prendre en compte à l’usage

• Dire qu’« aucune clé API n’est nécessaire » n’est vrai qu’à moitié : le Python dans tools tourne en local, donc il n’a pas besoin de clé externe. En revanche, les agents eux-mêmes tournent avec Claude Code ; chacun doit donc y brancher sa propre clé (BYOK).
• Le dépôt public contient surtout l’idée et un petit exemple : il inclut un exemple en anglais de 15 nœuds, ce qui permet à n’importe qui de reproduire le même graphe après un simple clone. L’instance réelle d’environ 2 300 nœuds que j’utilise au quotidien reste séparée et privée ; merci donc de la distinguer du dépôt public.
• Mode coréen (WIKI_LANG=ko) : seuls le corps du texte et les métadonnées en haut des documents (frontmatter) passent en coréen ; les notations qui indiquent la structure du document, comme ## Summary ou [fact], sont volontairement laissées en anglais. Cela signifie que ce n’est pas du « tout coréen ».

Origine du projet et état actuel

• Le point de départ a été d’ajouter une implémentation au gist LLM Wiki partagé par Karpathy. Ce concept avait déjà été présenté auparavant sur GeekNews : https://fr.news.hada.io/topic?id=28208
• Le fait que séparer la rédaction et la validation réduise vraiment les validations bâclées, ou que la boucle d’auto-amélioration aide réellement, reste pour l’instant une hypothèse en cours d’expérimentation, pas un résultat correctement mesuré.