Embeddings
Définition
Représentation vectorielle d'un texte (suite de nombres) qui capture son sens. Permet de comparer la similarité sémantique de deux textes pour la recherche sémantique ou le RAG.
Comment ça marche
Un embedding est une suite de nombres (souvent 768 à 3072 dimensions) qui représente le sens d'un texte dans un espace vectoriel à haute dimension. Le modèle d'embedding lit le texte d'entrée et le projette dans cet espace de façon à ce que deux textes proches sémantiquement aient des vecteurs proches, même s'ils ne partagent aucun mot en commun. Cette proximité se mesure par une distance mathématique : cosinus, dot product ou distance euclidienne. Le modèle a appris cette projection en lisant des milliards de textes et en apprenant que certains contextes apparaissent ensemble : démissionner et quitter son emploi finissent dans le même quartier de l'espace.
À quoi ça sert
Les embeddings sont la brique qui rend possible la recherche sémantique. Cas concrets : un utilisateur tape résilier mon abonnement et le système retrouve un article intitulé comment annuler votre formule, sans qu'aucun mot ne soit partagé. On les utilise massivement dans le RAG (retrouver les passages pertinents pour une question), les moteurs de recherche internes (chercher dans une base produits par intention), la classification (regrouper automatiquement des tickets support par thème), la déduplication (détecter deux articles qui parlent du même sujet), et les recommandations (proposer des contenus similaires à celui qu'on consulte).
Les modèles disponibles
Le marché est dense. OpenAI text-embedding-3-small et text-embedding-3-large dominent par défaut, avec un bon rapport qualité/prix. Voyage AI propose voyage-3 et voyage-3-large qui battent souvent OpenAI sur les benchmarks récents. Cohere embed-v3 reste très performant et propose des dimensions Matryoshka qu'on peut tronquer. Côté open-source, BGE-large, E5-large et les modèles de l'INRIA pour le français permettent l'auto-hébergement. Le choix dépend du budget, du besoin de souveraineté, et de la langue cible : tous les modèles ne sont pas équivalents en français.
Le stockage et la recherche
On stocke les vecteurs dans une base spécialisée qui sait calculer rapidement les distances sur des millions de vecteurs. pgvector dans PostgreSQL est le choix par défaut pour démarrer : il s'intègre dans la base métier, supporte les index HNSW et IVFFlat pour les recherches en quelques millisecondes. Pour des volumes plus importants (au-delà de quelques millions de vecteurs) ou des besoins de filtrage avancé, on regarde Qdrant, Weaviate, Pinecone ou Milvus. Le choix de l'index (HNSW vs IVFFlat) impacte le compromis précision/vitesse : HNSW est plus rapide en lecture, IVFFlat plus rapide en écriture.
Quand l'utiliser
Les embeddings s'imposent dès qu'on veut chercher par sens plutôt que par mot exact. À l'inverse, pour des recherches sur des identifiants, des dates, des nombres ou des champs structurés, une recherche SQL classique reste plus précise et plus rapide. Pour des cas où la pertinence dépend autant des mots-clés que du sens (recherche juridique, e-commerce), on combine recherche full-text (BM25, ts_vector PostgreSQL) et recherche vectorielle dans un hybrid search, puis on re-rank avec un modèle dédié. Le mix bat presque toujours chaque approche prise isolément.
Les pièges à éviter
Trois pièges. Croire qu'un embedding suffit pour la production sans normalisation : on normalise les vecteurs (norme 1) pour que la distance cosinus soit calculable rapidement et de façon stable. Ignorer la dimension : un embedding à 3072 dimensions stocke plus d'information mais coûte plus cher en stockage et en calcul. Pour beaucoup de cas, 512 ou 768 dimensions suffisent largement. Et surtout, changer de modèle d'embedding sans réindexer toute la base : les embeddings de modèles différents ne sont pas comparables, on doit toujours utiliser le même modèle pour l'indexation et la requête.