RAG vs. LLM Wiki vs. Knowledge Graph: Why Retrieval Is Not Memory

Retrieval-augmented generation re-derives knowledge from your documents on every query and forgets the result. An LLM wiki does the extraction once and writes it down as pages the model reads afterwards. A knowledge graph extracts the relations instead of the prose, and lets the model traverse them. These are three different answers to the same problem — how an AI reaches knowledge that isn't in its weights — and they are not mutually exclusive.

Which one you need depends on your objectives and on how much maintenance you can carry. This page compares them on the same question, over the same knowledge base — it covers the semantic layer of an AI knowledge base, and assumes the storage layer already exists.

 

What RAG Does, and Where It Stops

By default, an LLM pointed at your knowledge base uses vector similarity search. Your query is embedded, the chunks closest to it in that embedding space are retrieved, they are assembled into a context window, and the response is generated from that context.

For lookup this is the right mechanism and hard to beat. For anything else it has a structural limit: similarity is not relevance. Insights tend to live in the gaps between well-covered areas, or require multi-hop reasoning across paths that no single chunk contains. A chunk that would complete an argument but shares little vocabulary with the question never gets retrieved, because nothing in the ranking knows it is related.

The second limit is that nothing is retained. Every session re-derives its context from scratch, so a cross-reference the model made yesterday has to be rediscovered today — and as a conversation grows, its context becomes less relevant, which is why long chats drift towards the generic.

Frontier models now ship their own retrieval harnesses that partly compensate for both. They are also deliberately undocumented — a competitive advantage is not a specification. That opacity removes observability and control: you cannot see what was retrieved, why, or what was skipped, so you cannot steer it. Adding your own semantic layer is how you get that back, and it has a second benefit — you end up understanding the shape of your own material.

 

Option 1 — A Knowledge Graph

A knowledge graph represents the concepts in your knowledge base as nodes and their relations as edges. It is the cheapest of the three layers to set up and to maintain, because it is generated from your material rather than written alongside it — nothing in your vault changes.

With the InfraNodus skill, you generate a graph per folder; the skill records them in a manifest.json and adds instructions to CLAUDE.md telling the model when to consult which. Asked a question, Claude reads those instructions and queries the relevant graph.

Underneath is GraphRAG: the context is built not only from statements that mention the topic you asked about, but from graph traversal around it. Ask about topic A and the retrieval also follows the relations connecting A to B, and B to C and D. The context that reaches the model is a neighbourhood rather than a list of near-duplicates.

The graph also does something retrieval cannot: it measures gaps. Community detection identifies the topics that have formed, betweenness centrality identifies the concepts holding them together, and pairs of topics that both exist without being connected are the structural holes. An answer can then address the question and bridge a gap in the surrounding context, which is how latent ideas resurface instead of staying buried.

Other tools build graphs too — Graphify parses a repository into a local graph and traverses it with a Python script, Neo4j if you want to run the database yourself. In our experience Graphify pushes its own tool use ahead of the model's rather aggressively, which is occasionally useful as a second opinion and occasionally in the way. Neither does gap analysis.

 

Option 2 — An LLM Wiki

An LLM wiki is a wiki for your model: a structured, machine-written representation of what is in your vault. Instead of retrieving context from the source files, the model reads pages that already state the main ideas and how they relate, then goes to the sources for detail. The pattern comes from Andrej Karpathy — raw documents in a raw/ folder, model-written pages in wiki/ linked with [[wikilinks]], generated results in output/ — and the LLM Wiki skill scaffolds it.

What it buys you over plain retrieval is durability. Extraction happens once. Syntheses and cross-references made in one session are still there in the next, in a form you can read and correct by hand.

The cost is that it writes into your vault. A wiki is a layer of machine-generated content, and mixing it with your own notes makes the boundary between what you wrote and what a model inferred hard to see later. Run it in a separate folder. Copy the documents on a given topic into it, build the wiki there, and integrate what you get back into the main base by hand. This is the single most common mistake with the pattern and the easiest to avoid.

 

Option 3 — Both

The two layers are complementary rather than competing. The wiki gives the model a high-level account of the material in language; the graph gives it a structural account it can measure and traverse. Used together, the model has both an overview of the context and the ability to find non-obvious paths through it.

The InfraNodus LLM Wiki skill does this in one pass: it builds the wiki and generates knowledge graphs from that same content, then consults the graphs for the queries where structure matters — gap analysis, research questions, anything asking what the material implies rather than what it says.

Above this sits a fourth option that is usually overkill for individuals and small teams: a custom ontology with a database layer, the approach behind enterprise systems like Palantir's. It produces very precise answers and takes real engineering to build and maintain. A wiki plus a graph gets most of the way there for a fraction of the work — and if what you need is the ontology's reasoning discipline rather than its database, an AI reasoning graph gets you typed relations, constraints, and explicit reasoning paths in plain text.

 

The Same Question, Three Paths

A knowledge base containing the Claude Code documentation, and the question "tell me about prompt caching". What happens between the question and the answer:

The answers differ in kind, not only in quality. Retrieval restates the caching page. The wiki situates it — caching explained through the statelessness that makes it necessary, because the wiki holds both concepts and the link between them. The graph gets to the mechanism and the cost model, because traversal pulled in the neighbouring concepts rather than the similar sentences.

The wiki path is worth watching once, because the reasoning is visible in a way retrieval never is. The model opens index.md in the wiki/ folder, reads the concept list and the log, locates the page that holds the relevant knowledge, and only then answers. You can follow every step and correct any of the files it read.

And the graph can do something none of the three answers show: tell you that the documentation covers caching and statelessness in detail and connects them nowhere. That is a fact about the knowledge base rather than about the question, and no amount of reading it will surface.

 

Which One to Use

If your knowledge base is mostly reference material and your questions are mostly lookup, retrieval is already enough and adding layers will slow you down.

If you are doing research — where the point is to find what your material implies rather than what it states — start with the knowledge graph. It is the cheapest layer to add, it leaves your files untouched, and gap analysis is the capability the other two don't have.

Add an LLM wiki when you are working a specific corpus hard over weeks and want the model's understanding of it to persist and be editable. Run it in its own folder. If you are doing both, the LLM Wiki skill generates the graphs alongside the pages, so it is one setup rather than two.

 

Set It Up

• InfraNodus skill — run /infranodus in a vault or repository to generate graphs per folder and write the manifest.
• LLM Wiki skill — scaffolds the raw / wiki / output structure with ontology generation and gap detection at each stage.
• MCP server — network analysis and GraphRAG retrieval available to Claude as tools.
• API and GraphRAG endpoints — the same retrieval for your own pipeline.
• GraphRAG documentation — how the traversal and context construction work.

 

FAQ

 

---

Add a Semantic Layer

Give your model a structural view of your knowledge base — the topics inside it, the concepts that connect them, and the gaps between them:

Sign Up     Log In