Best embedding models for RAG in 2026
The choice is easy to reverse in a demo. In production, switching means re-embedding every document you have.
The short answer
Voyage-3-large scores highest on public retrieval benchmarks. OpenAI's text-embedding-3-large is the safer default when your team already uses OpenAI and wants one vendor, one bill.
Cohere's embed-v4 earns its spot on multilingual document sets that mix images and text. Open-weight models close most of the quality gap and drop the per-token bill, at the cost of hosting your own inference.
None of this matters as much as your chunking. A better model on badly split documents still loses to a mediocre model on well-split ones.
How this ranking was made
Verified
We ranked five embedding models on the Massive Text Embedding Benchmark, or MTEB. It is the public leaderboard the field uses to compare retrieval quality across models. We added published pricing and our own experience building retrieval on top of them.
MTEB scores were read from each vendor's own benchmark page on 14 August 2026. The public leaderboard mixes model versions and does not always show the newest release. Pricing came from each vendor's current pricing page on the same date.
We excluded models with no maintained hosted endpoint and no clear open-weight release. A model you cannot call in production or self-host is not a real choice for a RAG build.
- Retrieval quality
- MTEB retrieval score, not the overall average, since retrieval is the task a RAG pipeline actually runs.
- Price per million tokens
- What embedding your corpus, and re-embedding it, actually costs.
- Dimension and storage cost
- Higher dimensions mean better recall and a bigger, more expensive index.
- Re-embedding cost
- What it takes to leave. Embeddings from different models are not compatible, so switching means reprocessing every document.
The five at a glance
Pricing and dimensions read from vendor documentation on 14 August 2026.
| Model | Runs as | Max dimensions | Best moment to pick it |
|---|---|---|---|
| Voyage-3-large | Hosted API (Voyage, now part of MongoDB) | 1024, with shorter options via Matryoshka | Retrieval quality is the deciding factor |
| OpenAI text-embedding-3-large | Hosted API | 3072, reducible via dimensions parameter | You already build on OpenAI for generation |
| Cohere embed-v4 | Hosted API | 1536, with Matryoshka truncation | Multilingual or mixed image-and-text documents |
| BGE-large (BAAI) | Open weight, self-hosted | 1024 | You need to run inference inside your own network |
| GTE-large (Alibaba) | Open weight, self-hosted | 1024 | English retrieval on a fixed self-hosting budget |
The ranking
Order reflects retrieval quality first, then how many teams the trade-offs actually suit.
Highest general retrieval score of the hosted models
Voyage AI publishes benchmark results showing voyage-3-large beating OpenAI's and Cohere's general models on several public data sets. Pick this when retrieval quality is the thing your tests keep failing on.
It supports Matryoshka embeddings. You can truncate the vector to a smaller size and keep most of the quality, which trims storage without a full model swap. Voyage also ships models tuned for code, legal and finance documents. That matters if your corpus is domain-heavy rather than general text.
The cost is vendor risk on a smaller company than OpenAI or Cohere, now folded into MongoDB after its 2025 acquisition. Confirm the roadmap commitment before betting a large corpus on it.
Best for
- Teams whose evaluation shows retrieval, not generation, is the weak link
- Domain-heavy corpora where a specialised model (code, legal, finance) exists
Not for
- Teams that want the same vendor for embeddings and generation
- Anyone who needs a long, boring vendor track record before committing
- Runs as
- Hosted API
- Max dimensions
- 1024, truncatable
- Domain variants
- Code, legal, finance
The default when OpenAI already runs your generation
This is the model most teams reach for first, and for many the reasoning holds up. One vendor, one API key, one bill. Quality sits close enough to the leader that the gap rarely shows up in real tests.
OpenAI's docs support a dimensions setting that shortens the output vector while keeping most of the quality. It is the same trade Voyage offers under a different name. The default size is large, so storage grows fast on big corpora unless you set it lower.
A smaller version, text-embedding-3-small, exists for cost-sensitive workloads. It costs less per token and scores lower on retrieval benchmarks, so treat it as a deliberate trade, not a free downgrade.
Best for
- Teams already calling OpenAI for generation
- Products where operational simplicity beats a small quality edge
Not for
- Corpora where the retrieval gap against the leader shows up in evaluation
- Teams that need every byte kept off a US-based API
- Runs as
- Hosted API
- Max dimensions
- 3072, reducible
- Smaller variant
- text-embedding-3-small
Multilingual and mixed image-and-text retrieval
Cohere's embed-v4 puts text and images into the same vector space. It also works across more than 100 languages. That mix is narrow but real. Scanned contracts or captioned photos are a real case the general models do not target.
It also supports truncating the vector down from its full size. Cohere ships smaller versions built to cut storage cost, which matters once an index passes a few million entries.
For an English-only text set, those strengths pay for capability you will not use. Pick it for the specific problem it solves, not as a general default.
Best for
- Multilingual document sets across many languages
- Corpora mixing images and text in the same retrieval index
Not for
- English-only text corpora with no multimodal need
- Teams optimising purely for lowest cost per token
- Runs as
- Hosted API
- Modality
- Text and image, same vector space
- Languages
- 100+
Open-weight model with no per-token bill
BGE is one of the most widely used open-weight embedding families. A Chinese research lab, BAAI, publishes it under a license that allows commercial self-hosting.
Running it yourself removes the per-token bill and keeps every document inside your own network. That matters for regulated data that cannot leave your systems. It also means you now own the GPU capacity, the model updates and the on-call for that service.
Quality sits close behind the hosted leaders on public benchmarks, close enough that most teams will not notice the gap in real use. The gap that does matter is who gets paged. Nobody is paged when a hosted API has a bad day. Someone is paged when your own service does.
Best for
- Regulated data that cannot leave your own infrastructure
- High embedding volume where per-token pricing adds up fast
Not for
- Teams with nobody willing to operate a GPU inference service
- Low-volume products where the API bill was never the constraint
- Runs as
- Open weight, self-hosted
- License
- MIT
- Max dimensions
- 1024
A second open-weight option for English retrieval
GTE-large is Alibaba's open-weight model. It scores in the same range as BGE on the same public benchmarks. It sits here as the second real option, not a clear step up or down.
The real reason to pick one over the other is rarely the benchmark score. It is the license terms, the tooling around it, and which one your stack already has a tested link to.
If nothing else pulls you toward BGE or GTE, that itself is a signal. The choice is not where your project's risk lives. Spend that time on chunking instead.
Best for
- Teams already self-hosting BGE-class models who want a second benchmark point
- English retrieval on a fixed self-hosting budget
Not for
- Teams wanting a single, well-known default open-weight model
- Multilingual or multimodal corpora
- Runs as
- Open weight, self-hosted
- Max dimensions
- 1024
- Strength
- English retrieval
- PickModel sets the quality ceiling.
- EmbedEvery document, at your cost.
- IndexDimension size sets storage cost.
- RetrieveWhere the model choice shows up.
- SwitchMeans re-embedding everything, not a config change.
The last step is the one buyers underprice.
Not sure which model fits your corpus?
Tell us what you are retrieving and in how many languages. We will name the model we would pick and say why, on a scoping call that costs nothing.
When none of these is the answer
If your documents are few and structured, with clear fields like date, status or customer name, a plain database query beats semantic search. It also costs nothing to embed.
And if your answers are already wrong, a new model rarely fixes it. Bad chunking, or a missing rerank step, causes most of the failures teams blame on the model.
- 01Structured lookups by name, date or status do not need embeddings at all.
- 02Test whether reranking fixes your accuracy problem before you swap models.
- 03A smaller, cheaper model with good chunking usually beats a better model with bad chunking.
Retrieval over real document sets, running in production
Questions buyers ask
01Does a better embedding model fix a RAG system that gives wrong answers?
Rarely on its own. Chunking and reranking cause most retrieval failures, so fix those first. A better model on badly split documents still underperforms a mediocre model on well-split ones.
02Can we switch embedding models later without a full rebuild?
Not without re-embedding your corpus. Vectors from different models are not compatible, so switching means reprocessing every document and rebuilding your index, not changing a config value.
03Is an open-weight model good enough for production, or do we need a hosted API?
BGE and GTE score close to the hosted leaders on public retrieval benchmarks. The real question is whether your team wants to operate GPU inference, not whether the model is capable enough.
04Why rank Voyage above OpenAI when most teams use OpenAI?
Because this ranking orders by retrieval quality first. OpenAI is the right pick for most teams for operational reasons, and the verdict says so. But that is a different question from which model scores highest.
05Do higher dimensions always mean better retrieval?
Generally, yes, up to a point, and always at a storage cost. Most current models support truncating the vector to a smaller size with a small accuracy trade. Test that before you commit to the full dimension count.
Related reading
- Best vector databases for RAG →Where the vectors actually live, and when the store matters.
- What an embedding is →What the term means, without the vendor framing.
- Why your RAG returns wrong answers →The failure modes that are not the model's fault.
- RAG development →How we build retrieval that holds up.
