What are embeddings? Vector embeddings explained for developers

Embeddings are lists of numbers (vectors) that represent the meaning of a piece of content, such as a sentence, a code snippet or an image, so that similar content gets similar vectors. An embedding model produces them, and software compares them with simple math to power semantic search, recommendations, clustering and retrieval augmented generation (RAG).

OpenAI's embeddings guide gives the shortest definition: "An embedding is a vector (list) of floating point numbers." The distance between two vectors measures how related the inputs are: small distances mean high relatedness, large distances mean low relatedness.

This guide explains how embeddings work, which models exist today, how to compare vectors, and where embeddings fit in an LLM app.

What is an embedding, exactly?

An embedding is the output of an embedding model. You send it text (or, with some models, images, audio or video) and it returns a fixed-length array of floats. A sentence might come back as 1,024 or 3,072 numbers, depending on the model.

No single number has a readable meaning. What matters is the position of the whole vector relative to others. Anthropic's embeddings guide describes text embeddings as "numerical representations of text that let you measure semantic similarity."

That is the key shift from keyword search. "How do I reset my password?" and "I forgot my login credentials" share almost no words, but a good embedding model places them close together because they mean nearly the same thing.

How do embeddings capture meaning?

Embedding models are neural networks trained so that related inputs land near each other in the vector space and unrelated inputs land far apart. You never design the space by hand; the model learns it from its training data.

Two practical consequences follow:

• Quality depends on the model and domain. Anthropic's guide lists dataset size and domain specificity as the first thing to weigh when choosing a provider, because "Larger or more domain-specific data generally produces better in-domain embeddings."
• Every model has its own space. Vectors from different models are not comparable. Google's Gemini embeddings docs warn that the spaces of its two current models are incompatible, so switching models means re-embedding everything.

What are embeddings used for?

OpenAI's guide lists the common jobs:

• Search: rank results by relevance to a query.
• Clustering: group similar text together.
• Recommendations: suggest items with related text.
• Anomaly detection: find outliers with little relatedness to the rest.
• Diversity measurement: analyze how similar items in a set are.
• Classification: label text by the label it is most similar to.

Google's docs add RAG, search reranking and information retrieval to that list. For developers building on LLMs, retrieval is the use that comes up most: embed your documents once, embed each question as it arrives, and pull the closest passages into the model's prompt.

How do you compare two embeddings?

You measure the distance or angle between vectors. The three common measures are cosine similarity, dot product and Euclidean distance.

OpenAI recommends cosine similarity and notes that the choice usually matters little. Its embeddings are normalized to length 1, which means cosine similarity can be computed with a plain dot product, and cosine similarity and Euclidean distance give the same ranking. Anthropic's guide says the same about Voyage AI embeddings.

Here is a minimal semantic search in Python with the OpenAI SDK and NumPy:

from openai import OpenAI
import numpy as np

client = OpenAI()

docs = [
    "To reset your password, open Settings and choose Security.",
    "Invoices are emailed on the first day of each month.",
    "Our API rate limit is applied per key.",
]

def embed(texts):
    resp = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in resp.data])

doc_vecs = embed(docs)
query_vec = embed(["I forgot my login credentials"])[0]

# Vectors are normalized, so the dot product equals cosine similarity
scores = doc_vecs @ query_vec
print(docs[int(np.argmax(scores))])

For a handful of documents, a NumPy array is enough. For thousands or millions, you store vectors in a vector index or a database with vector search and let it find nearest neighbors quickly.

Which embedding models can you use?

The three big model vendors take different paths. OpenAI and Google offer their own embedding models. Anthropic does not: its guide says "Anthropic does not offer its own embedding model" and walks through Voyage AI by MongoDB as one provider, while advising you to assess several vendors.

Figures below come from each vendor's docs, read in October 2026:

Voyage AI also lists domain models for law and finance, a multimodal model, and contextualized chunk models that embed each chunk with the context of its whole document. OpenAI prices embeddings per input token; check each vendor's pricing page for current rates.

How do you choose dimensions and settings?

Three settings matter more than people expect.

Dimensions. Bigger vectors can hold more detail but cost more to store and search. OpenAI lets you pass dimensions to get a shorter vector "without the embedding losing its concept-representing properties," and says that if you shorten a vector yourself you must normalize it again. Gemini offers output_dimensionality and recommends 768, 1,536 or 3,072. Voyage AI models that support multiple output dimensions produce what Anthropic's guide calls Matryoshka embeddings: pass output_dimension, or truncate stored vectors to their leading dimensions and normalize them again.

Query versus document. Retrieval works better when the model knows which side of the search an input is on. Voyage AI uses input_type="query" or "document", and Anthropic's guide says not to omit it for retrieval. gemini-embedding-001 uses a task_type such as RETRIEVAL_QUERY or RETRIEVAL_DOCUMENT, while gemini-embedding-2 uses a text prefix instead.

Normalization. If your vectors are not normalized, cosine similarity and dot product give different rankings. Google notes that gemini-embedding-001 needs manual normalization for any size other than 3,072.

How do embeddings fit into RAG?

In a typical RAG pipeline you split documents into chunks, embed each chunk, store the vectors, and at question time embed the query and fetch the nearest chunks into the prompt. Our guide to what RAG is walks through the full loop.

Embeddings alone are not always enough. Anthropic's Contextual Retrieval post (September 2024) notes: "While embedding models excel at capturing semantic relationships, they can miss crucial exact matches." An error code like TS-999 or a function name is exactly the kind of thing semantic search can blur. The post pairs embeddings with BM25, "a ranking function that uses lexical matching to find precise word or phrase matches," and reports that its contextual method "can reduce the number of failed retrievals by 49% and, when combined with reranking, by 67%."

The same post points out that if your knowledge base is smaller than 200,000 tokens, about 500 pages, you can often skip retrieval and put the whole thing in the prompt. Our guide on LLM tokens helps you estimate that size.

What are the limits of embeddings?

Plan for these before you build:

• Exact terms get blurred. IDs, version numbers and rare names may not retrieve well by meaning alone. Hybrid search with keyword matching helps.
• Indexes go stale. When a document changes, its vectors must be regenerated, or retrieval returns old text.
• Model lock-in. Changing models means re-embedding the whole corpus, so record the model name and dimensions next to every vector.
• Data leaves your system. Hosted embedding APIs receive the full text you embed. Check the provider's data policy, or use an open-weight model you run yourself; Anthropic's guide lists voyage-4-nano as an Apache 2.0 open-weight option.
• Similar is not the same as correct. The nearest chunk can still be the wrong one, and the model may then answer confidently from it. See AI hallucinations for how grounding and citations reduce that risk.

Where should your retrieval prompts live?

The prompt that turns retrieved chunks into an answer is as important as the vectors. Good ones tell the model to answer only from the provided passages, quote its sources, and say when the passages do not contain the answer. Kipt keeps prompts like that as Markdown in a private GitHub repo you own, with fill-in blanks for the question and the retrieved context, so the version that works is easy to find and reuse.

What should you read next?

Read what is RAG to see embeddings inside a full retrieval pipeline, then fine-tuning vs RAG to decide whether retrieval or training fits your problem. For managing what ends up in the model's window, see context engineering.