Embeddings deep dive

From word vectors to sentence vectors

word2vec gave every word a fixed vector (6.3 Word embeddings); BERT gave every token a vector that depends on its sentence (7.5 Encoder-only: BERT and friends (and sentence embeddings)). A retriever needs one vector per chunk that captures what it is about. The naive approach — average BERT's token vectors or take its [CLS] vector — works badly: raw BERT embeddings are anisotropic (they crowd into a narrow cone, so every pair looks similar), and nothing in masked-language-model pretraining ever asked "do these two texts mean the same thing?". Sentence-BERT (2019) fixed this by fine-tuning with a contrastive objective on pairs of texts that should be close. Every modern embedding model — the E5, BGE and GTE families, and the API models from OpenAI, Voyage, Cohere and Google — follows the same recipe: a transformer encoder, a pooling step (mean pooling or a [CLS]/last-token vector), and contrastive training on hundreds of millions of pairs, often with an instruction prefix such as query: or passage: so the model knows which side of the retrieval it is encoding.

Bi-encoders, cross-encoders and late interaction

A bi-encoder encodes query and document independently: $\mathbf{q} = f(\text{query})$, $\mathbf{d}_i = f(\text{doc}_i)$, score $= \mathbf{q}\cdot\mathbf{d}_i$. Because the document vectors do not depend on the query, you compute them once offline and search them with a vector index (9.3 Vector search and indexes); a query costs one forward pass plus a nearest-neighbour lookup. A cross-encoder feeds the pair [CLS] query [SEP] document through the transformer and outputs a relevance score. Query and document tokens attend to each other, so it is far more accurate — but there is nothing to precompute: scoring $N$ documents costs $N$ forward passes. The standard design therefore uses the bi-encoder to fetch 50–200 candidates and a cross-encoder to rerank them (9.5 Retrieval quality: hybrid search, reranking, query transforms and metrics). Late interaction (ColBERT) sits between: it stores one vector per token for each document and scores with $\sum_i \max_j \mathbf{q}_i\cdot\mathbf{d}_j$, keeping much of the cross-encoder's precision while remaining indexable.

Training embeddings: InfoNCE with in-batch negatives

Take a batch of $B$ positive pairs $(q_i, d_i^+)$ — a question and the passage that answers it, a title and its article, two paraphrases. Encode everything, normalize, and define similarities $s_{ij} = \mathbf{q}_i\cdot\mathbf{d}_j / \tau$ with a temperature $\tau$. The loss treats the other $B-1$ documents in the batch as negatives:

This is a softmax cross-entropy (4.3 Loss functions catalog) over the question "which document in the batch belongs to query $i$?": it pulls $\mathbf{q}_i$ toward $\mathbf{d}_i^+$ and pushes it away from everything else. It is exactly the InfoNCE loss of SimCLR (5.8 Self-supervised and contrastive learning), and its symmetric version (also classifying documents against queries) is CLIP's objective (8.10 Multimodal models). Three practical consequences:

• Bigger batches are better. More in-batch negatives make the task harder and the embedding sharper; embedding models are trained with batches in the thousands or tens of thousands.
• Hard negatives matter. Random passages are too easy. Mine negatives that BM25 or a previous model ranks highly but that are wrong; most of the quality gap between models comes from data curation here.
• Temperature sharpens. With $\tau \approx 0.01$–$0.05$ a small difference in cosine becomes a large difference in probability, which trains fine-grained ranking.

Math check. With $B=2$, cosines $0.2$ (positive) and $0.1$ (negative) and $\tau=0.01$, the logits are $20$ and $10$ and query 1's loss is $-\log\frac{e^{20}}{e^{20}+e^{10}} = \log(1+e^{-10}) \approx 4.5\times10^{-5}$ — already solved. At $\tau = 1$ the same cosines give $\log(1+e^{-0.1}) \approx 0.64$: without a low temperature the loss barely distinguishes 0.2 from 0.1.

Cosine, dot product or Euclidean?

Three similarity measures are in common use, and for unit vectors they rank documents identically. If $\|\mathbf{a}\| = \|\mathbf{b}\| = 1$,

so the smallest Euclidean distance is the largest dot product is the largest cosine (1.1 Vectors, dot products and norms). Most APIs return normalized vectors, which is why "cosine" and "dot" indexes give the same results. The exception is deliberate: some models are trained with unnormalized dot products so that vector length can encode prior importance — a popular, information-dense passage gets a longer vector. Use the metric the model card specifies, and never mix normalized and unnormalized vectors in one index.

Dimension, Matryoshka and quantization

Dimension $d$ ranges from 384 (MiniLM) to 1,024–3,072 and beyond. Storage is $d \times 4$ bytes in float32: one million 1,024-dimensional vectors is about 4 GB before index overhead (9.3 Vector search and indexes). Two tricks shrink that. Matryoshka representation learning trains the model so that any prefix of the vector — the first 256 of 1,024 dimensions, say — is itself a good embedding; you truncate at query time and trade a little recall for four times less memory and faster search. Quantization stores int8 (4× smaller) or binary (32× smaller) vectors, and rescoring the top candidates with full-precision vectors recovers most of the lost accuracy.

Choosing an embedding model in 2026

The MTEB benchmark aggregates retrieval, clustering, classification and semantic-similarity tasks across many languages. Use it to shortlist, not to decide: leaderboard scores are averages over domains that are not yours, some entries overfit to the public tasks, and the cost, latency, context-length and dimension columns matter as much as the score. The procedure that works:

1. Build a small retrieval test set from your documents — 50–200 queries with labelled relevant chunks (9.5 Retrieval quality: hybrid search, reranking, query transforms and metrics).
2. Compare two or three candidates (a small open model you can self-host, a strong open model, an API model) on recall@$k$ and nDCG, plus embedding latency, price per million tokens, maximum input length and dimension.
3. Check language coverage (multilingual models for non-English corpora) and whether the model expects asymmetric query/passage prefixes or instructions.
4. If the domain is unusual (legal, chemistry, internal jargon), fine-tune the open model on synthetic query–passage pairs generated by an LLM from your chunks; a few thousand pairs already help.

Multimodal retrieval follows the same geometry: CLIP-style models embed images and text in one space (8.10 Multimodal models), and page-image models embed whole PDF pages so you can retrieve a slide by its content without OCR (9.7 Advanced RAG patterns).

Where this shows up later

• Searching millions of vectors quickly is the job of an index — 9.3 Vector search and indexes; the chunks you embed come from 9.4 Chunking and ingestion.
• Cross-encoder reranking and hybrid search build on the bi-/cross-encoder distinction — 9.5 Retrieval quality: hybrid search, reranking, query transforms and metrics.
• The same contrastive loss trained SimCLR (5.8 Self-supervised and contrastive learning) and CLIP (8.10 Multimodal models); agent memory stores embeddings of past events — 10.4 Memory and context engineering.