Building the Graph Before the Question
GraphRAG’s distinctive work begins before a user asks for a global answer. The important question is how a collection of ordinary text becomes a usable representation of entities, relationships, and claims without making the extraction stage too expensive or too lossy. Following that path shows what the later graph can know, what it may miss, and why indexing quality is part of answer quality rather than a separate technical concern.
From documents to semantic elements
The first boundary is between a document collection and the chunks that an LLM will inspect. A model cannot process an unlimited amount of text in one prompt, so GraphRAG divides source documents into smaller units and asks the model to extract information from each one. Chunking looks like a routine preprocessing step, but it sets the amount of context available for each extraction call and therefore changes both cost and recall.
Longer chunks mean fewer calls. If a corpus is divided into 600-token units, there will be more extraction requests than if it is divided into 2,400-token units. Fewer requests can reduce the indexing bill and simplify throughput. The cost is that an LLM may pay less attention to information at the beginning of a long chunk by the time it produces its output. The paper describes this as a recall problem: information that is present in the chunk can still fail to appear in the extracted result.
The appendix gives a concrete illustration from a HotPotQA sample. With the generic extraction prompt and GPT-4, 600-token chunks produced almost twice as many entity references as 2,400-token chunks before the authors varied the number of self-reflection passes. That observation is useful because it exposes the direction of the trade-off, not because it establishes a universal chunk size. A different model, document genre, prompt, or distribution of entities could change the balance.
GraphRAG uses self-reflection to push against that balance. After the initial extraction, the LLM is shown what it produced and is asked whether important entities were missed. If the model indicates that something is missing, a follow-up prompt encourages it to look again and add more entities. The process can be repeated up to a configured maximum. Conceptually, the system is exchanging additional model work for a chance to recover information that a larger first pass overlooked.
That exchange has two failure directions. With too little reflection, a large chunk may be cheap to process but leave gaps in the graph. With too much reflection, the system spends more tokens and calls revisiting outputs, while the model may add weak or duplicate candidates. The paper reports that this approach allowed larger chunks without the quality drop or forced noise shown in its experiment, but it does not claim that any reflection budget is optimal for every corpus. Self-reflection is a quality-control mechanism whose value must be judged against its added work.
Once a chunk is selected, GraphRAG asks the LLM to produce more than a bag of keywords. It asks for important entities, each with a name, type, and description. It also asks for pairs of entities that are clearly related, together with the source entity, target entity, a description of the relationship, and a numeric strength. The “clearly related” condition matters: the prompt is not asking the model to invent every association it can imagine. It is asking for relationships grounded in the text as interpreted by the extraction prompt.
The system can also extract claims. A claim is a factual statement about an entity, such as a date, event, interaction, or other verifiable assertion. Claims give later summaries more than a list of names and connections. They can carry the concrete events that explain why a relationship matters, or the details that allow a summary to say what happened rather than merely that two entities appeared near each other.
The paper’s NeoChip example shows the intended distinction. From a short passage about a company’s public debut, its acquisition by Quantum Systems, and its low-power processors, an extraction can produce an entity for NeoChip, an entity for Quantum Systems, a relationship describing the ownership history, and claims about the public listing and acquisition. Those outputs are not a verbatim copy of the paragraph. They are compact descriptions that make the passage’s important participants and connections explicit for later aggregation.
That compactness is exactly why the outputs can support a graph. It is also why they need scrutiny. The paper describes entity, relationship, and claim extraction as a form of abstractive summarization: an extracted description may express the meaning of a passage without repeating its exact wording. Abstraction helps reconcile information across many documents, but it creates a place where an LLM can omit a qualifier, paraphrase inaccurately, or produce a relationship that sounds plausible without adequate support. The extraction result is an index representation, not independent verification of the source.
Prompt design determines which parts of the source receive representation. A general prompt can identify broad named-entity categories such as people, places, and organizations. A scientific corpus may need prompts and examples that distinguish experiments, instruments, theories, or biological entities. A legal corpus may require other distinctions. GraphRAG’s authors recommend domain-appropriate few-shot exemplars—small examples supplied to the model so it can see the intended pattern—and domain-specific entity types where specialized knowledge makes the generic categories inadequate.
This is not merely a question of labeling. Consider two systems processing the same medical text. One prompt may treat a drug name as the central entity and leave the dosage relationship implicit. Another may represent the drug, condition, trial, outcome, and adverse event separately. The downstream community structure will differ because the graph receives different elements and edges. The paper supports the general need for domain tailoring; it does not provide a complete extraction benchmark that tells us which prompt is best for every specialized field.
The division of responsibility is therefore clear. Chunking decides what the LLM sees together. The extraction prompt decides what semantic roles the LLM is asked to notice. Self-reflection can revisit omissions. The resulting instances then cross an interface into graph construction. At that interface, the system must decide when several mentions describe one element and how their descriptions should be combined.
The diagram shows a feedback loop, not a guarantee that every omission is found. It also shows why the graph does not appear immediately when text is read. First, the source is divided; then an LLM proposes semantic elements; then an optional review pass revisits those proposals; only after that can repeated instances be consolidated. Each boundary changes the representation that the next component receives.
Consolidating instances into a graph
A corpus rarely mentions an entity only once. The same person, organization, event, or concept may appear in many documents and many chunks. If every extraction were kept as an unrelated object, the graph would be a pile of repeated observations rather than a useful index. GraphRAG therefore aggregates instances. Entity descriptions are combined and summarized for an entity node. Relationship instances become graph edges, and the number of duplicate observations for a relationship becomes its edge weight. Claims are aggregated in a similar way.
Suppose several chunks describe NeoChip and its connection to Quantum Systems. The graph should not treat every mention as a completely new company and a new owner. It should collect the descriptions, produce a consolidated representation, and preserve the repeated relationship as a signal of prominence. A higher edge weight does not by itself prove that the relationship is more important in the world; it records that the extraction process encountered that relationship repeatedly. The weight is therefore useful graph evidence, but it remains dependent on the documents, chunking, prompt, and matching rule that produced it.
Entity matching is the key decision at this interface. In the analysis reported in the paper, GraphRAG uses exact string matching to reconcile different extracted names. Identical strings can be joined directly, but names that refer to the same real-world entity can be written differently. “International Business Machines” and “IBM” may be related in meaning but are not the same string. Conversely, two different entities can share a name. Exact matching avoids some false merges, but it can leave aliases split; softer matching could join more variants, while also creating new opportunities to merge things that should remain separate.
The authors describe softer matching as a possible adjustment to prompts or code, not as the matching method evaluated in the manuscript. That distinction matters. It would be easy to read “the system can use softer matching” as if the reported results already demonstrated its quality. They do not. The empirical comparison is tied to the exact-string analysis, while other matching strategies remain possible extensions whose precision and recall would need to be tested on the target corpus.
Duplicates do not necessarily destroy the later pipeline. The authors note that duplicate entities are typically clustered together during subsequent summarization, making GraphRAG generally resilient to some duplication. That is a qualified observation, not permission to ignore normalization. If two names remain separate, their degrees and relationships may be divided between nodes. A community algorithm may then place them in different groups, or a summary may describe one side without recognizing the other. If two unrelated names are incorrectly merged, their edges can create a connection that changes the apparent theme of a community. Later clustering may soften some duplication, but it cannot reliably repair every false merge or missing relationship.
The same reasoning applies to relationship descriptions and claims. A repeated relationship can strengthen its graph presence, but aggregation can also combine descriptions that differ in time, direction, or qualification. A claim about an acquisition in one year is not interchangeable with a claim about ownership in another period. The source describes aggregation and summarization, but it does not provide a full audit of temporal consistency or claim-level factual verification. Therefore, the graph should be understood as a structured, LLM-derived representation of source evidence with known abstraction boundaries.
This view gives a more useful definition of graph quality than “the graph contains many nodes.” A useful graph has enough recall to retain the entities and relationships needed for the questions users will ask. It has enough precision that its connections do not overwhelm the meaningful structure with noise. It combines repeated evidence without erasing qualifiers, and it matches aliases well enough that important relationships are not fragmented. Those properties can conflict. A prompt that extracts more candidates may improve recall while adding noise; a strict matching rule may protect precision while hiding aliases.
GraphRAG’s global purpose makes these local decisions consequential. A vector search system can sometimes recover from a missed extraction by returning the original passage when a later query contains the right words. A community summary built from an incomplete graph may not expose the missing passage at all, especially if the omitted entity was the bridge connecting two topics. Similarly, a false edge can make a weak association look like part of a coherent community. The graph does not merely speed up retrieval; it determines which relationships are available for the later global summaries.
There is also a difference between source ownership and index ownership. The documents remain the underlying evidence. The extraction LLM owns the act of proposing semantic elements for each chunk. The normalization step owns the decision about which proposals are treated as instances of the same node or edge and how they are aggregated. The graph index owns the reusable representation passed to community detection. No one of these layers independently guarantees that the representation is correct. A strong pipeline keeps the boundaries visible so an apparent global theme can be traced back to the elements and source material that support it.
That is why the indexing stage is best seen as controlled transformation rather than automatic understanding. GraphRAG gains a structure that a corpus-wide query can use, but it pays for that structure with model calls, prompt dependence, matching decisions, and abstraction. The next problem is structural: once the graph contains many connected elements, how can the system divide it into meaningful scopes without losing the whole-corpus view? Communities provide that divide-and-conquer layer, but their quality will inherit every important choice made while building the graph.