GraphRAG addresses a gap in standard vector-based RAG: while similarity search handles local questions whose answers resemble the query and sit in a specific document, it fails on global questions requiring reasoning across an entire corpus, since the true answer emerges as a pattern rather than a retrievable location. GraphRAG solves this by extracting entities and relationships into a knowledge graph, clustering it hierarchically via Leiden clustering into communities, and generating summary reports for each community during indexing. Local search expands from matched entities into a ranked context window, while global search runs map-reduce over community reports. Microsoft's data shows graph extraction accounts for roughly 75% of indexing cost, and larger context windows (64K tokens) don't close the gap on global queries. Cost-reduction variants like LazyGraphRAG and FastGraphRAG trade graph quality for cheaper indexing, and agentic RAG adds a routing layer that picks a retrieval strategy per query rather than committing to one architecture.
Table of contents
AI’s Next Bottleneck Is Deployment. (Sponsored)Retrieval BasicsSimilarity Limits[Webinar] How to stop babysitting your agents (Sponsored)Knowledge GraphsGraph ConstructionCommunity DetectionQuery ModesCost TradeoffsAgentic RetrievalConclusionQuestions this post answers
Why does standard vector RAG fail on questions that require reasoning across an entire document collection, like finding the most common failure cause across all postmortems?
Standard RAG retrieval relies on the assumption that the answer text resembles the query text, which breaks down for global questions whose answer is a pattern distributed across hundreds of documents rather than located in one retrievable chunk. The nearest-neighbor vectors returned are just vocabulary matches (e.g. documents using the word 'recurring'), not the underlying pattern, so the model produces fluent but poorly grounded text. Anyone weighing retrieval architectures for corpus-wide questions can find deeper GraphRAG breakdowns on daily.dev.
Does using a larger context window instead of GraphRAG fix the retrieval quality gap on global questions?
No. Microsoft tested vector retrieval with 8,000 and 64,000 tokens of context against GraphRAG, and even the 64,000-token window left the gap open on comprehensiveness, diversity, and quality of supporting source material for global questions. Larger context alone does not substitute for a structure that aggregates information across the whole corpus. Developers deciding between bigger context windows and structured retrieval can track findings like this on daily.dev.
How much does GraphRAG indexing cost compared to standard vector RAG, and how does LazyGraphRAG reduce that cost?
Graph extraction accounts for roughly 75 percent of GraphRAG's total indexing cost because it requires two language model passes over the corpus (one for entity/relationship extraction, one to merge descriptions) plus report generation for every community at every hierarchy level. LazyGraphRAG instead builds its index using NLP rather than an LLM and defers language model work to query time, cutting indexing cost to 0.1 percent of full GraphRAG while keeping global-query quality comparable and dropping query cost by more than a factor of 700. Teams budgeting for RAG infrastructure can follow cost-tradeoff writeups like this on daily.dev.
2.4K Impressions1 Comment