Write down the ten questions your users will actually put to the system before you pick a retrieval architecture. If most of them read like “find me the section that covers X,” vector search will carry the workload on its own. If they read like “which suppliers are connected to the contracts affected by X,” no amount of embedding tuning will get you there, because that is a relationship query and similarity is the wrong primitive for it.
Knowledge graphs and vector search get framed as competitors, but they answer different question shapes. Embeddings measure how alike two pieces of text are. A graph records that two things are related, how, and on whose authority. Most architecture arguments dissolve once the team stops debating technology and starts sorting its real queries into those two piles.
Executive Takeaway
- Match the primitive to the question shape: similarity for “find the passage,” traversal for “how are these things connected.”
- Vector search is cheap to stand up and hard to explain. A graph is expensive to curate and easy to audit. Pick the cost that fits the risk profile of the workflow.
- Most workloads are served well by vector search plus a disciplined metadata layer; a graph earns its upkeep when relationship queries are the product.
Where Vector Search Earns Its Keep
Vector search is the right default for recall over unstructured content: policies, reports, tickets, transcripts, contracts. It tolerates vocabulary mismatch, which is where keyword search dies, and a team can stand it up in days by chunking the corpus, embedding it, and indexing it.
Similarity cannot count, aggregate, or join. Ask a vector store how many subcontract agreements include a particular flow-down clause and you will get chunks that resemble the question, not an answer. Provenance is shallow: you know which chunk a claim came from, but not how that chunk relates to the entities the business cares about. And embeddings handle negation poorly, so a query about vendors that are not certified retrieves passages about certification either way.
What a Knowledge Graph Actually Buys
A graph gives you typed entities and explicit relationships, so multi-hop questions become traversals instead of guesses: this program depends on that system, which is owned by that team, which sits under that contract. The join is explainable, the path is auditable, and access control can be enforced on relationships rather than whole documents. For provenance-heavy work, that is the difference between an answer and an argument.
The cost is not the graph database. The cost is ontology design, entity resolution, and permanent curation. Somebody has to decide what counts as a supplier, merge the four spellings of the same company across source systems, and keep the edges current as the business changes. That curation load is what stalls most graph initiatives, usually in year two, when the founding team has moved on and nobody owns the merge queue.
The Criteria That Decide It
- If fewer than one in five real queries need multi-hop relationships, start with vector search and revisit when the query log says otherwise.
- If answers must show a governed path back to systems of record, put a graph or a structured store in the design from the start.
- If nobody will own entity resolution after launch, do not build a graph. An uncurated graph degrades into a stale diagram within months.
- If the relationships already live in an ERP or CRM, query those systems directly rather than duplicating them into a store you must keep in sync.
Hybrid Patterns That Survive Production
The pattern that holds up most often is layered: vector search finds the entry points, and structure carries the expansion. Sometimes that structure is a true graph traversal from retrieved entities out to their neighbors. More often it is a well-built metadata layer on the vector store, with entity tags, document types, effective dates, and permission labels attached to every chunk and filtered before similarity runs. That layer delivers much of what teams want from a graph at a fraction of the curation cost.
Hybrid designs need a routing decision, though. Something has to look at each query and choose similarity, traversal, or both, and that router needs its own evaluation set. Skip it and you get two retrieval systems and inconsistent answers that erode user trust.
This layered approach is how Sprinklenet builds retrieval inside Knowledge Spaces: permission-aware indexes and source citations by default, with entity structure added where the query log proves the need, so retrieval stays a governed control layer instead of a second data swamp.
Common Failure Modes
- Building the graph before a query pattern exists, which produces an ontology nobody traverses and a curation bill nobody budgeted.
- Using similarity where exact relationships matter, so the system answers compliance and dependency questions with plausible but unverifiable text.
- Underfunding metadata on the vector side, which forfeits most of the graph value that tags and filters would have delivered cheaply.
All three share a root cause: the architecture was chosen before anyone studied the queries. Pull a real sample of user questions, classify each as recall or relationship, and let the distribution make the call.
Three Questions That Settle the Choice
- Of the top twenty queries users actually run, how many require following relationships across entities?
- When an answer is challenged, what evidence does the workflow require: a source passage, or a path through systems of record?
- Who owns entity resolution and index freshness a year from now, and is that in their job description?
A team that cannot answer the first question does not have an architecture problem yet. It has a discovery problem, and a week spent reading real query logs will save a quarter spent building the wrong index.
Sprinklenet Perspective
Sprinklenet builds retrieval systems designed for enterprise and government-grade requirements, where “the model said so” is never an acceptable evidence trail. Knowledge Spaces is the platform we run them on, and in a typical six-week pilot-to-production engagement the first stretch goes to the query log and the source inventory, because that is where the graph-versus-vector question usually answers itself.
Explore Knowledge Spaces, review our AI engineering services, or talk to Sprinklenet about what your query log says your retrieval architecture should be.
