What an Embedding Is, and What It Cannot Do

In one line: an embedding turns text into a point in space so that nearness stands in for similarity, and every strength and failure of vector search follows from that one substitution.

The substitution

A model maps input to a fixed-length vector, trained so that things people consider similar land near each other. Once that holds, "find similar items" becomes "find nearby points", and nearest-neighbour search is a solved geometric problem.

That is the entire trick, and it is genuinely powerful. "Laptop sleeve" and "notebook case" share no words and sit close together, so retrieval stops depending on the user guessing your vocabulary.

The four things it cannot do

Each is a real production failure, and naming them unprompted is the difference between someone who has used vector search and someone who has read about it.

Exact identifiers

An embedding is trained to place similar things nearby. A part number, SKU, error code or account ID has no useful similarity structure — A2338 and A2339 are different products, and the model has no reason to separate them and every reason to place them close.

So a user searching for an exact identifier gets semantically similar and factually wrong results. This is the single most common complaint about pure vector search in e-commerce and support, and it is why hybrid retrieval exists.

Negation

"Shoes without laces" and "shoes with laces" embed to nearly the same point. The model captures topic far more strongly than polarity, and a short negating word barely moves the vector.

The consequence is that a query's constraint is often invisible to retrieval. Handling it means extracting the constraint into a filter rather than hoping the embedding respects it.

Numbers and ranges

"Under 500 dollars" is a numeric constraint. Embeddings represent it as text about price, not as an inequality. Retrieval will happily return a 900-dollar item that is textually about being affordable.

Anything with an ordering or a threshold — price, date, rating, distance — belongs in structured metadata and a filter, not in the vector.

Similar is not relevant

The deepest one. Two documents about the same topic are close together whether or not either answers the question. A query about a bug's fix retrieves passages about the bug, because they are topically identical.

That last point is the architectural payoff. The reason a cross-encoder reranker sits after retrieval is that a bi-encoder embeds query and document independently, so it can never model their interaction. A reranker reads both at once and can tell "about X" from "answers X".

What the vector actually encodes

Worth being precise about, because it explains the limitations rather than just listing them.

The dimensions have no individual meaning. There is no "price" dimension. The model learned a coordinate system in which the training objective's notion of similarity became geometric proximity — and that objective is not yours.

Most general-purpose embedding models are trained on some form of "these two texts are related" signal drawn from the open web. If your notion of relevance differs — legal precedent, medical equivalence, code that solves the same problem — the geometry may simply not encode it, and no amount of index tuning fixes a space that never represented the distinction.

That is the argument for domain-specific models and for fine-tuning embeddings, and it is worth being able to state as a capability question rather than a quality one.

Beyond text

The same machinery applies to any modality, and multimodal models place different types in one shared space so an image and its description land near each other.

The design consequence is worth a sentence: once modalities share a space, cross-modal retrieval is free — search images with text, or find the document that matches a diagram — with no change to the index at all. The index does not know or care what produced the vectors.

Next: choosing the model, and why that choice is hard to undo.