Graph RAG: Knowledge Graphs and Multi-Hop Reasoning

Making relationships explicit instead of implicit

Every architecture so far represents knowledge as a collection of independent chunks. Graph RAG represents it instead as a knowledge graph: a network of entities (people, companies, products, events) connected by explicit, labeled relationships ("founded," "acquired," "reports to," "supersedes"). This structure is typically built by running an extraction step, often an LLM itself, over the source documents once, ahead of time, pulling out entities and relationships the same way indexing extracts and embeds chunks.

Why this enables multi-hop reasoning

Recall the multi-hop question from Lesson 5: "which vendors raised prices after switching CEOs." A knowledge graph answers this by traversal, not similarity search: find the "switched CEO" relationship, follow it to the vendor entities on the other end, then follow each of those entities' "raised prices" relationship to check which ones also have that edge. Each step is a precise graph lookup, not a fuzzy similarity guess, so the answer is assembled correctly even though no single source chunk ever stated it directly.

What it costs

Building and maintaining a knowledge graph is significantly more upfront work than chunking and embedding: entity extraction has to be accurate and kept in sync as source documents change, and designing a good relationship schema (which relationship types actually matter for your domain) is a real modeling task, not a default setting. Graph RAG earns that cost specifically on data where relationships between things are the whole point, organizational structures, supply chains, scientific literature with citation networks, not on data that is mostly independent, self-contained documents.