TL;DR An embedding turns a piece of text into a list of numbers that marks a point in space, arranged so that things meaning similar things sit close together. Once meaning is a location, “find similar” becomes ordinary distance arithmetic, and that is the engine under search, recommendations, and retrieval.
In an earlier piece I said a token is a chunk of text turned into a number so the model can work with it. That gets text in the door, but a token's number is just an ID, a seat number in a vocabulary. It says nothing about what the word means. The number for “cat” is no closer to “kitten” than it is to “helicopter.” An embedding is the step that fixes that: it turns text into numbers that actually carry meaning.
From tokens to meaning
Here is the shift. Instead of one arbitrary ID per token, an embedding represents a piece of text as a long list of numbers, often hundreds or thousands of them. That list is not random and it is not a lookup-table seat number. It is learned. As the model trains on enormous amounts of text, it nudges these numbers around so that words used in similar ways end up with similar lists. Meaning stops being a label and starts being a pattern of numbers.
The useful way to picture a long list of numbers is as coordinates. Two numbers give you a point on a page. Three give you a point in a room. Hundreds give you a point in a space too big to imagine, but the idea does not change: every piece of text becomes a point, and its position is its meaning.
A point in space
Once you accept that meaning is a location, some famous behaviour stops being surprising. Related words huddle into neighbourhoods: the animal words sit in one region, the vehicle words in another. Even the directions between points mean something. The classic example is that the step from “king” to “queen” is roughly the same step as from “man” to “woman.” The model was never told about gender or royalty. Those directions fell out of arranging the numbers to fit how the words are actually used.
And it is not only single words. You can embed a sentence, a paragraph, a product description, or a support ticket. The same rule holds: the whole thing becomes one point, positioned by what it is about. Two reviews that both complain about battery life land near each other even if they do not share a single word.
Closeness you can measure
This is where embeddings earn their keep. If meaning is a position, then “how similar are these two things” becomes “how close are these two points,” and closeness is just arithmetic a computer does instantly across millions of points. You embed a question, then look for the stored points nearest to it. The nearest ones are your answer, ranked by meaning rather than by matching words.
This is why search built on embeddings can find “change my credentials” when you asked to “reset my password.” Old keyword search would miss it, because not one word overlaps. Semantic search does not care, because the two phrases sit in the same neighbourhood. The same trick, dressed differently, is what drives “more like this” recommendations and the grouping of similar items: all of it is nearest-point lookups in an embedding space.
Why any of this matters
Embeddings are the bridge between messy human language and arithmetic a machine can do at scale. Tokens get text into the model; embeddings give that text a place to stand, so that meaning becomes something you can measure, sort, and search. If a feature ever needs to answer “what is this about” or “what is like this,” there is almost certainly an embedding underneath.
It is also the missing half of the retrieval story. When people ask how a chatbot can answer questions about their own private documents, the honest short answer is: embed the documents, embed the question, keep the nearest chunks. That pattern has a name, and it is the one I want to write about next.