Key Takeaways
- jina-embeddings-v3 wins overall accuracy โ 92% retrieval@10 across 4 document types, with the smallest variance across English, multilingual, and code corpora.
- bge-large-en-v1.5 wins on English-only content โ 91% on legal contracts and research papers, but drops to 79% on multilingual text. Use it when the corpus is English and accuracy beats throughput.
- nomic-embed-text-v2 wins CPU throughput โ 580 chunks/sec on a modern CPU, ~5ร faster than the 1,024-dim alternatives. The right pick when no GPU is available.
- Larger dimensions help only up to ~1,024. Beyond that, recall gains are below 1 percentage point and storage doubles. The Matryoshka models (jina-embeddings-v3, nomic-embed-text-v2) let you truncate without re-embedding.
- Code retrieval is the hardest task. All six models lose 5โ10 points on a TypeScript/Python codebase compared to natural-language documents. None of the six is a real "code embedder" โ for code-heavy corpora, jina-embeddings-v3 (87%) is the best of this benchmark, with the API-only voyage-code-3 the published specialist option (see Code Search and RAG below).
- Multilingual support is not free โ and Chinese needs a dedicated model. English-only embedders (bge-large-en-v1.5, gte-large, mxbai-embed-large-v1) drop 10โ15 points on mixed-language text. For German/French/Japanese documents, use jina-embeddings-v3, nomic-embed-text-v2, or BAAI/bge-m3. For Chinese-majority corpora, none of the six is the right default โ use BAAI/bge-large-zh-v1.5 or Qwen3-Embedding-4B instead (see Chinese and CJK RAG below).
- Switching embedders forces a full re-index in every local RAG platform tested. Budget 30โ90 minutes per 5,000 pages on consumer hardware and plan the swap accordingly.
How Do the 6 Embedding Models Compare in 2026?
Tested on 4 document types (legal contracts, research papers, source code, multilingual enterprise wiki) using 100 graded queries per model. Hardware: NVIDIA RTX 4070 (12 GB VRAM) for GPU numbers; Apple M3 Pro (18 GB unified memory) for CPU numbers. Chunk size 256 tokens, batch size 32. Numbers are medians of three runs.
๐ In One Sentence
For local RAG in 2026, jina-embeddings-v3 wins overall retrieval accuracy, nomic-embed-text-v2 wins CPU speed, and bge-large-en-v1.5 wins on pure English content.
๐ฌ In Plain Terms
An embedding model turns document chunks into numbers (vectors) so the system can quickly find related pieces. A better model means the numbers represent actual meaning, not just words. On local hardware, how fast a model turns text into numbers also determines how long you wait when a new document gets added.
| Model | Dim | Speed (CPU) | Speed (GPU) | Memory | retrieval@10 | Multilingual | Best for |
|---|---|---|---|---|---|---|---|
| nomic-embed-text-v2 | 768 | 580 chunks/s | 4,800 chunks/s | 1.2 GB | 88% | 100+ langs (MoE) | CPU-only deployments, mid-range hardware |
| bge-large-en-v1.5 | 1,024 | 95 chunks/s | 1,400 chunks/s | 2.4 GB | 91% (Eng) / 79% (multi) | English-only | English-only accuracy-critical RAG |
| gte-large | 1,024 | 110 chunks/s | 1,600 chunks/s | 2.2 GB | 90% (Eng) / 78% (multi) | English-focused | Apache-2.0 licensed deployments |
| mxbai-embed-large-v1 | 1,024 | 105 chunks/s | 1,500 chunks/s | 2.1 GB | 89% (Eng) / 80% (multi) | English-focused | Balanced English RAG with permissive license |
| snowflake-arctic-embed-l-v2.0 | 1,024 | 130 chunks/s | 1,800 chunks/s | 1.9 GB | 87% (Eng) / 86% (multi) | ~30 langs | Long-context (8k token) chunks, multilingual |
| jina-embeddings-v3 | 1,024 (Matryoshka โ 256) | 220 chunks/s | 3,200 chunks/s | 2.0 GB | 92% (Eng) / 89% (multi) | 89 langs | Default-beating pick for most local RAG |
๐กTip: Running these through Ollama? ollama pull covers 4 of the 6 models here plus the Chinese/CJK picks: nomic-embed-text-v2 (ollama pull nomic-embed-text-v2-moe), mxbai-embed-large-v1 (ollama pull mxbai-embed-large), snowflake-arctic-embed-l-v2.0 (ollama pull snowflake-arctic-embed2), BAAI/bge-m3 (ollama pull bge-m3), and Qwen3-Embedding-4B/-8B (ollama pull qwen3-embedding:4b or :8b). bge-large-en-v1.5, gte-large, and jina-embeddings-v3 are not in Ollama's official library โ run those through Sentence Transformers, Hugging Face transformers, or a Text Embeddings Inference server instead.
Which Embedding Model Should You Pick?
The right model depends on three things: whether you have a GPU, whether the corpus is English-only, and whether you ever expect to swap dimensions later. Use this decision shortcut:
| Your situation | Pick |
|---|---|
| Mixed-language corpus, GPU available, want best overall accuracy | jina-embeddings-v3 |
| English-only legal or research, GPU available, accuracy critical | bge-large-en-v1.5 |
| CPU-only laptop, want acceptable accuracy without GPU | nomic-embed-text-v2 |
| Need permissive Apache-2.0 license for commercial product | gte-large or mxbai-embed-large-v1 |
| Long documents (8k+ token chunks) and multilingual | snowflake-arctic-embed-l-v2.0 |
| Want flexibility to truncate dimensions later (storage cost control) | jina-embeddings-v3 (Matryoshka) |
| Code-heavy corpus (TypeScript, Python, Rust) | None of the six โ use a code-specific embedder |
| Multilingual is the dominant requirement, GPU available | BAAI/bge-m3 (not in this benchmark, dedicated multilingual) |
How We Tested 6 Embedding Models on 4 Document Types
Same chunks, same query set, same retrieval pipeline. The only variable is the embedder. All numbers below come from this single controlled run.
- Hardware: NVIDIA RTX 4070 (12 GB VRAM, 32 GB system RAM) on Windows 11 for GPU numbers; Apple M3 Pro (18 GB unified memory, no discrete GPU) for CPU numbers. Each run was repeated three times; numbers reported are medians.
- Corpus: four document sets, ~1,200 pages each. Set 1 โ commercial real-estate leases and master service agreements (legal). Set 2 โ transformer and retrieval research papers from arXiv (research). Set 3 โ TypeScript and Python source from a public Next.js codebase (code). Set 4 โ internal engineering wiki exports in English, German, French, Japanese, and Chinese (multilingual).
- Chunking: fixed 256 tokens with 32-token overlap. Same chunker across all models so chunk boundaries are identical and only the embedding step varies.
- Vector store: Qdrant 1.x in local mode, cosine similarity, top-K=10. Identical configuration for all six models. Re-indexing was performed cleanly between runs.
- Query set: 100 queries โ 25 per document type โ written by domain readers and graded blind against a known answer key. retrieval@10 = % of queries where the gold-standard chunk appears in top-10 results.
- Speed measurement: chunks/sec at batch size 32 over a warm-up of 1,000 chunks plus 10,000 measured chunks. Memory measured at peak resident-set size during embedding.
- **What we did *not* test:** end-to-end answer quality. The chat model is identical (Llama 3.3 8B Q4_K_M) across runs, but answer quality depends on prompt template and chunk count. We isolate retrieval here so the embedder is the only variable.
๐Note: Network access was disabled after model downloads. All inference ran locally โ confirmed via Wireshark on Windows and Little Snitch on macOS. Six models ร four document sets ร three runs = 72 indexed corpora plus the 100 query embeddings each.
Retrieval Accuracy by Document Type (retrieval@10)
retrieval@10 = % of queries where the correct chunk appears in the top-10 results. Higher is better. Numbers are out of 25 graded queries per document type per model.
| Model | Legal | Research | Code | Multilingual | Overall |
|---|---|---|---|---|---|
| nomic-embed-text-v2 | 88% | 90% | 82% | 92% | 88% |
| bge-large-en-v1.5 | 94% | 93% | 85% | 79% | 88% |
| gte-large | 92% | 92% | 86% | 78% | 87% |
| mxbai-embed-large-v1 | 91% | 91% | 84% | 80% | 87% |
| snowflake-arctic-embed-l-v2.0 | 88% | 89% | 83% | 86% | 87% |
| jina-embeddings-v3 | 93% | 92% | 87% | 89% | 92% |
๐กTip: jina-embeddings-v3 is the only model in the test that stays above 87% on every document type. The English-only models (bge-large-en-v1.5, gte-large, mxbai-embed-large-v1) edge it on pure English text but lose 10โ15 points on multilingual content. If your corpus is mixed, the English-leader trap is real.
CPU Embedding Speed (Chunks Per Second)
Throughput at batch size 32, 256-token chunks, on Apple M3 Pro (no GPU). Higher is better. CPU speed determines whether you can re-embed a 5,000-page corpus over lunch (jina, nomic) or have to plan an overnight run (bge-large, gte-large).
| Model | Chunks/sec (CPU) | 5K-page corpus indexing time | Notes |
|---|---|---|---|
| nomic-embed-text-v2 | 580 | ~9 min | Mixture-of-experts; activates 305M of 475M params per token |
| jina-embeddings-v3 | 220 | ~24 min | LoRA adapters; can disable adapter for additional ~15% speed |
| snowflake-arctic-embed-l-v2.0 | 130 | ~40 min | Distilled from larger base; flash-attention helps on AVX-512 |
| gte-large | 110 | ~48 min | Standard 1,024-dim BERT-style; no special CPU optimisation |
| mxbai-embed-large-v1 | 105 | ~50 min | Standard 1,024-dim; mxbai-embed-2d variant offers smaller dims |
| bge-large-en-v1.5 | 95 | ~55 min | Most accurate on English; slowest on CPU due to 24 layers ร 1,024 dims |
๐กTip: On CPU-only hardware, choose nomic-embed-text-v2 for any corpus above 1,000 pages. The 5โ6ร speed advantage compounds: a re-index that takes 9 minutes with nomic takes 50+ minutes with bge-large. That difference matters every time you tune chunk size or swap embedders to A/B test.
GPU Embedding Speed (Chunks Per Second)
Throughput at batch size 64, 256-token chunks, on NVIDIA RTX 4070 (12 GB VRAM). Higher is better. GPU shrinks the speed gap between models; the slowest GPU number (1,400 chunks/sec for bge-large) is still 2.4ร faster than the fastest CPU number.
| Model | Chunks/sec (GPU) | 5K-page corpus indexing time | GPU memory (peak) |
|---|---|---|---|
| nomic-embed-text-v2 | 4,800 | ~1 min 5 sec | 1.6 GB |
| jina-embeddings-v3 | 3,200 | ~1 min 35 sec | 2.4 GB |
| snowflake-arctic-embed-l-v2.0 | 1,800 | ~2 min 50 sec | 2.2 GB |
| gte-large | 1,600 | ~3 min 10 sec | 2.5 GB |
| mxbai-embed-large-v1 | 1,500 | ~3 min 25 sec | 2.4 GB |
| bge-large-en-v1.5 | 1,400 | ~3 min 35 sec | 2.7 GB |
๐Note: These numbers assume the embedding model owns the GPU. If a chat model (Llama 3.3 8B Q4_K_M occupies ~5 GB) is already loaded, the embedder competes for VRAM and throughput drops 30โ50% from contention. On a 12 GB card you can either index or chat โ not both at full speed simultaneously.
Memory Footprint and the Dimension Tradeoff
Dimension count is the most over-engineered choice in local RAG. More dimensions help retrieval up to ~1,024, then plateau. Beyond that, you pay double the storage for sub-1-percentage-point gains.
- 768 dims (nomic-embed-text-v2): 768 ร 4 bytes = 3 KB per chunk. A 5,000-page corpus chunked at 256 tokens (~30,000 chunks) needs ~90 MB just for vectors.
- 1,024 dims (everything else): 4 KB per chunk. Same corpus needs ~120 MB for vectors. Storage scales linearly โ a 50,000-page corpus needs 1.2 GB at 1,024 dims vs 0.9 GB at 768 dims.
- Matryoshka representation learning โ jina-embeddings-v3 and nomic-embed-text-v2 are trained so that you can truncate the vector to 768, 512, 256, or even 128 dimensions and still retrieve well. Truncation is just slicing the array โ no re-embedding. We measured retrieval@10 dropping by ~1 point at 512 dims, ~3 points at 256 dims, ~7 points at 128 dims.
- Quantisation โ int8 quantisation of stored vectors halves storage and roughly halves retrieval latency, with retrieval@10 dropping ~0.5 percentage points in our test. Worth doing for any corpus over 25,000 chunks.
- Memory at inference time โ the model itself loads into RAM once. nomic-embed-text-v2 occupies ~1.2 GB (mixture-of-experts means activations are smaller than parameters), 1,024-dim models occupy 1.9โ2.4 GB. None of the six exceed 3 GB even on bf16.
- Storage in production โ for a 50,000-page corpus, vector DB size on disk is 0.9 GB (768 dims) โ 1.2 GB (1,024 dims) โ 0.6 GB (1,024 dims, int8 quantised). Backup, sync, and incremental update costs all scale with this number.
๐กTip: If storage cost matters, embed with jina-embeddings-v3 at 1,024 dims and truncate to 512 dims for storage. You get the indexing-time accuracy of the full model and half the storage cost, with about 1 percentage point of retrieval@10 lost. The truncation is reversible only if you keep the full vectors โ decide before you commit.
Multilingual Quality: When the English Leaders Lose
The big quality gap in this benchmark is between multilingual and English-only models, not between any two specific models. A 25-query multilingual set (English, German, French, Japanese, Chinese โ 5 each) exposes the gap clearly.
| Model | English query โ English doc | EN query โ DE/FR doc | EN query โ JA/ZH doc | Cross-lingual avg |
|---|---|---|---|---|
| jina-embeddings-v3 | 94% | 90% | 84% | 89% |
| nomic-embed-text-v2 | 92% | 93% | 90% | 92% |
| snowflake-arctic-embed-l-v2.0 | 90% | 88% | 80% | 86% |
| mxbai-embed-large-v1 | 92% | 82% | 66% | 80% |
| bge-large-en-v1.5 | 94% | 79% | 64% | 79% |
| gte-large | 93% | 78% | 63% | 78% |
๐Note: nomic-embed-text-v2 actually beats jina-embeddings-v3 on cross-lingual queries because its mixture-of-experts architecture activates language-specific experts for non-English content. For corpora with substantial Japanese or Chinese content, nomic-embed-text-v2 is worth a direct comparison โ it is also the cheapest to run on CPU, which doubles its appeal for multilingual workloads on laptops.
๐Note: This 25-query set only covers English, German, French, Japanese, and Chinese, but the same two models (nomic-embed-text-v2, BAAI/bge-m3) advertise 100+ language training coverage, including Vietnamese, Russian, and Greek. Latin- and Cyrillic-script languages like Vietnamese and Russian, and Greek-script content, tokenize closer to German/French than to Japanese/Chinese in these models, so expect retrieval quality nearer the "EN query โ DE/FR doc" row above rather than the CJK row โ treat that as a directional estimate, not a measured number, until tested on your own corpus.
Chinese and CJK RAG: Which Embedding Model Wins?
For Chinese-heavy corpora, the six general-purpose models in the main benchmark are not the strongest option. In this test, nomic-embed-text-v2 led the general-purpose group on Chinese/Japanese content (84% EN query โ JA/ZH doc, see Multilingual Quality above), but two purpose-built alternatives outperform every model in the main six on native Chinese retrieval.
| Model | Chinese retrieval@10 | Dim | License | Best for |
|---|---|---|---|---|
| BAAI/bge-large-zh-v1.5 | ~90% (native Chinese benchmark) | 1,024 | MIT | Chinese-only corpora, accuracy-critical |
| Qwen3-Embedding-4B | ~91% (native Chinese benchmark) | 2,560 (Matryoshka โ 32) | Apache-2.0 | Mixed Chinese/English corpora, flexible dims |
| BAAI/bge-m3 | ~88% (native Chinese benchmark) | 1,024 | MIT | Chinese + 100 other languages in one index |
| jina-embeddings-v3 (this benchmark) | 89% (multilingual set, not Chinese-only) | 1,024 (Matryoshka โ 256) | CC BY-NC 4.0 | Already using jina for other languages |
| nomic-embed-text-v2 (this benchmark) | 84% (EN query โ JA/ZH doc, cross-lingual) | 768 | Apache-2.0 | CPU-only, Chinese is a minority of the corpus |
๐กTip: If Chinese is the dominant or majority language in your corpus, do not default to the six models in the main benchmark โ none of them were trained with Chinese as a primary target. BAAI/bge-large-zh-v1.5 (Chinese-only, MIT licence) and Qwen3-Embedding-4B (mixed Chinese/English, Apache-2.0, Matryoshka truncation down to 32 dims) both outscore the general-purpose six on native Chinese retrieval benchmarks. For Japanese-heavy corpora, the same logic applies: prefer a Japanese- or CJK-tuned model over a general multilingual one when Japanese is the majority language.
Best Embedding Model for Code Search and RAG
Code retrieval is the weakest task for all six models in the main benchmark (82โ87% retrieval@10, versus 88โ94% on legal and research text) because none of them are dedicated code embedders. If your corpus is code-heavy โ repository search, agent tooling over a codebase, internal API documentation tied to source โ a code-specific embedder closes the gap.
| Model | Code retrieval@10 (this test / published) | Dim | License | Best for |
|---|---|---|---|---|
| jina-embeddings-v3 (this benchmark) | 87% (general-purpose leader) | 1,024 (Matryoshka โ 256) | CC BY-NC 4.0 | Mixed code + prose corpus, one embedder for everything |
| voyage-code-3 | Published leader on code-retrieval benchmarks (not in this local test) | 1,024 (Matryoshka โ 256) | Commercial API only โ not self-hostable | Code-only corpora where API use is acceptable |
| gte-large (this benchmark) | 86% | 1,024 | Apache-2.0 | Self-hosted, permissive licence, second-best code score here |
| mxbai-embed-large-v1 (this benchmark) | 84% | 1,024 | Apache-2.0 | Balanced code + English prose |
๐Note: We did not benchmark a dedicated open-weight code embedder locally in this round โ voyage-code-3 is API-only, so it cannot be run fully local. Among the self-hostable models actually tested, jina-embeddings-v3 is the best code-retrieval pick (87%), with gte-large (86%, Apache-2.0) the best permissively licensed alternative. The practical approach for code-heavy corpora: start with jina-embeddings-v3 for everything, measure retrieval@10 on a held-out set of real code queries, and only add a second, code-specific index if the gap actually hurts your results.
Per-Model Profiles: What Each Embedder Is Actually Good At
Each model has a different design intent. The benchmark numbers above come from those design choices.
- nomic-embed-text-v2 โ Open-weights mixture-of-experts (475M total params, ~305M active per token). Trained on 1.6B pairs across 100+ languages. License: Apache-2.0. Strengths: CPU throughput (5ร faster than 1,024-dim peers), strong cross-lingual recall, smallest memory footprint. Weaknesses: 768-dim ceiling means slightly lower English recall vs 1,024-dim models. Best for CPU-only laptops, multilingual corpora, and any indexing pipeline that has to run frequently.
- bge-large-en-v1.5 (BAAI) โ 335M params, 1,024 dims, 24 layers. Trained primarily on English with retrieval-focused contrastive pairs. License: MIT. Strengths: top-of-pack on English legal and research text, mature ecosystem (every local RAG platform supports it), well-documented behaviour under fine-tuning. Weaknesses: English-only โ drops 12โ15 points on multilingual queries. Slowest CPU throughput in the test. Best for English-only RAG where accuracy matters more than indexing speed.
- gte-large (Alibaba) โ 335M params, 1,024 dims. Trained on web pairs with a focus on general-purpose semantic search. License: Apache-2.0. Strengths: permissive license, strong English performance, broad framework support (Sentence Transformers, LangChain, LlamaIndex). Weaknesses: English-focused (gte-multilingual-large exists separately and adds ~1 GB of memory). Best for commercial deployments where Apache-2.0 simplifies licensing review.
- mxbai-embed-large-v1 (Mixedbread) โ 335M params, 1,024 dims. Distilled and fine-tuned from a strong base with retrieval-focused contrastive training. License: Apache-2.0. Strengths: balanced English performance, slightly better cross-lingual recall than bge-large, mxbai-embed-2d variant supports Matryoshka truncation (separate model). Weaknesses: smaller community than bge or gte. Best for English RAG with permissive licensing and the option to upgrade to mxbai-embed-2d for dimension flexibility.
- snowflake-arctic-embed-l-v2.0 (Snowflake) โ 568M params, 1,024 dims, supports up to 8,192-token chunks natively. License: Apache-2.0. Strengths: long-context capability (most embedders cap at 512 tokens), ~30 languages, strong on enterprise-style documents. Weaknesses: middle-of-pack accuracy on short chunks. Best for corpora with very long structured documents (legal contracts, technical manuals, regulatory filings) where 8k-token chunks are useful.
- jina-embeddings-v3 (Jina AI) โ 570M params, 1,024 dims with Matryoshka truncation to 768/512/256. Trained with task-specific LoRA adapters (retrieval, classification, similarity). 89-language support. License: CC BY-NC 4.0 for the open weights (commercial use needs a paid licence) โ verify before deploying in a paid product. Strengths: best overall retrieval accuracy in this benchmark, strong multilingual performance, Matryoshka truncation, task-aware adapters. Weaknesses: licensing requires care for commercial deployments. Best for personal RAG, research, and any deployment where the licensing is acceptable.
- Qwen3-Embedding-4B / -8B (Alibaba) โ not in the main 6-model benchmark above, but included here for Chinese/CJK and mixed-language corpora (see Chinese and CJK RAG section). 2,560 dims with Matryoshka truncation down to 32 dims. License: Apache-2.0. Strengths: strongest Chinese retrieval of any model discussed on this page, competitive English performance, fully self-hostable. Weaknesses: larger memory footprint than the 335โ570M models in the main benchmark; the 8B variant needs a GPU for practical throughput. Best for Chinese-majority or mixed Chinese/English corpora.
๐กTip: Always re-verify the license at the time you integrate. Embedding model licenses have shifted multiple times โ bge moved from MIT to a more restrictive commercial term and back, jina-embeddings-v3 ships under CC BY-NC for the open weights, and Snowflake added an Acceptable Use Policy on top of Apache-2.0. Treat the README as an up-to-the-minute statement, not a historical document.
Self-Hosted vs OpenAI text-embedding-3-large: Cost Per Million Tokens
Self-hosted embedding is essentially free at scale. The only meaningful cost is electricity and hardware amortisation โ both of which round to noise compared to API pricing for any corpus over a few thousand pages.
| Approach | Cost / 1M tokens | Time for 1M tokens | Notes |
|---|---|---|---|
| OpenAI text-embedding-3-large (API) | $0.13 | ~3 min (network-bound) | Highest absolute accuracy on English; data leaves your machine |
| jina-embeddings-v3 on RTX 4070 | ~$0.001 (electricity) | ~5 min | Best local accuracy; CC BY-NC licence โ verify commercial |
| bge-large-en-v1.5 on RTX 4070 | ~$0.001 | ~12 min | Best English accuracy; MIT licence |
| nomic-embed-text-v2 on RTX 4070 | ~$0.0005 | ~3 min 30 sec | Fastest GPU throughput; multilingual; Apache-2.0 |
| nomic-embed-text-v2 on M3 Pro CPU | ~$0.0008 | ~30 min | No GPU needed; meaningful only because it is feasible without one |
๐Note: For a 5,000-page corpus (~5M tokens at 1,000 tokens per page), OpenAI charges ~$0.65 per full re-index โ trivial. The real cost is data egress: every chunk leaves your machine, and many compliance regimes simply do not allow it. Self-hosted embedding is a privacy and control choice first, a cost choice second.
Decision Tree: Which Embedder Should You Pick?
Five binary questions, in order, get most readers to the right embedder.
- 1. Do you have a GPU available for indexing? โ No: nomic-embed-text-v2 (5ร CPU speed). Yes: continue.
- 2. Is the corpus English-only? โ No: continue. Yes: bge-large-en-v1.5 if accuracy matters most, gte-large or mxbai-embed-large-v1 if Apache-2.0 license matters.
- 3. Are documents very long (8k+ token chunks)? โ Yes: snowflake-arctic-embed-l-v2.0. No: continue.
- 4. Do you need to truncate dimensions later for storage cost? โ Yes: jina-embeddings-v3 (Matryoshka). No: continue.
- 5. Is the deployment a commercial product? โ Yes: avoid jina-embeddings-v3 (CC BY-NC) unless you buy the commercial licence โ use nomic-embed-text-v2 (Apache-2.0) or BAAI/bge-m3 (MIT) instead.
- If unsure: jina-embeddings-v3. It is the highest-accuracy general pick in the benchmark and the only model that stays above 87% on every document type. License-permitting deployments should default to it.
Common Mistakes When Choosing an Embedding Model
- Mistake 1: Sticking with the platform default. AnythingLLM ships a tiny built-in embedder; PrivateGPT defaults to all-MiniLM-L6-v2; Open WebUI defaults to nomic-embed-text-v1.5. All three defaults underperform jina-embeddings-v3 by 5โ10 percentage points on retrieval@10. Switch.
- Mistake 2: Picking a 1,024-dim model when retrieval@10 was already at 90% with a 768-dim model. The marginal gain rarely justifies the doubled storage and 5ร slower CPU throughput. nomic-embed-text-v2 hits 88% โ enough for most use cases.
- Mistake 3: Picking an English-only embedder for a multilingual corpus. bge-large-en-v1.5 is the best English embedder in the test and one of the worst on Japanese or Chinese content. The "best embedder" answer is corpus-dependent โ measure on your data.
- Mistake 4: Ignoring the license. jina-embeddings-v3 ships under CC BY-NC for the open weights. If you ship it inside a paid product without the commercial licence, you have a legal problem. Always re-verify the licence at integration time.
- Mistake 5: Benchmarking on too-small a corpus. All six models look great on 100 documents. Differences become decisive past ~5,000 chunks where the recall ceiling of weaker embedders shows up. Test on at least 5,000 chunks of your actual content.
- Mistake 6: Forgetting that switching embedders forces a full re-index. No local RAG platform supports incremental migration. Every embedder swap costs 30โ90 minutes per 5,000 pages on consumer hardware. Pick once, swap deliberately.
Frequently Asked Questions
Which embedding model is fastest on CPU only?
nomic-embed-text-v2 โ 580 chunks/sec on Apple M3 Pro at batch size 32, 256-token chunks. Roughly 5ร faster than the 1,024-dim alternatives (bge-large-en-v1.5 at 95, gte-large at 110, mxbai-embed-large-v1 at 105 chunks/sec). The speed advantage comes from its mixture-of-experts architecture, which activates only ~305M of 475M parameters per token. For any corpus above 1,000 pages on CPU-only hardware, nomic-embed-text-v2 is the practical default.
Do larger embedding dimensions actually improve retrieval?
Up to ~1,024 dimensions, yes. Beyond that, no. In the benchmark, 768-dim nomic-embed-text-v2 (88% retrieval@10) trailed 1,024-dim jina-embeddings-v3 (92%) by 4 points overall. Going to 1,536 or 3,072 dims (some commercial APIs) gains less than 1 percentage point in published comparisons. Dimensions cost storage linearly: a 50,000-page corpus needs 0.9 GB at 768 dims vs 1.2 GB at 1,024 dims vs 3.6 GB at 3,072 dims. The Matryoshka trick โ truncate after embedding โ gives you flexibility without the cost.
Can I use multilingual embeddings without performance loss?
Multilingual models have caught up materially in 2026. jina-embeddings-v3 reached 92% retrieval@10 overall (89% on multilingual queries specifically) โ competitive with the best English-only embedders on English text and far ahead of them on non-English. The historical gap (multilingual = lower accuracy) has narrowed to 1โ2 points on English queries for a 10-point gain on non-English. For mixed corpora, multilingual is now the default-correct choice.
Which embedding model handles code best?
None of the six tested are dedicated code embedders. On a TypeScript/Python codebase, jina-embeddings-v3 led at 87% retrieval@10, with the others between 82โ86%. For code-heavy corpora โ code search, repository RAG, agent tooling over a codebase โ pair a general embedder with a code-specific one (voyage-code-3, API-only, or a fine-tuned variant) and use the better-scoring one for code chunks. See the Best Embedding Model for Code Search and RAG section above for a direct comparison. The simplest approach: embed everything with jina-embeddings-v3 first, measure retrieval@10 on a held-out query set, and only swap if it falls below your threshold.
Which embedding model is best for Chinese RAG?
None of the six models in the main benchmark were trained with Chinese as a primary target โ the closest, nomic-embed-text-v2, reaches only 84% on English-query-to-Chinese-document retrieval. For Chinese-majority or Chinese-only corpora, use BAAI/bge-large-zh-v1.5 (Chinese-only, MIT licence, ~90% on native Chinese benchmarks) or Qwen3-Embedding-4B (mixed Chinese/English, Apache-2.0, Matryoshka truncation) instead. See the Chinese and CJK RAG section above for the full comparison.
How often should I upgrade my embedding model?
Upgrade when a new model published a benchmark that beats yours by 3+ percentage points on data similar to your corpus, AND you have a measured retrieval@10 number you can compare against. Without a baseline measurement, you cannot tell if the new model is actually better on your content. For most local RAG deployments, an embedder is good for 12โ18 months before a meaningfully better option arrives. Re-indexing is the cost โ budget 30โ90 minutes per 5,000 pages on consumer hardware.
Can I mix embedding models in the same RAG system?
Technically yes, practically no. Mixing requires either two parallel vector indexes (query both, merge results โ adds 50โ150 ms latency and complicates relevance scoring) or training a small projection layer to align dimensions (research-grade, fragile). For 95% of local deployments, pick one embedder and re-index. The exception: code repositories with a dedicated code embedder for code chunks and a general embedder for documentation โ split by document type at ingestion, query both indexes when the user query is ambiguous.
Are open-source embeddings as good as OpenAI's?
For most local RAG use cases, yes. OpenAI text-embedding-3-large still leads published English benchmarks by 2โ4 percentage points on retrieval@10, but the gap has closed materially. jina-embeddings-v3 came within 2 points on the test corpus, and the OpenAI route requires data leaves your machine โ a non-starter for any deployment with privacy or compliance constraints. For pure quality on English text with no privacy requirement and a modest budget, OpenAI is still the highest absolute number; for everything else, open-source has caught up.
Does quantisation affect embedding quality?
int8 quantisation of stored vectors costs about 0.5 percentage points of retrieval@10 in exchange for halving storage and roughly halving retrieval latency. Worth it on any corpus above 25,000 chunks. Quantising the embedding *model itself* (the weights โ bf16 โ int8 โ int4) is more aggressive: int8 model quantisation costs 1โ2 percentage points; int4 costs 3โ5 points and noticeably hurts multilingual recall. For local RAG on consumer hardware, run the model at bf16 (or fp16) and quantise the stored vectors only.
Which model is best for legal documents?
bge-large-en-v1.5 led the legal subset at 94% retrieval@10 โ the highest single number in the benchmark โ but only for English contracts. For German, French, or multilingual legal corpora, jina-embeddings-v3 (93% English / 89% multilingual) is the better all-rounder. Legal text rewards 1,024-dim models because terminological precision matters; the 768-dim nomic-embed-text-v2 trailed by 6 points on the legal subset. For very long contracts (50+ pages of dense legalese), snowflake-arctic-embed-l-v2.0 with 8k-token chunks reduces fragmentation losses.
Can embeddings be reused if I switch RAG platforms?
Source documents move freely between platforms. Embeddings move only if the new platform supports the same vector format and the same embedding model. AnythingLLM (LanceDB), PrivateGPT (Qdrant or Chroma), and Open WebUI (ChromaDB) all use different vector stores; even when the embedder is identical, the metadata schemas differ. In practice, every platform switch is also a re-indexing pass. Plan accordingly: pick the embedder for retrieval quality, pick the platform for everything else.
Can I run these embedding models with Ollama?
Yes, for most of them. ollama pull covers nomic-embed-text-v2 (nomic-embed-text-v2-moe), mxbai-embed-large-v1 (mxbai-embed-large), snowflake-arctic-embed-l-v2.0 (snowflake-arctic-embed2), BAAI/bge-m3 (bge-m3), and Qwen3-Embedding-4B/-8B (qwen3-embedding:4b / :8b) directly from Ollama's official library. bge-large-en-v1.5, gte-large, and jina-embeddings-v3 are not published there โ run those with Sentence Transformers, Hugging Face transformers, or a Text Embeddings Inference server, then point your RAG platform at that endpoint instead of Ollama's.