llm-wiki-compiler : compiler une base de connaissances markdown au lieu de la rechercher à chaque requête
The knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathy's LLM Wiki pattern.
En bref
- De quoi s’agit-il ?
- Le projet TypeScript atomicstrata/llm-wiki-compiler transforme des sources brutes en wiki markdown typé, cité et lintable, avec des profils de cycle de vie validés. Voici ce que la documentation permet réellement de vérifier, et où l'outil n'est pas le bon choix.
- À qui s’adresse-t-il ?
- Adoptez llm-wiki-compiler si vos sources ont une durée de vie supérieure à celle d'une recherche ponctuelle et si vous acceptez de maintenir un profil JSON validé. Passez votre chemin pour des logs bruts qui changent en permanence, pour un site statique ou pour une ontologie lourde : le README écarte explicitement ces usages.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 5 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : arrêter de redécouvrir la connaissance à chaque requête
Le README formule l'objectif sans détour : au lieu de retrouver l'information dans les fichiers bruts à chaque interrogation, llmwiki la compile une fois en pages durables qui accumulent structure, provenance, état de revue et métadonnées de retrieval. Le public visé est précis. Des équipes qui ingèrent des articles scientifiques, des notes, des README, des transcriptions, des PDF, des images ou des pages web et qui veulent fournir à un agent un paquet de contexte stable plutôt qu'un dossier en vrac. Le README mentionne aussi l'usage humain : parcourir le résultat localement, l'interroger en CLI, l'exposer via MCP ou l'intégrer par le SDK.
La limite est posée dans le même paragraphe. L'outil n'est pas un générateur de site statique, ni une base ontologique lourde, ni un substitut à la recherche ad hoc sur des logs bruts à évolution rapide. Cette dernière exclusion est la plus utile à retenir : si votre matière première change plus vite que vous ne la relisez, la phase de compilation devient un coût pur. Le projet se positionne sur de la connaissance qui vaut la peine d'être compilée, relue et réutilisée.
Deux phases, quatre types de pages, et un profil qui décide de tout
Le mécanisme central tient en une phrase du README : un pipeline LLM en deux phases extrait d'abord les concepts, puis génère des pages typées, à savoir concept, entity, comparison et overview. La sortie n'est pas un tas de chunks mais un wiki markdown où les paragraphes et les affirmations citent des fichiers sources avec des plages de lignes, et où llmwiki lint valide les liens. C'est le point qui distingue le projet d'un simple index vectoriel : la citation est une donnée de première classe, pas un commentaire ajouté après coup.
Au-dessus de ce pipeline, les Configurable Lifecycle Profiles forment le contrat unique. Un fichier .llmwiki/profile.json validé peut déclarer des entités typées avec leurs champs, des relations dirigées, des états de cycle de vie avec les preuves exigées pour chaque transition, des workflows multi-étapes, des artefacts ancrés par hash, des connecteurs, des niveaux de contenu et une politique de retrieval. Le README insiste sur un point d'architecture : ces règles sont appliquées par le runtime, pas laissées à des conventions de prompt. Un profil invalide ou une écriture qui contourne une porte déclarée échoue en mode fail-closed. La compatibilité ascendante est présentée comme structurelle : sans fichier de profil, le projet retombe sur le profil par défaut concepts-and-queries et conserve le comportement antérieur à la 1.0.
Mise en route : profil, template, validation
Le README donne trois chemins d'entrée. Le premier consiste à écrire son propre profil, une entité à la fois, avec llmwiki profile init research --entity paper. Le deuxième passe par un template déclaratif local ou intégré, avec llmwiki template list, llmwiki template inspect autosci puis llmwiki template init autosci. Le troisième installe un template signé depuis un tap de confiance, mécanisme décrit plus loin dans le README avec llmwiki template publish et une signature Ed25519.
Deux commandes reviennent ensuite dans la documentation comme points de contrôle : llmwiki profile validate et llmwiki workflow list. La première vérifie le contrat de profil, la seconde énumère les workflows déclarés. Le template autosci construit un système de recherche avec papers, ideas, experiments, manuscripts, evidence artifacts, workflows et import Crossref ; newsroom applique la même machinerie à des articles, desks, bylines et workflows éditoriaux. Un détail de conception mérite d'être relevé : les templates contiennent de la configuration et des exemples, jamais de code plugin exécutable. C'est un choix de sécurité lisible, et il limite en même temps ce qu'un template peut faire.
Pour l'exploration, le README cite llmwiki view, une interface navigateur en lecture seule avec recherche, métadonnées de page, exploration de graphe, badges de fraîcheur des sources et pastilles de citation. Côté agent, llmwiki serve expose ingest, compile, query, lint, read, status, eval, context-pack et les échanges OKF via MCP. Côté code, createWiki({ root }) pilote ingest, compile, query, context, status, export, eval et l'import/export OKF depuis TypeScript, sans passer par le shell.
Retrieval hybride et réparation de la fraîcheur
La recherche ne repose pas sur un seul signal. Le README décrit une combinaison de recherche sémantique par chunks, de reranking BM25 et d'expansion par le graphe de wikilinks, le tout pour produire des paquets de preuves compacts destinés aux requêtes et aux agents. L'expansion par wikilinks est la partie qui dépend directement de la qualité du maillage produit à la compilation : un wiki pauvrement lié réduit l'apport de ce troisième étage.
La maintenance de la fraîcheur est traitée par deux commandes. llmwiki lint et llmwiki next font remonter les pages obsolètes ou orphelines, tandis que llmwiki refresh --stale répare la connaissance modifiée sans recompiler des sources nouvelles sans rapport. Ce dernier point est important en pratique : il évite de payer une recompilation complète pour corriger une dérive locale. Le README mentionne également une politique de revue : les pages générées peuvent être retenues automatiquement lorsque des règles de confiance, de contradiction, de schéma ou de provenance se déclenchent. Et llmwiki eval rapporte un score de santé, une distribution par page qui signale les pires, la santé du graphe de wikilinks, la couverture et la précision des citations, des statistiques de corpus, des deltas de régression et, en option, le support de citation par un modèle juge.
Les portes de confiance ne couvrent que ce qu'elles déclarent
Le point faible le plus net concerne le périmètre des garanties. Les portes de relation, de preuve, d'artefact et humaines sont appliquées par le chemin d'écriture, ce qui est plus solide qu'une convention de prompt. Mais elles n'existent que si le profil les déclare. Un profil minimal, ou l'absence de profil, laisse le comportement par défaut sans ces contrôles. Le lint détecte la dérive après coup, ce que le README assume explicitement en parlant de détection a posteriori.
Deuxièmement, la qualité de sortie dépend d'un pipeline LLM. Le README décrit des mécanismes de revue et de confiance, pas une exactitude garantie. La citation traçable rend les erreurs vérifiables, elle ne les empêche pas. Troisièmement, la portabilité des providers est annoncée pour Anthropic, Claude Agent SDK en connexion locale, OpenAI Codex CLI en connexion locale, les serveurs compatibles OpenAI, Ollama, GitHub Copilot, Atlas Cloud, OrcaRouter et des runtimes locaux compatibles OpenAI. La liste est large, mais rien dans le matériel fourni ne documente les écarts de comportement entre ces backends sur un même corpus. Enfin, l'échange OKF mérite attention : les imports OKF externes passent par la file de revue par défaut, et seuls les bundles explicitement considérés comme de confiance peuvent être écrits directement.
Face à un index vectoriel ou à un wiki manuel
L'alternative la plus directe reste un index vectoriel branché sur les fichiers bruts, éventuellement avec un reranker. La différence d'approche est nette : l'index vectoriel retrouve des passages au moment de la requête et ne conserve aucun état entre deux interrogations, tandis que llmwiki produit des pages typées qui portent leur provenance, leur état de revue et leurs métadonnées de retrieval. Un index vectoriel ne vous demandera jamais de valider un .llmwiki/profile.json, et c'est précisément son avantage quand les sources bougent en continu. Il ne vous donnera pas non plus de pages à relire, à linter ou à exporter au format OKF.
Face à un wiki markdown tenu à la main, le compromis est inverse. Un wiki manuel n'a pas de coût de compilation ni de dépendance à un provider, mais il n'offre ni citations automatiques avec plages de lignes, ni détection de pages orphelines, ni gates d'écriture. Le choix se joue donc sur un critère simple : acceptez-vous de payer une étape de compilation et la maintenance d'un contrat de profil pour obtenir de la traçabilité et un état de revue exploitables par un agent ?
Coût de maintenance et licence
Le matériel fourni ne contient aucune donnée de performance, aucun chiffre de coût par token et aucune estimation de durée de compilation. Ces éléments ne peuvent pas être évalués ici et devront être mesurés sur votre propre corpus. Ce qui est vérifiable, c'est la cadence de publication : v1.0.0 le 11 juillet 2026, v1.1.0 le 16 juillet 2026, v1.2.0 le 10 septembre 2026, avec un dernier push sur main à la même date que la 1.2.0. Trois versions publiées en deux mois indiquent un rythme soutenu, ce qui implique de relire les notes de version avant chaque montée, en particulier autour du contrat de profil dont dépendent le CLI, le SDK, le serveur MCP, le viewer, le context builder, lint, status, export et l'échange OKF.
Le projet est publié sous licence MIT. Cette licence est permissive et n'impose pas de publication de vos modifications, mais elle s'applique au code du compilateur, pas nécessairement aux templates signés que vous installeriez depuis un tap ni aux corpus que vous compilez. Le README ne détaille pas les conditions attachées aux taps de templates. Ce point mérite une vérification directe auprès de la source du tap concerné, et non une déduction à partir de la licence du dépôt.
Conclusion éditoriale
Adoptez llm-wiki-compiler si vos sources ont une durée de vie supérieure à celle d'une recherche ponctuelle et si vous acceptez de maintenir un profil JSON validé. Passez votre chemin pour des logs bruts qui changent en permanence, pour un site statique ou pour une ontologie lourde : le README écarte explicitement ces usages. Avant tout déploiement, lancez llmwiki template inspect autosci puis llmwiki profile validate sur votre propre .llmwiki/profile.json, et vérifiez que le provider que vous comptez utiliser figure bien dans la liste de portabilité annoncée.
Notes de la communauté