# What is GraphRAG? The Hybrid Approach | APRIXITY > Source: https://aprixity.run/en/wissen/framework/was-ist-graphrag ### Cookie Settings We use cookies to improve your experience and optimize our service. #### Essential Always active These cookies are required for the basic functionality of the website. #### Analytics & Performance These cookies help us understand how you use our website to improve it. - Google Analytics 4 (visitor statistics) - Page views and navigation - Interactions and events Accept AllSave PreferencesReject All For more information, see our [Privacy Policy](/en/privacy) [Skip to main content](#main-content) [![APRIXITY Logo](/logo-64.png)APRIXITY](/en/) [AI consulting](/en/ai-consulting-hannover)[Renovation](/en/sanierung)[Real Estate](/en/osiris)MethodKnowledge[About me](/en/#about) 🇺🇸English [Check](/en/bottleneck-check)[Conversation](https://cal.aprixity.run/melvin-aprixity.run/catch-up) 🇺🇸English [View All](/en/wissen) Framework For Customers Intermediate # What is GraphRAG? The Hybrid Approach Explained How GraphRAG connects knowledge graphs with RAG, where the advantage is measurable and where it is not. 4 min read1360 viewsUpdated: 7/30/2026 ## TL;DR GraphRAG combines knowledge graphs with RAG, following relationships instead of only retrieving similar text. The advantage is in multi-step reasoning (53.4 to 42.9 on GraphRAG-Bench). On plain fact retrieval, classic RAG is ahead. ## Key Takeaways ### Hybrid-Ansatz Kombiniert Graph-Traversierung mit semantischer Suche ### Enger, aber echter Vorteil Auf GraphRAG-Bench gewinnen Graphverfahren beim mehrstufigen Schließen, nicht beim Faktenabruf ### Kompression Nur der relevante Subgraph geht ans LLM statt ganzer Dokumente ### Multi-Hop Reasoning Kann Beziehungen über mehrere Ebenen verfolgen ## 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](/en/osiris) ## Frequently Asked Questions ### Do I need GraphRAG if I only want to search documents? No. Plain vector RAG is enough for document search, and benchmarks put it slightly ahead there. GraphRAG earns its cost with relationship questions, CRM/ERP integration, and diagnosis ("why is X stalled?"). ### Is GraphRAG harder to implement? Yes. Schema design and entity extraction are added work. It pays off for questions that chain several facts and where you need to trace how an answer was reached. For plain lookup it does not. ### Can I use GraphRAG without a persistent knowledge graph? In principle yes, with flat graphs extracted from documents on the fly. For business data (CRM, ERP) a persistent graph is worth it for consistency and query performance. ## Sources 1. [When to use Graphs in RAG: A Comprehensive Analysis (GraphRAG-Bench)](https://arxiv.org/abs/2506.05690) - Xiang et al., ICLR 2026 (2025) 2. [HippoRAG: Neurobiologically Inspired Long-Term Memory for LLMs](https://arxiv.org/abs/2405.14831) - Gutiérrez et al., NeurIPS 2024 (2024) 3. [From Local to Global: A Graph RAG Approach to Query-Focused Summarization](https://arxiv.org/abs/2404.16130) - Edge et al., Microsoft Research (2024) 4. [Lost in the Middle: How Language Models Use Long Contexts](https://arxiv.org/abs/2307.03172) - Liu et al., TACL (2024) ### Use Cases - Business Intelligence - CRM Integration - Process Diagnosis - Multi-Source Analytics ### Prerequisites - Grundverständnis von RAG - Basis Knowledge Graphs ### Effort MVP-Scope, iterativ erweiterbar Next step ## Knowledge becomes valuable inside a process. Find your binding constraint or explore the method through the Academy. [Bottleneck Check](/en/bottleneck-check)[Back to Knowledge](/en/wissen) APRIXITY AI-First Business Transformation for Premium Service Businesses apricity: the warmth of the sun on a cold winter day ### Framework - [AI consulting Hannover](/en/ai-consulting-hannover) - APRIXITY Stack - About APRIXITY - AI-First Definition ### Resources - Knowledge Hub - [Aprixity Briefing](/en/briefing) - [Developer Resources](/en/developers) ### Legal - [Privacy Policy](/en/privacy) - [Imprint](/en/imprint) - [Terms & Conditions](/en/terms) - Cookie Settings ### Connect - [Email](mailto:kontakt@aprixity.run) - [APRIXITY on LinkedIn](https://www.linkedin.com/company/aprixity) - [Melvin Voigtländer](https://www.linkedin.com/in/melvin-voigtländer-9767ba192/) - [Conversation](https://cal.aprixity.run/melvin-aprixity.run/catch-up) © 2026 APRIXITY. All rights reserved. Engineered in Hannover, Germany•Hosted on Hetzner