What is graph-enhanced retrieval?

Graph-enhanced retrieval means running a knowledge graph alongside vector search and using it to reach documents the query's own wording would never have found. It is a specific technique with a specific cost, and it is worth understanding both before adopting it — including the cases where it buys you nothing.

The problem vector search cannot solve

Vector search retrieves passages that resemble the question. That is a good match for most questions, and it fails in one specific way: when the answer requires combining two passages that do not resemble each other.

Consider a question like "does finishing onboarding early reduce churn?" One document reports retention rates by onboarding speed. Another explains that accounts which reach value quickly stay. Neither document mentions the other. A vector search over the question will probably find both, because both are topically close — but the connection between them is not written down in either one, so the answer either restates both passages and leaves the reader to join them, or it asserts a connection the model inferred and cannot cite.

That second outcome is the one to worry about. It looks like a good answer. It is a hallucination with two real citations attached.

What the graph adds

A knowledge graph built from your corpus stores what documents assert as edges between entities. When two documents each assert something about the same entity, that entity becomes a join point, and the relationship between the two documents becomes a thing you can query rather than a thing a model has to guess.

In practice this buys you two kinds of reach an ordinary search does not have:

• Content the question never worded. Documents whose vocabulary does not overlap with the question at all, reached because the things they discuss are connected to the things the question is about — ask about React and you reach material that only ever says JSX.
• The documents that support the point rather than resemble it. A passage supporting a claim, rather than a passage that merely sounds like the question.

Both are additive. The ordinary search still runs at full strength, and if the graph contributes nothing the result is a normal search rather than an error. That property is worth insisting on when you build or buy: a graph that can degrade your baseline is worse than no graph.

What it costs

Two costs, both real:

The ingest cost is predictable in money and significant in operational surface: extraction is the step that fails, retries, and needs concurrency limits. The query-time cost is latency you are adding to every search, which matters a great deal for a typeahead and not at all for an analytical question.

When plain retrieval is enough

Four cases where the extra reach has nothing to reach for. Worth checking against your own corpus before you add the cost.

• Your questions are answered by single passages. "What is our refund window" is a lookup, and a lookup was never about connecting documents.
• You have one content source with one vocabulary. The graph earns its keep by bridging entities across sources, so with one source there is less to bridge — and the count that would show it working, entities appearing in two or more systems, will read low.
• Your corpus is small. Under a few thousand documents, a search over everything is close to exhaustive already, so the recall problem the graph solves is one you do not yet have.
• Latency is your binding constraint. If the search box has to feel instant, the extra reach is not available to you regardless of what it would add — though it may still suit a different surface in the same product.

How to tell whether it is working

Two metrics, neither of which is "does it feel better".

The first is how often graph-derived documents reach the final result set at all. If the extra reach rarely surfaces a document an ordinary search missed, the graph is decoration. It is the easy one to measure, and it only tells you the machinery is running.

The second is harder and more important: does it answer questions the baseline could not? This requires a question set with known answers and a run of each system over it, counting questions answered by one and refused by the other in both directions. It is more work than it sounds, and it is the only measurement that distinguishes a real improvement from a system that has simply become more willing to talk.

What to take away

Graph-enhanced retrieval is the right technique when your content spans multiple systems, your questions span multiple documents, and you need to be able to point at the evidence behind an answer. It is the wrong technique when you have a lookup problem, one source, or a latency budget measured in tens of milliseconds.

And if you adopt it, insist on two properties: that the vector baseline always runs, and that every fact the graph holds can name the documents that assert it. Without the first you have added a way to get worse. Without the second you have added a way to be confidently wrong.