Graph RAG builds a knowledge graph of entities and relationships from your documents.
Retrieval then traverses that graph rather than only matching similarity.
This answers questions requiring several connected hops.
It can also summarise across an entire corpus rather than a few chunks.
It costs far more to build and maintain than plain vector RAG.
Graph RAG builds a knowledge graph from your documents instead of only chunking them.
Entities become nodes and relationships between them become edges.
A model extracts both during ingestion, which is the expensive part.
Retrieval then traverses the graph rather than only matching similarity.
That answers questions plain vector search handles badly.
Which suppliers are affected if this factory closes requires following connections.
No single chunk contains that answer, since it lives across several documents.
Vector search returns chunks about factories and chunks about suppliers, unconnected.
The graph holds the connection explicitly and can be walked.
It also supports corpus-level questions such as what are the main themes here.
Communities in the graph can be summarised in advance for exactly that.
The cost is substantial, since extraction means a model call per chunk.
The graph must also be maintained as documents change, which is harder than updating an index.
Extraction errors compound, because a wrong edge produces a confidently wrong traversal.
It is worth it for connected domains and overkill for a straightforward document search.
One question on this card. Every option explains itself once you pick, right or wrong.
19 concepts in this module, then a graded test with every answer explained.