Standard RAG retrieves by similarity: embed the question, find the chunks whose embeddings are nearest, hand them to the model. It works well for "find me text about X." It falls down on questions whose answer lives in the relationships between facts. That's the gap Graph-RAG fills.
Where vector search struggles
Ask "which projects did the people who worked on X later lead?" and pure similarity search flounders. The answer isn't in any single similar-looking chunk — it's assembled by following connections: X to its people, people to their later projects. Similarity retrieves neighbors in meaning; it doesn't traverse relationships.
Vector search finds things that sound alike. Graph-RAG finds things that are connected.
The graph approach
Graph-RAG builds a structured representation — entities and the relationships between them — and retrieves by traversing it. Instead of only pulling similar text, it can follow edges: from a concept to related concepts, from an entity to its connections. For multi-hop questions that span several linked facts, this retrieves the right context rather than the merely similar.
When to use which
Graph-RAG isn't a replacement — it's a complement. For straightforward "find relevant passages" needs, vector search is simpler and often enough. For questions that require connecting multiple pieces of information, or reasoning over a web of entities, the graph structure earns its complexity. The strongest systems increasingly combine both: similarity to find entry points, structure to traverse from there.
The broader point is that retrieval is not one technique. Matching the retrieval method to the shape of the question — flat similarity, structured relationships, or both — is becoming a core design decision.
