Embeddings, what they do and what they do not do

An embedding turns text into a list of numbers such that texts with similar meaning produce similar numbers. That property is genuinely useful and it is also narrower than it sounds.

What similarity actually captures

Embeddings are trained so that text appearing in similar contexts ends up nearby. This captures topic and register well. It does not reliably capture negation, quantity, or time.

"The Pro plan includes lead forms" and "The Pro plan does not include lead forms" are nearly identical as strings. They differ by one word that reverses the meaning entirely, and they will sit very close together in embedding space.

This is not a bug to be fixed by a better model. It is a consequence of what similarity means. If your content contains both a statement and its negation, similarity search cannot reliably tell you which one answers the question.

The practical consequences

Numbers do not embed well

"500 credits" and "5,000 credits" are close in embedding space and ten times apart in fact. Any question whose answer hinges on a specific number is at risk from pure vector retrieval. This is a strong argument for hybrid retrieval on pricing content specifically.

Recency is invisible

An embedding has no concept of when text was written. A 2024 pricing page and a 2026 pricing page embed almost identically. If both are in your index, retrieval will pick one essentially at random. The fix is at the source level: do not index superseded content.

Contradictions are undetectable at query time

If two indexed pages disagree, retrieval will surface one of them and the model will answer from it confidently. There is no mechanism that notices the disagreement. This has to be prevented at indexing time, by having a single authoritative source per fact.

What embeddings are good at

Worth being fair about the strengths, because they are the reason to use this at all:

• Paraphrase. "How much" and "what is the cost" retrieve the same content, which keyword search fails at.
• Vocabulary mismatch. A visitor saying "chatbot" finds content saying "assistant".
• Conceptual grouping. Related content clusters without anyone tagging it.
• Multilingual, with the right model. A question in one language can retrieve content in another.

Choosing dimensions and models

Higher dimensional embeddings capture more nuance and cost more to store and search. For a website assistant with a few thousand chunks, this is not the constraint people expect it to be. The index is small and search is fast either way.

The more consequential choice is consistency: the same model must embed your content and your queries. Mixing models produces vectors in different spaces and the similarity scores become meaningless. If you change embedding models, you must reindex everything. This is the migration cost people forget when they plan an upgrade.

A useful mental model

Treat embedding search as a fast, fuzzy first pass that narrows thousands of chunks to a handful. It is a filter, not a decision. If precision matters for a particular question type, add a second stage that applies more expensive logic to those few candidates, whether that is keyword matching, reranking or a rule.