Embeddings open source : choisir et déployer ses modèles de vectorisation pour le RAG

Chaque pipeline RAG repose sur une étape invisible mais critique : la transformation du texte en vecteurs numériques. Qdrant, pgvector, Ollama, vLLM : toutes les briques de la stack s’appuient sur des embeddings pour fonctionner. Pourtant, le choix du modèle d’embedding est rarement documenté. Un mauvais modèle peut diviser par deux la pertinence des résultats de recherche, quel que soit le LLM utilisé ensuite. Cet article fait le point sur les modèles open source disponibles, les critères de sélection, et les options de déploiement auto-hébergé.

Qu’est-ce qu’un embedding et pourquoi c’est la fondation du RAG

Un embedding est une représentation vectorielle d’un texte dans un espace de grande dimension (typiquement 384 à 4096 dimensions). Deux textes sémantiquement proches produisent des vecteurs proches, mesurés par similarité cosinus. Dans un pipeline RAG, cette propriété est exploitée deux fois : à l’ingestion (vectoriser les documents et les stocker dans Qdrant ou pgvector) et à la requête (vectoriser la question de l’utilisateur et chercher les documents les plus proches).

Le modèle d’embedding détermine la qualité de cette correspondance. Un modèle entraîné uniquement sur l’anglais produira des résultats médiocres sur du texte français. Un modèle avec une fenêtre de contexte de 256 tokens tronquera les paragraphes longs. Un modèle de petite dimension sera rapide mais moins précis sur des requêtes complexes. Chaque choix a des conséquences directes sur la pertinence du RAG.

Le benchmark MTEB : comparer les modèles objectivement

Le Massive Text Embedding Benchmark (MTEB) est la référence pour évaluer les modèles d’embedding. Hébergé sur Hugging Face, il teste les modèles sur des dizaines de tâches : recherche sémantique, classification, clustering, réordonnancement. Le leaderboard MTEB permet de filtrer par langue, taille de modèle et type de tâche.

Pour un RAG francophone, les métriques à surveiller sont le score de retrieval (capacité à retrouver le bon document) et la couverture multilingue. Un modèle en tête du classement anglais peut être médiocre sur le français. Il faut vérifier les résultats sur les sous-ensembles multilingues ou francophones spécifiquement.

Modèles recommandés pour une stack francophone

Plusieurs familles de modèles open source se distinguent pour un usage RAG en français :

Sentence-Transformers / all-MiniLM-L6-v2 — 384 dimensions, 80 Mo. Le modèle d’entrée de gamme, rapide et léger, mais limité en multilingue. Suffisant pour du prototypage ou des corpus courts en anglais, insuffisant pour du français en production.

multilingual-e5-large — 1024 dimensions, 2,2 Go. Entraîné par Microsoft sur 100+ langues. Excellent rapport qualité/taille pour le français. Préfixer les requêtes par query: et les documents par passage: pour activer le mode asymétrique.

BGE-M3 (BAAI) — 1024 dimensions, fenêtre de 8192 tokens. Supporte le dense, le sparse et le ColBERT simultanément. Le choix le plus polyvalent pour du RAG multilingue avancé, avec une fenêtre de contexte suffisante pour des documents longs.

nomic-embed-text — 768 dimensions, fenêtre de 8192 tokens, licence Apache 2.0. Disponible nativement dans Ollama (ollama pull nomic-embed-text). Le meilleur compromis pour une stack entièrement auto-hébergée avec Ollama.

mxbai-embed-large — 1024 dimensions, performant sur MTEB. Également disponible dans Ollama. Alternative à nomic-embed-text quand on veut plus de dimensions pour des corpus complexes.

Déploiement : quatre options selon la stack

Option 1 — Ollama (le plus simple). Ollama expose une API d’embedding via POST /api/embeddings. L’intégration est immédiate avec n8n, LangGraph ou tout client HTTP. C’est l’option à privilégier si Ollama est déjà déployé pour les LLM. Modèles disponibles : nomic-embed-text, mxbai-embed-large, all-minilm, snowflake-arctic-embed.

Option 2 — vLLM. Depuis la version 0.4, vLLM supporte le serving d’embeddings via l’endpoint /v1/embeddings compatible OpenAI. Avantage : batching automatique et gestion GPU optimisée. À utiliser quand le volume de vectorisation est élevé et qu’un GPU dédié est disponible.

Option 3 — TEI (Text Embeddings Inference) de Hugging Face. Serveur Rust spécialisé pour les embeddings, avec support ONNX et quantification. Très performant en latence. Déploiement Docker en une ligne :

docker run -p 8080:80 \
  ghcr.io/huggingface/text-embeddings-inference:latest \
  --model-id BAAI/bge-m3

Option 4 — Sentence-Transformers en Python. Pour un pipeline custom ou un script de vectorisation par lots. La bibliothèque sentence-transformers permet de charger n’importe quel modèle Hugging Face et de produire des embeddings en quelques lignes :

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("BAAI/bge-m3")
embeddings = model.encode(["Texte à vectoriser"], normalize_embeddings=True)

Critères de choix : la grille de décision

Le choix du modèle se fait sur cinq axes. La langue : un modèle multilingue est indispensable pour du contenu français ; les modèles anglais-only sont à écarter. La dimension du vecteur : plus elle est élevée, plus la recherche est précise mais plus le stockage et le calcul sont coûteux : 768 à 1024 est un bon compromis. La fenêtre de contexte : 512 tokens suffisent pour des chunks courts, mais 8192 tokens permettent de vectoriser des paragraphes entiers sans chunking agressif. La taille du modèle : un modèle de 300 Mo tourne sur CPU, un modèle de 2 Go demande un GPU ou une patience certaine. Enfin la licence : vérifier qu’elle permet un usage commercial (Apache 2.0, MIT) si le déploiement est en production.

Intégration avec la stack existante

Dans une architecture RAG typique auto-hébergée, le modèle d’embedding est appelé à deux moments. À l’ingestion : Docling ou Crawl4AI extrait le texte, n8n orchestre le pipeline, le modèle d’embedding (via Ollama ou TEI) vectorise chaque chunk, et les vecteurs sont stockés dans Qdrant ou pgvector. À la requête : l’utilisateur pose une question via Open WebUI, le même modèle d’embedding vectorise la question, Qdrant/pgvector retrouve les documents pertinents, et le LLM (via vLLM ou Ollama) génère la réponse avec le contexte.

Point critique : le modèle d’embedding utilisé à l’ingestion doit être identique à celui utilisé à la requête. Changer de modèle implique de re-vectoriser l’intégralité du corpus. C’est un choix structurant qu’il faut faire une fois et documenter.

Quantification et optimisation

Pour réduire la consommation mémoire et accélérer l’inférence, plusieurs techniques s’appliquent aux modèles d’embedding. La quantification ONNX (INT8) réduit la taille du modèle de 50 % avec une perte de précision minime : TEI supporte ce format nativement. Matryoshka Representation Learning (MRL), supporté par nomic-embed-text et certains modèles BGE, permet de tronquer les vecteurs (par exemple de 768 à 256 dimensions) après génération, réduisant le stockage sans ré-entraînement. Enfin, le batching : envoyer les textes par lots de 32 ou 64 plutôt qu’un par un, multiplie le débit par 10 à 20 sur GPU.

Recommandation pour démarrer

Pour une stack auto-hébergée francophone avec Ollama déjà en place : commencer avec nomic-embed-text (rapide, Apache 2.0, 8k tokens de contexte). Si les résultats de retrieval sont insuffisants, passer à BGE-M3 via TEI pour bénéficier du mode hybrid (dense + sparse). Dans tous les cas, évaluer la qualité en mesurant le recall@10 sur un échantillon de questions/réponses attendues avant de passer en production.