What is GraphRAG? The Hybrid Approach Explained

The problem with classic RAG

RAG (Retrieval Augmented Generation) is the standard way to give an LLM external knowledge:

1. Documents are split into chunks and stored as vectors
2. A question retrieves the most semantically similar chunk
3. That chunk goes to the LLM as context

The limit of a single retrieval: relationships are not joined automatically.

Fictional, simplified example: The following details illustrate a query. Any inferred reason remains a hypothesis until the underlying sources are checked.

Ask "why is the Mozart Street deal stalled?" and the system has to connect:

• The Mozart Street deal is linked to the Mozart Street property
• That property is missing an energy certificate
• The certificate has been missing for 8 days
• The responsible provider has been contacted twice

That information is spread across several documents and records. A single Vector RAG retrieval does not join the fragments automatically; additional retrieval and synthesis logic can do so.

GraphRAG: the hybrid approach

Stage 1: entity extraction and graph building

Entities (customers, properties, deals, documents) and their relationships are extracted from your data and stored in a knowledge graph.

Stage 2: graph-augmented retrieval

1. Entity recognition: "Mozart Street deal" is located in the graph
2. Graph traversal: The system follows the edges (CONCERNS, MISSING, CONTACTED)
3. Subgraph extraction: Only the relevant nodes and edges are pulled
4. Context compression: That subgraph becomes compact text instead of whole documents
5. LLM generation: The model answers from the selected context; completeness and correctness still need checking

What the measurements show

Many articles put figures like "3.4x more accurate" or "100x fewer tokens" here. Neither holds up. Here is what can be supported.

Classic RAG leads on plain fact retrieval. Table 2 of GraphRAG-Bench v1 reports, on the Novel dataset and its stated accuracy metric, 60.9 for RAG with reranking and 60.1 for HippoRAG2; Microsoft GraphRAG global appears in a separate row at 36.9. These are results for this dataset and these methods, not a universal ranking.

Chained questions reverse the order on the same Novel dataset. Table 2 of GraphRAG-Bench v1 reports 53.4 for HippoRAG2 and 42.9 for RAG with reranking. The difference is scoped to this task type, metric, and version.

The effect depends on the dataset and retriever configuration. HippoRAG v3 reports Recall@5 for ColBERTv2 versus HippoRAG using Contriever: 68.2 versus 89.5 on 2WikiMultiHopQA and 49.2 versus 52.1 on MuSiQue. This is not a controlled test of graph structure alone.

The token comparison is narrowly scoped too. Figure 8 of GraphRAG-Bench v1 reports average prompt tokens per query on the Novel dataset: 879 for V-RAG, 38,707 for Microsoft GraphRAG local, and 331,375 for Microsoft GraphRAG global. This setup establishes neither total operating cost nor a universal token rule.

Treat evaluation by a second language model with care. Zeng et al. v1, section 5.1, compared two identical LightRAG instances and the protocol produced a 90:10 split. The authors attribute it to position and single-trial bias.

Microsoft uses a second language model to judge several answer-quality dimensions in the cited study. Such model judgments depend on the protocol and do not establish a universal ranking.

Why compress at all?

The position of information in a context window can affect whether a model uses it. Liu et al. study this effect in long contexts; transfer depends on the model, task, and setup.

Less context means less room for the decisive fact to get buried.

Multi-hop reasoning

Questions requiring several jumps through the graph:

1 hop: "Which documents are missing for the Mozart Street deal?"

2 hops: "Which customers have deals with missing documents?"

3 hops: "Which notaries handle deals for customers from Hamburg?"

Vector RAG can also reach such answers through repeated retrieval. It needs suitable query and synthesis logic, and quality depends on the dataset, retriever, and evaluation.

When to use GraphRAG

Described Osiris target architecture

The Osiris target architecture described on this website proposes Neo4j for graph-based queries. Data scope, connectors, and operating status must be checked for each project.

1. Data transfer: A project-specific connector can transfer approved CRM data into a graph model; scope and update behavior need prior verification.
2. Schema design: A real-estate ontology (property, deal, customer, document, activity)
3. Cypher queries: Graph queries tuned for the recurring questions
4. MCP integration: The LLM queries Osiris through the Model Context Protocol
5. Context compression: Subgraphs become compact prompts

→ See Osiris in detail