The problem with the usual explanations
When you mention a Knowledge Graph to a CIO or an R&D director, the conversation typically lasts about four minutes before getting lost in terms like "ontology", "RDF triple" or "semantic inference".
That's not their fault. No one starts from real-world usage. So let's do it differently.
Let's start with what you already know
Imagine you're searching your organisation's archives for the answer to this question:
"Which regulatory waivers were granted for this type of component, by which authority, under what conditions?"
You have two options.
Option A — Traditional document search. You type keywords into your document management system or SharePoint. You get a list of documents. You open each one. You read. You look for the waiver. You check whether it applies to your component. You take notes. You start again. Result: three days of work for an experienced engineer — and even then, if the 2012 documents used a different term from those of 2019, some waivers will slip through the net.
Option B — A traditional database. You have a "waivers" table with columns. You run an SQL query. Done in two seconds. The problem: your archives are not in a structured database. They're in PDFs, Word documents, emails, reports. And no one has re-entered them into a table.
The knowledge graph is the third option — the one that didn't really exist before.
What a knowledge graph is
A knowledge graph reads your documents and extracts entities (a component, an authority, a waiver, a condition) and relationships between those entities. What it builds looks like this:
[Waiver W-142] —granted by→ [DGAC] [Waiver W-142] —applies to→ [Component C-SW-38B] [Waiver W-142] —condition→ [Annual audit required] [Waiver W-142] —date→ [14 March 2017] [Waiver W-142] —reference→ [Document REF-2017-0892, section 4.3]
When you ask your question in plain language, the system translates it into a traversal of this graph. It follows the relationships. It finds the answers. It cites its sources — not "according to available documents", but "per document REF-2017-0892, section 4.3, validated on 14 March 2017 by the DGAC".
How this differs from an LLM (ChatGPT, Copilot, etc.)
An LLM (language model) has been trained to produce plausible text from billions of documents. When you ask it a question, it generates a response that resembles what a knowledgeable person might say on the subject. The problem: it "fills in the gaps". On specialist regulatory corpora, this completion is frequently incorrect — and it looks correct. That is what is known as a hallucination.
A knowledge graph doesn't "fill in" anything. It traverses relationships that have been explicitly established. If the relationship does not exist in the graph, it returns "no result found" — not "here is my best estimate".
| General-purpose LLM | Knowledge Graph | |
|---|---|---|
| Source of the answer | Training statistics | Explicit relationships in the data |
| Traceability | "According to available sources…" | Source document + section + date |
| Possible error | Yes, often undetectable | No — absent result if unknown |
| Consistency | Varies between sessions | Identical on every query |
| GxP / ITAR compliance | Structurally incompatible | Compatible by design |
What the graph does not do
It does not generate text. It does not write reports. It does not summarise. It responds to structured queries and cites its sources. For text generation, an LLM may be used downstream — but as the writer of a result already validated by the graph, not as the source of the answer.
It does not replace the expert. It frees the expert from documentary research work so they can do what they were trained to do: analyse, decide, argue.
It does not work on just any corpus. Building a knowledge graph requires modelling (what constitutes an entity? which relationships matter?) and ingestion work. It is not plug and play. It is an infrastructure project.
What this changes in practice
Here are three typical questions in regulated industrial environments, and what each approach produces.
Question 1: "Which active fungicide substances have had a restriction on vines updated since 1 January 2022?"
- RAG on the same corpus: 3 minutes, 2 errors out of 7 results (confusion between closely related substances)
- Graph: 4 seconds, 0 errors, ANSES source paragraphed for each result
Question 2: "Which class signals of severe hepatotoxicity on our molecule since 2020, cross-referenced with EMA publications on the same therapeutic class?"
- RAG: partial result, 3 signals missing (adjacent terms in PSURs across 2 languages), no primary source
- Graph: 7 seconds, 0 signals missing, PSUR reference + section + validation date for each result
Question 3: "All precedents of stress corrosion on category 1 pipework since 2015, by unit, with the intervention carried out and the 6-month outcome?"
- Traditional document search: estimated 3 weeks of work
- Graph: 9 seconds, 14 precedents with documentary reference, unit, date, intervention and status
The question to ask yourself
If your organisation regularly spends several weeks retrieving information that has already been produced — and that information carries regulatory compliance, safety, or legal liability — then the question is not "can a knowledge graph help us?"
The question is: "how much is it costing us not to have one?"