What is a knowledge graph?
Erwin Berkouwer
A knowledge graph is a network structure of entities (nodes) and relationships (edges) that links facts together, unlike flat tables in a regular database. Google has used this in search results since 2012, and businesses increasingly use it to make AI assistants more reliable when answering questions about linked company data (customers, products, processes). For small, unstructured datasets, a regular database is often still sufficient.
A knowledge graph is a network of facts and the relationships between them, letting computers and AI systems connect information instead of storing isolated data points.
A knowledge graph is a way of storing information as a network of facts and the relationships between them, rather than as separate rows in a table. Each fact becomes an 'entity' (a customer, a product, a location), and the connections between them ("buys", "works for", "belongs to") describe how those facts relate. Search engines like Google have used this for years to enrich search results, and AI systems increasingly rely on the same idea to reason more reliably about business information.
A knowledge graph doesn't just answer "what is this", it also answers "how does this connect to everything else".
How it works
A knowledge graph is built from two basic parts: nodes and edges. A node is an entity, such as a customer, a product, an employee, or an invoice. An edge describes the relationship between two nodes, such as "customer X ordered product Y" or "employee A is responsible for process B".
The difference from a regular database lies in the structure. A traditional database (tables with rows and columns) is good at storing individual facts, but less good at combining many different kinds of relationships at once. Figuring out how three tables relate to each other usually means writing multiple joins, and that gets complicated fast as the number of relationships grows.
A knowledge graph, by contrast, is built around those relationships. Questions like "which customers bought a product that was later recalled, and who last spoke with that customer" are far more natural to answer in a graph structure, because the relationships are stored explicitly instead of being buried inside separate tables.
Triples: the building block
The smallest unit in a knowledge graph is often a 'triple': subject, predicate, object. For example: "Company X (subject) supplies (predicate) Product Y (object)". Combine thousands of these triples and you get a network you can navigate from one fact to the next.
Why it matters for SMEs
For most small and medium businesses, a knowledge graph is not a goal in itself, it's a way to make AI tools more reliable. If you deploy an AI assistant that answers questions about customers, products, or internal processes, the quality of its answers depends heavily on how well that underlying information is structured.
Without a clear structure, an AI model has to guess how pieces of information relate, and that guessing is exactly where hallucinations (made-up or incorrect answers) come from. A knowledge graph captures those relationships explicitly, so an AI system can navigate along facts instead of guessing.
Concretely, for an SME this means:
- Product data, customer records, and order history get linked together instead of sitting in separate, disconnected systems
- An internal AI assistant can answer questions that span multiple systems (for example CRM plus inventory plus invoicing)
- New employees or AI tools can find the right context faster, without someone having to explain everything by hand
A concrete example
The best-known example is the Google Knowledge Graph, introduced in 2012. When you search Google for a business, an info box often appears on the right with opening hours, address, and reviews. That information doesn't come from a single webpage, it comes from a network of linked facts about that entity (the business, the location, the owner, related businesses).
A more realistic example for an SME is an internal AI assistant that answers questions like "which customers filed a complaint about product Z last month, and which supplier delivers that product". Without a structured link between customers, complaints, products, and suppliers, the AI has to "invent" these connections from loose documents, with a real risk of errors. With a knowledge graph as the underlying structure (often combined with RAG techniques), the answer can be traced directly back to the correct facts.
When to use it, when not
A knowledge graph isn't necessary for every business. For many SME use cases, a well-organized database, or even a tidy spreadsheet, is more than enough.
| Situation | Knowledge graph | Database/spreadsheet |
|---|---|---|
| Simple, isolated data (e.g. one customer list) | Overkill | Sufficient |
| Many different kinds of relationships between data (customers, products, processes, suppliers) | Valuable | Becomes unwieldy fast |
| AI assistant needs to answer questions spanning multiple linked topics | Strongly recommended | Limited usefulness |
| Small, static dataset that rarely changes | Not needed | Fine as-is |
| Growing number of data sources that need to "talk" to each other | A logical next step | Hard to maintain |
The rule of thumb: the more different kinds of relationships matter to the questions you want answered, the sooner a graph structure adds value.
Related concepts
A few terms tend to appear alongside knowledge graphs:
- Semantic search: searching by meaning and context instead of exact keywords
- RAG (Retrieval-Augmented Generation): an AI model that first retrieves relevant facts (for example from a knowledge graph) before generating an answer
- Ontology: a defined structure describing which types of entities and relationships exist within a domain
- Entities: the "things" (people, products, organizations) stored as nodes in the graph
- Structured data / schema markup: structured information on webpages that helps search engines and AI systems recognize entities
Together, these concepts form the foundation that lets AI systems combine facts instead of interpreting loose data in isolation.
If you want to know whether a knowledge graph is worthwhile for your situation, start by mapping out what data you have and how (or whether) it's currently connected. At AI consultancy, we look together at how to make existing data usable for reliable AI applications, and whether a lightweight graph structure should be part of that. Want to see where your business stands first? Take the free AI scan for a concrete picture of opportunities and risks.
Ultimately, it's not about the technology itself, it's about preventing AI answers that are factually wrong because the underlying data was never properly connected.
Veelgestelde vragen
Korte, heldere antwoorden die je helpen sneller beslissen.
What is the difference between a knowledge graph and a database?
A regular database stores data in tables of rows and columns, where relationships between tables are implicit and require joins. A knowledge graph stores relationships explicitly as edges between entities (nodes), making complex, highly interconnected questions much easier to answer.
Does a small SME need a knowledge graph?
Not always. For simple, isolated data, a spreadsheet or standard database is often enough. A knowledge graph becomes valuable once you need AI tools to answer questions that combine multiple linked data sources, such as customers, products, and complaints together.
What is the best-known example of a knowledge graph?
The Google Knowledge Graph, introduced in 2012, is the best-known example. It powers the info boxes shown next to search results with facts about businesses, people, or places, built from linked entities rather than individual webpages.
How does a knowledge graph reduce AI hallucinations?
An AI model with access to a well-structured knowledge graph can trace its answers back to explicitly stored facts and relationships, instead of guessing how disconnected data points relate. This lowers the risk of made-up or incorrect answers.
