Knowledge Graph

A knowledge graph is a structured representation of facts in which nodes are entities, such as people, places, products, or concepts, and labeled edges are the relationships between them. Each fact is a triple of subject, predicate, and object, such as (Marie Curie, born in, Warsaw), and a schema or ontology defines which types of entities and relationships are allowed. Because relationships are stored explicitly, a system can answer questions by following paths through the graph, combine facts from different sources about the same entity, and infer facts that were never stated directly. Google's Knowledge Graph, launched in 2012, supplies the fact panels beside search results, and Wikidata, the free knowledge graph maintained by Wikimedia volunteers, holds more than 100 million items.

Entities, Relationships, and Triples#

• Entities (nodes): Things with an identity, each typed by the ontology, such as a person, a city, or a chemical compound.
• Relationships (edges): Directed, labeled links such as "born in" or "capital of". The label carries meaning, so (Warsaw, capital of, Poland) and (Poland, capital of, Warsaw) are different claims.
• Attributes: Literal values attached to an entity, such as a date of birth or a population.
• Ontology: The schema of classes, relationship types, and rules, for example that every capital is a city, which lets a reasoner derive new facts from existing ones.

Two data models dominate. The W3C's Resource Description Framework (RDF) identifies every entity and relationship with a web URI and stores pure triples queried with SPARQL, which suits open, linked data such as Wikidata. Property graphs, used by graph databases such as Neo4j, let nodes and edges carry key-value properties and are queried with languages such as Cypher or GQL, which ISO published as a standard in April 2024.

In this small graph, the question "in which country was Marie Curie born?" is a two-hop path from Marie Curie through Warsaw to Poland, and the shared "won" edges connect both Curies to their joint 1903 prize.

Building and Querying a Knowledge Graph#

Graphs are populated from curated databases, from text through named entity recognition (NER) and relation extraction, increasingly performed by large language models (LLMs), and from images. Entity resolution then merges different mentions of the same thing, such as "M. Curie" and "Marie Skłodowska-Curie," into one node. Beyond explicit queries, knowledge graph embeddings such as TransE represent each entity and relation as a vector and score a candidate triple by how closely head plus relation lands on tail, which predicts missing links, and graph neural networks learn from the graph's structure directly.

Computer vision supplies entities and relations from images. The output of a YOLO26 detector becomes (image, contains, class) triples, and joining them with background facts answers questions the detector alone cannot, such as which vehicle types appear in an image:

import networkx as nx
from ultralytics import YOLO

# Detect objects in an image
model = YOLO("yolo26n.pt")
results = model("https://ultralytics.com/images/bus.jpg")
result = results[0]

# Each detected class becomes an entity node linked to the image
graph = nx.DiGraph()
for class_id in result.boxes.cls.int().tolist():
    graph.add_edge("bus.jpg", result.names[class_id], relation="contains")

# Background knowledge as (subject, relation, object) triples
for subject, relation, obj in [("bus", "is_a", "vehicle"), ("car", "is_a", "vehicle"), ("person", "is_a", "human")]:
    graph.add_edge(subject, obj, relation=relation)

# Two-hop query: which detected entities are vehicles?
vehicles = [node for node in graph.successors("bus.jpg") if graph.has_edge(node, "vehicle")]
print(f"Vehicles in bus.jpg: {vehicles}")

Knowledge Graphs and Large Language Models#

LLMs store knowledge implicitly in their weights, which makes their facts hard to inspect or update and prone to hallucination. Knowledge graphs store facts explicitly, with sources that can be cited and edits that take effect immediately. GraphRAG combines the two: it extends retrieval-augmented generation (RAG) by retrieving connected entities and relationship paths, or summaries of graph communities, instead of isolated text chunks, which helps with multi-hop questions such as which suppliers of a delayed part also serve another plant. LLMs also translate natural-language questions into SPARQL or Cypher queries over existing graphs.

Real-World Applications#

• Search and assistants: Entity panels, direct answers, and voice assistants look up facts about people, places, and organizations in large curated graphs.
• Drug discovery: Biomedical graphs link genes, proteins, compounds, diseases, and side effects, and link prediction proposes candidate drug targets or new uses for approved drugs.
• Fraud detection: Accounts that share devices, addresses, or payment cards form connected rings that stand out when traversing the graph, even when each account looks normal alone.
• Scene understanding: Scene graphs describe an image as objects and their relationships, such as (person, riding, horse). The Visual Genome dataset annotates more than 100,000 images this way for training models that answer questions about scenes.

Knowledge Graphs vs. Related Data Stores#

• Relational databases: Store records in tables linked by foreign keys, which suits transactions with a fixed schema. Multi-hop questions such as "friends of friends who bought this product" need one join per hop, while a graph traverses stored edges directly.
• Vector databases: Retrieve items by embedding similarity, which finds related content without explicit links. A knowledge graph records exactly how two entities are related, and hybrid systems use both.
• Ontologies: An ontology is the schema of types and rules, and a knowledge graph is that schema populated with instance facts such as the millions of individual people, places, and works in Wikidata.