knowledge graph
A knowledge graph stores facts as triples — subject, predicate, object — so "Eiffel Tower, located in, Paris" and "Eiffel Tower, designed by, Gustave Eiffel" become edges connecting named entities rather than sentences buried in a document. Google popularized the term when it launched its own Knowledge Graph in 2012, seeded in part by the Freebase dataset it had acquired, to answer search queries with facts and related entities instead of only matching pages; Wikidata, the open, community-edited counterpart, now holds on the order of one hundred million items and is a common free source for bootstrapping a new graph rather than building entity data from nothing.
Two competing representations split the ecosystem, and the choice is rarely revisited once made. RDF triple stores give every entity and relation a globally unique identifier (a URI), query through SPARQL, and lean on formal ontologies and description-logic reasoning to infer new facts from existing ones — the W3C standard, and the choice when interoperability with external linked-open-data sources like Wikidata or DBpedia matters. Property graphs, the model behind Neo4j and its Cypher query language, instead attach arbitrary key-value properties directly to nodes and edges and favor fast traversal over formal inference — the simpler choice when the graph is purpose-built for one application rather than meant to interlink with the wider semantic web. Both represent the same subject-predicate-object idea; they differ in how strictly identity is standardized and how much reasoning the store does on your behalf.
Embedding a knowledge graph turns symbolic facts into the vector arithmetic a model can use directly. TransE (Bordes and colleagues, 2013) was the method that popularized the idea: it learns a vector for every entity and every relation such that adding the subject's vector to the relation's vector lands close to the object's vector — so "Paris" plus "capital-of" should land near "France." The approach is elegant for simple one-to-one relations and breaks down for relations with many valid objects (a person can have many children, and they cannot all sit at the same translated point), which is why later methods like DistMult and ComplEx replace the translation with other scoring functions better suited to one-to-many and symmetric relations. These embeddings are what let a knowledge graph plug into a neural pipeline instead of staying a purely symbolic, traversal-only structure.
Entity resolution is the unglamorous step that decides whether the graph is usable at all. Raw extraction from text produces many surface forms for the same real entity — "Paris," "the City of Paris," and a misspelled variant — and a graph that treats each as a separate node fragments every fact about that entity across disconnected nodes instead of consolidating it onto one. Entity linking resolves a mention to a canonical identifier, typically against a reference graph like Wikidata, and the quality of that linking step bounds the quality of every multi-hop query run afterward: a graph is only as connected as its entity resolution made it.
GraphRAG applies this structure to the retrieval problem that plain vector search handles badly. A vector database finds chunks that are individually similar to a query, but a question like "how are these two acquisitions connected through a shared executive" needs the retrieval step to follow relationships, not just rank passages — exactly what a knowledge graph is built for. Microsoft's GraphRAG (2024) formalizes this by using an LLM to extract an entity-relationship graph from a document set, clustering it into communities, and summarizing each community so that broad, synthesis-style questions can be answered from community summaries while narrow factual questions still go through targeted graph traversal. The tradeoff is upfront cost: building and maintaining the graph is far more expensive than embedding chunks, which is why graph-augmented retrieval tends to appear on top of, rather than instead of, a vector index.
A knowledge graph can encode disputed or outdated claims as first-class facts rather than forcing one version of the truth. Because every triple can carry its own source, timestamp, and confidence, a well-built graph can hold "Source A claims X" and "Source B claims not-X" as two valid, separately attributed statements rather than silently picking a winner — which matters for fraud investigation, legal research, and any domain where provenance of a claim is as important as the claim itself. The cost of that flexibility is that a graph without disciplined metadata quickly becomes impossible to query cleanly, which is why production knowledge graphs invest as much in schema and provenance discipline as they do in the facts themselves.
Read a knowledge graph as the tool for the retrieval and reasoning tasks a flat vector index structurally cannot do — anything requiring a traversal of several connected facts rather than a single best-matching chunk — and the real engineering cost is not storing triples but building and maintaining the entity resolution that makes those triples connect to each other in the first place.