IV · Retrieval & RAGEmerging★

GraphRAG

also known as Graph-Based RAG, Knowledge Graph RAG

Build an LLM-extracted entity-and-relation knowledge graph plus hierarchical community summaries, then answer global queries via map-reduce over those summaries.

Context

A team is using a retrieval-augmented system over a large corpus and starts receiving questions about the corpus as a whole rather than individual facts in it: 'what are the main themes in these reports?', 'how does this position evolve across the documents?', 'which entities are central to the discussion?' These are corpus-level sensemaking queries, not local lookup queries, and they arrive alongside the easier fact-style questions.

Problem

Naive retrieval pulls the top-k chunks for each query, which is fine for local lookup but cannot answer questions about the whole corpus. The answer to 'what are the main themes?' does not live in any single chunk; it requires seeing how chunks connect, what entities recur across them, and how communities of related content cluster. Without a representation that captures corpus-level structure — entities, relations, communities — chunk-level retrieval is mismatched to corpus-level questions, and the system returns confidently wrong, partial summaries that the user has no easy way to spot.

Forces

  • Indexing cost is high (LLM calls per entity, relation, community).
  • Graph quality depends on extraction prompts.
  • Local-search vs global-search modes serve different query types and must be routed.

Example

An analyst pointed at a 4000-page deal-room corpus asks 'what are the recurring risk themes across these contracts?' Naive RAG returns five chunks and an answer that misses two themes entirely because no single chunk carries them. The team switches to GraphRAG: at index time the LLM extracts parties, obligations, and clauses into a knowledge graph, clusters the graph into communities, and writes a summary of each. The corpus-wide question now map-reduces over community summaries and surfaces the recurring themes the chunk-level retriever could not see.

Diagram

Solution

Therefore:

Index time: extract entities and relations from chunks; build a knowledge graph; cluster into hierarchical communities; summarise each community. Query time: classify query as local (entity-specific) or global (corpus-wide). Local queries use entity-anchored retrieval; global queries map-reduce over community summaries.

What this pattern forbids. Global queries operate only on community summaries, not raw chunks; local queries operate only on entity-anchored neighbourhoods.

The smaller patterns that complete this one —

  • usesMapReduce for Agents★— Split an oversize task into independent chunks, process each in parallel, then aggregate.

And the patterns that stand alongside it, or against it —

  • alternative-toNaive RAG★★— Condition the generator on top-k chunks retrieved from an external dense index so knowledge lives outside parameters.
  • composes-withKnowledge Graph Memory★— Persist agent memory as entities and relations in a structured graph so symbolic queries (path, neighbour, type) become possible.
  • alternative-toHippoRAG★— Build an LLM-extracted schemaless knowledge graph from the corpus and run Personalized PageRank seeded on the query's key concepts so multi-hop retrieval completes in a single pass.
  • alternative-toHierarchical Retrieval★★— Route a query through a multi-level cascade — coarse source or index selection, then per-source narrower retrieval, then chunk-level — so each retrieval decision is pushed to the cheapest tier that can answer it.
  • complementsWorld-Model Graph Memory★— Memory store structured as a typed entity-relation graph used as the agent's authoritative world model for planning — not only for retrieval.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in frameworks

References

Provenance