Best embedding models for RAG (2026)
The choice is easy to reverse in a demo. In production, switching means re-embedding every document you have.
The short answer
Voyage's voyage-4-large is our pick when retrieval quality decides. 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 5, released on 30 September 2026, earns its spot on multilingual sets that mix images and text. Open-weight models close most of the quality gap and drop the per-token bill, but you host 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.
Key takeaways
3 things that decide this
- 01Voyage-4-large is the best embedding model for RAG when retrieval quality is what your tests keep failing on.
- 02We ranked five models on retrieval quality, price per token, dimension and storage cost, and what it costs to switch away later.
- 03Test on your own documents first: switching later means re-embedding everything.
How we ranked
Verified
We ranked five embedding models on retrieval quality from each vendor's published benchmarks. We added pricing and our own experience building retrieval on them. Vendor benchmark pages pick their own comparisons, so treat each one as a claim to test on your data.
Model names, dimensions and licences were read from each vendor's docs or model card on 11 November 2026. We left out models with no hosted endpoint and no open-weight release. A model you can't call or self-host isn't a real choice.
Hashlogics publishes this page. We build custom software and are not one of the tools ranked here. No company paid for its place.
- 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
Dimensions and licences read from vendor docs and model cards on 11 November 2026.
| Model | Runs as | Max dimensions | Best moment to pick it |
|---|---|---|---|
| Voyage-4-large | Hosted API (Voyage, part of MongoDB since 2025) | 2048 (default 1024); 256 and 512 also offered | 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 5 (embed-v5.0-pro) | Hosted API | 2048 default, Matryoshka down to 256 | Multilingual or mixed image-and-text documents |
| BGE-large (BAAI) | Open weight, self-hosted (MIT) | 1024 | You need to run inference inside your own network |
| GTE-large (Alibaba) | Open weight, self-hosted (Apache-2.0) | 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. Checked against vendor docs on 11 November 2026.
Highest general retrieval score of the hosted models
Voyage AI publishes benchmark results for its flagship, voyage-4-large, against OpenAI's and Cohere's general models. Pick this when retrieval quality is the thing your tests keep failing on.
You can set the output to 256, 512, 1024 or 2048 dimensions, which trims storage without a model swap. Voyage also ships models tuned for code, law and finance, which matters if your corpus is domain-heavy rather than general text.
MongoDB bought Voyage in February 2025, and the models stay on Voyage's own API. Confirm the roadmap before you bet 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
- 2048 (default 1024)
- Domain variants
- Code, law, 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 released Embed 5 on 30 September 2026, replacing embed-v4 as its flagship. It puts text, images and mixed content into one vector space and supports over 100 languages. Scanned contracts or captioned photos are a real case the general models don't target.
You can truncate the vector from 2048 down to 256 dimensions, and a faster tier, embed-v5.0-fast, shares the same space. For an English-only text set, you'd pay for features you won't use, so pick it for the problem it solves.
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
- License
- Apache-2.0
- Max dimensions
- 1024
- 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.
Diagnosing which stage is actually broken, chunking, retrieval, reranking or the model, is the RAG development work we do for clients.
- 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
01What is the best embedding model for RAG?+
Voyage-4-large is the best embedding model for RAG when retrieval quality decides. OpenAI's text-embedding-3-large is the safer default if you already build on OpenAI, and BGE suits data that can't leave your network.
02How were these models ranked?+
We ranked five models on retrieval quality, price, dimension and storage cost, and switching cost, checked against vendor docs on 11 November 2026. Hashlogics publishes this page and is not one of the tools ranked; no company paid for its place.
03How do I compare embedding models fairly?+
Run every model on the same few hundred real questions from your own documents, with the same chunking. Score how often the right passage comes back, and compare that before you look at price.
04Does 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.
05Can 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.
06Is 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.
07Why 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.
08Do 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.
09Why isn't Jina, Nomic or Google's Gemini embedding model on this list?+
We ranked the five models with the clearest benchmark track record and the widest use in the builds we've shipped. Jina and Nomic are credible open-weight options, worth a bake-off if BGE or GTE doesn't fit your license terms. We left them out of the ranking, not out of the field.
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.
