2026.09.20
obsidian-llm-wiki: A Graph-Based Knowledge Base Inside Obsidian
obsidian-llm-wiki turns Obsidian notes and supported documents into a linked, queryable knowledge base. Its graph-based retrieval avoids embeddings and vector databases, but users should review model-data handling, backups, format support, and automated page rewrites before deployment.
What the project does
GD4AI/obsidian-llm-wiki is an open-source Obsidian plugin for turning Markdown notes into a connected, queryable knowledge base. It follows the Karpathy LLM Wiki idea: an LLM reads source material, creates entity and concept pages, and adds relationships while the resulting wiki remains inside the user’s Obsidian vault.
The README describes retrieval through the [[wiki-link]] graph using Personalized PageRank and Monte Carlo methods. It presents this as a zero-embedding, zero-vector-database design. That can suit Obsidian users who already maintain many internal links and want graph relationships to remain visible through Obsidian’s native Graph View.
Who it may suit
The plugin is aimed at people who already use Obsidian and want to organize reading notes, research material, or a personal knowledge base into topic-oriented pages. Students, writers, researchers, and personal knowledge-management users may find the in-editor workflow more convenient than operating a separate retrieval service.
The README lists cloud and local-facing options including Ollama and LM Studio, alongside providers such as OpenAI, Anthropic, and Gemini. This gives users room to choose based on existing accounts, deployment preferences, and data sensitivity. Provider availability should not be read as a guarantee that every endpoint supports every feature equally: behavior can depend on structured output, file handling, and the endpoint’s API compatibility.
Documented capabilities
The documented inputs include Markdown, PDF, images, and Office formats such as DOCX, PPTX, and XLSX. The project also describes PDF ingestion paths, a MinerU-based multi-format backend, verbatim source-page quotations, candidate gates, health scans, and bulk fixes. The interface and generated wiki output have separate multilingual support. Exact behavior for each language and format should be checked against the documentation for the version being deployed.
Model calls are central to retrieval, question answering, and page generation. Repository metadata identifies the project as Apache License 2.0 and shows that the repository is not archived. Release 1.27.2 is particularly relevant for operators: its notes say that a response cut off by the token limit is no longer written over an existing page, and that ingest state is released when a file is skipped or a task is cancelled.
Limitations and deployment considerations
A graph-based retriever does not make generated answers automatically correct. Link quality, note structure, model behavior, and generated-page review all affect the result. The 1.27.2 release notes document fixes for content-loss classes caused by incomplete model output, so users should treat backups and version control as operational requirements. Test bulk ingestion on a copy of the vault before applying it to primary material.
“Local-first” also does not mean that every processing step is local. When a cloud provider is selected, notes, PDFs, or extracted text may be sent to that service. The supplied sources do not establish the retention or training policies of each provider. For confidential material, review provider terms, organizational requirements, and plugin settings before ingestion.
Finally, real-world ingestion depends on parsing, OCR, context limits, model costs, and endpoint behavior. The supplied sources do not confirm universal minimum hardware requirements, performance guarantees, or a complete compatibility matrix. A cautious rollout is to pin a plugin version, test representative notes, verify generated paths, links, citations, and recovery behavior, and only then expand the corpus.
Sources
Sources checked: 2026-09-20