Best Embedding Models in 2026: OpenAI vs Open Source by MTEB

If the embedding model doesn't connect a query with the relevant passage, that information never reaches the model as context, and the retrieval system fails before the LLM ever generates a response.

Choosing an embedding model in 2026 means comparing very different systems. OpenAI still uses its text-embedding-3 generation, Google and Cohere support multimodal inputs, Voyage offers several models that share an embedding space, and Qwen, BGE, and Microsoft provide self-hosted options with different compute and licensing requirements.

MTEB can help with that comparison, although its published scores aren't always equivalent. Results can come from different benchmark versions, language sets, task selections, and averaging methods, so two numbers that appear side by side can represent different evaluations.

This comparison covers the leading models across retrieval performance, dimensions, context limits, modalities, deployment, and cost, while keeping results from incompatible benchmark setups separate.

What Makes an Embedding Model "Best"?

The best embedding model depends on what has to be retrieved. Retrieval quality is the obvious starting point, but language coverage, modality, context limit, vector dimensions, latency, cost, licensing, and deployment are all qualifiers that can remove a model from the shortlist before its headline benchmark score even comes into the picture.

Vector dimensions also affect storage and query cost. Larger embeddings increase the storage and index footprint inside a vector database, and models with Matryoshka or configurable dimensions can reduce vector size without retraining the model. The retrieval loss from that reduction varies by model and corpus.

Reducing vector dimensions lowers storage and query cost, but the retrieval-quality tradeoff still has to be tested on the actual corpus.

A longer context window allows larger inputs, but a 32K or 128K limit doesn't mean an entire document should be encoded as a single embedding. Retrieval quality still depends on the size and granularity of the indexed units, so chunking strategy should be tested independently of the model's maximum input length.

In a RAG system, embeddings need to be able to retrieve the evidence the LLM needs while keeping latency, storage, and cost within acceptable limits.

How to Read MTEB in 2026

The Massive Text Embedding Benchmark (MTEB) began as a text-embedding benchmark and now includes evaluation across text and image embedding tasks. For text models, benchmark suites cover retrieval, classification, clustering, semantic textual similarity, reranking, bitext mining, and other task types across English and multilingual datasets.

An "MTEB score" can refer to vastly different evaluations: English v2, Multilingual v2, older MTEB releases, partial task sets, or provider-run evaluations that use an earlier benchmark configuration.

Aggregation changes the headline number, too — in the current MTEB tooling, Mean(Task) averages task-level results, while Mean(TaskType) first groups results by task category. Qwen publishes Mean(Task) results for MTEB English v2, while Microsoft's Harrier model cards report Mean(TaskType) results for Multilingual MTEB v2; those numbers belong in the same article, but not in the same ranking.

Two similar-looking MTEB scores can come from different benchmark versions, aggregation methods, and language coverage.

The leaderboard also tracks zero-shot status based on whether a model was trained on datasets used by the evaluation tasks. Where that information is available, it adds context to a headline score because prior exposure to benchmark data can make direct comparisons less representative of an unfamiliar corpus. Most of the providers compared in this article don't disclose zero-shot status for their published scores, which is itself a reason to treat any single headline number as a starting point rather than a settled ranking.

As for RAG and semantic search, retrieval scores are more informative than the aggregate result because gains in classification or clustering can raise the overall average without improving document retrieval to the same degree.

Before comparing headline scores, it helps to check how each result was produced and what the benchmark actually covers:

MTEB can narrow the candidate set, after which corpus-level retrieval tests should validate the finalists before deployment.

MTEB Results for Leading Embedding Models

The table below keeps each score attached to the benchmark, version, and evaluation setup it came from, so results from different MTEB variants or provider-specific tests aren't presented as if they belonged to a single directly comparable leaderboard:

The three Qwen models were evaluated under the same MTEB English v2 setup, so their numbers can be compared with one another; the same applies to the two OpenAI v3 models inside OpenAI's 2024 evaluation and the Harrier family inside Microsoft's Multilingual MTEB v2 reporting.

Gemini Embedding 2, Voyage 4, Cohere Embed 4, and BGE-M3 still have public evaluation evidence, but those results answer different benchmark questions. Their entries below use provider specifications and retrieval evidence without converting them into an artificial MTEB rank.

Best Embedding Models in 2026

Model selection also depends on the inputs each model supports, how much context it can process, its vector dimensions, deployment model, license, and cost:

OpenAI Embedding Models in 2026

OpenAI's embedding lineup has stayed on the text-embedding-3 generation since 2024. As of writing this article in September 2026, the API still lists text-embedding-3-large, text-embedding-3-small, and the older text-embedding-ada-002.

OpenAI text-embedding-3-large

text-embedding-3-large is OpenAI's most capable current embedding model, producing up to 3,072 dimensions with the dimensions parameter available for shorter vectors. It's text-only and API-based.

Its MTEB and MIRACL scores in the table above come from OpenAI's original 2024 launch evaluation, so they're directly comparable to 3-small under that same setup — not to the newer MTEB v2 numbers elsewhere in this comparison.

OpenAI text-embedding-3-small

text-embedding-3-small trades some retrieval quality for a substantially lower per-token price and smaller vectors than 3-large, evaluated under the same 2024 OpenAI benchmark shown above. At high embedding volumes, that lower price and smaller vector size reduce both embedding spend and storage requirements.

Both v3 models support shortened embeddings through the dimensions parameter. OpenAI L2-normalizes the output, including embeddings shortened through that parameter, so cosine similarity and dot-product scoring produce equivalent rankings.

text-embedding-ada-002 is still available, but it belongs to the previous embedding generation. Migrating an existing Ada index to either v3 model requires the stored corpus to be re-embedded because the vector spaces are incompatible.

Here are the two models compared:

Managed Alternatives to OpenAI

Google Gemini Embedding 2

Gemini Embedding 2 (stable version released on April 22, 2026) accepts text, images, audio, video, and PDFs and encodes them into one embedding space.

Text input supports up to 8,192 tokens, while output dimensions can be set between 128 and 3,072. Google lists 768, 1,536, and 3,072 as recommended vector sizes.

Paid text embedding currently costs $0.20 per million tokens on the standard API and $0.10 per million through Batch, with images, audio, and video using separate rates. Google's free tier is also available, with different data-use terms from the paid tier.

A text query can retrieve semantically related media without routing every modality through a separate embedding family, which gives Gemini Embedding 2 a different retrieval scope from the text-only models in this comparison — this is why it doesn't have an aggregate MTEB rank.

Voyage 4 Family

Voyage 4 is a family of text embedding models with a 32,000-token context limit and output dimensions of 256, 512, 1,024, or 2,048. The main API lineup includes voyage-4-large, voyage-4, and voyage-4-lite, alongside the code-focused voyage-code-4.

All Voyage 4 models produce compatible embeddings, meaning that a corpus can be indexed with one family member and queried with another without rebuilding the document vectors. That creates a practical way to allocate a more expensive model to indexing and a lower-cost model to high-volume queries.

Current API pricing is $0.12 per million tokens for voyage-4-large, $0.06 for voyage-4, and $0.02 for voyage-4-lite. The family also supports Matryoshka dimensions and several quantized output formats.

voyage-4-nano extends the family to local inference under Apache 2.0 while retaining vector compatibility with the API models. Voyage also publishes voyage-context-4, which can process up to 120,000 total document tokens with automatic chunking, while still keeping individual chunks within the 32K model limit.

Cohere Embed 4

Cohere Embed 4 accepts text, images, and mixed text-image inputs such as document pages. Its 128K context limit is the largest among the main models in this comparison — although, again, a large input limit doesn't remove chunk size as a retrieval variable — and output dimensions can be set to 256, 512, 1,024, or 1,536.

Text and images can be embedded together as one input, allowing a document page containing prose, diagrams, tables, or screenshots to receive one representation. The model also supports multilingual retrieval across more than 100 languages.

Embed 4 can return float, int8, uint8, binary, or unsigned-binary embeddings, which provides another route to reducing index storage beyond lowering the vector dimension.

The model is available through Cohere and supported cloud platforms, with private deployment also offered. Cohere's current Model Vault pricing starts at $4/hour for a Small Embed 4 instance and $5/hour for Medium.

Best Open-Source Embedding Models

Searches for open-source embedding models often mix permissively licensed releases with open-weight models that carry extra restrictions. The models below use Apache 2.0 or MIT licenses and can be run on self-managed infrastructure.

Qwen3-Embedding

Qwen3-Embedding comes in 0.6B, 4B, and 8B parameter versions. All three support a 32K sequence length, Apache 2.0 licensing, Matryoshka Representation Learning, and task instructions.

Maximum vector size rises with model size: 1,024 dimensions for 0.6B, 2,560 for 4B, and 4,096 for 8B. User-defined output dimensions can reduce those vectors when a smaller index is preferred.

The family supports more than 100 natural and programming languages, including multilingual, cross-lingual, and code retrieval. Qwen also reports that task-specific instructions improve many downstream evaluations by roughly 1–5%.

Under the MTEB English v2 numbers shown earlier, retrieval scales with model size, but not evenly: the gap between 4B and 8B is much narrower than the gap between 0.6B and 4B.

The three sizes can be tested against the same corpus to measure whether the larger variants improve retrieval enough to justify their higher inference requirements.

Qwen also publishes the separate Qwen3-VL-Embedding family under Apache 2.0 for multimodal embedding across text, images, and video — separate from the text-only Qwen3-Embedding family compared in the main table.

BGE-M3

BGE-M3 produces dense, sparse lexical, and multi-vector representations from one model. Those outputs can be used individually or combined in a hybrid retrieval pipeline.

The model produces 1,024-dimensional dense vectors, accepts up to 8,192 tokens, supports more than 100 languages, and is released under the MIT license.

Dense retrieval handles semantic similarity, sparse token weights support lexical matching, and multi-vector output provides ColBERT-style late interaction without deploying three separate embedding models.

BGE-M3 predates Qwen3 and Harrier, but its retrieval modes and mature tooling still give it a different position in the comparison. Public evaluation spans multilingual and long-document retrieval datasets rather than one current aggregate MTEB v2 number, so no single score is inserted into the earlier table.

Microsoft Harrier OSS v1

Harrier OSS v1 is Microsoft's MIT-licensed family of multilingual dense embedding models. It comes in 270M, 0.6B, and 27B versions, all with a 32,768-token maximum input.

The 270M model produces 640-dimensional embeddings, 0.6B produces 1,024 dimensions, and 27B produces 5,376. Microsoft lists support for 94 languages and uses last-token pooling with L2 normalization.

Microsoft also reports a Multilingual MTEB v2 score of 66.5 for the 270M model, extending the family's benchmarked range below the 0.6B and 27B scores shown earlier. All three stay comparable to each other, but not to Qwen's MTEB English v2 figures.

The 270M and 0.6B variants require far less local inference capacity than the 27B model, which carries the highest Harrier benchmark result and substantially higher memory and compute requirements.

API vs Open-Source Embedding Models

Managed APIs remove embedding inference infrastructure, while self-hosted models keep the model and source data within infrastructure you control:

OpenAI, Gemini, Voyage, and Cohere remove the need to run embedding inference directly. Self-hosted models replace per-token API charges with hardware and operating costs, which vary substantially between a sub-billion-parameter model and a 27B model.

On the topic of licensing the open-source embedding models, Apache 2.0 and MIT releases permit relatively broad reuse, while other downloadable weights can come with additional restrictions. A permissive model license also doesn't necessarily mean that the complete training dataset is public.

How to Choose an Embedding Model for RAG

MTEB and provider benchmarks can reduce the candidate set. The final comparison should use the documents and queries the application will actually be retrieving.

First, remove models that conflict with the basic requirements: input modality, language coverage, context limit, deployment, or licensing.

Then evaluate the remaining models in the same retrieval setup:

1. Build a representative query set and relevance labels. For each query, identify which passages should count as relevant so the retrieval metrics have a reference answer.
2. Index the same corpus with each model. Keep chunking, metadata, filtering, and retrieval settings unchanged so the embedding model is the main variable.
3. Measure retrieval quality. Recall@k shows whether relevant passages were retrieved, while MRR and nDCG also account for their position in the ranking.
4. Check downstream answer quality. If better retrieval scores don't improve answer quality in a RAG pipeline, they shouldn't be assumed to translate into better end-to-end performance.
5. Repeat the test at different vector sizes where supported. Compare the retrieval disparity with the reduction in index size and query cost.
6. Measure latency and total cost. Include embedding throughput, query latency, API charges or inference compute, and vector storage.

Maximum dimensions are not automatically the right production setting, for the same storage-versus-retrieval-loss tradeoff described earlier — test reduced dimensions against the corpus rather than assuming the largest vector wins.

Model size should be tested in the same way. Qwen3-Embedding-8B leads its smaller variants in Qwen's published MTEB English v2 results, but that doesn't establish the size of the retrieval disparity on a narrower domain-specific corpus.

After the benchmark pass, compare corpus-level retrieval results, latency, and total cost before selecting the deployment model.

A higher MTEB score doesn't guarantee better RAG results — validate on your own corpus and measure the end-to-end impact.

The Role of Embedding Models in a Persistent Memory Stack

An embedding model determines how semantic similarity is represented and which information can be retrieved through vector search. For persistent agent memory, that's one part of a longer lifecycle that also includes relationships, provenance, session context, and revisions of stored information over time.

Changing to a new embedding model usually requires re-embedding the underlying corpus and replacing the stored vectors, unless the models share a compatible embedding space. The surrounding memory system can stay intact while the embedding layer changes, leaving room to benchmark new models without rebuilding how persistent context, relationships, and provenance are managed.

cognee's memory architecture combines vector retrieval with graph structure, lexical retrieval, sessions, and provenance. The embedding engine can be configured independently, with support for OpenAI, Gemini, Hugging Face, Ollama, Fastembed, vLLM, and OpenAI-compatible endpoints.

FAQ

Answers to the most common questions from this guide.

Can queries and documents use different embedding models?+

Yes, but only when the encoders were designed to produce compatible representations. Most retrieval systems use the same embedding model for both sides, while some architectures use separate query and document encoders trained into the same vector space. Voyage 4 extends that idea across several compatible models in one family.

Do you still need a reranker with a high-quality embedding model?+

A reranker can still improve precision after the embedding model retrieves the initial candidate set — it helps most once several passages are semantically similar and their relevance comes down to finer distinctions than vector similarity captures.

The embedding model determines which candidates reach the second stage, so reranking cannot recover a relevant passage that was never retrieved in the first place.