Embeddings & vector DB : base d'un chatbot RAG (2026)

Pourquoi vous vous retrouvez à parler de vecteurs (même si vous n'aimez pas les maths)

Vous voulez un chatbot qui répond correctement.

Pour ça, vous voulez un chatbot qui trouve la bonne information.

Le problème : les humains ne parlent pas en mots-clés. Ils parlent en intentions.

“J’ai oublié mon mot de passe” = “Je ne peux plus me connecter” = “Ça me dit identifiants invalides”.

Une recherche keyword peut rater. Une recherche sémantique (vectorielle) est faite pour ça.

Dans une architecture RAG, le retrieval est la moitié du succès. (Voir : RAG pour chatbot.)

Définition : un embedding, c'est quoi ?

Un embedding est une représentation numérique (un vecteur) qui capture le sens d'un contenu.

Deux contenus proches en sens → deux vecteurs proches dans l'espace.

Les fournisseurs exposent des APIs d'embeddings :

• OpenAI documente l'usage des modèles d'embeddings via son API.¹
• Google (Gemini API) documente des endpoints d'embeddings.²
• Mistral documente son API d'embeddings (ex. mistral-embed).³
• Cohere documente ses modèles d'embeddings (ex. embed-v4.0).⁴

Ce qu'une vector database fait (et ce qu'elle ne fait pas)

Une vector database n'est pas une base de données “magique”.

Elle fait surtout trois choses :

1. Stocker des vecteurs (embeddings) + métadonnées.
2. Trouver les vecteurs les plus proches d'une requête (k-NN).
3. Le faire rapidement, à grande échelle.

Ce qu'elle ne fait pas :

• vérifier la vérité,
• comprendre votre compliance,
• choisir la bonne version d'un document.

C'est votre architecture qui fait ça.

Similarité : comment la machine décide que deux textes “se ressemblent”

Vous n'avez pas besoin de faire un cours de géométrie. Mais comprendre l'intuition aide à debugger.

Un embedding est un vecteur (une liste de nombres). La recherche vectorielle compare ces vecteurs via une mesure de similarité.

Dans la pratique, vous verrez souvent :

• cosine similarity (angle entre vecteurs),
• dot product (produit scalaire),
• parfois des distances (euclidienne) selon les index.

Vous n'avez pas besoin de choisir “la bonne formule” au début : votre stack le fait. Mais vous avez besoin de comprendre le symptôme :

• si votre recherche renvoie des chunks “proches mais hors-sujet”, vous avez un problème de représentation (embeddings), de chunking, ou de bruit documentaire;
• si elle renvoie des chunks “très généraux”, vous manquez souvent de métadonnées ou de reranking;
• si elle renvoie “rien de bon”, votre base est peut-être mal indexée (ou trop petite).

Cette compréhension évite le réflexe : “changeons de modèle”. Souvent, le modèle n'est pas le vrai problème.

Pipeline RAG : où vivent les embeddings

Le pipeline typique :

1

Ingestion

Vous collectez vos documents (PDF, pages, base de connaissance).

2

Chunking

Vous découpez en morceaux cohérents (sections, paragraphes).

3

Embedding documents

Vous générez un embedding par chunk, via un modèle d'embeddings (provider ou open-weight).

4

Indexation

Vous stockez vecteur + texte + métadonnées dans la vector DB.

5

Embedding query

À chaque question utilisateur, vous générez l'embedding de la requête.

6

Retrieval + rerank

Vous récupérez top-k chunks, éventuellement rerank, puis injectez au LLM.

Cette mécanique est simple. Les détails font toute la différence.

Les index (HNSW, IVF, etc.) : pourquoi la vector DB n'est pas un simple tableau

Quand vous avez 1 000 chunks, vous pourriez théoriquement comparer votre requête à tout. Quand vous avez 1 000 000 chunks, vous n'avez plus ce luxe.

Les vector DB utilisent des structures d'index (souvent de l'approximate nearest neighbors) pour retrouver vite des candidats “assez proches”.

Le point à retenir :

• plus l'index est approximatif, plus vous gagnez en vitesse,
• mais vous pouvez perdre un peu en rappel (vous ratez parfois le meilleur chunk).

C'est une autre raison pour laquelle le reranking est utile : il corrige une partie de l'approximation.

Si vous n'avez pas besoin d'une base gigantesque, gardez votre setup simple. L'optimisation précoce est une manière polie de dire “on se distrait”.

Document embedding vs query embedding : attention au “mode”

Certains fournisseurs distinguent :

• embeddings “document” (pour indexer),
• embeddings “query” (pour rechercher).

Cohere, par exemple, décrit des “input types” différents selon l'usage (search_document vs search_query, etc.).⁵

Pourquoi ? Parce que la requête et le document ne sont pas la même chose :

• la requête est courte, intentionnelle,
• le document est long, descriptif.

Si vous mélangez ces modes, vous perdez de la pertinence.

Multimodal embeddings : quand votre RAG doit comprendre autre chose que du texte

Dans certains secteurs, l'information utile n'est pas un paragraphe. C'est :

• une image (photo d'un produit, d'un dommage),
• un scan,
• un tableau.

Les embeddings multimodaux permettent de représenter différents types de contenus dans un espace comparable.

Cohere, par exemple, présente Embed v4.0 comme une génération multimodale pour texte et images (selon la doc).⁶

Cela ouvre des cas d'usage :

• retrouver une procédure à partir d'une photo,
• indexer des documents scannés,
• améliorer la recherche quand les utilisateurs envoient des captures d'écran.

Mais attention : la multimodalité ajoute des contraintes :

• ingestion plus complexe (OCR, normalisation),
• coûts plus élevés,
• questions de données sensibles (une image peut contenir une pièce d'identité).

Ne “faites pas multimodal” parce que c'est cool. Faites-le si votre support en a besoin.

Chunking + embeddings : le duo qui décide de votre recall

Deux erreurs classiques :

Erreur 1 : chunks trop grands

Vous récupérez un chunk qui contient la réponse… mais noyée. Le LLM “voit” trop de bruit, et se trompe.

Erreur 2 : chunks trop petits

Vous récupérez des miettes, sans contexte. Le LLM invente les liens entre miettes.

Le bon chunking dépend du document :

• contrats : sections + exceptions + définitions → chunks “structurels”
• FAQ : question + réponse → chunks “Q/A”
• procédures : étapes → chunks “workflow”

Opérations : re-indexer, mettre à jour, et ne pas exploser votre budget

Un RAG en production n'est pas un export Excel qu'on refait une fois.

Vous aurez :

• des nouveaux documents,
• des documents supprimés,
• des documents corrigés,
• des versions.

Donc vous avez besoin d'une stratégie de mise à jour :

• full rebuild (simple, mais coûteux),
• incremental indexing (plus complexe, mais souvent nécessaire),
• versioning (garder l'historique, ou non).

Et vous devez décider :

• à quelle fréquence indexer,
• qui valide les documents,
• comment vous purgeez.

Ce n'est pas “technique”. C'est du produit + gouvernance.

Si vous sautez cette étape, votre chatbot commencera bien, puis deviendra incohérent : contradictions, sources obsolètes, et réponses qui changent selon l'humeur des index.

Hybrid search : quand vector + keyword est plus robuste

En entreprise, vous avez souvent des requêtes mixtes :

• du sens (“résilier”),
• et des identifiants (“contrat 8391”, “article 7.2”).

La recherche hybride combine :

• vector search (sens),
• keyword search (exact),
• puis reranking.

Résultat : meilleur rappel et meilleure précision.

Reranking : la couche “qualité” (souvent indispensable)

Le vector search vous donne des candidats. Le reranker met le bon en haut.

Sans reranking, vous pouvez récupérer des chunks “proches”, mais pas “répondants”.

Le reranking coûte plus (compute), mais augmente la pertinence.

Si votre chatbot est critique (support, conformité), le reranking est souvent rentable.

Metadonnées : le super-pouvoir sous-utilisé

La recherche purement sémantique ne connaît pas votre contexte :

• pays,
• produit,
• version,
• date,
• rôle utilisateur.

Ajoutez des métadonnées et filtrez.

Exemple :

• si l'utilisateur est en Belgique, filtrez les docs FR-BE,
• si le produit est “Premium”, filtrez Premium,
• si la date est 2026, filtrez la version 2026.

Cette discipline réduit les contradictions, et améliore la qualité “perçue”.

Évaluer embeddings + retrieval : ce qui se mesure se corrige

Beaucoup d'équipes évaluent “la réponse du chatbot”. Mais si le retrieval est mauvais, la réponse sera mauvaise.

Donc, évaluez :

• recall (a-t-on récupéré un chunk qui contient la réponse ?),
• precision (les chunks sont-ils pertinents ?),
• groundedness (la réponse s'appuie-t-elle sur les chunks ?).

On détaille la méthode et les rubriques ici : Évaluer un chatbot IA.

Exemple terrain : “ça trouve, mais pas ce que je veux”

Scénario réel (classique) :

Vous lancez votre RAG. Vous posez une question simple. La réponse est à côté.

Vous regardez les chunks récupérés : ils parlent du bon sujet général, mais pas de la clause que vous visiez.

Avant de changer de modèle, posez-vous ces questions, dans cet ordre.

1) Est-ce que la clause existe dans la base ?

Ça paraît stupide. Et pourtant, c'est fréquent :

• le PDF n'a pas été ingéré correctement,
• l'OCR a raté une page,
• ou la version la plus récente n'est pas indexée.

2) Le chunking respecte-t-il la structure ?

Si vous chunkiez “au hasard” (toutes les 800 tokens), vous pouvez couper :

• une définition en deux,
• une exception loin de la règle,
• une clause sans son contexte.

Résultat : le retrieval ne peut pas vous ramener “le bon bloc”.

3) Les métadonnées filtrent-elles correctement ?

Si vous avez plusieurs produits/pays, vous devez filtrer.

Sinon, le retrieval est honnête : il vous renvoie le chunk le plus proche. Mais ce chunk peut venir d'un autre produit.

Le chatbot répond donc correctement… pour un autre client.

4) Hybrid search est-il nécessaire ?

Si l'utilisateur tape “article 7.2”, la vector search peut trouver “résiliation” mais rater “7.2”. Ajoutez du keyword.

5) Le reranking améliorerait-il la précision ?

Le retrieval donne une shortlist. Le reranker choisit le meilleur.

Si vos top-k contiennent la bonne clause mais pas en première position, le reranking est souvent la meilleure optimisation.

6) Le prompt force-t-il l'ancrage ?

Dernier point : même si le chunk est bon, le modèle peut “élargir”. Un prompt strict (“répond uniquement à partir des sources”) limite cette dérive.

Ce diagnostic vous donne une super-puissance : vous corrigez le bon composant. Et vous évitez la solution “bling” (changer de modèle) qui coûte cher et masque le vrai problème.

Choisir un modèle d'embeddings (sans vous noyer)

Critères pragmatiques :

• qualité sur vos langues (français),
• qualité sur vos types de docs (contrats, tickets),
• latence et coût,
• support multimodal (si images/scans),
• stabilité et documentation.

Les docs de Mistral (embeddings), Google (embeddings) et Cohere (embed-v4.0 multimodal) peuvent guider selon vos besoins.²³⁶

Les pièges qui cassent un RAG (et que les embeddings ne sauveront pas)

• documents obsolètes,
• contradictions,
• ingestion sans nettoyage,
• absence de RBAC,
• prompts permissifs (“utilise tes connaissances”),
• pas de logging retrieval.

Les embeddings sont un moteur de recherche. Ils ne sont pas une gouvernance.

Choisir une vector DB : une checklist utile (et volontairement simple)

Avant d'acheter ou de self-host, posez-vous ces questions :

• avez-vous besoin de filtres avancés sur métadonnées ?
• avez-vous besoin d'index multimodal ?
• quel volume (chunks) cible à 6 mois ?
• quelle latence maximale acceptable ?
• qui opère l'infra (SRE/MLOps) ?
• besoin de chiffrement / résidence des données ?

Si vous ne pouvez pas répondre, commencez petit :

• 1 domaine,
• 1 index,
• 1 boucle d'évaluation.

Puis vous verrez ce qui bloque vraiment.

Checklist “zéro à héros” embeddings / vector DB

• choisir 1 source documentaire prioritaire,
• chunker et indexer,
• ajouter métadonnées (pays, produit, date),
• activer hybrid search si besoin,
• ajouter reranking si la pertinence est insuffisante,
• mesurer recall/precision sur 50 questions réelles,
• logguer et itérer.

Ce n'est pas spectaculaire. Mais c'est exactement comme ça qu'un chatbot devient fiable.

Et c'est aussi ce qui rend votre contenu “citable” : quand vos réponses s'appuient sur des passages retrouvables, vous pouvez expliquer d'où vient l'information. Un chatbot qui sait retrouver est un chatbot qui sait justifier. Et en B2B, la justification est souvent plus précieuse que la brillance.

Si vous prenez une habitude dès aujourd'hui : à chaque amélioration du chatbot, demandez-vous “est-ce que ça améliore le retrieval ou la génération ?”. Cette question vous force à regarder au bon endroit. Et elle vous évite de confondre une amélioration de style (sympa) avec une amélioration de fiabilité (vital).

Et versionnez vos embeddings : quand vos sources changent, re-indexez. Sinon, vous optimisez une base qui n'existe déjà plus. Ça change tout.

Et si vous devez arbitrer entre “une nouvelle feature” et “rendre le retrieval plus robuste” (métadonnées, hybrid search, reranking), choisissez le retrieval. C'est rarement sexy, mais c'est ce qui transforme un chatbot agréable en chatbot réellement utile. C'est immédiat, vraiment.

FAQ

Questions frequentes

Puis-je faire du RAG sans vector DB ?+

Oui, sur un petit volume, vous pouvez faire une recherche simple (keyword) ou un scan. Mais dès que les documents et formulations se multiplient, la recherche sémantique via embeddings devient très utile.

Les embeddings éliminent-ils les hallucinations ?+

Non. Ils améliorent le retrieval. Pour réduire les hallucinations, il faut RAG + prompts stricts + garde-fous + évaluation.

Pourquoi mon RAG répond mal alors que j'ai une vector DB ?+

Souvent : chunking mauvais, métadonnées absentes, documents obsolètes, ou absence de reranking. Le retrieval est un système, pas un composant unique.

Sources et references

1. [1]OpenAI, “Embeddings guide”.
2. [2]Google, “Embeddings API” (Gemini).
3. [3]Mistral AI, “Embeddings”.
4. [4]Cohere, “Embeddings” (docs).
5. [5]Cohere, “Embed API reference” (input types).
6. [6]Cohere, “Embed v4.0” (multimodal).