GraphRAG
Retrieval over a knowledge graph the model built from your documents — better at questions about the whole corpus, and expensive enough that most projects shouldn't.
When not to use it
- Lookup questions. If the answer lives in a chunk, standard RAG finds it faster and for a fraction of the cost.
- Frequently changing corpora. The index is expensive to build and doesn't update incrementally in any pleasant way.
- Before you've built standard RAG. You don't yet know whether your users ask global questions, and they probably don't.
Reach for something else instead
- Standard RAG answers most real questions and costs an embedding per chunk.
- Reranking is the cheapest large improvement to a RAG system and should be exhausted first.
- Hierarchical summarisation without a graph may capture much of the benefit — this is the untested ablation.
Sources & further reading
- Edge et al. (2024), From Local to Global: A Graph RAG Approach to Query-Focused Summarization — the Microsoft Research paper; graph extraction, community detection, hierarchical summaries.
- Lewis et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — the baseline it extends and the thing to build first.
- Liu et al. (2023), Lost in the Middle: How Language Models Use Long Contexts — why stuffing the whole corpus into context isn't the alternative it appears to be.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Building it before knowing your query mix. It's an expensive answer to a question most users don't ask.
- Underestimating entity resolution. Duplicate entities silently split the connections you built the graph for, and nothing errors.
- Assuming the graph is what's helping. Multi-level summarisation may be doing the work, and the ablations that would tell you are largely missing.