Knowledge graph

What is a knowledge graph?

A knowledge graph is a map of things and the labelled links between them. Picture a customer linked to a contract, which links to a product and a country. Each link states its exact meaning, and people define that in advance rather than letting the computer guess.

The part that distinguishes it from any other linked dataset sits above the data. A schema, or ontology, states what kinds of thing exist and which relationships are permitted between them. Without that layer you have a network; with it you have something that can be queried, validated and reasoned over.

Two implementation families dominate and the choice matters less than vendors suggest. Property graphs attach attributes directly to nodes and edges and suit operational querying. RDF and triple stores express everything as subject, predicate, object and suit federation and formal reasoning. Most enterprise work uses the first and most published theory assumes the second, which is a recurring source of confusion when teams read the literature.

When does a Knowledge graph beat vector search?

When the answer requires following a chain rather than finding a passage. That is the whole test, and it is sharper than the usual advice about graphs being good for relationships. If a single document contains the answer, retrieval is cheaper and simpler. If the answer only exists across several hops, a graph earns its cost.

Applying it to real questions makes the decision quick.

The last row is where most real questions land, which is why the argument about graphs replacing vector search was always misplaced. The interesting capability is composing traversal with retrieval and aggregation in a single chain, rather than choosing one. Where the retrieval side of that sits is covered at agentic RAG.

Why do knowledge graph projects fail?

Because the hard part is not building the graph, it is agreeing what goes in it. Defining an entity means deciding whose definition wins, and that decision has budget and headcount attached to it. Teams reach for a technology selection when the actual blocker is an unresolved disagreement.

The pattern repeats closely enough to be worth naming.

• The ontology negotiation stalls. Sales counts an account one way, finance another, legal a third. All three are correct for their purpose. A single graph forces a choice, and nobody in the project has authority to make it.
• Scope expands to justify the cost. Because a graph is expensive to build, the business case grows to cover the whole enterprise, which makes it slower, which makes it later, which makes it harder to defend.
• It is built for an audience that never arrives. Many were built on the assumption analysts would query them directly. Analysts mostly did not, because they had dashboards that answered their questions already.
• Nobody owns it after launch. A graph is a derived artifact, so the moment sources change it drifts. Without a named owner, drift is discovered by whoever is embarrassed first.

What changed with the Knowledge Graph in the last two years?

Building a knowledge graph used to be the expensive step. People had to read through documents and records by hand or write rigid rules that broke whenever the data looked slightly different. Now AI language models do much of that reading and sorting automatically. The harder challenge is still there, which is getting everyone to agree on what each term means, such as what exactly counts as a ‘customer’. Because the building became cheap and the agreeing did not, most of the effort now goes into reaching that shared understanding.

Three consequences follow, and the third is the one worth planning around.

1. 01
   Automatic construction became viableA graph can now be derived from ingested data rather than hand-modelled first. What it changes: the project can start by producing something and then arguing about it, instead of arguing first and producing later.
2. 02
   The consumer changed from a person to an agentThe audience that never arrived for the analyst-facing graph does exist for the agent-facing one, because an agent has no dashboard alternative. What it changes: the business case no longer depends on persuading people to learn a query language.
3. 03
   The bottleneck moved to governanceWhen a graph is generated rather than curated, nobody reviewed what went into it. What it changes: you now need to know which relationships were asserted by a source and which were inferred by a model, because those carry different weight and a generated graph looks identical either way.

That third point deserves care. An automatically constructed graph is a set of claims, and some of them are extractions a model made with imperfect confidence. Recording how each edge got there is the difference between a graph you can defend and one you can only use, and it is far cheaper to capture during construction than to reconstruct afterwards.

What does it cost to keep one?

More than building it, and the build cost is the one that appears in the business case. A knowledge graph is derived from sources that keep changing, so it is stale from the moment it is finished unless something keeps re-deriving it.

Four running costs, roughly in the order they surprise people.

• Re-derivation. Sources change daily. Rebuilding the whole graph is expensive and updating it incrementally requires knowing what changed, which brings you back to whether your connectors report deletions. See enterprise connectors.
• Schema drift. A new product line, a new entity type, an acquisition. Each needs the ontology extended, and each extension is another small negotiation.
• Entity resolution, forever. Deciding that two records are the same customer is not a one-off. New records arrive that match neither cleanly nor cleanly enough to reject.
• Permissions that track the sources. If a record becomes restricted at source, the graph has to know. A graph that ignores this becomes a way to reach data through relationships that access control never anticipated.

That last one is worth stating plainly because it is a security property rather than a maintenance chore. A knowledge graph can leak by inference: no individual edge is sensitive, and the path between them reveals something that was meant to be restricted. Whether permissions travel with the record is covered at agent identity.

What do agents need that analysts did not?

To know whether a fact still holds. An analyst reading a graph brings judgment and can tell that a relationship looks stale. An agent traverses an edge and acts on it, so a graph built for human interpretation is missing the properties that make it safe to act on.

This is where the term stops being sufficient on its own, and it is the honest limit of this page.

A knowledge graph asserts that something is the case. It generally does not record when that became true, how long it holds, which source asserted it, or who may rely on it. Those four properties turn a graph you can read into a graph an agent can act on, and adding them produces something the literature calls a context graph. That page covers the difference properly, including which of the four can be retrofitted to an existing graph and which cannot.

The practical sequence, if you are starting now: build the graph automatically from your sources, record provenance and timing while you construct it because both are unrecoverable later, and resist the urge to model the whole enterprise before producing anything.