Guide · Knowledge Graph RAG
Building a Knowledge Graph for RAG
Vector RAG gets you close. A knowledge graph gets you correct. Here's the end-to-end pipeline — extraction, resolution, verification, retrieval — and how each step compounds into a retrieval system that stops hallucinating and starts learning.
Why a graph, not just vectors
Vector-only RAG optimises for semantic similarity — the retriever hands the model chunks that read like the answer. That's fine for single-hop factual questions and disastrous for anything that requires composing facts. Multi-hop questions ("which drugs prescribed to patients in trial X also interact with Warfarin?") force the retriever to guess a chunk that happens to contain the whole chain — and it rarely does.
A knowledge graph makes the chain explicit. Nodes are entities, edges are typed relationships, and every fact carries a source. Retrieval becomes a traversal you can inspect, cite, and improve. The output isn't just "grounded" text — it's a structured answer you can verify.
The six steps
- 01
Extract atomic facts from source text
Chunk your sources, then use an LLM to pull subject–predicate–object triples: ("Warfarin", "interacts_with", "Ibuprofen"). Keep each triple atomic — one claim, one edge. Skip anything the model isn't confident about; a smaller, cleaner graph beats a large noisy one.
- 02
Resolve entities to canonical nodes
"Apple Inc.", "Apple Computer", and "AAPL" all point to one node. Use embeddings plus a lightweight resolver (string similarity + type-aware rules) so the graph doesn't fragment. Every downstream retrieval quality metric — precision, multi-hop recall, provenance — depends on this step.
- 03
Infer and typecheck edges
Give every edge a predicate type from a controlled vocabulary. This is what turns a bag of triples into a queryable graph: you can now ask "which drugs interact with Warfarin?" without the retriever guessing what "interacts_with" means.
- 04
Verify before you index
Every new fact must be checked — against existing facts (contradiction detection), against a second model (cross-verification), and against source provenance (citation retention). Facts that don't verify are quarantined, not indexed. This is the single biggest quality lever a RAG system has.
- 05
Retrieve by graph traversal, not vector similarity alone
At query time, do vector search to find seed nodes, then walk edges to gather the neighborhood. Multi-hop questions ("who founded the company that acquired X?") work because the traversal path is explicit and auditable. Vectors get you close; the graph gets you correct.
- 06
Keep it fresh
A knowledge graph that stops updating is a static snapshot with a slowly rising error rate. Re-verify facts on a rolling schedule, retire facts contradicted by newer verified sources, and feed the deltas back into your extractor so it learns from its own corrections.
How Seedthink does this
Every Seed on Seedthink runs this pipeline as its default ingestion loop. Facts are extracted from URLs and documents, resolved to shared canonical entities, verified against contradicting facts already in the graph, and attached to their source before they're ever exposed to the retriever. Facts that fail verification are surfaced as gaps — a queue the Seed's owner (or the user's questions) can close over time.
The result is a knowledge graph that compounds: it gets more accurate the more it's used, not less. That's the difference between a static graph shipped with a model and an intelligence that grows.