What is an enterprise knowledge graph, and when is it worth building?

The short version

• An enterprise knowledge graph stores an organisation's entities, such as people, customers, contracts and systems, and the relationships between them, so software can query the connections directly.
• Vector search finds passages that sound like the question; a knowledge graph answers questions that depend on how things are connected.
• The hardest part of an enterprise knowledge graph is entity resolution, deciding which records refer to the same person or customer, not the choice of database.
• A knowledge graph built once goes stale, because roles, owners and documents keep changing, so upkeep has to be designed in from the start.
• For most organisations, permission-aware search is the right first step, with a graph added only where real questions turn on relationships.

What is an enterprise knowledge graph?

An enterprise knowledge graph is a model of an organisation's entities and the relationships between them, stored so software can query the connections directly. The entities are the nouns the business runs on: people, teams, customers, contracts, products, systems, tickets and documents. The relationships are the verbs: owns, signed, reports to, depends on, replaces, mentions.

The point is not the diagram. It is that a question like 'which customers are on contracts that reference the old pricing schedule' becomes a walk along known links, rather than a hope that the right passages happen to sound like the question.

In AI assistants the graph usually sits beside a search index rather than replacing it. The index holds the text. The graph holds the structure: which document belongs to which customer, which version replaced which, and who is accountable for what. Together they are the two halves of what people mean by a 'company brain'.

Why do organisations want an enterprise knowledge graph?

Because the information needed to answer one question is usually spread across systems that do not share identifiers. The CRM knows the customer, the ticketing system knows the complaints, the shared drive holds the contract, and no two of them spell the customer's name the same way. Someone has to join them by hand, every time.

The complaint is common, even if its cost is hard to pin down. Microsoft's 2023 Work Trend Index, a survey of 31,000 workers across 31 markets, found time spent searching for information among the things workers say they struggle with. Atlassian's State of Teams 2025, based on 12,000 knowledge workers and 200 executives, also treats time spent looking for information as a major drain on teams.

Both are vendor surveys, and both vendors sell tools that promise to fix the problem. Read them as evidence that the complaint is widespread, not as a measure of what it costs you. The better test is local: how long does a new starter take to answer a question that spans three of your systems?

How is an enterprise knowledge graph different from vector search?

Vector search finds passages whose meaning is close to the question. A knowledge graph follows explicit links between known entities. The first is good at 'what does the policy say'. The second is good at 'what is connected to this, and how'.

Vector search has no idea of identity. Two passages about two different customers called Harris look alike to an embedding. It has no idea of completeness either. It returns the closest few matches, so a question that needs every matching record gets a sample, and the answer presents the sample as the whole.

A graph has the opposite profile. It is exact about what it holds and blind to everything it was never told. If a relationship was never extracted, the graph does not know it exists, and it will not warn you.

Which questions suit vector search, and which suit a knowledge graph?

Is there evidence that a knowledge graph improves AI answers?

Yes, in specific settings, reported by the teams that built the systems. The two most useful studies show real gains, but neither shows that a general-purpose enterprise graph pays for itself.

LinkedIn built a graph from its historical customer service tickets, keeping the structure inside each ticket and the links between related tickets, then retrieved from that graph to answer support questions. In offline tests it reported a 77.6% improvement in mean reciprocal rank over a baseline without the graph. After about six months of use inside its customer service team, it reported a 28.6% reduction in median per-issue resolution time.

Notice what made that work. Support tickets already have sections and fields, and they already reference each other. The graph formalised relationships that were in the data. It did not have to infer them from loose prose.

Microsoft Research compared its GraphRAG approach with ordinary vector retrieval on 125 sensemaking questions, each judged five times, over two corpora of roughly one million and 1.7 million tokens. GraphRAG's answers were judged more comprehensive and more diverse than those from vector RAG.

Two caveats matter. The judge was a language model, not a panel of people. And the questions were about whole collections, such as the main themes across many transcripts, not lookups of a single fact. That is where top-few retrieval is weakest, so the result shows a graph helping with questions vector search was never built for. It does not show a graph helping with everything.

What makes an enterprise knowledge graph hard to build?

Four things, and the graph database is not one of them: entity resolution, extraction quality, staleness and permissions. Each is a data problem, and each decides whether the graph can be trusted.

Entity resolution is deciding that 'J. Harris', 'Jo Harris' and the account jharris are one person, and that two suppliers called Harris are not. Every answer inherits those decisions. Get one wrong and the graph confidently joins records that should never meet.

Extraction is how relationships get in. Structured fields, such as a ticket's customer ID or a contract's counterparty, are cheap and dependable. Relationships pulled from prose by a language model cost a model call per chunk before anyone asks a question, and some will be wrong in ways that are hard to spot.

Staleness is the cost nobody budgets for. People change roles, systems change owners, documents are replaced. A graph built once and left alone becomes a confident record of how the organisation used to work.

Permissions are harder in a graph than in a search index, because an edge can reveal what a document would not. The fact that an employee is linked to a grievance case is sensitive even if the case file stays locked. Access control has to cover the relationships, not only the documents at either end.

When is an enterprise knowledge graph not worth building?

When the questions people actually ask are answered by one document at a time. Policy lookups, how-to questions and 'where is the template for' are search problems. A graph adds build cost and upkeep without changing the answer.

It is also not worth it when the source systems share no identifiers and nobody is prepared to fix that. The project then becomes data cleaning under another name, and it should be scoped and priced as data cleaning.

And it is rarely worth it as the first step. A permission-aware search over the documents you already have will show you which questions fail. Those failures tell you which relationships deserve modelling. Building the graph first means guessing which ones matter.

How should an organisation start on an enterprise knowledge graph?

1. Collect a few dozen real questions from last month's tickets, chat and email, not from a workshop.
2. Run them against a plain, permission-aware search and record which ones fail.
3. Sort the failures into missing content, poor ranking, and questions that depend on relationships.
4. Model only the entities and relationships the third group needs, starting with structured fields that carry stable IDs.
5. Decide how each relationship stays current, and who hears when it breaks, before you build it.
6. Re-run the same questions after every change, so you know whether the graph earned its place.