Skip to content

Glossary

GraphRAG

GraphRAG uses graph structure to organize or retrieve context for a generated answer.

Context engineering

Also known as: Graph retrieval-augmented generation

GraphRAG is a family of approaches that use a graph of entities, relationships, or document-derived summaries to support retrieval and generation. A graph can expose connections that are hard to find through isolated passages, such as a question spanning several documents. The term does not specify one graph construction method or guarantee that edges are verified facts. Graphs derived from text can inherit extraction errors, missing qualifiers, and ambiguous identities.

In practice, each node and edge should remain traceable to source material, and retrieval should preserve the path by which an answer was assembled. Community summaries can help with broad questions, while precise claims still need their underlying passages. Testing should distinguish questions about global themes from questions about a specific entity or date. The graph's update process matters because an old edge can persist after its source changes.

For defensible decisions, graph structure can reveal how claims relate and where evidence is missing, but it cannot substitute for provenance or temporal scope. An inferred relationship should be marked as an inference, and a source-derived edge should be checked against the original wording. Knowledge graphs are the broader representation concept; GraphRAG refers to using such structure in a retrieval-and-generation workflow. A generated synthesis remains subject to grounding and faithfulness checks.

Example

A graph links Halden Therapeutics AG (fictional) to two filings, but an answer checks the dated passages before stating that a relationship held on a particular day.

What the graph adds to retrieval

Plain retrieval returns passages that look similar to the query. It struggles with questions that need relationships across many documents, such as which organisations are connected to a compound through different studies, or with questions about the whole corpus, such as the main themes. The approach in Edge and colleagues builds an entity knowledge graph from the source documents with a language model, detects communities of related entities, summarises each community, and answers a global question by combining the summaries. The survey by Peng and colleagues organises the wider field of graph-based retrieval-augmented generation into graph construction, retrieval from the graph and generation using the retrieved structure. A curated graph, as described by Hogan and colleagues, can serve the same purpose when entities and relationships have been established deliberately instead of extracted wholesale.

The benefit is in multi-hop and global questions; the cost is the work of building and maintaining the graph and the risk that errors in extraction become edges that look authoritative. A graph built by a model from text is a set of extracted claims, and it inherits the failure modes of information extraction.

Keeping a graph-based answer defensible

A path through a graph is a navigation aid; it is not evidence. Each edge used in an answer should be traceable to the source passage from which it was extracted and, where possible, to the date it was read, so that the answer can cite passages and not just graph structure. Community summaries are a second layer of model-generated text: they compress many passages into a paragraph that may contain errors, and an answer that cites a summary is one step further from the evidence. For answers that matter, the pipeline should descend from the summary to the supporting passages before citing.

Evaluate against the claims. Take a sample of answers, list the graph elements used, and check each against the source. Compare with plain retrieval on the same questions to see where the graph helps and where it only adds complexity. The article on multi-hop RAG citation completeness provides a test for whether every step of a multi-hop answer has evidence, and the article on knowledge graph truth maintenance addresses what happens to derived answers when an edge is retracted.

A worked example

A user asks which organisations are linked to a fictional compound through studies sponsored by Halden Therapeutics AG (fictional). Plain retrieval returns passages that mention the compound, with partial lists of sites. A graph-based pipeline starts from the compound node, follows investigates edges to studies, then sponsors edges to organisations and site edges to institutions, and returns a table. Each row carries the edges used, and each edge carries its source passage and date. One row depends on an edge extracted from a press release that called a university a partner; the reviewer opens the passage and finds that the partnership was for a different compound, so the edge is wrong. The error is found because the edge was traceable; in a summary-only pipeline it would have appeared in the answer without a trail.

Checks a reviewer can run

Sample ten answers and trace each edge to a source passage. Measure the proportion of edges that are supported. Ask how a wrong edge is corrected and how answers that used it are found and reissued. Compare against a plain retrieval baseline on the same questions. Check whether community summaries are cited as evidence or whether the pipeline cites underlying passages.

Related terms and boundaries

GraphRAG joins a knowledge graph to retrieval-augmented generation. It depends on entity resolution so that nodes mean what they say, on provenance so that edges can be defended, and on the measures of grounding and faithfulness for the final answer.

Common misreadings

  • Treating every extracted edge as a verified fact.
  • Citing a graph summary without its source passages.
  • Ignoring stale edges after a source correction.

Found an error on this page? See corrections for what counts as one, how to report it and the dated log.

Enquiry

Where does "GraphRAG" bear on a decision of yours?

This entry sits under context engineering. If a decision in your organization turns on it, send the entity concerned, the sources you fuse to describe it and who may read which of them. We reply with what a first record would cover.

Or write to [email protected] in your own words.