Every technique in this series so far retrieves chunks of text based on similarity - vector, keyword, or a hybrid of both. That works well when the answer lives inside one or two documents. It works much worse when the answer depends on relationships scattered across many documents - "which projects did people who left the company in the last year work on" isn't a similarity problem, it's a connect-the-dots problem. GraphRAG is what you reach for when the second kind of question shows up often enough to matter.
The kind of question vector search struggles with
Vector similarity finds chunks that resemble the query in meaning, but it has no concept of entities or the relationships between them. A question like "who reports to the manager of the team that shipped the Q2 release" requires traversing a chain of relationships - manager, team, release - that no single chunk is likely to state outright, even if every individual fact is written down somewhere in the corpus. Vector search will return chunks that mention some of those terms, but stitching them into a correct answer is left entirely to the model's ability to reason over loosely related fragments, which is unreliable at best.
What a knowledge graph adds
A knowledge graph represents information as entities (people, projects, documents, products) and explicit relationships between them (manages, shipped, belongs-to), rather than as unstructured chunks of text. GraphRAG builds this graph - often by using an LLM to extract entities and relationships from your source documents during ingestion - and then retrieval becomes graph traversal: starting from entities mentioned in the query and following relevant relationships outward, rather than searching for chunks that merely resemble the query text.
Vector retrieval finds similar text. Graph retrieval follows explicit, named relationships between entities.
Community summaries and global questions
Beyond point-to-point traversal, some GraphRAG implementations also cluster related entities into "communities" and generate summaries of each cluster in advance. This helps with a different kind of hard question - broad, corpus-wide questions like "what are the main themes across all customer complaints this quarter" that don't have a single answer chunk at all, but require synthesizing across a large portion of the graph. Precomputed community summaries make that kind of global question answerable without traversing the entire graph at query time.
The real cost of going this route
GraphRAG is meaningfully more expensive to build and maintain than a standard vector pipeline: entity and relationship extraction typically requires LLM calls over your entire corpus during ingestion, the graph needs to be kept in sync as documents change, and querying it well requires different tooling than a vector database. It's not a drop-in upgrade - it's a different architecture with its own operational overhead.