What Are Embeddings? Vectors and Cosine Similarity Explained Simply

Search for “how to get my money back”, and a good system should find a page titled “Refund policy”, even though the two share no important words. That ability comes from embeddings, one of the most useful ideas in modern AI.

This guide explains embeddings without heavy maths. We ran a small example in Python 3.13, and its output is shown below. The vectors in it are ones we made up by hand, with only three numbers each, to make the idea easy to see. Real embeddings come from a trained model and often have hundreds or thousands of numbers.

What is an embedding?

An embedding is a representation of something as a list of numbers, called a vector. A model is trained so that items with related meanings get vectors that are close together.

"kitten"  -> [0.9, 0.8, 0.1]
"cat"     -> [0.9, 0.7, 0.2]
"invoice" -> [0.0, 0.1, 0.9]

Once text is in this form, a computer can calculate how similar two pieces of text are, which it cannot do directly with words. Embeddings are not limited to words, either. Sentences, whole documents, images, audio and products can all be embedded.

Why not just match keywords?

Our guide to RAG shows this in practice. A simple word-count search scored zero for “When can I get my money back?” against a refunds document, since they shared no words. Note the third row as well: exact identifiers are a weakness of embeddings, so keyword search still has a place.

Think of a map

Imagine placing every word on a huge map, where location reflects meaning. “Cat” and “kitten” sit almost next to each other, “dog” is in the same neighbourhood, and “invoice” is in a different city. To find related words, you simply look nearby.

A real embedding works the same way, except that the map has hundreds of dimensions rather than two. People cannot picture that, but the math works just the same. Individual numbers generally have no neat meaning, like “furriness”. What matters is the overall position.

A small working example

Here is how to compare our hand-made vectors:

import math

def cosine(a, b):
    dot = sum(x * y for x, y in zip(a, b))
    return dot / (math.sqrt(sum(x * x for x in a)) *
                  math.sqrt(sum(y * y for y in b)))

vectors = {
    "kitten":  [0.9, 0.8, 0.1],
    "cat":     [0.9, 0.7, 0.2],
    "dog":     [0.8, 0.3, 0.2],
    "invoice": [0.0, 0.1, 0.9],
}

for word in ("kitten", "dog", "invoice"):
    print(word, round(cosine(vectors["cat"], vectors[word]), 3))

# kitten 0.994
# dog 0.955
# invoice 0.238

Against “cat”, “kitten” scores highest, “dog” next, and “invoice” far lower. We chose these vectors to produce that pattern, so the ranking proves nothing about real language. It only shows how the calculation behaves. A semantic search does the same thing in three steps: embed the query, score it against every stored item, and sort.

query = [0.85, 0.75, 0.15]
sorted(vectors, key=lambda w: cosine(query, vectors[w]), reverse=True)

# ['kitten', 'cat', 'dog', 'invoice']

Cosine similarity explained

Each vector can be thought of as an arrow pointing from the origin. Cosine similarity measures the angle between two arrows, ignoring how long they are. We confirmed the key values:

cosine([1, 2, 3], [2, 4, 6])   # 1.0   same direction
cosine([1, 0], [0, 1])         # 0.0   unrelated (at right angles)
cosine([1, 0], [-1, 0])        # -1.0  opposite directions

Look at the first line. [2, 4, 6] is twice as long as [1, 2, 3], yet the score is a perfect 1.0, because direction is all that counts. That is useful for text, where length can reflect things like document size rather than meaning. Be careful with thresholds, too. There is no universal score that means “similar”, as useful ranges differ from model to model, so test on your own data.

Other distance measures

The difference is easy to see. Those same two vectors with a cosine score of 1.0 have a Euclidean distance of 3.742, since one is longer than the other. Many systems normalize vectors, scaling each to a length of 1. After that, the dot product and cosine give the same answer, and we confirmed this: both gave 0.955 for “cat” and “dog”. Check your model’s documentation to see which measure it recommends.

How embeddings are learned

Nobody assigns these numbers by hand in real systems. A neural network learns them during training. An early and influential idea is that words appearing in similar contexts tend to have similar meanings, as with “I fed my cat” and “I fed my dog”. Models such as Word2Vec and GloVe learned word vectors from those patterns.

Later, transformer-based models such as BERT made embeddings context-aware, so “bank” could get a different vector in “river bank” and “bank loan”. Many modern models embed entire sentences or passages at once. Our guide to large language models explains how transformers handle context.

Where embeddings are used

Searching at scale

Our example compared a query with every item, which is known as an exact search. That works fine for thousands of items, but it becomes slow with many millions. Approximate nearest neighbour (ANN) indexes such as HNSW solve this. They find very close matches quickly, by giving up a small chance of missing the absolute best one.

Vector databases and extensions, such as pgvector for PostgreSQL, provide these indexes along with filtering and storage. Our vector database guide covers the options. For a small project, you may not need one at all, and an in-memory search is a perfectly good way to start.

Choosing an embedding model

• Language. If your content is in Hindi or Tamil, for example, check that the model handles it well.
• Domain. General models can struggle with specialist legal or medical terms.
• Dimensions. More dimensions can capture more detail, but they cost more storage and memory.
• Cost and hosting. Compare a hosted API with an open model you can run yourself, especially for private data.
• Input length. Models have a limit, so long documents must be split into chunks first.

The best test is your own data. Collect about 20 real queries along with the documents they should find, and compare how each model ranks them. Published benchmarks may not reflect your content.

Limitations

• Model lock-in. Vectors from different models cannot be compared. If you change models, you must embed everything again.
• Exact terms. IDs, codes and rare names may not be matched reliably.
• Negation. “Refunds allowed” and “refunds not allowed” can land close together, despite meaning opposite things.
• Similar does not mean correct. A close match may be outdated or simply wrong.
• Bias. Embeddings can absorb stereotypes from their training data.
• Cosine is not magic. Researchers have questioned how meaningful it is on some learned embeddings, so treat scores as a useful signal and not as a measure of truth.

Common mistakes

• Mixing models. Embed queries and documents with the same model and version.
• Using one similarity threshold everywhere. Tune it for each model and task.
• Embedding huge documents whole. Meaning gets diluted, so chunk them first.
• Skipping evaluation. Without test queries, you cannot tell if a change helped.
• Using embeddings for everything. If users search for exact IDs, a normal database index is better.

Final thoughts

An embedding turns meaning into numbers, so that software can compare ideas rather than strings. The concept is simple, while the practical work lies in choosing a model, chunking data and testing on real queries. To try it yourself, embed a few dozen of your own documents with any embedding model, search them with real questions, and see where the results surprise you.

Frequently asked questions

Keep learning