La base de données Actian VectorAI prend désormais en charge l'indexation IVF et la quantification vectorielle

#IA #Bases de données #LLM #RAG #VectorAI DB

Points clés à retenir

La base de données Actian VectorAI prend désormais en charge l'indexation IVF et la quantification vectorielle, en plus de l'algorithme HNSW, pour offrir davantage de souplesse dans les compromis entre mémoire, taux de rappel et latence.
La méthode IVF réduit la taille de l'index et le coût de mise à jour grâce au regroupement des vecteurs, tandis que la quantification des produits et des scalaires permet de réduire encore davantage l'espace de stockage des vecteurs.
HNSW reste le meilleur choix lorsque l'on privilégie avant tout un taux de rappel élevé avec une faible latence et que la mémoire ne constitue pas une contrainte.
L'IVF est mieux adaptée aux déploiements soumis à des contraintes de mémoire, fréquemment mis à jour, basés sur disque et en périphérie, où un index de graphe peut ne pas convenir.
VectorAI DB prend en charge l'IVF et la quantification dans les environnements cloud, sur site, en périphérie et isolés physiquement, afin que les équipes puissent optimiser adapter l'indexation à chaque charge de travail.

La base de données Actian VectorAI prend déjà en charge l'indexation HNSW (hierarchical navigable small world), qui reste le choix par défaut idéal lorsque le taux de rappel avec une faible latence est primordial et que la mémoire ne constitue pas une contrainte.

Mais c'est souvent le cas avec la mémoire. C'est pourquoi la base de données Actian VectorAI DB prend désormais en charge l’indexation par fichiers inversés (IVF) et la quantification vectorielle en plus de HNSW, ce qui aide les utilisateurs à contourner les contraintes de mémoire. Vous choisissez le profil de mémoire, de récupération et de latence adapté à chaque cible d’ déploiement , plutôt que d’utiliser un profil unique partout.

L’IVF réduit la taille de l’index et rend les mises à jour moins coûteuses, tandis que la quantification compresse davantage chaque vecteur ; ensemble, ces techniques permettent d’adapter la recherche vectorielle en production à du matériel sur lequel un index de graphes ne fonctionnerait pas. Qu’il s’agisse d’un index de recherche sémantique sur un appareil mobile ou une passerelle industrielle, d’un catalogue de commerce électronique qui évolue fréquemment, ou encore d’une collection dont la taille a dépassé le budget mémoire alloué : vous choisissez le profil de mémoire, de récupération et de latence en fonction de chaque cible d’ déploiement , au lieu d’appliquer un profil unique partout.

Pourquoi la FIV et la quantification des produits, prises ensemble, ont plus d'importance que chacune d'entre elles prise séparément

La quantification détermine l'espace occupé par chaque vecteur. L'IVF détermine la partie de l'index qu'une « requête » doit parcourir et la partie qui doit être reconstruite lorsque les données changent. Utilisées conjointement, ces deux techniques permettent de gérer à la fois l'empreinte mémoire et le calcul par «requête » au sein d'un même moteur.

Cette combinaison modifie les cas d'utilisation envisageables :

Déploiements avec des contraintes de mémoire et en périphérie: C'est grâce à un index plus petit par vecteur que la recherche sémantique ou la génération augmentée par la recherche peuvent fonctionner sur un appareil mobile, une passerelle industrielle ou un capteur IoT disposant d'une mémoire limitée. Un index de graphe de la même collection pourrait ne pas tenir du tout sur l'appareil.

Données nécessitant de nombreuses écritures et fréquemment mises à jour: La reconstruction ou la mise à jour partielle des affectations de clusters est moins coûteuse que celle d’un graphe. Les catalogues de commerce en ligne, caractérisés par une rotation constante des stocks et une détection d’ anomalie s à haut volume, constituent deux ex avantage s de ce cas de figure.

Coût de l'infrastructure à grande échelle : Un indice plus faible pour une même in jeu de données tion implique un nombre de nœuds plus restreint ou des nœuds plus petits. Lorsque l'on atteint des centaines de millions de vecteurs, la mémoire nécessaire par vecteur devient une question liée au nombre de nœuds et, par conséquent, une question de budget.

Choisir entre la HNSW et la FIV

Fonctionnalité	HNSW	FIV
Rappel à faible latence	Plus élevé	Plus faible pour une latence identique
Taille de l'index	Agrandir (graphique et vecteurs)	Plus petit (vecteurs et affectations de clusters)
Durée de compilation	Plus long	Plus court
Coût de la mise à jour et de la suppression	Reconstruction du graphe, opération très gourmande en ressources de calcul	Moins coûteux en termes de calcul de reconstruire ou de mettre à jour partiellement
Au-delà de la mémoire	Doit tenir dans la mémoire	Performances constantes sur les systèmes de stockage sur disque

Privilégiez HNSW lorsque la priorité est donnée à la récupération à faible latence et que la mémoire ne constitue pas une contrainte. Optez pour IVF lorsque l'index doit occuper moins d'espace, lorsque les données changent constamment ou lorsque le volume de données dépasse la capacité de la mémoire.

Quel que soit votre choix, évaluez-le à l’aide de vos propres données. Une base de données vectorielle ne peut pas fournir de taux de rappel de manière autonome, car elle n’a aucun moyen de connaître les résultats corrects pour une requête requête. Vous avez besoin de données de référence, c’est-à-dire d’un ensemble de test de requêtes dont les réponses correctes sont connues, ainsi que d’un score de rappel calculé en faisant la moyenne sur des centaines d’entre elles. Les benchmarks du secteur constituent un point de départ raisonnable pour la comparaison, mais seuls vos propres modèles d’ requête s vous permettront de déterminer les performances d’un système pour votre charge de travail.

Indexation existante dans la base de données VectorAI

Jusqu'à cette version d'octobre 2026, VectorAI DB ne proposait que le modèle HNSW. HNSW est un graphe multicouche dans lequel chaque vecteur est un nœud connecté à ses voisins immédiats. Les recherches commencent par de grands sauts à travers une couche supérieure clairsemée, puis s'affinent vers le bas jusqu'à ce qu'il ne reste plus qu'un petit nombre de candidats à comparer. Cela permet d'obtenir un taux de rappel élevé avec une faible latence, ce qui est indispensable pour les systèmes de recommandation, la génération augmentée par la recherche sur un ensemble de documents et la recherche sémantique dans un catalogue.

La surcharge liée à l'indexation HNSW réside dans le graphe lui-même. HNSW stocke les connexions en plus des vecteurs bruts ; l'index est donc nettement plus volumineux que les vecteurs seuls. La création de ces connexions prend également beaucoup de temps.

Dans les bases de données vectorielles gérées dans le cloud, le service prend en charge cette surcharge mémoire. En revanche, pour l’ sur site e ou en périphérie, il n’y a pas d’élasticité permettant de l’absorber. Cette surcharge devient alors une contrainte.

Qu'est-ce que la FIV ?

L'IVF regroupe les vecteurs en grappes au lieu de construire un graphe. Chaque grappe possède un « centroïde », c'est-à-dire un point synthétique situé à la position moyenne des vecteurs qui lui sont attribués. Chaque vecteur est attribué à la grappe dont le centroïde est le plus proche.

La recherche se déroule en deux étapes. Dans un premier temps, l’ requête e est comparé aux centroïdes, ce qui permet d’identifier les clusters les plus prometteurs. Cette étape est peu coûteuse, car le nombre de clusters est bien inférieur à celui des vecteurs. L’ requête e effectue ensuite une recherche au sein d’un sous-ensemble de ces clusters. La taille de ce sous-ensemble est configurable : elle est contrôlée par un paramètre. Des valeurs faibles, correspondant à un sous-ensemble plus restreint, permettent d’obtenir des résultats plus rapidement, tandis que la recherche dans un sous-ensemble plus large augmente le taux de rappel au détriment de la latence.

Trois propriétés découlent de cette structure :

L'index est plus petit, car il contient des vecteurs et des affectations de clusters plutôt qu'un graphe.
La précision (recall) est réglable au moment de l'requête , ce qui vous permet de l'ajuster en fonction d'un objectif de latence spécifique sans avoir à reconstruire quoi que ce soit.
La structure du cluster conserve ses performances par rapport à un stockage sur disque ; l'index n'est donc pas limité par la mémoire disponible.

Le compromis réside dans l'effort de réglage. Pour égaler le taux de rappel de HNSW, IVF doit analyser davantage de grappes, ce qui augmente la latence. Les modifications des paramètres d'IVF ont également une incidence sur le taux de rappel ; leur réglage nécessite donc des tests plus minutieux que les paramètres par défaut de HNSW.

Qu'est-ce que la quantification vectorielle ?

La quantification réduit chaque vecteur à une représentation plus compacte, en sacrifiant une partie de la précision numérique au profit d'un encombrement moindre des données. Un vecteur en pleine précision stocke chaque dimension dans toute sa largeur. Un vecteur quantifié en donne une approximation qui ne nécessite qu'une fraction de l'espace.

VectorAI DB prend en charge trois variantes de FIV :

Format plat : Vecteurs non compressés regroupés en grappes, sans quantification appliquée. Cette approche offre la plus grande précision, mais occupe également tout l'espace mémoire nécessaire aux vecteurs.
Quantification des produits : Chaque vecteur est divisé en sous-vecteurs et codé à l'aide d'un livre de codes appris, ce qui permet d'obtenir la plus grande réduction d'encombrement possible
Quantification scalaire : La précision de chaque dimension est réduite, ce qui permet généralement de conserver davantage de précision, mais offre une réduction de la mémoire moindre que la quantification par produit.

La quantification résout directement le problème posé par un « index trop volumineux pour tenir en mémoire » en privilégiant la vitesse de consultation au détriment de la taille de l'index. Vous déterminez vous-même ce compromis en choisissant le niveau de compression qui répond aux exigences de précision de votre cas d'usage.

Réalisez une FIV partout où vous pouvez installer un conteneur

Le choix de l'index est un élément essentiel pour une base de données vectorielle. C'est par la diversité des contextes dans lesquels cet index peut fonctionner que VectorAI DB se distingue.

Les secteurs réglementés, les obligations souveraines en matière d'IA, les sites isolés et les applications embarquées sensibles en matière de confidentialité nécessitent tous une recherche vectorielle au sein d'un périmètre qu'ils contrôlent. Un index moins volumineux permet d'augmenter la quantité d'charge de travail s pouvant y être conservée. C'est particulièrement important lorsque l'inférence locale est nécessaire.

VectorAI DB est une base de données vectorielle privilégiant le fonctionnement local. Elle se déploie sous forme de conteneur portable ou de runtime « Embarqué » en périphérie, sans service cloud en arrière-plan et sans que les données ne quittent votre environnement. Le même moteur peut fonctionner sur un nœud cloud, un serveur sur site, une passerelle industrielle ou au sein d’une installation isolée physiquement (air-gapped). Grâce à l’IVF et à la quantification, VectorAI DB rend ces cibles plus modestes viables, en réduisant l’empreinte de l’index à un niveau adapté au matériel.

Dans d'autres solutions, le déploiement en local implique généralement de accepter un débit moindre. Mais VectorAI DB réduit ce compromis au minimum : selon les tests de performance, il est 22 fois plus rapide que le moteur open source le plus courant.

Essayez les méthodes IVF et de quantification sur vos propres données

Téléchargez Actian VectorAI DB Community Edition et créez gratuitement un index IVF. Pour les utilisateurs actuels de VectorAI DB, il n’y a aucune nouvelle dépendance ni aucune configuration à effectuer. Réalisez votre propre comparaison de rappel et de latence par rapport à HNSW, puis contactez Actian pour discuter d’un contrat de production lorsque vous serez prêt.