When chunks aren't the unit of knowledge
Every retrieval system we've covered so far operates on the same assumption: that knowledge lives in chunks. Embed the chunk, store it, find the nearest ones at query time. For most questions — lookup questions, specific-fact questions, "what does this documentation say" questions — that assumption holds up perfectly well.
But some questions don't have answers in any single chunk. "What are the main themes across all our customer interviews?" or "How are the research groups in this corpus connected to each other?" — these questions require synthesizing relationships across dozens or hundreds of documents. A vector search returns the most similar fragments; it has no concept of the structure that spans them.
Graph-based retrieval is the answer to that class of problem. Instead of treating a document corpus as a bag of passages, it treats the corpus as a network — entities connected by relationships — and retrieves by traversing that network. The results look completely different from chunk retrieval, and so do the tradeoffs.
Microsoft's graph approach to the whole corpus
GraphRAG, published by Microsoft Research in 2024, is the most complete graph retrieval system available today, and it starts with a question that sounds almost philosophical: what if you could answer questions not about individual documents, but about an entire body of knowledge at once?
The pipeline works in four phases. First, an LLM reads every document in your corpus and extracts entities and the relationships between them — people, organizations, concepts, events, and how they connect. Second, those entities become nodes in a knowledge graph. Third, a community detection algorithm — specifically the Leiden algorithm — partitions that graph into clusters of densely connected entities. Fourth, an LLM generates a summary for each community.
At query time, you have two modes. Local search operates like an enriched vector search: find the entities most relevant to the query, then pull their immediate neighbors and community summaries as context. Global search is the distinctive capability: it runs the query against the community summaries directly, synthesizing an answer from the thematic structure of the entire corpus — without looking at individual chunks at all.
The cost: Building a GraphRAG index is extremely expensive. Every document requires LLM calls for entity extraction, and every community requires LLM calls for summarization. This is an indexing pipeline you run once on a relatively static corpus — not something you run on a live data stream. For simple factual Q&A, you're better served by standard vector RAG, which is faster, cheaper, and actually more accurate for direct lookups.
The Leiden algorithm and why communities matter
The Leiden algorithm is the heart of what makes GraphRAG different from just building a knowledge graph. Most graph partitioning algorithms produce communities that can be poorly connected — the Leiden algorithm is specifically designed to guarantee that every community is internally well-connected, which means the LLM summaries it produces are genuinely coherent rather than arbitrary groupings.
Here's why this matters for retrieval. When you ask a broad thematic question — "what are the recurring concerns in these engineering post-mortems?" — the answer doesn't live in any node. It lives in the pattern of which nodes cluster together and what that cluster represents. The community summary captures that pattern as language the LLM can reason about directly.
GraphRAG builds communities hierarchically. At the first level, you get fine-grained clusters of closely related entities. At higher levels, those clusters merge into broader thematic groupings. You can retrieve from any level depending on how general or specific the question is — a question about a specific product team pulls from a low-level community; a question about the whole organization's strategic direction pulls from a high-level one.
Using a graph you already have
GraphRAG builds a knowledge graph from scratch, which is powerful but expensive. Many organizations already have a structured graph — a product ontology, a Wikidata export, an internal entity registry, a medical taxonomy. Knowledge Graph Augmentation is the pattern for putting that existing structure to work in a RAG pipeline without rebuilding anything.
The pattern is simpler than it sounds: run your standard vector retrieval to get the initial set of candidate chunks, then use the entities mentioned in those chunks to look up their neighbors in the knowledge graph. A one-hop traversal is usually enough — you take the entity, pull its direct connections, and add those facts to the context window before generation.
Think of it as vector retrieval for the anchor and graph traversal for the enrichment. If a user asks about a company, vector search finds the relevant passages, and the graph lookup automatically adds the company's parent organization, key products, and leadership team — facts that probably don't appear together in any single chunk but exist cleanly in a structured ontology.
When to reach for this: This pattern works best when you already have a well-maintained structured knowledge source. Building and maintaining a high-quality knowledge graph is expensive — if you don't have one already, full GraphRAG is usually better than trying to create a partial graph just for augmentation.
Query-guided traversal for broad questions
DRIFT — Dynamic Reasoning and Inference across a Focused Topic — is a query expansion technique that uses the entity graph to guide what to retrieve. Where standard multi-query generation produces linguistic variations on your question, DRIFT produces topically related context by traversing the graph in the direction the query points.
The mechanism is graph-based query expansion: identify the entities most relevant to the query, walk their neighborhood in the knowledge graph, and surface the community context those neighbors belong to. The traversal is query-focused — it doesn't explore the whole graph, just the portion most semantically connected to what you're asking about.
DRIFT sits between Knowledge Graph Augmentation and full GraphRAG in both complexity and cost. You're not rebuilding the entire graph; you're using an existing graph to generate richer, more contextually grounded retrieval for broad thematic questions where pure vector search tends to retrieve plausible but disconnected fragments.
Structure is a retrieval signal too
The clearest framing for all three patterns in this lesson: graphs make the relationships between entities retrievable, not just the entities themselves. That's the capability that vector RAG fundamentally lacks, and it's the right tool precisely when the answer to a question lives in the structure of the corpus rather than in any individual passage.
The practical decision tree is straightforward. If your questions are mostly specific and factual — "what does this document say about X" — vector RAG is faster, cheaper, and accurate enough. If your questions require synthesizing across many documents, or if you need to surface themes and connections the user didn't know to ask for explicitly, graph retrieval earns its cost. GraphRAG when you're building from scratch; Knowledge Graph Augmentation when you already have a structured ontology; DRIFT when you want graph-guided expansion without committing to a full rebuild.
In the next lesson, we'll look at what happens when retrieval becomes a loop rather than a single pass — agentic and iterative retrieval patterns, where the system decides for itself when to keep looking.