Knowledge graphs and multi-hop retrieval
A knowledge graph is a graph of entities and typed relations, and it is the form in which an agent can retrieve a fact with its context rather than a passage with a guess. It is also the form in which teams most often assume a currency problem is solved when it has only been restated.
What is a knowledge graph?
A knowledge graph is a graph of data intended to accumulate and convey knowledge of the real world, in which nodes represent entities of interest and edges represent relations between them. That is the formulation used by the Hogan et al. survey published in ACM Computing Surveys in 2021. The important part is the intent: knowledge about things rather than stored records, queried for what is true of an entity rather than for rows that match a key.
What makes it a knowledge graph rather than a database
Three properties distinguish the two, and none is about the storage engine. Entities and relations are typed — a node is a customer, a component or a policy; an edge is an ownership, a dependency or a supersession — and the type is part of the data, not an application convention. Entities have identifiers that mean something beyond the system that issued them, so two graphs can be merged. And the schema is open, so sources can add relations without a migration that stops the world.
Those properties make a graph answerable in ways a record store is not. A relational schema is designed around the questions someone anticipated; a knowledge graph is designed around the entities, and the questions arrive later. That is the trade: give up a fixed schema, gain the ability to ask questions nobody modelled.
RDF triples and labelled property graphs
The two families in common use differ in where identity lives. RDF models everything as triples — subject, predicate, object — with subjects and predicates identified by IRIs and objects that are IRIs or literals, so a graph is a set of such statements. Because those identifiers are global, two RDF graphs using the same IRI for the same thing merge without a mapping table, and the standard query language works over patterns of triples. The RDF and SPARQL pages cover both.
Labelled property graphs take the other approach: nodes and edges carry a label and key-value properties, and identity is local to the database. That suits application data and graphs that live inside one system; the cost appears at the boundary, where combining two such graphs means mapping their notions of the same entity by hand. Neither choice is wrong. A graph that lives inside one application is fine as a labelled property graph; one meant to accumulate knowledge from several sources is better served by RDF, where identity is the point.
Identity: IRIs, aliases and entity resolution
Every graph of any size acquires the same defect: one entity under several names, and one name over several entities. A knowledge graph handles it by making identity explicit — one identifier per entity, the other names attached to it as labels, and any equivalence between two vocabularies recorded as a statement in the graph rather than kept in a mapping document.
This is the same problem an ontology addresses: matching tools can propose that two records are the same entity, but someone decides and the graph records it. An alias list that is not maintained is worse than none, because it makes a graph look complete while quietly splitting one entity in two.
Why graphs help agents
An agent working over documents retrieves passages and guesses which applies. An agent working over a graph retrieves the entity and walks. A question spanning several relations — which systems depend on the component this supplier provides — is a path in the graph and a set of similarity scores in a passage index. The graph returns the fact with the relations connecting it to the question, which is the context an agent needs in order to act rather than summarise.
Three consequences follow. Multi-hop questions become answerable without the agent inventing intermediate steps, because the steps are edges. Types and constraints become checkable, because the graph states them. And the answer carries its basis: the triples that produced it are the citation, which is what makes an agent's output auditable.
What a graph does not solve
A graph does not make knowledge current. It is a representation, and a graph of stale facts is still stale. If the source that knows the supplier changed last month never writes to the graph, the graph answers confidently with last month's supplier and cites itself for it. Structure is not currency.
What a graph does provide is somewhere for currency to be recorded. Provenance statements let each fact carry where it came from and when it was asserted, so an agent can tell a fact written yesterday from one written in a migration three years ago — the subject of PROV-O. Persistent identifiers and archived versions let one identifier resolve to what was true at a given time, not only now — the subject of Mementos. And a taxonomy or ontology keeps the types from proliferating.
A graph does not solve coverage either. It answers well about what has been modelled and says nothing about what has not, and the gap is invisible from outside: an agent that queries a graph and gets no result cannot tell whether the fact is false or merely absent. That distinction has to be designed into the query, the model, or the agent's instructions.
FAQ
A graph database is storage that traverses connected records well. A knowledge graph is a claim about content: entities of interest, typed relations between them, and the intent to accumulate knowledge of a domain rather than merely hold records. You can build one in a graph database, a relational database or a triple store.
No, but the choice has consequences. RDF gives global identifiers, a standard model and a standard query, which is what makes graphs from different sources mergeable. Labelled property graphs give attributes on nodes and edges and a query style many developers find quicker to work with. They differ in how much of the identity and merging work the standard does for you.
Size is the wrong measure. Coverage of the questions you actually ask and stability of the identifiers matter far more than node count. A small graph with unambiguous identities answers more useful questions than a large one in which the same entity appears three times under three names.
No. A graph is a representation, and a graph of stale facts is still stale. Currency comes from the processes that write to it, from recorded provenance about where each fact came from, and from identifiers that resolve to the version that applied at a given time.
Sources
- Hogan et al., Knowledge Graphs, ACM Computing Surveys, 2021. Verified 200. Source for the definition of a knowledge graph quoted above, and for the survey treatment of graph models and the field.
- RDF 1.1 Concepts and Abstract Syntax — W3C Recommendation. Verified 200. Source for the triple model: IRIs as subject and predicate, IRIs or literals as object, graphs as sets of triples.