Multilingual legal corpus spanning English, French, Spanish, and Mandarin documents
Highly specialized biomedical corpus with technical jargon not seen in general training data
Corpus of long-form legal contracts where individual clauses run 4K+ tokens
Mobile / on-device retrieval where the index has to fit in <500MB of RAM
Hard P99 latency target of 30ms per embedding call at 10K QPS
Greenfield English-language enterprise search with no labeled eval data yet and a tight launch deadline
Choosing an embedding model is not about finding the single best one. It's about finding the one that solves your specific deployment constraint.
Most teams reach for the top MTEB model out of habit. MTEB ranks general purpose retrieval on English benchmarks. If your corpus is English, general purpose, and short, MTEB rank is fine as a default. If any of those three break, MTEB rank is misleading.
The six scenarios in this question name the most common breaks. Multilingual corpora need a model trained on those languages. Specialized domains like biomedical text need a model that has seen the jargon. Long clauses need a model whose input length covers them. On-device deployments need small vectors. Strict latency targets need a fast model or local hosting. Greenfield English projects with no eval data are the one case where the MTEB default is actually correct, until you have eval data to verify.
Name the dominant constraint first. Then pick the model.
Embedding model selection is a constraint resolution problem, not a leaderboard lookup. Each deployment has exactly one dominant constraint, and naming it correctly is most of the work.
**The six common constraints** map cleanly to six scenarios. Multilingual corpora demand a model trained on all the target languages: BGE-M3, Cohere Embed v4 multilingual, or Voyage Embed v3 multilingual. Highly specialized domains demand domain trained or fine-tuned models: BioBERT-derived or MedCPT for biomedical, or fine-tuning a base model on in-domain pairs. Long documents demand a model whose max input covers them: Voyage Embed v3 and Cohere Embed v4 reach 32K tokens, while many older models cap at 512.
Operational constraints reshape the choice further. On-device deployments care about vector dimension (smaller dim equals smaller index); text-embedding-3-large supports Matryoshka truncation to 256 dim. Strict P99 latency demands self-hosted small models or ONNX-quantized local inference. Greenfield projects with no eval data are the one place MTEB rank is the right default, with a planned re-evaluation once eval data exists.
The wrong move is to always pick the top MTEB model. MTEB is an English general purpose benchmark; your corpus may match none of those assumptions.
Quick reference
TL;DR
No universal best embedding model. Each deployment has one dominant constraint: language coverage, domain fit, input length, dimension, latency, or off the shelf strength. Pick the model that resolves it.
Imagine choosing a translator for a job. If the documents are in four languages, you hire someone who actually speaks all four, not the smartest English-only translator in town. If the documents are medical reports full of jargon, you hire someone trained in medicine, not a generalist with more credentials. If each document is the size of a novel, you need someone with the stamina to read the whole thing before summarizing, not someone who can only handle short notes. If you need ten thousand translations per second, you build a small fast team rather than calling one expensive consultant. Picking the right text to numbers model is the same. Each scenario has one constraint that dominates everything else, and the trick is naming that constraint before evaluating candidates.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Corpus and queries are entirely English general purpose web style text An MTEB-leading general purpose model is genuinely the right default; domain or multilingual specialization is unnecessary overhead.
You already have a labeled retrieval eval set Skip leaderboards and run head to head retrieval on your own eval. Leaderboards generalize across corpora; your eval is your corpus.
Tiny corpus where keyword search already meets quality bar Embedding overhead is unjustified at small scale; BM25 or simple lexical search is often enough and avoids embedding-model selection entirely.
Quick scan · 2–4 min
Everything important, quickly.
3 min: enumerate the six constraints, name 2026 reference models for each, explain why MTEB rank alone is the wrong selector for non-English or non-general corpora, and describe how an in-house eval replaces the default.
Code example
python
# Six-constraint selector for embedding models in a RAG project.
# Name the dominant constraint, then pick.
def pick_embedding_model(corpus_profile, ops_profile):
langs = corpus_profile.languages # e.g. {'en', 'fr', 'es', 'zh'}
domain = corpus_profile.domain # 'general' | 'biomed' | 'legal' | 'code'
max_tokens = corpus_profile.max_doc_tokens
dim_budget = ops_profile.max_dim # None or int
p99_ms = ops_profile.p99_latency_ms
if len(langs) > 1:
return "voyage-embed-v3-multilingual" # or Cohere Embed v4 multilingual, BGE-M3
if domain in ("biomed", "legal", "finance"):
return f"fine-tuned-{domain}-embed" # or domain pretrained
if max_tokens > 8000:
return "voyage-embed-v3" # 32K input; Cohere Embed v4 alt
if dim_budget and dim_budget < 512:
return "text-embedding-3-large@256" # Matryoshka truncate
if p99_ms < 50:
return "self hosted bge small onnx" # local, no network hop
return "text-embedding-3-large" # safe MTEB default
Real products, models, and research that use this idea.
1Cohere Embed v4 (multilingual, 32K input) and Voyage Embed v3 (multilingual variant, 32K input) are the 2026 references for cross-lingual retrieval in enterprise RAG.
2OpenAI text-embedding-3-large supports Matryoshka representation learning: a 3072-dim vector can be truncated to 256 dim with graceful quality loss, ideal for on-device indexes.
3BGE-M3 from BAAI is the leading open weight multilingual embedding model and a common self-hosted choice when API cost or data residency rules out hosted providers.
4MedCPT and BioBERT-derived embeddings are standard for biomedical RAG; general models lose to domain tuned models on PubMed-style retrieval benchmarks.
5pgvector, Pinecone, Qdrant, and Weaviate all expose dimension as an index creation parameter; shrinking from 3072 to 768 cuts index memory by roughly 4x.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QYou ran MTEB and your in-house eval and they disagree on the top model. Which do you trust?
Sign in or go Pro to see the approach for this follow-up.
QHow would you decide between hosted (OpenAI, Cohere, Voyage) and self-hosted (BGE, GTE) embedding models?
Sign in or go Pro to see the approach for this follow-up.
QWalk me through fine-tuning a base embedding model on your domain. What data and loss function?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Picking the top MTEB model without checking whether your corpus matches the benchmark's languages, domain, or input length distribution. MTEB rank is a default, not a decision.