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 problem: relationships are lost.

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. Vector RAG finds the fragments but does not join them.

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 compressed context

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 wins at plain fact retrieval. On GraphRAG-Bench, classic RAG with reranking scores 60.9, the best graph method 60.1, and Microsoft's GraphRAG in global mode 36.9.

Chained questions reverse it. On the same data, for questions connecting several facts: 53.4 for the best graph method against 42.9 for classic RAG.

The effect varies sharply by dataset. HippoRAG lifts Recall@5 on 2WikiMultiHopQA from 68.2 to 89.5, but on MuSiQue only from 49.2 to 52.1.

A fair token budget shrinks the gap. Graph methods pull more context per query. Give classic RAG the same budget and it rises from 65.8 to 71.0 on MultiHop-RAG, level with the graph method at 71.2. What survives is temporal and comparative questions: 43.7 against 49.1.

On tokens the common claim is upside down: graph methods use more, not fewer. On GraphRAG-Bench classic RAG uses 879 tokens per query, Microsoft's GraphRAG 38,707 local and 331,375 global. Microsoft's documented 9x to 43x saving is against map-reduce summarization of source texts, not against vector search. GraphRAG buys capability, not savings.

Treat LLM-judged win rates with care. Zeng et al. ran a method against an identical copy of itself; the standard protocol declared one copy the winner 90 to 10. Position and length effects manufacture advantages that are not there.

Microsoft also scores answer quality with a second LLM as judge rather than an accuracy metric. On directness, Vector RAG wins every comparison.

Why compress at all?

Cost is not the only reason. Where information sits in the context window affects whether the model uses it. Liu et al. measured this: with the key passage in the middle of a long context, GPT-3.5-Turbo scored below its own no-documents baseline of 56.1% on multi-document QA. A larger context window does not fix it.

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 reach these answers through repeated retrieval, but it needs several passes and loses the thread more often.

When to use GraphRAG

Use case	Vector RAG	GraphRAG
Document QA ("What does the contract say?")	Strong	Comparable
Looking up single facts	Strong	Somewhat weaker
Relationship questions ("Who handles whom?")	Weak	Core strength
Aggregations ("How many deals are stalled?")	Unreliable	Native
Diagnosis ("Why is deal X stalled?")	Guesses at gaps	Follows the path
CRM/ERP integration	Awkward	Native

How Osiris implements GraphRAG

1. Continuous extraction: Data from PropStack/CRM syncs into the graph
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