Obsidian graph view for an LLM wiki

Research notes usually fail in one of two ways. Either they are raw archives, full of PDFs and copied links that are easy to store but hard to reuse, or they are polished notes that take too much time to maintain. An LLM wiki is an interesting middle ground: keep the sources as they are, but ask a language model to compile them into small, linked Markdown pages that can be opened in Obsidian.

The idea is simple. A folder contains the original material: papers, technical reports, meeting notes, links exported as Markdown, or old project notes. Another folder contains the wiki itself. Each page explains one concept, method, dataset, equation, software component, or decision. Pages link to one another using [[wiki links]], so Obsidian can display the structure as a graph and make navigation natural.

This is different from using a chatbot as a search box over a pile of files. Retrieval-augmented generation is useful when the goal is to answer a question from documents. The LLM wiki pattern adds a compilation step: after a new source is added, the model updates existing pages, creates missing pages, links related concepts, and flags contradictions. The knowledge base changes over time instead of being recomputed from scratch at every question.

For research work, that distinction matters. A PhD topic, numerical method, or code base is not a static set of documents. It is a growing network of assumptions, experiments, failures, definitions, and decisions. A good wiki page on a numerical method should not only summarize one paper; it should also point to the equations used in the code, the boundary conditions that caused trouble, the datasets used for validation, and the open questions that remain.

A practical folder layout

I would start with a deliberately small structure:

research-wiki/
  raw/
    papers/
    notes/
    meetings/
  wiki/
    index.md
    log.md
    concepts/
    methods/
    projects/

The raw/ folder is append-only. It is the evidence base: PDFs, Markdown exports, notes, and transcripts. The wiki/ folder is the compiled layer. It should be readable without opening the raw files every time.

The two most useful files are index.md and log.md. The index gives a short map of the wiki: main topics, important pages, and unresolved questions. The log records what was added, when, and which pages were modified. Without a log, it becomes difficult to know whether a page reflects last week’s sources or last year’s understanding.

What to ask the model to do

The prompt should be explicit about structure and uncertainty. A useful instruction is not “summarize these papers”; it is closer to:

Read the new files in raw/.
Update the Markdown wiki in wiki/.
Create one page per concept, method, dataset, software component, or important result.
Use Obsidian-style [[links]] between related pages.
When updating an existing page, preserve useful prior content and add new source-backed details.
Flag contradictions, missing definitions, and claims that need verification.
Update index.md and log.md.
Do not invent citations or results that are not present in the sources.

The last line is important. An LLM wiki is only useful if it remains humble. It should expose weak links, not hide them behind fluent prose.

Why Obsidian fits well

Obsidian works because it does not require a database or a special export format. The wiki is just Markdown files in folders. This keeps the notes portable and easy to version with Git. The graph view is also useful, not as decoration, but as a debugging tool: isolated pages reveal topics that are not connected; over-connected pages often mean that a concept should be split; clusters show where a project has become mature enough to deserve its own index.

Obsidian also keeps the human in the loop. The model can draft and maintain pages, but the researcher should still review important claims, rename pages, merge duplicates, and decide which contradictions are real. The workflow is better understood as assisted editorial work than as automatic knowledge management.

Maintenance rules

The wiki needs occasional linting. Every few additions, ask the model to inspect the compiled pages and report:

  • duplicate pages with different names;
  • pages that mix several concepts and should be split;
  • pages with no incoming or outgoing links;
  • claims without a source;
  • contradictions between pages;
  • obsolete statements that newer sources have superseded.

This audit pass is where the system starts to compound. The value is not only in producing more notes, but in making old notes easier to reuse.

Where this is useful

I would use this pattern for subjects that evolve over months: literature reviews, numerical methods, software architecture notes, experiment logs, or teaching material. It is less appropriate for information that changes daily or for situations where every sentence needs a precise citation trail. In those cases, a conventional search index or a stricter reference manager is still better.

The promising part is the combination of boring files and active maintenance. Markdown keeps the system inspectable. Obsidian makes it navigable. The LLM does the repetitive compilation work. The researcher keeps responsibility for judgment.

Inspired by the Data Science Dojo tutorial on the LLM wiki pattern, but adapted here for a research notebook workflow with Obsidian and Git.