Embeddings explained, without the heavy math

An embedding is a list of numbers that captures what a piece of text means, produced by a model so that text with similar meaning gets similar numbers. That's the whole idea. Feed a sentence into an embedding model, get back a vector — an array of a few hundred to a few thousand numbers — and the useful property is that two sentences meaning roughly the same thing come out as two vectors sitting close together, while unrelated sentences come out far apart. Everything embeddings power, from semantic search to RAG to recommendations, is that one property being exploited. This is the intuition-first tour: what they are, why the geometry works, how to search them, how to choose a model, and where they quietly fall down. No linear algebra required.

The intuition: meaning becomes a location

Here's the mental model that makes the rest click. Imagine a giant map where every possible piece of text has a spot. Sentences about dogs cluster in one region; sentences about tax law cluster in another far-off region. "How do I get a refund" and "I want my money back" land almost on top of each other, because they mean the same thing, even though they share no words. An embedding model is the thing that assigns each piece of text its spot on that map. The vector — that list of numbers — is just the coordinates.

Real embeddings don't live on a 2D map; they live in a space with hundreds or thousands of dimensions, which no one can picture. But the intuition survives the jump: similar meaning = nearby location, different meaning = distant location. You don't need to know what any individual number means (you can't — no single dimension is "the dog-ness axis" you can read). You only need to trust that the model placed similar things near each other, because that's exactly what it was trained to do. Once meaning is a location, comparing meanings becomes measuring distance, and distance is something a computer does trivially.

How similarity search works

This is where the payoff lands. You embed every document in your corpus once, up front, and store the vectors. When a query comes in, you embed the query the same way, then find the stored vectors closest to it and return those documents. That's semantic search, and it's the retrieval half of most RAG systems.

The standard way to measure "closest" is cosine similarity, and the intuition is simpler than the name. Picture each vector as an arrow pointing out from the center of the space. Cosine similarity measures the angle between two arrows, ignoring how long they are. Two arrows pointing the same direction score near 1 (very similar meaning); perpendicular arrows score near 0 (unrelated); opposite directions go negative. Direction carries the meaning, length doesn't, which is why angle is the right thing to measure.

For a few thousand documents you can literally compare the query against every stored vector — that's fast enough. Once you're into tens of thousands or millions, you reach for a vector database, which builds an approximate index so it can find the near-neighbors without brute-forcing every comparison. You trade a sliver of accuracy for a massive speed win. For the full head-to-head on when this beats plain word matching, I keep that in vector search vs keyword search.

What embeddings power

The same "nearby = similar" trick shows up all over, and once you see it you'll recognize it everywhere:

• Semantic search — find documents by meaning, not exact words. The base case above.
• RAG — retrieve the most relevant chunks by embedding similarity, then feed them to an LLM to ground its answer. Embeddings are the retrieval engine; where retrieval fits against the other options is RAG vs fine-tuning vs long context.
• Clustering — group similar items automatically by looking at which vectors bunch together, with no labels required. Useful for organizing a support inbox or surfacing themes in feedback.
• Deduplication — near-identical items produce near-identical vectors, so a high similarity score flags duplicates and near-duplicates that exact-string matching would miss.
• Recommendations — "more like this" is just "vectors near this one." Embed items (and even users' histories) and the nearest neighbors are your suggestions.

Different products, one primitive. That's why embeddings are worth understanding once, deeply — the return compounds across features.

Choosing an embedding model

There's no single best model; there's a best fit for your data and budget. Three levers matter.

Dimensions. More dimensions can capture finer distinctions, but they cost more to store and search, and the quality gains flatten out quickly. Most retrieval work is well served somewhere in the range of a few hundred to about 1,500 dimensions. Don't chase the biggest number — treat dimensions as a cost-and-speed dial, not a quality score. Some newer models let you truncate the vector to fewer dimensions and give back a little accuracy for cheaper storage, which pays off at scale.

Cost. You pay to embed every document once and every query forever. For a large corpus the one-time document embedding is the big bill; for a high-traffic app the per-query cost adds up. Both are usually modest, but they're real, so factor them in.

Domain fit. A model trained mostly on general web text may underperform on medical, legal, or code-heavy content where the vocabulary is specialized. This is the lever people skip and regret. The only reliable way to choose is to test candidate models on your actual queries and your actual documents, and measure which one retrieves the right thing most often. Benchmarks are a starting shortlist, not a verdict.

Practical gotchas

Three things bite people in production.

Chunking. You rarely embed whole documents — a single vector can't faithfully represent a 40-page manual, because it averages everything into one blurry point. You split content into chunks and embed each. Chunk too big and the vector is unfocused; too small and you lose the context that made the passage meaningful. Getting this right is most of the quality in a real RAG system, and it's context engineering territory.

Consistency (the "normalization" question). Use the same model and the same preprocessing for your stored documents and your queries. Cosine similarity already ignores length, so it doesn't care about normalization — but if your index uses a length-sensitive distance, normalize both sides to unit length so "close" means "similar direction." The failure that actually happens is subtler: someone re-embeds documents with a new model but keeps embedding queries with the old one, and retrieval silently degrades. Vectors from two different models are not comparable. Ever.

Staleness. Embeddings are a snapshot. Change a document and its stored vector is now wrong until you re-embed it. Change your embedding model and every stored vector is now incomparable with new ones — you have to re-embed the whole corpus. Build the re-embedding path before you need it, or your index quietly rots.

When embeddings are not the answer

Embeddings are a hammer, and not everything is a nail. When the match is about exact tokens — SKUs, error codes, IDs, names, legal citations — keyword search is more precise, because embeddings blur near-identical strings ("error 4011" and "error 4001") into neighbors. When you need exact filters — price under 50, in stock, category equals X — that's a database WHERE clause, not a similarity score, and forcing it through embeddings is slower and less reliable. When your entire corpus fits in the model's context window, you may not need retrieval at all; just hand the model everything. And remember embeddings capture similarity, not truth — they'll cheerfully return a confidently wrong or outdated passage if that's what sits closest, so pair them with the discipline of grounding and, where structure matters, structured output and tool use.

The through-line: embeddings turn meaning into geometry so a computer can compare concepts with arithmetic. That's a genuinely powerful trick, and most of getting value from it is knowing precisely which problems are shaped like it — and reaching for a different tool when they aren't. For where this fits in the larger build, the field guide to building with LLMs puts it in context.