C'est quoi les embeddings en termes simples ?
Un embedding est une façon de transformer un texte, une phrase ou un document en ensemble de nombres - un vecteur de longueur fixe. Un modèle d'embeddings apprend pour que des phrases proches en sens soient « proches » dans cet espace numérique, et les différentes, loin. C'est la base de la recherche sémantique, du RAG, des recommandations et du regroupement de documents. Ci-dessous : ce que sont les embeddings, comment ils diffèrent des tokens et des réponses LLM, et où ils comptent vraiment pour le business.
- Vecteur - liste de centaines ou milliers de nombres, une « empreinte du sens » du texte
- Embedding model - réseau neuronal séparé qui encode le texte en vecteur ; ce n'est pas un modèle de chat
- Proximité sémantique - « livraison par coursier » et « envoi express » sont plus proches que « livraison » et « déclaration fiscale »
- Usage principal - recherche par le sens, RAG, déduplication, classification
- Ne pas confondre - un embedding ne génère pas de réponse ; il aide seulement à trouver des extraits pertinents
- En pratique - indexer la base de connaissances une fois, puis chercher Top-K extraits par requête
Qu'est-ce qu'un embedding en deux mots
Imaginez une bibliothèque où les livres ne sont pas rangés par auteur mais par thème : logistique ensemble, comptabilité à part, marketing ailleurs. Un embedding fait pareil pour le texte, mais dans un espace multidimensionnel de nombres.
Un embedding est la sortie d'un modèle encodeur : entrée « comment traiter un retour produit », sortie par exemple un vecteur de 1 536 nombres. Chaque morceau de doc, ticket ou paragraphe a son vecteur. Quand arrive la question utilisateur, elle est encodée avec le même modèle et le système cherche les correspondances les plus proches.
| Notion | Ce que c'est | Exemple |
|---|---|---|
| Texte | Mots d'origine | « Délai de livraison 2-3 jours » |
| Embedding model | Réseau encodeur | text-embedding-3-small, bge-m3 |
| Vecteur | Représentation numérique | [0.12, -0.04, 0.88, …] |
| Vector DB | Stockage de vecteurs + recherche rapide | pgvector, Qdrant, Pinecone |
Un embedding ne « comprend » pas le texte comme un humain et n'écrit pas de réponses. Il donne des coordonnées de sens pour que l'ordinateur compare vite des millions de fragments.
À quoi servent les vecteurs si la recherche classique existe
La recherche par mots-clés cherche des correspondances exactes : la requête « retour » ne trouvera pas un paragraphe qui dit seulement « refund policy » ou « procédure de renvoi ». La recherche sémantique avec embeddings compare le sens, pas les lettres.
Tâches typiques :
- FAQ entreprise et support - agent ou bot trouve le bon règlement selon la formulation du client.
- RAG - avant la réponse LLM, récupération de chunks pertinents depuis wiki, PDF, tickets.
- Tickets similaires - « on a déjà eu cet incident » sans tagging manuel.
- Déduplication - filtrer articles, avis ou fiches presque identiques.
- Clustering - regrouper demandes, avis, sujets forum pour l'analytics.
Si tout le texte tient dans la fenêtre de contexte du modèle et change peu, les embeddings ne sont pas obligatoires. Dès que le corpus est grand, vivant et changeant - un index vectoriel coûte presque toujours moins cher que tout mettre dans le prompt à chaque fois.
Comment le texte devient des nombres
Pipeline simplifié :
Document → chunking → embedding model → vecteurs → vector DB
Requête → même embedding model → vecteur requête → recherche Top-K → LLM
1. Chunking
Longs PDF ou bases d'articles découpés en morceaux de 256-1 024 tokens avec chevauchement pour ne pas couper un paragraphe en deux. Chunks trop petits perdent le contexte ; trop grands, la précision.
2. Embedding model
Un modèle spécialisé traite chaque chunk et renvoie un vecteur de dimension fixe - 384, 768, 1 536 ou 3 072 nombres selon le modèle. Cloud : OpenAI text-embedding-3, Cohere, Voyage. Open source : BGE, E5, multilingual-e5 ; aussi en local via Ollama ou serveur dédié.
3. Indexation et recherche
Les vecteurs vont dans un vector store - PostgreSQL avec pgvector, Qdrant, Weaviate, Chroma. À la requête on mesure la distance entre vecteur question et vecteurs base ; le plus courant est la similarité cosinus. Retour des Top-K fragments les plus proches, en général 3 à 10.
La qualité de recherche dépend à ~80 % de « chunking + embedding model », pas du LLM de chat le plus intelligent. Détail retrieval + generation dans l'article RAG.
Proximité sémantique sans magie
La « proximité » des vecteurs n'est pas des synonymes de dictionnaire. Le modèle a été entraîné sur d'énormes corpus pour que des points voisins correspondent à des contextes proches. Donc :
- « prix de livraison » et « coût du service coursier » se retrouvent proches ;
- « Python pour l'analyse de données » est plus proche de « tutorial pandas » que de « serpent au zoo » ;
- sur modèles multilingues, une requête en français peut trouver un paragraphe anglais au même sens.
Important : on ne compare que des vecteurs de la même embedding model et version. Mélanger vecteurs OpenAI et BGE dans un index est invalide - ce sont des cartes différentes.
Où les embeddings apparaissent dans les produits
| Scénario | Rôle des embeddings |
|---|---|
| Chatbot entreprise | Trouver articles pertinents avant l'appel LLM |
| IDE et code | Recherche sémantique repo (Cursor @Codebase, index Copilot) |
| Marketplace | « Produits similaires », recherche par description sans SKU exact |
| Modération | Clustering spam, détection d'avis dupliqués |
| CRM | Appariement de deals similaires, RAG sur base de connaissances pour managers |
Partout le schéma est le même : retrieval sur vecteurs + raisonnement sur LLM. Les embeddings économisent fenêtre de contexte et budget API : seuls les chunks trouvés vont dans le prompt, pas toute la base.
Embeddings vs tokens vs fine-tuning
Trois mécanismes souvent confondus :
| Embeddings | Tokens LLM | Fine-tuning | |
|---|---|---|---|
| Tâche | Recherche par sens | Génération de texte | Changer le comportement du modèle |
| Sortie | Vecteur numérique | Texte / tokens de réponse | Nouveaux poids du modèle |
| Mettre à jour les connaissances | Réindexer documents | Nouveau prompt / RAG | Réentraînement |
| Coût | Moins cher que générer | Paiement input + output | Cher et long |
Un token est unité de facturation et découpage pour modèles de chat. Un embedding est autre produit API avec autre prix au 1M et autre modèle. Comparez les stratégies dans fenêtre de contexte vs RAG vs fine-tuning.
Choisir un embedding model
En pratique, quatre paramètres :
- Langues - corpus mixtes nécessitent modèles multilingues (bge-m3, multilingual-e5, voyage-3).
- Dimension - plus de dimensions souvent plus précis, mais index et stockage plus lourds.
- Latence et coût - pour millions de documents, chiffrer indexation initiale et réindexation aux mises à jour.
- Déploiement - API cloud pour démarrer vite ; modèles locaux pour données privées sans envoi SaaS.
Pour un MVP, un modèle éprouvé et pgvector dans PostgreSQL existant suffit souvent. Plusieurs rerankers et hybride BM25 + vectors ont du sens quand les métriques de recherche plafonnent.
Erreurs typiques
- Indexer « au hasard » - sans nettoyage HTML, sans stratégie de chunking, avec doublons - recherche bruyante.
- Changer de modèle sans réindexer - anciens et nouveaux vecteurs incompatibles.
- Attendre du raisonnement des embeddings - un vecteur ne répond pas ; il faut LLM ou templates sur les chunks.
- Ignorer les métriques - sans jeu de test « question → document attendu », les ajustements au feeling tiennent rarement en prod.
- Confondre avec recherche full-text - pour SKU et codes exacts, mieux vaut hybride keywords + embeddings.
En résumé
Un embedding est une « empreinte numérique du sens » du texte. Il sert quand il faut trouver le pertinent dans un gros corpus : RAG, support, wikis internes, recherche de code. Pour un chat court avec un fichier en contexte, l'index vectoriel est optionnel. Pour une base vivante, les embeddings sont la brique de base ; le LLM se construit dessus, pas à la place.
Questions fréquentes
En quoi un embedding diffère-t-il d'un token ?
Un token est un fragment de texte pour modèles de chat : de lui dépendent longueur du prompt et coût API. Un embedding est un vecteur pour tout un fragment (phrase, paragraphe, chunk) qui capture le sens pour la recherche. Les tokens découpent pour générer ; les embeddings encodent le sens pour comparer.
Pourquoi un embedding model séparé si ChatGPT et Claude existent ?
Les modèles de chat optimisent la génération de réponses. Un embedding model optimise la compression du sens en vecteur compact et recherche rapide. Les encodeurs dédiés coûtent moins sur de gros volumes d'indexation et ne brûlent pas de tokens output chers pour « résumer » des documents.
Peut-on mélanger des vecteurs de modèles différents dans une base ?
Non. Chaque modèle a son espace de coordonnées et sa dimension. Construisez l'index avec une embedding model ; au changement - réindexation complète. Comparez seulement des vecteurs du même encodeur, même version.
Combien coûtent les embeddings via API ?
En général moins cher que la génération de texte du même fournisseur : facturation des tokens input sur l'endpoint embedding, sans output. Prix exact selon modèle et volume ; pour budget mensuel multipliez tokens du corpus par tarif au 1M et prévoyez réindexation. Plus sur les tokens dans coût des tokens.
Un chatbot simple sur le site a-t-il besoin d'embeddings ?
Pas toujours. Si le bot répond depuis une FAQ fixe de quelques pages ou charge un PDF une fois dans la fenêtre de contexte - le prompt suffit. Les embeddings sont utiles quand il y a beaucoup de documents, ils changent souvent et la recherche par formulation utilisateur compte - cas typique de RAG pour support et assistants internes.