Embeddings turn text into lists of numbers so a computer can compare meaning, not just spelling. Here is how that works and how it powers semantic search.

Classic search matches words. If you search for “cheap flights” it looks for pages containing those exact words. A page about “affordable airfare” is missed, even though it is exactly what you wanted.

Embeddings fix this. They let software compare what a piece of text means, and they sit behind semantic search, recommendations and most “chat with your documents” features.

What an embedding is

An embedding is a list of numbers that represents a piece of text. A special model reads the text and produces the list. Text with a similar meaning gets a similar list of numbers.

You can picture each list as a point on a map. Sentences about the same topic land close together, and unrelated ones land far apart.

Keyword search compares spelling. Semantic search compares meaning.

Measuring “close”: similarity

Once text is a list of numbers, comparing two pieces of text is just maths. The most common method is cosine similarity, which measures how closely two lists point in the same direction. A score near 1 means very similar. A score near 0 means unrelated.

similarity.py
import math

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

# tiny made-up 3-number "embeddings"
cheap_flights   = [0.9, 0.1, 0.2]
affordable_fare = [0.8, 0.2, 0.3]
banana_bread    = [0.1, 0.9, 0.1]

print(cosine(cheap_flights, affordable_fare))  # about 0.98, very close
print(cosine(cheap_flights, banana_bread))     # about 0.27, far apart
Higher means closer in meaning. The numbers are illustrative.

How semantic search is built

Almost every semantic search system follows the same five steps. The first three happen once, ahead of time. The last two happen on every search.

Prepare once, then search quickly every time.

The place you store the vectors is called a vector database (or a vector index inside a normal database). It is built to answer one question fast: “which stored vectors are nearest to this one?” Instead of comparing against every vector, it uses approximate methods that are much quicker and are almost always accurate enough.

Where you will see it used

  • Search that understands intent. Help centres and docs that find the right page even when you phrase things differently.
  • Retrieval for AI answers. The “R” in RAG. Find the most relevant passages, then hand them to a language model. See our RAG vs fine-tuning guide.
  • Recommendations. “People who read this also read...” based on similar content.
  • Duplicate detection. Spotting support tickets or questions that say the same thing in different words.

Things that go wrong

  • Chunks that are too big or too small. Huge chunks blur many topics together. Tiny chunks lose context. A few paragraphs is a common starting point.
  • Mixing embedding models. Vectors from different models are not comparable. Always embed documents and queries with the same one.
  • Trusting similarity blindly. Close does not always mean correct. Exact things like product codes and names are often better served by keyword search, so many teams combine both.
  • Forgetting to re-embed. If your documents change, their vectors must be refreshed too.