RAG : Avec AlloyDB, GCP est en quête du compromis entre vitesse et précision

AlloyDB, un poisson dans un banc de bases de données vectorielles

Les évolutions précédentes d’AlloyDB concernaient l’ajout du stockage vectoriel et des recherches par similarité, l’extension du langage de requête SQL pour combiner les données structurées et non structurées (représentées par des vecteurs). Les fonctionnalités d’AlloyDB s’appuient sur ces avancées.

En raison du rôle que joue désormais la recherche vectorielle dans le développement de l’IA générative, de nombreux fournisseurs de solutions de gestion de données ont ajouté des fonctionnalités similaires. Par exemple, la recherche vectorielle est intégrée à la dernière version en date de la base de données Oracle, est prise en charge par PostgreSQL ou encore SAP HANA, tout comme par les éditeurs de solutions NoSQL comme MongoDB ou Elastic.

Compte tenu de l’importance grandissante de la recherche vectorielle et du fait que les fonctionnalités que Google ajoute à AlloyDB améliorent ses capacités de recherche vectorielle dans la base de données, les annonces sont significatives pour les clients d’AlloyDB, selon David Menninger, analyste chez Ventana Research, une filiale d’ISG.

« La recherche vectorielle est au cœur des capacités RAG et est presque universelle dans les charges de travail d’IA générative », avance-t-il. « Ainsi, bien qu’elles ne soient pas révolutionnaires, les fonctionnalités sont certainement utiles pour l’un des types de charges de travail les plus populaires actuellement ».

Trois fonctionnalités « incrémentales », mais très utiles, selon les analystes

Voici plus en détail les fonctionnalités présentées cette semaine :

• Un filtrage en ligne pour l’index ScaNN d’AlloyDB – une recherche vectorielle par approximation du plus proche voisin (ANN) – afin d’améliorer les performances des recherches.
• Des outils d’observabilité et de gestion -- y compris un évaluateur de rappel pour surveiller le pourcentage de résultats pertinents lors de l’exécution d’une requête de recherche – qui visent à assurer la stabilité de la performance et de la qualité de la recherche.
• Des Statistiques de distribution de la recherche vectorielle pour l’index ScaNN afin de fournir aux utilisateurs un aperçu des changements dans les données en temps réel pour qu’ils puissent maintenir une performance stable de la recherche vectorielle.

Selon Tony Baer, directeur chez dbinsight, ces fonctionnalités « représentent une amélioration incrémentale importante axée sur l’optimisation et l’amélioration de la qualité des requêtes vectorielles ».

Les bases de données relationnelles traditionnelles ont connu une évolution similaire, selon l’analyste chez dbinsight.

« C’est l’histoire qui se répète », poursuit Tony Baer. « Lorsque les bases de données relationnelles sont apparues, l’étape suivante a été de réaliser que toutes les requêtes n’étaient pas identiques et que nous avions besoin de différentes manières de les optimiser. C’est l’objectif derrière le trio de fonctionnalités ».

Toutefois, deux d’entre elles sortiraient du lot.

« Le filtrage en ligne est un ajout important à la palette d’optimisation des requêtes vectorielles, tandis que l’évaluateur de rappel est une mesure critique et corrective de la fiabilité des requêtes », considère Tony Bear de dbinsight. « Ces deux fonctionnalités sont d’importance égale ».

Selon GCP, le filtrage en ligne permet d’appliquer des filtres à même la base de données « au lieu de le faire au post-traitement dans l’application ».

C’est une prolongation de l’effort autour de la simplification des commandes SQL pour combiner données structurées et vecteurs. Le filtrage en ligne est une technique d’optimisation permettant d’évaluer les métadonnées qui conditionnent à la fois les filtres et les recherches vectorielles en « s’appuyant sur les index vectoriels et les index sur les colonnes de métadonnées ».

 Google précise qu’AlloyDB automatise l’optimisation de l’exécution des requêtes en choisissant la meilleure stratégie selon la sélectivité des filtres. Toutefois, lorsque de nombreuses réponses sont possibles, ce qui implique un grand nombre de vecteurs, cette approche génère de la latence. Le filtrage en ligne, adapté aux cas de « sélectivité moyenne », accélère le traitement en ne calculant la distance qu’entre les vecteurs correspondant aux filtres sur les métadonnées.

Quant au rappel, il est important, car il permet de mesurer la qualité de recherche de vecteurs. Cet indicateur désigne la proportion de vecteurs pertinents – et donc des documents qu’ils représentent – parmi l’ensemble des vecteurs sélectionnés par l’opération de recherche. Cette mesure du recall est souvent effectuée avec d’autres outils, dont Weight & Bias pour n’en citer qu’un.

Au-delà de l’évolution des capacités de recherche vectorielle d’AlloyDB, ces fonctionnalités obligeront les concurrents des bases de données vectorielles à réagir, estime M. Baer.

« C’est le premier coup d’envoi de ce que nous devrions voir plus souvent cette année », estime-t-il. « Je considérais les optimisations de l’index vectoriel comme les prochaines étapes les plus probables de l’amélioration des magasins de données vectorielles, mais les améliorations d’AlloyDB en matière de filtrage et de rappel montrent qu’il existe de nombreuses approches possibles ». D’autres acteurs comme Qdrant se sont davantage intéressés à la manière d’accélérer l’indexation par GPU et d’éviter les filtrages non indexés.

David Menninger a également souligné l’intérêt du filtrage en ligne.

En privilégiant les recherches ANN qui identifient des points de données aux caractéristiques similaires, plutôt que des recherches exactes de voisins les plus proches, Google met l’accent sur la vitesse plutôt que la précision. Justement, selon l’analyste de Ventana Research, la rapidité est parfois préférable à la précision.

« L’index ScaNN offre une flexibilité qui n’existait pas auparavant », considère-t-il. « En contrepartie, les résultats ne trouveront peut-être pas tous les “plus proches voisins”, mais cela n’est peut-être pas aussi important que de fournir plus rapidement un ensemble raisonnable d’éléments similaires ».

Google Cloud doit favoriser la migration vers AlloyDB, selon Ventana Research

Maintenant que l’évaluation du rappel est disponible dans AlloyDB pour contrôler le pourcentage de résultats pertinents à partir d’une requête d’index ScaNN donnée, Google pourrait aller plus loin en ajoutant des outils qui mesurent la précision de différentes requêtes d’index vectoriel, selon Tony Baer.

« L’étape suivante logique consiste à créer différents types d’index adaptés à différents niveaux de rappel », note-t-il. « En effet, selon la nature de la tâche, toutes les requêtes vectorielles ne nécessitent pas le même niveau de recall ».

David Menninger, quant à lui, suggère que Google pourrait rendre AlloyDB plus attrayant pour les nouveaux clients potentiels en ajoutant de nouvelles capacités de migration. Le géant du cloud a précédemment introduit le service de migration de base de données pour automatiser la conversion du code et du schéma des bases Oracle vers AlloyDB. Google pourrait faire de même pour les SGBD d’IBM, de Microsoft et de SAP, entre autres.

« Le processus de conversion est généralement le principal obstacle à la migration d’une base de données vers une autre », rappelle l’analyste.