When Retrieval Is Not Enough
GraphRAG is a retrieval-augmented generation system designed for a question that ordinary retrieval handles poorly: not “which passage mentions this?” but “what is happening across this entire collection?” The focus here is the boundary between local fact-finding and global sensemaking. Understanding that boundary gives the reader a practical way to decide when a familiar retrieval pipeline is enough, when it is structurally mismatched to the question, and why GraphRAG builds an additional layer before answering.
The local question and the global question
A conventional retrieval-augmented generation system starts with a large external collection—documents, transcripts, reports, or records—that cannot fit into a model’s context window. A context window is the amount of text an LLM can process in one prompt. At query time, the system finds a limited set of records that appear semantically close to the user’s question, places those records beside the question, and asks the model to generate an answer from them. In the paper, this family of approaches is called vector RAG because embeddings represent text and queries as points in a vector space, where closeness is treated as semantic similarity.
That design fits a local question. Suppose a reader asks what a particular podcast guest said about privacy regulation, or asks for the date of an event described in a report. The answer may be contained in one passage or a small group of passages. Retrieving the most relevant records is then a sensible division of labor: search narrows the evidence, and generation explains it.
A global sensemaking question has a different shape. “What are the main themes in this dataset?” asks for coverage across the collection. “How are scientific discoveries influenced by interdisciplinary research over the past decade?” asks for patterns, connections, and contrasts that may be distributed across many records. A useful answer might need to identify several recurring ideas, notice how different entities are related, compare perspectives, and explain which themes appear central rather than merely memorable. No single passage is likely to contain the answer in finished form.
The distinction is not simply between an easy question and a hard question. It is between two evidence requirements. A local question asks the system to find a sufficient piece of the corpus. A global question asks the system to construct an account of the corpus. The first rewards precise selection. The second rewards organized coverage.
Vector retrieval can still return passages that are relevant to a global question. The problem is what happens next. The system normally has room for only a bounded number of chunks, so it must select a sample. That sample may overrepresent passages that use the query’s vocabulary or describe the most obvious aspect of the topic. It may leave out less direct evidence, competing perspectives, or relationships that become visible only when several parts of the collection are considered together. The passages can each be relevant while the set is not representative enough to support a claim about the whole.
This is why “retrieve more” is not a complete solution. More passages increase the chance of coverage, but they also consume the same limited context budget and still require a selection rule. The system has not changed the question from “which records are nearest?” to “which patterns organize the collection?” It has only made the nearest-records problem larger.
Global does not mean that every answer must mention every record. It means that the answer’s scope is the collection as a whole, and that the method must have a defensible way to combine evidence from across that scope. A concise global answer can omit details while still being global if its themes and judgments are formed from an organized view of the corpus. Conversely, a long answer can remain local if it simply lists a few retrieved facts.
What GraphRAG changes
GraphRAG responds to this mismatch by changing when and how the collection is organized. Instead of waiting for a question to decide which raw passages matter, it uses an LLM during indexing to extract important entities, relationships between them, and—when enabled—claims about those entities. These elements become a knowledge graph: entities are nodes, relationships are edges, and claims provide associated factual statements. The system then detects groups of closely connected elements and creates summaries for those groups. The summaries are available before a user asks a global question.
The graph is not the final answer, and it is not presented as a perfect copy of the source. It is an intermediate index designed to make relationships and recurring structure easier to summarize. Its distinctive contribution is the use of graph communities as reusable units. A community can gather entities and relationships that belong together in the extracted structure; communities can also be nested, allowing the same corpus to have broad and detailed views. The model can summarize those views rather than asking one prompt to absorb the entire raw collection.
At query time, GraphRAG uses a map-reduce process over community summaries. In the map stage, separate groups of summaries support separate partial answers. In the reduce stage, those partial answers are combined into a final response. The approach therefore moves some expensive work to indexing time, where it can be reused across questions, and keeps the query-time task focused on selecting and synthesizing prepared views of the corpus.
The contrast in the diagram is a contrast in organization, not a claim that one path should replace the other. Vector RAG begins with a question and selects a small evidence set. GraphRAG begins by organizing the corpus into connected, summarized views and then uses a question to decide how those views should contribute to an answer. The graph gives the system a way to represent relationships; the hierarchy gives it different scopes; the summaries make those scopes fit within model limits; and map-reduce turns them into a response.
That sequence also explains why GraphRAG is more than a graph attached to a search engine. Some graph-based RAG systems use a graph to traverse related facts at query time. The paper emphasizes a different property: graph modularity. Closely connected elements can be partitioned into communities, and those communities can be summarized at several levels. The graph is valuable because it creates a structure over which broad summarization can be divided and recombined.
This design carries a clear exchange. It can improve the chance that a global answer reflects multiple parts of a corpus, but it requires indexing calls, extraction choices, entity matching, community detection, and repeated summarization. It also introduces intermediate representations between the source and the answer. If an entity is missed, two names are not matched, or an important detail is compressed away, the later answer may inherit that limitation. GraphRAG changes the coverage problem; it does not make evidence management disappear.
What the evidence can—and cannot—say
The paper’s subject is a proposed method and an evaluation of that method on a defined class of questions. Its reported experiments use two text collections in the roughly one-million-token range: podcast transcripts and news articles. The comparison is designed around global sensemaking, not around the ordinary question of whether a system can retrieve a particular fact. That scope matters. Results on corpus-wide questions do not establish that GraphRAG is the better choice for a request whose answer is already localized in one document.
The strongest reported advantage is also specific. In the study, global approaches—including GraphRAG at several community levels and a graph-free map-reduce summarizer—generally produced more comprehensive and more diverse answers than the vector-RAG baseline. Vector RAG produced the most direct answers in the comparisons, while empowerment results were mixed. These dimensions describe different kinds of usefulness: an answer can cover more perspectives yet be less concise, and a longer answer is not automatically more accurate or more helpful for a decision.
There are further reasons to treat the findings as initial evidence rather than a universal performance guarantee. The questions were generated with an LLM from descriptions of potential users and tasks. The answers were compared by an LLM judge, and a second LLM-based process extracted claims for an additional check. Those methods are useful ways to study a task without a single gold answer, but they do not independently certify that every generated claim is true. The authors also identify missing analysis of fabrication rates and the need to test more domains and use cases. Examples, quotes, and citations may matter greatly to a reader’s ability to judge an answer, yet the paper notes that the pipeline can lose such details.
The appropriate conclusion is therefore narrower and more useful than “GraphRAG solves RAG.” When a user needs to understand themes, relationships, or patterns across a large collection—and especially when many such questions will be asked—the method offers a way to pay an indexing cost for reusable global structure. When the question is local, directness and precise retrieval may matter more. When the answer will influence a decision, the system still needs provenance, uncertainty disclosure, and monitoring for errors.
That makes the next design problem unavoidable: before communities can summarize a corpus, GraphRAG must decide what counts as an entity, a relationship, or a claim, and must reconcile the many imperfect extractions produced from separate chunks. The quality of the global answer begins with that quieter act of building the map.