Embedding — What They Are and How They Power Modern AI | AI Terms Guide
Category: RetrievalDifficulty: BeginnerFirst widely used: 2013 (Word2Vec)Last updated: Aug 6, 2026

Embedding (dense vector representation)

An embedding is a dense vector representation of data — text, an image, a piece of code — where semantic similarity between items corresponds to geometric closeness between their vectors.
Embeddings turn meaning into math. Two sentences with similar meaning produce similar vectors, even if they share no words. This property makes embeddings the foundation of semantic search, RAG, recommendation systems, clustering, classification, and anywhere you need to compare content by meaning rather than exact text.

At a glance

Also known as
Vector Embedding, Dense Embedding
Category
Representation
First widely used
2013 (Word2Vec)
Difficulty
Beginner

Definition

An embedding is a dense vector — a list of numbers, typically 384 to 3072 dimensions long — that represents a piece of data in a way that captures its semantic meaning. Text embeddings represent sentences or documents; image embeddings represent images; multimodal embeddings can represent both in a shared space. The key property: items with similar meaning produce similar vectors, regardless of surface differences.

You compute similarity between embeddings using distance metrics — most commonly cosine similarity or dot product for normalized vectors. A cosine similarity of 1.0 means identical direction (same meaning); 0.0 means unrelated; -1.0 means opposite. In practice, most useful pairs sit in the 0.3 to 0.9 range.

Embeddings came into their own with Word2Vec in 2013, which showed that word meaning could be captured in dense vectors trained via a simple prediction objective. The famous demonstration: king - man + woman ≈ queen. Vector arithmetic on semantic space. Modern embedding models (OpenAI text-embedding-3, Cohere embed-v3, BGE, E5) generalize this to sentences and documents, using contrastive training on massive pairs of semantically related text.

Embeddings are the substrate of the entire modern retrieval-augmented AI stack. When you build a RAG system, you embed your documents at indexing time and queries at retrieval time, finding matches by vector similarity. When ChatGPT does 'memory' or when Claude has Projects, embeddings power the retrieval underneath. When you upload PDFs to any AI product and ask questions, embeddings are involved.

Real-world example

Why embeddings work — a concrete demonstration

Consider three sentences: 'The cat sat on the mat.', 'A feline rested on the rug.', and 'Docker containers are lightweight.'. To a keyword search, sentences 1 and 3 share more words with a query like 'What did the cat do?' than sentence 2 does (which shares zero words). But an embedding model produces vectors where sentence 2 is close to sentence 1 (both about a cat resting on fabric) and sentence 3 is far away. Cosine similarity turns semantic meaning into a number — and that number drives everything from RAG retrieval to recommendation systems.

PYTHON
# Computing embeddings with the OpenAI API
from openai import OpenAI

client = OpenAI()

def embed(text: str) -> list[float]:
    """Return the embedding vector for a piece of text."""
    response = client.embeddings.create(
        input=text,
        model="text-embedding-3-large",
    )
    return response.data[0].embedding

# Compute embeddings for three sentences
e1 = embed("The cat sat on the mat.")
e2 = embed("A feline rested on the rug.")
e3 = embed("Docker containers are lightweight.")

# Compute cosine similarity
import numpy as np

def cosine_sim(a, b):
    a, b = np.array(a), np.array(b)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

print(cosine_sim(e1, e2))  # ~0.65 — semantically similar
print(cosine_sim(e1, e3))  # ~0.10 — unrelated
print(cosine_sim(e2, e3))  # ~0.11 — unrelated

# For 100K+ documents, you'd store vectors in a
# vector database (Pinecone, Weaviate, Qdrant, pgvector)
# and use ANN indexes (HNSW, IVF) for fast retrieval.
Notice: Different embedding models produce different vectors. When you switch models, you must re-embed everything — you can't mix vectors from different models. Choose your embedding model carefully; migrating is expensive.

When you'll encounter this

  • You're building semantic search — the reference use case for embeddings.
  • You're building a RAG system — embeddings are how the retrieval half works.
  • You need to cluster or categorize documents — embeddings + clustering algorithms (k-means, HDBSCAN) group similar content.
  • You're building a recommendation system — user and item embeddings capture preference and content in the same space.
  • You need deduplication or near-duplicate detection — high similarity between embeddings often means duplicates even with surface differences.

How it works

1

Training the embedding model

Modern embedding models are trained on pairs of semantically related text — question-answer pairs, translations, paraphrases — using contrastive learning. Positive pairs are pushed together in vector space; negative pairs are pushed apart.

2

Encoding input text

Text is tokenized, passed through a transformer encoder (usually BERT-style), and the hidden states are pooled — typically mean-pooled or using the [CLS] token — to produce a single vector.

3

Normalization

Most embedding models produce L2-normalized vectors (unit length). This makes dot product equivalent to cosine similarity — computationally faster.

4

Storing at scale

For small collections (<10K), a Python list of vectors and numpy computations work fine. For larger collections, you need a vector database with an approximate nearest neighbor index.

5

Approximate nearest neighbors

For large collections, exact similarity search is too slow. Indexes like HNSW and IVF trade a tiny amount of recall for orders-of-magnitude speedup.

6

Retrieval

Given a query, embed it with the same model, then use the vector database to find the top-k most similar vectors. This is the foundation of every modern retrieval system.

7

Reranking (optional)

Because ANN is approximate and similarity is a coarse signal, retrieved candidates are often passed through a reranker — a cross-encoder that scores query-document pairs more precisely.

Common misconceptions

Misconception #1: Higher-dimensional embeddings are always better.
Diminishing returns. text-embedding-3-large's 3072 dimensions perform better than the 1536-dim version, but the gap is small on many tasks. Higher dimensions cost more storage, compute, and money. Many production systems use 384-1024 dim embeddings and are perfectly happy.
Misconception #2: You can mix vectors from different embedding models.
You cannot. Different models produce vectors in different spaces — even if dimensions match, cosine similarity between vectors from different models is meaningless. Always encode queries with the same model used for indexing.
Misconception #3: Embeddings understand meaning perfectly.
They capture a lot but miss things. Negation is famously hard ('not happy' can embed close to 'happy'). Rare terminology, novel concepts, and highly specialized domains often need domain-specific embeddings or fine-tuning to reach production quality.

Where you'll see this in practice

Learn more

Sources & further reading

  1. Efficient Estimation of Word Representations in Vector Space — Mikolov et al., 2013 (Word2Vec). Read →
  2. Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks — Reimers & Gurevych, 2019. Read →
  3. Text and Code Embeddings by Contrastive Pre-Training — Neelakantan et al., 2022 (OpenAI embeddings). Read →
  4. MTEB: Massive Text Embedding Benchmark — Muennighoff et al., 2023. Read →
FAQ

Frequently asked about Embedding

For English general-purpose: OpenAI text-embedding-3-large is a strong default. For multilingual: Cohere embed-v3 or BGE-M3. For self-hosting: BGE, E5, or Nomic. For latest options, check the MTEB leaderboard. Model choice is usually less impactful than chunking strategy in a RAG system.

Match your embedding model — OpenAI's text-embedding-3-large is 3072 dims, but supports truncation to smaller sizes. 768-1024 is a common sweet spot for cost and quality. 256-384 is enough for many simple use cases. Higher dims cost more storage and compute in the vector database.

Use a multimodal model — CLIP (OpenAI), SigLIP (Google), or JinaCLIP. These produce vectors in a shared image-text space, letting you find images by text query or vice versa. Multimodal embedding is central to modern search-over-images products.

Yes. Fine-tuning an embedding model on your domain (legal, medical, code) can meaningfully improve retrieval quality. Tools like Sentence-Transformers make this straightforward — you need pairs of related and unrelated text from your domain.

No — that's what BM25 is for. Embeddings excel at semantic similarity but can miss exact-match cases where terminology is precise (product SKUs, medical codes, legal citations). Hybrid search combining both is standard in production.

Share with