Lorsque vous créez vos index, pensez aux vecteurs binaires.

Une forme de consensus s’est dessinée à ce sujet sur Hacker News, en réaction au retour d’expérience d’un ingénieur américain. L’intéressé y pointe les limites de pgvector… et suggère de lui préférer une base de données vectorielle.

À chaque index ses inconvénients

L’extension donne, rappelle-t-il, le choix entre deux types d’index : IVFFlat (Inverted File with Flat quantization) et HNSW (Hierarchical Navigable Small World). Le premier partitionne l’espace vectoriel en clusters. Le second construit un graphe.

Avec IVFFlat, la création d'index est plus rapide, en plus d'une consommation mémoire inférieure. Et les performances sont acceptables pour de nombreux cas d'usage.
Il est toutefois impératif de spécifier au préalable le nombre de clusters. Ce nombre a une nette influence sur la latence des requêtes. Comme sur la qualité du rappel, qui peut par ailleurs varier en fonction de la distribution des données.

Avec HNSW, le rappel est meilleur sur la plupart des datasets. La performances des requêtes est globalement plus consistante et le système passe bien à l'échelle.
La construction des index nécessite cependant beaucoup de mémoire et peut se révéler lente (plusieurs heures quand on atteint des millions de vecteurs).

Reconstructions et mises à jour

Avec IVFFlat, la clusterisation de nouveaux vecteurs se base sur la structure existante (distribution telle qu'elle était quand on a construit l'index). Avec le temps, il peut en résulter une sous-optimisation. D'où la nécessité de reconstruire régulièrement l'index. Et donc de tolérer une dégradation de la qualité de recherche voire une indisponibilité. Ou bien d'accepter de mettre en place un mécanisme de contournement, tels le provisionnement d'une grande quantité de RAM ou la mise en place d'un index séparé depuis lequel on réalise un échange atomique. S'y ajoute le besoin de gérer les insertions effectuées dans ce laps de temps.

Avec HNSW, chaque insertion exige de mettre à jour le graphe. Donc d'effectuer une traversée pour intégrer le nœud et actualiser les connexions, au risque d'engendrer des contentions de verrou si le taux d'écritures est suffisamment élevé.

Le dilemme du filtrage des recherches

Autre aspect à prendre en compte : les métadonnées, stockées dans d'autres tables ou tout du moins dans d'autres colonnes, et qu'il faut garder synchronisées. Pas si évident avec des reconstructions qui peuvent durer.

Quant aux filtres, faut-il les appliquer avant ou après la recherche vectorielle ? L'une et l'autre méthode ont leurs avantages... et leurs inconvénients.
L'option "avant" fonctionne bien lorsque le filtre est très sélectif. Elle assure une bonne qualité de rappel (k résultats garantis), mais la recherche peut s'avérer lente.
L'option "après" est au contraire adaptée aux filtres permissifs. Elle permet une recherche rapide, mais la qualité de rappel est variable (souvent 0 résultat ou en tout cas moins que k).

D'autres questions se posent si on souhaite appliquer plusieurs filtres. Dans quel ordre le faire ? Faut-il mélanger les deux options ?... PostgreSQL a bien un planificateur, mais pas optimal, son modèle de coût n'ayant pas été élaboré pour la recherche vectorielle. Les choses ne s'arrangent pas à mesure qu'on insère de nouveaux vecteurs, à moins d'enclencher un ANALYZE, qui coûte des ressources, sans pouvoir appréhender totalement la distribution des données.
On en arrive ainsi à devoir réécrire les requêtes pour différents types d'utilisateurs, partitionner les données dans des tables distinctes ou encore à filtrer dans le code de l'application quitte à récupérer plus de données que nécessaire.

L'option pgvectorscale

Les bases de données vectorielles ont résolu ces problèmes, affirme l'ingénieur : planification adaptée, recherche hybride native, indexation en temps réel sans pics de conso mémoire, scaling et monitoring spécifiques... Il mentionne OpenSearch, dont le plug-in k-NN permet de spécifier la stratégie de filtrage ; Pinecone, qui gère automatiquement la sélectivité des filtres ; Weaviate, qui embarque des optimisations pour les patterns de filtrage communs. Et d'appeler à mesurer le coût d'opportunité de pgvector ; en l'occurrence, le temps qu'on consacre à sa maintenance plutôt qu'à d'autres projets.

Il y a sinon, dans le domaine open source, pgvectorscale. Cette version "enrichie" de pgvector ajoute un nouveau type d'index basé sur l'algorithme DiskANN de Microsoft et plus efficace en mémoire. Elle apporte également une méthode de compression améliorée par rapport à la quantification binaire standard.
Il s'agit néanmoins d'une dépendance supplémentaire à gérer et elle n'est pas disponible, entre autres, pour RDS.

Discourse allie pgvector et vecteurs binaires

Le dilemme entre pré- et post-filtrage a été résolu dans la version 0.8.0 avec les scans itératifs, fait remarquer ingénieur chez Discourse. Son entreprise, affirme-t-il, utilise pgvector en production, sur des milliers de bases de données.

Un de ses pairs, travaillant pour un fournisseur de solutions cyber, s'en étonne : à une telle échelle, dans sa société, PostgreSQL a montré ses limites. Une base de données spécialisée (Vespa) lui a donc été préférée. Elle opère un map-reduce sur tous les nœuds de graphe, limitant le nombre de traversées à effectuer.

Si Discourse n'a pas ce souci, c'est parce que chaque forum a sa base de données. Il existe donc une sorte de "sharding gratuit", où chaque instance a en moyenne moins d'un million de topics.
L'entreprise utilise aussi beaucoup la quantification : avant indexation, elle convertir les vecteurs à virgule flottante en vecteurs binaires (chaque dimension est réduite à 1 bit). La majeure partie de leur utilisée est conservée, et la qualité de rappel avec.

Illustration générée par IA

The post Face aux bases de données vectorielles, pgvector atteint-il ses limites ? appeared first on Silicon.fr.