Docs and articles
R-49
Technology
The Case Against Vector Store Sprawl in AI Applications
Pure vector retrieval gives you semantic similarity. It does not give you context. GraphRAG fuses three signals — and it consistently beats vector-only on the queries that matter.
PAR2 Labs
August 29, 2026
2 min
Every team building on LLMs in 2026 has a vector store. Most of them have two. Few of them are happy with the results. The problem isn't the choice of vector database — it's the assumption that semantic similarity alone is enough.
01
What pure vector retrieval gets right
Vector similarity is genuinely useful. “Documents similar in meaning to this query” is a powerful primitive. It handles synonyms, paraphrases, and cross-lingual matches in ways that keyword search never will.
02
What it gets wrong
It's stateless. A vector store treats every embedded chunk as if it exists in isolation. The fact that two chunks come from the same document, share an author, or sit five edges away in a knowledge graph is information the vector store doesn't have and can't use.
Concretely: a query for “Q3 fraud incidents involving the Helsinki branch” might score highly against a Q2 fraud report from a different branch (because the embeddings are dominated by “fraud incident”) and miss the actual Helsinki-Q3 report if its embedding happened to land in a slightly different cluster.
03
Three signals, one retrieval
GraphRAG fuses three independent signals through Reciprocal Rank Fusion:
Vector similarity — HNSW nearest neighbour over embeddings. Catches semantic intent.
Text relevance — BM25 over the same documents. Catches keyword anchors like “Helsinki” and “Q3”.
Graph proximity — adjacency traversal from retrieved nodes. Catches contextual neighbours the embedding ignored.
A single hybrid query runs all three and fuses the rankings, so “Helsinki” and “Q3” anchor the result while the embedding supplies the semantic intent and the graph pulls in the connected facts. In Tessera these three signals index the same records — there's no separate vector store, search cluster, or graph database to keep aligned.
Each signal has failure modes the other two compensate for.
04
Why fusion beats picking one
Each signal has failure modes the other two compensate for. Vector misses exact anchors. BM25 misses synonyms. Graph misses items that aren't connected to a seed node. RRF combines them so that an item ranked highly by two of the three gets promoted above an item ranked highly by only one — even if that one ranking is very confident.
The right question isn't “which retrieval algorithm is best.” It's “which combination of signals correctly disambiguates the queries my users actually ask.”
05
When pure vector is enough
If your corpus is genuinely unstructured — a pile of independent product reviews, say — there are no graph edges to traverse and BM25 buys you marginal recall. Pure vector is fine. The moment your documents have authors, citations, versions, parents, or any kind of relationship — which is true of most enterprise corpora — fusion wins.
06
The cost
Three indexes instead of one. In Tessera that's an implementation detail — the same hyperedge feeds all three, and there's no separate vector store to keep in sync. Outside Tessera, you're now operating two more systems, and we're back to the sprawl we wrote about in “Five Databases Are Four Too Many”. Pick your poison.
Key Takeaways
01
Vector similarity handles synonyms and paraphrase, but treats every chunk as if it existed in isolation.
02
GraphRAG fuses vector similarity, BM25 text relevance and graph proximity through Reciprocal Rank Fusion.
03
Each signal covers the others' failure modes, so an item ranked highly by two of the three is promoted.
04
Pure vector is fine for genuinely unstructured corpora; once documents have relationships, fusion wins.
PAR2 Labs · Technology
Talk to us