Découvrez ce qu'est une base de données vectorielle, comment les embeddings permettent la recherche par similarité, et quand choisir pgvector, Pinecone ou Weaviate pour la recherche IA et le RAG.
Une base de données vectorielle est un système conçu pour stocker et rechercher des embeddings : des listes de nombres qui représentent le « sens » de textes, images ou autres données. Au lieu de demander « est‑ce que cet enregistrement contient le mot exact remboursement ? », on demande « quels enregistrements sont les plus similaires à cette question ? » et on obtient les correspondances les plus proches.
Imaginez que chaque document (ou produit, ticket, FAQ) devienne un point sur une carte. Les éléments traitant de la même idée se retrouvent proches, même s'ils utilisent des mots différents. Une base de données vectorielle répond rapidement à la question : qu'est‑ce qui est le plus proche de ce nouveau point ?
Les bases SQL traditionnelles sont excellentes quand vous connaissez la structure de votre requête : filtrer par date, user_id, statut, etc. La recherche par mots‑clés est excellente quand la bonne réponse contient littéralement les mêmes mots que vous tapez.
Les bases vectorielles diffèrent parce qu'elles se concentrent sur la similarité sémantique. Elles traitent des requêtes comme « comment récupérer mon argent ? » et trouvent du contenu qui dit « notre politique de remboursement… » sans exiger la même formulation.
Cela ne remplace pas SQL ni la recherche par mots‑clés. Dans beaucoup de systèmes réels, vous utilisez les deux : SQL/filtres pour les règles métier (région, permissions, fraîcheur) et recherche vectorielle pour le « sens ».
Si vous retenez une phrase : une base de données vectorielle est un moteur « items les plus similaires » pour des embeddings, optimisé pour le faire rapidement et à grande échelle.
Les bases vectorielles fonctionnent parce que les embeddings permettent de comparer le sens numériquement. Vous ne lisez pas les nombres ; vous les utilisez pour classer « à quel point » deux contenus sont proches.
Un embedding est une liste de nombres (souvent des centaines ou milliers) représentant un contenu. Chaque nombre capte un aspect du sens appris par un modèle. On n'interprète pas les nombres individuellement ; l'important est que des contenus similaires produisent des schémas numériques proches.
Pensez‑y comme des coordonnées sur une carte très haute dimension : des phrases sur la « politique de remboursement » et « retourner un produit » atterrissent proches, même si elles n'utilisent pas les mêmes mots.
Différents modèles d'embedding transforment différents médias en vecteurs :
Quand tout est un vecteur, la base peut rechercher sur de larges collections avec la même opération : "trouver les vecteurs les plus proches".
Pour décider de la proximité, on utilise des règles de score simples :
Vous n'avez pas besoin de les calculer à la main : l'important est qu'un score plus élevé signifie « plus semblable ».
La majorité des gains de qualité proviennent d'embeddings et d'un bon découpage plutôt que du simple changement de base. Si votre modèle ne capture pas le langage de votre domaine (noms de produits, jargon interne, formulations juridiques), même l'indice vectoriel le plus performant renverra des réponses « proches mais incorrectes ». Choisir pgvector, Pinecone ou Weaviate compte, mais choisir le bon modèle d'embeddings et le bon format d'entrée est souvent plus déterminant.
Mélanger ces outils est une source courante de déceptions : chacun résout un problème différent.
La recherche traditionnelle (Elasticsearch, Postgres full‑text, etc.) matche des mots et expressions. C'est idéal quand l'utilisateur sait quoi taper et que le document contient ces termes.
Elle peine avec :
Une base vectorielle stocke des embeddings — représentations numériques du sens. Les requêtes sont aussi embedées, et les résultats sont classés par similarité, ce qui permet de récupérer des contenus conceptuellement liés même si les mots diffèrent. C'est pourquoi la recherche vectorielle est prisée pour la recherche sémantique et le RAG.
SQL est l'outil adapté pour :
Les vecteurs sont inadaptés quand la précision est non négociable (par ex. « commandes pour customer_id = 123 »).
Même avec la recherche sémantique, il faut souvent des filtres classiques — fourchettes de prix, dates, langue, catégorie, permissions. La plupart des systèmes réels font un hybride : filtres SQL/métadonnées d'abord, puis classement par similarité vectorielle dans l'ensemble autorisé.
Quand vous stockez des données dans une base vectorielle, chaque élément devient une longue liste de nombres (embedding). Rechercher revient à : « trouver les vecteurs les plus proches de ce vecteur de requête ».
Une base réaliste peut contenir des millions de vecteurs. Comparer votre requête à chaque vecteur serait trop lent et coûteux. Les bases construisent donc un index — une structure qui réduit rapidement les candidats, de sorte que le système ne calcule les distances que pour un sous‑ensemble restreint.
La plupart des recherches utilisent l'ANN. « Approximatif » signifie que la base cherche des correspondances très bonnes rapidement, plutôt que de garantir le top mathématiquement parfait à chaque fois.
Analogie utile : au lieu de parcourir chaque livre d'une bibliothèque, l'ANN vous conduit d'abord vers les bonnes étagères.
Ce compromis se règle souvent avec des paramètres comme « à quel point l'index doit chercher ? »
Pratiquement, le recall est « à quelle fréquence les résultats incluent ce qu'un humain considérerait comme les bonnes réponses ». Pour le RAG, un recall plus élevé réduit souvent le risque d'omission d'informations clés (au prix d'un coût ou d'une latence supérieurs).
Différents produits (pgvector, Pinecone, Weaviate) exposent ces idées avec des valeurs par défaut et des options de réglage différentes, mais l'objectif reste le même : recherche de similarité rapide avec précision contrôlable.
Le flux est majoritairement une boucle "stocker puis récupérer les meilleures correspondances". L'important est de garder la signification (embeddings) avec le contenu original pour que la recherche matche des idées et pas seulement des mots.
On commence par rassembler les documents (pages, PDFs, tickets, descriptions produit), les découper en chunks et générer un embedding pour chaque chunk.
Dans la base on stocke typiquement :
Au moment de la recherche, on embedde la requête utilisateur et on demande les vecteurs les plus proches.
Beaucoup d'équipes mélangent similarité vectorielle et scoring par mots‑clés (type BM25) pour obtenir des correspondances sémantiques et valoriser les termes exacts comme des codes SKU, noms ou messages d'erreur.
Avant ou pendant la récupération, appliquez des filtres métadonnées — particulièrement utile pour les applications multi‑tenant et les permissions. Les filtres améliorent aussi la précision (par ex. « uniquement 90 derniers jours », « uniquement Centre d'Aide »).
Un schéma courant : récupérer rapidement les 50–200 premiers, puis re‑classer les 10–20 meilleurs avec un modèle plus puissant ou des règles (rafraîchissement, priorité source).
Pour le RAG, on prend les chunks finaux et on les envoie comme contexte dans une invite LLM, souvent avec citations et une instruction « ne pas répondre si l'info n'est pas trouvée ». Le résultat est une réponse ancrée dans votre contenu, pas une supposition du modèle.
Si votre but est de valider la qualité de la récupération rapidement, une plateforme de prototypage comme Koder.ai peut aider à créer une application de recherche sémantique ou RAG de bout en bout depuis une interface de chat. En pratique, vous pouvez monter une UI React, un backend Go et une base Postgres (y compris une approche basée sur pgvector) et itérer avec des outils de planification, snapshots et rollback — puis exporter le code source quand vous êtes prêts.
pgvector est une extension PostgreSQL qui permet de stocker et rechercher des vecteurs d'embeddings directement dans votre base existante. Plutôt que d'avoir une base vectorielle séparée, vous ajoutez un nouveau type de colonne (vector) aux mêmes tables qui contiennent déjà utilisateurs, produits, documents et métadonnées.
pgvector brille pour les équipes déjà engagées sur Postgres et souhaitant moins de composants. Si la source de vérité de votre app est Postgres, garder les vecteurs là‑dessous simplifie l'architecture : une stratégie de sauvegarde, un modèle d'accès, des migrations familières et du SQL pour jointures et filtres.
Le gros bénéfice est de rassembler données structurées et vecteurs. Vous pouvez faire une recherche sémantique tout en appliquant des contraintes « normales » comme tenant_id, catégorie, statut ou permissions sans recoller des résultats entre systèmes. Opérationnellement, c'est souvent plus simple : votre déploiement Postgres existant plus une extension.
Des charges vectorielles élevées peuvent pousser Postgres au‑delà de ses réglages par défaut. Il faudra penser aux index vectoriels (IVFFlat ou HNSW), aux paramètres mémoire, au comportement de vacuum et aux patterns de requêtes.
Si vous attendez des collections d'embeddings très grandes, beaucoup de recherches concurrentes ou une croissance rapide, la montée en charge et le tuning peuvent demander plus de travail que pour un service vectoriel managé. Pour beaucoup d'équipes, pgvector est l'option "commencer simple" qui peut aller assez loin.
Pinecone est un service vectoriel entièrement managé : vous lui envoyez des embeddings (vecteurs) avec des IDs et des métadonnées, et il vous fournit une recherche de similarité rapide avec l'opérationnel majoritairement pris en charge.
Avec Pinecone, vous ne vous souciez généralement pas de provisionner des machines, de tuner les réglages bas‑niveau au quotidien ou de bâtir votre propre histoire de scalabilité et de basculement. Vous interagissez via une API pour upserter des vecteurs, interroger les voisins les plus proches et filtrer par métadonnées (langue, tenant, type de document, niveau d'accès).
Pinecone est un bon choix si vous :
Les équipes le choisissent souvent quand le produit dépend d'une récupération de haute qualité et qu'elles préfèrent « la recherche vectorielle comme un service » plutôt que d'avoir encore un système à maintenir.
Le principal atout de Pinecone est la rapidité de passage en production. La mise à l'échelle managée et les fonctions de fiabilité réduisent le temps consacré à la planification de capacité et à la réponse aux incidents. Il s'intègre aussi bien avec les piles IA courantes pour la recherche et le RAG.
Les compromis principaux sont le risque d'enfermement fournisseur et des coûts d'usage continus qui peuvent augmenter avec le volume de requêtes, le stockage et le débit. Vérifiez aussi la résidence des données, les exigences de conformité et la manière dont votre organisation gère les données sensibles avant de vous engager.
Weaviate est une base vectorielle open‑source qui offre un backend de recherche IA complet avec une API GraphQL. Si vous préférez contrôler votre infrastructure (ou déployer sur votre cloud) tout en bénéficiant d'une expérience produit — schéma, filtrage, options d'indexation et intégrations — Weaviate est souvent dans la short‑list.
Weaviate stocke des objets (documents, produits, tickets) avec métadonnées et embeddings vectoriels. On peut l'interroger par similarité tout en appliquant des filtres (« seulement 30 derniers jours », « catégorie = support »). L'API GraphQL facilite des requêtes expressives sans devoir construire beaucoup d'endpoints personnalisés.
Weaviate convient aux équipes qui :
Avantages : bon support schéma/métadonnées, écosystème de modules et intégrations, et options d'indexation configurables pour régler les performances.
Inconvénients : si vous l'exploitez vous‑même, vous êtes responsable de l'exploitation — mises à jour, scalabilité, monitoring, sauvegardes, réponse aux incidents. À mesure que vous ajoutez modules, multi‑tenancy et schémas complexes, le système peut devenir plus difficile à maîtriser sans conventions claires.
Si vous comparez les options, Weaviate se situe souvent entre « simple extension dans votre base » et « service managé », offrant flexibilité au prix d'une responsabilité opérationnelle.
Choisir une base vectorielle relève plus de l'adéquation que du « meilleur » absolu : où vous voulez l'exécuter, la taille attendue, la nature des requêtes et la surcharge opérationnelle que votre équipe peut accepter.
pgvector = vecteurs dans Postgres. Idéal si votre app vit déjà sur Postgres et que vous voulez une seule base pour données métier et embeddings.
Pinecone = managé. Vous échangez du contrôle contre une adoption plus rapide : moins de réglages, moins d'infrastructure à gérer.
Weaviate = open‑source, auto‑hébergeable ou managé. Bon compromis si vous voulez un système vectoriel natif tout en conservant des outils ouverts.
À petite échelle, les trois conviennent. En croissance, posez‑vous :
Si vous attendez une croissance rapide et un QPS élevé, Pinecone gagne souvent sur la simplicité opérationnelle. Si la croissance est modérée et que vous opérez déjà Postgres à grande échelle, pgvector peut être plus économique.
Si vous avez de lourds besoins de filtrage relationnel (jointures, prédicats complexes) avec similarité, pgvector est attractif.
Pour la recherche hybride (mots‑clés + sémantique), filtrage riche ou isolation multi‑tenant forte, comparez Pinecone et Weaviate fonctionnalité par fonctionnalité.
Soyez honnêtes sur sauvegardes, monitoring, upgrades et charge on‑call. Le managé réduit la charge. L'auto‑hébergement peut coûter moins cher, mais seulement si votre équipe a les compétences et le temps pour l'exploiter.
Une bonne recherche vectorielle commence par un schéma sobre et fiable. Traitez chaque « unité searchable » comme une ligne/objet que l'on peut récupérer, filtrer et expliquer plus tard.
Au minimum, stockez :
Cela garde la récupération simple : la recherche vectorielle renvoie des ids, puis on récupère le chunk + contexte pour afficher ou alimenter le RAG.
Le chunking est le principal levier de qualité que vous contrôlez. Chunks plus petits = plus précis mais parfois hors contexte ; chunks plus grands = plus de contexte mais signal dilué.
Point de départ courant : 200–400 tokens avec 10–20% d'overlap, puis ajustez selon le contenu.
Conservez les métadonnées que vous interrogez réellement :
Évitez de stocker d'énormes blobs JSON pour les champs fréquemment filtrés ; préférez des champs indexables.
Les embeddings évoluent. Enregistrez embedding_model, model_version et chunking_version (et created_at). Quand vous mettez à jour un modèle, re‑embeddez en parallèle et basculez progressivement le trafic sans mélanger des vecteurs incompatibles.
La recherche vectorielle paraît instantanée en démo, puis peut ralentir ou coûter cher en production. Bonne nouvelle : les principaux leviers sont prévisibles et gérables, que vous utilisiez pgvector, Pinecone ou Weaviate.
Beaucoup sous‑estiment les parties hors‑recherche :
Une meilleure recherche ne garantit pas de meilleures réponses automatiquement.
Créez un petit jeu de test : 30–100 requêtes réelles, chacune avec quelques résultats « bons » attendus. Mesurez la pertinence (taux de hit dans le top‑k) et suivez les changements quand vous touchez chunking, index ou prompts.
Considérez les embeddings comme potentiellement sensibles.
La qualité de la recherche vectorielle n'est pas que technique — c'est aussi comment vous opérez le système. Quelques habitudes de gouvernance évitent des résultats mystérieux et facilitent les audits.
Si vos documents contiennent des données sensibles, envisagez de garder le contenu brut dans votre datastore principal (stockage d'objets, BDD, DMS) et de ne stocker que :
Cela réduit l'exposition si le store vectoriel est compromis et simplifie le contrôle d'accès. C'est aussi utile quand vous utilisez plusieurs backends (pgvector pour usages internes, Pinecone pour une fonctionnalité publique).
Les embeddings peuvent « garder » de l'ancien texte si vous ne les nettoyez pas.
Consignez assez pour déboguer la pertinence sans stocker de secrets :
Cela rend les dérives et régressions évidentes après des changements de modèle ou de données.
Planifiez la rétention (durée de vie des vecteurs et logs), chiffrement en transit/au repos et besoins d'audit (qui a cherché quoi, quand). En environnements régulés, documentez les flux et chemins d'accès pour ne pas bloquer les sorties en revue.
Même une bonne configuration vectorielle peut décevoir si quelques pièges surviennent. En voici les plus fréquents et comment les corriger tôt.
Les vecteurs excellent pour le sens, pas pour les contraintes strictes. Si vous n'utilisez que la recherche sémantique, les résultats peuvent paraître aléatoires ou dangereux.
Évitez‑le : combinez similarité avec filtres structurés (tenant_id, catégorie, langue, dates). Faites du filtrage métadonnées une partie intégrante de la conception des requêtes.
Une démo convaincante sur quelques prompts peut masquer des problèmes de recall et de pertinence.
Évitez‑le : construisez un petit jeu d'évaluation (30–100 requêtes réelles) et suivez des métriques simples (pertinence top‑k, taux de clics, jugements humains). Réévaluez à chaque changement d'embeddings, chunking ou index.
Les modèles d'embeddings évoluent. Changer de modèle (ou de version) modifie l'espace vectoriel et peut dégrader silencieusement la recherche.
Évitez‑le : stockez le champ embedding_model et traitez les embeddings comme des artefacts versionnés. Ayez une pipeline de ré‑embedding et planifiez des backfills (par incréments si le coût est un facteur). Re‑embeddez d'abord le contenu le plus utilisé si nécessaire.
Si votre application a un contrôle d'accès, la récupération doit le respecter — sinon vous exposez du contenu restreint.
Évitez‑le : appliquez les permissions lors de la récupération en utilisant des index par tenant, des filtres métadonnées ou des champs ACL précomputés. Vérifiez par des tests : "l'utilisateur A ne doit jamais récupérer les documents de l'utilisateur B", même parmi les top‑k candidats.
Une base de données vectorielle est un système conçu pour stocker des embeddings (représentations numériques de textes, images ou autres) et récupérer rapidement les items les plus similaires. Elle est pertinente quand les utilisateurs cherchent par sens (recherche sémantique) ou quand vous construisez du RAG pour qu'un assistant IA puise dans vos contenus avant de répondre.
Règles pratiques :
Montez un petit proof of concept en une journée :
Si vous voulez des conseils d'implémentation ou sur les coûts, voyez /blog. Pour considérations tarifaires ou options hébergées, consultez /pricing.
Une base de données vectorielle stocke et recherche des embeddings (vecteurs : longues listes de nombres) qui représentent le sens de textes, images ou autres données. Plutôt que de trouver des occurrences exactes de mots, elle renvoie les éléments qui sont les plus similaires à une requête dans l'espace sémantique — utile quand des intentions identiques sont formulées avec des mots différents.
Un embedding est une « empreinte » numérique du contenu produite par un modèle ML. On n'interprète pas chaque nombre isolément ; on utilise l'ensemble du vecteur pour comparer des éléments. Les contenus similaires (par ex. « politique de remboursement » et « retourner un produit ») se retrouvent proches, permettant la recherche sémantique.
La recherche par mots‑clés trouve des correspondances sur les mots et expressions (utile pour les termes exacts). La recherche vectorielle trouve le sens (utile pour synonymes et paraphrases). En pratique, on utilise souvent une recherche hybride :
SQL est idéal pour des questions structurées et exactes : IDs, jointures, agrégations, filtres stricts. La recherche vectorielle sert pour les requêtes floues de type « trouver similaire ». Un schéma courant est :
La plupart des systèmes utilisent l'indexation ANN (Approximate Nearest Neighbor). Plutôt que de comparer le vecteur de la requête à tous les vecteurs stockés, l'index réduit les candidats pour que seuls quelques éléments soient réellement évalués. On sacrifie un peu de garantie de perfection au profit d'une grande vitesse et d'un coût réduit.
Cosine similarity compare la direction des vecteurs (pointent‑ils de la même façon ?). Le produit scalaire (dot product) récompense une direction proche et peut aussi prendre en compte la magnitude selon la normalisation des embeddings.
Pratiquement : utilisez la métrique recommandée pour votre modèle d'embeddings et soyez cohérent pour l'indexation et les requêtes.
Le chunking détermine ce que représente chaque vecteur. Trop grand : contexte bruyant et mélange de sujets. Trop petit : perte de contexte important.
Démarrage pratique :
Ajustez ensuite selon le type de contenu (APIs/texte légal plutôt petits ; narratifs plutôt plus grands).
Le RAG suit en général :
Choisir selon le déploiement et la tolérance aux opérations :
Pièges fréquents :
