The useful question is not whether knowledge graphs are better than embeddings. It is where the system needs meaning to live.
Embeddings are excellent at finding candidates. A knowledge graph is where a system records what those candidates are, how they relate, where they came from, and which rules they satisfy.
That distinction gets lost because both are sold as ways to make systems "know" things. They do not know in the same way. The OpenAI embeddings guide describes an embedding as a vector of floating point numbers, where distance between vectors measures relatedness. Relatedness is a powerful primitive. It is not identity.
If I ask for documents about supplier risk and one page says "vendor exposure", a vector index can still bring it back. That is the win. The text did not need to be modelled ahead of time. Dense retrieval earned its place in open-domain QA for exactly this reason: Dense Passage Retrieval showed that dense representations can retrieve useful passages across question-answering datasets, and RAG made dense retrieval an access path for generation over external text.
But a relevant passage is not the same thing as a dependable answer.
Embeddings win at recall
Use embeddings when the hard part is finding language that points in the right direction: paraphrase, fuzzy search, semantic similarity, near-duplicate discovery, and retrieval over documents that nobody has turned into a domain model yet.
That covers many early systems. The team has PDFs, notes, tickets, policies, and emails. Nobody agrees on the schema. The right first move is often to index the corpus and see what comes back.
Even then, vector search should not become a religion. BEIR found that BM25 remained a strong zero-shot baseline across diverse retrieval tasks, while dense models still had room to generalize. Exact terms still matter. Part numbers, policy clauses, named standards, and error codes should not be blurred into semantic neighbourhoods if the literal token is the evidence.
The practical retrieval layer is usually mixed: vector search for candidate recall, lexical search for exact terms, and reranking where the first pass is too broad. That layer is an index. Rebuild it when the embedding model changes. Tune it when recall gets noisy. Do not mistake it for the knowledge model.
Graphs win at identity
A knowledge graph earns its keep when the system has to preserve identity under change.
RDF 1.1 makes identifiers and named relationships part of the model: subject, predicate, object. OWL adds machine-interpretable classes, properties, individuals, and data values. SHACL validates RDF data graphs against shapes graphs. Those are not retrieval conveniences. They are contracts.
This is where graphs beat embeddings. A graph can say that this control satisfies that policy clause, that this evidence came from that test run, that this supplier is the same legal entity as the supplier in another system, and that this answer violates a shape because the required approval is missing.
Provenance is the cleanest example. PROV-O models entities, activities, agents, and derivation relationships. That is the structure behind the question, "why should I trust this answer?" A vector index can retrieve a citation-looking passage. The graph can represent who produced it, which activity generated it, what it derives from, and whether it is still the current source.
This connects directly to the earlier RDF vs property graph argument: the architecture question is where meaning has to live. Embeddings put relatedness in a distance function. Graphs put meaning in identifiers, predicates, constraints, and provenance.
The handoff is the architecture
The strongest pattern is not replacement. It is handoff.
Let embeddings find plausible candidates. Let lexical search protect exact names and codes. Then let the graph decide what those candidates mean, connect to, satisfy, contradict, and prove.
GraphRAG is one version of that pattern. The GraphRAG paper argues that ordinary RAG struggles with global questions over a whole corpus and uses an entity knowledge graph plus community summaries to support query-focused summarization. The GraphRAG documentation describes a pipeline that extracts a graph from text, builds community structure, and uses those artifacts in retrieval. I would treat that as a useful implementation pattern, not a settled answer for every corpus.
The failure modes are worth naming. Graphs become stale. Extraction misses entities. Two names get collapsed when they should stay separate. A bad graph can give precise wrong answers, which is worse than a retrieval system admitting it only found candidates.
Embedding systems are not structureless either. They can carry metadata filters, citations, hybrid lexical search, and rerankers. The point is narrower: that structure sits around the vector index. It is not the core model of identity, policy, provenance, or lifecycle state.
So the decision rule is simple. If the problem is recall over language, start with embeddings and keep lexical search close. If the problem is identity under change, put the durable commitments in a graph.
Vectors can be rebuilt. Identifiers are promises.