GraphRAG

Vector RAG is excellent at finding similar passages. It is weaker when the answer lives across many documents or when the question asks for a global pattern: "which suppliers create the most compliance risk across all contracts?" GraphRAG answers by turning the corpus into entities, relations, communities, and summaries.

The pipeline#

First, an LLM extracts entities and relationships from chunks: companies, people, products, claims, dependencies. Those become graph nodes and edges. Next, community detection groups related nodes. Then the system writes summaries for each community and often summaries of summaries. Retrieval can now choose passages, graph neighborhoods, or community summaries depending on the question.

Local and global search#

Local search starts from entities mentioned in the query and expands around their graph neighborhood. It is good for questions about one customer, one product, or one incident. Global search uses community summaries to answer broad questions across the corpus. That is the distinctive GraphRAG move: summarize structure first, then query the summaries.

Cost realities#

GraphRAG is not a default replacement for vector search. Indexing is expensive because extraction and summarization call models many times. The graph also needs maintenance when documents change. For straightforward "find the paragraph that says X" workloads, hybrid search plus reranking is usually simpler and better.

Practical takeaways#

Reach for GraphRAG when your questions are multi-hop, cross-document, or about themes across a corpus. Keep plain vector RAG for targeted lookup. The best systems combine both: vector search for evidence, graph search for structure, and citations back to original documents so generated summaries can be audited.