What Is GraphRAG in 2026? How Knowledge Graph Retrieval Works, Real Indexing Costs and When It Beats Vector RAG
GraphRAG is retrieval over a knowledge graph your LLM builds from your documents at index time, so queries follow entity relationships instead of ranking text chunks by similarity. It wins on multi-hop and whole-corpus questions. The catch is indexing cost: Microsoft Research puts full GraphRAG at roughly 1,000x vector RAG.
- GraphRAG is for relationship questions. If users ask "which" or "who changed what", a graph helps. If they ask "what does clause 7 say", vector search already wins.
- The indexing bill is no longer the blocker. On Claude Haiku 5.5 at $0.10 per million input tokens with the Batch API's 50% discount, a 48M-token corpus indexes for under $10.
- Microsoft's reference repo is in maintenance mode. Its README says the project is "largely in maintenance mode" and is not taking new features, so choose your implementation deliberately.
- LinkedIn has the only well-documented production result. Its ticket knowledge graph cut median per-issue resolution time 28.6% over roughly six months, per arXiv 2404.17723.
- The skill that transfers is graph modelling, not the library. Most teams asking about GraphRAG have a chunking problem, and deciding what counts as an entity in your domain is the part no framework does for you.
Your RAG bot answers "what is the waiting period for maternity cover" perfectly, then falls apart on "which policy wordings did we change after the 2024 regulator circular, and who approved each one". Same documents, same embeddings, same model. The second question needs the links between documents, and your vector index threw those away the moment it sliced everything into 600-token chunks. That gap is the entire reason GraphRAG exists.
What Is GraphRAG, and What Problem Does It Solve?
GraphRAG replaces the flat chunk store with a graph. At index time an LLM reads every chunk and emits structured output: entities (policies, claims, regulations, approvers), typed relationships between them, and short claims about each. Those become nodes and edges. At query time you traverse the graph instead of, or alongside, ranking chunks by cosine similarity.
Why that matters is specific. Vector search ranks text by how closely it reads like your question, not by how the underlying facts connect. Ask a two-hop question and it returns ten chunks that each cover one hop, then the model guesses the join. Ask "what are the recurring themes in last quarter's complaints" and it returns the ten most question-like chunks out of eighty thousand, which is not an answer about all eighty thousand.
Graph retrieval handles both because the join is already materialised. Microsoft's implementation splits this into local search, which pulls the neighbourhood around the entities you named, and global search, which map-reduces over pre-computed summaries of graph communities. Keep those modes straight: most of the confused GraphRAG benchmarks online pit one of them against a vector baseline never built for that question shape.
Also read: Retrieval Augmented Generation Explained in 2026 for the vector pipeline this sits on top of.
How GraphRAG Works: Extraction, Communities and Two Search Modes
The pipeline has an expensive half you run rarely and a cheap half you run constantly.
Index time: four passes over your corpus
Chunk, as in any RAG build. An LLM then reads each chunk with an extraction prompt and returns entities and typed relationships. A clustering algorithm (Microsoft's implementation uses Leiden) partitions the graph into communities of densely connected entities. Finally an LLM writes a summary report per community, bottom up, so a top-level summary transitively covers everything beneath it. That fourth pass is where the token bill concentrates, and it is the pass LazyGraphRAG removes.
Query time: local versus global
Local search resolves the entities in your question, walks one or two hops out, collects the attached text units and claims, and puts that subgraph in the prompt. Global search ignores your entities, fans the question across community summaries and reduces the partial answers into one response. Local search costs about what a vector query costs. Global search is the expensive one, because it touches many summaries per question.
The GraphRAG pipeline, index time and query time
The left column runs once per corpus refresh. The right runs on every question, and the branch it takes decides your per-query cost.
Drawn from Microsoft's published GraphRAG pipeline description and the microsoft/graphrag README, checked 11 October 2026.
GraphRAG vs Vector RAG: 10 Criteria and an Honest Verdict
Here is the comparison most vendor blogs will not give you straight, because nearly all of them sell a graph database.
| Criterion | Vector RAG | GraphRAG |
|---|---|---|
| Single-fact lookup | Wins. One hop, one chunk, done | Overkill, and slower |
| Multi-hop question | Weak. The model has to guess the join | Wins. The join is materialised as edges |
| Whole-corpus question | Fails by design. Top-k is not "all" | Wins via global search over summaries |
| Indexing cost | One embedding pass, single-digit dollars at 48M tokens | Microsoft Research puts full GraphRAG at roughly 1,000x that |
| Per-query cost | Lowest. One retrieval, one prompt | Local search is comparable; global search is far higher |
| Incremental updates | Trivial. Upsert the changed chunk | Hard. Community summaries go stale and need rebuilding |
| Time to first working demo | An afternoon | One to three weeks, mostly on the extraction schema |
| Explainability | Citations to chunks | Citations plus the traversal path, which audit teams like |
| Ops surface | One vector store | Vector store, graph store, and an extraction job to babysit |
| Skills required | Embeddings, chunking, reranking | All of that plus graph modelling and Cypher or Gremlin |
The verdict. Default to hybrid vector RAG with good metadata filters and a reranker. Add a graph only when you can name the question your current system gets wrong and that question is about relationships or about the whole corpus. Teams that succeed here state that question in one sentence before writing any code. The ones that struggle picked the graph first and went looking for a question afterwards. Both halves of this pipeline are what the AI Engineer Course builds live, in that order.
Also read: pgvector vs Pinecone in 2026 if you are still choosing the vector half of the stack.
What GraphRAG Actually Costs: A Worked Indexing Bill
Run the numbers, because the received wisdom that GraphRAG is unaffordable was priced on 2024 frontier models. Take an illustrative scenario: a two-person platform team at a mid-size Indian insurer, 80,000 claim notes and policy wordings averaging about 600 tokens each, so roughly 48M tokens of source text. A full index reads every chunk more than once across extraction, claims and community summarisation, so budget around 120M input and 15M output tokens.
| Index run on 48M tokens of source text | Standard API | With the Batch API 50% discount |
|---|---|---|
| Claude Haiku 5.5 at $0.10 in / $0.50 out per MTok (prompts under 100k) | About $19.50 | About $9.75 |
| Claude Sonnet 5.5 at $2 in / $10 out per MTok | About $390 | About $195 |
| Vector RAG baseline (one embedding pass over 48M tokens) | Single-digit dollars on current embedding endpoints | Not applicable |
| Neo4j AuraDB to hold the graph | Free tier at $0, no card required; Professional from $0.09/GB/hour, 1GB minimum | Not applicable |
Prices read off the Anthropic and Neo4j pricing pages on 11 October 2026. Token volumes are our estimate for this scenario, not a measured benchmark.
So the insurer's first index costs less than a team lunch on a small model, about Rs 17,000 on a mid-size one. That is not the problem. They will rebuild it, because the extraction schema will be wrong on the first attempt and wrong again on the second, and because every month of new claims invalidates the community summaries above them. Five tuning rebuilds plus monthly refreshes is where a $10 line item turns real. Microsoft's LazyGraphRAG work exists because of this: its blog reports indexing at vector-RAG cost, 0.1% of full GraphRAG, and more than 700 times lower query cost than global search at comparable quality on global questions.
Where your first 40 hours should go
Teams underspend on the schema and the eval harness, which is why their second index run looks like their first.
Our recommended effort split for a first build, not measured data. Mapped to the pipeline stages documented in microsoft/graphrag, 11 October 2026.
Holding an evaluation set like that is its own discipline, and the part of the MLOps Engineer Course students find most immediately useful, because it is the artefact that tells you whether the graph earned its cost.
Case Study: What LinkedIn Got From a Knowledge Graph RAG
The clearest knowledge graph RAG result in production belongs to LinkedIn's customer service team, who published their approach as arXiv 2404.17723. Instead of embedding support tickets as flat text, they modelled each ticket as a tree with separate nodes for summary, description, solution and root cause, then connected tickets using relationships their issue tracker already carried: clone_of, related_to, caused_by. At query time a user question became a graph query that pulled the relevant subgraph, with E5 embeddings for semantic retrieval and GPT-4 for parsing and generation.
Reported results: retrieval up 77.6% in MRR and generation up 0.32 BLEU against their baseline. More useful for anyone funding this work, the system ran inside the team for roughly six months with members split randomly between using it and working manually, and median per-issue resolution time fell 28.6%, P50 going from about 7 hours to about 5.
The win came from relationships that already existed in structured form. LinkedIn did not ask an LLM to invent a graph, they lifted one their ticketing system had been recording all along, and if you have a Jira, a CRM, a claims system or a git history, you have the same free edges sitting unused. Note the limits too: a single internal deployment reported in a 2024 paper, no independent evaluation, no later production follow-up we could find. Evidence the pattern works, not a benchmark you will reproduce.
Microsoft GraphRAG, LightRAG or Build It Yourself?
This is where the advice online is most out of date, and the detail that changes the decision sits in plain sight on GitHub.
| Option | What it gives you | Pick it when |
|---|---|---|
| microsoft/graphrag | The reference pipeline, local and global search, 36.3k stars. README says it is "largely in maintenance mode" and not accepting new features | You want to study the canonical design or run a one-off index |
| LazyGraphRAG (Microsoft Research) | No pre-summarisation at index time; noun-phrase extraction plus co-occurrence, at vector-RAG indexing cost per Microsoft's blog | Your questions are mostly global and the corpus changes often |
| LightRAG | 40.1k stars; fewer LLM calls at index and query time, plus incremental insert and selective delete via the indexing-time LLM cache | You need a maintained path where update and delete actually work |
| Hand-rolled on a graph store | Full schema control; you write extraction, loading and traversal | Your edges already exist in a source system, as LinkedIn's did |
| Hybrid retrieval, no graph | Vector plus BM25 plus metadata filters plus a reranker | Almost always, as the thing you try first |
Repo details checked on GitHub, 11 October 2026.
Our pick for a team shipping this year: if your edges exist in a source system, hand-roll it. If they do not and you need an LLM to extract them, start with LightRAG, because incremental update stops being a nice-to-have the moment your corpus has a second month of data. We would not start a new product on microsoft/graphrag today, and that is not a criticism. It did its job as a reference implementation and says so in its own README.
Day to day this work is structured LLM output, tool calls and prompt-level cost control, the ground the CCDV-F developer prep course covers; the "should this be a graph at all" call is the trade-off the CCAR-F architect foundations track drills. The certifications overview shows how they fit together.
- Entity explosion. Leave the extraction prompt generic and the model invents a new entity type per document: 400,000 nodes, no reusable edges. Constrain the types to a list you wrote by hand.
- Duplicate entities. "HDFC ERGO", "HDFC Ergo General" and "hdfc_ergo" become three nodes, and your two-hop traversal finds nothing. Entity resolution is a real step.
- Stale community summaries. New documents land, nobody rebuilds the summaries, and global search confidently answers last quarter's question.
- No baseline. Teams ship a graph without measuring the vector system on the same questions, so nobody can say what the graph bought.
- Global search wired to a public chat box. Every question fans out across every community summary, and the bill arrives at month end.
6 Steps to Ship Your First GraphRAG Pipeline
The order matters more than the tooling. This is the sequence we would hand the insurer's two-person team.
Write 30 questions your current system gets wrong
Pull them from real logs, not your imagination, and label each single-hop, multi-hop or corpus-wide. Deliverable: a scored baseline run of your vector system on all 30.
Look for edges you already have
Check your ticketing system, CRM, document metadata and approval workflows for relationships someone already records. Deliverable: a list of free edge types with counts.
Hand-write the schema before you prompt anything
Name 8 to 12 entity types and 6 to 10 relationship types in your domain's words: Policy, Claim, Endorsement, Circular, Approver, amends, supersedes, approved_by. Deliverable: a one-page schema your subject expert signed.
Extract on 500 documents, not 80,000
Run the prompt on a slice, read the raw output yourself, count how many entities are duplicates or junk. Deliverable: an extraction prompt whose output you would defend in review.
Load, resolve and traverse
Push nodes and edges into the store, run entity resolution, write the three traversal queries that answer your multi-hop questions. Deliverable: correct subgraphs on the slice.
Index fully, re-score, then decide
Only now pay for the full index, batch the calls for the 50% discount, re-run the 30 questions. Deliverable: a score that justifies keeping the graph, or an honest decision to drop it.
Step 6 is the one teams skip, and skipping it is how a graph survives in production for a year without anyone being able to say what it does. If your scheduled rebuilds need a home, the orchestration patterns in a live Microsoft Fabric data engineering programme transfer directly: a GraphRAG refresh is an ordinary batch job with an expensive middle.
The Honest Caveat: Most Teams Do Not Have a Graph Problem
A large share of the retrieval failures that send teams looking for GraphRAG are chunking, metadata or missing-reranker failures. Your chunks split mid-table. Your filters do not carry the document's effective date, so the model cites a superseded wording. You retrieve top-5 where top-20 plus a reranker would have found the passage. None of that is fixed by a graph, and all of it is cheaper to fix.
The evaluation story is oversold too. The widely circulated graph-versus-vector figures mostly come from vendor blogs and single studies: one comparison published by Neo4j, citing a 2026 study by the UK's National Innovation Centre for Data on 510 complex questions, reports GraphRAG answering 65.3% against 28.9% for vector-only RAG. Striking numbers, from a company that sells graph products, on a question set chosen to be complex. Industry reports suggest hybrid designs beat either approach alone, which is the least exciting and most likely conclusion.
If you are a solo developer with 2,000 documents, skip this entirely. The graph pays for itself at scale and complexity, and you have neither yet.
Learn to build the retrieval system first, then earn the right to add a graph
The AI Engineer Course runs 100+ hours live over 16 weeks and teaches you to build agents that plan, use tools and act, certified on both Microsoft Copilot Studio and Claude Code. You ship a working RAG service, evaluate it against real questions, and add graph retrieval only where the numbers justify it.
Explore the course
Is GraphRAG Worth Learning in 2026?
Yes, but learn the part that transfers. Frameworks here have a two-year half-life; the microsoft/graphrag README is the proof, and LightRAG will be superseded too. What does not expire is the ability to look at a messy corpus and decide what counts as an entity, which relationships are worth materialising, and which questions genuinely need a traversal. That is data modelling, the same skill that made a good warehouse designer valuable in 2015.
For hiring in India, "built a GraphRAG pipeline" reads as a tutorial follow-along. "Found the 30 questions our RAG system failed, proved 11 needed relationship retrieval, shipped a graph for those and left the rest on vector search" reads as an engineer. Postings naming graph retrieval are still a thin slice of AI engineering roles, so treat it as a differentiator on top of solid RAG work, not a specialism to lead with. If you want the retrieval, evaluation and agent layers in one 16-week run, start with the live AI Engineer Course; the generative AI developer track adds the Azure AI retrieval side.
Related guides
- LLM Evaluation in 2026 because steps 1 and 6 both need an eval harness you can trust.
- How Do Large Language Models Work? for the tokens-and-embeddings grounding behind the cost maths.
- AI Engineer Salary in India 2026 for which retrieval and agent skills actually move a pay band.
- AI Engineer Interview Questions 2026 because retrieval design is what panels ask about most.
- AI Engineer Roadmap 2026 for where retrieval work sits in a first-role plan.
Frequently asked questions
What is GraphRAG in simple terms?
GraphRAG is retrieval that reads a knowledge graph instead of a flat pile of text chunks. At index time an LLM pulls entities and relationships out of your documents and stores them as nodes and edges. At query time you follow those edges, so the system can answer questions about how things connect, not just questions that look like one passage.
Is GraphRAG better than vector RAG?
Not in general. GraphRAG is better on multi-hop questions and questions about an entire corpus. Vector RAG is better on single-fact lookups, far cheaper to index and much easier to update. Most production systems that use a graph keep vector search alongside it and route each question to whichever retrieval fits.
How much does it cost to index a corpus with GraphRAG?
Less than people assume on a small model. For 48M tokens of source text, budgeting 120M input and 15M output tokens, the Anthropic pricing page as of 11 October 2026 lists Claude Haiku 5.5 at $0.10 per million input and $0.50 per million output, so about $19.50, or $9.75 with the Batch API's 50% discount. The same run on Claude Sonnet 5.5 is roughly $390, or $195 batched. The real cost is repeated rebuilds.
What is the difference between GraphRAG and LightRAG?
Microsoft's GraphRAG pre-computes community summaries at index time, which is what makes global search possible and indexing expensive. LightRAG, at 40.1k GitHub stars as of 11 October 2026, skips community reports to cut LLM calls at index and query time, and supports incremental inserts and selective deletes by reusing its indexing-time LLM cache.
Is Microsoft GraphRAG still maintained?
Its README states the project is largely in maintenance mode and is not accepting new pull requests or features, with only bug fixes and dependency updates expected, as read on 11 October 2026. It remains a useful reference implementation, but we would not start a new product on it without planning to own the code.
Is GraphRAG worth it for a small document set?
Usually not. Under a few thousand documents, a hybrid of vector search, keyword search, metadata filters and a reranker gets you most of the way, and some questions are answerable by putting the documents straight into a long context window. Graph retrieval pays off when the corpus is large enough that top-k can no longer see the whole picture.
About this guide. 360 Digital Transformation is an Anthropic Partner and a Microsoft Authorized Training Partner. Other certification bodies, vendors and employers named here are not affiliated with us. Product features and pricing change often; figures cited were checked on 11 October 2026.
Python
Claude API
FAISS
ChromaDB
LangChain
LangGraph
CrewAI
AutoGen (AG2)
