Your Vector Database Can't Tell You What's Missing

Vector search is good at finding things that look similar. It is structurally incapable of answering a whole category of business questions that don't care about similarity at all — they care about structure, state, and absence. This session made that case through a running example: a fictional analyst named Betsy, and the question of what happens when a document that was supposed to arrive never does.

The Question Similarity Search Can't Answer: "What's My Exposure to Company X?"

The opening example: a client wants to know their total exposure to a company, across every possible path of ownership. The answer isn't a single number pulled from a document, it's a computed sum across several routes:

• Client → direct → Company X: 2.1%
• Client → Fund A → Company X: 0.8%
• Client → Fund B → feeder fund → Company X: 0.4%
• Total exposure to Company X: 3.3%

The framing that matters here: "Multiply ownership along each path; sum across paths. The answer is a path set, not a number — every hop auditable, down to the source document." No single chunk of text contains that 3.3%. It doesn't exist anywhere until it's computed by walking the ownership graph. A vector database, no matter how good its embeddings are, cannot retrieve a number that was never written down anywhere.

Four Things Similarity Search Cannot Compute, In Principle

This is the core argument of the session, laid out as four distinct failure modes, not just one general limitation:

Global structure. Cycles and redundancy in a network are properties of the whole graph, not of any single document. The session's example: a 77.5% figure that "wasn't retrieved, it was computed" — meaning no chunk of text anywhere contained that number. It only existed as the output of analyzing the full structure.

This instance. Retrieval is fundamentally about finding things that resemble other things. But if you ask an agent what a specific stuck loan is waiting on, retrieval gives you back what stuck loans usually look like in general. That's not the same answer. As the session put it: "State is particular; similarity generalizes." A specific case needs specific state, not a statistically likely pattern.

Absence. A document that never arrived has no embedding, because embeddings only exist for things that exist. If a required document is missing, similarity search has nothing to retrieve, because there's nothing there to find. The expectation that something should have arrived by now only lives on a graph that models what's supposed to happen, not on the (nonexistent) document itself.

Action. Retrieval can inform a next step, but it cannot constrain one. Whether a legal or business process is even allowed to move from one state to the next is a structural relationship, an edge in a graph, not a similarity score. The session's memorable framing: "Legal transitions are edges — that's why Betsy answers the phone." Betsy, in this recurring example, is the person (or system) that has to know a specific transition is or isn't permitted right now, which similarity search simply has no mechanism to represent.

The session's summary line for all four: "Retrieval stays for recall. It can't be the steering logic." Vector search remains genuinely useful for finding relevant information. It just can't be trusted to drive decisions that depend on structure, specific state, missing pieces, or permitted next steps.

How to Start: The Order of Operations

The session closed with a practical four-step sequence for teams wanting to add graph-based reasoning without a massive up-front project:

1. Extract the edges. Most organizations already have this structure declared somewhere: ORM schemas, dbt refs, CI configs, workflow YAML, Terraform, queue topics, import graphs. Extraction is a parsing exercise, not a multi-quarter initiative.

2. Run the classics. Standard graph algorithms, strongly connected components, betweenness centrality, community detection, ship with every mainstream graph library. The session's claim: you'll find your first real insights the same day, pointing to specific examples like "your 21-node tangle" and "your 4x node."
3. Hand them to the agent. Each graph query becomes a callable tool, exposed through MCP or any function-calling interface, feeding into the same agent loop already covered in earlier sessions.
4. Then add expectations. Push changed facts into the agent's live context, and fire events when something expected doesn't show up. That's the Betsy example, and the tax document (K-1) that never arrived.

What This Means for Anyone Building AI Over Business Data

If your AI strategy is entirely built on a vector database and semantic search, you have a good recall system and a structurally incomplete reasoning system. Anything involving multi-hop exposure calculations, the specific status of one particular case, a document or event that should have happened but didn't, or whether a next action is even permitted, needs graph structure underneath the retrieval layer, not instead of it. The two aren't competing approaches. Retrieval finds what's relevant. Graphs tell you what's true, what's missing, and what's allowed to happen next.

Wondering if your AI strategy is missing the structural half of the problem? Winsome helps companies figure out where retrieval ends and real data architecture needs to begin. Talk to Winsome about your AI data strategy.