GraphRAG: Retrieval Over a Knowledge Graph

GraphRAG retrieves over a knowledge graph of entities and relationships, often with community summaries, so multi-hop and corpus-wide questions can use structure that vector top-k alone misses. The family name covers any RAG that queries an entity graph; Microsoft Research’s Edge et al. 2024 system and the open-source microsoft/graphrag library are one widely documented implementation of that family, not the only one. Neo4j’s “What is GraphRAG as a retrieval architecture?” guide and IBM Think’s GraphRAG topic page both open by contrasting vector-only retrieval with graph-backed retrieval. It states how the graph is built, how local and global query modes differ, where indexing cost concentrates, and when vector RAG still wins, with depth for the Microsoft package routed to its leaf and cheaper dual-level variants routed to LightRAG among the failure that motivated it.

What is GraphRAG as a retrieval architecture?

GraphRAG is retrieval-augmented generation that indexes a corpus as entities, relationships, and often hierarchical community summaries, then answers by traversing or aggregating that structure rather than only ranking similar text chunks. Microsoft’s GraphRAG documentation (microsoft.github.io/graphrag, as of the September 2026 capture) defines the process as extracting a knowledge graph from raw text, building a community hierarchy, generating summaries for those communities, and using those structures at query time. Neo4j’s GraphRAG explainer frames the same idea as using a knowledge graph so a document can help even when it does not share embedding neighbourhood with the query phrasing. IBM Think describes GraphRAG as organizing entities into hierarchical communities so pregenerated community summaries can support sense-making over large private corpora.

The name needs a boundary. “GraphRAG” in practitioner search often means the Microsoft Research approach associated with Edge et al. 2024 (arXiv:2404.16130) and the modular library at github.com/microsoft/graphrag. The same word also names the broader pattern of graph-backed RAG that Neo4j, Databricks, and others describe without requiring Leiden community summaries. Package depth for the Microsoft indexer, DRIFT search, and LazyGraphRAG variants lives under Microsoft GraphRAG. The substrate that makes relationships first-class storage is covered under knowledge graphs. Flat retrieve-then-generate without a graph remains the baseline leaf when the question is a single-passage lookup.

Microsoft’s documentation states two failure classes where baseline vector RAG performs poorly: questions that must connect disparate pieces through shared attributes, and questions that need holistic understanding of summarized concepts over large collections. Edge et al. 2024 evaluate global sensemaking on corpora in the roughly one-million-token range and report substantial improvements versus conventional RAG on comprehensiveness and diversity in that setting. Those are qualitative claims from the paper’s framing; no invented win-rate percentage for Microsoft GraphRAG appears here. What the definition settles is the retrieval unit: relationships and communities become first-class context, which raises the next question of how that graph is built at index time.

How does GraphRAG build the knowledge graph?

GraphRAG builds the knowledge graph at index time by slicing the corpus into text units, extracting entities and relationships with an LLM, assembling the graph, detecting communities, and writing summaries bottom-up before embedding graph text for hybrid lookup. Microsoft’s documented Index process (as of the September 2026 capture) lists six structural steps: slice the corpus into TextUnits; extract entities, relationships, and key claims from each unit; assemble the graph; run hierarchical clustering with the Leiden technique; generate community summaries from the bottom up; and use those structures, with embeddings of entity, relationship, and community text, when answering. Neo4j’s construction section and IBM Think’s community description share the same spine even when the store is a property graph rather than the Microsoft pipeline’s default layout.

Does GraphRAG still use vector embeddings? In the Microsoft-documented pattern and in Neo4j-style hybrid stacks, yes: vectors find entry points into entities or text units, and the graph supplies neighbourhood context and community summaries that cosine similarity alone would not assemble. GoodData’s GraphRAG write-up (Medium, GoodData.AI Developers) contrasts top-down ontology-first graphs with bottom-up data-first extraction; both still end in a traversable graph plus retrieval. The important cost implication is already visible here: every text unit typically triggers an LLM extraction call, and every community typically triggers a summary call, so index spend scales with corpus size and community count rather than with a single embedding pass.

What a graph stores as a retrieval substrate, including ontology and curation overhead, is owned by the knowledge-graphs node. Runnable wiring through Neo4j GenAI, LangChain, or LlamaIndex property graphs is owned by pipeline build. The mechanism stops at the reference pattern so query modes can be stated without turning into a CLI walkthrough.

How does GraphRAG answer a query?

GraphRAG answers a query by choosing a search mode that matches the question shape: local search for entity-centred questions, global search for corpus-wide themes, optional DRIFT hybrid behaviour in the Microsoft stack, and basic vector search when top-k chunks are enough. Microsoft’s query documentation describes local search as matching entities in the question and fanning out to neighbours, relationships, chunks, and nearby community context. Global search runs a map-reduce over community summaries for questions such as “what are the main themes in this corpus?” DRIFT search is named in the same docs as a hybrid that starts from community context and then fans into local follow-ups; its configuration depth belongs on the Microsoft leaf. Basic search remains available when the question is a conventional similarity lookup.

IBM Think’s component sketch (query processor, retriever, organizer, generator) is a useful vocabulary for the same idea without locking the reader to one vendor CLI. Databricks’ GraphRAG blog emphasises exact matching during retrieval when ambiguity is unacceptable, which is why local neighbourhood traversal earns its keep in compliance and curated domains even when embeddings remain in the stack for fuzzy entry points. Neo4j’s retriever types section similarly separates graph querying patterns from “dump the nearest chunks into the prompt.”

Mode choice is the operational skill: global search can be powerful and expensive because it processes communities; local search stays cheaper when the question names a concrete entity. That cost difference is why indexing and query economics must be treated as first-class, not as a footnote under benefits lists.

How expensive is GraphRAG?

GraphRAG is expensive primarily at index time, because LLM extraction runs per text unit and LLM summarisation runs per community, and global queries then spend tokens in proportion to how many communities must be read. The microsoft/graphrag GitHub README warns that GraphRAG indexing can be an expensive operation and tells operators to read the cost documentation and start small. Microsoft’s process docs make the structural units clear without publishing a universal dollar figure for every corpus: extraction calls scale with TextUnits; community summaries scale with the Leiden hierarchy; global search map-reduce scales with community count and summary length.

At query time, local search is usually cheaper because it expands a neighbourhood rather than reducing across the whole community set. Global search is the mode that makes GraphRAG famous for thematic questions and the mode that can dominate token spend on large corpora. Edge et al. 2024’s evaluation framing for roughly million-token private corpora is about answer comprehensiveness and diversity on global sensemaking tasks, not a transferable cost calculator. LightRAG’s paper later measures a Legal-setup contrast in which GraphRAG-style community traversal consumed on the order of 610 level-2 communities times about 1,000 tokens each; that comparison is owned in depth on the LightRAG profile and is cited here only as evidence that community traversal is the expensive query shape.

There is no honest universal price per document for GraphRAG as a family. The operational rule is to measure extraction and summary tokens on a sample of your corpus before committing the full index, and to route dynamic-update pain or community-traversal cost to cheaper graph variants when eval allows. Writer’s product page claims material cost reductions for its own Knowledge Graph product versus traditional RAG; that is a vendor claim for Writer’s stack, not a site-wide GraphRAG benchmark, and it is not used as a crown. When the budget question is settled, the decision question is which corpora and question types justify the spend.

When should you use GraphRAG?

GraphRAG earns its keep when questions need shared entities across documents, thematic answers over a large private corpus, entity-rich domains where paths matter, or explainable relationship chains that vector similarity cannot show. Microsoft’s baseline-RAG failure cases (connect-the-dots; holistic summaries over large collections) are the positive signal. Neo4j lists enterprise-grade use cases around complex questions and knowledge that lives in relationships. Databricks frames GraphRAG as valuable when precision and exact matching matter in compliance, legal, or highly curated datasets. IBM Think’s application list (query-focused summarisation, knowledge management, decision support) is the same pattern in different words: structure must participate in retrieval.

GraphRAG is the wrong default when the labelled set is single-passage fact lookup, when the corpus is small or entity-poor, or when latency and index budget already meet the bar with vector RAG. GoodData’s closing trade-off is explicit: traditional RAG remains simpler and more efficient for straightforward use cases, while GraphRAG’s overhead buys richer multi-step answers when consistency and explainability matter. The decision matrix for pure knowledge-graph versus RAG families lives under RAG versus knowledge graph. Sibling patterns on the architectures hub remain the router when the failure is hierarchy without entities (RAPTOR), dual-level graph retrieval without heavy community traversal (LightRAG), or iterative retrieve-reason loops without a graph (multi-hop RAG).

Prove the choice on your own multi-hop and global-question labels. Vendor demos and qualitative Edge et al. claims do not transfer a win rate to an unseen corpus. Once the when-to-use gate is clear, the failure section names what GraphRAG actually prevents so teams do not expect it to fix bad extraction.

What failure does GraphRAG prevent?

GraphRAG primarily prevents the failure where single-shot vector retrieval cannot traverse shared attributes across documents or answer corpus-wide sensemaking from a small top-k chunk set. Microsoft’s documentation states those two baseline struggles directly: connecting the dots through shared attributes, and holistic understanding of summarized concepts over large collections. Edge et al. 2024 position global sensemaking on private corpora as the evaluation target for community-summary retrieval. The architecture changes the index so relationships and communities are first-class context for the generator.

GraphRAG does not by itself fix missing documents, bad entity extraction, stale community summaries, or permission leaks. Symptom diagnosis when two documents must be composed and single-shot retrieval fails lives under multi-hop retrieval failures. Iterative retrieve-reason loops that do not build an entity graph live under multi-hop architecture. If extraction invents entities or drops relationships, local and global search will confidently assemble the wrong neighbourhood; that is a data-quality failure, not a reason to abandon graph retrieval after one bad index.

Knowing the failure GraphRAG targets is what makes the implementation handoff honest: pick a stack because you measured connect-the-dots or global-theme misses, not because the pattern is trending among named RAG architectures.

How do you implement GraphRAG?

You implement GraphRAG by choosing whether you need Microsoft-style community-summary global search or entity-neighbourhood retrieval on an existing property graph, then wiring extraction, storage, and query modes without treating the mechanism brief as the runnable tutorial. The reference open-source path for the community-summary pattern is the Microsoft GraphRAG library (github.com/microsoft/graphrag) with docs at microsoft.github.io/graphrag, as captured in September 2026. Neo4j GenAI, LangChain, and LlamaIndex property-graph recipes appear throughout common tutorials and belong on pipeline build once the pattern is chosen. Package-level Microsoft options (CLI, DRIFT, LazyGraphRAG) stay on the Microsoft leaf.

When a vector store is named beside peers for the hybrid embedding layer, Weaviate leads and Pinecone, Qdrant, and Milvus follow as the wider field. Placement does not invent a GraphRAG accuracy lift for any store. Cheaper dual-level graph retrieval with incremental union updates is the LightRAG profile. Hierarchical summary trees without an entity graph are RAPTOR. Runnable, pinned builds and Docker-shaped walkthroughs live under how to build a RAG pipeline from scratch.

GraphRAG is the family of retrieval architectures that make entities, relationships, and often community summaries first-class context so connect-the-dots and corpus-wide questions can succeed where vector top-k fails. Index cost concentrates in LLM extraction and community summaries; query cost concentrates in global community traversal. Use it when your labelled multi-hop and global questions fail under naive retrieval and your corpus is entity-rich enough to repay the graph. Measure tokens on a sample before full indexing, keep Microsoft package depth on its leaf, and open LightRAG when incremental updates or community-traversal cost dominate the trade-off.