A knowledge graph is a way of organizing knowledge as a network of "entities" and the "relationships between them." Take a triple like "Zhang Wei — works at — a tech company — as an engineer": link enough "subject–relation–object" triples together and you get a graph. The biggest difference from a table: relationships are first-class citizens, so you can query connections directly without joins.
What it looks like
The most intuitive picture is nodes plus edges: nodes are entities like people, companies, places, and events; edges are relations like "founded in," "located in," or "acquired." The relation itself carries a name, so a machine reading it understands the meaning instead of guessing from column headers. The knowledge panels in search engines and the infoboxes on encyclopedia pages are often powered by knowledge-graph thinking.
Three boundaries: what is not a knowledge graph
First, something that does semantic retrieval is not a knowledge graph—that is a vector database: vectors store "what it resembles," while a knowledge graph stores "how things relate." Second, a graph database is not the same as a knowledge graph: a graph database is a storage engine, while a knowledge graph is a way of organizing knowledge; the engine can hold a knowledge graph, but it can hold other graphs too. Third, a large language model itself is not a knowledge graph: the knowledge implicit in model parameters is probabilistic and fallible, whereas every relation in a knowledge graph is explicitly stated and traceable.
Comparison: how knowledge graphs, vector databases, and RAG divide the work
One sentence to settle the three-way relationship: RAG is the workflow that does the job, while vector databases and knowledge graphs are two kinds of knowledge stores feeding that workflow.
| Dimension | Knowledge graph | Vector database | | Stores | Entities and explicit relations | Text converted into vectors | | Strength | Multi-hop reasoning, precise QA | Fuzzy semantic matching | | Typical query | "Which other companies did company A's founder start?" | "Find a passage with a similar meaning" | | Weakness | Expensive to build, slow to update | Prone to irrelevant answers |
RAG (retrieval-augmented generation) is the full pipeline of handing retrieved knowledge to a large model and then answering: it can do semantic retrieval against a vector database, relation queries against a knowledge graph, or both—an approach researchers call GraphRAG.
Three common misconceptions
Misconception one: "knowledge graphs are obsolete, replaced by vector retrieval." The opposite is true—relational questions are exactly where vector retrieval falls short: multi-hop questions (like "who acquired the previous company of a product's founder") often break the retrieval chain, and graph-based relation reasoning fills the gap. Misconception two: "building a knowledge graph means installing a graph database." The engine is just the container; the real work is in ontology design and entity alignment—deciding whether "Beijing" and "Beijing City" are the same node matters far more than which database you pick. Misconception three: "small companies can't use one." Hand-building a domain-wide graph is indeed costly; the pragmatic approach is small and focused: cover one business domain, such as a product fault library or a regulations database, and that's where results come fastest.
Where it truly shines
Related-party tracing in financial risk control, product knowledge QA in e-commerce, drug-interaction queries in healthcare, policy-clause tracing in customer service—the common thread is that answers must be precise, explainable, and traceable to specific relations, not just text that "looks similar." A knowledge graph answers "what it actually is": when the business can't tolerate vague answers, a network of explicit relations remains indispensable infrastructure.
