AI & ML

Knowledge Graph

A structured representation of real-world entities and the relationships between them, stored as nodes and edges in a graph database.

A knowledge graph is a network of real-world entities (people, places, concepts, events) and the relationships between them. Data is stored as subject-predicate-object triples (e.g., "Toronto" → "is located in" → "Canada").

Knowledge graphs power Google's Knowledge Panel, Amazon's product recommendations, and enterprise search systems. They excel at answering questions that require connecting multiple facts across different sources.

In AI applications, knowledge graphs complement LLMs and RAG systems by providing structured, traversable relationships. While vector search finds semantically similar documents, graph traversal finds logically connected information through explicit relationships.

Building a knowledge graph involves entity extraction (identifying entities in text), relationship extraction (finding connections), entity resolution (merging duplicates), and graph storage (using Neo4j, Amazon Neptune, or similar graph databases).

How it works

A knowledge graph stores facts as small statements that link to each other. In the W3C's RDF standard each statement is a triple: a subject, a predicate and an object, and a set of triples is an RDF graph. Because triples reuse the same identifiers, the facts join into one connected network instead of sitting in separate rows.

Entities get stable identifiers (IRIs in RDF), so two things that share a name, such as a city and a sports team, become two different nodes. Google described its 2012 Knowledge Graph in these terms: a model of real-world entities and their relationships, "things, not strings". At launch Google said it held more than 500 million objects and more than 3.5 billion facts about and relationships between them.

Questions are answered by traversal: start at a node and follow edges. Query languages such as SPARQL (for RDF stores) or Cypher (for property-graph databases) describe patterns like "every company headquartered in a city that is located in Canada". Each hop is an explicit relationship, so an answer can be traced back to the exact path that produced it.

Two data models are common. RDF uses triples and shared vocabularies so that data from different publishers can be merged. Property graphs attach key-value properties directly to nodes and edges, which many application developers find more natural. Both can hold a knowledge graph; they differ in how identity and schema are expressed.

Example

A tiny graph in Turtle (an RDF text format) and a SPARQL query that needs two hops to answer.

@prefix ex: <https://example.org/> .

ex:Acme     ex:headquarteredIn ex:Toronto .
ex:Toronto  ex:locatedIn       ex:Ontario .
ex:Ontario  ex:locatedIn       ex:Canada .
PREFIX ex: <https://example.org/>

SELECT ?company WHERE {
  ?company ex:headquarteredIn ?city .
  ?city ex:locatedIn+ ex:Canada .   # "+" = follow locatedIn one or more times
}

No triple says Acme is in Canada. The query still returns ex:Acme because the property path walks Toronto → Ontario → Canada. That chain of explicit links is what a keyword or vector search cannot reconstruct on its own.

Common confusion

What is the difference between a knowledge graph and a vector database?

A vector database stores embeddings and returns the items most similar to a query, ranked by a similarity score. A knowledge graph stores explicit, named relationships and returns what is connected to what. Similarity is fuzzy and ranked; graph answers are exact paths.

They solve different problems and are often combined: vector search finds relevant passages, and the graph supplies the relationships between the entities in them. That combination is the idea behind GraphRAG.

Is a knowledge graph the same as a graph database?

No. A graph database is a storage engine optimised for nodes and edges. A knowledge graph is the data itself: entities, their relationships, and usually a schema or ontology describing what those relationships mean. A knowledge graph can live in an RDF triple store, a property-graph database or even relational tables, and a graph database can hold data that is not a knowledge graph.

Further reading

Want to learn more?

Explore more developer terms or read in-depth articles on the blog.

Browse all terms