GraphRAG (Graph-based Retrieval-Augmented Generation) is an advanced evolution of traditional RAG that incorporates knowledge graphs as a structured retrieval layer. While standard RAG relies on vector similarity search to find relevant text chunks, GraphRAG uses graph-structured data — where entities are nodes and relationships are edges — to enable multi-hop reasoning over semantically distinct but logically connected information.
The core problem GraphRAG solves is that vector search alone cannot follow chains of reasoning. If a user asks “Which hotels in our portfolio have amenities similar to the ones that received the highest guest satisfaction scores?”, traditional RAG would need to find chunks that contain all of these concepts together. GraphRAG can instead traverse: Hotel → hasAmenity → Amenity → mentionedIn → Review → hasSatisfactionScore → Score, connecting disparate pieces of information through their explicit relationships.
Introduced as a research framework by Microsoft in 2024, GraphRAG has rapidly become a key architecture for enterprise AI systems that require complex reasoning over large document corpora. Benchmarks show that integrating graph-based structures into RAG workflows can improve answer precision by up to 35% compared to vector-only retrieval, particularly on questions requiring synthesis across multiple documents.
GraphRAG operates in two major phases: indexing (offline) and querying (online). The indexing phase transforms raw documents into a structured knowledge graph with community summaries:
Phase 1 — Text Chunking: Documents are split into manageable TextUnits. Phase 2 — Graph Extraction: An LLM extracts entities and relationships from each TextUnit, producing nodes and edges. Phase 3 — Graph Augmentation: Community detection algorithms (Hierarchical Leiden) group densely connected entities. Phase 4 — Community Summarization: LLM generates summaries of each community, bottom-up through the hierarchy. Phase 5 — Document Linking: Source documents are linked back to their extracted entities for provenance tracking.
The most critical step is Phase 2, where an LLM reads each text chunk and extracts structured knowledge. The LLM is prompted with an entity extraction schema (often derived from an ontology) and returns structured output:
# Example LLM extraction prompt (simplified)
Given the following text, extract all entities and relationships.
Entity types: [Person, Hotel, Amenity, Location, Event]
Relationship types: [worksAt, locatedIn, hasAmenity, attendedBy]
Text: "Sarah manages The Grand Resort in Miami, which features
a rooftop pool and hosted the 2024 Tourism Summit."
# Expected extraction:
Entities:
- (Sarah, Person)
- (The Grand Resort, Hotel)
- (Miami, Location)
- (Rooftop Pool, Amenity)
- (2024 Tourism Summit, Event)
Relationships:
- (Sarah, worksAt, The Grand Resort)
- (The Grand Resort, locatedIn, Miami)
- (The Grand Resort, hasAmenity, Rooftop Pool)
- (2024 Tourism Summit, attendedBy, The Grand Resort)
After extracting from all chunks, entities with the same name are merged and their descriptions are summarized by the LLM into a single coherent description. This deduplication step is crucial for graph quality.
Once the full graph is assembled, GraphRAG applies the Hierarchical Leiden algorithm to detect communities — clusters of densely connected entities. This algorithm recursively partitions the graph:
Each community receives an LLM-generated summary that captures the key entities, relationships, and themes within that cluster. Summaries are generated bottom-up: leaf communities first, then higher levels incorporate child summaries as context.
Community summaries are GraphRAG’s secret weapon. They act as pre-computed, thematically organized abstractions of the corpus. When a query arrives, the system can match it against these summaries rather than individual chunks, enabling answering of broad “what is the overall theme of X?” questions that vector search handles poorly.
GraphRAG supports two query modes that handle different question types:
Local Search starts from specific entities mentioned in the query, then traverses their neighborhood in the graph to gather connected context. This excels at questions like “What amenities does The Grand Resort offer?” The system identifies “The Grand Resort” as a node, follows hasAmenity edges, and collects the connected amenity nodes along with their descriptions and source text.
Global Search uses a map-reduce approach over community summaries. In the map step, each community summary is independently evaluated for relevance to the query, producing partial answers. In the reduce step, partial answers are combined and synthesized into a comprehensive final response. This handles broad questions like “What are the main trends in guest satisfaction across our portfolio?”
# Pseudocode: Global Search Map-Reduce
def global_search(query, community_summaries):
# MAP: Score each community's relevance
partial_answers = []
for summary in community_summaries:
relevance = llm.score(query, summary)
if relevance > threshold:
partial = llm.answer(query, context=summary)
partial_answers.append(partial)
# REDUCE: Synthesize partial answers
final_answer = llm.synthesize(query, partial_answers)
return final_answer
The defining advantage of GraphRAG over traditional RAG is multi-hop reasoning — the ability to follow chains of relationships across multiple entities to answer complex questions. Consider this query chain:
Property → hostedEvent → EventEvent → hasSpeaker → SpeakerSpeaker → spokeAt → Event (other events)Event → hostedBy → Property (competitor venues)Each hop follows explicit graph edges, gathering context that would be nearly impossible to retrieve via vector similarity alone because the relevant information is spread across completely separate documents.
The comparison highlights complementary strengths:
Organizations with large document corpora (contracts, manuals, reports) use GraphRAG to build knowledge graphs that connect entities across documents. A legal team can ask “Which contracts mention force majeure clauses related to the same jurisdictions as our pending litigation?” — a query requiring multi-hop traversal across contract entities, clause types, and jurisdiction nodes.
For companies managing portfolios of properties, GraphRAG connects guest reviews, property features, staff information, and event histories into a queryable graph. Questions like “What renovation investments had the strongest correlation with improved review scores?” become answerable through graph-structured retrieval that traditional RAG cannot support.
GraphRAG enables analysts to synthesize findings across hundreds of reports. By building a knowledge graph of companies, technologies, market segments, and trends, analysts can explore questions like “Which emerging technologies are being adopted by the top 5 competitors in our space?” through structured multi-hop traversal.
Complex support scenarios often require connecting information across product documentation, known issues, and resolution histories. GraphRAG enables support agents to ask “What fixes have worked for customers experiencing this error who also have this specific hardware configuration?” — traversing product, error, configuration, and resolution nodes.