Je pense depuis longtemps que toutes les solutions vectorielles ne devraient pas être collectivement appelées bases de données vectorielles, même si leurs capacités peuvent les rivaliser à certains égards. De mon point de vue, comme pgvector ou Elasticsearch, ce sont des produits à la fois excellents et matures qui peuvent en effet bien répondre aux besoins des utilisateurs dans des scénarios spécifiques.
Lorsque la quantité de données est faible, l’utilisation d’Elasticsearch combinée à la récupération scalaire suffit à répondre aux scénarios métiers. Alternativement, si vos données originales sont entièrement stockées dans une base de données relationnelle, il est alors tout à fait possible de rechercher des centaines de milliers, voire 1 million de données sur la base d'opérations pgvector. Mais à mesure que la quantité de données augmente, vous constaterez que de nombreux scénarios commerciaux seront limités par la conception de bases de données traditionnelles et ne pourront pas évoluer correctement.
En fait, lorsque l’on discute des capacités qu’offre une base de données vectorielle, je pense qu’il y a plusieurs points clés qui ne peuvent être évités, notamment les algorithmes, la puissance de calcul et la planification. En tant que base de données vectorielle, ces aspects nécessitent une conception spéciale.
Un exemple que je continue de mentionner est que si vous souhaitez simplement effectuer la récupération du voisin le plus proche, vous pouvez écrire un ANN, et cela ne prendra que moins de 10 lignes de code pour obtenir la fonction de récupération du voisin le plus proche dont vous avez besoin. Mais la raison pour laquelle tout le monde choisit de ne pas le faire est en grande partie due à des facteurs de performance et de coût. De ce point de vue, une fois que les performances, le coût et l’évolutivité sont essentiels pour vous, de nombreuses bases de données traditionnelles risquent de ne pas être en mesure de répondre à vos besoins.