What is a Knowledge Graph? Guide

TL;DR

• A knowledge graph represents facts as entities connected by relationships - not rows in tables, but a network of things and how they relate.

• The basic unit is a triple: subject → predicate → object. "Alice → worksAt → Acme Corp" is one fact.

• Knowledge graphs answer path questions - "Who supplies components used in products we sell to Customer X?" - that require traversing connections across systems.

• They complement databases and vector search - graphs store structure; RAG retrieves text; relational DBs handle transactions.

• You don't need a graph database on day one - understanding the model helps whether you build in Neo4j, RDF, or even PostgreSQL with adjacency tables.

Why This Matters

Your company stores "Customer" in Salesforce, "Subscription" in Stripe, "Support Ticket" in Zendesk, and "Product" in an internal catalog. Each system defines entities differently. Answering "Which enterprise customers who filed P1 tickets this month use a product with a known CVE?" requires joining four systems with brittle ID mappings.

A knowledge graph unifies these as connected entities. Customer:acme links to Subscription:sub_123, which links to Product:widget-pro, which links to CVE:2024-1234. The question becomes a path traversal, not a one-off SQL script that breaks when schemas change.

Engineers encounter knowledge graphs in Google Search (knowledge panels), fraud detection (transaction networks), recommendation systems (user-item graphs), and GraphRAG for multi-hop AI retrieval. Understanding the concept - before choosing Neo4j vs RDF vs a JSON adjacency list - prevents expensive wrong turns.

The Problem Knowledge Graphs Solve

Data lives in silos with incompatible schemas. CRM "Account," billing "Customer," and support "Requester" refer to the same real-world entity but have different IDs, fields, and update cadences. Knowledge graphs introduce a canonical identity layer with sameAs links to source records.

Relationship queries are awkward in relational databases. "Find all paths between User A and Document D within 4 hops" in SQL requires recursive CTEs that degrade on large datasets. Graphs index adjacency - each hop is a direct edge lookup.

AI systems lose structural context. Vector search retrieves similar text but not structured relationships. "Which suppliers of Component X also supply our competitors?" needs entity linking and graph traversal, not cosine similarity alone.

Knowledge graphs do not replace transactional databases. They provide a read-optimized semantic layer for connected data.

What Is a Knowledge Graph?

A knowledge graph is a directed, labeled graph where:

• Nodes (entities) represent things: people, products, documents, concepts, organizations.

• Edges (relationships) represent typed connections between entities: worksAt, supplies, mentions, dependsOn.

• Properties attach attributes to nodes and edges: name, date, confidence score, source system.

The name "knowledge graph" implies more than a generic graph data structure. Production knowledge graphs typically include:

1. A schema or ontology - allowed entity types and relationship types (Ontologies).

2. Identity resolution - canonical IDs linking records across source systems.

3. Provenance - where each fact came from and when it was last verified.

A Simple Example

Natural language facts:

Alice works at Acme Corp. Acme Corp is headquartered in San Francisco. Acme Corp supplies Widget Pro to Beta Inc.

As triples:

(Alice, worksAt, AcmeCorp)
(AcmeCorp, headquarteredIn, SanFrancisco)
(AcmeCorp, supplies, WidgetPro)
(AcmeCorp, sellsTo, BetaInc)

GraphRAG builds a knowledge graph from source documents, clusters entities into communities, and retrieves graph-aware context for complex multi-hop questions.

Query: "Where is Alice's employer located?" → traverse worksAt → headquarteredIn → San Francisco.

Engineering Insight

The power is in traversal, not storage. The same four facts in four SQL tables require JOINs with explicit foreign keys. In a graph, the query follows the shape of the question.

Knowledge Graph vs Other Data Models

How Knowledge Graphs Work

Building Blocks: Triples

The atomic unit is a triple: (subject, predicate, object).

Predicates have direction and type. supplies is different from suppliedBy (inverse). Schemas define which predicates connect which entity types.

Entity Resolution

The same real-world entity appears under different IDs:

(CRM:account_4521, sameAs, Customer:acme-corp)
(Billing:sub_789, belongsTo, Customer:acme-corp)
(Support:user_jane@acme.com, worksFor, Customer:acme-corp)

Entity resolution merges or links these into one canonical node so queries traverse across systems.

Querying: Pattern Matching

Graph queries describe patterns to match:

// Cypher (property graph style)
MATCH (p:Person)-[:worksAt]->(o:Org)-[:supplies]->(prod:Product)
WHERE p.name = "Alice"
RETURN prod.name

# SPARQL (RDF style)
SELECT ?product WHERE {
  ?person :name "Alice" .
  ?person :worksAt ?org .
  ?org :supplies ?product .
}

Both ask: find products supplied by the organization where Alice works. The query shape mirrors the question shape.

The indexing phase extracts entities and relationships, constructs community summaries, and stores graph structures for later retrieval.

Architecture

A typical knowledge graph system has four layers:

The retriever scores document chunks against the query embedding and returns the top-k passages that ground the generator.

Best Practice

Start with a bounded domain - "products and suppliers" or "services and dependencies" - not "the entire company knowledge." Scope controls complexity.

Real Production Example

A SaaS company builds a lightweight knowledge graph for internal search. Documents mention products, customers, and features. An NLP pipeline extracts entities and links them:

from dataclasses import dataclass, field

@dataclass
class Entity:
    id: str
    type: str
    name: str
    properties: dict = field(default_factory=dict)

@dataclass
class Triple:
    subject: str
    predicate: str
    object: str
    source: str
    confidence: float = 1.0

class SimpleKnowledgeGraph:
    def __init__(self):
        self.entities: dict[str, Entity] = {}
        self.triples: list[Triple] = []

    def add_entity(self, entity: Entity):
        self.entities[entity.id] = entity

    def add_triple(self, triple: Triple):
        self.triples.append(triple)

    def neighbors(self, entity_id: str, predicate: str = None) -> list[tuple]:
        results = []
        for t in self.triples:
            if t.subject == entity_id and (predicate is None or t.predicate == predicate):
                results.append((t.predicate, t.object))
        return results

    def find_path_products_for_customer(self, customer_id: str) -> list[str]:
        """Customer -[purchased]-> Product -[hasFeature]-> Feature"""
        products = []
        for pred, obj in self.neighbors(customer_id, "purchased"):
            if pred == "purchased":
                products.append(obj)
        return products

# Ingest from a support doc
kg = SimpleKnowledgeGraph()
kg.add_entity(Entity("customer:acme", "Customer", "Acme Corp"))
kg.add_entity(Entity("product:widget", "Product", "Widget Pro"))
kg.add_entity(Entity("doc:ticket-4521", "Document", "Ticket #4521"))

kg.add_triple(Triple("doc:ticket-4521", "mentions", "customer:acme", "zendesk"))
kg.add_triple(Triple("doc:ticket-4521", "mentions", "product:widget", "zendesk"))
kg.add_triple(Triple("customer:acme", "purchased", "product:widget", "billing"))

# Query: which products are mentioned in docs about Acme?
acme_docs = [t for t in kg.triples if t.object == "customer:acme" and t.predicate == "mentions"]

This in-memory graph is a prototype. Production moves to Neo4j or Neptune with indexed traversal, but the model - entities, triples, paths - is identical.

Decision Matrix

⚠ Common Mistakes

1. Modeling everything as a graph. Not all data is relational. Time-series metrics, event logs, and transactional records belong elsewhere.

2. Skipping entity resolution. Duplicate nodes (Acme, ACME Corp, acme-corp) fragment the graph and break traversal.

3. No ontology/schema. Without typed relationships, the graph becomes a junk drawer of untyped edges nobody can query reliably.

4. Ignoring provenance. Facts without source and timestamp cannot be audited or deprecated when sources change.

5. Confusing knowledge graph with GraphRAG. The graph is data infrastructure. GraphRAG is a retrieval pattern that uses it. Build the graph first.

Common Mistake

Building a knowledge graph before understanding what questions you need to answer. Start with five real queries your users ask, then model entities and edges to answer them.

Where It Breaks Down

• Unstructured data quality - NLP entity extraction mislabels entities. Confidence scores and human review loops are mandatory.

• Schema evolution - Adding new relationship types can invalidate existing queries. Version your ontology.

• Scale of traversal - Unbounded multi-hop queries explode combinatorially. Set hop limits and use indexed predicates.

• Write-heavy workloads - Graph databases optimize reads.

High-frequency transactional updates belong in OLTP stores; sync to the graph via CDC.

• ROI justification - Building an enterprise KG is expensive. Prove value on a narrow domain before company-wide rollout.

Running Knowledge Graphs in Production

Decision Trade-off

RDF standards maximize interoperability but add complexity. Property graphs are developer-friendly but less portable. Pick based on team skills and integration requirements, not hype.

Ecosystem

Related Technologies

• Knowledge Graphs: Deep dive into production modeling, RDF vs property graphs, and deployment patterns.

• Ontologies: Schema definitions that govern entity types and allowed relationships.

• RDF: W3C standard for representing graph data as triples.

• Property Graphs: Neo4j-style labeled nodes and edges with native properties.

• Graph Databases: Storage engines optimized for graph traversal.

• GraphRAG: Using knowledge graphs to enhance RAG for multi-hop questions.

Learning Path

Prerequisites: Large Language Models

Next topics: Knowledge Graphs · Ontologies · Graph Databases

Estimated time: 35 min · Difficulty: Beginner

FAQs

Is a knowledge graph the same as a graph database?

No. A knowledge graph is a data model - entities and relationships with semantic meaning. A graph database is storage technology that can hold a knowledge graph (among other graph structures).

Do I need Neo4j to have a knowledge graph?

No. You can model triples in PostgreSQL, RDF files, or even Python dictionaries for prototypes. Graph databases add indexed traversal at scale.

What's the difference between a knowledge graph and an ontology?

An ontology defines the schema - what entity types and relationships are allowed. A knowledge graph is the populated instance with actual data conforming (mostly) to that schema.

How is this different from a data warehouse?

Warehouses aggregate facts for analytics (OLAP). Knowledge graphs preserve individual entity relationships for traversal and linking. They complement each other - ETL from warehouse to graph is common.

Can LLMs build knowledge graphs automatically?

Partially. LLMs extract entities and relationships from text with useful accuracy, but require validation, entity resolution, and provenance tracking. Use LLMs as extraction assist, not autonomous KG builders.

When should I use a knowledge graph vs RAG?

Use RAG for document Q&A ("What does our refund policy say?"). Use knowledge graphs when questions require traversing relationships ("Which products share suppliers with discontinued Item X?"). Many production systems use both.

What is entity resolution?

The process of determining that CRM:4521, billing@acme.com, and Acme Corp refer to the same real-world entity, and linking them to one canonical ID.

How big should my first knowledge graph be?

Start with one domain and 10K–100K triples. Prove you can answer five critical business questions before expanding scope.

What's the difference between RDF and property graphs?

RDF uses subject-predicate-object triples with W3C standards (SPARQL). Property graphs use labeled nodes and edges with properties on both. See Knowledge Graphs for a full comparison.

References

• From Local to Global: A Graph RAG Approach (Microsoft, 2024)
• Microsoft GraphRAG Documentation
• Neo4j LLM Knowledge Graph Builder

Further Reading

• LangChain GraphRAG Integration
• Apache Jena Documentation
• OpenAI Structured Outputs

Summary

• A knowledge graph models data as entities connected by typed relationships - optimized for path queries. - Triples (subject, predicate, object) are the atomic unit of facts. - Knowledge graphs solve silo, traversal, and AI context problems - not transactional workloads. - Entity resolution and provenance are as important as the graph structure itself. - Start with a bounded domain and real user questions before enterprise-wide rollout.

• Graphs complement RAG and relational databases - they don't replace them.

Production Checklist

• Defined scope - which domain and which questions the graph must answer
• Ontology/schema with entity types and allowed relationship types
• Canonical entity IDs with sameAs links to source systems
• Provenance on every triple (source, timestamp, confidence)
• Entity resolution pipeline with duplicate detection metrics
• Ingestion from authoritative sources (CDC or scheduled ETL)
• Query API (Cypher, SPARQL, or REST) with hop limits
• Access control at entity or edge level for sensitive data
• Monitoring: orphan rate, ingestion lag, query p95 latency
• Evaluation set of path queries with expected results