Plain vector RAG quietly fails on a whole class of questions: anything that requires connecting facts scattered across many documents, or summarizing what an entire corpus is "about." Similarity search returns the most relevant chunks, but never the relationships between them. GraphRAG's core move is to do the reasoning work at index time — turning unstructured text into an entity-and-relationship graph, then partitioning that graph into communities and pre-summarizing each one, so a query can reason over structure rather than scrounge for snippets.
What Sets It Apart
- LLM-extracted knowledge graph: entities, relationships, and claims are pulled from source text, so retrieval traverses connections rather than matching keywords.
- Hierarchical Leiden communities with bottom-up summaries: the corpus is clustered into nested communities, each summarized in advance, which is what enables corpus-level "sensemaking" answers.
- Three query modes for different shapes of question: Global Search aggregates community summaries for broad themes, Local Search grounds entity-specific questions in graph context, and DRIFT Search blends the two.
- On global sensemaking over million-token datasets, the graph approach measurably improves answer comprehensiveness and diversity versus a conventional RAG baseline.
Who It's For and the Trade-offs
Great fit if you need to answer "what are the main themes," "how do X and Y connect," or holistic questions over a large private corpus where chunk-level retrieval falls short. Look elsewhere if your questions are narrow lookups that vector RAG already nails — the indexing pass runs many LLM calls to extract and summarize the graph, so it costs real tokens and time up front. The payoff is in query quality on hard, cross-document questions, not in cheap one-off retrieval.
