What Is a Knowledge Graph? How It Works and How to Build One

A knowledge graph is a way of storing facts as a network of entities and the relationships between them. Entities such as companies, people and products become nodes. Relationships such as "founded by" or "located in" become the edges that connect them.

Most knowledge graphs also use a schema, often called an ontology. The ontology defines which entity types and relationships are allowed. This shared structure lets both software and people read the same facts in the same way.

Here is a simple fact written as part of a graph:

• Olostep → has website → olostep.com
• Olostep → offers → Web Data API

The best-known example is Google's. As of May 2020, Google said Google's Knowledge Graph "has amassed over 500 billion facts about five billion entities."

The Building Blocks of a Knowledge Graph

Most knowledge graphs are built from four parts. Entities and relationships form the network, while properties and the ontology add detail and rules.

Entities (Nodes)

An entity is any distinct thing you want to describe, such as a company, a person, a product or a city. In a graph, each entity is a node.

Each node needs a stable ID that does not change. Without one, the same company can show up as two separate nodes, which can break queries that depend on it.

Relationships (Edges)

A relationship is a typed, directed link between two entities. "Olostep offers Web Data API" is an edge that points from a company to a product.

Relationships are stored as data in their own right. In a relational database, you usually rebuild a connection at query time with joins. In a knowledge graph, the connection already exists and has a name.

Properties (Attributes)

A property is a key-value fact attached to a node or an edge. A company node might have name, website and employee_count properties.

Properties are also the right place to record where a fact came from. Storing source_url and retrieved_at on each fact lets you show sources in AI answers and find facts that are out of date.

Ontology (Schema)

An ontology defines the entity types, relationships and rules your graph allows. For example, it might say that a Company can be headquartered_in a City, but a City cannot be founded_by a Product.

How formal your ontology needs to be depends on your use case. You can start with a light schema and add rules as the graph grows. Shared vocabularies such as schema.org give you a ready-made starting point for common types like Organization and Product.

How a Knowledge Graph Stores Facts: Triples and Property Graphs

Knowledge graphs usually store facts in one of two data models: RDF triples or property graphs. Both describe entities and relationships, but they package the details differently.

The W3C RDF 1.1 specification states that "RDF graphs are sets of subject-predicate-object triples, where the elements may be IRIs, blank nodes, or datatyped literals." A triple is one fact with three parts: the subject, the predicate (the relationship) and the object.

Here is the same fact in both models:

# RDF triples (Turtle syntax)
:olostep  :hasWebsite  <https://www.olostep.com> .
:olostep  :offers     :webDataAPI .

// Property graph (Cypher)
CREATE (o:Company {name: "Olostep", website: "https://www.olostep.com"})
CREATE (p:Product {name: "Web Data API"})
CREATE (o)-[:OFFERS {source_url: "https://www.olostep.com"}]->(p)

Notice that the property graph puts source_url directly on the relationship. In plain RDF, adding details about a triple takes extra modeling, though newer RDF work adds support for this.

Knowledge Graph vs Graph Database vs Vector Database

A knowledge graph is a model of facts, while a graph database is one place to store that model. A vector database is a different tool. It stores embeddings, which are lists of numbers that capture meaning, so it can find similar text.

You do not always need a graph database to run a knowledge graph. Smaller graphs can live in Postgres tables for nodes and edges. Many RAG systems pair a knowledge graph with a vector database instead of picking one.

Knowledge Graph Examples You Already Use

You likely use knowledge graphs every day, often without noticing them. Three common types stand out:

• Search engine graphs: Google's Knowledge Graph is the source behind the knowledge panels that Google shows for many people, places and companies.
• Open public graphs: Wikidata's own introduction describes it as a free, collaborative, multilingual knowledge base of structured data. Its stable item IDs help other projects link to the same entities.
• Enterprise knowledge graphs: Companies connect customers, suppliers, products and contracts in one graph. This helps with tasks such as supply chain mapping and fraud detection.

Knowledge Graphs for AI, RAG and GraphRAG

Knowledge graphs help AI systems answer questions that need several connected facts. Standard RAG (retrieval-augmented generation) finds text chunks similar to a question and passes them to an LLM. GraphRAG adds a graph so the system can follow relationships across many documents.

The evidence for GraphRAG is promising but mixed. Microsoft Research's GraphRAG results reported in July 2024 that "GraphRAG, when using community summaries at any level of the community hierarchy, outperforms naive RAG on comprehensiveness and diversity (~70–80% win rate)." Those win rates were judged by an LLM on broad, summary-style questions.

Independent studies add important limits. One RAG vs. GraphRAG evaluation found that "RAG performs better on single-hop questions and those requiring fine-grained details, whereas GraphRAG is more effective for multi-hop and reasoning-intensive questions." An unbiased GraphRAG evaluation also reported: "We apply our unbiased framework to evaluate 3 representative GraphRAG methods and find that their performance gains are much more moderate than reported previously."

Graphs also add build and upkeep costs, so treat GraphRAG as a choice for specific question types, not a default. Many teams combine both approaches through agentic RAG retrieval agents that choose a retriever for each question.

How to Build a Knowledge Graph From Web Data

A knowledge graph can only be as accurate and current as the data you feed it. The steps below cover the full path from web page to queryable graph.

Step 1: Find and Collect Sources

Start by choosing authoritative sources for each entity type, such as company websites, product pages and official registries. Then collect the pages at the scale your graph needs.

Olostep lets you crawl entire websites to gather source pages and returns clean content for each one. For the first large load, you can batch-process thousands of URLs in one job instead of writing your own queue and retry logic.

Step 2: Extract Entities and Relationships Into JSON

Next, turn each page into structured JSON that matches your schema. With schema-based extraction, you define the output you want, such as field names and types, instead of writing selectors for each site.

Nested JSON already looks like a small graph. A company object with a list of products holds two entity types and the relationship between them:

{
  "company": {
    "name": "Example Corp",
    "website": "https://example.com",
    "headquarters": "Berlin",
    "products": [
      { "name": "Example Analytics", "category": "Software" }
    ]
  },
  "source_url": "https://example.com/about",
  "retrieved_at": "2026-10-15T09:00:00Z"
}

Your extraction method affects how repeatable the results are. Read about parsers versus LLM extraction to decide between fixed parsers for known page layouts and LLM extraction for varied ones.

Step 3: Resolve Duplicate Entities

Entity resolution means merging records that describe the same real-world thing. If "Acme" and "ACME Holdings Inc." stay separate, relationships get split between two nodes and queries return partial answers.

First, normalize web data such as names, domains and country codes so that records can be compared. Then match records on strong identifiers like official websites or public IDs. Olostep's knowledge graph search API returns entity types, aliases, identifiers and source URLs in JSON, which gives you reference data to match against.

Step 4: Load Triples Into a Graph Store

Now convert each JSON record into nodes and edges. This short Python example turns the extraction output above into triples while keeping the source details:

def to_triples(record):
    c = record["company"]
    meta = {"source_url": record["source_url"],
            "retrieved_at": record["retrieved_at"]}
    triples = [
        (c["name"], "has_website", c["website"], meta),
        (c["name"], "headquartered_in", c["headquarters"], meta),
    ]
    for p in c.get("products", []):
        triples.append((c["name"], "offers", p["name"], meta))
    return triples

Load the triples into whichever store fits your stack, such as Neo4j, an RDF triple store or Postgres. Keep the source details with each fact so you can trace and update it later.

Step 5: Keep the Graph Fresh

Facts change: companies hire new CEOs, move headquarters and launch products. Without updates, a graph can keep giving confident answers that are no longer true.

Set up jobs to monitor source pages for changes, then re-extract only the pages that changed. Update retrieved_at on refreshed facts. If history matters, keep old values with valid-from and valid-to dates instead of overwriting them.

Common Knowledge Graph Challenges

Many knowledge graph problems are data problems, not database problems. These are common issues teams run into:

• Extraction quality: Automated extraction can produce wrong or inconsistent facts, especially without a fixed schema.
• Duplicate entities: Name variants split one real-world entity across several nodes.
• Stale facts: Source pages change, but the graph does not update unless you re-collect them.
• Schema drift: New entity types and relationships appear faster than the ontology is updated.
• Cost: Building and refreshing a graph, especially with LLM extraction, adds extraction and maintenance work on top of text indexing.

A knowledge graph is often the wrong choice when most questions are single-fact lookups. In that case, well-tuned vector search is usually the simpler option.

Frequently Asked Questions About Knowledge Graphs

What is a knowledge graph in simple terms?
A knowledge graph is a map of facts where things are dots and their relationships are the lines that connect them.

What is an example of a knowledge graph?
Google's Knowledge Graph, the source behind Google's knowledge panels, and Wikidata, a free and collaborative public knowledge base, are two well-known examples.

What is the difference between a knowledge graph and an ontology?
An ontology is the set of rules and types, while the knowledge graph is the actual collection of facts that follows those rules.

What is the difference between a knowledge graph and a knowledge base?
A knowledge base is any store of facts, and a knowledge graph is a knowledge base that organizes those facts as connected entities and relationships.

Do you need a graph database to build a knowledge graph?
No. Small and medium graphs can run on relational databases like Postgres, though graph databases make deep relationship queries easier.

Can LLMs build knowledge graphs automatically?
LLMs can extract entities and relationships from text, but the results usually need a fixed schema and duplicate merging to stay consistent.

How do you keep a knowledge graph up to date?
Track the source URL and retrieval time for each fact, watch sources for changes, and re-extract only the pages that changed.

Is GraphRAG better than regular RAG?
It depends on the question: GraphRAG tends to help with multi-hop and broad summary questions, while regular RAG often does better on simple fact lookups.