GraphRAG & Knowledge Graphs

An AI platform has 10,000 incident reports, runbooks, and trace summaries. An on-call engineer asks: "Why did inference-api breach the latency SLO during release 2026.06.14?" A simple retrieval system can find the incident about that service. But when an analyst asks: "What are the top three recurring reasons model-serving incidents breach latency SLOs?" a small top-k result set may represent only a few incidents. It doesn't itself provide coverage over recurring themes across the corpus.

The previous chapter made retrieval-augmented generation (RAG) adaptive: rewrite the query, generate hypothetical evidence, critique retrieved context, and retry when evidence is weak. GraphRAG changes a different layer. It indexes relationship structure and summaries alongside text so a system can retrieve connected evidence or corpus-level themes, at additional extraction and query cost. The engineering question is when that tradeoff complements vector search and when it adds needless complexity.

Microsoft's GraphRAG architecture addresses that query class by building a graph-based index of entities and relationships, pregenerating hierarchical community reports, and embedding text artifacts for retrieval ^{[1]Reference 1From Local to Global: A Graph RAG Approach to Query-Focused Summarization.https://arxiv.org/abs/2404.16130[2]Reference 2GraphRAG Indexing Overviewhttps://microsoft.github.io/graphrag/index/overview/[3]Reference 3GraphRAG Default Dataflowhttps://microsoft.github.io/graphrag/index/default_dataflow/}. In the original paper's global sensemaking evaluation, GraphRAG improved answer comprehensiveness and diversity over its vector RAG baseline ^{[1]Reference 1From Local to Global: A Graph RAG Approach to Query-Focused Summarization.https://arxiv.org/abs/2404.16130}. Its index also supplies structured artifacts for entity-focused local context construction. A broader roadmap by Pan et al. places this in the wider effort to combine LLMs with structured knowledge graphs ^{[4]Reference 4Unifying Large Language Models and Knowledge Graphs: A Roadmap.https://arxiv.org/abs/2306.08302}.

Picture vector RAG as a filing cabinet and GraphRAG as a case board. Vector search finds chunks that look like the question. A graph index records connections and summary layers that a query method can use when evidence spans multiple documents. Standard GraphRAG local search builds ranked mixed context from graph and text artifacts; a product that needs explicit path traversal must implement and evaluate that behavior.

Why small top-k retrieval can be insufficient

The global query problem

Consider a corpus of 10,000 incident reports, runbooks, traces, and postmortems for an AI product. It stays as the running example throughout the article.

Local queries (vector search handles well)

For a specific question about a single issue, vector search excels:

"What is the timeout for the embeddings API?" Retrieval path: top-5 similar documents, then answer from local context. This works because the needed evidence is concentrated in a few chunks.

The question is self-contained. A few chunks about the API contract and runbook contain everything the system needs.

Global queries (small top-k retrieval can miss coverage)

For a question that requires synthesizing across the entire corpus, small top-k vector retrieval can struggle:

"What are the top 3 recurring reasons model-serving incidents breach the latency SLO?" Failure mode: no single chunk contains a cross-corpus summary, and a top-5 result set is unlikely to represent themes across 10,000 documents. The resulting answer can be incomplete or misleading.

Why similarity-only retrieval struggles

Vector search retrieves the most similar chunks, not necessarily the most representative ones. When answering a global query, no single chunk may contain the complete answer. One way to create broader retrieval units is to add:

1. Entity extraction across the entire corpus
2. Relationship modeling between entities
3. Community detection to find natural clusters of related information
4. Hierarchical summarization at different levels of abstraction

A concrete multi-hop example

Before the definitions, compare the two approaches on a tiny incident corpus:

Incident 1842: "inference-api release 2026.06.14 ran in us-east-1 and hit p95 latency after redis-cache began evicting hot keys." Incident 2031: "redis-cache in us-east-1 still uses the old maxmemory policy. The config migration is blocked by a compatibility test." Incident 3155: "inference-api breached the inference latency SLO twelve minutes after deploy. Rollback restored latency."

Now ask:

"Why did inference-api breach the latency SLO, and is this likely to happen again?"

Illustrative vector-only result: Suppose retrieval finds Incident 3155 (mentions "inference-api" and "latency SLO") and Incident 1842 (mentions "inference-api" and "redis-cache"), but not Incident 2031 because it doesn't mention the service name. The answer can identify the rollout and cache eviction but miss the unresolved maxmemory policy.

Graph-enriched context: Suppose extraction produced these entities and relationships, with source-chunk provenance:

• (inference-api) --[ran_in]--> (us-east-1)
• (inference-api) --[depends_on]--> (redis-cache)
• (inference-api) --[triggered_by]--> (release 2026.06.14)
• (redis-cache) --[located_in]--> (us-east-1)
• (redis-cache) --[has_issue]--> (old maxmemory policy)
• (old maxmemory policy) --[blocked_by]--> (compatibility test)

An implementation that supports evidence-backed traversal could start at inference-api, follow depends_on to redis-cache, and retrieve evidence about both the eviction event and the unresolved maxmemory policy. It may then answer: "inference-api breached the latency SLO after a rollout, and source material ties the incident to cache evictions plus an unresolved cache policy." It shouldn't predict another breach unless source evidence supports that claim.

This is relationship-heavy retrieval: useful evidence is connected through entities that weren't all present in the query. Microsoft's standard local-search dataflow ranks graph and text artifacts into a context window; it isn't a promise that every answer executes a deterministic path. If explicit multi-hop paths matter, preserve edge provenance and test the traversal policy.

What is a knowledge graph?

A knowledge graph represents information as a network of entities (nodes) and relationships (edges). Unlike a flat vector database that stores text chunks as isolated embeddings, a knowledge graph preserves the structure of how facts connect.

The fundamental unit is the triple: (Subject) - [Predicate] -> (Object). The edge direction should reflect the meaning of the relation itself, not some generic left-to-right convention.

From our running example:

• (inference-api) --[depends_on]--> (redis-cache)
• (redis-cache) --[has_issue]--> (old maxmemory policy)
• (old maxmemory policy) --[blocked_by]--> (compatibility test)

In production, you're usually working with a property graph rather than bare triples. That means nodes and edges carry metadata like type, description, source_chunk_ids, timestamps, or confidence scores. Those extra fields matter for filtering, provenance, and ranking during retrieval.

This graph structure mirrors how operations teams reason through associations. When a query mentions redis-cache, a retrieval system can use typed relationships and provenance to distinguish service dependencies, region-specific incidents, config drift, and release side effects instead of relying on service-name similarity alone.

The GraphRAG pipeline

Phase 1: Graph construction (indexing)

The indexing phase transforms raw document chunks into a structured graph index. In Microsoft's GraphRAG docs, the standard pipeline extracts entities and relationships, optionally extracts claims, builds hierarchical communities, generates community reports, and embeds the resulting artifacts for downstream retrieval ^{[2]Reference 2GraphRAG Indexing Overviewhttps://microsoft.github.io/graphrag/index/overview/[3]Reference 3GraphRAG Default Dataflowhttps://microsoft.github.io/graphrag/index/default_dataflow/}:

Step 1: Entity & relationship extraction

The first step is to pass each document chunk to an extraction system that identifies key entities and the relationships between them. In standard GraphRAG, this is LLM-driven. In FastGraphRAG, some of this work is replaced with cheaper NLP-based heuristics to cut indexing cost ^{[5]Reference 5GraphRAG Indexing Methodshttps://microsoft.github.io/graphrag/index/methods/}. A simple extraction prompt looks like this:

In production, don't rely on raw string prompting for JSON. Use structured output frameworks like Instructor (Python) or Zod (TypeScript) with function calling or tool-use APIs to enforce schema adherence. This prevents syntax errors when processing thousands of chunks.

The runnable version below uses a deterministic extractor so you can test the graph contract without calling an LLM. In production, replace extract_from_chunk() with a structured-output model call and keep the same Entity and Relationship objects.

Step 2: Build the knowledge graph

Once the entities and relationships are extracted and deduplicated, construct the graph data structure. Mapping isolated facts from individual chunks into an interconnected network gives later retrieval policies access to relationships that weren't explicit in any single chunk.

This function takes the lists of entities and relationships as input. Using a graph processing library like NetworkX, it adds each entity as a node and each typed relationship as a directed edge with provenance and weighting metadata:

Step 3: Community detection (Leiden algorithm)

After the graph is built, we need to find natural clusters of related entities. In an incident corpus, those clusters might become themes such as cache pressure, queue starvation, release risk, and eval flakiness. The algorithm decides the groups based on how densely entities connect to each other, not on keyword matching.

The Leiden algorithm identifies these clusters. It's preferred over the classic Louvain method because Louvain can produce disconnected communities (nodes in the same group that aren't connected by edges). Traag et al. show that Leiden adds a refinement phase and guarantees connected communities ^{[6]Reference 6From Louvain to Leiden: guaranteeing well-connected communities.https://arxiv.org/abs/1810.08473}. That avoids a structural defect before report generation, although it can't correct bad entity extraction or unsupported edges. Microsoft's GraphRAG pipeline applies hierarchical Leiden recursively until communities hit a size threshold, which is how it gets both coarse and fine-grained views of the same corpus ^{[3]Reference 3GraphRAG Default Dataflowhttps://microsoft.github.io/graphrag/index/default_dataflow/}.

One quality function Leiden can optimize is modularity ($Q$), a measure of community structure quality in the extracted graph. In plain terms, modularity asks: "Are there more edges inside each group than we'd expect by chance?" A high $Q$ indicates strong clustering in that graph; it doesn't prove that extraction captured the underlying topic correctly.

For an unweighted, undirected graph, the formula is:

$Q = \frac{1}{2m} \sum_{i,j} \left[ A_{ij} - \frac{k_i k_j}{2m} \right] \delta(c_i, c_j)$

Where $A_{ij}$ is 1 if nodes $i$ and $j$ are directly connected and 0 otherwise; $k_i$ and $k_j$ are the number of edges each node touches; $m$ is the total number of edges in the graph; and $\delta(c_i, c_j)$ is 1 if the two nodes are in the same community, 0 otherwise. Higher modularity indicates better community structure.

The runnable example below computes one weighted Leiden partition with python-igraph. Standard GraphRAG recursively applies community detection to build a hierarchy; keeping this example at one level makes the clustering contract visible and keeps it fast enough to run locally.

The diagram visualizes how entities group into hierarchical communities, from specific concepts at the bottom to broad themes at the top:

Step 4: Community summarization

This function takes the entities, their descriptions, and their relationships within a community as input. It passes these to a summarizer, returning a community report that can later be used for global search ^{[1]Reference 1From Local to Global: A Graph RAG Approach to Query-Focused Summarization.https://arxiv.org/abs/2404.16130[3]Reference 3GraphRAG Default Dataflowhttps://microsoft.github.io/graphrag/index/default_dataflow/}:

Phase 2: Query processing (runtime)

GraphRAG's query engine exposes Basic Search, Local Search, Global Search, and DRIFT Search. Local and global search are the core mental model here: local search builds context for entity-centric questions, global search synthesizes over community reports, Basic Search is a text-focused baseline, and DRIFT combines community-level entry points with local exploration ^{[7]Reference 7GraphRAG Local Searchhttps://microsoft.github.io/graphrag/query/local_search/[8]Reference 8GraphRAG Global Searchhttps://microsoft.github.io/graphrag/query/global_search/[9]Reference 9GraphRAG DRIFT Searchhttps://microsoft.github.io/graphrag/query/drift_search/}.

Local search (specific questions)

Local search goes beyond named-entity matching and one-hop neighbor expansion. In Microsoft's GraphRAG docs, local search maps the query into semantically related entities, then prioritizes a mixed context from connected entities, relationships, community reports, linked text units, and optionally covariates if claim extraction is enabled ^{[7]Reference 7GraphRAG Local Searchhttps://microsoft.github.io/graphrag/query/local_search/}.

The runnable example below demonstrates a bounded neighborhood expansion for intuition. It's a custom graph-walk sketch, not an exact reproduction of the GraphRAG context builder or its ranking policy:

The actual context-builder problem includes a token budget: relevant entities, relationships, text units, and reports compete for room in one generation request. A production route needs ranking and provenance, not unbounded expansion.

Global search (broad questions)

For queries that require cross-corpus understanding, GraphRAG uses a map-reduce pattern over community reports from a selected hierarchy level. The global-search docs batch community reports into chunks, produce rated intermediate points during the map step, then aggregate the highest-value points in the reduce step ^{[1]Reference 1From Local to Global: A Graph RAG Approach to Query-Focused Summarization.https://arxiv.org/abs/2404.16130[8]Reference 8GraphRAG Global Searchhttps://microsoft.github.io/graphrag/query/global_search/}:

The level argument above hides a cost problem. Static global search maps over every community report at chosen level, so cost scales with that whole level even when most communities are irrelevant. Dynamic community selection starts near hierarchy top, rates each report against query, prunes irrelevant branches, and expands only sub-communities under surviving reports. Microsoft reports finer-grained selection with fewer reports entering map step and lower token cost at comparable answer quality.^{[10]Reference 10GraphRAG: Improving global search via dynamic community selection.https://www.microsoft.com/en-us/research/blog/graphrag-improving-global-search-via-dynamic-community-selection/} Rating calls add work, so benchmark dynamic selection against static search on your workload.

Hybrid graph-vector architecture

A useful production design doesn't treat vector search and GraphRAG as mutually exclusive. The GraphRAG stack already mixes graph structure with embeddings during both indexing and query-time context building ^{[2]Reference 2GraphRAG Indexing Overviewhttps://microsoft.github.io/graphrag/index/overview/[7]Reference 7GraphRAG Local Searchhttps://microsoft.github.io/graphrag/query/local_search/}. One hybrid architecture looks like this:

A router is a policy to evaluate, not a guarantee. Measure supported-answer accuracy, p95 latency, and spend for each query class. In a workload dominated by direct evidence lookups, a text route may cover most requests; an analyst-heavy workload may justify more graph/report queries.

One subtle detail: GraphRAG the technique doesn't require a dedicated graph database. Microsoft's reference implementation writes structured output tables to disk and builds query context from those artifacts directly. A graph database like Neo4j or Neptune becomes useful when you need custom traversals, shared KG infrastructure, or analyst-facing graph queries outside the stock pipeline ^{[11]Reference 11GraphRAG Outputshttps://microsoft.github.io/graphrag/index/outputs/}.

Query expansion and context bridging

Beyond simple routing, the knowledge graph layer can actively enrich vector results.

Query expansion uses entities found in initial vector results to expand the search query, finding semantically related but textually distinct content.

Context bridging is a custom retrieval option when two retrieved chunks don't directly connect. If edges retain supporting chunks, a traversal can identify intermediate entities for retrieval and citation. For example, if one chunk mentions "inference-api depends on redis-cache" and another mentions "redis-cache still uses the old maxmemory policy," a policy can inspect inference-api -> redis-cache -> old maxmemory policy, then fetch source text before making a claim about the latency incident.

Result ranking can boost text results with short, supported paths to query entities. Treat this as a ranker feature to evaluate, not proof that a nearby node supports the answer.

Performance considerations

Indexing cost

The biggest barrier to adopting standard GraphRAG is upfront indexing cost. Compared with vector-only RAG, its standard pipeline adds LLM-heavy graph extraction, summarization, community report generation, and multiple embedding passes ^{[1]Reference 1From Local to Global: A Graph RAG Approach to Query-Focused Summarization.https://arxiv.org/abs/2404.16130[3]Reference 3GraphRAG Default Dataflowhttps://microsoft.github.io/graphrag/index/default_dataflow/}. Whether the resulting query quality justifies that work is an evaluation question.

Mitigation strategies

To make this viable at scale, teams need to optimize the ingestion pipeline. Microsoft explicitly recommends starting with fast, inexpensive models while you learn the system ^{[12]Reference 12GraphRAG Getting Startedhttps://microsoft.github.io/graphrag/get_started/}, and their indexing-methods docs estimate that graph extraction (entity and relationship extraction plus their summarization) is roughly 75% of standard indexing cost ^{[5]Reference 5GraphRAG Indexing Methodshttps://microsoft.github.io/graphrag/index/methods/}. If your use case is mostly global summarization, FastGraphRAG can reduce cost further: it replaces LLM-based entity extraction with NLP noun-phrase extraction (using libraries like NLTK or spaCy) and defines relationships by entity co-occurrence within a text unit. The graph is noisier and less reusable outside GraphRAG, but indexing is much cheaper ^{[5]Reference 5GraphRAG Indexing Methodshttps://microsoft.github.io/graphrag/index/methods/}.

LazyGraphRAG in practice

Microsoft Research introduced LazyGraphRAG in November 2024 ^{[13]Reference 13LazyGraphRAG: Setting a New Standard for Quality and Costhttps://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/}. It targets a central cost concern with standard GraphRAG: paying for an LLM-driven index before knowing how often graph-assisted queries will run.

LazyGraphRAG defers LLM use to query time. Its index uses NLP noun-phrase extraction and graph statistics for community structure, without entity summaries or precomputed community reports. In Microsoft's reported experiment, its indexing cost matched the vector RAG setup and was approximately 0.1% of full GraphRAG indexing cost ^{[13]Reference 13LazyGraphRAG: Setting a New Standard for Quality and Costhttps://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/}. Treat that as a benchmark result, not a universal constant for every corpus and deployment. At query time it blends vector similarity with community structure and exposes a relevance test budget that trades query cost for quality. Microsoft reports that, at evaluated budget levels, LazyGraphRAG was competitive with or better than the tested alternatives on local and global query criteria ^{[13]Reference 13LazyGraphRAG: Setting a New Standard for Quality and Costhttps://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/}.

The practical takeaway is that precomputed community reports aren't the only candidate for global sensemaking. If the corpus changes frequently or global queries are rare, benchmark a lazy approach against standard GraphRAG. If reusable community reports are a product output, the standard index provides artifacts the lazy path intentionally omits.

Use observed quality and workload volume to compare indexing strategies rather than choosing from architecture labels:

Query cost

While indexing represents the bulk of the computational expense, runtime query costs can also be higher than standard vector search. The cost depends heavily on the query strategy used:

• Local search: Usually moderate. You still have to build a mixed context from entity embeddings, graph neighborhoods, text units, and community reports, but the response path is much narrower than global search ^{[7]Reference 7GraphRAG Local Searchhttps://microsoft.github.io/graphrag/query/local_search/}.
• Global search: Potentially expensive. Cost grows with the number of community-report batches you need to map over and the hierarchy level you choose ^{[8]Reference 8GraphRAG Global Searchhttps://microsoft.github.io/graphrag/query/global_search/}.

Mitigation strategies

To manage these runtime costs, standard GraphRAG precomputes community reports at multiple hierarchical levels. At query time, evaluate whether a coarse level answers the question adequately before paying for more detailed reports. Lower levels tend to yield more thorough responses, but they can also increase report volume and LLM work ^{[8]Reference 8GraphRAG Global Searchhttps://microsoft.github.io/graphrag/query/global_search/}.

Graph maintenance

Knowledge graphs aren't static; they must evolve as the underlying document corpus changes. Keeping the graph in sync with a live, mutating dataset adds engineering complexity. Current GraphRAG releases now expose explicit update flows and standard-update / fast-update methods, and the output tables include fields used for incremental update merges ^{[14]Reference 14GraphRAG CLI Referencehttps://microsoft.github.io/graphrag/cli/[11]Reference 11GraphRAG Outputshttps://microsoft.github.io/graphrag/index/outputs/}.

• Additions: When new documents arrive, the system must extract entities and relationships, then merge them into the existing graph. New connections can shift community structure, requiring reclustering and regeneration of affected reports.
• Deletions: Removing a document isn't as simple as deleting a row in a database. The system must trace and remove nodes or edges supported solely by that document. If removed evidence changes graph structure, communities and reports may need recomputation.
• Strategy: Even with update support, a deployment may prefer scheduled refreshes for structural artifacts. Entity merges, community boundaries, and report summaries can shift when new documents arrive, so online reclustering is harder to operate than plain vector re-indexing.

When to use GraphRAG

Because of the high indexing and maintenance costs, GraphRAG shouldn't be treated as a default replacement for all retrieval tasks; it's a specialized tool for complex analytical workloads. Evaluate the query profile of your application before committing to a knowledge graph architecture. This decision matrix shows where each approach fits:

Use this framework to decide:

The pragmatic path: Start with vector search. It's cheaper, faster, and easier to maintain. Only add the graph layer when you hit specific limitations:

1. Users ask questions that require synthesizing information from many documents
2. You need to trace influence chains (who reports to whom, what depends on what)
3. Global sensemaking queries are a core use case, not an edge case
4. The corpus is large enough to justify the indexing investment

Explain GraphRAG as a tradeoff

Treat GraphRAG as an engineering tradeoff, not a buzzword. If you can explain when graph structure earns its indexing and query cost, you can defend the design in a review or interview.

Key concepts

• GraphRAG adds entities, typed relationships, and community reports on top of chunk retrieval.
• Local search answers entity-centric questions with mixed graph and text context.
• Global search answers corpus-level questions with map-reduce over community reports.
• Hierarchical Leiden avoids disconnected communities before report generation; extraction quality still determines whether reports are useful.
• LazyGraphRAG shifts most LLM cost from indexing time to query time.

Skill levels to aim for

• Foundational: Explain why small top-k similarity retrieval can underrepresent global sensemaking queries.
• Intermediate: Describe the GraphRAG indexing pipeline: entity extraction, relationship extraction, entity and relationship summarization, community detection, community reports, and retrieval-time embeddings.
• Advanced: Explain why hierarchical Leiden matters for community detection and report generation.
• Advanced: Compare Local Search, which builds mixed entity/text/report context, with Global Search, which map-reduces over community reports.
• Advanced: Analyze cost and latency tradeoffs: expensive indexing buys query capabilities that plain vector search doesn't have.
• Advanced: Design a hybrid graph-vector architecture where simple lookups stay cheap and structural questions get graph context.
• Advanced: Explain how to compare LazyGraphRAG with a precomputed-report pipeline using measured quality, query volume, and index/query cost.

Follow-up questions

Common pitfalls

When engineers first encounter knowledge graphs and GraphRAG, they often bring assumptions from traditional vector search or long-context LLMs. These are the most common traps, what they look like in practice, and how to avoid them.

Mistake 1: "Use a bigger context window"

• Symptom: You stuff 100,000 tokens into a long-context model and ask for a summary. The output misses key themes or contradicts itself.

• Cause: A 1M token context window doesn't automatically solve global sensemaking. You still have to decide what to include, very large prompts are expensive to run, and models can still underuse information buried in the middle of long contexts ^{[15]Reference 15Lost in the Middle: How Language Models Use Long Contextshttps://arxiv.org/abs/2307.03172}.

• Fix: Benchmark selective retrieval and structured indexing against long-context prompting. Standard GraphRAG is one candidate when repeated global questions justify precomputed reports; it isn't required for every long document.

Mistake 2: Treating GraphRAG as a replacement for vector search

• Symptom: You replace your entire vector index with a knowledge graph. Simple lookups become slow and expensive.

• Cause: GraphRAG is complementary, not substitutive. Local search uses entity-description embeddings and linked text units as part of context construction. Global search adds report synthesis for questions that require coverage across many documents.

• Fix: Use a hybrid router. Route simple fact lookups to vector search, entity questions to local search, and global summaries to global search.

Mistake 3: Ignoring entity resolution

• Symptom: Your graph has three separate nodes for RedisCache, redis-cache, and redis.internal. Queries that should traverse through the cache dependency fail because the path is broken.

• Cause: Entity extraction from unstructured text is inherently noisy. Skipping deduplication leaves near-duplicate nodes that fragment the graph.

• Fix: Implement a three-stage resolution pipeline: (1) normalize names (lowercase, strip punctuation), (2) use embeddings or string distance to find candidate duplicates, (3) use a lightweight LLM verification step to confirm whether two names refer to the same entity before merging.

Mistake 4: Extracting every noun as a node

• Symptom: The graph balloons to millions of nodes, most of them useless. Common words like "service," "alert," and "team" become nodes with thousands of meaningless edges.

• Cause: Without a schema, the extractor treats every noun as an entity.

• Fix: Define an ontology (a typed schema) before extraction. Restrict nodes to domain-relevant types like Service, Datastore, Region, Incident, ConfigIssue, and Runbook. Filter low-information entities in a post-processing step.

Mistake 5: Underestimating indexing cost

• Symptom: The prototype works on 200 documents, then the first full-corpus run burns budget on extraction, summarization, and embedding passes.

• Cause: Standard GraphRAG does much more than embed chunks. It asks models to extract entities, extract relationships, summarize repeated descriptions, generate community reports, and embed several downstream artifacts.

• Fix: Measure indexing cost before committing to the architecture. Start with a small representative corpus, use inexpensive models while tuning prompts, consider FastGraphRAG for global-summary-heavy workloads, and set a refresh cadence instead of pretending every graph update is free.

Mistake 6: Ignoring graph maintenance

• Symptom: Search results become stale or paths break after documents are added, deleted, or corrected.

• Cause: A graph index has structure. New evidence can merge entities, change edge weights, move community boundaries, and invalidate old community reports.

• Fix: Treat graph refresh as a product requirement. Track provenance with text_unit_ids, run incremental update flows where they are good enough, and schedule full rebuilds when entity resolution or community boundaries drift.

Try it yourself

Here's a short exercise to check your understanding. Work through it on paper or in a text editor before reading the solution sketch.

The corpus

Doc A: "The inference gateway routes overflow traffic to GPU Queue B during peak load." Doc B: "GPU Queue B has a priority inversion bug that can starve batch jobs." Doc C: "Batch job #7712 was routed through the inference gateway, waited in GPU Queue B, and timed out after 18 minutes."

The question: "Why did batch job #7712 time out, and what systemic issue might cause similar failures?"

Step 1: List the entities and relationships you'd extract from each document.

Step 2: Draw (or list) the triples that connect batch job #7712 to the systemic issue.

Step 3: Explain why standard vector RAG might miss the systemic issue.

Solution sketch

Entities: inference gateway, GPU Queue B, priority inversion bug, batch job #7712, timeout.

Key triples

• (batch job #7712) --[routed_through]--> (inference gateway)
• (inference gateway) --[routes_to]--> (GPU Queue B)
• (GPU Queue B) --[has_issue]--> (priority inversion bug)
• (priority inversion bug) --[can_cause]--> (batch job starvation)
• (batch job #7712) --[result]--> (timeout)

Multi-hop path: batch job #7712 --[routed_through]--> inference gateway --[routes_to]--> GPU Queue B --[has_issue]--> priority inversion bug. The queue edge explains why that scheduler bug is relevant to this specific timeout.

Why similarity retrieval may miss it: No single document contains both "batch job #7712" and "priority inversion bug." A search for "Why did batch job #7712 time out?" may retrieve Doc C while missing Docs A and B because neither mentions the job. If extraction is accurate, a graph makes the path from job to gateway to queue bug explicit and retrievable with provenance.

When the graph earns its cost

1. GraphRAG addresses a global query problem that small top-k vector retrieval can handle poorly. Standard GraphRAG adds structure and precomputed summaries for corpus-level synthesis.

2. Standard GraphRAG is more than graph extraction. It extracts entities and relationships, can optionally extract claims, builds hierarchical Leiden communities, generates community reports, and embeds multiple artifacts for retrieval.

3. Local search (entity-centric + vector) handles specific questions like "Why did this batch job time out?" Global search (map-reduce over community summaries) handles broad questions like "What are the main themes?" DRIFT adds a hybrid middle ground, and Basic Search remains the plain vector fallback.

4. Indexing is expensive, and query cost depends on the search mode. Local search is usually manageable. Global search can get expensive if you have to map over many community-report batches.

5. Hybrid routing is an evaluation choice. Test simple questions on text retrieval and structural questions on graph/report context, then release routes that meet support, cost, and latency targets.

6. Start with vector search, add graphs when needed. GraphRAG helps with complex, interconnected datasets and global sensemaking. For simple fact retrieval, vector search remains faster and cheaper.

7. The expensive standard index isn't the only option. LazyGraphRAG (2024) moves LLM work to query time; Microsoft reported vector-RAG-like indexing cost in its comparison. Benchmark lazy and precomputed-report approaches on your query mix rather than assuming that ratio transfers unchanged.

Start by labeling 30 real queries as fact lookup, entity-specific investigation, or corpus-wide trend. Use that label table as a release gate: ship GraphRAG only for the bucket where vector retrieval fails and graph/report context improves cited-answer quality within your latency budget.