Publié le 22 septembre 2026 à 11:00 · Publication originale
Une question arrive.
Pour trouver les passages les plus proches, le système pourrait comparer le vecteur de la question aux dix millions de vecteurs.
Le résultat serait précis.
Mais effectuer cette recherche exhaustive à chaque requête devient coûteux.
Les bases vectorielles utilisent donc des index de recherche approximative.
L'un des plus répandus s'appelle HNSW, pour "Hierarchical Navigable Small World".
Il transforme les vecteurs en graphe.
Chaque point possède des voisins. Au-dessus apparaissent des couches plus clairsemées contenant des connexions permettant de parcourir rapidement de grandes distances.
La recherche commence dans ces couches supérieures, effectue de grands sauts vers une région prometteuse puis descend vers des couches plus denses pour affiner le résultat.
Elle ne visite donc pas nécessairement tous les candidats.
Cette propriété explique un détail important: accélérer la recherche peut diminuer le rappel, c'est-à-dire la proportion des véritables voisins les plus proches effectivement retrouvés.
Le compromis devient plus subtil lorsqu'un filtre intervient.
Chercher les documents sémantiquement proches ne suffit pas si l'utilisateur ne peut consulter que ceux de son département, d'une période donnée ou d'un niveau de confidentialité précis.
Selon l'architecture, le moteur peut parcourir des voisins très pertinents puis découvrir qu'une partie d'entre eux ne satisfait pas le filtre.
pgvector permet alors d'étendre progressivement le parcours de l'index jusqu'à obtenir suffisamment de résultats admissibles.
Qdrant utilise une variante de HNSW permettant d'intégrer les contraintes de filtrage pendant le parcours.
Une recherche vectorielle n'est donc pas simplement "trouver ce qui ressemble le plus".
En production, elle arbitre entre proximité, vitesse, mémoire, filtres et probabilité de retrouver les bons documents.
ULTRA®
HNSW possède un réglage particulièrement révélateur: "ef_search".
Il contrôle approximativement la taille de la liste de candidats explorée pendant une recherche. L'augmenter améliore généralement le rappel, mais augmente aussi latence et travail effectué.
pgvector montre un piège plus rare. Avec un filtre sélectionnant 10% des données et un "ef_search" de 40, environ quatre résultats seulement peuvent en moyenne survivre au filtrage. Ses scans itératifs peuvent poursuivre automatiquement l'exploration du graphe.
Conseil: mesurer recall\@k sur plusieurs centaines de requêtes réelles avec leurs vrais filtres, pas seulement sur une recherche vectorielle sans contraintes.
Deux utilisateurs interrogeant les mêmes vecteurs avec des permissions différentes peuvent ainsi obtenir des performances de récupération différentes.
L'autorisation peut modifier non seulement ce qu'un utilisateur a le droit de voir, mais la qualité même de ce que le moteur parvient à retrouver.