Intermédiaire 10 minEmbeddings

Sentence Transformers : les embeddings en local

Le modèle d'embedding décide de ce que votre recherche documentaire est capable de retrouver. C'est la décision la plus déterminante d'une chaîne RAG, la plus souvent prise par défaut, et celle qui échoue sans le moindre message d'erreur. Sentence Transformers est la bibliothèque qui permet de faire tourner ces modèles en local : texte en entrée, vecteurs en sortie, sur processeur ou sur carte graphique.

Par Mohamed Meguedmi·Màj 2026-09-28·Testé sur Windows, macOS, Linux

#Ce qu'est un embedding

Un modèle d'embedding transforme un texte en une liste de nombres de longueur fixe, positionnée de telle sorte que deux textes de sens proche se retrouvent proches. La récupération devient alors une affaire de géométrie : on encode la question, on cherche les passages les plus proches, on les donne au modèle de langage. C'est tout le mécanisme du RAG.

Deux conséquences méritent d'être intégrées une fois pour toutes. Le modèle qui encode vos documents doit être celui qui encode vos questions, sinon les deux jeux de coordonnées ne parlent pas de la même chose. Et la notion de « proche » qu'a le modèle vient de son entraînement — c'est pourquoi un modèle entraîné surtout sur de l'anglais est un juge peu fiable de la similarité en français.

#Choisir un modèle

Le kit RAG Local

Tes documents, ton IA : un RAG local fiable sur tes PDF, notes et mails — sans rien envoyer dans le cloud.

  • Espace en ligne à vie
  • PDF + fichiers
  • Remboursé 30 j
Les propriétés qui décident, dans l'ordre
PropriétéCe qu'elle changeComment trancher
Couverture linguistiqueQue la similarité veuille dire quelque chose sur votre corpusDu contenu non anglophone exige un modèle multilingue : ce n'est pas négociable
Longueur maximale d'entréeLa taille de morceau au-delà de laquelle on tronqueL'aligner sur votre découpage : le dépassement est jeté en silence
DimensionLe stockage et la mémoire par vecteurPlus grand n'est pas automatiquement meilleur, et coûte toujours plus
Taille du modèleLa vitesse d'indexation et de chaque requêteLes questions sont encodées en temps réel : un modèle lent se ressent
DomaineCode, juridique et médical se comportent différemmentTester sur ses propres données : les classements ne sont pas votre corpus
!
Certains modèles attendent un préfixe
Plusieurs modèles d'embedding répandus sont entraînés avec une instruction différente pour les documents et pour les questions. L'omettre dégrade mesurablement la récupération. On lit la fiche du modèle avant d'indexer un corpus : c'est un détail d'une ligne qui coûte de la précision en silence.

#Les erreurs qui ruinent un corpus en silence

Un modèle anglophone sur du contenu français
Tout fonctionne, rien n'échoue, et la récupération est subtilement fausse pour toujours.
Des morceaux plus longs que la limite du modèle
La fin est jetée sans avertissement : la conclusion de chaque long passage est invisible à la recherche.
Deux modèles différents pour documents et questions
Résultats aberrants garantis, en général introduits quand une partie de la chaîne est mise à jour et pas l'autre.
Une mesure de distance qui ne correspond pas
Le classement se dégrade sans que rien ne casse.
L'oubli de la normalisation
Certains modèles attendent des vecteurs normalisés pour la similarité cosinus ; certaines bibliothèques le font, d'autres non.

Toutes ces erreurs échouent en silence. C'est précisément pour cela que le choix du modèle d'embedding mérite un petit dispositif d'évaluation plutôt qu'une opinion : un jeu de questions avec les passages attendus, rejoué à chaque changement.

#L'exécuter en local

Le processeur suffit souvent
Ces modèles sont petits ; un GPU accélère l'indexation en masse et change peu pour une requête isolée.
Indexer par lots
Encoder les documents un par un gaspille l'essentiel du débit disponible.
Le GPU est partagé
Sur une machine qui sert un modèle de langage, l'encodage en masse dispute la même mémoire. On indexe quand personne n'interroge.
Mettre en cache
Réencoder des documents inchangés est du gaspillage pur : la clé du cache doit porter sur le contenu, pas sur le nom du fichier.
Noter le nom du modèle à côté de l'index
Votre futur vous aura besoin de savoir quel modèle a produit ces vecteurs.

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

La recherche vectorielle est un filtre rapide et approximatif. Un modèle de reclassement — qui évalue directement la question face à chaque passage candidat, au lieu de comparer des vecteurs calculés d'avance — est plus lent et considérablement plus précis sur la poignée de candidats qui subsistent. Récupérer vingt passages par similarité puis les reclasser pour n'en garder cinq est l'une des améliorations de qualité les moins chères d'une chaîne RAG, et elle bat souvent le passage à un modèle d'embedding plus gros.

#FAQ

Faut-il un GPU pour les embeddings ?+
Non. Ces modèles sont assez petits pour tourner sur processeur, et une requête isolée est rapide dans les deux cas. Le GPU sert surtout à indexer un gros corpus.
Peut-on utiliser son modèle de conversation pour encoder ?+
Non. Un modèle d'embedding est entraîné spécifiquement pour placer les textes proches les uns des autres ; un modèle de discussion ne l'est pas, et le résultat est une récupération médiocre alors que le code semble fonctionner.
Que se passe-t-il si je change de modèle d'embedding ?+
Tout doit être réencodé : les vecteurs de deux modèles ne sont pas comparables. L'ancien index devient dénué de sens.
Une dimension plus grande, est-ce mieux ?+
Pas de façon fiable, et cela coûte toujours plus de stockage et de mémoire. L'entraînement du modèle compte bien davantage que le nombre de dimensions.
Pourquoi la fin de mes longs passages n'est-elle jamais retrouvée ?+
Vos morceaux dépassent la longueur maximale d'entrée du modèle et le surplus est tronqué en silence. Alignez la taille des morceaux sur cette limite.
Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.