# LLM Wiki's Two-Step Chain-of-Thought Ingest: How Incremental Cache and Source Traceability Replace Traditional RAG > Source: > Published: 2026-09-15 10:06:52+00:00 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. Most RAG pipelines chunk documents, embed them, and retrieve at query time. LLM Wiki splits ingestion into two explicit phases: This separation buys you three things: Traditional RAG treats the knowledge base as a hidden index. LLM Wiki treats it as the product. 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. ``` ┌─────────────┐ │ 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. 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. 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. 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. 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." 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. The ingest queue is a JSON file on disk. Each entry includes: 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. 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. LLM Wiki lets you configure models per project. You can route Chat and Ingest to different endpoints: 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. 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. You can export a complete project as a `.llmwiki` archive. The archive includes: 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. Common failure modes: 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. | 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) | **Use LLM Wiki when:** **Avoid LLM Wiki when:** 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.