Accélérer la recherche de similarité sur de très grandes données avec l’indexation vectorielle
De la vision par ordinateur à la découverte de nouveaux médicaments, les moteurs de recherche par similarité vectorielle alimentent de nombreuses applications populaires d’intelligence artificielle (IA). Un composant essentiel de ce qui permet d’interroger efficacement les jeux de données de millions, de milliards, voire de billions de vecteurs sur lesquels reposent les moteurs de recherche par similarité est l’indexation, un processus d’organisation des données qui accélère considérablement la recherche dans le big data. Cet article couvre le rôle que joue l’indexation dans l’efficacité de la recherche par similarité vectorielle, les différents types d’index de fichiers inversés vectoriels (IVF), ainsi que des conseils sur l’index à utiliser dans différents scénarios.
Aller à :
- Comment l’indexation vectorielle accélère-t-elle la recherche par similarité et l’apprentissage automatique ?
- Quels sont les différents types d’index IVF et à quels scénarios conviennent-ils le mieux ?
- FLAT : adapté à la recherche dans des jeux de données relativement petits (à l’échelle du million) lorsque 100 % de rappel est requis.
- IVF_FLAT : améliore la vitesse au détriment de la précision (et vice versa).
- IVF_SQ8 : plus rapide et moins gourmand en ressources qu’IVF_FLAT, mais aussi moins précis.
- IVF_SQ8H : nouvelle approche hybride GPU/CPU encore plus rapide qu’IVF_SQ8.
- En savoir plus sur Milvus, une plateforme de gestion de données vectorielles à très grande échelle.
Comment l’indexation vectorielle accélère-t-elle la recherche par similarité et l’apprentissage automatique ?
Les moteurs de recherche par similarité fonctionnent en comparant une entrée à une base de données afin de trouver les objets les plus similaires à cette entrée. L’indexation est le processus d’organisation efficace des données, et elle joue un rôle majeur pour rendre la recherche par similarité utile en accélérant considérablement les requêtes chronophages sur de grands jeux de données. Une fois qu’un immense jeu de données vectorielles est indexé, les requêtes peuvent être acheminées vers des clusters, ou sous-ensembles de données, qui sont les plus susceptibles de contenir des vecteurs similaires à une requête d’entrée. En pratique, cela signifie qu’un certain degré de précision est sacrifié pour accélérer les requêtes sur de très grandes données vectorielles.
On peut établir une analogie avec un dictionnaire, où les mots sont classés par ordre alphabétique. Lorsqu’on recherche un mot, il est possible de naviguer rapidement vers une section qui ne contient que des mots ayant la même initiale — ce qui accélère considérablement la recherche de la définition du mot saisi.
Quels sont les différents types d’index IVF et à quels scénarios conviennent-ils le mieux ?
Il existe de nombreux index conçus pour la recherche par similarité vectorielle en haute dimension, et chacun implique des compromis en matière de performances, de précision et d’exigences de stockage. Cet article couvre plusieurs types d’index IVF courants, leurs forces et leurs faiblesses, ainsi que les résultats des tests de performance pour chaque type d’index. Les tests de performance quantifient le temps de requête et les taux de rappel pour chaque type d’index dans Milvus, une plateforme open source de gestion de données vectorielles. Pour plus d’informations sur l’environnement de test, consultez la section méthodologie en bas de cet article.
FLAT : adapté à la recherche dans des jeux de données relativement petits (à l’échelle du million) lorsque 100 % de rappel est requis.
Pour les applications de recherche par similarité vectorielle qui nécessitent une précision parfaite et dépendent de jeux de données relativement petits (à l’échelle du million), l’index FLAT est un bon choix. FLAT ne compresse pas les vecteurs et est le seul index capable de garantir des résultats de recherche exacts. Les résultats de FLAT peuvent également être utilisés comme point de comparaison pour les résultats produits par d’autres index qui ont un rappel inférieur à 100 %.
FLAT est précis parce qu’il adopte une approche exhaustive de la recherche, ce qui signifie que, pour chaque requête, l’entrée cible est comparée à chaque vecteur d’un jeu de données. Cela fait de FLAT l’index le plus lent de notre liste, et il est mal adapté à l’interrogation de données vectorielles massives. Il n’y a aucun paramètre pour l’index FLAT dans Milvus, et son utilisation ne nécessite ni entraînement des données ni stockage supplémentaire.
Résultats des tests de performance de FLAT :
Les tests de performance du temps de requête de FLAT ont été réalisés dans Milvus à l’aide d’un jeu de données composé de 2 millions de vecteurs à 128 dimensions.
Résultats des tests de temps de requête pour l’index FLAT dans Milvus.
Points clés à retenir :
- À mesure que nq (le nombre de vecteurs cibles pour une requête) augmente, le temps de requête augmente.
- En utilisant l’index FLAT dans Milvus, nous pouvons constater que le temps de requête augmente fortement dès que nq dépasse 200.
- En général, l’index FLAT est plus rapide et plus cohérent lorsque Milvus s’exécute sur GPU plutôt que sur CPU. Cependant, les requêtes FLAT sur CPU sont plus rapides lorsque nq est inférieur à 20.
IVF_FLAT : améliore la vitesse au détriment de la précision (et inversement).
Une méthode courante pour accélérer le processus de recherche de similarité au détriment de la précision consiste à effectuer une recherche approximative des plus proches voisins (ANN). Les algorithmes ANN réduisent les besoins en stockage et la charge de calcul en regroupant les vecteurs similaires, ce qui permet une recherche vectorielle plus rapide. IVF_FLAT est le type d’index de fichier inversé le plus élémentaire et s’appuie sur une forme de recherche ANN.
IVF_FLAT divise les données vectorielles en un certain nombre d’unités de clusters (nlist), puis compare les distances entre le vecteur d’entrée cible et le centre de chaque cluster. En fonction du nombre de clusters que le système est configuré pour interroger (nprobe), les résultats de recherche de similarité sont renvoyés uniquement sur la base des comparaisons entre l’entrée cible et les vecteurs du ou des clusters les plus similaires — ce qui réduit drastiquement le temps de requête.
En ajustant nprobe, il est possible de trouver un équilibre idéal entre précision et vitesse pour un scénario donné. Les résultats de notre test de performance IVF_FLAT démontrent que le temps de requête augmente fortement à mesure que le nombre de vecteurs d’entrée cibles (nq) et le nombre de clusters à rechercher (nprobe) augmentent. IVF_FLAT ne compresse toutefois pas les données vectorielles ; les fichiers d’index incluent des métadonnées qui augmentent légèrement les besoins en stockage par rapport au jeu de données vectorielles brut non indexé.
Résultats des tests de performance de IVF_FLAT :
Les tests de performance du temps de requête de IVF_FLAT ont été réalisés dans Milvus à l’aide du jeu de données public 1B SIFT, qui contient 1 milliard de vecteurs à 128 dimensions.
Résultats des tests de temps de requête pour l’index IVF_FLAT dans Milvus.
Points clés à retenir :
- Lors de l’exécution sur CPU, le temps de requête pour l’index IVF_FLAT dans Milvus augmente avec nprobe et nq. Cela signifie que plus une requête contient de vecteurs d’entrée, ou plus une requête recherche de clusters, plus le temps de requête sera long.
- Sur GPU, l’index présente une variance temporelle moindre face aux changements de nq et de nprobe. Cela s’explique par le fait que les données d’index sont volumineuses et que la copie des données de la mémoire CPU vers la mémoire GPU représente la majeure partie du temps total de requête.
- Dans tous les scénarios, sauf lorsque nq = 1 000 et nprobe = 32, l’index IVF_FLAT est plus efficace lorsqu’il s’exécute sur CPU.
Les tests de performance du rappel de IVF_FLAT ont été réalisés dans Milvus en utilisant à la fois le jeu de données public 1M SIFT, qui contient 1 million de vecteurs à 128 dimensions, et le jeu de données glove-200-angular, qui contient plus de 1 million de vecteurs à 200 dimensions, pour la construction de l’index (nlist = 16 384).
Résultats des tests du taux de rappel pour l’index IVF_FLAT dans Milvus.
Points clés à retenir :
- L’index IVF_FLAT peut être optimisé pour la précision, atteignant un taux de rappel supérieur à 0,99 sur le jeu de données 1M SIFT lorsque nprobe = 256.
IVF_SQ8 : plus rapide et moins gourmand en ressources qu’IVF_FLAT, mais aussi moins précis.
IVF_FLAT n’effectue aucune compression, les fichiers d’index qu’il produit ont donc à peu près la même taille que les données vectorielles brutes originales non indexées. Par exemple, si le jeu de données SIFT 1B original fait 476 Go, ses fichiers d’index IVF_FLAT seront légèrement plus volumineux (~470 Go). Charger tous les fichiers d’index en mémoire consommera 470 Go de stockage.
Lorsque les ressources disque, CPU ou mémoire GPU sont limitées, IVF_SQ8 est une meilleure option qu’IVF_FLAT. Ce type d’index peut convertir chaque FLOAT (4 octets) en UINT8 (1 octet) en effectuant une quantification scalaire. Cela réduit la consommation de disque, de CPU et de mémoire GPU de 70 à 75 %. Pour le jeu de données SIFT 1B, les fichiers d’index IVF_SQ8 ne nécessitent que 140 Go de stockage.
Résultats des tests de performance d’IVF_SQ8 :
Les tests du temps de requête d’IVF_SQ8 ont été menés dans Milvus à l’aide du jeu de données public SIFT 1B, qui contient 1 milliard de vecteurs à 128 dimensions, pour la construction de l’index.
Résultats des tests de temps de requête pour l’index IVF_SQ8 dans Milvus.
Points clés à retenir :
- En réduisant la taille des fichiers d’index, IVF_SQ8 offre des améliorations de performance marquées par rapport à IVF_FLAT. IVF_SQ8 suit une courbe de performance similaire à celle d’IVF_FLAT, le temps de requête augmentant avec nq et nprobe.
- Comme IVF_FLAT, IVF_SQ8 affiche des performances plus rapides lorsqu’il s’exécute sur CPU et lorsque nq et nprobe sont plus petits.
Les tests de performance du rappel d’IVF_SQ8 ont été menés dans Milvus à l’aide du jeu de données public SIFT 1M, qui contient 1 million de vecteurs à 128 dimensions, ainsi que du jeu de données glove-200-angular, qui contient plus de 1 million de vecteurs à 200 dimensions, pour la construction de l’index (nlist = 16 384).
Résultats des tests du taux de rappel pour l’index IVF_SQ8 dans Milvus.
Points clés à retenir :
- Malgré la compression des données originales, IVF_SQ8 ne subit pas de baisse significative de la précision des requêtes. Avec divers paramètres nprobe, IVF_SQ8 présente au maximum un taux de rappel inférieur de 1 % à celui d’IVF_FLAT.
IVF_SQ8H : nouvelle approche hybride GPU/CPU encore plus rapide qu’IVF_SQ8.
IVF_SQ8H est un nouveau type d’index qui améliore les performances de requête par rapport à IVF_SQ8. Lorsqu’un index IVF_SQ8 exécuté sur CPU est interrogé, la majeure partie du temps total de requête est consacrée à la recherche des clusters nprobe les plus proches du vecteur d’entrée cible. Pour réduire le temps de requête, IVF_SQ8 copie les données pour les opérations de quantificateur grossier, qui sont plus petites que les fichiers d’index, dans la mémoire GPU — ce qui accélère considérablement les opérations de quantificateur grossier. Ensuite, gpu_search_threshold détermine quel appareil exécute la requête. Lorsque nq >= gpu_search_threshold, le GPU exécute la requête ; sinon, le CPU exécute la requête.
IVF_SQ8H est un type d’index hybride qui nécessite que le CPU et le GPU fonctionnent ensemble. Il ne peut être utilisé qu’avec Milvus compatible GPU.
Résultats des tests de performance d’IVF_SQ8H :
Les tests de performance du temps de requête d’IVF_SQ8H ont été menés dans Milvus à l’aide du jeu de données public SIFT 1B, qui contient 1 milliard de vecteurs à 128 dimensions, pour la construction de l’index.
Résultats des tests de temps de requête pour l’index IVF_SQ8H dans Milvus.
Points clés à retenir :
- Lorsque nq est inférieur ou égal à 1 000, IVF_SQ8H affiche des temps de requête presque deux fois plus rapides qu’IVFSQ8.
- Lorsque nq = 2000, les temps de requête pour IVFSQ8H et IVF_SQ8 sont identiques. Cependant, si le paramètre gpu_search_threshold est inférieur à 2000, IVF_SQ8H surpassera IVF_SQ8.
- Le taux de rappel des requêtes d’IVF_SQ8H est identique à celui d’IVF_SQ8, ce qui signifie qu’un temps de requête plus faible est obtenu sans perte de précision de recherche.
En savoir plus sur Milvus, une plateforme de gestion de données vectorielles à très grande échelle.
Milvus est une plateforme de gestion de données vectorielles qui peut alimenter des applications de recherche de similarité dans des domaines allant de l’intelligence artificielle, au deep learning, aux calculs vectoriels traditionnels, et plus encore. Pour plus d’informations sur Milvus, consultez les ressources suivantes :
- Milvus est disponible sous une licence open-source sur GitHub.
- Des types d’index supplémentaires, notamment des index basés sur des graphes et des arbres, sont pris en charge dans Milvus. Pour une liste complète des types d’index pris en charge, consultez la documentation sur les index vectoriels dans Milvus.
- Pour en savoir plus sur l’entreprise qui a lancé Milvus, visitez Zilliz.com.
- Discutez avec la communauté Milvus ou obtenez de l’aide pour un problème sur Slack.
Méthodologie
Environnement de test des performances
La configuration du serveur utilisée pour les tests de performances mentionnés dans cet article est la suivante :
- Intel (R) Xeon (R) Platinum 8163 @ 2.50GHz, 24 cœurs
- GeForce GTX 2080Ti x 4
- 768 Go de mémoire
Concepts techniques pertinents
Bien que cela ne soit pas nécessaire pour comprendre cet article, voici quelques concepts techniques utiles pour interpréter les résultats de nos tests de performance des index :
Blog_Accelerating Similarity Search on Really Big Data with Vector Indexing_8.png
Ressources
Les sources suivantes ont été utilisées pour cet article :
- « Encyclopedia of database systems », Ling Liu et M. Tamer Özsu.
Et ensuite
Continuez à lire Accelerating Similarity Search on Really Big Data with Vector Indexing: Part II.
Continuer à lire
Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI
Vector Lakebase: a unified, lake-native data foundation for AI workloads — and an answer to what happens after vector databases succeed.
Zilliz Cloud Now Available in AWS Europe (Ireland)
Zilliz Cloud launches in AWS eu-west-1 (Ireland) — bringing low-latency vector search, EU data residency, and full GDPR-ready infrastructure to European AI teams. Now live across 30 regions on five cloud providers.
Milvus 2.6.x Now Generally Available on Zilliz Cloud, Making Vector Search Faster, Smarter, and More Cost-Efficient for Production AI
Milvus 2.6.x is now GA on Zilliz Cloud, delivering faster vector search, smarter hybrid queries, and lower costs for production RAG and AI applications.