Comparer les bases vectorielles à grande échelle

Comparer les bases vectorielles à grande échelle

Le choix d’une base vectorielle ne se résume pas à comparer des requêtes par seconde sur un jeu de démonstration. Le compromis central oppose latence, rappel, coût mémoire, vitesse d’ingestion et complexité d’exploitation, avec un détail agaçant : améliorer un axe dégrade presque toujours un autre.

Explication de la marmotte

Chercher un document par son sens ressemble à retrouver une chanson dont on a oublié le titre mais retenu l’ambiance. Une base spécialisée sert à parcourir une immense collection sans lire chaque élément un par un, tout en gardant assez de précision pour ne pas répondre avec une recette de gratin à une question sur les contrats.

→ Lire l’explication complète de la marmotte

La première décision n’est pas le produit, mais le niveau de garantie attendu. Pour une recherche conversationnelle interne, un résultat absent est souvent moins grave qu’un résultat interdit. Pour un moteur documentaire avec droits fins, filtrer l’accès après la recherche est une erreur d’architecture, pas une optimisation différée.

Les fondations de la recherche sémantique restent décrites dans Embeddings : vecteurs, recherche sémantique et RAG. Cette page traite le problème suivant : sélectionner et régler le moteur de recherche lorsque l’index n’est plus un jouet posé à côté d’un notebook.

HNSW, IVF et recherche exacte : le compromis performance

La recherche exacte compare le vecteur de requête à tous les vecteurs stockés. Elle fournit le meilleur rappel, c’est-à-dire la proportion des voisins réellement pertinents retrouvés, mais son coût croît linéairement avec le corpus. Elle reste le bon étalon pour mesurer les autres méthodes et le bon choix lorsque l’ensemble interrogé est petit après filtrage métier.

La recherche approximative de voisins, ou ANN (Approximate Nearest Neighbor), accepte de manquer certains résultats proches afin de réduire la latence. Ce n’est pas une dégradation accidentelle : c’est le contrat. Afficher un taux de rappel sans préciser la latence, les filtres et la distribution des requêtes relève de la décoration de slide.

L’index HNSW (Hierarchical Navigable Small World) organise les vecteurs dans un graphe à plusieurs niveaux. Il offre généralement une faible latence et un excellent rappel, avec des insertions en ligne convenables. Son prix est la mémoire : les liens entre nœuds s’ajoutent aux vecteurs, et les paramètres M et efConstruction font rapidement gonfler l’empreinte. Réduire efSearch accélère la recherche mais diminue le rappel. Il faut mesurer cette courbe, pas choisir 64 parce qu’un billet de blog l’a décidé un mardi.

L’index IVF (Inverted File Index) partitionne l’espace vectoriel en cellules, puis ne cherche que dans une partie d’entre elles. Il consomme moins de mémoire qu’un graphe dense et convient bien aux recherches par lots. En revanche, il exige un entraînement représentatif : une dérive des données ou des requêtes rend les centroïdes moins pertinents. Le paramètre nprobe règle le nombre de partitions explorées, donc le couple latence-rappel.

La compression par quantification de produit, souvent notée PQ (Product Quantization), remplace des composantes numériques par des codes courts. Elle réduit fortement la mémoire et améliore la localisation sur disque, au prix d’une distance approximée. Associer IVF et PQ est cohérent lorsque le corpus ne tient plus confortablement en mémoire. L’associer sans reranking revient à demander à une photo compressée de servir de preuve médico-légale.

La position à retenir est nette : préférer HNSW pour la recherche interactive exigeant un rappel élevé et des mises à jour fréquentes ; préférer IVF avec compression lorsque le budget mémoire domine et que la recherche peut être rerankée ; conserver une recherche exacte sur un sous-ensemble filtré pour les requêtes sensibles. Le reranking recalculera alors une distance précise, ou utilisera un modèle plus coûteux, sur les meilleurs candidats retournés par l’index approximatif.

Qdrant, Milvus, pgvector et OpenSearch : choisir le moteur

Qdrant est le choix le plus direct pour un service de recherche sémantique dédié. Son index HNSW, les filtres de métadonnées intégrés, la persistance et les opérations de collection réduisent le nombre de briques à assembler. Il convient lorsque les vecteurs et leurs métadonnées constituent la charge principale. Son point de vigilance est le dimensionnement mémoire : un index HNSW mal calibré ne devient pas discret par la grâce d’un manifeste Kubernetes.

Milvus vise les charges plus massives et les stratégies d’index variées. Sa séparation entre calcul, stockage objet et journalisation peut absorber des besoins d’ingestion élevés, mais augmente les dépendances opérationnelles. Un stockage compatible S3 (Simple Storage Service), un moteur de métadonnées et des composants de coordination deviennent des éléments de reprise. Milvus se justifie lorsque l’élasticité et les index spécialisés compensent réellement cette complexité.

pgvector ajoute la recherche vectorielle à PostgreSQL. Il faut le choisir lorsque les données métier vivent déjà dans PostgreSQL, que les transactions entre métadonnées et vecteurs comptent davantage que la latence minimale, et que l’équipe sait exploiter PostgreSQL. Les index HNSW et IVFFlat y sont efficaces dans leur domaine, mais le moteur relationnel n’est pas magiquement transformé en usine à recherche vectorielle. Les écritures, les index et les sauvegardes se disputent les mêmes ressources.

OpenSearch est recevable lorsque la recherche textuelle classique, les agrégations et les filtres complexes sont déjà centraux. La recherche hybride, combinant texte et vecteurs, y est un vrai avantage. En contrepartie, l’indexation vectorielle partage le cluster avec des mécanismes coûteux de recherche documentaire. Isoler les charges reste préférable : un tableau de bord bavard ne doit pas pouvoir dégrader la recherche applicative.

Le choix dépend donc de la question suivante : le vecteur est-il un attribut d’une donnée transactionnelle ou le cœur du service de recherche ? Dans le premier cas, pgvector limite la duplication et simplifie la cohérence. Dans le second, Qdrant est le défaut raisonnable. Milvus ne doit apparaître qu’après avoir démontré que ses capacités d’échelle et d’index compensent son coût d’exploitation. OpenSearch est un moteur hybride, pas une base vectorielle déguisée en licorne.

Mesurer la latence, le rappel et l’ingestion

Une mesure crédible sépare latence médiane, percentile 95 et percentile 99. Le percentile 99 indique la latence sous laquelle passent 99 % des requêtes. Une médiane flatteuse masque très bien les pauses de compactage, les défauts de cache et les recherches filtrées. C’est une tradition ancienne de l’informatique : mesurer ce qui rassure, puis découvrir ce qui brûle.

Le benchmark doit utiliser les mêmes vecteurs, les mêmes filtres, la même distance et les mêmes paramètres de rappel sur chaque moteur. Les distances cosinus, produit scalaire et euclidienne ne sont pas interchangeables sans normalisation cohérente des vecteurs. Un modèle produisant des vecteurs normalisés doit être interrogé avec la métrique attendue par ce modèle, sinon le comparatif évalue surtout une erreur de configuration.

Mesurer au minimum :

• le rappel à k, en comparant les résultats ANN à une recherche exacte ;
• la latence par requête avec cache froid puis chaud ;
• le débit d’ingestion avec indexation activée ;
• l’empreinte mémoire après construction de l’index ;
• la durée et l’impact des suppressions, mises à jour et compactions ;
• la latence avec les filtres réellement utilisés, notamment les filtres d’autorisation.

Les filtres sont souvent le point de rupture. Un filtre sélectif appliqué avant la recherche réduit l’espace utile. Un filtre appliqué après recherche peut retourner moins de k résultats ou, pire, exposer des candidats non autorisés dans une trace, un cache ou un journal applicatif. L’autorisation doit donc être exprimée dans le filtre natif du moteur, testée sous charge et associée à des index de métadonnées.

Exemple reproductible avec Qdrant et mesure de rappel

L’exemple suivant démarre Qdrant, crée une collection avec vecteurs de dimension 384 et active un index HNSW. La dimension doit correspondre exactement au modèle d’embeddings choisi, sinon l’insertion échoue. C’est une protection bienvenue : mieux vaut un refus immédiat qu’une pertinence transformée en bouillie statistique.

# Démarrer Qdrant localement avec un volume persistant.
docker run --rm -p 6333:6333 \
  -v "$PWD/qdrant-storage:/qdrant/storage" \
  qdrant/qdrant:latest

# Créer une collection pour des vecteurs normalisés de dimension 384.
# La distance COSINE est cohérente avec ce type de vecteurs.
curl -X PUT "http://localhost:6333/collections/documents" \
  -H "Content-Type: application/json" \
  -d '{
    "vectors": {
      "size": 384,
      "distance": "Cosine",
      "hnsw_config": {
        "m": 16,
        "ef_construct": 128
      }
    }
  }'

# Interroger avec ef=128 pour privilégier le rappel.
# Tester ensuite plusieurs valeurs ef afin de tracer rappel contre latence.
curl -X POST "http://localhost:6333/collections/documents/points/search" \
  -H "Content-Type: application/json" \
  -d '{
    "vector": [0.01, 0.02, 0.03],
    "limit": 10,
    "params": { "hnsw_ef": 128 }
  }'

La commande de recherche exige un vecteur de 384 valeurs, le fragment est volontairement raccourci pour la lisibilité. Le jeu de test doit contenir des requêtes annotées ou une référence exacte calculée hors ligne. Sans vérité de terrain, un benchmark de rappel ne mesure rien. Il chronomètre seulement une machine qui fait des choses très vite, ce qui est le cœur de nombreuses démos.

Surface d’attaque, secrets et reprise

Une base vectorielle ne garantit ni la confidentialité des documents sources ni la pertinence des résultats. Un vecteur peut révéler des relations sémantiques et les métadonnées contiennent fréquemment identifiants, classifications ou droits. Chiffrer le disque protège le support perdu, pas un compte de service compromis.

Les vecteurs empoisonnés constituent une attaque réaliste : injecter des contenus conçus pour apparaître dans des requêtes ciblées permet d’influencer une réponse générée. La contre-mesure est une chaîne d’ingestion authentifiée, avec provenance, validation de format, journal d’audit et séparation entre corpus de confiance. Les documents récupérés ne doivent jamais devenir des instructions exécutables sans politique explicite. Le terme « agentique » n’a jamais transformé un texte hostile en texte inoffensif.

Exposer l’interface d’administration sur le même chemin que l’interface de recherche est une faute classique. Séparer les identités de lecture, d’écriture et d’administration ; imposer TLS (Transport Layer Security) ; limiter le réseau ; journaliser les opérations de collection et les modifications de schéma. Les jetons d’accès doivent être stockés dans un gestionnaire de secrets, avec rotation testée. Une rotation non testée est une date de panne avec un nom optimiste.

Les sauvegardes doivent inclure vecteurs, métadonnées, configuration d’index et version du modèle d’embeddings. Restaurer les vecteurs avec un modèle différent crée une incohérence silencieuse. La reprise doit donc vérifier la dimension, la métrique, le modèle, les droits et le nombre de points avant de rouvrir le service. Les principes de cloisonnement réseau détaillés dans l’architecture cyber s’appliquent ici sans exception : un moteur de recherche reste une base de données, même lorsqu’il porte un pull de machine learning.

🐝 Ce qui arrive si on s’en passe

Sans filtre d’autorisation natif appliqué avant la recherche, le moteur se comporte en oracle : le nombre de résultats renvoyés, inférieur à k lorsque des candidats interdits ont été écartés après coup, et la latence de la requête varient selon la présence de documents confidentiels proches du vecteur soumis. En multipliant des requêtes formulées autour d’un sujet sensible, un compte autorisé en lecture peut ainsi déduire l’existence d’un contenu qu’il ne voit jamais, sans qu’aucun journal d’accès ne signale de consultation interdite. Sans référence de rappel calculée par recherche exacte, la dérive des centroïdes IVF ou un changement de modèle dégrade la pertinence sans produire d’erreur ni d’alerte : les réponses manquantes restent invisibles, et aucune mesure antérieure ne permet de dater le début de la régression.

🦫 Explication de la marmotte 🍫

Une recherche sémantique commence par transformer chaque document en une longue liste de nombres. Cette liste représente le sens général du texte selon un modèle entraîné auparavant. La question posée est transformée de la même manière. Le système cherche alors les listes de nombres les plus proches de celle de la question.

Comparer la question avec tous les documents donne les meilleurs résultats, mais devient lent lorsque la collection grandit. Les bases vectorielles utilisent donc souvent un index, c’est-à-dire une organisation préparée à l’avance pour ne regarder qu’une partie des documents. Cette méthode accélère la recherche, mais peut manquer un bon résultat. Les réglages déterminent combien de temps est consacré à chercher et combien de résultats corrects sont retrouvés.

Certains moteurs gardent les vecteurs près des données métier existantes. D’autres sont spécialisés dans cette recherche et utilisent davantage de mémoire pour répondre vite. Il faut aussi vérifier les droits d’accès pendant la recherche, pas seulement après, afin qu’un document interdit ne soit jamais proposé.

Quand des documents sont ajoutés, modifiés ou supprimés, l’index doit suivre. Les sauvegardes doivent conserver les vecteurs, les informations associées et le modèle qui les a produits. Si le modèle change, les anciens vecteurs peuvent ne plus être comparables aux nouveaux. Enfin, une base vectorielle ne décide pas si une information est vraie, sûre ou autorisée : ces contrôles doivent être ajoutés autour d’elle.

À lire aussi

• Sécuriser un corpus RAG contre l’injection indirecteCette fiche décrit comment empêcher qu’un document empoisonné dans un corpus RAG détourne un modèle de langage lors de la génération.
• Contrôler les accès d’un assistant IA interneMettre en œuvre la gouvernance des identités et le filtrage des accès dans un assistant IA interne utilisant un corpus documentaire.
• Fenêtre de contexte et mémoire d’un LLM localChoisir, dimensionner et exploiter la fenêtre de contexte d’un LLM local sans sacrifier inutilement la performance, la sécurité ou la continuité des conversations.
• Fine-tuning local ou RAG pour données internesComparer le fine-tuning local et le RAG pour exploiter des données internes sans augmenter inutilement le risque de fuite.

Pages voisines

Comparer les bases vectorielles à grande échelle

Elle cite

• ⇄Lien dans les deux sens :Déployer Qdrant local pour recherche sémantique interne
• ⇄Lien dans les deux sens :Embeddings : vecteurs, recherche sémantique et RAG
• ⇄Lien dans les deux sens :Quand la recherche sémantique contourne les droits
• Installer et sécuriser PostgreSQL auto-hébergé sur Debian

⇄ : les deux pages se citent l’une l’autre.