nashsu LLM Wiki: Turn source documents into a traceable, maintained knowledge base

When your files are easy to locate but the reasoning inside them is hard to recover, another one-off document chat may not solve the real problem. nashsu LLM Wiki is a desktop application designed to turn an expanding source collection into a persistent wiki. According to its official documentation, it analyzes documents, creates source-linked knowledge pages, connects related ideas, and gives you several ways to review and query the result.

It is worth evaluating when you are building a long-lived research or personal knowledge system. If you only need to ask a few questions about a handful of PDFs, the setup and maintenance may be more than you need.

How it differs from one-off document Q&A

Many retrieval-augmented generation tools search for relevant chunks when a question arrives, then assemble a new answer. LLM Wiki takes a different approach: it first compiles source material into a knowledge structure that can be maintained, then queries that structure later.

The upstream README describes three layers:

Raw Sources preserve imported material for later reference.
Wiki contains LLM-generated and updated summaries, concept pages, entity pages, and cross-links.
Schema defines how the wiki is organized, named, and maintained.

The recurring work is organized around three operations:

Ingest reads sources, analyzes them, and creates or updates wiki content.
Query retrieves from the wiki, original sources, and relationship graph.
Lint identifies maintenance work, conflicts, and items that need human judgment.

The important distinction is not whether the application has a chat box. It is whether each ingest leaves behind pages and source references that remain useful after the conversation ends.

What happens between source import and a queryable wiki

The official README describes a two-stage ingest instead of asking the model to read and write in one pass.

The first stage analyzes entities, concepts, arguments, possible tensions, and connections to the existing wiki. The second stage uses that analysis to generate source summaries, concept and entity pages, index changes, and Review items.

A completed ingest is expected to produce more than one answer:

Wiki pages with a sources field linking back to contributing material.
index.md as a content catalog and navigation entry point for the model.
log.md as a chronological operation record.
overview.md as a current summary of the knowledge base.
[[wikilink]] connections between concept and entity pages.
Review items and proposed research directions that remain available for human judgment.

The README also describes SHA-256 incremental caching, so unchanged sources can be skipped during later runs. Source-folder watching is intended to carry additions, edits, and deletions into the same maintenance lifecycle.

Which source formats it is designed to handle

The documented parsing surface extends beyond Markdown and plain text:

PDF through a built-in parser, with MinerU Cloud, Local API, or Local Pipeline options for more complex layouts.
DOCX with headings, lists, tables, and basic text structure.
PPTX with slide-level heading and list extraction.
XLSX, XLS, and ODS with worksheet data converted into Markdown tables.
EPUB and MOBI with book metadata, chapters, and body text.
Web clips captured through the project's Chrome extension and converted to Markdown.
Images, audio, and video that can be previewed or played in the application. Image analysis still depends on the selected model and configuration.

A format appearing in the support list does not prove that every file will parse correctly. Scanned PDFs, highly designed slide decks, unusual fonts, and large spreadsheets should be tested with non-sensitive samples before you commit a full collection.

A practical order for the first run

The upstream Quick Start can be turned into a clear evaluation sequence:

Create a project and choose a Research, Reading, Personal Growth, Business, or General template.
Configure an LLM provider, API key, and model in Settings.
Add optional embedding, web search, PDF processing, or source-folder monitoring only when the project needs them.
Import a small document set from Sources.
Watch the Activity Panel as analysis and wiki generation progress.
Open the generated pages and verify that their sources references lead back to the right material.
Ask questions in Chat, then inspect which wiki pages support each response.
Use Knowledge Graph and Review to investigate poor links, knowledge gaps, and decisions that require a person.
Run Lint periodically so the knowledge base is maintained rather than only expanded.

The main cost is not the download. It is the provider setup, the first schema decisions, and continued review. If you do not plan to correct the generated structure, producing more pages may not produce a more reliable knowledge base.

What search, graph, and agent access each contribute

The documented retrieval pipeline searches both wiki content and raw sources, then expands results through page links and source overlap. Optional LanceDB vector search can connect to an OpenAI-compatible embedding endpoint to find semantically related pages that do not share obvious keywords.

The graph uses direct links, shared sources, common neighbors, and page types to score relationships. Its practical role is to show which topics are connected and which areas remain sparse, not merely to provide a visual map.

For external tools, the upstream project also describes a token-protected local HTTP API bound to 127.0.0.1, a bundled MCP server, and a separate Agent Skill. These interfaces can expose project lists, files, graph traversal, and source rescans to Claude Code, Codex, or another compatible client. You still need to evaluate tokens, permissions, and the effective data boundary in your own setup.

The data-flow decisions that matter before importing sensitive files

A desktop interface does not guarantee that every processing step stays on the device. The configuration you choose determines which services may receive data.

Chat and Ingest require a model. The README lists OpenAI, Anthropic, Google, Ollama, and custom providers.
Vector Search is optional. When enabled, it uses the embedding endpoint you configure.
Deep Research can use Tavily, SerpApi, or SearXNG.
Complex PDF processing can use MinerU Cloud or a local mode.
Firecrawl can point to a hosted or self-hosted service.

The useful privacy question is therefore not simply whether LLM Wiki is a local application. Ask which providers are enabled, what each endpoint receives, and which project files are allowed to leave the machine. Client, employer, and personal records should not be the material for a first experiment.

A small test that can tell you whether the system is worth the effort

Before moving a full archive, prepare 5 to 10 non-sensitive documents. Include one repeated concept, one pair of conflicting statements, and one structurally difficult file. Then check:

Does each source create a recognizable summary page?
Do page-level sources references lead back to relevant material?
When the same concept appears in several files, does the system merge, link, or duplicate pages?
Do Chat citations support the answer rather than merely accompany plausible prose?
Does Review preserve a contradiction for human judgment instead of silently flattening it?
After deleting a test source, do its summary, index entries, and dead links change as expected?
How much time and model cost does a complete ingest require?

If source traceability and human review do not improve your decisions, a larger graph and more automation will not automatically make this a better second brain.

Who should evaluate it, and who can skip it

LLM Wiki may be a good evaluation candidate if you:

Maintain research, reading notes, product documentation, or cross-format project material over time.
Want durable knowledge pages with source references instead of saved chat answers alone.
Are willing to configure a model provider and maintain Review and Lint work.
Want an Obsidian-compatible Markdown wiki that can also be queried by AI agents.

You may want a lighter tool if you:

Only need one-off Q&A over a small document set.
Do not want to manage API keys, model cost, or a local model environment.
Expect document import to require no human review.
Need enterprise permissions, audit controls, team collaboration, or a formal data-residency guarantee that the current upstream material does not establish.

Official download and current release

Download only from the official nashsu/llm_wiki repository or its official releases.

The official GitHub API was checked again on August 11, 2026. The latest release was v0.6.8, published on August 8, 2026. Windows x64 assets included a portable ZIP, setup EXE, and MSI. The official SHA-256 for the portable ZIP was:

5e6e921a276d2f98a7b52a7d43a96c4cd4ea74ab1d630069b347df0b1ed75906

Gwarket does not mirror or repackage these files. Recheck the current release, filename, and checksum before downloading.

What this guide can and cannot conclude

Based on the upstream architecture and documented workflow, the project's distinctive idea is to replace repeated answer generation with a knowledge structure that can be maintained and traced back to source material.

Gwarket has not completed a Windows clean-room Ingest, Query, and Lint first-success. We therefore do not claim installation compatibility, parsing quality, answer accuracy, performance, privacy, long-term stability, or support. This is an official-source evaluation guide, not a hands-on recommendation.

Sources and license

The LICENSE file identifies GNU General Public License version 3 and names Yong Su as the 2024-2026 copyright holder. Models, external services, input documents, and generated outputs may have separate rights and terms. The repository license should not be treated as a blanket conclusion about all of them.