Skip to main content

Command Palette

Search for a command to run...

Day 14: Why embeddings are useful and easy to overtrust

Why semantic similarity is useful, but not the same as correctness or trust.

Updated
3 min readView as Markdown
Day 14: Why embeddings are useful and easy to overtrust
V
I’m Vamsi, a builder focused on production AI systems. I write Production AI Field Notes to break down the architecture behind reliable LLM apps, RAG, agents, multi-agent workflows, evaluation, observability, safety, and governance. My goal is simple: help builders move beyond impressive AI demos and design systems that can be tested, operated, trusted, and improved in the real world.

How does a computer know that "refund" and "money back" mean roughly the same thing, when they share almost no letters?

It stops comparing spellings and starts comparing positions.

Meaning gets an address

An embedding converts text into a long list of numbers: coordinates in a space arranged so that distance corresponds to similarity of meaning. "Refund", "money back", and "return my payment" land near each other. "Refund" and "refuel" do not, despite looking alike.

That is the machinery under semantic search, and it is genuinely powerful: users can ask in their own words and still reach documents written in yours.

Similarity is not relevance

Here is the gap that causes production problems. Embeddings measure similarity. Teams use them as if they measured relevance. Those two overlap often enough to be convincing and diverge often enough to hurt.

"What is our refund policy?" and "customers furious about refunds" sit close together in embedding space. One is a policy question; the other is a complaints analysis. Semantic closeness gets you to the right neighbourhood, not the right house, and the scoring function will not tell you which one you got.

The sharpest version of this: "eligible" and "not eligible" embed remarkably close together. Negation barely moves the coordinates, and the consequences of getting it backwards are enormous. Any domain where a "not" flips the outcome (eligibility, compliance, safety, permissions) needs a signal that is not purely semantic.

Three ways teams overtrust them

  • Domain vocabulary. General-purpose embedding models are trained on general-purpose text. Your internal product names, acronyms, and jargon may be positioned badly or arbitrarily. Test with the vocabulary your users actually type, not with tidy examples.
  • Version lock-in. The embedding model defines the geography of your index. Change the model and every stored vector becomes meaningless relative to new queries. You must re-embed the entire corpus. If that migration is not planned from day one, it eventually happens as an emergency.
  • Confidence theatre. A similarity score of 0.87 looks like a probability of correctness. It is not. It is a distance in a space you did not design, and the threshold that seemed reasonable on sample data may be meaningless on real queries.

What to actually do

Use embeddings for what they are excellent at: broad recall, catching paraphrases, surfacing candidates you would never have matched by keyword — then let other components decide precision: exact-match signals for identifiers, metadata filters for permissions and dates, reranking for final ordering.

The practical test: find queries in your domain where the semantically closest text is the wrong answer. Every domain has them. If you cannot find any, you have not looked hard enough, and your system is currently trusting similarity as though it were truth.

Closing thought

Embeddings give meaning an address. They do not tell you whether the resident is trustworthy, current, or allowed to talk to this particular user.

Day 14 of 60 Days of Production AI Systems.

Where in your product are you relying on semantic closeness when the user actually needs an exact match?


Previous: Day 13: Why chunk boundaries shape answer quality
Next: Day 15: Why vector stores are infrastructure, not magic memory

Day 14 of 60 · Retrieval Foundations (chapter 3 of 10)

Retrieval Foundations

Part 2 of 6

A practical foundation for retrieval systems. This series explains how chunking, embeddings, vector databases, keyword search, semantic search, hybrid retrieval, metadata, and access filters decide what evidence an AI system can safely use.

Up next

Day 15: Why vector stores are infrastructure, not magic memory

Why vector databases need to be operated like infrastructure, not treated like magic memory.