Choosing an Embedding Model
Selecting, benchmarking, and fine-tuning dense embedding models for high-precision semantic search and RAG.
Choosing an Embedding Model determines vector retrieval precision, index storage footprint, and latency in RAG pipelines. Selection criteria include vector dimensionality (e.g. 384-d vs 1536-d vs Matryoshka Flexible Embeddings), MTEB Benchmark rankings (Massive Text Embedding Benchmark), domain adaptation (general vs code vs medical), and Symmetric vs Asymmetric search (matching short queries against long documents).
Key Decision Criteria Matrix
EMBEDDING SELECTION MATRIX
┌──────────────────────────┬──────────────────────────┬──────────────────────────┬──────────────────────────┐
│ 1. EMBEDDING DIMENSION │ 2. CONTEXT LENGTH │ 3. DOMAIN SPECIALIZATION │ 4. DEPLOYMENT (HOST/API) │
├──────────────────────────┼──────────────────────────┼──────────────────────────┼──────────────────────────┤
│ 384-d (MiniLM) │ 512 tokens (SBERT) │ General Text (bge, gte) │ Commercial API (OpenAI) │
│ 1536-d (OpenAI v3) │ 8192 tokens (nomic-embed)│ Code (jina-embeddings) │ Self-Hosted Open-Source │
│ Matryoshka (256d-1536d) │ │ Medical / Legal │ (bge-m3, nomic, E5) │
└──────────────────────────┴──────────────────────────┴──────────────────────────┴──────────────────────────┘
Top Embedding Models (MTEB Leaders)
| Model Name | Vector Dim | Max Tokens | Open Source? | Best Use Case |
|---|---|---|---|---|
text-embedding-3-large | 3072 (Matryoshka) | 8,191 | No (API) | Cloud enterprise RAG (Truncates to 256/512-d) |
bge-m3 (BAAI) | 1024 | 8,192 | Yes | Gold Standard Open Source (Multi-linguality + Dense + Sparse) |
nomic-embed-text-v1.5 | 768 (Matryoshka) | 8,192 | Yes | Fully open weights, long context |
gte-large-en-v1.5 | 1024 | 8,192 | Yes | High MTEB retrieval performance |
all-MiniLM-L6-v2 | 384 | 256 | Yes | Lightweight CPU-bound edge deployment |
Matryoshka Embeddings (MRL)
Named after Russian nesting dolls, Matryoshka Representation Learning trains models so that early vector dimensions capture macro semantic intent:
Full Vector [1536 dimensions] ──► High Recall, 100% Vector RAM Footprint
Truncated Vector [256 dims] ──► 96% Recall, 16.6% Vector RAM Footprint! (6x Memory Savings)
Say this out loud
"Selecting an embedding model requires evaluating MTEB benchmark retrieval scores, context window limits, and vector dimensionality. For cloud APIs, OpenAI text-embedding-3 supports Matryoshka truncation to 256 dimensions for 6x RAM savings. For self-hosted open-source RAG, bge-m3 and nomic-embed-text provide 8k context and multi-lingual density."
Follow-ups to expect
- What is bge-m3 Multi-Functionality?
bge-m3outputs three representations simultaneously from one forward pass: Dense Retrieval vectors, Lexical Sparse (learned BM25 weights) vectors, and Multi-Vector (ColBERT late interaction) embeddings. - How do you fine-tune embedding models on custom domain data? Use Multiple Negatives Ranking Loss (MNRL) over pairs of (Query, Positive Passage) with in-batch negatives, adapting pre-trained embeddings to specialized medical or legal vocabularies.
Check yourself
Question 1 of 3
What is the MTEB (Massive Text Embedding Benchmark) leaderboard used for when selecting embedding models?