What is Knowledge Graph?

The plain definition

A knowledge graph stores facts as triples: subject, predicate, object. Invoice 4021 — was issued by — Supplier A. Supplier A — is owned by — Holding Company B. Entities are nodes, relationships are labelled edges, and the relationships carry as much meaning as the entities.

The advantage over a relational schema is traversal. Answering 'which of our suppliers are ultimately controlled by the same parent' requires following an arbitrary number of ownership links — a query that is awkward and slow in SQL and natural in a graph. Any question of the form 'how is X connected to Y' belongs here.

Where it beats vector search

Embedding similarity finds content that resembles a query. It does not reason over structure. Ask 'which components in this assembly are affected if part 7A fails', and semantic search returns documents that talk about part 7A; a graph returns the actual dependency chain.

This distinction shows up sharply in multi-hop questions, where the answer requires combining facts that never appear together in any single document. Vector retrieval struggles because no chunk contains the answer; a graph composes it from the relationships. Aggregate questions have the same shape — 'how many of our contracts inherit this clause through a parent agreement' is a traversal, not a similarity match.

The trade-off is construction cost. Graphs need entity resolution (three spellings of the same supplier must become one node), a schema for relationship types, and ongoing maintenance. That is real work, and it is why graphs pay off where relationships are the product — supply chains, financial ownership, clinical pathways, permissions, fraud rings — and are overkill where documents are simply documents.

GraphRAG and the practical combination

The interesting current pattern combines both retrieval strategies rather than choosing. Use embeddings to find the entry points — the entities a question is about — then traverse the graph to gather connected context, and supply that structured subgraph to the model. This is broadly what 'GraphRAG' refers to, and it addresses the multi-hop and aggregation weaknesses of plain retrieval-augmented generation directly.

Language models also lowered the cost of building graphs in the first place. Extracting entities and relationships from unstructured documents used to require bespoke NLP pipelines; an LLM with a well-specified schema does a serviceable job, which makes graph construction viable for organisations that would never have attempted it. Verification still matters — extracted triples need review, and entity resolution remains the hard part — but the economics have shifted considerably.

A useful decision rule: if your users ask 'find me information about X', embeddings are enough. If they ask 'how does X relate to Y', or 'what else is affected by X', you need a graph.