Une base de données vectorielle stocke des vecteurs numériques, souvent des embeddings issus de textes, images ou autres objets, et retrouve les vecteurs proches selon une mesure de similarité. La production exige aussi identifiants, contenu source ou références, filtres de métadonnées, droits, mises à jour et garanties opératoires. Certains produits sont dédiés; des bases générales et moteurs de recherche offrent aussi colonnes et index vectoriels. La capacité nécessaire compte plus que l’étiquette du vendeur.
Une démonstration rapide encode un petit corpus propre et retourne des voisins plausibles, puis échoue face aux permissions, doublons, documents changeants, langues, filtres et latence réelle. Les équipes règlent la vitesse sans vérifier si l’embedding représente la tâche. Elles supposent aussi que similarité sémantique signifie pertinence factuelle. La base retourne des candidats; elle ne valide pas l’affirmation, ne préserve pas seule l’autorité et ne rend pas une réponse automatiquement fondée.
Commencez par la décision de recherche et un corpus de requêtes labellisé. Comparez mots-clés, filtres structurés, vecteurs et hybride avant l’infrastructure. Gardez identité source, version, permissions et relations de fragments près de chaque vecteur. Choisissez exact ou approximatif selon rappel, latence, échelle et coût mesurés. Traitez modèle d’embedding, segmentation, index et reranking comme un système versionné et évaluez le résultat aval.
Mécanique
L’index vectoriel est une couche du système de recherche
Un modèle d’embedding projette un objet dans un espace numérique où une distance est censée refléter une relation utile. La recherche exacte compare la requête à tous les candidats. Les index approximatifs réduisent le travail et échangent un peu de rappel contre vitesse et échelle. HNSW est une approche en graphe influente. Son article décrit la méthode hiérarchique small-world; le comportement réel dépend de l’implémentation et des paramètres de construction et recherche.
Une base générale peut ajouter la capacité vectorielle près des données transactionnelles. Le projet open source pgvector, par exemple, prend en charge les recherches exactes et approximatives dans PostgreSQL. Les systèmes dédiés offrent d’autres fonctions d’échelle et d’exploitation. L’architecture suit charge, cohérence, filtres, isolation, changements et compétence de l’équipe. Les embeddings n’imposent pas une nouvelle base.
| Composant | But | Question d’échec |
|---|---|---|
| Modèle embedding | Représenter objets et requêtes | L’espace correspond-il à la tâche? |
| Unité indexée | Définir la preuve récupérable | Le contexte est-il coupé ou dupliqué? |
| Index vectoriel | Trouver vite les candidats | Quel rappel est échangé? |
| Filtre metadata | Borner candidats et portée | Le filtre respecte-t-il les droits? |
| Reranker | Affiner l’ordre | Le coût améliore-t-il le résultat? |
Évaluation
Évaluer la pertinence avec des questions réelles, pas quelques démos
Créez la vérité depuis la décision réelle. Pour le support, l’objet pertinent peut être une procédure approuvée actuelle; pour une proposition, une preuve valable pour un client et une date; pour la découverte, la diversité peut compter autant que la similarité. Arbitrez les désaccords de labels. Segmentez identifiants, texte court ambigu, paraphrases, langues et questions exigeant plusieurs preuves.
Mesurez recherche et génération séparément. Le rappel vérifie si la preuve apparaît; le ranking où; l’évaluation de réponse si elle est bien utilisée. Comparez à une référence lexicale et structurée, car terminologie exacte, codes et dates les favorisent. L’hybride combine des signaux dont les poids exigent aussi des tests. Rejouez après changement d’embedding, segmentation, métadonnées, index ou corpus.
- Labelliser la pertinence pour la vraie tâche.
- Garder recherche exacte et lexicale en référence.
- Tester filtres et permissions réalistes.
- Mesurer la recherche avant la réponse générée.
- Versionner corpus, embeddings, index et évaluation.
Ce qui caractérise un bon résultat
Résultats concrets pour base de données vectorielle
- La recherche est testée sur des requêtes représentatives et preuves arbitrées.
- Chaque vecteur reste lié à une source, une version et une permission.
- Recherche lexicale, structurée, vectorielle et hybride ont un rôle démontré.
- L’index équilibre rappel, latence, écritures, mémoire et coût.
- Suppression et changement de source se propagent prévisiblement.
- Toute la version de recherche est reproductible, comparable et réversible.
Modèle opératoire
Comment exécuter le travail
- 01
Définir la tâche de recherche
Précisez question utilisateur, unité pertinente, autorité source, fraîcheur et permission. Construisez des requêtes pertinentes, non pertinentes, difficiles et multilingues. Incluez identifiants exacts et termes rares.
- 02
Concevoir l’objet indexé
Choisissez modèle, normalisation, limite du fragment, chevauchement, métadonnées et lien original. Définissez tableaux, titres, pièces, versions et sources supprimées. Ne faites jamais du vecteur la seule représentation restante.
- 03
Comparer les méthodes
Exécutez références lexicales, structurées, vectorielles exactes, approximatives et hybrides. Mesurez rappel des candidats et classement avec filtres réels. Ajoutez le reranking si le gain justifie délai et coût.
- 04
Exploiter le cycle de l’index
Versionnez modèle, prétraitement, schéma et réglages. Testez ajouts, mises à jour, suppressions, sauvegarde, reconstruction et retour arrière. Surveillez pertinence, candidats périmés ou interdits, latence et coût.
Évaluation
Les questions qui changent la décision
- Quel objet doit être considéré comme pertinent pour une requête?
- Les termes exacts, le sens ou les attributs structurés dirigent-ils la recherche?
- Quelle distance ou similarité correspond au modèle?
- La recherche exacte tient-elle l’échelle et la latence réelles?
- Comment filtres et droits interagissent-ils avec l’approximation?
- Comment mise à jour et suppression retirent-elles chaque vecteur dérivé?
Modes d’échec
Où les équipes perdent le contrôle
La segmentation sépare l’affirmation de la réserve qui change son sens.
L’index approximatif perd un candidat pertinent sous un filtre strict.
Un changement de modèle mélange des espaces incompatibles.
Les quasi-doublons envahissent les résultats et cachent des preuves diverses.
Filtrer les permissions après recherche divulgue du sensible.
Une source supprimée reste accessible par vecteur ou cache périmé.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- rappel à la profondeur de candidats sur requêtes arbitrées
- précision et qualité du classement par segment
- recherche conforme aux permissions et tentatives de fuite
- fraîcheur après création, mise à jour et suppression
- latence selon taille, sélectivité et charge
- coût stockage, mémoire, embedding et requête par résultat
Questions
Questions fréquentes
Qu’est-ce qu’une base de données vectorielle?
C’est une base ou capacité de recherche qui stocke des vecteurs numériques et retrouve les objets proches par similarité ou distance. En production, elle exige aussi identité source, métadonnées, permissions, mises à jour et opérations.
Une base vectorielle est-elle requise pour le RAG?
Non. Le RAG exige de retrouver des preuves pertinentes, par mots-clés, requêtes structurées, vecteurs exacts, approximatifs ou hybride. Choisissez selon corpus, questions, permissions, fraîcheur, pertinence et exploitation.
Qu’est-ce que la recherche approximative de voisins?
Un index trouve des vecteurs probablement proches sans comparer chaque candidat, échangeant du rappel contre vitesse et échelle. Mesurez ce compromis sur corpus, filtres et requêtes labellisées réels plutôt qu’un benchmark générique.
Comment évaluer la recherche vectorielle?
Utilisez des requêtes représentatives labellisées et mesurez rappel, ranking, permissions, fraîcheur, latence et coût. Comparez lexical, structuré et hybride, puis vérifiez que le résultat utilisateur aval progresse.
Sources
Sources primaires
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→