12 Graph-based RAG
Graph-based RAG extends standard retrieval by adding explicit relationships to the indexing and search process. Instead of treating text as isolated chunks connected only by similarity, it builds a graph of entities and edges so the system can retrieve not just what looks relevant, but what is structurally connected. This matters most for questions whose answers are distributed across documents, where the missing link is a relationship rather than a matching phrase.
The chapter groups the main designs into three patterns. One uses the graph for global sense-making by precomputing community summaries over hierarchical clusters, making it strong for broad, corpus-wide questions. Another uses the graph as an associative memory that spreads activation from query seeds to hidden bridge nodes, which helps with multi-hop reasoning. A third combines graph structure with vector search, routing queries to the most efficient path so the system can handle both specific facts and broader themes without paying the full cost of heavy graph summarization.
Each approach trades off build-time cost, query-time speed, and reasoning depth. GraphRAG offers the strongest global synthesis but requires expensive indexing and summarization. HippoRAG is cheaper to build and effective for connecting distant facts, but it does not provide rich global summaries. LightRAG aims for practical deployment by using a lightweight graph to improve retrieval quality while keeping most queries fast. The chapter closes by emphasizing that the right choice depends on whether the task is local lookup, multi-hop association, or dataset-level synthesis, and suggests that future systems may push more graph reasoning directly into the model itself.
A small knowledge graph for the authentication-service example. Three kinds of nodes: services in blue, the teams that own them in green, the incident in orange. Follow the depends_on edges into AuthService to see which services a change would touch, then the owned_by edges out of those to reach the teams that need telling. INC-2347 hangs off AuthService by triggered_by, which is how the past-incident half of the question gets answered by the same walk.
The same corpus and the same query, run through both workflows.
The summarization pyramid. The four phases of GraphRAG (extraction, community detection, hierarchical summarization, and Map-Reduce search) build and query this structure.
The associative ripple.
LightRAG's dual-path router.
Summary
- The unit of retrieval changes from the chunk to the relationship: These systems build an answer by following edges between entities instead of fetching a passage that already contains it.
- Three lineages, by what the graph is for: Global summarizers such as Microsoft's GraphRAG for sense-making across a whole corpus, associative reasoners such as HippoRAG for connecting facts that never appear together, and hybrid optimizers such as LightRAG for keeping the cost down.
- Traversal replaces similarity: Personalized PageRank walks from the entities in the query to related ones, reaching documents that share no words with it.
- Construction is where the money goes: an LLM reads every chunk and extracts entities before anything can be indexed. That upfront pass is what buys answers to the disconnected-fact questions flat RAG cannot reach.
- Text-overlap metrics cannot score this: Interaction information measures synergy directly, going negative when two passages answer a question together that neither answers alone, which is the thing the graph was built to produce.
- Nobody has published a deployment of these three: The measured production case in this space is LinkedIn's customer-service knowledge graph, which cut median per-issue resolution time by 28.6%.
Retrieval Augmented Generation, The Foundational Ideas ebook for free
