Un modèle d'embedding prend un morceau de texte — une phrase, un paragraphe, un document entier — et le compresse en un vecteur de nombres à virgule flottante de longueur fixe, généralement entre 384 et 4096 dimensions. La magie réside dans la disposition de ces nombres : pendant l'entraînement, le modèle apprend à placer les textes sémantiquement similaires proches les uns des autres dans cet espace à haute dimensionnalité et à éloigner les textes dissemblables. L'approche standard utilise l'apprentissage contrastif, où le modèle voit des paires de textes liés (une question et sa réponse, une phrase et sa paraphrase) et apprend à minimiser la distance entre leurs vecteurs tout en maximisant la distance par rapport aux paires non liées. Des modèles comme bge-large-en de BAAI, text-embedding-3 d'OpenAI et embed-v3 de Cohere utilisent tous cette recette générale, bien qu'ils diffèrent par l'architecture, les données d'entraînement et les objectifs contrastifs spécifiques qu'ils optimisent.
En pratique, on utilise les embeddings en encodant d'abord ses documents en vecteurs et en les stockant dans une base de données vectorielle comme Qdrant, Pinecone, Milvus ou FAISS. Au moment de la requête, on encode la question de l'utilisateur en vecteur avec le même modèle et on effectue une recherche de plus proches voisins pour trouver les vecteurs de documents les plus similaires. La métrique de distance compte — la similarité cosinus est la plus courante, mais certains modèles sont entraînés pour le produit scalaire ou la distance euclidienne. Un piège fréquent : il faut absolument utiliser le même modèle d'embedding pour les documents et les requêtes. Les vecteurs de modèles différents vivent dans des espaces complètement différents et ne peuvent pas être comparés, même s'ils ont le même nombre de dimensions.
La dimensionnalité du vecteur d'embedding représente un compromis entre expressivité et coût. Un vecteur de 1536 dimensions peut capturer plus de nuances qu'un vecteur de 384 dimensions, mais il coûte aussi quatre fois plus cher à stocker et à chercher. Pour un million de documents, la différence se mesure en dizaines de gigaoctets de RAM dans votre base de données vectorielle contre quelques gigaoctets. Certains modèles récents prennent en charge les embeddings Matryoshka, où l'on peut tronquer le vecteur à moins de dimensions avec une dégradation progressive — on utilise les 1024 dimensions complètes pour sa collection la plus importante et les 256 premières pour une moins critique. La quantification aide aussi : stocker les vecteurs en INT8 au lieu de float32 réduit la mémoire par 4 avec étonnamment peu de perte de précision, c'est pourquoi les systèmes de production utilisent de plus en plus des embeddings quantifiés.
Une idée fausse courante est que les modèles d'embedding comprennent le sens de la même façon que les humains. Ils sont très bons pour la similarité sémantique de surface — synonymes, paraphrases, concepts reliés — mais peuvent avoir du mal avec la négation (« le restaurant n'était pas bon » et « le restaurant était bon » se retrouvent souvent proches), avec les relations logiques complexes, et avec le jargon spécialisé sur lequel ils n'ont pas été entraînés. C'est pourquoi les systèmes de génération augmentée par récupération combinent souvent la recherche vectorielle avec la recherche par mots-clés (recherche hybride) et utilisent un modèle de reclassement en deuxième passe pour améliorer la précision. L'embedding récupère un ensemble large de candidats ; le reclasseur, plus lent mais plus précis, les trie par pertinence réelle. Bien calibrer ce pipeline compte bien plus que de choisir le modèle d'embedding avec le meilleur score au classement MTEB.