Best Embedding Models in 2026: How to Actually Choose

The question is wrong, and that is why the answers are bad

"What is the best embedding model" has no answer, in the same way "what is the best database" has no answer. An embedding model is a function that maps your text into a space where similar things end up close together, and whether it does that well depends entirely on what your text is. A model trained mostly on general web prose will do a mediocre job on Albanian legal filings or on a codebase, and no leaderboard position changes that.

So this post is not a ranked list. It is the four decisions that actually determine your choice, in the order they matter, followed by how to settle the remaining question with a measurement rather than an opinion.

Decision 1: API or self-hosted

This is the decision that eliminates most of the field, so make it first. A hosted API means you call an endpoint and never think about GPUs; a self-hosted open model means you own the serving, the scaling, and the pager. Two factors decide it.

Volume. Below roughly a few million embeddings a month, the API wins on total cost once you count engineering time honestly. You are paying a trivial per-token rate rather than paying for a GPU that is idle most of the day plus someone to keep it running. Above that threshold the arithmetic flips, and it flips hard, because your API bill scales linearly while a GPU you already own does not.

Sovereignty. If the text cannot leave your infrastructure, the decision is already made and volume is irrelevant. This comes up constantly in European work, and it is why I end up deploying BGE-M3 on client infrastructure more often than the benchmark tables would suggest. It is also the core of my self-hosted LLM work.

Decision 2: what is actually in your corpus

The shape of your data narrows the field faster than any benchmark. Four cases cover almost everything I see.

That last row deserves emphasis, because it is the case where the model choice removes an entire subsystem rather than shifting a benchmark number. If your documents are scanned or slide-based, a multimodal embedding model lets you skip OCR and layout parsing, and that is worth more than a few points of retrieval accuracy.

Decision 3: dimensions, and the mistake everyone makes

Embedding dimensions determine storage and search cost, not model quality. A 3072-dimension vector takes twice the space of a 1536-dimension one and makes every similarity comparison proportionally more expensive, but it is not twice as good and may not be better at all. I have watched teams pick the larger variant on the assumption that bigger is better, then discover that their vector database bill tripled for a difference in recall they could not measure.

Several current models support Matryoshka representation learning, which means the vector is trained so that its first N dimensions are themselves a usable embedding. That lets you truncate after the fact, trading a small, measurable amount of quality for a large reduction in index size, without re-embedding anything. If your index cost is becoming a problem, check whether your model supports this before you migrate to a different one.

Decision 4: how to actually benchmark, in an afternoon

Once the first three decisions leave you with two or three candidates, stop reading and measure. This takes about half a day and it is the only part of the process that produces a defensible answer.

1. Collect 50 real queries. Not queries you invented, queries your users actually typed, or the closest thing you have. If the product is not live, write them by asking the people who will use it rather than by imagining them.
2. Label the right answer for each. For every query, identify which document or chunk should be the top result. This is the tedious part and there is no way around it. Fifty labelled pairs is enough to separate candidate models; five is not.
3. Embed your corpus once per candidate model. Keep the chunking identical across candidates, otherwise you are measuring your chunking strategy rather than the model.
4. Measure recall at 5, 20 and 50. Recall at 50 tells you whether the model can find the document at all. Recall at 5 tells you whether it ranks it usefully. The gap between them tells you whether you need a reranker rather than a different model, which is the single most valuable number this exercise produces.
5. Only then compare cost and latency. If two models are within a point or two of each other on recall, pick the cheaper or simpler one. Marginal benchmark differences do not survive contact with production.

The framework for this is the same one I use for any model decision, and it generalises: see building an LLM evaluation framework for the broader version.

Head-to-head comparisons

If your shortlist has come down to a specific pair, these go deeper than this page does:

• BGE-M3 vs OpenAI embeddings - open and self-hosted against the default API, including BGE-M3's hybrid dense-sparse-multivector output.
• Voyage vs OpenAI embeddings - when domain-tuned retrieval quality is worth leaving the default.
• Cohere Embed v4 vs OpenAI text-embedding-3 - multimodal, Matryoshka dimensions, and VPC deployment.
• The original embedding models comparison - the broader survey this cluster grew out of.

What I would pick, if you forced me

Stated plainly, because refusing to answer is its own kind of unhelpful. For a new English-language RAG system at moderate volume, I start with OpenAI text-embedding-3-small, spend the saved effort on chunking and on adding a reranker, and revisit the model only if the benchmark says it is the bottleneck. That is the default I reach for on most AI integration work, and it is right often enough that I would need a specific reason to deviate.

The reasons to deviate are the ones above: a multilingual corpus, a specialised domain, documents that are really images, volume past a few million embeddings a month, or data that legally cannot leave your infrastructure. If none of those apply, the model is not your problem and you should stop optimising it.

Frequently asked questions

What is the best embedding model in 2026?

There is no single best one. Open models such as Qwen3-Embedding lead MTEB but must be self-hosted. Among APIs, OpenAI text-embedding-3-small is the sensible English default, Voyage leads on specialised corpora, and Cohere Embed v4 leads on multimodal and multilingual. The right answer is whichever wins on fifty of your own labelled queries.

Do MTEB scores predict performance on my data?

Loosely, and less so the further your corpus is from general web text. Use the leaderboard to build a shortlist, then measure recall at k on your own queries to decide.

API or self-hosted?

API below a few million embeddings a month; self-hosted above that, or whenever data residency means the text cannot leave your infrastructure. The sovereignty argument settles it on its own.

Do more dimensions mean better retrieval?

No. Dimensions set storage and search cost, not quality. Check whether your model supports Matryoshka truncation before migrating to shrink an expensive index.

Will a better model fix bad RAG results?

Usually not. Measure recall at 50 first. If it is high, retrieval works and your ranking is the problem, which a reranker fixes far more cheaply than a model migration.

Bottom line

Pick on deployment constraints and corpus shape, shortlist two or three, measure recall at k on your own labelled queries, and take the cheaper one when the difference is marginal. The leaderboard is a starting point for a shortlist and nothing more, and the afternoon you spend labelling fifty queries will tell you more than every comparison article on the internet, including this one.