A vector database finds what’s similar. A knowledge graph finds what’s connected. Many business problems need both.
The choice between the two representations is often presented as a technology decision. It’s more useful to read it as a question about the kind of queries the system will need to support, because that’s what determines the architecture.
How similarity search works
A vector database stores content in numerical form. Every chunk of a document is turned into a sequence of numbers that represents its meaning: content with related meaning gets representations that sit close together.
An everyday analogy captures the idea. Imagine placing every paragraph of your documents in a huge space, arranging them so that texts about similar things end up near each other. When a question comes in, you place it in the same space and look at what’s around it.
From this come the useful properties. Search works even when the words don’t match: “early termination” and “contract cancellation” end up close together. It works on very large archives with contained response times. And it doesn’t require content to be classified in advance.
And from this come the limits. Search returns what’s similar, not necessarily what’s correct. It doesn’t distinguish between a current document and a superseded one, if nothing in the text flags it. And it’s imprecise on literal references: an article code or a case number is better found with traditional text search, which is why hybrid solutions are almost always adopted in business settings.
How a relationship graph works
A knowledge graph represents entities and the links between them. It doesn’t store text: it stores structured statements.
The model is a list of facts. Product A includes component B. Component B is supplied by company C. Procedure D applies to product A. Circular E amends circular F. Company G controls company H at sixty percent.
Building one requires two upfront decisions: which types of entities to represent and which relationships to track. This is modeling work, not indexing, and it needs to be done with people who know the domain.
There are three useful properties. Answers are exact, because they derive from declared relationships rather than similarity. It’s possible to traverse multiple steps: from a component back up to every product that includes it, and from those to every customer who bought them. And inconsistencies become detectable, because a contradictory relationship is visible in the structure.
The limits are just as clear-cut. Building and maintaining it carries a significant cost. The graph only covers what’s been modeled: a question about something not represented gets no answer. And it doesn’t handle free-form language, because it isn’t a text archive.
When similarity alone falls short
The typical case is a question that requires following relationships across multiple steps.
“Which customers received products that include the component named in the non-conformity report.”
A similarity search retrieves documents that talk about that component and documents that talk about non-conformity. It doesn’t connect the two sets, because no single document contains the answer: the answer only exists as a chain of relationships between separate pieces of data.
The same holds in other contexts. Reconstructing a multi-level corporate ownership chain. Finding every circular that amends a provision, and which of those have themselves been amended. Establishing which procedures are affected by a change to a regulation.
The general rule: if the question contains a “which… that…” with more than one step, similarity alone isn’t enough.
The reverse holds too. For questions like “how do I carry out this procedure” or “what does the regulation say in this case,” the graph adds nothing and semantic search is the right solution.
Hybrid architectures
In most real projects the two representations coexist, with a defined division of labor.
The graph holds the structured entities and their relationships: products, components, case files, parties, regulations, versions. The vector database holds the textual content: manuals, procedures, acts, correspondence.
The link between the two runs through identifiers: every indexed chunk of a document records which entities in the graph it relates to.
A complex question is then broken down. The graph identifies the set of relevant entities by traversing relationships; semantic search retrieves the textual content associated with those entities; the model builds the answer from that material, citing the sources.
The graph brings a further benefit, often decisive: it lets you apply currency and permission filters in a structured way, instead of inferring them from the text.
On when to adopt a hybrid architecture, the criterion is practical. If the expected questions require traversing relationships, if there’s a domain with stable, well-identifiable entities, and if currency or versioning is a significant concern, the graph justifies its cost. Otherwise, it’s better to start with hybrid text and semantic search alone, and assess extending it after observing the real questions being asked.
What neither one solves
Neither creates information that doesn’t exist. If the relationship between a component and a product isn’t recorded anywhere, the graph can’t represent it.
Neither replaces the quality of the source data. A graph built on inconsistent master records produces incorrect relationships, with the added risk that they look precise.
And neither eliminates the need for evaluation. The system needs to be measured against real cases before release, whichever representation is chosen.
In closing
The question to ask at the start isn’t which technology to adopt, but which queries the system will need to support. Collecting twenty real questions from the intended users is an exercise of a few hours that determines the architecture more reliably than any abstract technology assessment.
If you’re designing a system of this kind, we’re available for a conversation about your case: which entities exist in your domain, which relationships are already recorded in your systems, and which questions you should be able to ask.
