TechnologyRetrieval & RAG
GraphRAG
At a glance
Build a knowledge graph from your corpus and retrieve through entities and relationships instead of isolated chunks.
- Who this is for
- Engineers and technical readers learning the terms used in AI systems.
- Topics
- Retrieval & RAG
- Technology
In short
GraphRAG is a retrieval method in which a model extracts entities and relationships from a corpus, groups them into communities, and summarizes each one, so corpus-wide questions are answered from those summaries rather than from similar passages. Bigcircle builds a graph when a question has a relational shape similarity cannot express, as on the ESG filing system, and leaves passage lookup on hybrid search with reranking. Entities are resolved at ingestion, because a wrong merge produces a graph that is consistent and wrong.
Key facts
Definition
GraphRAG is Microsoft Research's 2024 method that builds an entity and relationship graph from a corpus with a language model, clusters it into communities, and writes a summary for each community to answer questions across the whole corpus.
How Bigcircle does it
- On DocVerse, Bigcircle combines a knowledge graph with vector search, because vector search cannot express the same subsidiary two years earlier and graph traversal cannot find a narrative claim nobody structured.
- Bigcircle carries entity, period, unit and framework as hard metadata from parsing on that system, because a value inferred at query time cannot be corrected later.
- Bigcircle recommends starting a find-the-clause workload on hybrid search with reranking and adding a graph only when measured misses need one, because the graph costs model calls to build and to keep current.
Comparison
Vector RAG returns passages that resemble the question and suits answers held in one paragraph, while GraphRAG retrieves entity neighbourhoods or community summaries and suits questions about themes across many documents.
Key number
Microsoft's November 2024 post puts LazyGraphRAG indexing at the same cost as vector RAG and 0.1% of full GraphRAG, by deferring model work to query time.
GraphRAG is a retrieval method in which a language model reads a corpus, extracts the entities and relationships in it, groups related entities into communities, and writes a summary of each community. A question about the whole corpus is then answered from those summaries rather than from a handful of similar passages. Microsoft Research published the method in 2024 and maintains the open-source graphrag library.
The difference from vector RAG is what gets retrieved. Vector search returns passages that look like the question, which works when one paragraph holds the answer. It does poorly on "what are the main risk themes across all of these contracts?", because no single passage contains a theme. Edge et al. built GraphRAG for those corpus-wide questions, and on datasets of around a million tokens it beat a conventional RAG baseline on how comprehensive and varied the answers were.
How the index is built#
A model reads each chunk and extracts entities (companies, people, products, obligations) and the relationships between them. Those become the nodes and edges of a graph. The library then clusters the graph into communities with the Leiden algorithm, at several levels, and has a model write a summary for every community. At query time, each relevant community summary produces a partial answer, and the partial answers are summarized into one.
Extraction and every summary are model calls over your whole corpus, which is where the cost comes from. The library's own README warns that indexing "can be an expensive operation".
Local, global and the other search modes#
The library documents four query modes. Global search answers a broad question from community summaries. Local search starts from the entities named in the question and fans out to their neighbours, which suits questions about one customer, product or incident. DRIFT search is local search with community context added, and basic search is ordinary top-k vector search, included for questions that baseline RAG already answers.
Choose the mode from the question, not the other way round. If most of your traffic is "find the clause that says X", basic search is all you are using, and the graph is an index you pay to build and keep current. Start that workload on hybrid search with reranking, and measure whether it misses anything before adding a graph.
When GraphRAG earns its cost#
We build a graph when the question has a relational shape that similarity cannot express. On DocVerse, the ESG filing system we built, the system combines a knowledge graph with vector search, because pure vector search cannot express "the same subsidiary two years earlier", and pure graph traversal cannot find a narrative claim that was never structured. A comparison question is also broken into steps rather than answered by one retrieval: select sources, gather graph and vector evidence, build the claims, check them, and attach provenance. The longer account of that graph and vector pairing on a filing packet is document intelligence for agents.
That system does not lean on a model to guess what each entity is at query time. Entity, reporting period, unit and framework are carried as hard metadata from parsing, because a mistake inferred at query time cannot be recovered later. Apply the same caution to any LLM-extracted graph. An extraction step that merges two similar entity names produces a graph that is internally consistent and wrong. On Prospex, our own research engine, a misresolved entity yields a profile that is coherent, well sourced and about the wrong person, and every downstream check passes it. Resolve entities at ingestion and spot-check the merges before trusting a community summary built on them.
Cheaper variants and keeping it current#
The graph goes stale as documents change, and re-running extraction and summarization over a large corpus is the expensive part again. Microsoft's own answer is LazyGraphRAG, which defers the model work to query time: its November 2024 post puts indexing cost at the same level as vector RAG and 0.1% of full GraphRAG. Check what your stack offers before planning around it: as of October 2026 the post places LazyGraphRAG inside Microsoft's own services, not the open-source library.
Keep citations from every summary back to the source passages, whichever variant you run. A community summary is generated text, and without a path to the documents it was written from, nobody can audit what it says.