Google Cloud met la GenAI au service des bases de données (et vice-versa)

Des assistants « intelligents » pour les DBA et les Ops

Pour les administrateurs de bases de données (DBA) et les opérateurs, Google Cloud a développé un système de gestion de flottes de bases de données propulsées en partie par un LLM (Large Language Model) Gemini. Le système offre une vue unifiée sur la sécurité, la posture de conformité, l’utilisation des bases de données, les erreurs, la gestion des backups, etc.

« Vous pouvez utiliser la GenAI de manière proactive en posant des questions telles que : “quelles sont les bases de données qui n’ont pas été sauvegardées au cours des dernières 24 heures ?” »

« Nous avons des clients comme Ford qui déploient des milliers de bases de données », avance Andi Gutmans, vice-président et directeur général des bases de données chez Google Cloud. « Les clients ont toujours du mal à s’assurer que tout est sauvegardé, sécurisé. Sous contrôle. C’est pourquoi nous avons créé un seul et unique tableau de bord qui permet de visualiser l’ensemble de vos bases de données ».

« Vous pouvez utiliser la GenAI de manière proactive en posant des questions telles que : “quelles sont les bases de données qui n’ont pas été sauvegardées au cours des dernières 24 heures ?” », ajoute-t-il.

Cet assistant s’exécuterait en arrière-plan afin de signaler des erreurs et suggérer des recommandations que les DBA ou les Ops peuvent consulter en vue de résoudre de potentiels problèmes.

Pour l’instant, le gestionnaire de flottes est compatible avec cloud SQL et AlloyDB. « La prise en charge de Cloud Spanner est pour bientôt et l’objectif est de référencer toutes nos bases de données dans ce tableau de bord », avance Andi Gutmans. « Nous avons quelques clients qui l’utilisent déjà. Ils nous ont déjà donné beaucoup de bons retours pour faire évoluer la solution ».

Le troisième assistant est consacré à la migration de base de données. L’idée est de pouvoir analyser les procédures stockées, les déclencheurs, les fonctions d’une base de données relationnelle sur site afin de la convertir à PostgreSQL, avant de la migrer vers Cloud SQL ou AlloyDB.

D’ailleurs, GCP entend offrir par ce moyen une voie de migration pour les clients d’Oracle ou de Microsoft qui utiliseraient Exadata ou SQL Server. À ce titre, AlloyDB Omni serait plus adapté, selon Andi Gutmans. Cette variante d’AlloyDB peut être déployée sur différents clouds et sur site. L’espoir de Google Cloud est d’attirer petit à petit à lui les clients qui n’auraient pas encore adopté le cloud. C’était le premier cas d’usage présenté en août dernier au moment d’intégrer Duet AI dans les offres de bases de données.

L’indexation des vecteurs (embeddings) « à la Google »

AlloyDB bénéficie par ailleurs de fonctionnalités afin de mieux prendre en charge des cas d’usage liés à l’IA générative et les architectures RAG (Retrieval Augmented Generation).

En ce sens, GCP a développé ses propres capacités de gestion des vecteurs compatibles avec pgvector, le plugin consacré à cette tâche dans l’écosystème de PostgreSQL, la base de données open source sur laquelle s’appuie AlloyDB. GCP a revu le système d’indexation de ce SGBD pour le rendre plus performant que le standard postgres. Le fournisseur assure que les requêtes ciblant des vecteurs sont quatre fois plus rapides, que la création d’index peut être jusqu’à huit fois plus véloce et que son système consomme trois à quatre fois moins de mémoire vive que le « standard PostgreSQL ».

 GCP ne s’appuie pas sur la technique de recherche des plus proches voisins (k Nearest Neighbor ou kNN), mais sur un algorithme d’Approximate Nearest Neighbor ou ANN. Moins précise, cette approche est aussi plus efficiente, selon les chercheurs de Google qui travailleraient depuis douze ans sur le sujet.

La recherche approximative du plus proche voisin propulse déjà l’algorithme HSNW (Hierarchical Navigable Small World), celui-là même qui est utilisé pour gérer l’indexation des vecteurs dans pgvector, Redis, ou encore Pinecone. Or, il existe différentes catégories d’algorithmes ANN.

« La plupart des bases de données vectorielles utilisent aujourd’hui HNSW. Ce système d’indexation orienté graphes a ses avantages. Pour autant, les principaux inconvénients de HNSW, dans de nombreux cas d’usage, sont que le temps d’indexation est très lent et l’utilisation de la mémoire très élevée. Dans certains cas, les performances peuvent également varier considérablement », liste Andy Gutmans.

« Les index vectoriels basés sur la quantification arborescente structurent les données de manière à ce que les grappes de vecteurs proches soient regroupées et correctement compressées (quantifiées). »

Un argumentaire que GCP avait déjà développé en août dernier, en présentant son système d’indexation ScANN (Scalable Approximate Nearest Neighbour). En lieu et place de l’approche graphe, ScaNN s’appuie sur une structure en arborescence (B-Tree) vouée à améliorer la compression des vecteurs.

« Les index vectoriels basés sur la quantification arborescente structurent les données de manière à ce que les grappes de vecteurs proches soient regroupées et correctement compressées (quantifiées) », décrit Sandy Ghai, responsable produit groupe, AlloyDB chez Google Cloud, dans un billet de blog.

Non seulement plus frugal, ScANN serait plus adapté aux instructions SIMD prises en charge par les CPU.

« Et ce n’est que le début », affirme Andi Gutmans auprès du MagIT. « Nous connaissons déjà les optimisations que nous pourrons faire au cours des deux ou trois prochains mois. Nous n’avons pas eu le temps de les effectuer avant le début de la conférence [Google Cloud Next’24] ».

À l’avenir, pratiquement toutes les bases de données de Google prendront en charge les vecteurs selon Andi Gutmans, une approche similaire à celle annoncée par AWS en décembre 2023. AlloyDB, Redis, Cloud Spanner, FireStore, MySQL prennent en charge les embeddings ou le feront prochainement.

Toujours pour ancrer les résultats des grands modèles de langage, GCP a rappelé l’intégration avec LangChain, un framework utilisé pour orchestrer les flux des applications d’IA générative.

Un enjeu de véracité et de sécurité

En février, le géant du cloud a lancé AlloyDB AI, une suite de fonctionnalités permettant d’appliquer des modèles de machine learning sémantiques et prédictifs sur les données stockées dans la base compatible PostgreSQL.

Originellement, AlloyDB AI prend en charge deux grandes fonctions : l’invocation de LLM pour interagir avec des expressions SQL et la génération d’embeddings (de vecteurs).

« Quand une question est ambiguë pour AlloyDBAI, le système demande de clarifier la demande avec une question de suivi. »

Lors de Next, Google Cloud a lancé la préversion des intégrations d’AlloyDB avec des modèles distants, dont ceux gérés par Huggging Face, Anthropic et OpenAI. Surtout, le fournisseur a présenté un moyen de sécuriser l’interrogation en langage naturel des données stockées dans AlloyDB.

« Aujourd’hui, l’interrogation de bases de données en langage naturel pose un problème », note Andi Gutmans. « Deux approches sont possibles : la première consiste à utiliser une API qui tente de traduire le langage naturel en appels API. Cette méthode est fiable, mais manque de flexibilité, car elle ne permet pas d’obtenir de réponses pour des questions non prises en charge par l’API », explique-t-il. « La seconde option est de convertir le langage naturel en langage SQL. Elle offre une grande flexibilité, mais peut présenter des problèmes de sécurité et de précision ».

Les ingénieurs de Google ont mis en place un mécanisme de « clarification d’intention ». « Quand une question est ambiguë pour AlloyDBAI, le système demande de clarifier la demande avec une question de suivi », résume le VP responsable des bases de données.

Or l’accès aux données dans les tables d’une base de données relationnelle n’est pas libre. Le schéma est généralement un frein pour exploiter pleinement les données. Pour tenter de briser cette limite, AlloyDB AI pourra avoir accès aux métadonnées de la base, des exemples de requêtes ou d’autres sources d’informations, afin d’augmenter la pertinence du résultat à une requête spécifique.

Évidemment, un tel mécanisme réclame une attention supplémentaire en matière de sécurité. « Nous avons ajouté à cela ce que nous appelons une vue sécurisée paramétrée », signale Andi Gutmans. « Il s’agit d’un nouveau type de vue sécurisée qui vous permet d’injecter le contexte de l’utilisateur final dans la vue sécurisée, de sorte que même s’il dispose de toute la flexibilité nécessaire, s’il essaie de poser une question qu’il n’est pas censé poser, cela l’empêchera d’accéder aux données correspondantes ». Il s’agirait en premier lieu d’éviter les attaques par injection (prompt injection).

Malgré sa disponibilité en préversion publique, ce mécanisme n’est toutefois pas encore totalement au point, reconnaît le vice-président. « Cela fonctionne, mais cela prendra trois à quatre mois avant que le mécanisme soit vraiment bon », anticipe-t-il. « Nous n’en sommes pas encore là, mais nous sommes persuadés que nous allons y arriver ».