What is a vector embedding? A practical guide

If you’ve worked with vector databases, RAG pipelines, or semantic search, you’ve encountered vector embeddings. But what exactly are they, and why do they work so well for search?

What is a vector embedding?

A vector embedding is a list of floating-point numbers — a vector in a high-dimensional space — that represents the semantic meaning of a piece of data. Text, images, audio, code, and even molecular structures can be embedded into vectors.

The key property of embeddings is that semantically similar items end up close together in the vector space. A document about machine learning and a document about neural networks will have embeddings that are close in distance, even if they share no words.

# Example: two similar sentences have similar embeddings
import openai

client = openai.OpenAI()

sentences = [
    "The cat sat on the mat.",
    "A feline rested on the rug.",
    "The stock market fell 3% today.",
]

embeddings = [
    client.embeddings.create(input=s, model="text-embedding-3-small").data[0].embedding
    for s in sentences
]

# embeddings[0] and embeddings[1] will be much closer than either is to embeddings[2]

How are embeddings generated?

Embeddings are produced by neural networks trained to capture semantic relationships. The most common approach for text is a transformer model fine-tuned with contrastive learning: pairs of similar sentences are trained to produce similar vectors, and dissimilar pairs are trained to produce distant vectors.

Modern text embedding models include:

• OpenAI text-embedding-3-small / text-embedding-3-large — general-purpose, strong performance across domains
• Cohere embed-english-v3.0 — competitive performance, supports int8 quantization
• sentence-transformers/all-MiniLM-L6-v2 — open-source, fast, 384 dimensions
• BAAI/bge-large-en-v1.5 — open-source, strong retrieval performance
• intfloat/multilingual-e5-large — multilingual support across 94 languages

Understanding dimensions

The output of an embedding model is a vector of fixed length called the dimension. Typical ranges:

Model	Dimensions	Use case
all-MiniLM-L6-v2	384	Fast, low-cost, decent quality
text-embedding-3-small	1536	Good balance of cost and quality
text-embedding-3-large	3072	Best quality, higher cost
bge-large-en-v1.5	1024	Strong open-source option

Higher dimensions generally correlate with higher quality (more expressive representations) but also higher storage cost, higher query latency, and higher embedding API cost.

Distance metrics

The distance between two embeddings measures how similar they are. Common metrics:

Cosine similarity

Measures the angle between two vectors, ignoring their magnitude. Most embedding models are designed for cosine similarity, and their output vectors are often normalized (unit length) so that cosine similarity equals dot product.

cosine_similarity(A, B) = (A · B) / (|A| × |B|)

Range: -1 (opposite) to 1 (identical). Higher is more similar.

Dot product

The unnormalized version of cosine similarity. Faster to compute but sensitive to vector magnitude, so it works best with normalized embeddings or models that explicitly target dot product.

Euclidean distance (L2)

Measures the straight-line distance between two points in the embedding space. Less common for text embeddings but used in some computer vision and scientific applications.

Why embeddings work for search

Traditional keyword search (BM25, TF-IDF) matches exact terms. If someone searches “automobile” and your document says “car,” keyword search returns nothing. Embeddings solve this because “automobile” and “car” produce similar embeddings — they occupy nearby points in the vector space.

This enables:

• Synonym matching: “physician” finds “doctor”
• Paraphrase retrieval: “how do I cancel?” finds “account termination process”
• Cross-language retrieval: English query finds French documents (with multilingual models)
• Zero-shot domain transfer: embedding models generalize across domains

Choosing an embedding model

Key factors to consider:

Quality vs. cost tradeoff. Better models cost more per embedding (API cost) and produce larger vectors (storage cost). Start with text-embedding-3-small or all-MiniLM-L6-v2 and upgrade if recall benchmarks are insufficient.

Latency. Self-hosted models like MiniLM can be run locally with sub-millisecond embedding latency. API-based models add network round-trip time.

Dimensionality. Larger dimensions require more storage and slower ANN traversal. 1536 dimensions is a practical default for most production RAG workloads.

Domain specificity. General models work well across domains. For specialized corpora (biomedical, legal, financial), consider domain-specific models fine-tuned on in-domain text.

Multilingual support. If your corpus spans multiple languages, use a model like multilingual-e5 rather than an English-only model.

Embedding consistency: the critical rule

All vectors in a namespace must be generated with the same model. Embeddings from different models live in different geometric spaces — they are not comparable. Searching across mixed-model vectors will produce incorrect results.

If you need to switch embedding models, ManyVector’s namespace branching lets you fork your production namespace, re-embed the entire corpus with the new model, benchmark recall, and promote atomically — without any downtime.

What gets embedded?

Different data types require different model families:

Data type	Model family	Example
Text	Text transformers	OpenAI, Cohere, sentence-transformers
Images	Vision transformers	CLIP, SigLIP, DINOv2
Audio	Audio transformers	Wav2Vec, Whisper embeddings
Code	Code models	CodeBERT, codeT5+
Multimodal	CLIP-style	text and image in same space

ManyVector stores any vector — regardless of what it was embedded from.

Next steps

• Upsert your first vectors with the getting started guide
• Learn about hybrid search to combine embeddings with BM25 for better recall
• Understand namespace branching for safe embedding model upgrades