LLM Wikid — knowledge layer compilee vs RAG, 2 couches separees¶

Resume¶

Framework open-source (github.com/shannhk/llm-wikid) pour construire un "AI Knowledge Layer" — une couche de connaissances structuree entre l'utilisateur et ses agents. 504K vues cumulees, 2.3K bookmarks.

Architecture a 2 couches :

Principe cle : wiki compile > RAG. Au-dela de ~100 articles, le wiki compile (pages structurees avec cross-references) surpasse le RAG (chunking + recherche a chaque query) en qualite et en cout tokens (71.5x moins de tokens par query selon Graphify).

Operations : - /wiki-ingest : trie les sources brutes (raw/), fetche le contenu complet, telecharge les images, classifie par type, compile en pages wiki avec cross-references, met a jour l'index - /wiki-query : recherche dans le wiki, produit une reponse citee, file la reponse comme nouvelle page (boucle de capitalisation) - /wiki-lint : detecte contradictions, contenu obsolete, pages orphelines, doublons - /wiki-explore : navigation et validation humaine

Validation gates : chaque page generee par l'IA demarre avec explored: false. Seul un humain peut passer a true. Niveaux de confiance (high/medium/low/uncertain). Bias checks forçant les contre-arguments sur chaque page.

Scaling : 1 personne → equipe 5-10 → organisation 50+. Git pour le versioning. Obsidian Web Clipper pour la collecte passive. Scheduled ingest pour le traitement overnight.

Analyse critique approfondie¶

Interet reel¶

C'est le framework le plus mature que j'ai vu sur le sujet "memoire structuree pour agents". Il depasse significativement les approches naives (Obsidian+Claude, MemPalace, fichiers .md plats) grace a :

1. Separation KBL/BF : la distinction dynamique (agent-maintained) vs statique (human-only) est critique. Sans elle, l'agent finit par reecrire les regles fondamentales — exactement le probleme que l'Art. VII CONSTITUTIONAL (respect des skills) adresse
2. Wiki compile vs RAG : le claim "71.5x moins de tokens" est credible pour des corpus stables. Le RAG re-derive a chaque query, le wiki compile une fois et sert
3. Validation gates : explored: false par defaut est un pattern de confiance zero que peu de systemes implementent
4. Boucle de capitalisation : chaque query devient une page = le wiki grandit par l'usage, pas juste par l'ingestion

Limites serieuses :

• Pas de scoring de pertinence : toutes les pages ont le meme poids. Pas de mecanisme pour dire "cette page a ete utile 12 fois" vs "celle-ci n'a jamais ete consultee". Sans scoring, le wiki accumule du bruit sans le filtrer
• Pas de lifecycle : pas de promotion (page locale → globale), pas d'eviction (page obsolete → archive). A 1000 pages, le wiki devient un cimetiere de connaissances
• Pas de recherche semantique : /wiki-query repose sur la lecture de l'index + navigation par cross-references. Pas d'embeddings, pas de k-NN. Ca marche a 200 pages, pas a 2000
• Pas de verification formelle : /wiki-lint detecte les contradictions par analyse LLM, pas par logique formelle. Le LLM peut rater les contradictions subtiles (exactement ce que Prolog attrape dans ProbatioVault)
• Single-tenant : le systeme est concu pour un utilisateur. Le scaling multi-equipe est theorique, sans implementation documentee

Interet dans le contexte ProbatioVault¶

Mapping LLM Wikid → ProbatioVault :

Ce que LLM Wikid fait mieux : - Collecte passive : Obsidian Web Clipper + scheduled ingest est plus fluide que la collecte manuelle ProbatioVault. On pourrait s'inspirer du pattern "clip pendant la journee, ingest la nuit" pour la veille - Contre-arguments forces : chaque page wiki inclut automatiquement les contre-arguments et les lacunes. ProbatioVault n'a pas ce mecanisme de bias-check systematique dans les learnings - Niveaux de confiance : high/medium/low/uncertain sur chaque page. Les learnings ProbatioVault ont un reuse_score mais pas un niveau de confiance explicite

Ce que ProbatioVault fait mieux : - Recherche semantique (FAISS + nomic-embed-text) vs lecture d'index textuel - Scoring de reutilisation (reuse_score = tanh(...)) vs poids egal - Lifecycle automatique (promotion story → domain → global, eviction 8 semaines) vs accumulation indefinie - Verification formelle (Prolog) vs lint LLM - Multi-sources (learnings + veille + clarifications PO) vs source unique

Redondance avec les briques existantes¶

Redondance partielle (60%). Les briques de capitalisation ProbatioVault (B1-B5, PD-295) couvrent les memes besoins mais avec une architecture differente :

• KBL ≈ learnings.jsonl + veille.jsonl + clarifications.jsonl (3 sources vs 1 wiki)
• BF ≈ CONSTITUTIONAL.md + CLAUDE.md (meme concept, meme separation)
• Ingest ≈ collect-.py + index-.py (meme pattern mais avec embeddings)
• Query ≈ search-*.py via FAISS (semantique vs textuel)

Ce qui n'est PAS redondant : - Le pattern "clip + scheduled ingest" pour la veille — actuellement la veille est manuelle (/veille <url>) - Les contre-arguments forces sur chaque page - Le format wiki cross-reference vs JSONL plat

Difficulte de mise en oeuvre¶

Valeur pour les threads X¶

Excellent materiel pour un thread sur les learnings vivants (thread potentiel #10). Le contrast LLM Wikid vs ProbatioVault illustre parfaitement la difference entre "stocker tout" et "selectionner ce qui compte". L'angle : "13K bookmarks pour un systeme qui accumule tout. Voici pourquoi ca ne scale pas — et comment j'ai construit un systeme qui oublie volontairement."