Artykuł opublikowany po angielsku.
GraphRAG vs Vector RAG: Choosing a Retrieval Strategy by Question
Vector search finds similar text, but multi-hop questions need relationships. Learn when GraphRAG, hybrid or keyword retrieval fits, and what a graph costs to run.
The first version of a RAG application tends to look refreshingly simple. Process a document, split the text into chunks, embed each chunk, and store the vectors in a database. When a question arrives, fetch the closest chunks and pass them to the LLM. The whole flow in one picture:
Documents
│
▼
Text Extraction
│
▼
Chunking
│
▼
Embeddings
│
▼
Vector Database
│
│
User Query ─────────┘
│
▼
Similarity Search
│
▼
Context
│
▼
LLM
│
▼
Answer
For a large share of questions, that setup works remarkably well. Enterprise document intelligence exposes a second kind of question, though, where finding semantically similar text doesn't settle things. The difficulty stops being "can the system find relevant text?" and becomes "can it find the relevant information and also understand how the pieces connect?" That gap is where the rest of the discussion sits.
A question that spans documents
Take a simplified enterprise knowledge base. One file describes an engineering standard:
Document A
↓
Engineering Standard
↓
Requirement R1
Another holds a project specification:
Document B
↓
Project Specification
↓
Component C1Document C
↓
Validation Rule
↓
Rule V1
Now someone asks which requirement applies to Component C1, which standard defines that requirement, and which validation rule should be used. No single document holds the answer. A correct response means linking several facts:
Component C1
│
│ governed by
▼
Requirement R1
│
│ defined by
▼
Engineering Standard
│
│ validated by
▼
Validation Rule V1
A vector database doesn't know that structure exists. Its job is to find content that is semantically close to the query, and that job is very valuable. Semantic similarity and reasoning over relationships are simply different things.
Where vector search is the right tool
Being fair to vector retrieval matters before bringing graphs into it. It's one of the most useful building blocks for RAG, and the typical flow runs like this:
User Query
│
▼
Query Embedding
│
▼
Vector Similarity Search
│
▼
Top-K Chunks
│
▼
Context Construction
│
▼
LLM
Ask "What are the requirements for road pavement thickness?" when the knowledge base has a section on exactly that, and semantic retrieval will usually surface it. The question is local, so there's no need to understand a wide network of connections. Vector retrieval fits best when:
- the answer lives in one place
- semantic closeness is a decent stand-in for relevance
- documents can be handled mostly on their own
- a few passages are enough to answer
- keeping retrieval simple is a priority
So "is vector RAG good or bad?" is the wrong question to ask. The useful one is what kind of retrieval problem is actually on the table, because the answer to that decides whether plain similarity search is enough or whether something richer is needed.
Knowledge is usually connected
Enterprise material rarely sits in isolation. A standard defines requirements, and each requirement points to further things:
Standard
│
├── defines → Requirement
│
├── references → Section
│
└── supersedes → Previous Standard
Requirement
│
├── applies_to → Component
├── depends_on → Condition
└── validated_by → RuleComponent
│
├── belongs_to → Project
└── uses → Material
A question that touches several of these links brings in multi-hop retrieval. The system may need to:
- find the component
- work out which requirement applies
- identify the governing standard
- collect associated conditions
- locate the validation rule
- combine all the evidence
That's a different retrieval problem from fetching the nearest paragraph.
What a knowledge graph adds
A knowledge graph represents entities and their relationships explicitly. The usual pipeline treats knowledge as:
Document → Chunk → Embedding
A graph adds a second representation alongside it:
Entity ──relationship──> Entity
An example of how that looks in practice:
Standard
│
defines
│
▼
Requirement
│ │
applies_to validated_by
│ │
▼ ▼
Component Rule
│
belongs_to
│
▼
Project
The graph doesn't replace the documents. They stay the source material, and the graph becomes a structured layer describing the entities inside them and how they relate.
GraphRAG in one paragraph
GraphRAG pairs retrieval-augmented generation with graph-based knowledge representation and retrieval. Rather than leaning only on semantic similarity, the system follows relationships between entities and concepts to find relevant information. Conceptually:
User Query
│
▼
Query Understanding
│
┌──────────┴──────────┐
▼ ▼
Vector Retrieval Graph Retrieval
│ │
▼ ▼
Relevant Chunks Related Entities
│ │
└──────────┬──────────┘
▼
Evidence / Context
│
▼
LLM
│
▼
Answer
Implementations vary a lot. What stays constant is that retrieval has access to relationships, not just similarity.
Two different questions
The clearest way to separate the two is by what each one asks. Vector retrieval asks, roughly, which content is most similar to the query. Graph retrieval can ask which entities connect to the concepts in the query, and what can be learned by following those links.
They can work as a team:
Query
│
┌────────┴────────┐
▼ ▼
Semantic Structural
similarity relationships
│ │
▼ ▼
Chunks Entities
│ │
└────────┬────────┘
▼
Evidence
For that reason, GraphRAG isn't just a better vector database. It's another retrieval strategy for another class of problems.
When relationships earn their keep
Explicit relationships tend to pay off in a few situations.
Multi-step questions. A question such as "Which regulation governs this part, and what extra validation rules come with it?" can only be answered by walking several links in turn:
Component
↓
Requirement
↓
Regulation
↓
Validation Rule
Relationship-dense domains. Some fields are full of connections, including regulations, engineering standards, financial entities, scientific knowledge, product catalogs, organizational knowledge and dependency networks. There the relationships carry meaning of their own.
Evidence spread across files. One document defines a requirement, another gives an exception, a third explains validation. The hard part is stitching them together correctly.
Whole-entity questions. "What are all the requirements associated with this entity?" suits relationship-aware retrieval naturally.
The cost of adding a graph
It's tempting to hear about knowledge graphs and decide that vector RAG is old and GraphRAG is better. That's the wrong engineering takeaway. Graphs bring extra complexity, with more stages to build and run:
Document Processing
↓
Entity Extraction
↓
Relationship Extraction
↓
Entity Resolution
↓
Graph Construction
↓
Graph Storage
↓
Graph Retrieval
↓
Context Construction
Each stage is a new place to fail, and failures compound as they move down the pipeline. What if entity extraction is wrong? What if two entities share a name but differ? What if a relationship is inferred incorrectly, or the graph ends up incomplete, or maintaining it gets expensive as documents change? Those are engineering problems, not only AI problems.
The graph has to be built
A graph doesn't appear on its own. Construction is part of the job, and a simplified pipeline looks like this:
Documents
│
▼
Document Processing
│
▼
Text / Structure
│
▼
Entity Extraction
│
▼
Relationship Extraction
│
▼
Entity Resolution
│
▼
Knowledge Graph
Suppose one sentence in a source file states that R-102 is the rule for bridge part B-17 whenever C-4 holds. Turned into structure, that could read:
(R-102)
│
applies_to
↓
(B-17)
(R-102)
│
requires_condition
↓
(C-4)
Retrieval can then use those links. But if extraction mistakenly produces
R-102 → applies_to → B-71
the graph will carry wrong information forward. That's why the quality of knowledge extraction becomes part of retrieval quality.
Vector and graph together
Real systems often don't need to pick one. The pattern can be vector and graph:
Query
│
▼
Query Analysis
│
┌──────────┴──────────┐
▼ ▼
Vector Retrieval Graph Retrieval
│ │
▼ ▼
Relevant Chunks Related Entities
│ │
└──────────┬──────────┘
▼
Evidence Fusion
│
▼
Context Building
│
▼
LLM
Vector search finds semantically relevant passages, and graph retrieval supplies relationship context. Together they produce richer evidence, which helps most when a question combines "find the relevant information" with "understand how it connects."
Keyword, vector, hybrid and graph
Moving from keyword search to vector search to GraphRAG doesn't mean each step retires the one before it. Each method answers a different need:
Keyword Search
│
└── Exact terms / identifiers
Vector Search
│
└── Semantic similarityHybrid Search
│
└── Exact + semantic relevanceReranking
│
└── Improve ordering of candidatesGraph Retrieval
│
└── Relationship-aware retrieval
A production system may combine several of them. The engineering task is deciding which signals matter for the problem at hand.
Start from the answer
Rather than opening with "should GraphRAG be used?", begin with what a correct answer requires retrieving.
If it takes one strongly relevant passage, this may be enough:
Query
↓
Vector Search
↓
Passage
If exact identifiers matter, this may help:
Query
↓
Keyword / Metadata Search
If semantic understanding is the need, this is useful:
Query
↓
Vector Search
If several retrieval signals are needed, this fits better:
Query
↓
Hybrid Search
↓
Reranking
If relationships must be traversed, graph retrieval gets interesting:
Query
↓
Entity Identification
↓
Graph Retrieval
↓
Related Evidence
And if the retrieval strategy itself has to change from question to question, an agentic workflow may be justified:
Query
↓
Decision / Planning
↓
Choose retrieval strategy
↓
Retrieve
↓
Evaluate evidence
↓
Retrieve again if necessary
↓
Answer
A graph turns it into systems engineering
Without a graph, the system is just:
Application
↓
Vector Database
↓
LLM
With one, it becomes something closer to:
Application
│
▼
Query Understanding
│
┌─────────┴─────────┐
▼ ▼
Vector Store Graph Store
│ │
└─────────┬─────────┘
▼
Retrieval Layer
│
▼
Context Builder
│
▼
LLM
A new list of concerns lands on the team: how the graph gets built, keeping it in sync with the documents, indexing it, query latency, consistency, how good the graph really is, resolving duplicate entities, where it's stored, how to monitor it, and how to evaluate it. At that point GraphRAG stops being a framework feature and becomes a systems-engineering problem.
Rethinking what RAG is
Work on document intelligence changes how RAG looks. At first it seems to mean retrieving the right chunks and handing them to the LLM. A broader view is to design a representation of knowledge that lets the system fetch the evidence needed to answer the question. Sometimes that representation is chunks and embeddings. Sometimes metadata helps, or hybrid retrieval, or relationships important enough to justify a graph. And sometimes the system must decide dynamically how to search. Architecture should follow the information needs of the problem, not the popularity of a technology.
A simple decision model
Reduced to a mental model, the choice looks like this:
What does the question require?
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Exact terms Semantic meaning Relationships
│ │ │
▼ ▼ ▼
Keyword/ Vector Graph
Metadata Search Retrieval
│ │ │
└────────────────┼────────────────┘
▼
Hybrid System
│
▼
Reranking
│
▼
Context Building
│
▼
LLM
The goal isn't the most sophisticated architecture. It's the simplest one that reliably solves the retrieval problem.
Vector search is powerful, but similarity isn't the same as understanding relationships. When questions turn multi-hop, cross-document, entity-centric or relationship-heavy, modeling knowledge explicitly adds another strong retrieval mechanism. GraphRAG isn't interesting because it beats RAG. It's interesting because different questions call for different retrieval strategies. Understand the question and the structure of the knowledge first, and pick the technology after.