Knowledge Graph Construction
A graph of your entities and the relationships between them, built to answer specific questions your current systems cannot, with every fact carrying its source and a resolution process that survives duplicates.
Knowledge graph projects fail in a characteristic way: an elegant ontology is designed, entities are loaded, everyone admires the visualisation, and nobody can name a decision that changed. The discipline that prevents it is refusing to model anything until a specific unanswerable question demands it.
A knowledge graph represents entities and the relationships between them in a queryable structure, assembled from databases, documents and text. It suits questions that require traversing several connections, where a relational query would need many joins and a document search would return the pieces without the link between them.
Start from questions, not from an ontology
We begin by collecting the questions people currently cannot answer, and testing each one against a simple criterion: does answering it require following relationships across sources?
- Good graph questions. Which suppliers do we depend on indirectly through our tier-one suppliers? Which of our customers are connected to this sanctioned entity? Which products contain a component affected by this recall? Who else worked on the projects this expert worked on?
- Poor graph questions. How many orders were placed last month? What is our stock level? Anything a single table or a well-indexed search already answers.
The ontology is then derived from those questions rather than designed in advance. It ends up smaller, uglier and considerably more useful than the comprehensive model, and it can grow as new questions arrive.
The graph is a means, not the deliverable
Nobody outside the project will use a graph explorer. The deliverable is the answers, delivered into an application, a report or an assistant that people already use. We build the query layer and the interface as part of the engagement, because a graph without one is an expensive dataset.
The engineering that decides whether it works
Entity resolution is most of the work
The same company appears as five spellings across four systems. The same person is in the CRM twice and in the HR system once. Resolving these is the majority of the effort and the difference between a graph that answers questions and one that answers them wrongly. We build it with confidence scores, a review path for ambiguous matches, and a record of every merge so it can be undone.
Extract relationships from text as well as tables
Structured systems give you the obvious relationships. The interesting ones are frequently in contracts, reports, filings and correspondence, extracted with the entity and relation techniques described under text classification and entity extraction. Every extracted fact carries a confidence score and the sentence it came from.
Provenance on every fact
Where it came from, when, by what method, and with what confidence. This is what allows a surprising answer to be investigated rather than doubted, and it is what makes a graph usable in a regulated context. Facts without provenance are rumours in a database.
Handle time explicitly
Relationships start and end. A supplier relationship that concluded two years ago should not answer a question about current exposure. Temporal validity on edges is unglamorous and it is what separates a graph that ages well from one that quietly becomes wrong.
Measure quality rather than size
Node and edge counts measure nothing. We measure entity resolution precision and recall on a reviewed sample, relationship extraction accuracy, coverage of the questions the graph was built for, and staleness of facts by source.
Keep it current
Incremental updates from source systems, re-extraction when documents change, and a defined process for retiring facts. A graph built once and never refreshed is a snapshot that becomes misleading at a rate nobody notices.
Where graphs earn their cost
| Domain | The question | Why a graph |
|---|---|---|
| Supply chain risk | Indirect exposure through tiers | Requires traversing several supplier hops |
| Financial crime | Connections between parties and accounts | Rings are visible only as structure |
| Product and parts | What contains this component | Deep bills of material with substitutions |
| Expertise and staffing | Who has worked on what, with whom | People, projects and skills interlinked |
| Regulatory obligation | Which rules apply to which products where | Many-to-many across jurisdictions |
| Research and IP | Prior art and citation networks | Relationship structure is the answer |
Graphs also make retrieval-augmented systems substantially better where questions require multiple hops, which is the pattern described under agentic RAG.
How the engagement runs
Questions first, ontology second, and entity resolution measured before anything is trusted.
Question inventory and scope
Unanswerable questions collected and tested for graph-shape, the minimum ontology derived from them and agreed.
Ingestion and entity resolution
Sources connected, entities resolved with confidence scores, ambiguous matches routed for review, merges recorded.
Relationship extraction
Relationships extracted from structured sources and from text, each with provenance, confidence and temporal validity.
Query layer and delivery
The questions answered through an application, report or assistant that people already use, not a graph explorer.
Quality, refresh and handover
Resolution and extraction accuracy measured, incremental refresh built, ontology extension guide handed over.
What you receive
Answers to the questions you started with, and a graph that stays true as sources change.
Question-derived ontology
The minimum model required by the agreed questions, with the extension process documented.
Entity resolution
Matching with confidence scores, review path for ambiguity, and a reversible record of every merge.
Populated graph
Entities and relationships with provenance, confidence and temporal validity on every fact.
Query and delivery layer
The questions answered inside an application or report people already use.
Quality measurement
Resolution precision and recall, extraction accuracy and question coverage on a reviewed sample.
Refresh pipeline
Incremental updates, re-extraction on change and fact retirement, with staleness reporting.
Is this the right engagement?
Worth being direct. Knowledge Graph Construction is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- There are specific questions that require following relationships across sources.
- Entities appear in several systems with inconsistent identifiers.
- Important relationships are described in documents rather than stored in tables.
- Someone will act on the answers once they exist.
- A domain expert can adjudicate ambiguous entity matches.
Choose something else if
- The questions are answerable with a database query or good search.
- Nobody can name a decision that would change with the answers.
- Source data quality is so poor that entity resolution is hopeless.
- The goal is an ontology exercise rather than an operational answer.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
When is a knowledge graph the right tool?
When answering a question requires following relationships across several hops and several sources, where a relational query would need many joins and search would return the pieces without the connections. If a database query or good search answers it, use those instead and we will say so.
What is entity resolution and why does it dominate the effort?
It is deciding that five spellings of a company name across four systems are the same organisation. It is most of the work in any real graph, and getting it wrong produces confidently wrong answers. We build it with confidence scores, a review path and a reversible record of every merge.
Do we need a graph database?
Often, though not always: some graph workloads run acceptably in a relational database, particularly where the traversals are shallow. The choice follows from the query patterns your questions require, and it is less consequential than entity resolution quality.
How do you keep a knowledge graph current?
Incremental updates from source systems, re-extraction when documents change, temporal validity on relationships so ended ones stop answering current questions, and staleness reporting by source. A graph built once and never refreshed becomes misleading at a rate nobody notices.
How does a graph relate to retrieval-augmented generation?
It complements it. Retrieval finds relevant passages; a graph answers questions about structure and connection that passages cannot. Combining them is what makes multi-hop questions answerable, which is the pattern described under agentic RAG.
Often paired with this
Most clients combine two or three engagements from the Natural Language Processing pillar. These are the ones that most often run immediately before or after.
Semantic and Vector Search
Search that finds the right thing, measured on your real queries with hybrid retrieval and reranking.
Read more →Text Classification and Entity Extraction
Labels and entities extracted from text at volume, with a scheme your experts agree on and per-class accuracy.
Read more →Contract and Legal Document Analysis
Clause extraction, deviation flagging and obligation tracking, cited back to the page for fast verification.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.