What is GraphRAG and which kind of question is it built for?

**GraphRAG** is a retrieval pattern that prepares the corpus differently from plain vector RAG. Instead of just chunking and embedding text, it does extra offline work: an LLM reads the documents and pulls out entities (people, products, concepts) and the relationships between them, building a knowledge graph. That graph is then clustered into communities — groups of densely connected entities. For each community, an LLM writes a short summary. All of this happens ahead of time, before any user asks anything. The reason to do it is the kind of question it unlocks. Standard top-k retrieval only grabs the chunks most similar to your query, so it is great for fact lookups like "what is the refund window?" But it cannot answer global questions like "what are the main themes across all these reports?" because no single chunk holds that answer. GraphRAG answers those by reasoning over the community summaries, which together cover the whole corpus. The catch is cost: building and refreshing the graph burns a lot of LLM tokens.

**GraphRAG** restructures retrieval around a knowledge graph instead of a flat vector index. The offline pipeline has an LLM extract entities and their relationships from the corpus and assemble them into a graph. It then runs community detection to cluster densely connected entities, and generates a summary for each community at multiple levels of granularity. The motivation is a structural gap in vanilla RAG. Top-k similarity search retrieves a local slice — the few chunks nearest the query in embedding space. That serves specific, local fact lookups well, but it can never assemble a corpus-wide answer. A question like "what are the recurring themes?" has its answer distributed across the entire collection rather than concentrated in any one passage. GraphRAG answers global questions by map-reducing over community summaries. Each summary is queried for a partial answer, then those partials are combined into a final response that reflects the whole corpus structure. Local, entity-centric questions can also be served by walking the graph from the relevant nodes. The trade-off is the build cost. Extracting the graph and summarizing every community is token-heavy, and refreshing it when documents change is expensive too. So GraphRAG earns its keep on connected corpora where sensemaking questions matter, and is overkill when users only ask simple fact lookups.