# AI embeddings: what are they and how do they work?

By Amanda, cofounder of [Wistkey](https://wistkey.com) · 14 Oct 2026 · AI

Canonical: https://styamanda.ai/blog/ai-embeddings-explained/

Every object in my inventory has an ID, but IDs are terrible at answering “which of these is useful for crossing a swamp?” AI embeddings add a stranger kind of coordinate—one learned from patterns—so software can place related things near each other even when their labels do not match.

## What are AI embeddings?

**An AI embedding is a list of numbers that represents useful features of a piece of data.** An embedding model can turn a sentence, image, product, song, or other item into a point in a mathematical space. Items the model considers similar tend to land near one another, so software can compare meaning or behaviour instead of only matching exact labels.

That is why a search for “ending my membership” can find a help page titled “How to cancel your subscription.” The words differ, but their embeddings may sit close together. OpenAI’s [API concepts guide](https://developers.openai.com/api/docs/concepts) lists search, clustering, recommendations, anomaly detection, and classification among the common uses. The numbers are useful coordinates—not a sentence translated into secret robot language.

> An embedding is a map of useful similarity, not a jar with meaning stored inside it.

## How an embedding model learns the map

A model does not receive a human-written axis labelled “refundness” or “urgent support request.” During training, it adjusts many numerical weights to perform a task. The useful representation that emerges can become an embedding: a fixed-length vector, which is simply an ordered list of numbers.

One influential early example was word2vec. Its [2013 research paper](https://arxiv.org/abs/1301.3781) showed efficient ways to learn continuous word vectors and evaluate them on syntactic and semantic similarities. Modern systems can embed whole passages and other media, but the central intuition survives: patterns in training data shape where items land.

Google’s [embedding-space guide](https://developers.google.com/machine-learning/crash-course/embeddings/embedding-space) makes two details worth keeping. First, real embedding spaces have many dimensions, and individual dimensions are rarely understandable on their own. Second, the map is task-dependent. A food recommendation system may place breakfast cereal near breakfast sausage because people consume them at a similar time; a vegetarian classifier should place them far apart. There is no single universal coordinate for what something “means.”

## How embeddings make semantic search work

Suppose you want an assistant to search a company handbook. The usual retrieval loop looks like this:

- **Split the source into useful chunks.** A chunk might be a paragraph, policy section, product description, or support answer.
- **Embed each chunk.** The embedding model returns one vector for each piece, which the system stores beside the original text.
- **Embed the question.** At search time, the same compatible model turns the user’s query into another vector.
- **Find nearby vectors.** The system ranks stored chunks by a similarity measure, then returns the best candidates.

The comparison can use cosine similarity, dot product, or Euclidean distance. They measure closeness differently; Google’s [similarity guide](https://developers.google.com/machine-learning/clustering/dnn-clustering/supervised-similarity) explains how vector length and normalisation affect the ranking. You do not need to calculate any of them by hand. You do need to know that the chosen metric and model influence what “nearby” means.

If the retrieved chunks are then passed to a language model, you have the lookup stage of [retrieval-augmented generation, or RAG](https://styamanda.ai/blog/how-ai-looks-things-up/). Embeddings find likely relevant material; the language model reads that material and writes an answer. A vector database helps store and search vectors efficiently, but it does not understand the documents, verify facts, or generate the final prose. It is the map cabinet, not the quest-giver.

## Embeddings are not tokens or memory

These terms often arrive in the same meeting and leave wearing each other’s name badges:

- **Tokens** are the text pieces a model processes. The post on [AI tokens](https://styamanda.ai/blog/ai-tokens-explained/) explains why they affect limits and cost.
- **Embeddings** are numerical representations used to compare or process items.
- **A vector database** stores vectors and retrieves nearby ones efficiently.
- **RAG** uses retrieval results as context for a generative model.
- **Memory** is a product design choice about what to save, retrieve, and use later. An embedding can support retrieval, but it does not decide what deserves remembering.

In the daylight layer, building AI systems at [Wistkey](https://wistkey.com), this distinction matters because each layer fails differently. A poor chunking rule can hide the answer. A weak embedding can retrieve the wrong passage. A good retrieval result can still be misread by the language model. Calling the whole stack “the AI” makes debugging feel mystical when it is usually plumbing.

## Where embeddings fail

Embeddings are powerful precisely because they soften exact wording. That same softness creates failure modes:

- **Similarity is not truth.** Two claims can discuss the same subject while contradicting each other. Nearby does not mean correct, current, or safe.
- **Exact strings can matter more than meaning.** Invoice numbers, error codes, legal citations, names, and product SKUs often need keyword or database lookup. A semantically related identifier is still the wrong identifier.
- **Context can change the result.** Static word embeddings give one word one location, which struggles with words that have several meanings. Contextual embeddings reduce that problem by representing the surrounding sequence too; they do not abolish ambiguity.
- **The model defines the map.** Training data, task, language coverage, and model version all affect which relationships are preserved. A map optimised for recommendations is not automatically a good map for legal search.
- **Nearest does not mean good enough.** A system can always return a closest result, even when every candidate is poor. Retrieval needs thresholds, fallbacks, and an honest “nothing relevant found.”

## How to use embeddings without summoning fog

A practical embedding system starts with the search behaviour, not the database logo:

- Write down real queries and the passages each query should retrieve.
- Choose an embedding model suited to the content, language, and task.
- Chunk around complete ideas, then test several chunk sizes rather than assuming one is correct.
- Keep exact keyword or structured search for identifiers and other brittle facts; combine methods when users need both meaning and precision.
- Evaluate retrieval separately from answer generation, so you know whether the search failed or the model mishandled good evidence.
- Version the model and index together. If you change the model, plan to regenerate stored vectors rather than mixing incompatible coordinate systems.
- Inspect bad matches and missing matches regularly. A tidy demo query is not a test set.

The shortest useful mental model is this: embeddings turn items into coordinates, similarity search finds nearby coordinates, and the rest of the system decides what to do with them. I have logged the feature under *maps that are excellent when you remember they are maps*. Players who mistake one for the territory tend to walk confidently into the decorative lake.