When GraphRAG is worth it

Ethan Tenison — Tue, 14 Apr 2026 05:00:00 GMT

People often reach for GraphRAG too early, but a graph only adds value when the answer actually depends on relationships that plain retrieval cannot preserve.

That is the practical question. Not whether a graph is elegant, but whether the problem is relational enough to justify the cost. If the task is simple lookup, summarization, or FAQ-style retrieval, a well-built RAG system is usually enough. If the answer depends on entities, links, dependencies, or multi-hop reasoning, GraphRAG can add real value.

In other words, a graph does not make a system smarter by itself. It helps only when the structure of the data matters to the answer. The decision flow below in Figure 1 is the simplest version of the rule I use in practice. It also sets up the legal example that follows.

flowchart TD
 A["Answer in a few chunks?"]
 C["Missing text, not structure?"]
 B["Do relationships matter?"]

 R["Use RAG"]
 G["Use GraphRAG"]

 A -->|Yes| R
 A -->|No| C

 C -->|Yes| R
 C -->|No| B

 B -->|No| R
 B -->|Yes| G

 style A fill:#FAF7F2,color:#2A1F1A,stroke:#2A1F1A,stroke-width:2.25px
 style B fill:#FAF7F2,color:#2A1F1A,stroke:#2A1F1A,stroke-width:2.25px
 style C fill:#FAF7F2,color:#2A1F1A,stroke:#2A1F1A,stroke-width:2.25px

 style R fill:#EDE0D4,color:#2A1F1A,stroke:#2A1F1A,stroke-width:1.75px
 style G fill:#6B7A3A,color:#FAF7F2,stroke:#2A1F1A,stroke-width:2.5px

 linkStyle 0 stroke:#3D3530,stroke-width:2.25px,color:#2A1F1A
 linkStyle 1 stroke:#3D3530,stroke-width:2.25px,color:#2A1F1A
 linkStyle 2 stroke:#3D3530,stroke-width:2.25px,color:#2A1F1A
 linkStyle 3 stroke:#3D3530,stroke-width:2.25px,color:#2A1F1A
 linkStyle 4 stroke:#3D3530,stroke-width:2.25px,color:#2A1F1A
 linkStyle 5 stroke:#3D3530,stroke-width:2.25px,color:#2A1F1A

Figure 1: Use RAG when the answer is local. Use GraphRAG when correctness depends on relationships across entities or documents.

Case study: legal research where relationships determine the answer

To make that concrete, consider legal research. A legal research question often looks simple until you try to answer it with retrieval alone.

How does the definition of “personal data” under the General Data Protection Regulation compare to “personal information” under the California Consumer Privacy Act, and in what scenarios would a U.S.-based company need to comply with both?

A question like this does not live in one passage. It spans multiple legal regimes, overlapping definitions, territorial scope, and conditional obligations. To answer it well, the system has to connect terms, jurisdictions, exceptions, and compliance triggers across documents. The issue is not that the evidence is far apart. The issue is that the answer depends on how those pieces relate.

In legal data, those relationships are the substance of the answer:

Statutes define terms and establish obligations
Cases interpret, narrow, or extend those terms
Regulations refine scope and implementation
Clauses apply only under specific conditions and exceptions

A plain RAG system can retrieve relevant passages, but it can still miss how those passages fit together. That is the failure mode. The problem is not missing text. It is missing structure.

This is where GraphRAG can earn its cost. A graph gives the system a way to preserve entities, citations, dependencies, and exceptions across documents. When correctness depends on those links, a graph is not extra architecture. It is part of how retrieval stays grounded.

Figure 2: A relationship-heavy legal query often depends on traversing links between definitions, obligations, clauses, and parties, not just retrieving nearby text.

The point of this example is not that legal data can be drawn as a network. The point is that the answer depends on paths through that network. To answer whether a company must comply with both regimes, the system has to connect definitions, scope, obligations, exceptions, and the entities those obligations apply to. That is what justifies the graph. It is a relationship problem, not just a retrieval problem.

Once you see that distinction, the decision becomes simpler.

How should you decide?

Start with plain RAG. It is cheaper, faster, and easier to debug. Move to GraphRAG only when answer quality breaks because the task depends on relationships across entities, documents, or events. If you cannot name that failure mode, you probably do not need GraphRAG yet. The rubric in Table 1 is the decision rule I would use.

Question	Signals Plain RAG	Signals GraphRAG
Where does the answer live?	One document or a few chunks	Across linked entities or documents
What is failing?	Retrieval quality	Relationship structure
What kinds of questions break?	Lookup, summarization, FAQ	Citations, dependencies, exceptions, multi-hop reasoning
What must the system preserve?	Relevant text	Relationships and structure
Is added complexity justified?	Probably not	Possibly yes

Table 1: Decision rubric for when plain RAG is enough and when GraphRAG earns its cost.

What I’d do in practice

In practice, I would start with plain RAG and define a small benchmark around the real failure mode. Then I would measure where it breaks.

If the failures are mostly retrieval quality, I would improve chunking, embeddings, ranking, and citations before adding graph complexity. If the failures are relational, I would add GraphRAG narrowly, around the specific query classes that need it.

That approach keeps the system honest. A graph should earn its place.

You do not have to choose one forever

That is also why this is not always a clean either-or decision. For example, while building my own GraphRAG agent, I realized it did not make sense to treat the graph as a standalone answer engine given the diversity of ways that evidence could be relevant to the questions I cared about. Instead, I used a hybrid retrieval design with dense, sparse, graph, and reranked modes, plus a plan-retrieve-reason-verify workflow. In production, I imagine this is a more realistic path for building systems that need to answer complex questions from diverse evidence sources.

Use graph structure where relationships matter, then use ranking or reranking to decide which evidence is most relevant to the final answer.

The benchmark results for my hybrid graphrag project validated this choice for this context. A later hybrid configuration improved context recall from 0.5275 to 0.6525, context precision from 0.1880 to 0.2013, and answer faithfulness from 0.7467 to 0.8267. Pure graph mode, by contrast, still lagged badly on retrieval quality, with context recall at 0.2473 and context precision at 0.0675. That is the real lesson. Graph structure helped most when it was combined with stronger retrieval and reranking, not when it replaced them.

If you want to see how I approached this trade-off in practice, see my RiskFolio GraphRAG agent experiment here.

The important decision is not “graph or no graph” in the abstract. It is where structure improves retrieval enough to justify the added complexity.

The practical takeaway

GraphRAG is not the default answer. It is the right answer only when the problem depends on structure that plain retrieval cannot reliably preserve.

Start with the simplest system that can succeed. If plain RAG breaks because the answer depends on relationships, add graph structure where it actually helps. And if the task benefits from both, you do not have to choose a pure architecture. In practice, hybrid systems are often the honest solution.

Discussion question

Question: What failure mode are you actually trying to solve, missing context or missing relationships?