Map the relationships, or compile the knowledge first
When graph retrieval wins and loses, why the variants do not cost the same, and what a compiled wiki can and cannot hold.
On This Page
Chunk search is strong when the answer sits in one place. When the question connects facts or summarizes a whole corpus, you need a layer that stores relationships or compiles knowledge into prose ahead of time.
What graph retrieval is
Microsoft Research's 2024 approach has the model extract entities and relationships — supplies, belongs to, wrote — while indexing, build a knowledge graph, and prewrite a summary for each tightly connected community.
Four ways to answer:
- Local search looks around one entity. "Who owns project A?"
- Global search reads community summaries and combines them. "What failure shows up across projects?"
- DRIFT search starts from the broad context and narrows with follow-up searches.
- Basic search falls back to ordinary chunks.
The gap versus flat chunk search shows up on multi-hop questions and corpus summaries, and a path through the graph is easier to trace. The cost is real. Building the graph runs about 3 to 5 times a basic index, and quality depends on merging "Microsoft" with "Microsoft Corporation," or "삼성전자" with "Samsung." On a system that mostly looks up single facts, you pay more and gain little.
Same family name, different bill
| Variant | Idea | Strength | Watch-out |
|---|---|---|---|
| Microsoft GraphRAG | Extract entities and relationships, prewrite community summaries | Coverage on global questions | Many model calls at index time, very long context per question, painful rebuilds |
| LazyGraphRAG | Defer the heavy graph work until question time | Index cost near ordinary meaning search, reported around 0.1% of classic GraphRAG, with large cuts in global-question cost | More compute when someone asks |
| LightRAG | Dual retrieval at a specific level and a topic level | Easier to append new material | Context per question around 10,000 tokens |
| HippoRAG / HippoRAG 2 | Spread relevance the way associative memory does, covering several hops at once | Strong on multi-hop, short context, more stable as the corpus grows | A bad entity link spreads in the wrong direction |
| RAPTOR | Repeatedly summarize groups of chunks into a tree | Search at several levels of detail | Rebuild cost, and facts lost in summaries |
Where graphs win and lose
Three observations from GraphRAG-Bench, presented at ICLR 2026:
- On simple fact lookup, basic retrieval is as good or better. The graph pulls in related but unnecessary material. An earlier study it cites found graph methods 13.4% less accurate on ordinary question answering.
- On complex reasoning and contextual summaries, graphs pull ahead. The gap grows as the needed passages get farther apart.
- Context size has to be managed. When basic retrieval used about 900 tokens, Microsoft's global search grew into the tens of thousands. More text is also more noise.
When the corpus grew from about 56,000 tokens to 1.13 million, basic retrieval's accuracy on complex reasoning fell from 58.6% to 43.2%. HippoRAG 2 stayed roughly flat. One reading: as a corpus grows, meaning search collects more "similar but wrong" chunks, and an explicit entity match filters them.
Four practical rules:
- If the structure already exists — an org chart, customer to contract to owner — load it directly. Do not ask a model to rediscover it. Turning a question into a graph query is more accurate and cheaper. Extraction tools are for relationships hiding in unstructured prose.
- Relationships need a source and a valid time range. Otherwise the system says someone still owns a project they left.
- Send single-place questions to hybrid search. Send connection and global questions to the graph.
- Studying a research design is not the same as depending on that repository for a long-lived product. Check whether it is still maintained.
Compile a wiki when the material arrives
Andrej Karpathy's LLM Wiki, proposed in April 2026, reverses the direction. Instead of reassembling raw chunks on every question, the model reads sources at ingest time and maintains a Markdown wiki a person can read.
The sources are the code, the model is the compiler, the wiki is the build, a periodic lint is the test suite, and answering is execution.
| Piece | Role | Rule |
|---|---|---|
Raw layer raw/ | Papers, articles, notes, PDFs | The model may read, never edit. This is the evidence |
Wiki layer wiki/ | Source summaries, concept and entity pages, comparisons | Every page links to sources |
Index wiki/index.md | Page list and a one-line summary | The first thing read when a question arrives |
Log log.md | Ingest, query, and lint history | Append only |
| Schema file | Folders, page format, names, procedures | If this is vague, the wiki will be |
Three jobs cycle. Ingest reads new material and updates 10 to 15 related pages plus the links. Query reads the index first and opens only the pages it needs. A good answer can be filed back into the wiki, so the knowledge compounds. Lint looks for contradictions, stale claims, orphan pages, and concepts mentioned often but missing a page.
Karpathy's example, about 100 documents and 400,000 words, fit the index in context and ran without a vector store. Basic retrieval re-synthesizes on every question. The wiki reads deeply once. That helps subtle questions that need several documents, and it sidesteps a lot of chunking damage. If sources change constantly, look them up when asked. If knowledge accumulates and gets reused, compile ahead.
The limits are specific.
- Reports from practice put the comfortable size near 100 to 400 documents on one topic, about 400,000 words. Past that, the index is not enough and search comes back. qmd, a local hybrid search for Markdown, is the extension Karpathy pointed at.
- A wrong link left in the wiki contaminates later answers. Immutable sources, citations, version history, and linting are the safeguards.
- Do not mix a person's own notes with pages the model compiled.
- There is no role-based access, concurrent editing, or audit trail, so it is a poor fit for an enterprise-wide system of record.
A wiki or a graph is a useful prebuilt view of knowledge. It does not inherit the authority of the source. The dangerous loop is a model treating its own wiki as fact with no check. A practical split keeps hot, changing knowledge in the wiki and large, stable archives in search.