Une base de données vectorielle répond à une seule question, très vite
Donnez-lui une liste de nombres et elle renvoie les listes stockées qui en sont les plus proches. C'est toute l'interface.
Ces listes sont des embeddings. Un modèle d'embedding transforme un passage, une description de produit ou une image en quelques centaines à quelques milliers de nombres, placés de sorte que des sens similaires se retrouvent proches les uns des autres, et qu'est-ce qu'un embedding en IA explique comment. Une base de données vectorielle est l'endroit où vivent ces listes une fois qu'on en a beaucoup. Elle stocke chacune avec un identifiant et des métadonnées, construit un index dessus, et répond à la recherche des plus proches voisins : "voici un vecteur de requête, donne-moi les dix plus proches."
La difficulté tient au mot rapide. Comparer une requête à un million de vecteurs stockés de 1536 nombres chacun représente 1,5 milliard de multiplications, et faire cela à chaque frappe ne tient pas à l'échelle. Les bases de données vectorielles utilisent donc des index de plus proches voisins approximatifs, le plus courant étant HNSW, une structure en graphe issue d'un article de 2016 de Malkov et Yashunin, qui visite quelques centaines de candidats au lieu du million entier et trouve la bonne réponse presque à chaque fois. Ce "presque" est le compromis : un peu de rappel contre une accélération par mille.
Votre base de données existante trouve des mots ; une base de données vectorielle trouve du sens
Une base de données relationnelle trouve des lignes dont les valeurs correspondent : WHERE customer_id = 4127. Un index plein texte trouve des documents contenant des mots : remboursement ET politique. Une base de données vectorielle trouve des éléments dont le sens est proche : la requête "comment récupérer mon argent" renvoie le passage intitulé "Retours et remboursements" alors que les deux ne partagent aucun mot.
| Base de données relationnelle | Recherche plein texte | Base de données vectorielle | |
|---|---|---|---|
| Demande | Quelles lignes correspondent à cette valeur ? | Quels documents contiennent ces mots ? | Quels éléments ont un sens proche de ceci ? |
| Index | B-tree sur les colonnes | Index inversé sur les termes | Graphe ou clustering sur les vecteurs (HNSW, IVF) |
| Exact ? | Oui | Oui | Généralement approximatif |
| Fort pour | IDs, dates, montants, jointures | Noms, codes, phrases exactes | Synonymes, paraphrase, multilingue, images |
| Faible pour | Le sens | Le sens | Chaînes exactes, comptage, filtrage par valeur |
| Exemples | Postgres, MySQL, SQLite | Elasticsearch, Lucene | Pinecone, Weaviate, Qdrant, Milvus, Chroma, pgvector |
La dernière ligne montre à quel point la catégorie est floue. pgvector ajoute des colonnes vectorielles et un index HNSW à un Postgres ordinaire, et Elasticsearch propose un champ vectoriel depuis la version 7.0 en 2019 et la recherche HNSW depuis la 8.0 en 2022. Une "base de données vectorielle" est souvent une capacité intégrée à une base que vous utilisez déjà, plutôt qu'un nouveau produit, et les produits autonomes se distinguent par l'échelle et la finition opérationnelle, pas en faisant quelque chose que Postgres ne peut pas.
Le chat avec vos documents est une recherche vectorielle avec un modèle au bout
La génération augmentée par récupération, que qu'est-ce que le RAG détaille, comprend une étape de recherche et une étape de rédaction. La base de données vectorielle est l'étape de recherche.
- Découper chaque document en passages de quelques centaines à un millier de tokens.
- Créer l'embedding de chaque passage et stocker les vecteurs, avec le texte du passage et sa source, dans la base de données vectorielle.
- Quand une question arrive, créer son embedding et demander à la base les passages les plus proches.
- Transmettre ces passages au modèle de langage avec la question, et le laisser rédiger la réponse.
Les étapes 1 et 2 ont lieu une fois, à l'ajout des documents. Les étapes 3 et 4 ont lieu à chaque question. Le modèle de langage ne voit jamais toute la collection ; il voit les cinq ou dix passages choisis par la base. C'est pourquoi la réponse vaut ce que vaut la recherche : si le vecteur le plus proche est le mauvais passage, le modèle répond avec assurance à côté de la question, ce que qu'est-ce qu'une hallucination de l'IA classe comme un raté de récupération plutôt qu'une invention.
Quand en avoir besoin, et quand envoyer le fichier entier vaut mieux
La décision tient à la taille. Un modèle ne peut prendre en compte que sa fenêtre de contexte à la fois, et chaque token qu'elle contient est facturé à chaque tour. Une base de données vectorielle sert à ne présenter au modèle que la tranche pertinente. Pour un seul document qui tient dans la fenêtre, la récupération est une étape que l'on peut sauter ; pour une collection qui n'y tient pas, c'est la seule option.
Comparons les prix des deux approches sur un rapport de 300 000 tokens, plusieurs centaines de pages, avec dix questions posées, récupérant cinq passages de 1000 tokens par question. Envoyer le fichier entier à chaque fois représente 3 millions de tokens en entrée. Récupérer cinq passages de 1000 tokens par question en représente 50 000. Aux tarifs d'entrée affichés dans l'index des coûts des modèles d'IA, récupérés sur OpenRouter le 2026-08-20, l'écart est de 60x sur chaque modèle. La mise en cache des prompts, quand le fournisseur la propose, facture une relecture du même fichier à un dixième ou une moitié du tarif affiché, ce qui réduit l'écart à environ 6x à 30x. La récupération l'emporte encore, mais de moins loin.
L'approche du fichier entier offre quelque chose pour cet argent quand le fichier tient dans le budget : un contrat de 60 pages, environ 40 000 tokens, permet au modèle de répondre à des questions qui exigent le document entier à la fois, comme "est-ce que quelque chose ici contredit la clause 14", ce que la récupération ne peut pas faire car elle ne voit jamais la clause 14 et la contradiction dans le même lot. La règle qui en découle : un document, ou une poignée, part en entier ; une bibliothèque passe par une base de données vectorielle. Entre les deux, découpez l'upload par thème pour que le modèle obtienne la section dont il a besoin.
Whizi envoie le texte lui-même, jusqu'à 40 000 tokens par tour
Whizi ne fait pas tourner de base de données vectorielle pour votre chat. Quand vous joignez un fichier, le chemin d'upload de documents extrait le texte et l'envoie au modèle comme texte de prompt, jusqu'à un budget fixe de 40 000 tokens par tour ; un upload plus long est coupé, avec une notification et un repère dans le message qui le signale. Les fichiers de projet fonctionnent de la même façon : la fonctionnalité projets épingle jusqu'à 10 fichiers et reconstruit leur texte dans le prompt à chaque message, plafonné à 32 000 caractères par fichier et 120 000 pour l'ensemble du bloc projet.
Les plafonds sont la limite de la conception. Un fichier épinglé au-delà de 32 000 caractères est tronqué, une pièce jointe au-delà du budget de 40 000 tokens par tour est coupée, et un projet est un dossier, pas une bibliothèque consultable. Le compromis est délibéré : pour un contrat ou un article qui tient dans le budget du tour, avoir le texte présent vaut mieux que l'avoir cherché, et le contrôle qui compte, demander au modèle de citer le passage utilisé, fonctionne parce que le passage est là. Pour mille documents, une base de données vectorielle est le bon outil et une appli de chat le mauvais.
Deux habitudes découlent de ce mécanisme. Nommez le fichier dans votre question dès que plusieurs sont joints, car sinon le modèle choisit en silence. Et pour toute réponse sur laquelle vous allez agir, demandez la citation. Un système de récupération peut renvoyer le mauvais passage ; un système à fichier entier peut répondre de mémoire plutôt qu'à partir du fichier. La citation attrape les deux cas.
- Envoyez un seul document en entier ; placez une collection derrière une base de données vectorielle
- Découpez un long upload par thème pour que le modèle obtienne la section dont la question a besoin
- Demandez au modèle de citer le passage utilisé avant de vous fier à la réponse
- Utilisez la recherche plein texte pour les identifiants, codes et phrases exactes ; la recherche vectorielle trouve du sens, pas des caractères
- Traitez un raté de récupération comme un problème de recherche : réencodez avec un meilleur modèle ou des passages plus petits avant de blâmer le modèle rédacteur
Questions fréquentes
Qu'est-ce qu'une base de données vectorielle en termes simples ?
Un espace de stockage pour les listes de nombres qu'un modèle d'IA utilise pour représenter le sens, conçu pour trouver rapidement les correspondances les plus proches. Vous lui donnez l'embedding d'une question et elle renvoie les embeddings, et le texte derrière eux, dont le sens est proche. C'est la moitié recherche du chat avec vos documents dès que la collection est trop volumineuse pour être envoyée en entier.
Ai-je besoin d'une base de données vectorielle pour utiliser l'IA avec mes documents ?
Seulement si les documents ne tiennent pas dans la fenêtre de contexte du modèle. Un seul rapport ou contrat peut être envoyé au modèle en entier, ce que fait Whizi avec les pièces jointes et les fichiers de projet épinglés. Une bibliothèque de milliers de documents a besoin de récupération, et la récupération a besoin d'un index vectoriel, que ce soit dans un produit dédié ou une extension Postgres comme pgvector.
Quelle est la différence entre une base de données vectorielle et une base de données classique ?
Une base de données classique fait correspondre des valeurs : cet ID, cette date, ce mot exact. Une base de données vectorielle fait correspondre du sens, en renvoyant les éléments stockés dont les embeddings sont les plus proches de celui de la requête. Elle est généralement approximative, utilisant un index comme HNSW qui vérifie quelques centaines de candidats au lieu de chaque élément, et elle est faible sur la correspondance exacte que fait bien une base de données classique.
Quelles bases de données vectorielles sont les plus utilisées ?
Pinecone, Weaviate, Qdrant, Milvus et Chroma sont les produits autonomes courants, et pgvector ajoute la même capacité à Postgres. Elasticsearch et OpenSearch proposent aussi la recherche vectorielle. Le choix est généralement opérationnel, une question d'échelle et d'hébergement, car tous mettent en œuvre la même idée de plus proches voisins approximatifs.
Combien la récupération fait-elle économiser par rapport à l'envoi du fichier entier ?
Dix questions sur un rapport de 300 000 tokens coûtent $6.00 sur Claude Sonnet 5 si le fichier est envoyé à chaque tour, et $0.10 si cinq passages de 1000 tokens sont récupérés à la place, aux tarifs affichés par OpenRouter récupérés le 2026-08-20. Sur GPT-5.6 Luna, la même paire donne $0.60 contre $0.01. Le ratio est de 60x sur chaque modèle car les deux approches paient le même tarif par token.
