Knowledge Graph Retrieval
Level 4 of Retrieval
Maturity Levels: store knowledge as typed entities and the
typed relationships between them, then retrieve by tracing
relationship chains. Entities carry a type (Jordan is
a Person, Acme is a Company, PostPilot is a
Tool) and edges carry meaning (Jordan —works-at→ Acme,
Acme —endorsed-by→ PostPilot,
PostPilot —competitor-of→ Cadently). This answers "trace
topic X back to topic A" — the CRM-shaped questions where the value is
in the connections, not the documents. Tools: LightRAG/GraphRAG, Logseq,
Graphir. It is typically the most complex and expensive
layer to build, but can be lighter at retrieval than reading
whole files — following a typed edge to ElevenLabs beats
reading an entire AI-video-production file to find it.
The sharp distinction this concept enforces: a backlinked
wiki is not a knowledge graph. Obsidian-style links are untyped
"see also" / backlink connections — "these two pages are related
somehow" — with no statement of how (endorses,
builds, competes-with). They can achieve a
similar feel and are genuinely useful, but they don't carry
relationship semantics, so retrieval can't reason over the edges. If you
don't need relationship chains, you don't need a knowledge graph; per Query-Shaped Storage, reach for it
only when the questions themselves are about how a cast of entities
relate.
Claims
- A knowledge graph stores typed entities and typed relationships; retrieval traces the edges. observation — a factual description of the level-4 architecture and what it buys: relationship-chain answers.
- A backlinked wiki is not a knowledge graph — its links are untyped "see also," not typed relationships. principle — durable: the distinction is the presence of relationship semantics; conflating the two hides what graph retrieval can actually do that backlinks can't.
- Knowledge graphs are the most complex and expensive layer, but can be lighter at retrieval than reading whole files. observation — a tradeoff, not a pure cost: build cost is high, per-query cost can be low.
- Use a knowledge graph only when the questions are relationship chains across a cast. best practice — context: CRM-like domains with many related entities; "best" is a graph precisely when the query is about connections, and overkill otherwise. The underlying data often already exists in your files and can be embedded into the graph.
- In the wild, operators call a backlinked wiki a "knowledge
graph" or "mind map" — a concrete instance of the distinction to hold,
not collapse.
observation — a source (Nate
Herk) demos an Obsidian Compiled
Knowledge Base as his "knowledge graph"; its links are untyped
backlinks, though it does add typed folders
(
entities/concepts/sources/topics), which is folder-level typing, not typed edges. The colloquial usage is exactly why the backlinks≠graph line is worth enforcing.
Related
- Retrieval Maturity Levels — level 4 on the ladder.
- Semantic Retrieval — level 3; similarity-by-meaning, distinct from typed relationships.
- Query-Shaped Storage — reach for a graph only when the query is relationship-shaped.
- AI Second Brain — one (heavy) retrieval style a folder in the brain can use.
- Compiled Knowledge Base — a backlinked compiled wiki is often called a knowledge graph but isn't one; the untyped-backlinks-vs-typed-edges line is what separates them.
- Distillate: Every Level of a Claude Second Brain Explained
- Distillate: Fable 5 + Karpathy's LLM Wiki is Basically Cheating — a backlinked wiki demoed as a "knowledge graph / mind map."