Graph-based retrieval-augmented generation uses a graph of entities or relationships to select or organize information supplied to a generative model. It can support local relationship queries, multi-hop evidence gathering or broader summaries. Microsoft's GraphRAG is a specific implementation and research approach within this broader category.
A graph is useful when the relationships help answer the task. It does not make extracted claims true or automatically improve every retrieval workload.
Begin with a relationship question
Consider an illustrative service catalog:
Checkout service --depends_on--> Tax service
Tax service --owned_by----> Platform team
Platform team --on_call-----> Rotation R7
“Which on-call rotation owns the tax dependency of Checkout?” requires following typed relationships. If the catalog already stores these authoritative edges, query it directly and give the model the result plus evidence references. There is no reason to re-infer those facts from prose merely to use an LLM.
If the relationships exist only in documents, extraction may help construct a graph. The system then needs entity resolution, source provenance, time validity and a way to handle uncertain or conflicting edges.
Separate local, global and exact questions
| Question | Useful starting point | Key limitation |
|---|---|---|
| Who owns a named dependency? | Typed graph traversal or relational joins | Missing/stale ownership edges |
| What connects two projects? | Bounded graph expansion with source evidence | Connection does not establish causation |
| What themes recur across a corpus? | Community summaries or another coverage-aware synthesis | Summaries can omit minority evidence |
| How many orders meet a condition? | Authoritative structured query | An LLM summary is not an exact aggregation engine |
| Where is a particular rule documented? | Lexical/dense retrieval | A graph may add unnecessary cost |
Microsoft's original approach builds an entity graph and hierarchical community summaries for query-focused summarization. Its documented query modes include local, global, DRIFT and basic search. These modes address different information needs. Original paper, query documentation.
Design the ingestion path
- Parse source units while preserving document IDs, versions and permissions.
- Extract entities and typed relationships, or import authoritative structured records.
- Resolve entity identity using stable IDs, aliases and disambiguating attributes.
- Attach evidence references, validity periods and extraction/version metadata to edges.
- Build indexes for entity lookup and relationship traversal.
- Optionally detect communities and create source-linked summaries.
- Validate representative edges and summaries before making them queryable.
Not every graph requires a graph database. Small adjacency structures or relational tables may suffice; dedicated graph engines are useful when their query and operational capabilities fit the workload. Model choice for extraction follows measured accuracy and cost, not a rule that every document needs the largest available model.
A graph expansion hybrid
Read diagram source
flowchart TD
Q[Question and authenticated scope] --> R[Retrieve permitted seed passages]
R --> E[Resolve relevant entity IDs]
E --> T[Traverse allowed edge types within a budget]
G[Versioned graph with source evidence] --> T
T --> C[Load permitted supporting passages]
R --> D[Deduplicate combined candidates]
C --> D
D --> K[Rerank and pack evidence]
K --> A[Answer with verifiable sources]
This pattern expands candidates using relationships, then reranks them. Calling it only a “graph reranker” hides the fact that it can retrieve new evidence. The graph may be prebuilt, incrementally maintained or partially constructed on demand. Each option moves cost between ingestion and query time.
On-demand expansion still needs a way to discover relationships outside the initial seed passages. If the system never searches or indexes those sources, declaring a graph “lazy” does not make the missing edges available.
Bound traversal and verify edge meaning
Limit seed count, permitted edge types, hop count, visited nodes, tokens and deadline. For one seed with ten new neighbors at each step, three levels can produce 1 + 10 + 100 + 1,000 = 1,111 states before deduplication. High-degree nodes can rapidly fill the budget with weakly related material.
Use direction and relationship type. works_with is not approves, and mentioned_in is not caused_by. Preserve conflicting observations instead of merging them into a false single fact. Record when an ownership relationship was valid, especially for historical questions.
Graph connectivity is a retrieval signal. The final explanation should cite the source of important edges and identify unsupported inferences.
Community summaries and access controls
Community detection groups related entities. A summary can compress the group's information so a global query does not require loading every underlying passage at once. This helps manage context, but loses detail and can propagate extraction errors.
Evaluate coverage of themes, minority cases, contradictions and source support. For exact counts, use structured aggregation with a defined eligible set; do not ask a hierarchy of summaries to reconstruct precise totals that were discarded.
Permissions apply to derived summaries too. If a summary mixes confidential and public facts, filtering its visible citations afterward does not remove the confidential information already in its text. Build summaries for a valid access scope, recompute permitted views, or use a design that prevents mixed-scope disclosure.
Understand the related research directions
| Approach | Distinguishing idea | What not to assume |
|---|---|---|
| Microsoft GraphRAG | Entity graph plus community hierarchy and summaries | Every question needs global summarization |
| HippoRAG / HippoRAG 2 | Graph-based associative retrieval using Personalized PageRank, with richer passage integration in the second version | Benchmark gains transfer unchanged to a new corpus |
| LightRAG | Entity/relationship indexing with retrieval at different levels | A universally cheaper or more accurate replacement |
| LazyGraphRAG | Reduces upfront LLM summarization, shifting relevant work toward query time | Query-time reasoning becomes free |
| Graph-aware late chunking | Uses graph information with contextualized chunk representations in a studied domain | Biomedical results prove general production superiority |
Primary references: HippoRAG, HippoRAG 2, LightRAG, LazyGraphRAG, graph-aware late chunking.
These are distinct research and implementation choices. Avoid unsupported claims about which dominates production or that one delivers a fixed percentage of another's quality at a fixed fraction of the cost.
Maintenance and cost-benefit analysis
| Failure | Repair | Added responsibility |
|---|---|---|
| Two entities with the same name are merged | Use stable identity and disambiguation evidence | Resolution review and correction propagation |
| Deleted text still supports an edge | Maintain source-to-edge lineage and invalidate derivatives | Rebuild affected summaries and caches |
| Ownership changed | Apply versioned temporal updates | Current and historical query semantics |
| Popular nodes dominate traversal | Restrict edge types, degree and relevance | Risk of pruning useful paths |
| Summary confidently states an extraction error | Check source support and allow conflict/uncertainty | Validation and review cost |
Refresh frequency follows the freshness requirement and source changes. A quarterly schedule is inappropriate for a service catalog changing daily. Incremental updates may still invalidate summaries outside the edited document because communities and entity resolution can change.
Compare with simpler alternatives: better source parsing, hybrid retrieval, multi-query search, direct joins and coverage-aware document summarization. Classify existing failures and measure graph-specific improvements. There is no universal “30% graph-shaped failures” threshold that determines return on investment.
Budget extraction, entity resolution, graph storage, community processing, summary regeneration, query traversal and maintenance labor. Include security and deletion handling. A graph that looks compelling on a whiteboard may add little value if the original problem was missing source data.
Interview practice
Q1: When would you introduce GraphRAG?
When relationship structure or corpus-wide organization addresses measured failures that simpler retrieval does not resolve economically. I would specify the query classes and compare a bounded graph approach with the baseline, including update and permission costs.
Q2: Is a graph required for multi-hop questions?
No. An agent can issue successive searches, and structured relationships can be queried with joins. A graph can make repeated relationship traversal more explicit and efficient, but requires accurate edges and maintenance.
Q3: What makes entity extraction difficult?
Ambiguous names, implicit relations, negation, time validity and conflicting evidence. I preserve provenance and evaluate extraction accuracy separately from final answer quality. Larger models do not remove the need for these checks.
Q4: How does global summarization differ from local retrieval?
Global summarization uses broader coverage, often through community summaries. Local retrieval gathers evidence around specific entities. The former trades detail for coverage; the latter can miss broader patterns. Choose based on the actual question.
Q5: Why is lazy graph construction not automatically cheap?
It moves some extraction and reasoning to queries, where repeated work, caching, concurrency and tail latency matter. It also needs a source-discovery mechanism for relationships outside the initial candidates. Compare total workload cost.
Q6: What is the hardest access-control issue?
Derived summaries or edges can combine facts from different permission scopes. The application must ensure the derived object itself is safe to expose; hiding a restricted citation does not remove the leaked fact. Revalidation and provenance apply throughout the graph.
Q7: How would you test a graph answer?
Check entity identity, edge type/direction, temporal validity and source support, then evaluate whether the answer follows from that evidence. Include broken edges, renamed entities, permission changes and questions requiring exact aggregation.
Final notes
Recall card: Identity → typed relationships → provenance → bounded traversal → maintained summaries. A graph organizes evidence; it does not replace evidence.