Chapter 7: Microsoft’s GraphRAG implementation

Introduction

This chapter introduces Microsoft’s GraphRAG pipeline, which builds a summarized knowledge graph and retrieves from it through global and local search.

• Microsoft GraphRAG pipeline: Describe Microsoft’s GraphRAG as an end-to-end LLM-driven pipeline that constructs a knowledge graph from source documents and emphasizes natural-language summaries of entities and relationships.
  Why it matters: This pipeline provides the organizing framework for the indexing and retrieval techniques developed throughout the chapter.
• Two-stage graph construction: Trace the two-stage process in which entities and relationships are extracted and summarized first, then communities of closely related entities are detected and given domain-specific summaries.
  Why it matters: The two levels of summaries turn disconnected information from text chunks into an organized representation that can support retrieval.
• Global and local retrieval: State that the entity- and community-level summaries in the structured knowledge graph support multiple RAG retrieval methods, specifically global search and local search.
  Why it matters: Different query needs can be served by retrieving information at either the broader community level or the more specific graph level.

Key terms: Microsoft’s GraphRAG, MS GraphRAG, knowledge graph, LLM, entities, relationships, entity summaries, relationship summaries, graph communities, community summaries

7.1 Dataset selection

This section explains how to choose a suitable unstructured-text dataset and define entity types before implementing Microsoft GraphRAG.

• GraphRAG dataset suitability: Describe the dataset characteristics that make text suitable for MS GraphRAG: rich entity information and important entities distributed across multiple text chunks.
  Why it matters: MS GraphRAG can connect information across chunks only when the source material contains recurring, meaningful entities.
• Entity type selection: Explain that entity types are configurable in MS GraphRAG and must be chosen in advance by exploring the dataset and considering the questions the application should answer.
  Why it matters: The selected entity types shape the quality of downstream extraction, linking, and summarization.
• Odyssey implementation setup: State why The Odyssey is used for this implementation and identify the required setup: an empty running Neo4j instance, either local or cloud-hosted, with the accompanying Jupyter notebook available to follow along.
  Why it matters: The example works because its narrative has recurring entities and because the implementation needs a blank database environment.

Key terms: MS GraphRAG, unstructured text documents, entities, text chunks, cross-chunk summarizations, entity types, extraction, linking, summarization, domain-specific entities

7.2 Graph indexing

This section introduces constructing a knowledge graph from The Odyssey with the Microsoft GraphRAG pipeline, emphasizing that modeling choices affect summaries and queries.

• Graph indexing roadmap: Describe the graph-indexing work introduced here: construct a knowledge graph and generate entity and community summaries while walking through the Microsoft GraphRAG pipeline.
  Why it matters: This roadmap frames the indexing stages that prepare graph data for GraphRAG retrieval.
• Indexing design considerations: Explain that entity selection and graph connectivity are key construction choices, and that they influence the quality of generated summaries and queries.
  Why it matters: These choices determine whether the indexed graph supports useful summaries and effective querying.
• Odyssey source preparation: State that the walkthrough starts by loading The Odyssey from Project Gutenberg, after which the prepared text can be processed through the MS GraphRAG pipeline.
  Why it matters: The Odyssey is the source text used as the concrete example for the pipeline walkthrough.

Key terms: knowledge graph, entity summaries, community summaries, MS GraphRAG pipeline, entity selection, graph connectivity, summaries, queries, The Odyssey, Gutenberg project

7.2.1 Chunking

This section prepares The Odyssey for MS GraphRAG indexing by splitting it along natural book boundaries, measuring token lengths, and further chunking the books with a chosen size and overlap.

• Narrative division and token assessment: Describe why the text is cleaned of prefaces and footnotes, divided into its 24 books, and measured for token length before further chunking. Explain that books are semantically meaningful natural divisions but vary enough in size to require smaller sections.
  Why it matters: Checking the natural document divisions and their sizes prevents oversized inputs while preserving meaningful narrative structure.
• Chunk size extraction tradeoff: Explain the reported relationship between chunk size and entity extraction: smaller chunks tend to yield more extracted entity references, with 600-token chunks highest and 2,400-token chunks lowest in the comparison. Describe how additional self-reflection iterations, or repeated extraction passes, increase detected entity references across chunk sizes.
  Why it matters: Chunking and repeated extraction passes influence how much graph information the LLM can identify from the same source text.
• Selected chunking configuration: State the selected practical chunking configuration: split each book using a 1,000-word limit based on whitespace splitting and include a 40-word overlap between chunks. Distinguish this chosen implementation setting from the token-sized experimental comparisons.
  Why it matters: The concrete chunk limit and overlap turn the chunking decision into indexed text units for the next GraphRAG steps.

Key terms: prefaces, footnotes, books, token counts, natural divisions, chunk size, entity references, self-reflection iterations, extraction passes, 600-token chunk size

7.2.2 Entity and relationship extraction

This section configures an LLM prompt to extract typed entities and scored relationships from The Odyssey, imports the results into Neo4j, and examines the resulting descriptions and duplicates.

• Extraction prompt structure: Describe how the MS GraphRAG extraction prompt directs an LLM to identify entities of predefined types and clearly related entity pairs, returning both in a delimited structured list.
  Why it matters: The prompt structure determines what graph-ready information the LLM extracts from each text chunk.
• Entity type selection: Explain why entity types must be chosen before extraction and describe the example types selected for The Odyssey, including why categories such as EVENT and LOCATION can be ambiguous.
  Why it matters: The chosen type set controls which parts of a narrative become nodes and which relationships can be represented.
• Chunk extraction and graph import: Trace the extraction workflow for the first book of The Odyssey: process text chunks, extract entities and relationships from each chunk, and import entities before relationships into Neo4j to build the graph.
  Why it matters: This workflow converts unstructured source text into the graph representation used by later GraphRAG stages.
• Repeated graph descriptions: Explain that the same entity or entity pair can receive multiple extracted descriptions from different text chunks, and that overlapping descriptions can preserve key details rather than necessarily indicating lost information.
  Why it matters: Recognizing repeated descriptions helps interpret raw extraction output before later summarization.

Key terms: entity_types, entity_name, entity_type, entity_description, source_entity, target_entity, entity types, PERSON, ORGANIZATION, LOCATION

7.2.3 Entity and relationship summarization

This section explains how MS GraphRAG uses LLMs to consolidate repeated entity and relationship descriptions into coherent graph summaries while managing high-volume super nodes.

• LLM-based description consolidation: Explain why MS GraphRAG merges multiple descriptions of the same entity or relationship into one LLM-generated summary. Describe how this reduces redundancy, inconsistencies, and fragmentation while preserving contextual details.
  Why it matters: Consolidated descriptions make the indexed graph more coherent and useful than a collection of disconnected extraction outputs.
• Summarization prompt requirements: Describe the instructions given to the LLM for entity and relationship summarization: merge all supplied descriptions into a comprehensive third-person description, resolve contradictions, remove redundancy, and explicitly include the relevant entity name or names.
  Why it matters: The prompt requirements determine whether a summary remains complete, coherent, and understandable outside its original text chunk.
• Entity and relationship summary workflow: Trace the separate workflows for summarizing entities and relationships: find entities with multiple descriptions or pairs of entities with multiple relationships, use an LLM to consolidate their descriptions, and store the resulting relationship summaries back in the database.
  Why it matters: This workflow turns repeated chunk-level extractions into enriched graph representations that can support subsequent GraphRAG indexing and retrieval.
• Super node summarization limits: Describe why super nodes can make summarization impractical on large datasets and state that a filtering or ranking strategy is needed to prioritize relevant descriptions so the prompt and output remain concise.
  Why it matters: Without controlling super-node inputs, too many descriptions and relationships can exceed prompt capacity or produce unhelpfully long summaries.

Key terms: entity and relationship summarization, descriptions, coherent summary, redundancy, fragmentation, summarization prompt, description list, third person, contradictions, entity names

7.2.4 Community detection and summarization

This section detects densely connected graph communities with Louvain and produces structured community summaries for downstream GraphRAG retrieval.

• Community structure and purpose: Explain what a graph community is and why detecting communities provides higher-level themes and relationships beyond individual entity connections.
  Why it matters: Communities turn many entity-level facts into meaningful groups that can be understood at a broader level.
• Louvain community detection: Describe how the Louvain method assigns detected communities as a node property, and state why the number and membership of communities can vary between runs.
  Why it matters: The detected community assignments are the input to the later community-summarization step.
• Community summary structure: Describe how a structured LLM prompt turns each community's entities, relationships, and optional claims into a report with a title, executive summary, impact severity rating and explanation, and detailed findings.
  Why it matters: Structured community reports consolidate graph evidence into concise context that can be used effectively in downstream RAG.
• Large-community input ranking: Explain why very large communities require ranking and selecting the most relevant entities and relationships before summarization.
  Why it matters: Selecting relevant graph content prevents token-limit problems and keeps generated summaries concise and useful.

Key terms: community, community detection, entities, relationships, Louvain method, node property, Graph Data Science library, non-deterministic, community summarization, TITLE

7.3 Graph retrievers

This section introduces graph retrieval after indexing and contrasts local and global search as the two approaches explored next.

• Graph retriever stage: Describe the graph retriever stage as the step after graph indexing that retrieves relevant information from the structured graph to answer queries effectively.
  Why it matters: This stage turns the indexed graph into information that can be used to answer a query.
• Local and global search: Distinguish local search from global search: local search retrieves information from entities closely connected within a detected community, while global search considers the entire graph structure to find the most relevant information.
  Why it matters: Choosing the retrieval scope determines whether the system uses nearby community information or information from across the graph.

Key terms: graph retriever stage, graph indexing, structured graph, local search, global search, detected community, entire graph structure

7.3.1 Global search

This section explains how GraphRAG global search uses a map-reduce workflow over community summaries to answer broad questions spanning an entire dataset.

• Global search purpose: Explain how global search answers broad, thematic questions by aggregating precomputed community summaries rather than retrieving individual text chunks by vector similarity.
  Why it matters: Global search is the GraphRAG retriever designed for questions whose answer is distributed across the dataset.
• Map-reduce retrieval workflow: Trace the global-search map-reduce process: retrieve community reports at a chosen hierarchy level, map their chunks into scored key points, then filter and aggregate important points as context for a final answer.
  Why it matters: The map-reduce design lets GraphRAG synthesize evidence from many semantically meaningful communities into one cohesive response.
• Community hierarchy tradeoff: Describe how the selected community-hierarchy level trades response detail against efficiency: lower-level communities are more detailed but require more LLM calls and time, while higher-level communities are more abstract and efficient but can lose granularity.
  Why it matters: Choosing an appropriate hierarchy level is necessary to balance answer thoroughness with global-search processing cost.
• Evidence-grounded map and reduce prompts: Describe how the map prompt produces JSON key points with 0–100 importance scores and report-ID references, while the reduce prompt synthesizes the ranked points into a Markdown answer that preserves evidence references and avoids unsupported claims.
  Why it matters: These prompt constraints make intermediate results rankable and keep the final answer grounded in the community-report evidence.

Key terms: global search, community summaries, community reports, vector similarity, map step, reduce step, intermediate responses, key points, importance rating, community hierarchy

7.3.2 Local search

This section implements Microsoft GraphRAG local search, which starts from semantically matched entities and combines their graph neighborhood and source text into a cited, evidence-grounded LLM answer.

• Local search purpose: Explain that local search is designed for entity-focused questions requiring detailed understanding of a particular entity and its relationships. Describe how it combines structured knowledge-graph data with unstructured source-document text.
  Why it matters: Local search provides focused answers with both relationship context and supporting document evidence.
• Entity vector entry points: Describe how local search embeds each entity's summary, stores the embedding in the database, and creates a vector index. Explain that vector similarity search uses the user query to find semantically related entities that become entry points for further retrieval.
  Why it matters: Finding the right seed entities determines which local graph neighborhood and source evidence the answer can use.
• Neighborhood context ranking: Trace how the Cypher local-search query expands vector-matched entities into connected entities, relationships, community descriptions, and associated text chunks. Describe how the retrieved context is ranked and limited to fit the constrained prompt context window.
  Why it matters: Expansion supplies contextual evidence, while ranking and limits keep the LLM prompt relevant and manageable.
• Evidence-grounded answer generation: Describe how the implementation converts retrieved local context into data tables in a structured summarization prompt and sends it to the LLM. Explain that the prompt requires data-supported claims with record references, permits at most five record IDs per reference before using '+more', and requires the model to say it does not know rather than invent unsupported information.
  Why it matters: The prompt turns retrieved evidence into a transparent answer while explicitly discouraging hallucinated claims.

Key terms: local search, entity-focused queries, structured knowledge graph data, unstructured text, entity summaries, text embeddings, vector index, vector search, entry points, Cypher statement

7.4 Summary

This summary recaps Microsoft GraphRAG’s graph-indexing pipeline, its global and local retrieval modes, and the choices that affect retrieval quality and scale.