Knowledge Graphs for AI: GraphRAG Explained

Plain RAG retrieves chunks by vector similarity and asks the model to stitch an answer together. That works when the answer lives in one passage — and fails for holistic questions where the truth is distributed across many documents (“what themes unite this entire corpus?”). Microsoft’s GraphRAG approaches this differently: it first turns the documents into a knowledge graph of entities and relationships, then constructs a hierarchy of community summaries to answer both narrow and whole-corpus questions.

The two components

GraphRAG has two halves:

• Indexing engine — an offline pipeline that extracts a knowledge graph from raw text and builds community summaries.
• Query engine — retrieval over that index, in four modes: local, global, DRIFT, and basic search.

How indexing works

The pipeline is explicit and modular (illustrated in the ref’s architecture diagram):

LoadDocuments → ChunkDocuments → ExtractGraph → DetectCommunities
    ExtractClaims       ExtractRelationships        GenerateReports
    EmbedChunks         EmbedEntities               EmbedReports

1. TextUnits — the corpus is sliced into analyzable units with fine-grained references.
2. Graph extraction — an LLM extracts entities, relationships, and (optionally) claims from each text unit.
3. Community detection — the graph is clustered hierarchically with the Leiden algorithm, producing communities at multiple granularities.
4. Community reports — each community’s entities and relationships are summarized into a report, from “the whole graph” at the top level down to local clusters.
5. Embeddings — entity descriptions, text units, and community reports are embedded into your vector store.

The pipeline is LLM-heavy by design: entity extraction alone is roughly 75% of indexing cost. A faster, cheaper variant called FastGraphRAG substitutes NLP (noun-phrase extraction) for the LLM at index time, trading fidelity for cost.

Running the indexer

# after configuration in settings.yaml with your LLM + embeddings
env GRAPHROOT=/tmp/graphrag python -m graphrag.index --root /tmp/graphrag

# equivalent via the Python API
import asyncio
from graphrag.index import run_pipeline
from graphrag.index.io import load_pipeline_config

async def main():
    config = load_pipeline_config("settings.yaml")
    await run_pipeline_run(config)

asyncio.run(main())

The library adds an LLM cache around all model interactions so the indexer is idempotent and resilient to throttling — re-running on the same prompt returns a cached result instead of re-invoking the model.

Query modes

At query time, the structures feed the context window differently depending on the question:

• Global search — answers whole-corpus questions (“What are the most significant recurring themes?”) by reasoning across all community reports in a map-reduce fashion. Expensive but strong for holistic queries.
• Local search — drills into a specific entity by fanning out to its neighbors and associated concepts (good for “what are chamomile’s properties?”).
• DRIFT search — a newer hybrid: starts from the most semantically relevant community reports (a “primer”), then refines with local search in follow-up iterations, adding community context to local queries for better recall and quality.
• Basic search — plain top-k vector RAG, for fair baseline comparison.

The key property GraphRAG enables that flat RAG cannot: multi-hop reasoning over connected facts and explainable answer paths across documents.

Query example

# global search — the "what is this corpus ABOUT" question
from graphrag.query import GlobalSearch

result = GlobalSearch.run(
    query="What are the most important themes across all documents?",
    context_builder=...,   # built from the community report summaries
    config=...,
)
print(result.answer)

When to reach for GraphRAG

Use it when your knowledge is large, interconnected, and queried holistically: policy documents, support corpora, research literature, RAG over an entire codebase’s architecture. Skip it for “answer in one FAQ passage” use cases — plain RAG is cheaper and just as good. If you need multi-hop reasoning and corpus-level questions that naive retrieval misses, the graph pays for itself.

Putting It All Together

pip install graphrag
graphrag init --root ./mycorpus      # scaffold config
# edit settings.yaml: add embedding + LLM providers, input dir, vector store
graphrag index --root ./mycorpus      # build graph + community reports
graphrag query --root ./mycorpus      # interactive queries over the index

Conclusion & Next Steps

GraphRAG turns unstructured text into a navigable knowledge graph with community summaries, letting an LLM answer both isolated and corpus-wide questions — something naive RAG structurally cannot. Next: evaluate local vs global vs DRIFT on your own corpus, understand your indexing cost budget (entity extraction dominates), and start with the FastGraphRAG method if your goal is mostly global summarization.

References / Sources

• Microsoft GraphRAG. https://github.com/microsoft/graphrag
• GraphRAG indexing architecture. https://microsoft.github.io/graphrag/index/architecture/
• DRIFT search. https://microsoft.github.io/graphrag/query/drift_search/
• GraphRAG overview. https://microsoft.github.io/graphrag/