# LLM Wiki — Pattern de Knowledge Base Personnelle Maintenue par LLM

- **URL source** : Non publiée (document fourni en texte intégral par le user)
- **Auteur** : Inconnu (style d'écriture suggère un ingénieur/builder anglo-saxon, probablement publié sur un blog perso ou Gist)
- **Date de publication** : Récent (mentionne 2026-04-02 comme exemple de date dans log.md)
- **Date d'accès** : 2026-05-23
- **Type** : Concept / Spec / Pattern d'architecture
- **Thématique** : Knowledge management, RAG, LLM workflows, Obsidian, prise de notes augmentée par IA
- **Niveau de confiance** : Élevé (description méthodique, pas de claims marketing)
- **Conflit d'intérêt** : Aucun apparent — pas de produit vendu, document explicitement "abstract pattern"

## Résumé exécutif (TL;DR)

Le pattern "LLM Wiki" propose une alternative au RAG traditionnel : au lieu de laisser le LLM redécouvrir la connaissance à chaque requête, on lui fait **construire et maintenir un wiki Markdown persistant** entre les sources brutes et les questions de l'utilisateur. Le wiki est un **artefact qui compose dans le temps** : chaque nouvelle source enrichit les pages d'entités, met à jour les synthèses, et flague les contradictions. Le LLM fait tout le travail de bookkeeping (cross-références, mises à jour, cohérence) ; l'humain ne fait que curater les sources et poser les bonnes questions. Obsidian est l'IDE, le LLM est le programmeur, le wiki est le codebase.

## Idée centrale (le pourquoi)

> "Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question."

Le constat fondamental : le RAG classique (NotebookLM, ChatGPT uploads) **ne capitalise pas**. Chaque requête redémarre l'analyse de zéro. Or :
- Les contradictions ne sont pas mémorisées
- La synthèse n'évolue pas
- Les cross-références doivent être recalculées
- Les questions précédentes ne nourrissent pas la base

Le pattern LLM Wiki résout ça en faisant du LLM le **mainteneur** d'un wiki structuré, pas juste un retriever.

## Architecture — Les 3 couches

### Couche 1 — Raw sources (immuable)
- Articles, papiers, images, fichiers de données
- Le LLM y lit, ne modifie jamais
- Source of truth

### Couche 2 — Le wiki (LLM-owned)
- Répertoire de fichiers Markdown générés par le LLM
- Summaries, pages d'entités, concepts, comparaisons, synthèses
- L'humain lit ; le LLM écrit
- Maintien des cross-références automatiques

### Couche 3 — Le schéma (configuration)
- Document type `CLAUDE.md` ou `AGENTS.md`
- Définit les conventions, structures, workflows
- Co-évolue avec l'utilisateur
- **C'est ce qui transforme le LLM en mainteneur discipliné plutôt que chatbot**

## Opérations détaillées

### Ingest (intégration d'une source)
Workflow typique :
1. Drop d'une source dans la raw collection
2. LLM lit la source
3. Discussion des takeaways avec l'utilisateur
4. Écriture d'une page summary dans le wiki
5. Mise à jour de l'index
6. Mise à jour des pages d'entités et concepts liés (10-15 pages touchées)
7. Append entry dans le log

**Note** : ingest one-by-one avec supervision OU batch sans supervision selon préférence.

### Query (interrogation)
- Question contre le wiki
- LLM cherche les pages pertinentes, lit, synthétise avec citations
- Formats de sortie : MD, comparaison tableau, deck Marp, chart matplotlib, canvas
- **Insight clé** : les bonnes réponses peuvent être filed BACK dans le wiki comme nouvelles pages → exploration capitalisée

### Lint (health-check périodique)
Recherche :
- Contradictions entre pages
- Claims devenus stales par sources récentes
- Pages orphelines (no inbound links)
- Concepts importants mentionnés sans page propre
- Cross-références manquantes
- Data gaps comblables par web search

## Indexing & Logging — Les 2 fichiers spéciaux

### `index.md` — orienté contenu
- Catalogue de tout dans le wiki
- Lien + résumé d'une ligne + metadata (date, source count)
- Organisé par catégorie (entities, concepts, sources)
- Mis à jour à chaque ingest
- Lu en premier par le LLM lors d'une query
- **Scale efficace** : ~100 sources, ~centaines de pages SANS RAG/embeddings

### `log.md` — chronologique
- Append-only des événements (ingests, queries, lints)
- Préfixe consistant : `## [2026-04-02] ingest | Article Title`
- Parseable avec grep : `grep "^## \[" log.md | tail -5`
- Timeline de l'évolution du wiki

## Outils CLI optionnels

À mesure que le wiki grossit :
- **qmd** (https://github.com/tobi/qmd) : moteur de recherche local pour MD, hybrid BM25/vector + LLM re-ranking, on-device
  - CLI (shell out) + serveur MCP (tool natif)
- Search script naïf vibe-codé par le LLM

## Tips & Tricks (concrets)

| Tip | Détail |
|-----|--------|
| **Obsidian Web Clipper** | Extension navigateur → MD propre, get sources rapidement |
| **Download images locally** | Settings → Files → "Attachment folder path: `raw/assets/`" + Hotkey "Download attachments for current file" (Ctrl+Shift+D) → images locales, plus de URLs cassées |
| **Limitation LLM + images inline** | LLMs ne lisent pas MD avec images inline en one-pass → lire texte puis view images séparément |
| **Graph view Obsidian** | Voir la forme du wiki, hubs, orphans |
| **Marp** | Format MD slide decks + plugin Obsidian → présentations from wiki |
| **Dataview** | Plugin Obsidian, queries sur frontmatter YAML → tables dynamiques |
| **Git** | Wiki = repo git → version history, branching, collab gratuits |

## Cas d'usage (exemples du doc)

- **Personnel** : tracking goals, santé, psycho, self-improvement, journaling
- **Recherche** : deep-dive sur un sujet sur des semaines/mois
- **Lecture d'un livre** : chapitre par chapitre, build pages personnages/thèmes/plot (cf. Tolkien Gateway)
- **Business/team** : wiki interne maintenu par LLM nourri par Slack/transcripts/docs/calls (humans review)
- **Compétitif analysis, due diligence, trip planning, course notes, hobby deep-dives**

## Pourquoi ça marche (la thèse)

> "The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping."

Le job humain : curating sources, directing analysis, asking good questions, thinking about meaning.
Le job LLM : tout le reste (cross-refs, summaries, consistency, contradictions, file maintenance).

Reference historique : **Memex de Vannevar Bush (1945)** — personal curated knowledge store with associative trails. La pièce manquante de Bush ("qui maintient ?") est résolue par le LLM.

## Pertinence SEO pour ElevaSEO

**Application directe au projet en cours** :
- Le user (bastien@elevaseo.com) construit en ce moment ce wiki SEO (`/Users/humperdoo/Github/docs-seo/`)
- La structure recommandée : `raw/` + `sources/` (équiv. wiki pages) + `MEMORY.md` ou `index.md` + `log.md`
- Schema = ce CLAUDE.md projet à co-évoluer

**Application client** :
- Vendre du knowledge management LLM-augmented aux clients SEO :
  - Audit content gap : wiki des concurrents auto-maintenu
  - Veille SERP : ingest journalier des SERPs + détection changements
  - Brief de rédaction : wiki des entités du sujet → brief structuré

**Application interne agence** :
- Wiki des best practices SEO/GEO à jour automatiquement
- Onboarding rapide d'un nouveau consultant
- Mémoire d'agence (incidents clients, solutions, pattern)

## ⚠️ Méfiance / Bullshit detector

- **Promesse "near zero maintenance cost"** : faux à 100%. Le LLM coûte cher en tokens si on ingest des dizaines de sources/jour. Compter aussi le coût humain de "directing analysis".
- **"Wiki garde la maintenance"** : OUI si l'humain reste discipliné. Sans usage régulier, le wiki devient un musée comme tous les KMs avant lui.
- **"Pas besoin d'embeddings"** : OK à ~100 sources. Au-delà, le scan d'index commence à coûter en tokens (cache miss à chaque query).
- **Risque hallucination** : le LLM peut inventer des cross-références ou des "facts" issus de pages qu'il n'a pas relues. → Le pattern doit forcer le LLM à RE-LIRE les pages avant claim.
- **Lock-in cognitif** : si la synthèse du LLM devient ta seule vue sur les sources, tu perds le contact avec le matériau brut. Garder la pratique de lire la source originale.

## Adaptation recommandée pour ce projet docs-seo

```
/Users/humperdoo/Github/docs-seo/
├── raw/                    # Sources brutes (PDF, HTML clip, captures)
├── sources/                # 1 MD par source (le pattern du user)
├── entities/               # (à créer) pages par entité (Google, Cyrus Shepard, etc.)
├── concepts/               # (à créer) GEO, Query Fan-out, AI Overviews, etc.
├── log.md                  # Append-only timeline
├── index.md ou README.md   # Catalog
└── CLAUDE.md               # Schema projet (conventions)
```

Le user a déjà commencé avec `sources/` → reste à enrichir avec entities/, concepts/, et CLAUDE.md projet.

## Liens externes mentionnés

- [Tolkien Gateway](https://tolkiengateway.net/wiki/Main_Page) — exemple fan wiki riche, modèle d'inspiration
- [qmd](https://github.com/tobi/qmd) — Tobi Lütke (CEO Shopify), search engine MD local
- [Memex (Vannevar Bush, 1945)](https://en.wikipedia.org/wiki/Memex) — référence historique
- [Marp](https://marp.app/) — slide decks MD
- [Obsidian Web Clipper](https://obsidian.md/clipper) — extension navigateur

## Actionable pour ce projet

- [x] Créer `sources/` ✅ (fait)
- [ ] Créer `entities/` (pages : Cyrus Shepard, Google, Vercel, DeFiLéo, Outrank, etc.)
- [ ] Créer `concepts/` (pages : GEO, Query Fan-out, AI Overviews, Local SEO, Backlink directories, etc.)
- [ ] Créer `CLAUDE.md` projet définissant le schema (à co-évoluer)
- [ ] Créer `log.md` avec la convention `## [YYYY-MM-DD] ingest | Title`
- [ ] Créer `index.md` ou enrichir `README.md` comme catalog
- [ ] Installer qmd quand le wiki dépasse 100 sources
- [ ] Mettre le tout en repo git