LLM wikis and knowledge graphs: what should persist?

Most people talk about LLMs as if the main challenge is simply “retrieval.” Upload documents, search the documents, pass the relevant chunks into the model, and get an answer.

That is useful, but it is not the whole picture.

For many knowledge-heavy workflows, the problem is not just finding the right document again. The problem is making sure the system remembers what it has already learned, which decisions were already made, and how pieces of information relate to each other.

This note focuses on document-driven work, where the value of an LLM wiki and a knowledge graph is clearest. A companion note covers what changes once the system has to act in a world that is changing while it acts.

The limitation of ordinary RAG

Traditional RAG, or retrieval-augmented generation, works roughly like this:

This is helpful when the task is basic document Q&A. For example, if I ask, “What does this agreement say about termination?” retrieval may be enough.

But the limitation is that the model often has to rediscover the structure of the knowledge every time. It may retrieve relevant sections, but it does not necessarily remember:

• which concepts are central,
• which arguments were already rejected,
• which claim terms were already defined,
• which assumptions were chosen,
• which relationships matter,
• or how the thinking has evolved over time.

The idea of an LLM wiki

An LLM wiki is different. Instead of only retrieving pieces of text at question time, the system compiles uploaded documents into a more durable knowledge structure.

A simple version looks like this:

This matters because the knowledge does not disappear after each question. The system can build a persistent map of what it knows, refine it over time, and refer back to it the way a person would refer back to their own notes.

Knowledge graph memory

A knowledge graph adds another layer. Instead of only having wiki pages, the system also stores relationships among entities, concepts, documents, and decisions.

To make this concrete, the next two sections walk through two illustrative examples from very different domains. They are talking points, not descriptions of any particular implementation.

Example 1: patent drafting (illustrative)

Patent drafting is a useful first example because retrieval alone is clearly insufficient. A patent practitioner does not just find passages - they build up a stable view of the invention and reuse it across the specification, the claims, and the prosecution history.

If we upload invention disclosures, prior art, technical diagrams, and draft

specifications, an LLM wiki should begin forming persistent pages such as:

• Core inventive concept
• Claim elements
• Embodiments
• Alternative implementations
• Prior art distinctions
• Definitions
• Open questions
• Support mapping

A graph layer then connects them:

A graph lets the LLM ask better questions:

• What supports this claim element?
• Which prior art references overlap with this embodiment?
• Which assumptions depend on this technical feature?
• What has not been connected yet?

Example 2: foundry process design (illustrative)

In a metal casting foundry, designing a process for a new part involves a small set of recurring concepts: the part geometry, the alloy and its shrinkage behavior, the gating system that fills the mold, the risers that feed solidification, and the defects that show up when any of those are wrong.

A classical tool here is Chvorinov’s rule, which says the solidification time of a casting section is approximately proportional to the square of its modulus (volume divided by cooling surface area). Riser sizing then comes from a simple requirement: the riser must solidify after the section it feeds. That single rule ties together part geometry, alloy properties, riser design, and a whole class of shrinkage-porosity defects.

The wiki pages here look quite different from the patent example, but the shape is the same. Each part has stable pages for:

• Alloy and its shrinkage / freezing range
• Section modulus calculations
• Gating system design and rationale
• Riser sizing and the Chvorinov calculation behind it
• Known defect modes and the FMEA entries that track them
• Process decisions and the reasons they were chosen

And the relationships matter at least as much as the pages:

Without the graph, every new part starts from scratch. With it, the system can answer questions like “which past parts used a similar alloy and section modulus, and what defects did they see?” - which is exactly the kind of question a senior process engineer would ask out of habit.

What the two examples share

The domains are very different - legal drafting vs. metal casting - but the underlying memory shape is the same:

• Stable concepts become wiki pages.
• Relationships among those concepts become a graph.
• Retrieval still runs underneath, against the original source material.
• Decisions and their justifications are persisted alongside the knowledge.

This is why I think the right framing is not “RAG versus no RAG.” Retrieval still has a role. The better question is:

A combined architecture

For a document-driven workflow, the layers fit together roughly like this:

But what about systems where the world is changing?

Patents and foundry process design are largely document-driven. The world that the knowledge describes does not change much while the LLM is thinking about it.

That assumption breaks down quickly elsewhere. A robot on a factory floor, a fleet of delivery vehicles, a warehouse with inventory moving every minute, a lab automation run mid-protocol - none of these can be served by documents and a graph alone. The system has to remember what it just did, what changed because of it, and what is true right now.

That is a different kind of memory, and it is the subject of the next note.