Skip to main content
Beginner7 min read1 of 5

Graph vs Knowledge Graph vs Context Graph

Three terms that look alike but work very differently — and the gap between them is exactly what separates a connected database from a system that can actually reason.

Graph vs Knowledge Graph vs Context Graph

These three terms show up in the same conversations, often used interchangeably. They are not the same thing.

The difference is not technical complexity — it is what each layer knows about the data it holds.

  • A graph stores connections.
  • A knowledge graph stores connections that mean something.
  • A context graph delivers the connections that matter right now.

Each layer builds on the one before. To make this concrete, we'll use a biomedical example throughout — drugs, diseases, genes, proteins, trials, patients. The same ideas apply to any domain.


Layer 1 — Graph: Just Connections

A graph is the simplest structure: things (nodes) connected by lines (edges).

flowchart LR
  A(("Drug A")) --- B(("Disease B"))
  A --- C(("Protein C"))
  D(("Gene D")) --- B
  D --- A
  E(("Patient E")) --- F(("Trial F"))
  F --- A

Every node looks the same. Every line looks the same. You can see that Drug A connects to Disease B and to Protein C — but you cannot tell:

  • What kind of connection is it? Does the drug treat the disease or cause it?
  • How strong is the connection?
  • What is Drug A? Is it approved? Experimental? What does it do?

A graph shows you the shape of the data. It cannot tell you what any of it means.

[Note] A graph database like Neo4j can store and traverse billions of these connections extremely fast. But speed of traversal is a different problem from meaning. A plain graph is fast — it just does not know what it is talking about.


Layer 2 — Knowledge Graph: Connections That Mean Something

A knowledge graph takes the same nodes and edges and adds a schema — a formal definition of what each node type is, what properties it carries, and what kind of connection is valid between two things.

Every node gets a type. Every edge gets a name. Every property gets a constraint.

flowchart TD
  subgraph KG["Knowledge Graph — same data, now with meaning"]
    direction LR
    DRUG["🧬 Drug\n─────────────\nname: Pembrolizumab\ntype: Monoclonal Antibody\nstatus: Approved\ntarget: PD-1 pathway"]
    DIS["🔴 Disease\n─────────────\nname: Lung Cancer\ncategory: Oncology\ncode: C34"]
    PROT["⚙️ Protein\n─────────────\nname: PD-1\nrole: Immune checkpoint\nid: Q15116"]
    GENE["🧪 Gene\n─────────────\nname: KRAS\ntype: Proto-oncogene\nchromosome: 12p12.1"]

    DRUG -- "TREATS\n[efficacy: 45%]" --> DIS
    DRUG -- "TARGETS\n[binding: high]" --> PROT
    GENE -- "LINKED TO\n[score: 0.87]" --> DIS
  end

Now the graph can answer real questions:

QuestionHow the knowledge graph answers
What does this drug do?Node type Drug, property type: Monoclonal Antibody, edge TARGETS
How confident is the gene–disease link?Edge property score: 0.87
Which drugs are approved and treat this disease?Filter Drug.status = Approved + edge TREATS to Disease
Is this connection a treatment or a side effect?Edge name (TREATS vs CAUSES) makes the distinction

The schema is what makes this possible. Without it, "Drug A — Disease B" is just a line. With it, TREATS [efficacy: 45%] is a fact you can filter, rank, and reason over.

[Definition] The schema that gives a knowledge graph its meaning is called an ontology — a formal definition of what types exist, what properties they have, and what connections are allowed between them. The ontology is what separates a knowledge graph from a database of connected records.


Layer 3 — Context Graph: The Right Slice at the Right Moment

A knowledge graph can hold millions of nodes and hundreds of relationship types. An AI agent or application does not need all of it for every question — it needs the relevant slice assembled for this specific task.

That is the context graph: a dynamic subgraph pulled from the knowledge graph in response to a specific need. Like the highlighted amber paths in the diagram below — out of the full network, only the nodes and connections relevant to this question are activated.

flowchart TD
  FULL[(Full Knowledge Graph\nmillions of nodes\nhundreds of relationship types)]

  FULL -->|"Question: Is this patient\neligible for Trial NCT-4421?"| ASSEMBLE{Assemble\nrelevant slice}

  ASSEMBLE --> N1["Patient\nage: adult\ndiagnosis: Lung Cancer\nconsent: given"]
  ASSEMBLE --> N2["Trial NCT-4421\nphase: III · recruiting\nindication: Lung Cancer"]
  ASSEMBLE --> N3["Drug: Pembrolizumab\nstatus: Approved\nmechanism: PD-1 blockade"]
  ASSEMBLE --> N4["Safety record\n2 serious events on file"]
  ASSEMBLE --> N5["Policy: Phase III enrollment\nrequires: specialist sign-off"]

  N1 & N2 & N3 & N4 & N5 -->|"Context → Retrieval\n→ Reasoning → Action"| AI["🤖 AI Agent\ngenerates eligibility answer\nwith every fact sourced"]

The full knowledge graph never changes. But the context graph is different for every question:

  • An eligibility check assembles: patient + trial + drug safety + enrollment policy
  • A safety review assembles: drug + adverse events + severity ratings + trial phase
  • A supply check assembles: drug batches + manufacturing sites + quality records

Same underlying data. Different context. Different answer.

[Key Insight] The flow from image to insight mirrors the three layers exactly: Context → Retrieval → Reasoning → Actions. The context graph feeds the retrieval. The retrieval feeds the reasoning. The reasoning drives the action. Each step is only as good as what the previous step provided.


All Three Layers, Side by Side

flowchart LR
  subgraph G["① Graph"]
    direction TB
    g1(( )) --- g2(( ))
    g2 --- g3(( ))
    g1 --- g4(( ))
    g3 --- g4(( ))
    g4 --- g5(( ))
  end

  subgraph KG2["② Knowledge Graph"]
    direction TB
    k1["🧬 Drug\nApproved"] -- "TREATS\n45%" --> k2["🔴 Disease\nOncology"]
    k1 -- "TARGETS" --> k3["⚙️ Protein\nCheckpoint"]
    k4["🧪 Gene\nOncogene"] -- "LINKED TO\n0.87" --> k2
  end

  subgraph CG["③ Context Graph"]
    direction TB
    c1["Patient"] --> c2["Trial"]
    c2 --> c3["Drug"]
    c3 --> c4["Safety"]
    c4 -->|"→ AI"| c5{{"🤖"}}
  end

  G -->|"+ schema\n+ types\n+ properties"| KG2
  KG2 -->|"+ task\n+ question\n+ moment"| CG
LayerWhat it addsWhat it knowsWhat it answers
GraphNodes and edgesThat things are connectedWhat connects to what?
Knowledge GraphTypes, properties, named edgesWhat the connections meanWhat kind of connection? How strong?
Context GraphDynamic assembly per taskWhat matters right nowWhat does this AI agent need to act?

Why the Layers Build on Each Other

A context graph without a knowledge graph underneath is just a query result — unstructured, unchecked, not reusable. A knowledge graph without a schema is a plain graph wearing a label. Each layer depends on the one below.

In the biomedical domain, this chain looks like:

flowchart LR
  RAW["Raw data\nspreadsheets, APIs,\nclinical systems\n─────\nDrug names vary:\nPembrolizumab\nKEYTRUDA\nMK-3475"] -->|"Schema applied\nentity types defined\nproperties constrained"| KG3["Knowledge Graph\nOne canonical Drug node\nApproval status, mechanism,\ntyped relationships to\nDisease · Protein · Trial · Patient"]

  KG3 -->|"Question arrives\nrelevant slice assembled"| CTX["Context Graph\nOnly the nodes\nthe AI needs:\nDrug + Trial + Safety + Policy"]

  CTX -->|"Context → Retrieval\n→ Reasoning"| ANS["AI answer\ngrounded · sourced · auditable"]

The raw data has the same drug named three different ways across three systems. The knowledge graph resolves that into one canonical node with consistent properties. The context graph pulls just what an AI needs from that canonical node. The AI answer is grounded because everything traces back to a structured, validated source.


The Biomedical Example — 7 Interconnected Modules

A production biomedical knowledge graph is not one flat schema. It is a set of connected modules, each covering a different part of the domain:

flowchart TD
  F["Foundation\nDrug · Disease · Gene · Protein\nPathway · Anatomy · Biomarker"]
  CL["Clinical\nTrial · Adverse Event · Outcome"]
  PA["Patient\nPatient record · Patient-reported outcomes"]
  MA["Research\nPublications · Researchers · Boards"]
  SQ["Supply & Quality\nManufacturing site · Drug batch · Quality event"]
  GO["Governance\nPolicies · Compliance records"]
  CO["Commercial\nRegulatory submissions · External mappings"]

  F <--> CL
  CL <--> PA
  F <--> MA
  F <--> SQ
  SQ <--> GO
  CO <--> F

A question like "Which approved drugs have had supply issues in the past year and are currently in trials?" touches Foundation, Supply & Quality, and Clinical modules at once. That cross-module traversal is only possible because all three modules share the same schema — the same definition of what a Drug node is, so edges between modules point to the same canonical entities.


Where This Series Goes Next

  1. This article — the three layers and how they build on each other
  2. Why Knowledge Graphs Matter for Production AI — what breaks when AI has data but no structure
  3. Context Graphs and Agentic AI — how AI agents route across multiple databases, chain reasoning steps, and apply business rules
  4. GraphRAG Explained — how graph traversal powers retrieval, from entity extraction through community detection
  5. Ontology and Schema Design — how to design the schema that makes a knowledge graph useful