01
The question is whether structure is worth precomputing
A vector index asks which chunks are close to a query in embedding space. A graph index also asks which entities recur, how they are connected, which groups form, and what evidence produced each connection.
That distinction matters for questions such as “What are the major positions across this archive?”, “Which organisations bridge otherwise separate programs?”, or “Where do accounts of the same event conflict?” No single paragraph is likely to answer them. Microsoft's original GraphRAG paper describes this as query-focused summarization over a whole corpus: a task where retrieving a handful of similar chunks is structurally insufficient.
Decision rule
Pay the indexing cost when the expensive question concerns relationships, recurring groups, or the collection as a whole.
02
Six stages of indexing
Standard GraphRAG uses a language model to extract and summarise information, then graph algorithms to find groups of related entities. It saves each stage in tables that link the results back to source passages.
01
Chunk the corpus
Documents become overlapping text units with stable source links.
The system can return from an answer to the exact passage that supplied it.
02
Extract entities
A model identifies recurring people, organisations, places, events, and domain objects.
Mentions that use different wording can be assembled around one entity.
03
Extract relationships
The model describes how entity pairs are connected inside each text unit.
Retrieval can follow a chain of evidence instead of relying only on semantic similarity.
04
Consolidate descriptions
Repeated observations of an entity or relationship are summarized across the corpus.
The index carries a corpus-level view while retaining links to its observations.
05
Detect communities
Leiden clustering partitions the graph into densely connected groups at multiple levels.
The resulting groups make relationships across documents easier to explore.
06
Write community reports
A model summarizes the entities, relationships, and claims inside each community.
Global questions can be answered over prepared maps of the corpus rather than a few nearest chunks.
The graph is inferred, not discovered as ground truth. Entity extraction, relationship descriptions, and community reports all remain model outputs that must be traceable to source text.
03
Precomputation creates different ways to ask
GraphRAG keeps ordinary vector retrieval as a baseline, then adds three graph-aware query strategies. Local search gathers an entity's graph neighbourhood and source text. Global search runs map-reduce over community reports. DRIFT uses community information to broaden the starting point of a local investigation and generate follow-up questions.
| Query mode | Question it can serve | Best use | Failure boundary |
|---|---|---|---|
| Basic vector search | Which passages look most like this question? | Known concepts and passage-scale facts | A theme distributed across many documents may never rank as one of the nearest chunks. |
| Local graph search | What is connected to this entity, and which source text supports those connections? | Entity-centred investigation and multi-hop context | It depends on the extraction having found and joined the relevant entities correctly. |
| Global graph search | What does the collection say as a whole? | Themes, tensions, repeated patterns, and corpus-level summaries | It pays the largest indexing and query cost, and community reports are model-generated interpretations. |
| DRIFT search | Which community gives this specific question a better starting point, and what should be followed next? | Questions that begin locally but need broader context | Breadth improves only when the community structure is useful. |
04
How to trace an indexing error
A final answer hides where an indexing error entered the pipeline. An inspectable graph makes each transformation visible. If a community makes no sense, the operator can move backward: inspect its member entities, inspect their relationships, then open the text units that caused those edges.
| Artifact | Question it answers | Failure it can expose |
|---|---|---|
| Text units | Did parsing preserve the source, and can every extracted object return to a passage? | Missing text, broken page extraction, duplicated chunks |
| Entities | What did the model decide exists in the corpus? | Aliases split into separate nodes, generic nouns promoted to entities, important actors omitted |
| Relationships | Why are two entities connected, and in which passage? | Unsupported edges, reversed direction, weak co-occurrence presented as a meaningful relation |
| Communities | Which groups emerge from graph topology? | One giant cluster, isolated noise, unstable grouping caused by poor extraction |
| Community reports | How did the model interpret each cluster? | Claims that outrun the graph, summaries dominated by one document, lost disagreement |
These records help diagnose errors. Workflow progress, provider errors, cache hits and record counts also help distinguish a sparse collection from a failed extraction job.
05
Local and cloud builds exchange time, cost, privacy, and model quality
Graph construction is dominated by repeated completion calls: extraction per text unit, consolidation across repeated entities, and report generation per community. Embeddings add another pass. A local Ollama build pays with workstation time and memory but keeps document content on the machine. A cloud build pays per token and sends text to the configured provider, but can run more requests concurrently and use a stronger model.
| Build | Choose it when | Primary constraint |
|---|---|---|
| Local / Ollama | The corpus is sensitive, cost matters more than elapsed time, or repeatable offline work is required. | Model download, local memory, thermal load, and slower serial inference. |
| Cloud / OpenAI | Time and extraction quality matter more than provider cost, and the documents may be sent to the API. | Token cost, rate limits, credential scope, and external data processing. |
06
A graph can make model error look structural
The main risk is error propagation. A missed alias splits one actor into two nodes. A vague relationship produces a misleading edge. Those errors alter community detection; the altered community then shapes its report and every global query that reads it. More preprocessing therefore creates more query capability and more places to audit.
When to use it
The answer should trace back to its source text.
For lookup-heavy corpora, strong chunking, metadata filters, and vector retrieval may remain the better engineering choice.
07
Inspect the index with GraphRAG Workbench
The open-source workbench wraps Microsoft GraphRAG 3.1 in a local application. PDFs become source-linked text units; the graph populates as artifacts are produced; entities, relationships, communities, and terminal output remain inspectable. The Builder can run against local Ollama models or a configured cloud provider without editing environment files.
LOCAL / OLLAMA
Local inference · workstation time and memory
CLOUD / OPENAI
Provider processing · token charges08
Primary sources
- Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization
The original method and evaluation for global corpus questions.
- Microsoft GraphRAG indexing dataflow
The current document, text-unit, entity, relationship, community, report, and embedding pipeline.
- Microsoft GraphRAG indexing methods
The distinction between model-driven Standard GraphRAG and lower-cost FastGraphRAG.
- Microsoft GraphRAG query engine
Basic, local, global, DRIFT, and question-generation query modes.
- Microsoft GraphRAG architecture
Workflow composition, provider factories, and caching for repeatable indexing.