What Are Embeddings?

An embedding turns text into coordinates where distance approximates similarity of meaning. Excellent at paraphrase, weak at negation and exact identifiers — and the benchmark built to rank them found no model dominates.

Reviewed

An embedding is a list of numbers that represents a piece of text, and whose usefulness comes from one property: texts with similar meanings get similar lists.

That is the whole idea. Everything else — vector search, semantic search, RAG, recommendations, clustering, deduplication — is built on it.

What similar lists means

An embedding model turns a string into a vector of a few hundred to a few thousand floating-point numbers. On its own the vector is meaningless; no individual number corresponds to anything you could name. What matters is the geometry. How do I reset my password and I forgot my login details land close together. How do I reset my password and what is your refund policy land far apart.

Closeness is usually measured with cosine similarity — the angle between two vectors, ignoring their length — which yields a score you can rank on.

This is why embeddings do something keyword search cannot. A keyword index matches on the strings present; an embedding matches on what the text is about. A query with no words in common with the document that answers it will still find it.

What they are not

Embeddings do not understand. They encode statistical regularities of usage. A model will happily place two texts close together because they share a topic, register, or grammatical form, not because one answers the other. This is the source of most disappointing semantic search results.

Similarity is not relevance. Two customer complaints about entirely different products can be highly similar as text. If your task is find the document that answers this question, raw similarity is a proxy for it, and sometimes a poor one.

Similarity is not opposition-aware. The deployment succeeded and the deployment failed are extremely similar by embedding distance. They share almost everything except the one word that matters. Negation is a well-known weak spot, and it bites hardest in exactly the domains where it matters most.

They are not interchangeable. Vectors from different models — or often different versions of the same model — are not comparable. Change the model and you must re-embed everything.

Choosing a model: there is no best one

The reflex is to look for the top-ranked embedding model. The benchmark built to answer that question found the question does not have a general answer.

In MTEB: Massive Text Embedding Benchmark, Niklas Muennighoff, Nouamane Tazi, Loïc Magne and Nils Reimers evaluated across 8 tasks, 58 datasets and 112 languages, and concluded that no particular text embedding method dominates across all tasks.

So the useful question is not which model is best but which model is best on my data, for my task. Retrieval, classification, clustering and semantic similarity reward different things.

The practical inputs to the decision:

  • Dimensions. More is not better — it costs storage, memory and query time. Many strong models now support truncating dimensions with modest quality loss.
  • Maximum input length. If your chunks exceed it, the model silently truncates and you lose the tail.
  • Domain. General-purpose models handle general text well and can underperform badly on specialised vocabulary — legal, clinical, industrial part numbers.
  • Language coverage, if you need more than English.
  • Hosted or self-hosted, which is usually decided by cost at volume and by whether the text can leave your infrastructure.

Build a small evaluation set — fifty real queries with known-correct documents — and measure. It takes an afternoon and it beats any leaderboard, because the leaderboard was not run on your corpus. The same argument as how to evaluate and test your prompts.

Chunking is the part that actually determines quality

Most retrieval systems that disappoint are not failing at the embedding step. They are failing at the step before it.

You cannot embed a 90-page document usefully as a single vector — the result is an average of everything, close to nothing in particular. So documents get split, and how you split them decides what can be found.

Chunk too small and each piece loses the context that made it meaningful; a paragraph that says this does not apply to enterprise customers is useless when severed from what this refers to. Chunk too large and the specific answer gets diluted by surrounding text.

What tends to work: split on the document's own structure — sections, headings, natural boundaries — rather than a fixed character count. Keep some overlap so a sentence spanning a boundary is not lost. And carry identifying context into each chunk, so a chunk knows which document and section it came from.

Where they get used

Semantic search and RAG. Embed the corpus, embed the query, return the nearest chunks as context. This is the dominant use, and RAG vs fine-tuning vs prompt engineering covers when it is the right tool.

Hybrid search, which in practice beats pure vector search more often than not. Combining keyword matching with vector similarity covers each method's weakness: keywords nail exact identifiers, product codes and names, where embeddings are unreliable; vectors handle paraphrase, where keywords fail completely.

Reranking. Retrieve a generous candidate set by embedding similarity, then reorder with a slower, more accurate cross-encoder that reads the query and document together. This is frequently the single highest-return improvement to a mediocre retrieval system.

Clustering and deduplication — grouping support tickets by theme, finding near-duplicate content, spotting outliers.

Where they get stored

For a few thousand documents, an array in memory and a brute-force scan is genuinely fine, and considerably simpler than the alternative. Beyond that you want an index — see what is a vector database, which also covers the case for not adding one.

The short version

An embedding turns text into coordinates where distance approximates similarity of meaning. It is a powerful and slightly blunt instrument: excellent at paraphrase, weak at negation and exact identifiers, and entirely dependent on how you chunked the text in the first place. There is no universally best model, so measure on your own data.

More in the AI development pack.

Sources

← Back to Articles How we research & review →