Knowledge graph

What is a knowledge graph?

A knowledge graph is a structured way of representing information in which real-world entities, such as people, places, organizations, products, and concepts, are stored as nodes, and the relationships between them are stored as edges. The result is a network of interconnected facts that a machine can read, query, and traverse, rather than a flat table of values or an unstructured block of text.

The defining characteristic of a knowledge graph is that relationships are first-class data. A knowledge graph records not only that two things exist but explicitly how they are connected: that a person works for a company, that a city is located in a country, or that a drug treats a condition. This makes connections directly queryable and lets software follow chains of relationships to answer questions that span many linked facts.

The term entered mainstream use when Google launched its Knowledge Graph on May 16, 2012, summarized by the slogan things, not strings. At launch Google described it as containing more than 500 million objects and more than 3.5 billion facts about and relationships between them, and it powered the information panels that still appear beside many search results.

• Entities are stored as nodes (the things).
• Relationships are stored as labeled edges (how things connect).
• Both can carry attributes, and the whole structure is machine-readable.
• The graph can be queried by following relationships across many hops.

Nodes, edges and triples: how knowledge graphs represent facts

The atomic unit of most knowledge graphs is the triple, a single statement in the form subject, predicate, object. The subject and object are entities (nodes), and the predicate is the relationship (edge) that links them. For example, the fact that Marie Curie won a Nobel Prize can be encoded as the triple (Marie Curie, won, Nobel Prize). Many such triples chained together form the graph.

Two main technical conventions exist for building these graphs. RDF (Resource Description Framework), a World Wide Web Consortium standard, represents everything as triples and is queried with the standardized SPARQL language. Property graphs, popularized by databases such as Neo4j, attach arbitrary key-value properties directly to both nodes and edges and are typically queried with a traversal language such as Cypher. RDF emphasizes formal semantics and interoperability across systems, while property graphs emphasize operational navigation and fast traversal.

Because relationships are stored explicitly, a query can hop from node to node: start at one entity, follow an edge to a neighbor, then follow another edge from there. This multi-hop traversal is what lets knowledge graphs answer questions like which researchers co-authored papers with people who later joined a particular lab, a query that would require many joins in a conventional relational database.

# Each fact is a triple: (subject, predicate, object)
(Ada_Lovelace, born_in, London)
(Ada_Lovelace, worked_on, Analytical_Engine)
(Analytical_Engine, designed_by, Charles_Babbage)
(London, located_in, England)

# Nodes: Ada_Lovelace, Analytical_Engine, London ...
# Edges (predicates): born_in, worked_on, designed_by, located_in

Ontologies and schemas

Many knowledge graphs are organized by an ontology, a formal specification of the categories of entities, the types of relationships allowed between them, and the constraints that govern them. An ontology might declare that a Person can be employed_by an Organization, that an Organization has a headquarters_in a Location, and that certain relationships are mutually exclusive. This shared vocabulary keeps data consistent and enables logical inference, so that new facts can be deduced from existing ones.

In the RDF world, ontologies are expressed with standards such as RDFS and OWL, which add formal meaning and support automated reasoning. Not every knowledge graph uses a heavy formal ontology, however. Some use only a lightweight schema, and others are effectively schema-less, growing organically as new entity and relationship types are added. The right level of formality depends on whether the priority is rigorous reasoning and interoperability or flexibility and speed of iteration.

• Ontology: the formal model of entity types, relationship types, and rules.
• Schema: a lighter set of constraints on structure.
• Formal ontologies (OWL, RDFS) enable logical inference and interoperability.
• Schema-less graphs trade rigor for flexibility.

Knowledge graphs vs vector databases vs relational databases

These three technologies organize information in fundamentally different ways. A relational database stores data in tables with rows and columns and excels at structured, tabular records with well-defined schemas. Relationships exist through foreign keys, but querying deep, many-hop connections requires repeated joins that grow expensive and awkward.

A vector database stores information as numerical embeddings: high-dimensional vectors that capture the semantic meaning of text, images, or other content. It answers similarity queries, finding the items closest in meaning to a query, which is the backbone of semantic search. It does not, however, store explicit relationships or guarantee factual precision; it returns what is similar, not what is logically connected.

A knowledge graph sits between these. Like a relational database it is precise and structured, but unlike a relational schema it makes relationships explicit and cheap to traverse across many hops. The tradeoff is that knowledge graphs require defining entities and relationships up front and handle fuzzy, meaning-based matching less naturally than vector search. Many modern systems combine a vector database for semantic recall with a knowledge graph for precise, relationship-aware reasoning.

• Relational database: tables and joins, strong for structured records, weak at deep relationship traversal.
• Vector database: embeddings and similarity search, strong for meaning-based recall, no explicit facts.
• Knowledge graph: explicit entities and relationships, strong for multi-hop reasoning and precision.

Knowledge graphs in search and AI agents (GraphRAG)

Knowledge graphs have long powered search engines and recommendation systems by connecting entities so that a query for one thing can surface related things. The same structure is now used to ground large language models. Standard retrieval-augmented generation (RAG) fetches text passages by semantic similarity and feeds them to a model. GraphRAG, a technique from Microsoft Research released as an open-source library in 2024, instead uses an LLM to extract a knowledge graph from a document corpus, builds a hierarchy of topical communities, summarizes them, and uses that structure during retrieval.

The advantage is most visible on global questions that require synthesizing information scattered across many documents, where plain semantic search struggles to assemble the full picture. By following explicit relationships and community summaries, GraphRAG can answer broad, connect-the-dots questions and trace how a conclusion was reached, which improves both reasoning quality and traceability.

For AI agents, a knowledge graph can serve as a structured, queryable memory: a place to store facts about entities and their relationships that an agent can look up precisely rather than approximating from raw text. This makes graphs attractive wherever an agent must reason over interconnected facts and explain its answers.

Strengths, limits, and the cost of building one

The strengths of a knowledge graph follow from its explicit structure. It supports precise multi-hop queries, enables logical inference when an ontology is present, makes provenance and reasoning auditable, and integrates heterogeneous data sources under a shared vocabulary. These properties matter in domains such as fraud detection, drug discovery, and enterprise data integration, where relationships and explainability are central.

The costs are equally structural. Designing an ontology, extracting clean entities and relationships, resolving duplicates (deciding that two records refer to the same real entity), and keeping the graph current all require significant engineering and domain expertise. Extraction from unstructured text is imperfect, and a graph built from noisy data inherits that noise. Knowledge graphs also handle ambiguous, meaning-based queries less gracefully than vector search, because they rely on explicit, predefined relationships.

• Strengths: precise traversal, inference, explainability, data integration.
• Costs: ontology design, entity extraction and resolution, ongoing maintenance.
• Weakness: fuzzy, semantic matching is not the native strength of a graph.

When semantic retrieval beats explicit graphs

A knowledge graph is not always the right tool. When the goal is to retrieve relevant passages by meaning rather than to reason over precise relationships, semantic retrieval with embeddings is often simpler, cheaper, and good enough. Vector search needs no ontology and no manual relationship modeling: content is embedded and queried directly, which scales easily across messy, unstructured collections.

This is the model many consumer AI memory and second brain tools adopt, where a user stores documents, notes, photos, and voice memos and later retrieves them by asking in plain language, with semantic search and optical character recognition handling the matching instead of an explicit graph. The practical guideline is to choose semantic retrieval when queries are about similarity and recall over unstructured content, and to invest in a knowledge graph when queries depend on precise, multi-hop relationships and the answers must be explainable. Hybrid systems that pair both are increasingly common.