Points clés
- jina-embeddings-v3 gagne en précision globale — 92% retrieval@10 sur 4 types, variance minimale sur texte anglophone, multilingue et code.
- bge-large-en-v1.5 gagne sur contenu anglophone pur — 91% contrats et recherche, mais chute à 79% sur texte multilingue. À privilégier quand corpus anglophone et précision prioritaire.
- nomic-embed-text-v2 gagne en débit CPU — 580 chunks/sec sur CPU moderne, ~5× plus rapide que alternatives 1 024-dim. Choix correct sans GPU.
- Dimensions utiles seulement jusqu'à ~1 024. Au-delà, gains <1 point et stockage doublé. Modèles Matryoshka (jina-embeddings-v3, nomic-embed-text-v2) permettent troncature sans ré-embedding.
- Retrieval sur code est tâche la plus difficile. Les six perdent 5–10 points sur codebase TypeScript/Python. Aucun n'est vrai « code embedder » — corpora lourds en code nécessitent modèle spécialisé.
- Support multilingue ne vient pas gratuitement. Embedders anglophone seul (bge-large-en-v1.5, gte-large, mxbai-embed-large-v1) perdent 10–15 points sur texte mélangé. Documents allemand/français/japonais/chinois : utilisez jina-embeddings-v3, nomic-embed-text-v2 ou BAAI/bge-m3.
- Changer d'embedder force ré-index complet. Aucune plateforme RAG locale ne supporte migration incrémentale. Budget 30–90 min par 5 000 pages sur matériel grand public.
Comparaison des 6 modèles 2026
Testés sur 4 types (contrats légaux, articles recherche, code, wiki multilingue) avec 100 requêtes notées. Hardware : RTX 4070 (12 GB) GPU ; M3 Pro (18 GB mémoire unifiée) CPU. Chunk 256 tokens, batch 32. Médianes de trois exécutions.
| Modèle | Dim | Vitesse CPU | Vitesse GPU | Mémoire | retrieval@10 | Multilingue | Meilleur pour |
|---|---|---|---|---|---|---|---|
| nomic-embed-text-v2 | 768 | 580 chunks/s | 4 800 chunks/s | 1,2 GB | 88% | 100+ langues (MoE) | Déploiements CPU-only, matériel mid-range |
| bge-large-en-v1.5 | 1 024 | 95 chunks/s | 1 400 chunks/s | 2,4 GB | 91% (EN) / 79% (multi) | Anglophone seul | RAG critique anglophone |
| gte-large | 1 024 | 110 chunks/s | 1 600 chunks/s | 2,2 GB | 90% (EN) / 78% (multi) | Anglophone prioritaire | Déploiements Apache-2.0 |
| mxbai-embed-large-v1 | 1 024 | 105 chunks/s | 1 500 chunks/s | 2,1 GB | 89% (EN) / 80% (multi) | Anglophone prioritaire | RAG anglophone, licence permissive |
| snowflake-arctic-embed-l-v2.0 | 1 024 | 130 chunks/s | 1 800 chunks/s | 1,9 GB | 87% (EN) / 86% (multi) | ~30 langues | Long-context (8k tokens), multilingue |
| jina-embeddings-v3 | 1 024 (Matryoshka → 256) | 220 chunks/s | 3 200 chunks/s | 2,0 GB | 92% (EN) / 89% (multi) | 89 langues | Choix par défaut RAG local |
Quel modèle choisir ?
Trois critères : GPU disponible, corpus anglophone seul, dimension flexible. Guide rapide :
| Situation | Choisir |
|---|---|
| Corpus mélangé, GPU, précision maximale | jina-embeddings-v3 |
| Contrats/recherche anglophone, GPU, critère précision | bge-large-en-v1.5 |
| Laptop CPU-only, précision acceptable sans GPU | nomic-embed-text-v2 |
| Licence Apache-2.0 requise produit commercial | gte-large ou mxbai-embed-large-v1 |
| Documents longs (8k+ tokens), multilingue | snowflake-arctic-embed-l-v2.0 |
| Troncature dimension future (contrôle coût storage) | jina-embeddings-v3 (Matryoshka) |
| Corpus lourd code (TypeScript, Python, Rust) | Aucun — embedder code spécialisé |
| Multilingue dominant, GPU disponible | BAAI/bge-m3 (non dans benchmark) |
Méthodologie : 6 modèles sur 4 types de documents
Même chunks, même requêtes, même pipeline. Variable unique : embedder. Tous chiffres ci-dessous d'une exécution contrôlée.
- Hardware : RTX 4070 (12 GB VRAM, 32 GB RAM) Windows 11 pour GPU ; M3 Pro (18 GB mémoire unifiée) pour CPU. Trois exécutions ; chiffres rapportés sont médianes.
- Corpus : quatre ensembles, ~1 200 pages chacun. Set 1 — contrats immobiliers et services (légal). Set 2 — articles transformer et retrieval arXiv (recherche). Set 3 — TypeScript/Python codebase public Next.js (code). Set 4 — wiki engineering interne : EN, DE, FR, JA, ZH (multilingue).
- Chunking : 256 tokens fixes, 32-token overlap. Même chunker tous modèles donc limites chunks identiques.
- Vecteur store : Qdrant 1.x local, cosine similarity, top-K=10. Configuration identique tous modèles.
- Requêtes : 100 — 25 par type — écrites experts, notées contre clé réponse. retrieval@10 = % requêtes où chunk gold dans top-10.
- Vitesse : chunks/sec batch 32, chauffage 1 000 chunks + 10 000 chunks mesurés. Mémoire : peak RSS durant embedding.
- Non testé : qualité réponse end-to-end. Modèle chat identique (Llama 3.3 8B Q4_K_M) tous tests, mais qualité dépend template et chunk count.
📌Note: Réseau désactivé après téléchargement. Inférence 100% local — vérifié Wireshark/Little Snitch. Six modèles × quatre corpora × trois exécutions = 72 indexes + 100 embeddings requêtes chacun.
Précision retrieval par type (retrieval@10)
retrieval@10 = % requêtes où chunk correct dans top-10. Plus haut mieux. Basé 25 requêtes notées par type par modèle.
| Modèle | Légal | Recherche | Code | Multilingue | Global |
|---|---|---|---|---|---|
| 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 seul reste >87% sur tous types. Modèles anglophone seul (bge, gte, mxbai) excellent anglophone pur mais perdent 10–15 points multilingue. Corpus mixte : le piège « meilleur anglophone » est réel.
Vitesse CPU (Chunks par seconde)
Débit batch 32, chunks 256-tokens, M3 Pro sans GPU. Plus rapide réindexe corpus 5K pages midi (jina, nomic) ou planifie nuit (bge, gte).
| Modèle | Chunks/sec CPU | Temps index 5K pages | Notes |
|---|---|---|---|
| nomic-embed-text-v2 | 580 | ~9 min | MoE ; active 305M de 475M params/token |
| jina-embeddings-v3 | 220 | ~24 min | Adapters LoRA ; désactiver pour ~15% plus rapide |
| snowflake-arctic-embed-l-v2.0 | 130 | ~40 min | Distillé ; flash-attention aide AVX-512 |
| gte-large | 110 | ~48 min | 1 024-dim BERT standard ; pas opt CPU |
| mxbai-embed-large-v1 | 105 | ~50 min | 1 024-dim ; variante -2d offre dims plus petits |
| bge-large-en-v1.5 | 95 | ~55 min | Plus précis anglophone ; plus lent CPU 24 couches |
💡Tip: CPU seul, corpus >1 000 pages : choisir nomic-embed-text-v2. Avantage 5–6× s'accumule : 9 min nomic vs 50+ min bge. Compte à chaque tuning chunk size.
Vitesse GPU (Chunks par seconde)
Débit batch 64, chunks 256-tokens, RTX 4070 (12 GB). GPU réduit écart modèles ; slowest GPU (1 400 chunks/sec bge) 2.4× plus rapide fastest CPU.
| Modèle | Chunks/sec GPU | Temps index 5K pages | Mémoire GPU (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: Chiffres supposent embedder propriétaire GPU. Modèle chat (Llama 3.3 8B Q4_K_M ~5 GB) déjà chargé : embedder en contention, débit baisse 30–50%. Carte 12 GB : indexer OU chatter — pas les deux pleine vitesse.
Mémoire et dimensions
Dimension est choix le plus sur-construit RAG local. Aide retrieval jusqu'à ~1 024, puis plateau. Au-delà : gains <1 point, storage doublé.
- 768 dims (nomic-embed-text-v2) : 768 × 4 bytes = 3 KB/chunk. Corpus 5K pages chunked 256 tokens (~30K chunks) = ~90 MB vecteurs.
- 1 024 dims (autres) : 4 KB/chunk. Corpus 5K pages = ~120 MB. Storage linéaire — 50K pages = 1.2 GB à 1 024 dims vs 0.9 GB à 768 dims.
- Matryoshka — jina-embeddings-v3 et nomic-embed-text-v2 trainés pour troncature 768/512/256/128 sans ré-embedding. Juste slice array. Retrieval@10 baisse ~1 point à 512 dims, ~3 à 256, ~7 à 128.
- Quantisation int8 : réduit storage moitié, latency retrieval moitié, retrieval@10 baisse ~0.5 points. Vaut corpus >25K chunks.
- Mémoire inférence : modèle charge RAM une fois. nomic ~1.2 GB (MoE = activations <params), 1 024-dim = 1.9–2.4 GB. Aucun >3 GB même bf16.
- Storage production : corpus 50K pages : 0.9 GB (768 dims) → 1.2 GB (1 024) → 0.6 GB (1 024 int8 quantized).
💡Tip: Coût storage prioritaire : embedder jina-embeddings-v3 1 024 dims, troncature 512 pour storage. Précision indexing complet, coût storage moitié, retrieval@10 baisse ~1 point. Troncature reversible seulement si full vecteurs gardés.
Qualité multilingue : quand les leaders anglophone perdent
Écart qualité est multilingual vs anglophone seul, pas entre modèles spécifiques. 25-requête multilingue (EN, DE, FR, JA, ZH — 5 chacun) expose écart clairement.
| Modèle | Requête EN → Document EN | Requête EN → Docs DE/FR | Requête EN → Docs JA/ZH | Moyenne multilingue |
|---|---|---|---|---|
| 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 dépasse jina sur requêtes multilingues : architecture MoE active experts langue-spécifique. Corpora japonais/chinois substantiel : nomic-embed-text-v2 vaut comparaison — aussi moins cher CPU, idéal workloads multilingues laptops.
Profils modèles : ce pour quoi chaque embedder excelle
Chaque modèle conçu différemment. Benchmark ci-dessus reflète choix design.
- nomic-embed-text-v2 — MoE open-weights (475M params total, ~305M actif/token). Entraîné 1.6B paires, 100+ langues. Licence Apache-2.0. Forces : débit CPU (5× peers 1 024-dim), recall multilingue fort, footprint RAM minimal. Faiblesses : plafond 768 dims = recall anglophone <1 024-dim. Idéal : laptops CPU-only, corpora multilingue, pipelines indexing fréquents.
- bge-large-en-v1.5 (BAAI) — 335M params, 1 024 dims, 24 couches. Entraîné surtout anglophone, paires contrastives retrieval. Licence MIT. Forces : top texte anglophone légal/recherche, écosystème mature, fine-tuning documenté. Faiblesses : anglophone seul — perte 12–15 points requêtes multilingues. Idéal : RAG anglophone critique.
- gte-large (Alibaba) — 335M params, 1 024 dims. Entraîné paires web, sémantique générale. Licence Apache-2.0. Forces : licence permissive, perf EN forte, support framework large (Sentence Transformers, LangChain, LlamaIndex). Faiblesses : anglophone focus (gte-multilingual-large séparé, +1 GB). Idéal : déploiements commerciaux Apache-2.0.
- mxbai-embed-large-v1 (Mixedbread) — 335M params, 1 024 dims. Distillé base forte, fine-tuning retrieval. Licence Apache-2.0. Forces : perf EN équilibrée, recall multilingue légèrement mieux que bge, variante -2d supporte Matryoshka (modèle séparé). Faiblesses : community plus petite. Idéal : RAG EN avec licence permissive + option -2d dimension flexible.
- snowflake-arctic-embed-l-v2.0 (Snowflake) — 568M params, 1 024 dims, supporte nativement jusqu'à 8 192-token chunks. Licence Apache-2.0. Forces : capacité long-context (most embedders ~512 tokens), ~30 langues, fort docs enterprise. Faiblesses : precision mid-pack short chunks. Idéal : corpora docs longs structurés (contrats, manuels, regulatory filings) où 8k-token chunks utiles.
- jina-embeddings-v3 (Jina AI) — 570M params, 1 024 dims + Matryoshka à 768/512/256. Entraîné adapters LoRA task-spécifiques (retrieval, classification, similarity). Support 89 langues. Licence CC BY-NC open weights (commercial licence requise produit payant). Forces : meilleure precision globale benchmark, perf multilingue forte, Matryoshka, adapters task-aware. Faiblesses : licence nécessite attention commerciale. Idéal : RAG personnel, recherche, déploiements où licence acceptable.
💡Tip: Vérifier licence toujours à intégration. Licences embedder changent — bge MIT→restrictif→MIT, jina CC BY-NC open weights (commercial licence), Snowflake Apache-2.0+AUP. README = statement à jour, pas historique.
Auto-hébergé vs OpenAI : coût par million tokens
Auto-hébergement essentiellement gratuit à l'échelle. Coûts réels : électricité, amortissement hardware — bruits vs API prix corpus >quelques milliers pages.
| Approche | Coût / 1M tokens | Temps 1M tokens | Notes |
|---|---|---|---|
| OpenAI text-embedding-3-large (API) | €0,12* | ~3 min (réseau) | Plus haute précision anglophone ; données quittent machine |
| jina-embeddings-v3 sur RTX 4070 | ~€0,001 (électricité) | ~5 min | Meilleure précision locale ; CC BY-NC — vérifier commercial |
| bge-large-en-v1.5 sur RTX 4070 | ~€0,001 | ~12 min | Meilleure précision anglophone ; licence MIT |
| nomic-embed-text-v2 sur RTX 4070 | ~€0,0005 | ~3 min 30 sec | Plus rapide GPU ; multilingue ; Apache-2.0 |
| nomic-embed-text-v2 sur M3 Pro CPU | ~€0,0008 | ~30 min | GPU non requis ; sens seulement parce que c'est possible |
📌Note: Corpus 5K pages (~5M tokens, 1K tokens/page) : OpenAI ~€0,60 full ré-index — trivial. Vrai coût : data egress — chaque chunk quitte machine, compliance régimes refusent souvent. Auto-hébergement priorité privacité et contrôle, deuxième priorité coût. *converti $0,13 taux actuel.
Arbre de décision : quel embedder choisir ?
Cinq questions binaires, cet ordre, guident plupart lecteurs au bon embedder.
- 1. GPU disponible indexing ? → Non : nomic-embed-text-v2 (5× CPU). Oui : continuer.
- 2. Corpus anglophone seul ? → Non : continuer. Oui : bge-large-en-v1.5 si précision prime, gte-large ou mxbai-embed-large-v1 si licence Apache-2.0.
- 3. Documents très longs (8k+ token chunks) ? → Oui : snowflake-arctic-embed-l-v2.0. Non : continuer.
- 4. Troncature dimension future (coût storage) ? → Oui : jina-embeddings-v3 (Matryoshka). Non : continuer.
- 5. Produit commercial ? → Oui : éviter jina-embeddings-v3 (CC BY-NC) sans licence commercial — nomic-embed-text-v2 (Apache-2.0) ou BAAI/bge-m3 (MIT).
- Doute : jina-embeddings-v3. Choix général-purpose plus haute précision benchmark, seul modèle >87% tous types. Déploiements licence-acceptée devraient défaut ici.
Erreurs courantes modèle embedding
- Erreur 1 : Garder default plateforme. AnythingLLM tiny embedder built-in ; PrivateGPT all-MiniLM-L6-v2 ; Open WebUI nomic-embed-text-v1.5. Tous trois perd 5–10 points retrieval@10 vs jina-embeddings-v3. Changer.
- Erreur 2 : Modèle 1 024-dim quand 768-dim déjà 90% retrieval@10. Gain marginal rarement justifie storage doublé + CPU 5× plus lent. nomic-embed-text-v2 atteint 88% — assez plupart cas.
- Erreur 3 : Embedder anglophone seul pour corpus mélangé. bge-large-en-v1.5 meilleur anglophone, pire sur japonais/chinois. « Meilleur » est corpus-dépendant — mesurez votre data.
- Erreur 4 : Ignorer licence. jina-embeddings-v3 CC BY-NC open weights. Produit payant sans licence commercial = problème légal. Vérifier toujours intégration.
- Erreur 5 : Benchmark corpus trop petit. Six modèles tous excellents 100 docs. Différences deviennent décisives >5K chunks où ceiling recall faibles embedders remonte. Tester ≥5K chunks votre contenu.
- Erreur 6 : Oublier changement embedder force full ré-index. Zéro plateforme RAG supporte migration incrémentale. Budget 30–90 min par 5K pages. Choisir une fois, swap délibérément.
FAQ
Modèle embedding CPU-only le plus rapide ?
nomic-embed-text-v2 — 580 chunks/sec M3 Pro batch 32, chunks 256-tokens. ~5× plus rapide que 1 024-dim alternatives (bge 95, gte 110, mxbai 105 chunks/sec). Vitesse vient MoE architecture (305M de 475M params/token). Corpus >1K pages CPU-only : nomic-embed-text-v2 défaut pratique.
Dimensions plus grandes améliorent vraiment retrieval ?
Jusqu'à ~1 024, oui. Au-delà, non. Test : 768-dim nomic (88% retrieval@10) perd 4 points vs 1 024-dim jina (92%) global. Dimensions 1 536 ou 3 072 (APIs commerciales) gagne <1 point benchmarks. Dimensions coût storage linéaire : 50K corpus = 0.9 GB à 768 dims vs 1.2 GB à 1 024 vs 3.6 GB à 3 072. Matryoshka trick — troncature après embedding — flexibilité sans coût.
Embeddings multilingues sans perte ?
Modèles multilingues rattrapés 2026. jina-embeddings-v3 atteint 92% retrieval@10 global (89% requêtes multilingues) — compétitif meilleur anglophone, loin ahead non-anglophone. Écart historique (multilingue = lower) rétrécit à 1–2 points requêtes anglophone pour gain 10 points non-anglophone. Corpus mélangé : multilingue défaut-correct maintenant.
Modèle meilleur pour code ?
Aucun des six vrais « code embedder ». TypeScript/Python codebase : jina-embeddings-v3 mène 87% retrieval@10, autres 82–86%. Corpus lourd code — code search, repo RAG, agent tooling — combinez general embedder + code-specific (bge-code-v1, voyage-code-2, fine-tuned variant), utilisez meilleur-scorer code chunks. Simplest : embed tout jina d'abord, mesurer retrieval@10 query set, swap seul si <threshold.
Quand upgrader embedding model ?
Upgrade quand nouveau model benchmark >3 points yours sur data similaire votre corpus, ET vous avez baseline retrieval@10 comparer. Sans baseline, ne savez pas si nouveau vraiment mieux votre contenu. Plupart RAG local : embedder bon 12–18 mois avant meilleur arrive. Upgrade coûts : ré-index — budget 30–90 min par 5K pages hardware grand public.
Mixer embedding models même RAG ?
Techniquement oui, pratiquement non. Mélange requiert soit deux indexes vecteur parallèles (query both, merge results — +50–150 ms latence, scoring compliqué) soit training small projection layer aligner dimensions (recherche-grade, fragile). 95% déploiements locaux : pick one embedder, ré-index. Exception : code repos dedicated code embedder code chunks + general embedder docs — split document-type ingestion, query both indexes quand user query ambiguous.
Open-source embeddings aussi bons qu'OpenAI ?
Plupart cas local RAG, oui. OpenAI text-embedding-3-large lead benchmarks anglophone 2–4 points retrieval@10, gap rétrécit. jina-embeddings-v3 vient dans 2 points test corpus, OpenAI route requiert data quitter machine — non-starter compliance/privacy. Pure qualité anglophone, pas privacy constraint, budget humble : OpenAI nombre absolu plus haut ; sinon open-source rattrapé.
Quantisation affect embedding quality ?
int8-quantisation stored vecteurs coûts ~0.5 points retrieval@10 pour halve storage + halve retrieval latency. Vaut corpus >25K chunks. Quantiser embedding model itself (weights bf16→int8→int4) plus agressif : int8 model coûts 1–2 points ; int4 3–5 points, blesse recall multilingue. Local RAG consumer hardware : run model bf16 (ou fp16), quantiser stored vecteurs seul.
Meilleur modèle documents légaux ?
bge-large-en-v1.5 menait legal subset 94% retrieval@10 — nombre le plus haut benchmark — mais anglophone seul. Corpus légaux français/allemand/multilingues : jina-embeddings-v3 (93% anglophone / 89% multi) meilleur all-rounder. Texte légal récompense 1 024-dim modèles ; nomic-768-dim traîne 6 points legal subset. Contrats très longs (50+ pages dense legalese) : snowflake-arctic-embed-l-v2.0 8k-token chunks réduit fragmentation losses.
Embeddings réutilisables si switch RAG platform ?
Documents sources bougent libre entre. Embeddings bougent seul si nouveau platform supporte même format vecteur + même embedder. AnythingLLM (LanceDB), PrivateGPT (Qdrant ou Chroma), Open WebUI (ChromaDB) tous différent stores ; même embedder identical, metadata schemas differ. Pratique : chaque platform switch est aussi ré-indexing pass. Plan : pick embedder retrieval quality, pick platform tout-le-reste.