Sentence Transformers : les embeddings en local

#Ce qu'est un embedding, et ce que fait la bibliothèque

Un modèle d'embedding transforme un texte en une liste de nombres, un vecteur, de sorte que deux textes de sens proche aient des vecteurs proches. La documentation de Sentence Transformers décrit ces modèles, dits bi-encodeurs, comme calculant une représentation de taille fixe pour un texte, avec un calcul d'embedding souvent efficace et un calcul de similarité très rapide. C'est la brique de départ du RAG : on encode la question, on cherche les passages dont les vecteurs sont les plus proches, on les donne au modèle de langage. Deux conséquences à retenir : le modèle qui encode les documents doit être celui qui encode les questions, et sa notion de « proche » vient de son entraînement. Un modèle surtout entraîné sur l'anglais est un juge peu fiable du français.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
sentences = [
    "The weather is lovely today.",
    "It's so sunny outside!",
    "He drove to the stadium.",
]
embeddings = model.encode(sentences)
print(embeddings.shape)  # [3, 384]
similarities = model.similarity(embeddings, embeddings)

Ce modèle produit des vecteurs de 384 dimensions et sert d'exemple de départ, mais il est conçu pour l'anglais : pour un corpus français, remplacez-le comme indiqué plus bas. La bibliothèque place automatiquement le modèle sur le meilleur périphérique disponible (cuda, mps ou cpu), et vous pouvez forcer le choix avec le paramètre device.

#Installer et encoder un corpus français

1. 01
   Installer la bibliothèque

   Utilisez pip install -U sentence-transformers dans un environnement Python. La version 6.1.0 est parue le 18 septembre 2026 et demande Python 3.10 ou plus récent, d'après PyPI.
2. 02
   Choisir un modèle multilingue

   Prenez un modèle annoncé comme multilingue (voir le tableau plus bas), pas un modèle all-*, entraîné pour l'anglais.
3. 03
   Encoder les documents en lot

   Passez une liste de textes à encode : la bibliothèque les traite par lots, ce qui exploite bien mieux le matériel qu'un appel par texte.
4. 04
   Encoder la question avec le même modèle

   Utilisez le même modèle et les mêmes préfixes que pour les documents, puis comparez avec similarity.
5. 05
   Conserver le nom du modèle avec l'index

   Notez-le dans les métadonnées : si vous en changez, il faudra réencoder tout le corpus.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("intfloat/multilingual-e5-large")

docs = [
    "Le contrat peut être résilié avec un préavis de trois mois.",
    "La facture est payable à trente jours fin de mois.",
]
question = "Quel est le délai pour mettre fin au contrat ?"

doc_emb = model.encode(docs, prompt="passage: ", normalize_embeddings=True)
q_emb = model.encode(question, prompt="query: ", normalize_embeddings=True)
print(model.similarity(q_emb, doc_emb))

Le préfixe query: pour les questions et passage: pour les documents est celui que la documentation de Sentence Transformers cite pour ce modèle. Sans lui, la récupération se dégrade sans message d'erreur. Le paramètre prompt de encode applique le préfixe à chaque texte.

#Choisir un modèle qui comprend le français

La documentation propose des modèles d'origine et invite à consulter le classement MTEB comme source d'inspiration, avec deux réserves : filtrer les modèles trop gros pour votre matériel, et expérimenter, car les modèles bien classés ne réussissent pas forcément sur vos propres tâches. Le tableau suivant reprend ce que la documentation dit des modèles cités.

#Les erreurs qui ruinent un corpus sans message d'erreur

Un modèle anglophone sur du français

Tout fonctionne, et la récupération est pourtant faussée. C'est l'erreur la plus fréquente.

Des passages plus longs que la limite du modèle

La documentation précise que les textes plus longs sont tronqués aux premiers tokens du max_seq_length : la fin de chaque long passage devient invisible.

Un modèle différent pour documents et questions

Les vecteurs ne parlent plus de la même chose : résultats aberrants, généralement introduits en mettant à jour une partie de la chaîne seulement.

Des préfixes oubliés

Certains modèles demandent un préfixe différent pour les questions et les documents ; l'omettre dégrade la récupération.

Des vecteurs non normalisés avec un mauvais score

Si le modèle attend une similarité cosinus, normalisez les vecteurs ou utilisez la mesure qui correspond, sinon le classement se dégrade.

#Mesurer la proximité : normalisation et cosinus

Deux vecteurs se comparent par une mesure de similarité, le plus souvent le cosinus. La documentation d'Ollama indique que son point d'accès renvoie des vecteurs normalisés et recommande le cosinus pour la plupart des recherches sémantiques. Avec des vecteurs normalisés, cosinus et produit scalaire donnent le même classement, ce qui permet d'utiliser un index optimisé pour le produit scalaire. Le point à surveiller est la cohérence : la mesure de la base vectorielle doit correspondre à celle que le modèle attend, et elle est indiquée sur sa fiche.

Sur la longueur, la documentation donne un ordre de grandeur : 512 tokens pour de nombreux modèles de type BERT, soit 300 à 400 mots en anglais, et 256 tokens pour all-MiniLM-L6-v2. Le français consomme plus de tokens par mot : découpez vos passages en dessous de la limite avec de la marge, et vérifiez model.max_seq_length. Vous pouvez le réduire, mais pas l'augmenter au-delà de ce que le modèle supporte. La documentation ajoute qu'un modèle entraîné sur de courts textes représente moins bien les textes longs.

#Indexer vite sur sa machine

Processeur ou GPU

Le modèle s'exécute sur le meilleur périphérique disponible. Un GPU accélère l'indexation en masse et change peu pour une requête isolée.

Précision réduite

Sur GPU, le passage en float16 ou bfloat16 accélère l'inférence avec une perte minimale de précision, selon la documentation.

Backends ONNX et OpenVINO

La documentation annonce des accélérations possibles jusqu'à 2 à 3 fois selon le matériel et le backend ; testez-les sur votre machine.

Plusieurs GPU ou processus

encode accepte une liste de périphériques : utile sur de gros corpus, moins sur de petits à cause du coût de démarrage.

Vecteurs plus compacts

La quantification binaire ou en entiers des vecteurs et les modèles à dimensions tronquables réduisent le stockage et le coût de la recherche.

Cache et indexation

Ne réencodez pas les documents inchangés : la clé de cache porte sur le contenu, pas sur le nom du fichier. Sur une machine qui sert aussi un modèle de langage, indexez quand personne ne l'utilise.

#Ce que pèse un index de vecteurs

La taille d'un index se calcule en multipliant le nombre de vecteurs par leur dimension et par quatre octets si les nombres sont en float32. Un vecteur de 384 dimensions occupe 1 536 octets : un million de passages représente environ 1,5 Go. À 1 024 dimensions, le même million occupe environ 4 Go. Ces valeurs excluent les métadonnées et les structures d'index de la base vectorielle. Le choix du modèle a donc une conséquence directe sur la mémoire vive nécessaire à la recherche, et la quantification des vecteurs évoquée plus haut peut réduire cette empreinte.

#Sentence Transformers ou l'API d'embeddings d'Ollama

Ollama expose aussi des embeddings : la documentation indique que la commande ollama run peut produire des vecteurs et que le point d'accès api/embed renvoie des vecteurs normalisés en L2. Elle recommande les modèles embeddinggemma, qwen3-embedding et all-minilm, avec des vecteurs typiquement de 384 à 1 024 dimensions, et rappelle deux règles : cosinus pour la plupart des recherches, et même modèle pour l'indexation et l'interrogation.

#L'embedding n'est qu'un premier tri

La documentation de Sentence Transformers décrit le bi-encodeur comme la première étape d'une recherche en deux temps, où un cross-encodeur, ou reranker, reclasse les meilleurs résultats. Le cross-encodeur lit la question et chaque passage ensemble : il est plus lent, mais plus précis sur une poignée de candidats. Récupérer une vingtaine de passages par similarité, puis les reclasser pour n'en garder que quelques-uns, est l'une des améliorations les moins coûteuses d'une chaîne RAG. Le guide dédié au reranker détaille la mise en place ; mesurez le gain sur vos vingt questions avant de le conserver, car il ajoute une latence à chaque requête, un second modèle à maintenir et une consommation de mémoire supplémentaire.

Un bon réflexe, avant même de comparer les modèles, est de regarder ce que votre corpus contient : des phrases courtes et autonomes, ou de longs paragraphes techniques ? Des questions formulées comme des mots-clés, ou des phrases entières ? La réponse oriente le choix de la limite de longueur, du découpage et du modèle. Un corpus juridique dense n'appelle pas les mêmes réglages qu'une base de questions-réponses courtes, et aucun classement public ne le sait à votre place.

#Évaluer le choix du modèle avant d'indexer

1. 01
   Écrire vingt questions réelles

   Prenez des questions que vos utilisateurs poseront, formulées avec leurs mots, pas ceux du document.
2. 02
   Noter le passage attendu

   Pour chaque question, identifiez le ou les passages qui contiennent la réponse.
3. 03
   Comparer deux ou trois modèles

   Encodez le même corpus avec chaque modèle et regardez si le bon passage arrive parmi les cinq premiers résultats.
4. 04
   Rejouer à chaque changement

   Modèle, découpage ou préfixe modifiés : relancez ce petit test avant de réindexer.

#FAQ

#Pour aller plus loin

• Les meilleurs modèles d'embeddings pour le français
• BGE-M3 : des embeddings qui parlent vraiment français
• Ajouter un reranker à son pipeline
• Stratégies de chunking
• Qdrant : la base vectorielle d'un RAG local
• RAG local : introduction

• Source : Sentence Transformers, démarrage rapide
• Source : Sentence Transformers, calcul d'embeddings
• Source : Sentence Transformers, modèles pré-entraînés
• Source : Ollama, embeddings