Best Embedding Models in 2026: Open-Source Picks, Semantic Search, and How to Choose for RAG

Published 27 September 2026 · Updated 27 October 2026 · MTEB and RTEB leaderboard ranks, model cards and API prices checked on 27 October 2026

As of 27 October 2026, the best open-source embedding model for most teams is still Qwen3-Embedding from Alibaba's Qwen team: it is Apache 2.0, reads 32K tokens, ships in 0.6B, 4B and 8B sizes, and the 8B model ranks 5th on MTEB English v2 and 4th on MTEB Multilingual v2 with 95% or more of those tasks unseen in training. The highest-scoring open model outright is Microsoft's harrier-oss-v1-27b (MIT licence, 1st on MTEB Multilingual v2), and on the retrieval-only RTEB board the top open model is NVIDIA's Nemotron-3-Embed-8B. Five notable models have shipped since our first check on 26 September, among them Google's EmbeddingGemma 2, Cohere's Embed 5 and NVIDIA's Nemotron 3.5 Embed, and none of them displaces that default: three have no MTEB score yet, and the two small ones that do rank well below the leaders. For semantic search, pick from the retrieval column, which scores search alone, and pair the embedder with keyword search. For RAG, shortlist four models from those boards and let a labelled sample of your own queries decide.

Every rank below comes from the MTEB leaderboard API on 27 October 2026 (MTEB English v2 with 41 tasks and 349 ranked models, MTEB Multilingual v2 with 131 tasks and 483 models, and RTEB beta, which mixes open and private retrieval datasets across 30 tasks), every dimension, context length and licence comes from the model's own card, and every price comes from the vendor's pricing page or launch post on the same day. The one piece of evidence that is ours is a retrieval study we ran across 50,000 documents and 5,000 queries, published as File Search vs Vector Search for RAG, and it changes how much weight the embedding model deserves in the first place.

Embedding model comparison table, 27 October 2026

Ranks are the leaderboard's own rank field on each board. "n/r" means the model has not been run on enough of that board's tasks to receive a complete score, which is common for new or API-only models and says nothing about quality in either direction.

Two things in that table deserve a second look before anything else. MTEB's number one on English v2 today is still a closed 8B model released in May 2026, and the two open models directly behind it were each trained on roughly half of the benchmark's tasks (the leaderboard reports a zero-shot share of 48% for both), which is why they are not the default recommendation here even though they outrank Qwen3 on that board. And most of the hosted models teams actually call in 2026, Voyage AI's voyage-4 family, Google's gemini-embedding-2 and now Cohere's Embed 5, have no complete MTEB v2 score at all, so a table built only from MTEB averages silently drops them.

New embedding models since September 2026: five releases, no new default

Five releases since 26 September are worth knowing about, and the useful thing to say about each is what it changes for a team that is choosing today.

EmbeddingGemma 2 (Google, announced 6 October) replaces EmbeddingGemma-300M. The licence moved from Gemma terms to Apache 2.0, although the card still asks deployments to follow Google's Gemma prohibited-use policy and the MTEB leaderboard's metadata still lists the Gemma licence. Input grew from 2,048 to 8,192 tokens, and one 768-dimension space now covers text, code, images, video and audio; the text backbone alone is 270M parameters, which Google says needs about 191 MB of active RAM when quantized on a Pixel 11 Pro. Google's card reports 68.46 on MTEB English v2, 61.36 on Multilingual v2 (against 61.15 for version 1) and 78.68 on MTEB Code v1 (12 tasks) against 68.76; the leaderboard's own Code v1 run confirms the jump, 0.7788 (17th) against 0.6876 (34th) for version 1. The leaderboard's own results are less flattering: EmbeddingGemma 2 sits 59th on English v2 at 0.6753 and 40th on Multilingual v2 at 0.6052, below version 1 on both (34th at 0.6967 and 31st at 0.6114), and its English retrieval column is 0.5133 against 0.5569 for version 1. Pick it for the licence, the longer input and the extra modalities, and test text retrieval before assuming it beats the model it replaces. The card also warns that the model returns NaN or silently degraded embeddings in float16, so run it in bfloat16 or float32.

Cohere Embed 5 (generally available 30 September) comes in two tiers that share one embedding space: Pro at $0.12 per 1M text tokens and Fast at $0.08, both $0.40 per 1M image tokens, with 128K-token inputs, text, image and fused text-plus-image inputs, more than 100 languages, Matryoshka output from 2,048 down to 256 dimensions, and float, int8 or binary vectors. Cohere's launch post shows Pro ahead of voyage-4-large and Gemini Embedding 2 on ViDoRe V3, a visual-document retrieval benchmark of 10 datasets (8 public, 2 private), but it uses its own variant of the metric and does not say which datasets it ran, so we do not repeat its numbers. Qdrant's test on 23 October, using standard nDCG@10 (a retrieval metric, no LLM judge) on five public English ViDoRe V3 corpora with 12,969 page images and 1,489 questions, scored Embed 5 Pro at 65.8 with one vector per page, ahead of several multi-vector models and behind ColEmbed-3B-v2 at 67.5. Cohere supports private deployment and serving with vLLM, but the announcement does not describe open weights, so we list it as closed.

Nemotron 3.5 Embed (NVIDIA, 20 October) adds image documents to Nemotron-3-Embed. The 8B model's language model is the frozen Nemotron-3-Embed-8B, and NVIDIA states the two share one space and produce identical text embeddings, so text-only users gain nothing by switching and multimodal users keep the text quality that ranks 2nd on RTEB. Queries are text only; documents can be text, an image or both, up to 32,768 tokens. NVIDIA's card reports it ahead of Qwen3-VL-Embedding-8B on ViDoRe V3 image, text and image-plus-text retrieval, without saying which ViDoRe V3 datasets it used, so treat that as a vendor claim until an independent run appears. A 1B version (1.55B parameters, 2,048 dimensions) ships alongside it. Both are under OpenMDW-1.1, which the cards describe as ready for commercial use.

pplx-embed-v2 from Perplexity is a pair of MIT-licensed late-interaction models (0.6b and 9b) that produce one 128-dimension vector per token, where most models produce one vector per document, and embed page images directly without OCR. In Qdrant's test on four ViDoRe v3 datasets (11,609 pages, 200 English queries per dataset, nDCG@10), the 9b scored 0.681 on page images and 0.671 on the same pages converted to Markdown, and the 0.6b scored 0.666 on images. The storage bill is the catch: in the same write-up each page image becomes about 1,700 vectors, 856 KB per page in float32, which 1-bit quantization cuts to 40 KB while keeping 96.5% of quality before rescoring.

UltraBERT-Embed-150M from DMIS Lab is a 151M-parameter, Apache 2.0, English encoder that reads 32,768 tokens into one 768-dimension vector. It ranks 52nd on MTEB English v2 at 0.6724, and its card reports a 79.30 average across the 6 tasks of the LongEmbed long-document benchmark. Qdrant's test is the useful part for anyone tempted to stop chunking, and it is covered under long documents below.

On the leaderboard itself, two changes since September matter. Microsoft's harrier-oss-v1-0.6b now has a complete English v2 score and ranks 22nd, five places above Qwen3-Embedding-0.6B. And jina-embeddings-v5-text-small, which ranked 15th on English v2 on 26 September, now shows results for only 38 of 41 tasks and no complete score, a reminder that a rank can change because coverage changed while the model stayed the same.

Best open-source embedding model in 2026

The default: Qwen3-Embedding

Qwen3-Embedding is the default recommendation because it is near the top of every board it has fully run on, under a licence your legal team will not argue about. The 8B model scores 0.7522 mean(task) on MTEB English v2 (5th) and 0.7058 on Multilingual v2 (4th); its retrieval column on Multilingual v2 is 0.7088. The leaderboard lists 95% of English v2 tasks and 99% of Multilingual v2 tasks as zero-shot for it, so the score is not a product of training on the test.

Qwen3 also has the practical properties that decide production fit: a 32K-token context window on every size, Matryoshka-style truncation from the full width down to 32 dimensions, instruction-aware queries (the card recommends writing a task-specific instruction for queries), and a matching Qwen3-Reranker at 0.6B, 4B and 8B. Start with the 0.6B model if you are serving on modest hardware, move to 4B or 8B only if your own evaluation says the gain is worth the GPU.

Highest score: harrier-oss-v1

Microsoft's harrier-oss-v1 family, released in March 2026 under MIT, holds first place on MTEB Multilingual v2 with a 0.7427 mean(task) for the 27B model and the highest retrieval column on that board at 0.7827. It comes in three sizes (270M at 640 dimensions, 0.6B at 1,024, 27B at 5,376), all with 32,768-token inputs. The 0.6B model is the more interesting one for most teams: it ranks 10th on Multilingual v2 at 0.6901, ten places above Qwen3-Embedding-0.6B, at the serving cost of a sub-billion-parameter encoder. The 27B model is a quality ceiling, not a default; its weights alone are roughly 54 GB in bf16, before you index a single document.

Retrieval-only leaders: Nemotron-3-Embed and Octen

RTEB is the board to watch if all you care about is retrieval, because it scores models on legal, finance, healthcare and code retrieval tasks and keeps part of the data private so it cannot be trained on. NVIDIA's Nemotron-3-Embed-8B (released 16 July 2026) is the top open model there at 2nd, behind only a voyage-4-large configuration at 2,048 dimensions with evolved prompts, and its card states it is ready for commercial use under OpenMDW-1.1. Octen-Embedding-8B, an Apache 2.0 model derived from Qwen3-Embedding-8B, sits 3rd on RTEB and 7th on Multilingual v2. If your RAG corpus is contracts, filings or clinical notes, those two belong on the shortlist next to Qwen3, and if the same corpus is scanned pages, Nemotron 3.5 Embed gives you image retrieval without changing the text vectors you already have.

Small models for CPU, edge and tight latency budgets

Under a billion parameters, five models are worth testing today. Qwen3-Embedding-0.6B and harrier-oss-v1-0.6b are both 1,024-dimension, 32K-context models; harrier ranks higher on both overall boards (22nd against 27th on English v2, 10th against 20th on Multilingual v2), while Qwen3 has the stronger English v2 retrieval column (0.6183 against 0.5845), which is the column that matters for search. Google's EmbeddingGemma 2 is the pick when you need Apache 2.0 at 270M parameters, an 8K input or audio and images in the same index, with the leaderboard caveat above. UltraBERT-Embed-150M is the smallest 32K-context model here and English only. IBM's granite-embedding-311m-multilingual-r2, released in April 2026, is Apache 2.0 with a 32,768-token context, which is unusual at 311M parameters. Measured VRAM, Ollama tags and indexing throughput for the small models are in our guide to local embedding models.

If you are still on all-MiniLM-L6-v2, the gap is large and measurable: its English v2 retrieval column is 0.4292 against 0.6183 for Qwen3-Embedding-0.6B. That model was the embedder in our own 50,000-document study, and we said at the time that a stronger embedder would very likely raise the vector numbers.

Licences that look open and are not

Open weights and open licence are different things, and the difference is where a CIO gets involved. Jina AI's jina-embeddings-v5-text-small is a strong sub-billion model, but it is CC BY-NC 4.0, and the card says commercial use requires contacting Jina. NVIDIA's llama-embed-nemotron-8b (3rd on Multilingual v2) is marked "for non-commercial/research use only", NV-Embed-v2 is CC BY-NC 4.0, and Tencent's KaLM-Embedding-Gemma3-12B (2nd on Multilingual v2) ships under a custom community licence. Two of the top five open models on Multilingual v2 therefore need a legal read before production use, which is the strongest practical argument for the Apache and MIT options above. EmbeddingGemma 2 is the newest edge case: Apache 2.0 on the card, with Google's prohibited-use policy attached, so keep a copy of the exact card revision you ship.

Hardware for self-hosting

A rough sizing rule from parameter counts: weights in bf16 take about 2 bytes per parameter, so an 8B embedder needs roughly 16 GB of GPU memory before activations and batching, a 4B model roughly 8 GB, and a 0.6B model roughly 1.2 GB. That is arithmetic, not a benchmark, and long 32K inputs add activation memory on top. For CPU serving, stay under a billion parameters and cap input length.

Best embedding API if you do not want to self-host

For a hosted embedding API, voyage-4-large is the strongest option on a public retrieval board today (6th on RTEB at its default 1,024 dimensions, 1st at 2,048 with evolved prompts) at $0.12 per 1M tokens, and voyage-4 at $0.06 is the value pick at 12th. gemini-embedding-001 is the only hosted model in the table with complete scores on all three boards (9th, 5th and 13th), though Google's pricing page does not list it today. Cohere's Embed 5 is the newest entrant and the only one here with a 128K-token input and published fused text-and-image pricing, but it has no MTEB or RTEB score yet, so treat its comparisons as vendor-reported until it does. OpenAI's text-embedding-3-small is the cheapest at $0.02 per 1M tokens, tied with voyage-4-lite, and sits 54th on RTEB against 22nd for voyage-4-lite at the same price.

If you are building on Claude, Anthropic does not offer its own embedding model; its documentation uses Voyage AI in its examples and suggests evaluating several providers.

Which embedding model is best for semantic search?

For semantic search, the best embedding model is the one that ranks highest on retrieval tasks for your language and domain, which today means Qwen3-Embedding-8B or harrier-oss-v1 among open models and voyage-4-large or gemini-embedding-001 among hosted ones, run inside a hybrid search system alongside a keyword index. The overall MTEB English v2 score averages seven task types (retrieval, semantic similarity, classification, clustering, pair classification, reranking and summarization), and only one of those is search. Sort by the retrieval column or use RTEB.

Hybrid beats pure vector more often than the averages suggest

Our 50,000-document study is why a model name is not the whole answer. Across five datasets, vector search led keyword search on MRR@10 by 0.6320 to 0.5325. Remove the natural-language-to-code dataset and the ranking inverts: exact-match keyword search led the remaining four, 0.5931 to 0.5614. On science exam questions, keyword search scored 0.8145 against 0.6142 for vectors, because the query term (mitochondria, say) is the key itself, not an approximation of a concept. The run used all-MiniLM-L6-v2 at 384 dimensions, Tantivy 0.22.0 and ChromaDB on an Apple M4 on 14 January 2026, a single run scored by exact document-ID matching with no LLM judge. A stronger embedder narrows the gap; it does not remove the class of query where the exact term matters.

That is why hybrid search is the production default for semantic search: a keyword index for identifiers, names and rare terms, an embedding index for paraphrase and intent, and a merge step. BGE-M3 is worth knowing here because a single MIT-licensed model emits dense, sparse and multi-vector representations, so one model can serve both sides of a hybrid index.

Latency and the embedding tax

Query latency is dominated by where the model runs. Meilisearch's published measurements from an AWS London instance put a local all-MiniLM-L6-v2 at about 10 ms per query and a local bge-large-en-v1.5 at about 60 ms, against about 460 ms for OpenAI's text-embedding-3-small and 750 ms for text-embedding-3-large over the network. If you run search-as-you-type, a local sub-billion model is usually the only option that fits.

Indexing is the other cost. In our study, building the keyword index over 50,000 documents took 2.11 seconds and embedding plus indexing took 161.6 seconds, a factor of 76.4 on the same machine. That tax matters when an agent needs to search a document it read seconds ago, and it is paid again in full every time you change embedding model.

Queries, prefixes and rerankers

Most modern embedders expect you to tell them whether an input is a query or a document, and skipping that step quietly costs accuracy. Qwen3 and harrier take a task instruction on the query side, EmbeddingGemma 2 wants task: search result | query: {query} for queries and title: none | text: {content} for untitled documents, nomic-embed-text-v2-moe requires search_query: and search_document: prefixes, and Voyage's API takes an input_type of query or document. Use each model's documented format, or your comparison is testing your preprocessing rather than the model.

Short queries against long documents (asymmetric search) are where embeddings are weakest, because a five-word query vector sits a long way from a thousand-word document vector. Chunking to paragraph or section size helps, and a reranker run over the top candidates (Qwen3-Reranker is the matching open option) is the usual next step once the embedder is fixed.

Long documents: chunks still beat one 32K vector on most tests

A 32K-token window lets you embed a whole document as one vector, and the October tests show when that works and when it does not. Qdrant ran UltraBERT-Embed-150M both ways, whole document against 512-token chunks, scored by nDCG@10 unless noted (a retrieval metric, no LLM judge), on tasks from the LongEmbed benchmark, whose test sets hold 336 queries for SummScreenFD, 1,527 for QMSum, 300 for 2WikiMultihopQA and 400 for the needle task, plus MLDR with 800 questions over 200,000 Wikipedia articles. Whole-document vectors won on SummScreenFD (0.974 against 0.954), where each document is about one thing. Chunks won on QMSum (0.712 against 0.536), 2WikiMultihopQA (0.991 against 0.929) and MLDR (0.683 against 0.509). On the needle-in-a-haystack task at 32K tokens, whole-document recall@1 fell to 30% while 512-token chunks found the needle 56% of the time. Embedding whole transcripts also took about three times as long as embedding chunks on an NVIDIA L4. Long context is useful headroom for long sections and tables; it is not a reason to stop chunking documents that cover many facts.

Multilingual, code and multimodal search

For multilingual or cross-lingual search, use MTEB Multilingual v2 instead of English v2, and then test the specific languages your users type, because an average over more than 250 languages can hide a weak one. For code search, MTEB has a dedicated Code v1 benchmark of 12 tasks; the leaderboard's own runs put EmbeddingGemma 2 at 0.7788 (17th) and UltraBERT-Embed-150M at 0.7330 (24th), and Voyage sells a dedicated voyage-code-4 at $0.12 per 1M tokens. Vector search's biggest win in our own study was natural language to code, 0.9143 against 0.2901 for keyword.

For images, PDFs, audio or video, there are now permissive open options as well as hosted ones. Qwen3-VL-Embedding-8B is Apache 2.0 with 32K inputs covering text, image and video; Nemotron 3.5 Embed covers text and image documents under OpenMDW-1.1; EmbeddingGemma 2 adds audio at edge sizes. Among hosted models, gemini-embedding-2 maps text, images, video, audio and PDFs at $0.20 per 1M text tokens, and Cohere Embed 5 accepts text and page images at $0.12 (Pro) or $0.08 (Fast). Late-interaction models such as pplx-embed-v2 score well on page images but store hundreds of vectors per page, so price the index before you pick one. Our post on image embeddings versus vision models covers when to embed and when to reason.

How to choose an embedding model for RAG, step by step

Choosing an embedding model for RAG is a constraint filter followed by an experiment on your own data. Public leaderboards are the shortlist; your labelled queries are the decision.

An embedding model turns a piece of text into a fixed-length vector so that passages with similar meaning land close together. A RAG pipeline uses it twice: once at indexing time, to embed every chunk of your corpus, and again on every request, to embed the user's question and find the nearest chunks by cosine similarity. Those chunks are all the language model gets to read, so the embedder sets a ceiling on answer quality before generation even starts.

1. Write down the hard constraints first. Licence (commercial use or not), whether text may leave your infrastructure, the languages you must support, your latency budget per query, and the monthly spend you can tolerate. These remove more candidates than any benchmark will.

2. Shortlist four models. Take the top of the retrieval column on MTEB English v2 or Multilingual v2 and the top of RTEB, filter by your constraints, and include one small model as a baseline. A sensible shortlist today for an English commercial product is Qwen3-Embedding-4B, harrier-oss-v1-0.6b, Nemotron-3-Embed-8B and one hosted model such as voyage-4 or text-embedding-3-small.

3. Build a labelled eval set from your own queries. Somewhere between 100 and 200 real questions is enough to separate models, each with the ID of the chunk or document that answers it. Include exact identifiers, paraphrases, questions whose answer sits in a table, and a few with no answer at all. Keep the corpus and chunking fixed across every run.

4. Score retrieval, not answers. Use nDCG@10 (rewards putting the right chunk near the top), Recall@10 (did it appear at all) and MRR@10 (how high the first correct hit ranked). Answer quality depends on the generator and the prompt too, so measure it separately.

5. Measure latency, storage and price alongside quality. A million vectors at 1,024 dimensions take about 4.1 GB as float32, about 1 GB as int8 and about 128 MB as binary; the same million at 4,096 dimensions take about 16.4 GB as float32. Embedding a billion tokens costs $20 with text-embedding-3-small or voyage-4-lite, $60 with voyage-4, $80 with Cohere Embed 5 Fast, $120 with voyage-4-large or Embed 5 Pro, $130 with text-embedding-3-large and $200 with gemini-embedding-2 at standard rates. Pick the smallest model and the smallest dimension your eval tolerates.

6. Match context length to your chunks, not the other way round. A 32K-token window does not mean you should embed 32K-token chunks; one vector for a whole document blurs every fact in it, which is what the UltraBERT tests above measured. Most RAG pipelines retrieve best on paragraph- or section-sized chunks, which every model in the table above can read.

7. Plan for the next model. Store raw text and chunk IDs separately from vectors so a re-embed is a batch job rather than a migration.

A minimal version of steps 3 and 4 fits in a few lines with Sentence Transformers:

from sentence_transformers import SentenceTransformer
import numpy as np

# queries: list[str]; gold: list[int] (index of the answering chunk); chunks: list[str]
def evaluate(model_id, queries, gold, chunks, k=10, **query_kwargs):
    model = SentenceTransformer(model_id)
    doc_vecs = model.encode(chunks, normalize_embeddings=True, batch_size=32)
    q_vecs = model.encode(queries, normalize_embeddings=True, **query_kwargs)
    ranks = np.argsort(-(q_vecs @ doc_vecs.T), axis=1)[:, :k]
    hits = [np.where(r == g)[0] for r, g in zip(ranks, gold)]
    recall = np.mean([len(h) > 0 for h in hits])
    mrr = np.mean([1.0 / (h[0] + 1) if len(h) else 0.0 for h in hits])
    return {"recall@10": recall, "mrr@10": mrr}

print(evaluate("Qwen/Qwen3-Embedding-0.6B", queries, gold, chunks, prompt_name="query"))

Run the same function for each shortlisted model with its documented query prompt, and keep the numbers next to latency and cost in one table.

When to fine-tune or use a domain model. If your text is full of vocabulary a general model rarely saw (drug names, statute citations, internal product codes), check for a domain model first and fine-tune a general one second. Results do move by domain: in a September 2026 AIMultiple benchmark of 11 open models (200 LLM-drafted questions, 50 each over finance, legal, technical-support and medical corpora, scored by nDCG@10 in a single run, with an LLM judging extra relevant passages), BGE Large EN v1.5 led the finance subset while ranking fourth overall.

Why the top of the leaderboard is often the wrong pick

Three problems sit underneath any single leaderboard number, and today's snapshot shows all three. Training overlap: the leaderboard's own zero-shot field shows some top English v2 models trained on about half the tasks they are scored on. Coverage: several of 2026's most-used hosted models have no complete MTEB v2 score, so an average-sorted table cannot rank them, and coverage itself moves, as jina-embeddings-v5-text-small's lost English v2 rank shows. Task mix: the overall MTEB score blends clustering and classification with retrieval, and a model can climb the overall board without getting better at search.

Self-reported numbers add a fourth problem. EmbeddingGemma 2's card reports a higher Multilingual v2 score than version 1, and the leaderboard's own run of the same benchmark puts it lower; both numbers are real, and the gap comes from who ran the evaluation and how. Prefer the leaderboard's run when one exists, and your own when it matters.

Leaderboards also move. Of the models in the comparison table, harrier-oss-v1, jina-embeddings-v5, voyage-4, gemini-embedding-2, granite-embedding R2, Nemotron-3-Embed, Cohere Embed 5, EmbeddingGemma 2, UltraBERT-Embed and Nemotron 3.5 Embed were all released in 2026, four of them in the past month. Re-running your own eval set each quarter, or whenever a candidate appears near the top of RTEB, is cheaper than reacting to every release.

Switching costs and where your data goes

Changing embedding model means re-embedding everything, because vectors from different models are not comparable. Google's documentation says so directly for its own models: gemini-embedding-001 and gemini-embedding-2 produce incompatible spaces and upgrading requires re-embedding all existing data. Three vendors now sell families that share a space across sizes: Voyage's documentation states that all voyage-4 series embeddings are compatible with each other, Cohere says Embed 5 Pro and Fast share one space, with a small reported loss when one tier queries the other's index, and NVIDIA's Nemotron 3.5 Embed-8B produces the same text embeddings as Nemotron-3-Embed-8B, so adding image documents does not force a text re-embed.

Data residency is the other half of the decision. A hosted embedding API receives every chunk of your corpus and every user query; providers differ on retention and training use, and Google's pricing page lists free-tier inputs as used to improve its products while paid-tier inputs are not. Self-hosting an open model keeps text inside your own infrastructure at the price of GPU serving, upgrades and on-call. That trade is the one engineering managers should price explicitly, because the work recurs with every model upgrade.

What a better embedding model will not fix

An embedding model measures similarity, and several common retrieval failures are not similarity problems, a list Galileo's guide, now on Splunk's blog, documents in detail. A query about "2024 Q3 revenue" retrieves revenue passages from every quarter, because the year carries almost no weight in the vector. A query that excludes something ("Python examples without external dependencies") retrieves the excluded thing. And in our study the multi-hop HotpotQA questions failed in a specific way: vector search found the document about the first entity and missed the bridge document about the second, because the bridge document does not look like the query. No embedder upgrade fixes that; it needs metadata filters, reranking, or a stored relationship.

Agent memory adds a harder version of the same problem. When the corpus is conversation history, it grows every turn and contradicts itself: the fact stated in March and the correction in June are both similar to the query, and the vector has no view on which is current, or on whether "my manager" and "Sarah" are the same person. Choosing a better embedding model for that corpus improves which passages come back; it does not decide which of them is still true.

Where Maximem Synap fits

Maximem Synap is a memory layer for AI agents, and one of the things it takes off your plate is this entire decision. Synap runs embedding on Maximem's own infrastructure, so text is not sent to a third-party embedding API for that step, and choosing and upgrading the embedding model is Synap's job, not yours, which matters more in a month with five notable releases.

What sits around the embedder matters more. Synap reads a conversation and stores the facts, preferences and episodes worth keeping instead of raw transcript chunks; retrieval runs several techniques at once and merges them into one ranked answer (Resilient Retrieval); Entity Resolution collapses "my manager", "Sarah" and "Sarah Chen" into one person; and Conscious & Lossless Forgetting stops the agent repeating a fact that has since changed. In-conversation reads come from a cache pre-fetched into your own process, at an asserted P75 under 15 ms. If you are building document RAG, the steps above are the right way to pick a model. If you are building an agent that has to remember users, the embedding model is one component of a memory architecture, and Synap handles that architecture for you.

Frequently asked questions

What is the best open-source embedding model in 2026?

As of 27 October 2026, Qwen3-Embedding (0.6B, 4B or 8B, Apache 2.0, 32K context) is the best default open-source embedding model: the 8B model ranks 5th on MTEB English v2 and 4th on MTEB Multilingual v2, with 95% or more of tasks zero-shot. Microsoft's harrier-oss-v1-27b (MIT) has the highest MTEB Multilingual v2 score at 0.7427, and NVIDIA's Nemotron-3-Embed-8B is the top open model on the retrieval-only RTEB board.

Which embedding model is best for semantic search?

For semantic search, choose by the retrieval column or the RTEB board, since the overall MTEB average mixes retrieval with six other task types. Among open models that points to Qwen3-Embedding-8B, harrier-oss-v1 and Nemotron-3-Embed-8B; among hosted ones, voyage-4-large (1st on RTEB at 2,048 dimensions with evolved prompts, 6th at its default) and gemini-embedding-001. Run whichever you pick inside hybrid search, because exact-match keyword search still wins on identifiers and rare terms; in Maximem's 50,000-document study keyword search won outright on the two entity-heavy datasets and led the average once code search was excluded.

How do I choose an embedding model for RAG?

List your hard constraints (licence, data residency, languages, latency, budget), shortlist four models from the retrieval column of MTEB and from RTEB, then score each on 100 to 200 of your own labelled queries with nDCG@10, Recall@10 and MRR@10 while also recording latency, storage and price. Pick the smallest model and dimension that meets your quality bar, and store raw text separately so a future re-embed is a batch job.

What new embedding models came out in October 2026?

Between 26 September and 27 October 2026, Cohere released Embed 5 (Pro at $0.12 and Fast at $0.08 per 1M text tokens, 128K context, text and images), Google released EmbeddingGemma 2 (Apache 2.0, 8,192 tokens, text, code, image, video and audio), NVIDIA released Nemotron 3.5 Embed in 8B and 1B sizes for text and image documents, Perplexity's pplx-embed-v2 late-interaction models appeared under MIT, and DMIS Lab released UltraBERT-Embed-150M, a 32K-context English model. Only EmbeddingGemma 2 (59th) and UltraBERT-Embed-150M (52nd) have complete MTEB English v2 scores so far.

Is a bigger embedding model always better for RAG?

No. Bigger embedding models usually score higher on public boards, but the gain on your own data can be small while serving cost grows roughly with parameter count; an 8B model needs about 16 GB of GPU memory for weights alone, against about 1.2 GB for a 0.6B model. harrier-oss-v1-0.6b ranks 10th on MTEB Multilingual v2, within 0.06 of the 27B model's mean score at roughly one forty-fifth of the parameters.

Can I use Jina, NVIDIA or EmbeddingGemma models commercially?

It depends on the exact model. jina-embeddings-v5-text-small and NV-Embed-v2 are CC BY-NC 4.0 and llama-embed-nemotron-8b is marked non-commercial or research use only, so all of those need a commercial agreement. NVIDIA's Nemotron-3-Embed-8B and Nemotron 3.5 Embed are released under OpenMDW-1.1 and their cards state they are ready for commercial use. EmbeddingGemma 2 is Apache 2.0 with Google's Gemma prohibited-use policy attached, while EmbeddingGemma-300M remains under Gemma terms. Always read the licence of the specific checkpoint you download, since licences differ within a family.

Does Anthropic have an embedding model?

No. Anthropic's documentation states that it does not offer its own embedding model, and its embeddings guide uses Voyage AI in the examples while suggesting you evaluate several providers. Any model in the table above works with Claude, because the embedder only decides which chunks reach the prompt.

Do I need to re-embed my data if I change embedding models?

Almost always. Vectors from different models live in different spaces and cannot be compared; Google states that gemini-embedding-001 and gemini-embedding-2 are incompatible and require re-embedding. The exceptions are within a family: voyage-4 embeddings are mutually compatible, Cohere Embed 5 Pro and Fast share one space, and Nemotron 3.5 Embed-8B keeps Nemotron-3-Embed-8B's text embeddings. Budget the re-embed as compute time: in Maximem's study, embedding 50,000 documents locally took 161.6 seconds against 2.11 seconds for a keyword index.

Sources, retrieved 27 October 2026: MTEB leaderboard and its API (MTEB English v2, MTEB Multilingual v2, RTEB beta); model cards for Qwen3-Embedding-8B, Qwen3-Embedding-0.6B, Qwen3-VL-Embedding-8B, harrier-oss-v1-27b, harrier-oss-v1-0.6b, Nemotron-3-Embed-8B, Nemotron-3.5-Embed-8B, Nemotron 3.5 Embed 1B, llama-embed-nemotron-8b, Octen-Embedding-8B, EmbeddingGemma 2, EmbeddingGemma-300M, UltraBERT-Embed-150M, pplx-embed-v2, granite-embedding-311m-multilingual-r2, BGE-M3, nomic-embed-text-v2-moe, jina-embeddings-v5-text-small, KaLM-Embedding-Gemma3-12B-2511; Google, EmbeddingGemma 2 announcement (6 October 2026); Cohere, Embed 5 announcement (30 September 2026); ViDoRe V3 introduction, Hugging Face blog; LongEmbed dataset card; Qdrant on Cohere Embed 5 (23 October 2026), pplx-embed-v2 (13 October 2026) and UltraBERT-Embed (19 October 2026); OpenAI embeddings guide and model pages for text-embedding-3-large and text-embedding-3-small; Gemini embeddings documentation and Gemini API pricing; Voyage AI embeddings and pricing; Anthropic embeddings guide; Meilisearch semantic search model comparison (updated 4 August 2026); AIMultiple open-source embedding benchmark (updated 26 September 2026); Galileo, Choosing an Embedding Model for RAG (Splunk blog, 14 September 2026); Maximem, File Search vs Vector Search for RAG; Maximem, Local Embedding Models in 2026.