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 vs documents langage naturel. Aucun n'est vrai « code embedder » — corpora lourds en code : jina-embeddings-v3 (87%) meilleur de ce benchmark, voyage-code-3 (API seule) option spécialiste publiée (voir Recherche de code et RAG plus bas).
- Support multilingue ne vient pas gratuitement — et le chinois demande un modèle dédié. 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 : utilisez jina-embeddings-v3, nomic-embed-text-v2 ou BAAI/bge-m3. Corpus majoritairement chinois : aucun des six n'est le bon défaut — utilisez BAAI/bge-large-zh-v1.5 ou Qwen3-Embedding-4B (voir Chinois et CJK en RAG plus bas).
- 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.
📍 En une phrase
Pour le RAG local en 2026, jina-embeddings-v3 gagne en précision de récupération globale, nomic-embed-text-v2 gagne en vitesse CPU, et bge-large-en-v1.5 gagne sur le contenu purement anglophone.
💬 En termes simples
Un modèle d'embedding transforme des fragments de document en nombres (vecteurs) pour que le système puisse trouver rapidement les passages pertinents. Un meilleur modèle signifie que les nombres représentent le sens réel, pas seulement les mots. Sur du matériel local, la vitesse à laquelle un modèle transforme le texte en nombres détermine aussi combien de temps vous attendez lorsqu'un nouveau document est ajouté.
| 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 |
💡Tip: Via Ollama ? ollama pull couvre 4 des 6 modèles ci-dessus plus les sélections chinois/CJK : 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) et Qwen3-Embedding-4B/-8B (ollama pull qwen3-embedding:4b ou :8b). bge-large-en-v1.5, gte-large et jina-embeddings-v3 ne sont pas dans la bibliothèque officielle Ollama — utilisez plutôt Sentence Transformers, transformers de Hugging Face, ou un serveur Text Embeddings Inference.
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.
📌Note: Ce jeu de 25 requêtes couvre seulement EN, DE, FR, JA, ZH, mais les deux mêmes modèles (nomic-embed-text-v2, BAAI/bge-m3) annoncent une couverture d'entraînement de 100+ langues, dont vietnamien, russe et grec. Écritures latine et cyrillique (vietnamien, russe) et grecque tokenisent, chez ces modèles, plus près de l'allemand/français que du japonais/chinois — attendez-vous donc à une qualité proche de la ligne « Requête EN → Docs DE/FR » ci-dessus plutôt que de la ligne CJK. Estimation directionnelle, pas un chiffre mesuré, tant que non testé sur votre propre corpus.
Chinois et CJK en RAG : quel modèle d'embedding gagne ?
Pour corpus lourd en chinois, les six modèles généralistes du benchmark principal ne sont pas la meilleure option. Dans ce test, nomic-embed-text-v2 menait le groupe généraliste sur contenu chinois/japonais (84% requête EN → document JA/ZH, voir Qualité multilingue ci-dessus), mais deux alternatives conçues spécifiquement dépassent les six modèles principaux sur retrieval chinois natif.
| Modèle | retrieval@10 chinois | Dim | Licence | Meilleur pour |
|---|---|---|---|---|
| BAAI/bge-large-zh-v1.5 | ~90% (benchmark chinois natif) | 1 024 | MIT | Corpus chinois seul, critique précision |
| Qwen3-Embedding-4B | ~91% (benchmark chinois natif) | 2 560 (Matryoshka → 32) | Apache-2.0 | Corpus mixte chinois/anglais, dims flexibles |
| BAAI/bge-m3 | ~88% (benchmark chinois natif) | 1 024 | MIT | Chinois + 100 autres langues, un seul index |
| jina-embeddings-v3 (ce benchmark) | 89% (set multilingue, pas exclusivement chinois) | 1 024 (Matryoshka → 256) | CC BY-NC 4.0 | Déjà jina pour autres langues |
| nomic-embed-text-v2 (ce benchmark) | 84% (requête EN → document JA/ZH, cross-lingual) | 768 | Apache-2.0 | CPU seul, chinois minorité du corpus |
💡Tip: Si le chinois est la langue dominante ou majoritaire du corpus, ne pas défaut sur les six modèles du benchmark principal — aucun entraîné avec chinois comme cible primaire. BAAI/bge-large-zh-v1.5 (chinois seul, licence MIT) et Qwen3-Embedding-4B (chinois/anglais mixte, Apache-2.0, troncature Matryoshka jusqu'à 32 dims) dépassent tous deux les six généralistes sur benchmarks retrieval chinois natif. Corpora lourds en japonais : même logique — préférer modèle ajusté japonais/CJK à un multilingue généraliste quand japonais est langue majoritaire.
Meilleur modèle d'embedding pour la recherche de code et RAG
Retrieval sur code est tâche la plus faible pour les six modèles du benchmark principal (82–87% retrieval@10, contre 88–94% sur texte légal et recherche) car aucun n'est un embedder code dédié. Corpus lourd en code — recherche repository, agent tooling sur codebase, doc API interne liée au source — un embedder code-spécifique comble l'écart.
| Modèle | retrieval@10 code (ce test / publié) | Dim | Licence | Meilleur pour |
|---|---|---|---|---|
| jina-embeddings-v3 (ce benchmark) | 87% (leader généraliste) | 1 024 (Matryoshka → 256) | CC BY-NC 4.0 | Corpus mixte code + prose, un seul embedder pour tout |
| voyage-code-3 | Leader publié benchmarks retrieval code (pas dans ce test local) | 1 024 (Matryoshka → 256) | API commerciale seule — non auto-hébergeable | Corpus code seul où usage API acceptable |
| gte-large (ce benchmark) | 86% | 1 024 | Apache-2.0 | Auto-hébergé, licence permissive, second meilleur score code ici |
| mxbai-embed-large-v1 (ce benchmark) | 84% | 1 024 | Apache-2.0 | Équilibre code + prose anglophone |
📌Note: Aucun embedder code dédié open-weight testé localement ce round — voyage-code-3 API seule, ne peut tourner full local. Parmi modèles auto-hébergeables réellement testés, jina-embeddings-v3 meilleur pick retrieval code (87%), gte-large (86%, Apache-2.0) meilleure alternative licence permissive. Approche pratique corpus lourd code : démarrer jina-embeddings-v3 pour tout, mesurer retrieval@10 sur set requêtes code réelles réservé, ajouter second index code-spécifique seulement si écart nuit vraiment aux résultats.
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.
- Qwen3-Embedding-4B / -8B (Alibaba) — pas dans le benchmark principal 6-modèles ci-dessus, inclus ici pour corpora chinois/CJK et langue mixte (voir section Chinois et CJK en RAG). 2 560 dims avec troncature Matryoshka jusqu'à 32 dims. Licence Apache-2.0. Forces : retrieval chinois le plus fort de tout modèle discuté sur cette page, perf anglophone compétitive, entièrement auto-hébergeable. Faiblesses : footprint mémoire plus large que modèles 335–570M du benchmark principal ; variante 8B nécessite GPU pour débit pratique. Idéal : corpora majoritairement chinois ou mixte chinois/anglais.
💡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.
Questions fréquemment posées
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-3, fine-tuned variant), utilisez meilleur-scorer code chunks. Simplest : embed tout jina d'abord, mesurer retrieval@10 query set, swap seul si <threshold. Voir la section Meilleur modèle d'embedding pour la recherche de code et RAG ci-dessus pour comparaison directe.
Quel modèle d'embedding est meilleur pour RAG chinois ?
Aucun des six modèles du benchmark principal entraîné avec chinois comme cible primaire — le plus proche, nomic-embed-text-v2, atteint seulement 84% retrieval requête EN-vers-document chinois. Corpora majoritairement chinois ou chinois seul : utilisez BAAI/bge-large-zh-v1.5 (chinois seul, licence MIT, ~90% benchmarks chinois natifs) ou Qwen3-Embedding-4B (chinois/anglais mixte, Apache-2.0, troncature Matryoshka) à la place. Voir la section Chinois et CJK en RAG ci-dessus pour comparaison complète.
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.
Puis-je exécuter ces modèles d'embedding avec Ollama ?
Oui, pour la plupart. ollama pull couvre 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) et Qwen3-Embedding-4B/-8B (qwen3-embedding:4b / :8b) directement depuis la bibliothèque officielle Ollama. bge-large-en-v1.5, gte-large et jina-embeddings-v3 n'y sont pas publiés — utilisez plutôt Sentence Transformers, transformers de Hugging Face, ou un serveur Text Embeddings Inference, puis pointez votre plateforme RAG vers cet endpoint au lieu d'Ollama.