GraphRAG and Knowledge Graphs

The arc has mostly retrieved passages as independent candidates. A graph adds another representation: entities connected by relationships, with links back to the text that supports them.

This is useful when questions need connections across documents or coverage of broad themes. A passage-based system can answer such questions if it retrieves enough evidence; the challenge is getting that evidence into view reliably.

Microsoft’s GraphRAG extracts a graph, groups it into communities and produces community reports. Query methods use those artifacts alongside source text. Other graph-augmented retrieval systems make different choices.

The flat-retrieval limit

Consider two passages in a fictional engineering corpus:

• [doc-1] Mira Chen designed the Orion pump.
• [doc-2] Mira Chen leads the Hydraulics department.

The question is: which department does the designer of Orion lead?

A passage retriever might return both statements, allowing the generator to join them through Mira Chen. It might also return only the design passage. A graph can store the shared entity and make the second relationship directly traversable.

A graph lookup makes a join mechanical once the edges are correct. It does not make extracted relationships true. A mistaken merge between two people named Mira Chen would create a plausible but unsupported answer.

The other use case is thematic synthesis. A narrow top-k can omit whole topics. Community reports provide a broader precomputed representation; diverse passage retrieval and hierarchical summarization are alternative ways to pursue coverage.

The GraphRAG pipeline

Microsoft GraphRAG’s standard indexing path has these broad stages. Its current query interface includes local, global, DRIFT and basic search; this post focuses on what the graph and reports contribute.

Stage 1: chunk. Same as flat RAG. Split the corpus into passages of a few hundred tokens.

Stage 2: extraction. A model identifies entities and relationships in text units, producing descriptions linked to source material. Extraction may involve multiple passes or batches; it is not necessarily exactly one request per chunk.

Stage 3: graph assembly. Aggregate extracted entities, relationships and descriptions. Equal names need not identify the same object, and different names may refer to one object.

Stage 4: community detection. Leiden refines a graph partition using a chosen quality function. It supports objectives including modularity and the Constant Potts Model. Hierarchical clustering in GraphRAG creates groups and subdivisions for report generation.

For an unweighted undirected graph, one common objective is modularity:

$A_{ij}$ indicates an edge, $k_i$ is node degree, $m$ is the number of edges, and $\delta(c_i,c_j)$ selects pairs in the same community. The score compares observed internal connectivity with a degree-based null model. The visual computes this formula on a simple graph.

Inspect whether the resulting groups support your questions. A high modularity score alone does not validate the summaries.

Stage 5: community reports. Generate descriptions of communities from their entities and relationships. Broader communities and their detailed subdivisions provide different coverage. GraphRAG level numbers increase toward more detailed subdivisions; they do not count upward toward broader abstraction.

The reports are compressed views of extracted data. Keep provenance so a report’s claim can be traced back to the source text.

Query modes: local vs global

Local search combines relevant graph entities, relationships and source text. Entity embeddings can help locate the query’s starting point. It is more than an exact name lookup followed by a fixed two-hop walk.

Global search processes community reports through map and reduce stages to answer broad questions. Precomputed reports reduce the need to reread the entire raw corpus, but query-time processing can still require many model calls.

The application chooses the query method through configuration, explicit routing, or an optional router it builds. DRIFT uses community information to broaden local exploration.

Report generation shifts some work to indexing. That cost is amortized across the queries that reuse the reports.

Worked example

The code below uses a small fictional corpus so the mechanics are independent of historical fact claims.

1. Mira designed Orion.
2. Mira leads Hydraulics.
3. Jules maintains Orion.
4. Jules works in Operations.
5. Orion uses the inlet filter.

The extractions are supplied by hand. This lets us check the graph and query without calling a model.

Entities: Mira, Orion, Hydraulics, Jules, Operations and inlet filter.

Directed relationships: Mira → designed → Orion; Mira → leads → Hydraulics; Jules → maintains → Orion; Jules → works_in → Operations; Orion → uses → inlet filter.

We use an undirected projection for community detection and retain directed edges for reporting. The toy’s greedy-modularity partition is not Leiden and does not establish a semantic hierarchy.

Starting at Mira, one undirected hop reaches Orion and Hydraulics. Two hops also reach Jules and the inlet filter. The directed, labeled triples preserve who designed or leads what.

A real global query would generate and process community reports. The toy below prints edge inventories only; it does not generate natural-language reports.

Implementation sketch

This runnable sketch uses NetworkX for graph assembly, an undirected community partition and neighborhood retrieval. Extraction is authored; generation is omitted.

import networkx as nx
 
triples = [
    ("Mira", "designed", "Orion", "doc-1"),
    ("Mira", "leads", "Hydraulics", "doc-2"),
    ("Jules", "maintains", "Orion", "doc-3"),
    ("Jules", "works_in", "Operations", "doc-4"),
    ("Orion", "uses", "inlet filter", "doc-5"),
]
 
directed = nx.MultiDiGraph()
for head, relation, tail, source in triples:
    directed.add_edge(head, tail, relation=relation, source=source)
# Community detection here uses a simple undirected projection.
graph = nx.Graph(directed)
 
# Greedy modularity is a different algorithm from Leiden.
communities = list(nx.community.greedy_modularity_communities(graph))
for i, nodes in enumerate(communities):
    print("community", i, sorted(nodes))
 
def local(entity, hops=2):
    if entity not in graph or hops < 0:
        raise ValueError("unknown entity or negative hop count")
    nodes = set(nx.single_source_shortest_path_length(graph, entity, cutoff=hops))
    return [triple for triple in triples if triple[0] in nodes and triple[2] in nodes]
 
print(local("Mira", hops=1))
# [('Mira', 'designed', 'Orion', 'doc-1'),
#  ('Mira', 'leads', 'Hydraulics', 'doc-2')]

The implementation deliberately separates an undirected clustering projection from directed relation storage. Using an ordinary graph for both would lose relation direction and could overwrite multiple relations between the same entities.

When GraphRAG earns its cost

Count requests and tokens before estimating a bill.

LightRAG uses entity and relationship retrieval at different levels; HippoRAG uses graph connectivity and personalized PageRank. Compare their extraction and indexing work on the same corpus.

Updates need a policy for affected extractions, relationships and summaries. Incremental indexing can reduce work, but stale or deleted evidence must not remain authoritative. How much recomputation is necessary depends on the implementation and change.

Graph augmentation is worth evaluating when relationship queries or corpus-wide questions matter and simpler retrieval leaves coverage gaps. Include index maintenance, extraction errors and query-time costs in the comparison.

Combining graph and vector retrieval

Graph and vector representations can complement each other. One possible query path is:

1. Run vector search to get candidate chunks.
2. For each chunk, pull the entities it mentions from the graph.
3. Expand the subgraph around those entities (one or two hops).
4. Build the prompt from both the vector chunks and the subgraph.

The resulting prompt contains source passages and relevant relationships. Microsoft’s local search also combines graph artifacts with text.

Structured extraction formats can make output easier to parse. They do not establish that an entity or relationship was extracted correctly. Validate the content as well as its schema.

Misconceptions

"GraphRAG replaces vector RAG." GraphRAG can use vector search, and graph augmentation can sit alongside passage retrieval. Compare the methods on the questions that need them.

"The graph is the answer." The graph is a lossy representation of the source text. Extraction may omit conditions or qualifiers that matter to the answer. Use graph links to locate related evidence, and return the source passages needed to support the final claims.

"Precomputed reports make global queries free." Reports avoid repeated raw-corpus summarization, but the global map/reduce stages can still process substantial text and make multiple calls.

"Leiden finds the right topics." It optimizes graph structure under a chosen objective and resolution. Extracted graph quality and semantic interpretation still need inspection.

What's next

The next post, context windows: advertised vs. effective, examines how input length and evidence position affect performance. Accepting a million tokens does not establish that a model can use every passage reliably.

Additional reading (and watching)

• Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A., Truitt, S., & Larson, J. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130. The Microsoft GraphRAG paper. Primary source for the local/global split and the Leiden-plus-community-summaries pipeline.

• Traag, V. A., Waltman, L., & van Eck, N. J. (2019). From Louvain to Leiden: guaranteeing well-connected communities. Scientific Reports, 9(1). The Leiden algorithm paper. The modularity-optimization method GraphRAG uses for community detection.

• Guo, Z., et al. (2024). LightRAG. A graph-augmented retrieval design with dual-level retrieval.

• Jimenez Gutierrez, B., Shu, Y., Gu, Y., Yasunaga, M., & Su, Y. (2024). HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models. NeurIPS 2024. Skips community summaries entirely; uses personalized PageRank over an entity graph at query time.

• Neo4j. (2024-2026). Neo4j GraphRAG Python package documentation. The production-oriented graph-plus-vector retrieval library; hybrid retrievers, integrations with LangChain and LlamaIndex.

• Blondel, V. D., Guillaume, J.-L., Lambiotte, R., & Lefebvre, E. (2008). Fast unfolding of communities in large networks. Journal of Statistical Mechanics. The Louvain algorithm Leiden builds on; useful background if you want to understand modularity optimization from scratch.

• Pan, S., Luo, L., Wang, Y., Chen, C., Wang, J., & Wu, X. (2023). Unifying Large Language Models and Knowledge Graphs: A Roadmap. arXiv:2306.08302. Survey that frames the design space of LLM-plus-KG systems and maps where GraphRAG sits within it.

• Microsoft. GraphRAG query overview, global search and local search. Current query behavior and input artifacts.