Traditional RAG systems retrieve chunks and answer from scratch every time. LLM Wiki takes a different path: it analyzes documents once, generates persistent wiki pages with full source traceability, and caches intermediate results so incremental updates cost pennies instead of dollars. The result is a cross-platform desktop application (19,536 stars, trending #10 on GitHub TypeScript) that builds and maintains a structured knowledge base rather than ephemeral retrieval.
Why Two-Step Ingest Matters
Most RAG pipelines chunk documents, embed them, and retrieve at query time. LLM Wiki splits ingestion into two explicit phases:
- Analyze: Extract structure, entities, and relationships from the source document.
- Generate: Write a wiki page that synthesizes the analysis, links to other pages, and preserves references to the original source.
This separation buys you three things:
- Incremental cache: When a document changes, only the affected pages rebuild. The analysis step caches intermediate representations, so you pay for LLM calls once per document, not once per query.
- Source traceability: Every wiki page links back to the original PDF, image, or web clip. Updates or deletions propagate through the graph automatically.
- Persistent knowledge: The wiki is a first-class artifact. You can export it, version it, or rebuild the index from existing pages without re-ingesting sources.
Traditional RAG treats the knowledge base as a hidden index. LLM Wiki treats it as the product.
Ingestion Pipeline Architecture
The ingest queue is a serial processor with crash recovery. Each document enters the queue, gets analyzed, then generates one or more wiki pages. The queue persists to disk, so if the app crashes mid-ingest, it resumes from the last checkpoint.
Ingest Flow
┌─────────────┐
│ Raw Source │ (PDF, Office, EPUB, image, URL)
└──────┬──────┘
│
v
┌─────────────┐
│ Parse │ (MinerU, built-in, or cloud PDF processor)
└──────┬──────┘
│
v
┌─────────────┐
│ Analyze │ (LLM extracts entities, structure, relationships)
└──────┬──────┘
│
v
┌─────────────┐
│ Cache │ (Store intermediate representation)
└──────┬──────┘
│
v
┌─────────────┐
│ Generate │ (LLM writes wiki page with source links)
└──────┬──────┘
│
v
┌─────────────┐
│ Index │ (Update knowledge graph, vector store)
└─────────────┘The analyze step runs a chain-of-thought prompt that identifies key concepts, relationships, and metadata. The cache stores this analysis as JSON. The generate step reads the cache and writes Markdown with frontmatter that includes source references, creation date, and entity tags.
Incremental Cache Mechanics
When a source document changes, the system compares the new analysis to the cached version. If the structure is identical, it skips generation. If entities or relationships changed, it regenerates only the affected wiki pages and updates the knowledge graph edges.
This is cheaper than re-embedding the entire corpus. A 100-page PDF might cost $0.50 to analyze once, then $0.02 per incremental update. Traditional RAG would re-embed all 100 pages every time.
Source Traceability and Auto-Watch
Every wiki page includes a sources array in its frontmatter:
---
title: "Kubernetes Scheduler Internals"
sources:
- type: pdf
path: raw/sources/k8s-design-docs/scheduler.pdf
page: 12
- type: image
path: raw/sources/diagrams/scheduler-flow.png
---The raw/sources/ directory is auto-watched. When you drop a new PDF into a subfolder, the ingest queue picks it up. When you delete a file, the system marks the corresponding wiki pages as orphaned and optionally removes them.
This solves a common RAG problem: stale data. If you delete a source document, traditional RAG keeps serving chunks from it until you manually rebuild the index. LLM Wiki propagates deletions immediately.
Knowledge Graph: Four Signals and Louvain Clustering
The knowledge graph uses four signals to compute relevance between wiki pages:
| Signal | Description | Weight |
|---|---|---|
| Direct links | Explicit [[wikilinks]] in page content | High |
| Source overlap | Pages derived from the same source document | Medium |
| Adamic-Adar | Shared neighbors weighted by neighbor rarity | Medium |
| Type affinity | Pages with similar entity types (person, concept, tool) | Low |
The graph runs Louvain community detection to cluster pages into topics. Each cluster gets a cohesion score based on internal edge density. The UI surfaces “surprising connections” (high Adamic-Adar score between distant clusters) and “knowledge gaps” (low-cohesion clusters with few internal links).
This is useful for agents that need to explore a knowledge base without manual tagging. The graph provides a navigation layer that RAG’s flat vector space cannot.
Multimodal Image Ingestion
LLM Wiki extracts images from PDFs and runs them through a vision LLM to generate factual captions. The captions are indexed alongside text, so image-aware search returns both text snippets and relevant images.
The lightbox preview shows the image, caption, and a “jump to source” button that opens the original PDF at the correct page. This is harder than it sounds: you need to track image coordinates in the PDF, map them to page numbers, and preserve that metadata through the ingest pipeline.
The vision LLM prompt is tuned for factual descriptions, not creative captions. It avoids phrases like “a beautiful sunset” and focuses on “bar chart showing Q3 revenue by region.”
Vector Semantic Search (Optional)
LLM Wiki includes optional vector search via LanceDB. You can configure any OpenAI-compatible embedding endpoint. The vector store indexes wiki page content, not raw source chunks.
This is a key difference from traditional RAG. The embeddings represent synthesized knowledge, not raw text. When you search for “Kubernetes scheduler latency,” you retrieve wiki pages that summarize scheduler behavior, not individual PDF paragraphs.
The system supports hybrid search: combine vector similarity with knowledge graph traversal to find pages that are semantically close and structurally connected.
Persistent Ingest Queue and Crash Recovery
The ingest queue is a JSON file on disk. Each entry includes:
- Source path
- Current step (parse, analyze, generate, index)
- Progress percentage
- Error state (if any)
- Retry count
If the app crashes, it reads the queue file on restart and resumes from the last checkpoint. You can cancel or retry individual items from the UI.
This is critical for long-running ingests. A folder with 500 PDFs might take hours to process. Without crash recovery, a single failure would force you to start over.
Folder Import and Directory Structure
The folder import preserves directory structure. If you import raw/sources/projects/alpha/, the wiki creates a projects/alpha/ namespace with pages grouped by folder.
The folder name becomes a classification hint for the LLM. A file in raw/sources/legal/contracts/ gets analyzed with a prompt that mentions “legal contract context.” This improves entity extraction without requiring manual metadata.
Model Configuration and Routing
LLM Wiki lets you configure models per project. You can route Chat and Ingest to different endpoints:
- Chat: Fast model for interactive Q&A (e.g., GPT-4o-mini)
- Ingest: Slower, more accurate model for analysis (e.g., Claude 3.5 Sonnet)
You can add custom headers for API keys, set streaming preferences, and configure retry logic. The system supports any OpenAI-compatible endpoint, including local models via Ollama or vLLM.
Read Sources Only Mode
This mode restricts the LLM to answering exclusively from imported sources. It disables general knowledge and forces the model to cite wiki pages or source documents.
This is useful for compliance-sensitive workflows where you need to prove every answer came from approved material. The system logs every source citation, so you can audit the retrieval path.
Project Export and Migration
You can export a complete project as a .llmwiki archive. The archive includes:
- All wiki pages (Markdown + frontmatter)
- Source documents
- Knowledge graph edges
- Vector embeddings (if enabled)
- Configuration (models, prompts, settings)
Import the archive on another device, and the wiki rebuilds its index from the exported pages. This is faster than re-ingesting sources because the analysis cache is included.
Failure Modes and Observability
Common failure modes:
- PDF parsing errors: MinerU or built-in parser fails on scanned images or complex layouts. The system logs the error and marks the document as failed. You can retry with a different parser or manually OCR the file.
- LLM rate limits: The ingest queue respects rate limits and retries with exponential backoff. You can configure max retries and backoff multiplier.
- Out-of-memory: Large PDFs (1000+ pages) can exhaust memory during parsing. The system chunks large files into 100-page segments and processes them sequentially.
- Stale cache: If you change the analysis prompt, the cache becomes invalid. The system detects prompt changes and invalidates affected cache entries.
Observability is minimal. The UI shows ingest progress and error logs, but there is no structured telemetry or distributed tracing. For production deployments, you would need to add OpenTelemetry instrumentation.
Comparison: LLM Wiki vs. Traditional RAG
| Dimension | LLM Wiki | Traditional RAG |
|---|---|---|
| Knowledge artifact | Persistent wiki pages | Ephemeral retrieval |
| Incremental updates | Cache analysis, regenerate pages | Re-embed entire corpus |
| Source traceability | Every page links to source | Chunk metadata only |
| Knowledge graph | 4-signal graph with clustering | Flat vector space |
| Multimodal | Vision LLM captions, lightbox | Text-only or basic OCR |
| Crash recovery | Persistent queue with checkpoints | Restart from scratch |
| Cost per update | $0.02 (incremental) | $0.50 (full re-embed) |
Technical Verdict
Use LLM Wiki when:
- You need a persistent, version-controlled knowledge base that agents can query and maintain over time.
- Source traceability and audit trails matter (compliance, research, legal).
- Your document corpus changes incrementally, and you want to avoid re-processing everything.
- You want a knowledge graph with automatic clustering and gap detection.
Avoid LLM Wiki when:
- You need real-time retrieval over rapidly changing data (e.g., live logs, streaming events).
- Your queries are one-off and do not benefit from persistent synthesis.
- You need distributed, multi-tenant deployment with fine-grained access control (LLM Wiki is a desktop app).
- You require production-grade observability and telemetry out of the box.
LLM Wiki shifts the cost from query time to ingest time. If you query the same knowledge base repeatedly, this trade-off pays off. If you ingest once and query once, traditional RAG is simpler.
Source Links
- Primary source: nashsu/llm_wiki on GitHub
- GitHub Trending: TypeScript rank #10, 19,536 stars, 2,207 forks