AI 101 — What is a knowledge graph?
A knowledge graph is a database that stores facts as things and the relationships between those things — a company, a person, a part, a drug — rather than as rows in a table or chunks of text, so software can follow the connections instead of just matching words.
Google put the idea on the map in May 2012, describing a graph that understood real-world entities and how they relate — the company's framing was "things, not strings" — and said the launch version held more than 500 million objects and 3.5 billion facts about them. That sentence is still the best short definition. A string is the text "Apple". A thing is the company, with a founder, a headquarters, suppliers, lawsuits and a share price hanging off it.
The reason to care in 2026 is that AI agents are now expected to answer questions that live in the connections, not in any single document.
Why it matters right now
Ask a chatbot with a search tool "which of our suppliers depend on a component made in one factory?" and it will find you paragraphs about suppliers. It cannot count them, because counting means walking from supplier to part to factory to part to other supplier — several hops across structured relationships that no paragraph states outright. That is what a graph is for.
The money has noticed. In August, private equity firm Oakley Capital took a majority stake in Graphwise, a knowledge-graph vendor, and the write-up noted Gartner's forecast that 40% of enterprises will have adopted GraphRAG by 2029 (BigDATAwire). GraphRAG — graph plus retrieval — is the pattern that put knowledge graphs back in the AI conversation: Microsoft's April 2024 paper uses a language model to extract an entity graph from a document collection, group closely related entities into communities, and pre-write a summary of each community, so a question can be answered from those summaries rather than from raw text chunks. On corpora around a million tokens, that beat conventional retrieval on both comprehensiveness and diversity of answers, the authors reported.
The mental model: nodes, edges, and a schema
A knowledge graph has three parts, and only the first two are exotic.
Nodes are the things: a person, a company, a machine, a contract. Edges are the relationships, and each edge has a type — works_for, supplies, owns, cites. The basic unit is a triple: subject, relationship, object. Ming works for HKESE. HKESE publishes SiliconNoon. SiliconNoon cites a paper. Each triple is boring; the chain is the product.
The schema — often called an ontology — is the part people skip and then regret. It is the rulebook saying which kinds of things exist and which relationships are allowed between them. Without it you get a pile of edges that technically connects everything and answers nothing.
Querying is the payoff. A vector search asks "what is near this?" and returns text that reads similarly. A graph query asks "what is connected to this, and through what?" and returns an answer you can trace: these three suppliers, via this part, to that plant.
The library analogy
Picture a library. A vector database is the shelf where books on similar subjects sit together — reach for one, and the neighbours are usually relevant. That is genuinely useful, and it is why retrieval-augmented generation works as well as it does; if you want the mechanics, we explained what RAG is.
A knowledge graph is the librarian's cross-reference index. It records that this book cites that paper, that the paper's author now works at that lab, that the lab is owned by that company, that the company is being sued by this one. Nobody could answer "which researchers moved between these two labs in the last five years" by reading shelves, however well sorted. They answer it from the index.
And here is the modern twist: language models are now good enough to build that index automatically, reading documents and proposing the entities and edges. The librarian used to be a team of people with a spreadsheet.
Common misconceptions
"A knowledge graph is just a graph database." A graph database is storage — a way to keep nodes and edges and query them quickly. A knowledge graph is the meaning layer on top: the schema, the entity resolution, the decision that "IBM", "Big Blue" and "International Business Machines" are one node. The database is the filing cabinet; the graph is the filing system.
"LLMs make knowledge graphs obsolete." A model's weights are fuzzy recall: ask twice, get two answers, and you cannot point at the source. A graph is editable, auditable and citable — change a fact once and every answer built on it changes. That is why the two are being paired rather than pitted against each other.
"You need a perfect enterprise-wide ontology first." Neo4j's Jesús Barrasa told SiliconANGLE the practical path is to start with one use case, then align the next one to it — "that's how you build the knowledge layer. You build it incrementally" (SiliconANGLE). The enterprise-wide model is the thing that never ships.
"Vector search already covers this." Embeddings find similar text. They do not join, count, or aggregate — and they cannot tell you that two records describe the same real-world entity. Those are graph jobs.
"GraphRAG is free." Building the graph means running a model over the whole corpus to extract entities and edges, and Microsoft's version also pre-writes summaries. Indexing cost is real, which is why most teams start on the documents that actually get asked about.
Where to learn more
Read the GraphRAG paper for the pipeline, and Google's 2012 Knowledge Graph post for why "things, not strings" was a turning point in search. If you are building, the graph databases — Neo4j, Amazon Neptune, and the graph features now appearing in general-purpose databases — all ship GraphRAG tutorials.
For the layer underneath, see what AI memory is — the short-term and long-term store an agent keeps between turns — and keep in mind that a graph is usually what a serious memory system reaches for once the transcript gets too long to paste.
Has a knowledge graph ever answered a question your documents could not? Write to us via our contact page.
