recherche vectorielle

Cette page explique comment les recherches vectorielles sont implémentées sur les instances Cloud SQL pour MySQL. Cloud SQL vous permet de stocker des embeddings vectoriels, de créer des index vectoriels et d'effectuer des recherches vectorielles en plus de vos autres données stockées.

Stockage d'embeddings vectoriels

Vous stockez les embeddings vectoriels dans une table conforme aux propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID). Comme pour les autres données relationnelles de la table, vous pouvez accéder aux embeddings vectoriels de la table avec la sémantique transactionnelle existante.

Pour établir un mappage entre les lignes de la table et les représentations vectorielles, vous devez créer une colonne dans votre table pour stocker vos embeddings vectoriels. La colonne doit utiliser le type de données VECTOR de Cloud SQL et doit indiquer le nombre de dimensions requises par l'imbrication. La colonne d'embedding vectoriel ne peut stocker que des embeddings vectoriels qui utilisent exactement les mêmes dimensions que celles que vous spécifiez lors de la définition de la colonne.

Une table ne peut contenir qu'une seule colonne d'embeddings vectoriels. Le nombre de lignes dans le tableau n'est pas limité.

Pour distinguer la colonne d'embeddings vectoriels des autres colonnes, Cloud SQL ajoute à la colonne des valeurs COMMENT et CONSTRAINT spéciales. La contrainte est requise pour la validation des entrées, et l'annotation de la colonne d'embeddings vectoriels est visible en tant que COMMENT. Vous ne pouvez ni modifier, ni supprimer le commentaire ou la contrainte.

Si vous disposez de suffisamment d'espace de stockage et de mémoire sur votre instance Cloud SQL, vous pouvez avoir plusieurs tables avec leurs propres colonnes de représentations vectorielles continues.

La réplication de données fonctionne de la même manière pour la colonne d'embeddings vectoriels que pour les autres colonnes MySQL InnoDB.

Pour obtenir la liste des limites et restrictions concernant les tables, les colonnes et les instructions DML d'embedding vectoriel, consultez la section Limites.

Index vectoriels

Vous devez utiliser un indice vectoriel pour effectuer des recherches de similarité ANN sur vos embeddings vectoriels. Cloud SQL crée des index vectoriels à l'aide de l'algorithme Scalable Nearest Neighbors (ScANN).

Les index vectoriels sont soumis aux exigences suivantes:

  • Vous ne pouvez créer qu'un seul indice vectoriel par table.
  • Si vous avez plusieurs tables avec des représentations vectorielles continues sur votre instance, vous pouvez créer des index vectoriels pour chacune d'elles.
  • Si vous créez un index vectoriel, vous ne pouvez pas ajouter de contrainte à la clé primaire de la table indexée.

Pour améliorer la qualité de la recherche, ne créez un index vectoriel qu'après avoir chargé la majeure partie de vos données dans la table de base. Si vous disposez de moins de 1 000 embeddings dans la table de base, la création de l'index échoue.

Lorsque vous décidez de créer un indice vectoriel, si vous disposez d'un petit nombre de lignes, demandez-vous si vous pouvez plutôt effectuer une recherche KNN. Le choix d'utiliser une recherche KNN ou ANN dépend également du nombre de dimensions de l'embedding vectoriel. Un nombre plus élevé d'embeddings peut nécessiter un indice de vecteur.

Pour obtenir la liste des limites et restrictions applicables aux index vectoriels, consultez la section Limites. Pour en savoir plus sur la création d'un indice vectoriel, consultez la section Créer et gérer des indices vectoriels.

Mises à jour de l'index vectoriel

Cloud SQL met à jour les index vectoriels en temps réel. Toute transaction effectuant des opérations LMD (langage de manipulation de données) sur la table de base propage également les modifications apportées aux index vectoriels associés. Les index vectoriels se comportent de la même manière que tous les autres index secondaires de la table. Les index vectoriels sont entièrement cohérents au niveau des transactions et conformes aux principes ACID. Si vous effectuez le rollback d'une transaction, les modifications de rollback correspondantes se produisent également dans l'index vectoriel.

Réplication des index vectoriels

Cloud SQL réplique les index vectoriels sur toutes les instances dupliquées avec accès en lecture, y compris pour la réplication en cascade. Lorsque vous créez une instance dupliquée avec accès en lecture à partir d'une instance principale avec embedding vectoriel, l'instance dupliquée avec accès en lecture hérite des paramètres d'embedding vectoriel de l'instance principale. Pour les instances dupliquées avec accès en lecture existantes, vous devez activer la compatibilité avec les embeddings vectoriels sur chacune d'elles.

En termes d'impact sur le délai de réplication, la création et la gestion des index vectoriels fonctionnent de la même manière que les index MySQL classiques.

Persistance, arrêt et impact sur la maintenance

Les index vectoriels sont conservés de la même manière que les tables de base, avec une prise en charge complète de ACID. Les index vectoriels sont toujours synchronisés avec les données de leur table de base et ont la même visibilité, isolation et sécurité contre les plantages. L'index de vecteur n'est pas affecté lorsque l'instance est arrêtée ou qu'elle fait l'objet d'une maintenance.

Maintenance des index

Une fois que des opérations LMD étendues ont été effectuées sur la table de base, l'index vectoriel que vous avez entraîné sur les données initiales (au moment de la création de l'index) risque de ne pas refléter le nouvel état. Cela peut avoir un impact sur la qualité de la recherche.

L'index se compose de deux parties:

  • Arbre d'index. Il est créé en s'appuyant sur des données existantes. Il reste inchangé pendant toute la durée de vie de l'index.
  • L'index quitte la page. Ils contiennent toutes les lignes de données. Les feuilles de l'index ne sont jamais désynchronisées.

L'arborescence d'index peut devenir moins efficace après l'exécution d'un grand nombre d'instructions DML, car les lignes passent d'une feuille à une autre. Pour actualiser l'arborescence de l'index, vous devez recompiler l'index.

Opérations LDD non acceptées sur les tables avec des index vectoriels

  • Opérations de modification de table nécessitant un algorithme de copie
  • Opérations de modification de table qui nécessitent la recréation de la table.
  • Supprimez ou modifiez la clé primaire.
  • Déplacez la table vers un espace de table général.

recherche vectorielle

Cloud SQL fournit des fonctions de distance vectorielle que vous pouvez utiliser pour effectuer des recherches de similarité vectorielle des plus proches voisins approximatifs (ANN) et des k plus proches voisins (KNN) sur votre instance. Lorsque vous exécutez une requête, le vecteur de requête est comparé aux vecteurs de votre ensemble de données. Les fonctions de distance calculent la distance entre les vecteurs à l'aide d'une métrique de similarité telle que le cosinus. Les vecteurs dont la distance est la plus courte sont les plus similaires et sont renvoyés dans les résultats de recherche.

Cloud SQL utilise les fonctions suivantes pour mesurer la distance entre les vecteurs dans les recherches vectorielles lorsque vous effectuez des recherches vectorielles ANN et KNN:

  • Cosinus : mesure le cosinus de l'angle entre deux vecteurs. Une valeur plus faible indique une plus grande similarité entre les vecteurs.
  • Produit scalaire : calcule le cosinus de l'angle multiplié par le produit des grandeurs vectorielles correspondantes.
  • Distance au carré L2 : mesure la distance euclidienne entre deux vecteurs en ajoutant la distance au carré sur chaque dimension.

Une recherche vectorielle KNN est la méthode de recherche privilégiée lorsque vous avez besoin de résultats exacts ou que vous souhaitez ajouter un filtrage sélectif. La recherche KNN effectue un calcul de distance du vecteur de requête avec chaque représentation vectorielle continue de l'ensemble de données pour trouver le voisin le plus proche. Les recherches KNN dans Cloud SQL offrent un rappel parfait. Les recherches KNN n'utilisent pas d'index vectoriel. Elles sont donc une bonne option lorsque vous travaillez avec des ensembles de données plus petits.

Pour effectuer une recherche KNN, vous utilisez la fonction vector_distance qui prend deux vecteurs en entrée: le vecteur de requête (ce que vous recherchez) et un vecteur candidat de votre ensemble de données. Il calcule la distance entre ces deux vecteurs. Vous utilisez vector_distance dans une instruction SELECT. Pour en savoir plus, consultez la section Recherche des k plus proches voisins (KNN).

Si vous constatez que le KNN ne fonctionne pas bien, vous pouvez créer un index vectoriel plus tard et continuer à utiliser approx_distance dans votre application pour les recherches ANN.

Une recherche vectorielle ANN est le type de recherche privilégié lorsque l'efficacité des requêtes est un problème. Il accélère les recherches de similarité en calculant la distance entre votre vecteur de requête et une partie seulement des vecteurs de votre ensemble de données. Pour ce faire, Cloud SQL organise les données en clusters ou en partitions, puis concentre la recherche sur les clusters les plus proches de la requête. Les recherches ANN nécessitent des index vectoriels. Ces index donnent la priorité à la vitesse de recherche plutôt qu'à la mémorisation parfaite. Dans Cloud SQL, le type d'index TREE_SQ est utilisé pour les recherches ANN.

Pour effectuer une recherche avec une ANN, vous devez utiliser la fonction approx_distance avec une option de mesure de la distance. Vous utilisez approx_distance dans une liste ORDER BY ou SELECT, et une clause LIMIT est autorisée pour limiter les résultats de recherche. Vous pouvez également ajouter une clause WHERE pour effectuer un post-filtrage de vos résultats de recherche. Pour en savoir plus, consultez la section Rechercher des plus proches voisins approximatifs (ANN).

Dans certains cas, une recherche ANN est remplacée par une recherche KNN. Pour en savoir plus, consultez la section Vérifier l'état de remplacement pour les recherches ANN.

Conditions requises

Cloud SQL vous oblige à activer les embeddings vectoriels sur l'instance à l'aide de l'option cloudsql_vector avant d'ajouter des embeddings vectoriels. Pour en savoir plus, consultez la section Activer et désactiver les représentations vectorielles continues sur votre instance.

Limites

Voici les limites applicables aux tables comportant une colonne d'embeddings vectoriels:

  • Il ne peut y avoir qu'une seule colonne d'embeddings vectoriels par table.
  • Il ne peut y avoir qu'un seul indice vectoriel par table.
  • Un embedding vectoriel est limité à 16 000 dimensions.
  • La colonne d'embeddings vectoriels ne peut pas être une colonne générée.
  • Le partitionnement au niveau de la table sur les tables comportant des colonnes d'embeddings vectoriels n'est pas accepté.
  • Les clés primaires qui utilisent les types de données BIT, BINARY, VARBINARY, JSON, BLOB, TEXT ou les données spatiales ne sont pas compatibles avec les index vectoriels. Les clés primaires composites ne peuvent pas non plus inclure aucun de ces types.
  • Si un indice vectoriel est présent, vous ne pouvez pas ajouter de contrainte à la clé primaire de la table de base.
  • Lorsqu'un indice vectoriel est présent sur une table, certaines opérations LDD ne sont pas possibles. Pour en savoir plus, consultez la section Opérations LDD non compatibles sur les tables avec des index vectoriels.

Voici les restrictions concernant les requêtes de recherche vectorielle:

  • La fonction approx_distance ne peut être utilisée que dans une liste ORDER BY ou SELECT.
  • Les prédicats impliquant la table de base peuvent être utilisés dans la condition WHERE en combinaison avec des expressions approx_distance dans la liste ORDER BY ou SELECT. Les prédicats de condition WHERE sont évalués après l'évaluation des fonctions vectorielles approx_distance.

Bonnes pratiques pour l'utilisation des index vectoriels

Cette section présente les bonnes pratiques à suivre pour utiliser les index vectoriels. Chaque charge de travail est différente, et vous devrez peut-être procéder à des ajustements en conséquence.

  • Après des opérations LMD majeures, il est recommandé de recréer l'index.
  • En règle générale, il est acceptable de laisser Cloud SQL calculer le nombre de feuilles à utiliser. Si vous souhaitez spécifier le nombre de feuilles dans le cas d'une utilisation, nous vous recommandons de disposer d'au moins 100 vecteurs par feuille pour obtenir le meilleur rappel.

Étape suivante