Embeddings: Turning Tokens Into Meaning
Once text is split into token IDs (plain integers), the model needs to turn each ID into something that carries meaning. It does this with an embedding: a list of numbers (a vector) assigned to each token.
You can picture each token as a point in space. Tokens with similar meaning end up near each other; unrelated tokens end up far apart. "Cat" and "dog" land close together. "Cat" and "bicycle" land far apart.
Crucially, these positions aren't hand-designed — they're learned during training. The model starts with random vectors for every token and gradually nudges them around as it sees which words tend to appear in similar contexts ("the cat sat" vs. "the dog sat"). Words used in similar ways drift toward similar positions.
Real embeddings have hundreds or thousands of dimensions, far more than we can visualize. The explorer below compresses them down to 2D so you can see the shape of the idea, even though real embedding space is much richer.
Hover a word to see its nearest neighbors
Words that mean similar things end up close together in this compressed 2D view of embedding space.
This is why embeddings are so powerful: relationships become geometry. Famously, in well-trained embedding spaces, king - man + woman ≈ queen — the direction between words captures a relationship, not just a category.
Now that each token is a meaningful vector, the model needs a way to let tokens influence each other based on context. That's the job of self-attention, next.
The explorer above used hand-placed 2D positions so the idea of clustering stayed visible. Here's the real thing: genuine 128-dimensional embeddings from an actual trained model, compressed down to 3D with real PCA (principal component analysis) instead of hand-placed — drag to rotate, and look up any word.
Real embeddings, real 3D — drag to rotate
These points are real, pretrained word embeddings (the same tiny BERT from the attention widget), compressed from 128 real dimensions down to 3 with real PCA — genuine geometry, not a hand-placed layout.
Loading the real model's full vocabulary (~15MB, once per visit)…
One honest limitation: the 3D position is a lossy compression of 128 real dimensions down to 3 — two words can look farther apart here than they really are, or vice versa. That's why the nearest-neighbor list above is computed on the real, uncompressed vectors, not the picture.
What determines where a token's embedding ends up in vector space?