"RAG Core Study (23/26) — Graph RAG: Knowledge Graphs Meet Vectors"
Chunk similarity is powerful, but it is not a natural representation for relationship-heavy questions. That is where graphs enter RAG.
Graph RAG combines vector-style retrieval with explicit representations of entities, relations, and multi-hop structure. Traditional retrieval is good at finding locally relevant text. Graph-based retrieval is better at following relationship paths across documents. Part 23 explains why these are complementary rather than competing approaches.
0. Prerequisites
- Part 22 Corrective RAG
- Part 7 metadata design
- Part 9 vector database design
1. Learning Objectives
- Explain why Graph RAG exists at all.
- Understand entity, relation, and multi-hop retrieval as retrieval concepts.
- Distinguish vector retrieval from graph traversal.
- Recognise when Graph RAG is overkill.
2. ํต์ฌ ์์ฝ
Graph RAG tries to recover information not only by semantic similarity, but by explicit relationship structure. For questions like who approved what, and what committee later revised it? a graph can represent the entity links more directly than chunks alone. In practice, Graph RAG often follows a pattern like: vector seed retrieval -> entity extraction -> graph traversal -> context assembly. It can be powerful, but it increases ingestion complexity, update cost, and consistency risk.
3. Intuition — Why Multi-hop Questions Are Hard for Plain Chunk Retrieval
Question: “Which committee revised the procedure that the external-sharing approval policy depends on?”
This may require:
- a policy document
- a procedure document
- a revision-history document
Vector retrieval can find each piece separately, but it does not explicitly store the relationships between them. Graph RAG makes those links first-class.
4. Definitions — Core Graph Terms
| Term | Definition |
|---|---|
| Entity | a person, team, report, policy, product, or other distinct object |
| Relation | a link between entities, such as approved_by or revised_by |
| Triple | a structured statement like (subject, relation, object) |
| Multi-hop Retrieval | retrieval that follows more than one relationship step |
| Graph Traversal | moving through connected nodes and edges to gather evidence |
5. Mechanism — How Graph and Vector Retrieval Complement Each Other
- Vector retrieval answers: what text is semantically close?
- Graph retrieval answers: what objects are structurally connected?
One common hybrid pattern is:
- use vectors to find likely seed documents
- extract entities from those documents
- expand over the graph for supporting links
- assemble the final evidence context
6. Walkthrough — A Minimal Graph RAG Flow
6.1 Triple extraction
triples = [
("External Sharing Exception", "APPROVED_BY", "Security Officer"),
("External Sharing Procedure", "REVISED_BY", "Information Governance Committee"),
]
6.2 Graph query example
MATCH (p:Policy {name: "External Sharing Exception"})-[:APPROVED_BY]->(team)
MATCH (p)-[:REVISED_BY]->(committee)
RETURN team, committee
6.3 Vector + graph combination
seed_docs = vector_store.search(query, k=5)
seed_entities = extract_entities(seed_docs)
graph_context = graph.expand(seed_entities, hops=2)
Self-explanation: Why is Graph RAG not simply “a better vector database”?
7. Variants and Use Cases
7.1 Entity-centric graphs
What changes
The graph is built mainly around named entities and their connections.
Why it matters
It provides a clean way to represent approval chains, ownership, revisions, and dependencies.
What it enables
You can answer relationship-heavy questions more directly.
Limit and next step
Entity extraction quality becomes a critical bottleneck.
7.2 Document-entity hybrid graphs
These connect documents and entities together, allowing retrieval to move between text evidence and structured links.
7.3 Hierarchical summary graphs
Long reports can be represented with summary nodes plus detailed nodes, enabling both global and local retrieval.
8. Limits and Failure Modes
8.1 Graph construction is expensive
If entity or relation extraction is noisy, the graph can become misleading rather than helpful.
8.2 Updates are harder than plain re-indexing
When the underlying documents change, graph consistency must also be maintained.
8.3 Not every corpus needs a graph
Short FAQ corpora or straightforward policy retrieval may gain little from graph complexity.
8.4 Next step — Once retrieval becomes multi-step, planning becomes harder too
At that point retrieval stops looking like a single function call and starts looking like a controlled workflow. That is Part 24.
8.5 Common Pitfalls
| # | Pitfall | Symptom | Fast Check |
|---|---|---|---|
| 1 | using Graph RAG for simple FAQ | overengineering | inspect query structure first |
| 2 | unvalidated entity extraction | wrong relations | sample triples manually |
| 3 | no graph update policy | stale structural evidence | define update triggers |
| 4 | treating graph and vector as substitutes | poor retrieval coverage | keep their roles distinct |
| 5 | expanding too many hops | high noise | cap traversal depth |
9. Self-check — Answer Before Looking
Q1. What kind of question motivates Graph RAG most strongly?
Answer Relationship-heavy and multi-hop questions.
Why Those questions depend on explicit links across documents or entities.
Q2. How does graph traversal differ from vector retrieval?
Answer Graph traversal follows explicit relationships, while vector retrieval finds semantically similar text.
Why The underlying evidence structures are different.
Q3. When can Graph RAG be excessive?
Answer When the corpus mostly supports direct FAQ-style retrieval without meaningful relationship chains.
Why The graph adds ingestion and maintenance cost that may not pay off.
Cheat Sheet — One-page Summary
Definitions - Entity: distinct object in the knowledge space - Relation: explicit connection between entities - Triple: structured relation statement
Minimal code
seed_entities = extract_entities(seed_docs)
graph_context = graph.expand(seed_entities, hops=2)
When to use what | Situation | Retrieval style | |---|---| | direct semantic lookup | vector-first | | relation-heavy question | graph + vector | | multi-document dependencies | graph expansion |
References
Primary sources
- Edge, D. et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. 2024.
Supporting notes
- User notes, chapter 20 Graph RAG
Bridge to the Next Part
Once retrieval itself becomes multi-step and structured, the next question is whether the system should plan those steps explicitly. Part 24 covers Agentic RAG.
๋๊ธ
๋๊ธ ์ฐ๊ธฐ