GraphRAG: Knowledge Graph-Enhanced Retrieval (2026)
GraphRAG (Microsoft, 2024) extracts entities and relationships from documents to build a knowledge graph, then uses community detection to create summaries at multiple granularities. At query time, it routes to the right graph community rather than searching individual chunks. It dramatically outperforms naive RAG on queries requiring synthesis across the full corpus ('What are the main themes?') but adds significant indexing cost and complexity.
When to Use
- ✓Analytical queries that require synthesizing information across the full document corpus ('What are the main risks across all reports?')
- ✓Multi-hop questions connecting entities across documents ('Which authors work with which companies on which topics?')
- ✓Relationship queries that vector search fundamentally can't answer ('How is entity A connected to entity B?')
- ✓Organizational knowledge management where understanding how concepts relate is as important as the content itself
- ✓When naive RAG has poor performance on global questions and you can tolerate higher indexing cost
How It Works
- 1Entity and relationship extraction: use an LLM to extract named entities (people, organizations, concepts) and relationships from each document chunk. This produces a list of (entity1, relationship, entity2) triples.
- 2Build a graph: create nodes for entities and edges for relationships. Microsoft GraphRAG stores entity descriptions and source document references alongside each node.
- 3Community detection: apply graph algorithms (Leiden algorithm) to identify clusters of closely related entities. Each community represents a coherent topic or domain within the corpus.
- 4Community summaries: use an LLM to generate summaries of each community at multiple levels of granularity (small communities → larger communities → global themes).
- 5Query routing: for local queries (about specific entities), use vector search over entity descriptions. For global queries (about themes, summaries), retrieve relevant community summaries. Many queries use both paths.
Examples
# Install and initialize Microsoft GraphRAG
pip install graphrag
# Initialize workspace
graphrag init --root ./my_graphrag
# Add documents to ./my_graphrag/input/
# Edit ./my_graphrag/settings.yaml to set your LLM model
# Build the graph (expensive — uses many LLM calls)
graphrag index --root ./my_graphrag
# Query (global = synthesizes across corpus)
graphrag query --root ./my_graphrag --method global --query 'What are the main themes in these documents?'
# Query (local = specific entity search)
graphrag query --root ./my_graphrag --method local --query 'Who is mentioned alongside AI regulation?'# GraphRAG uses this extraction prompt for each chunk
EXTRACT_ENTITIES_PROMPT = """
Given the following text, extract all entities and relationships.
Entity types: PERSON, ORGANIZATION, LOCATION, CONCEPT, DATE, TECHNOLOGY
For each entity-relationship pair, output:
(entity1 | entity_type | description) -> (relationship | strength 1-10) -> (entity2 | entity_type | description)
Text:
{input_text}
Output only the triples, one per line."""
# Example output:
# (Sam Altman | PERSON | CEO of OpenAI) -> (leads | 10) -> (OpenAI | ORGANIZATION | AI research company)
# (OpenAI | ORGANIZATION | AI research company) -> (develops | 9) -> (GPT-4o | TECHNOLOGY | language model)Common Mistakes
- ✗Using GraphRAG for simple factual queries — GraphRAG adds significant complexity (10-100x indexing cost, higher query latency). For 'what does document X say about Y?', plain RAG is better. GraphRAG shines for analytical queries that naive RAG fundamentally can't answer.
- ✗Not accounting for indexing cost — GraphRAG indexing requires one or more LLM calls per chunk for entity extraction. A 100K token corpus costs $5-50 to index depending on the model used. This is a one-time cost but plan for it.
- ✗Skipping community summary validation — LLM-generated community summaries can be wrong or misleading. Spot-check 10-20 community summaries before deploying to production.
- ✗Running GraphRAG on a corpus that changes frequently — every document addition requires partial or full re-extraction. For dynamic corpora (news feeds, live databases), the maintenance overhead is prohibitive. GraphRAG is best for static or slowly changing corpora.
FAQ
How does GraphRAG compare to naive RAG on performance?+
Microsoft's original paper showed GraphRAG improved comprehensiveness and diversity on global queries by 2-5x over naive RAG (as judged by an LLM evaluator). For local queries about specific entities, it's comparable to good naive RAG. For queries requiring synthesis ('summarize the key themes'), GraphRAG is dramatically better.
What's the total cost to index a 1M token corpus?+
Using GPT-4o-mini for entity extraction (~$0.40/1M tokens) and Claude Haiku for community summaries, a 1M token corpus costs approximately $10-50 to index fully. Using GPT-4o for extraction costs $30-150. This is a one-time cost amortized over all queries. The graph storage itself is negligible.
Is Microsoft's GraphRAG the only option?+
No. LlamaIndex has PropertyGraphIndex (similar approach, more customizable). Neo4j has GraphRAG tooling. NebulaGraph and Tigergraph have LLM integrations. For simpler relationship queries without full community detection, a property graph with LLM-generated relationships often suffices at lower cost than full GraphRAG.
Can GraphRAG and vector RAG be combined?+
Yes — this is the recommended approach. Use vector RAG for local, specific queries and GraphRAG for global, analytical queries. A router LLM classifies the query type and dispatches accordingly. This gives you the best of both worlds with manageable complexity.
How do I handle entity disambiguation in GraphRAG?+
Entity disambiguation (determining if 'Apple' means the company or the fruit) is a known weakness of LLM-based entity extraction. Microsoft's GraphRAG handles this through entity deduplication post-extraction. For high-precision use cases, add a disambiguation step that uses context to resolve entities before building the graph.