What is a knowledge graph?
A knowledge graph is a data structure that stores entities (customers, orders, products, policies) as nodes and the named relationships between them as edges, so a system can traverse from one fact to a connected fact instead of retrieving isolated records. Each fact is typically written as a triple: subject, relationship, object.
A single support question often depends on four or five linked facts at once: who the customer is, which plan they hold, which order failed, which policy governs that order, and which regional rule overrides the policy. A graph holds those links explicitly, so they can be followed.
How a knowledge graph works
A knowledge graph is assembled in four layers: schema, ingestion, entity resolution, and query.
The schema declares which entity types exist (customer, order, subscription, device, policy) and which relationships are legal between them. Ingestion pulls records from source systems, a CRM, a billing platform, a knowledge base, and converts each record into nodes and typed edges. Entity resolution is the layer that decides whether the account in billing and the email address on a ticket belong to the same person, then merges their edges under one identifier. Get that wrong and every downstream answer inherits the error.
Query is where the payoff arrives. A traversal starts at a customer node and walks two or three hops to reach the entitlement that governs their case. Retrieval stacks pair this with semantic search over unstructured text, so retrieval-augmented generation can return a policy passage and the customer's actual entitlements in one response. Conceptual graphs, a formalism from the 1980s that mapped logic statements into graph form, shaped how these edges came to be typed.
Types of knowledge graphs
Enterprise graphs: Model an entire organization's entities, customers, contracts, products, and internal systems, so separate departments query one shared representation.
Domain graphs: Scoped to a single subject area such as billing or device diagnostics, which makes them cheaper to maintain and usually more accurate.
Product and catalog graphs: Link SKUs, variants, compatibility, and replacement parts, which is what makes "will this part fit my model" answerable at all.
Customer graphs: Center on a person and their accounts, orders, subscriptions, and contact history, and carry the heaviest privacy obligations of the five.
Ontology-driven graphs: Enforce a formal vocabulary and inference rules, strong where classification must stay consistent, brittle where the business redefines itself quarterly.
Knowledge graph vs relational database vs vector index vs ontology
Teams conflate these four because all of them promise to make company data answerable. A relational database stores rows in fixed tables and answers the questions its schema anticipated. A vector index stores numeric embeddings of passages and answers by similarity to a query. An ontology stores the vocabulary and inference rules that define what an entity is allowed to be. A knowledge graph stores the entities themselves along with the named links between them, which is what lets one answer travel from a customer to the specific policy that binds their case.
What it holds | Ownership | Who reads it | AI-retrievable | Choose it when | |
|---|---|---|---|---|---|
Knowledge graph | Entities and named relationships | Data team plus domain owners per edge type | Software, and analysts through a query layer | Yes, by traversal | Answers depend on connections across systems |
Relational database | Rows and columns in fixed tables | Engineering | Applications and reporting tools | Only through predefined queries | The question is a lookup the schema already covers |
Vector index | Embeddings of text passages | Whoever owns the content pipeline | Retrieval systems | Yes, by similarity | The answer lives in prose, not in records |
Ontology | Entity types, properties, and inference rules | Governance or architecture function | Modelers, and the graph that enforces it | Indirectly, as constraints | Classification must stay consistent over years |
If the questions arriving unanswered are lookups your schema already anticipated, the database is enough. If they are connection questions that span billing, orders, and policy, you need the graph, with an ontology acting as its rulebook and a vector index handling the prose.
Why a knowledge graph matters for customer experience
Without one, every cross-system question becomes a research task. An agent asked whether a customer qualifies for a free replacement has to establish the order date, the warranty window, the regional rule, and how many replacements were already issued. Four systems, four windows, several minutes, and a different answer depending on who is working the queue.
AI grounding fails quietly in the same situation. A model can quote exactly the right policy sentence and still apply it to the wrong entitlement, because it had the prose and no reliable link between that prose and this customer's record.
The tradeoff is upkeep. Every schema change, merged account, deprecated product, and renamed plan costs maintenance work, and a stale graph asserts incorrect relationships with the same fluency it asserts correct ones.
How is a knowledge graph measured?
Graph quality is measured on four dimensions, and each has to be checked separately. Coverage asks what share of the entity types your real questions touch actually exist as nodes. Entity resolution accuracy asks how often two records for the same person were correctly merged, and how often two different people were wrongly collapsed into one. Edge freshness asks how long a relationship survives after the underlying record changed. Multi-hop answer correctness asks whether a traversal of several steps still lands on the right fact.
No standards body publishes a target for graph completeness, so the available external reference points describe model performance on knowledge-intensive tasks: multi-hop question answering suites score systems on a 0-100 accuracy scale, and the year-over-year movement in those scores is tracked annually in the Stanford HAI AI Index. Treat any completeness percentage a vendor quotes as a description of their own dataset.
How AI agents change knowledge graphs
An AI agent queries at answer time, under a latency budget, with no ability to open a second screen and reconcile what it finds. That changes what the graph is for. It stops being an analytics asset and becomes the runtime source of entitlements, eligibility, and account state that a generated answer has to be true against.
Two consequences follow. First, edges now need provenance and a timestamp, because an agent that cannot tell when a relationship was last confirmed cannot decide whether to act on it or hand off. Second, the graph becomes the natural home for long-term memory, since a returning customer's history is a set of relationships, and a graph already stores relationships as first-class objects.
The failure this prevents is the one teams recognize immediately: two sources describing the same account differently, producing conflicting answers across knowledge sources that a customer discovers before you do.
What to look for in a knowledge graph
Judge a graph platform on five axes. Schema flexibility comes first: adding an entity type should take days, and the platform should let you keep provisional edges while the model settles. Integration surface is second: connectors that sync incrementally beat nightly full reloads, and the query API has to be callable inside an agent's response window.
Governance is third, and it is the one teams skip. Every edge type needs a named owner who decides what it means, otherwise the same relationship gets defined twice with different semantics.
On security, customer graphs concentrate linked personal data in one place, so regulated buyers ask how a GDPR deletion request propagates across merged identities, and how SOC 2 Type II evidence covers who can traverse which subgraph.
The operational constraint that bites hardest is entity resolution drift: identifiers change, and someone has to adjudicate the ambiguous merges every week.
Knowledge graphs and knowledge operations
A graph describes how entities relate, and a knowledge atlas describes where written knowledge lives, who owns each source, and which two sources disagree. Run together, they answer both halves of a support question: what is true about this customer, and what is written about this policy.
The retrieval choice sits alongside them. Reading the tradeoffs in grounding versus retrieval-augmented generation clarifies which facts belong in a graph as structured edges and which belong in prose that gets retrieved.
What does a knowledge graph mean in plain terms?
Think of a knowledge graph as a family tree drawn for a company's records. Every customer, order, plan, and rule is a dot, and every line between two dots is labelled with how they are related. You can start at any dot and walk the lines to reach whatever you need to know.
Without it, answering "can this customer get their money back" means opening four screens and holding the pieces together in your head. That works until the thing doing it is software, which cannot open screens or notice that two of them disagree.
The tradeoff is upkeep. Someone has to keep the lines true. A line drawn once and never checked keeps pointing confidently at an answer that stopped being correct months ago, and nobody finds out until a customer is told the wrong thing.
Common knowledge graph mistakes
Most graph projects fail in one of four ways.
The first is modelling everything before answering anything. Teams spend months designing a schema that covers the whole business, and ship nothing that a support agent can query. The mechanism is that schema work has no feedback signal until something queries it, so errors compound invisibly.
The second is treating entity resolution as a one-time load job. Identifiers change constantly, accounts merge, people switch emails, and a resolution pass that ran once at migration decays into a graph where the same customer exists three times with a third of their history each.
The third is letting the graph and the documents drift apart. When a policy changes in an article but not in the rules attached to the graph, retrieval returns both and the answer depends on which one surfaced first. That is a knowledge architecture problem, and no amount of tuning the retriever resolves it.
The fourth is leaving edge types unowned. An unowned relationship gets redefined by whoever touches it next, and two teams end up reading opposite meanings from the same label.
What is a knowledge graph in customer support?
A knowledge graph in customer support stores customers, orders, subscriptions, devices, and policies as connected entities, so a single query can establish who someone is, what they bought, and which rule applies. Support agents and AI agents use it to answer eligibility and entitlement questions that would otherwise require checking several separate systems.
What is the difference between a knowledge graph and a vector database?
A knowledge graph stores explicit, named relationships between entities and answers by traversing them, so the path to an answer is inspectable. A vector database stores numeric embeddings of text and answers by similarity, which handles prose well and handles precise entitlement questions poorly. Most production support stacks run both together.
Knowledge graph vs ontology: what is the difference?
A knowledge graph holds the actual instances: this customer, this order, this policy, and the links joining them. An ontology holds the schema above it, defining which entity types exist, what properties they carry, and which relationships are valid. The ontology is the rulebook; the graph is the populated record that obeys it.
What is an example of a knowledge graph triple?
A knowledge graph triple is a three-part statement: subject, relationship, object. "Order 4412 was placed by Maria" is one triple, and "Maria subscribes to the premium plan" is another. Because both triples share the Maria node, a system can answer which plan covers order 4412 without either fact stating it directly.
Do you need a knowledge graph for RAG?
A knowledge graph is not required for retrieval-augmented generation, which works on text passages alone. It becomes necessary when answers depend on account-specific facts: entitlements, order state, plan tier, prior claims. Text retrieval can supply the policy wording, and the graph supplies which version of that policy applies to this person.
How do you build a knowledge graph from existing systems?
Building a knowledge graph starts from questions, not from data. List the cross-system questions that currently take agents several minutes, identify the entities those questions touch, define the relationships joining them, then connect only the source systems that populate those edges. Add entity resolution early, and expand the schema once the first traversals return correct answers.