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 même temps que 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 tableau et les représentations vectorielles, vous devez créer une colonne dans votre tableau pour stocker vos embeddings vectoriels. La colonne doit utiliser le type de données VECTOR de Cloud SQL et indiquer le nombre de dimensions requises par l'embedding. 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 lorsque vous définissez 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 des valeurs COMMENT et CONSTRAINT spéciales à la colonne. 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 des 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 et colonnes d'embedding vectoriel, ainsi que les instructions LMD, consultez Limites.

Index vectoriels

Vous devez utiliser un index 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 index vectoriel par table.
  • Si votre instance comporte plusieurs tables avec des embeddings vectoriels, 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 une meilleure qualité de 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 la table de base contient moins de 1 000 embeddings, la création de l'index échoue.

Lorsque vous décidez de créer ou non un index vectoriel, si vous avez un petit nombre de lignes, demandez-vous si vous pouvez effectuer une recherche KNN à la place. La décision d'utiliser une recherche KNN ou ANN dépend également du nombre de dimensions de l'embedding vectoriel. Un plus grand nombre d'embeddings peut nécessiter un index vectoriel.

Pour obtenir la liste des limites et restrictions concernant les index vectoriels, consultez Limites. Pour savoir comment créer un index vectoriel, consultez Créer et gérer des index vectoriels.

Mises à jour des index vectoriels

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 les autres index secondaires de la table. Les index vectoriels sont entièrement cohérents au niveau transactionnel et conformes à 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 répliqué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 répliqué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 compatibilité ACID complète. Les index vectoriels sont toujours synchronisés avec les données de leur table de base. Ils présentent la même visibilité, le même niveau d'isolation et la même sécurité en cas de plantage. L'index vectoriel n'est pas affecté lorsque l'instance est arrêtée ou fait l'objet d'une maintenance.

Maintenance des index

Après avoir effectué des opérations LMD importantes 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) peut 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 :

  • Arborescence de l'index. Il est créé en s'entraînant sur des données existantes. Elle reste inchangée pendant toute la durée de vie de l'index.
  • L'index quitte. Elles contiennent toutes les lignes de données. Les feuilles d'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 LMD, car les lignes passent d'une feuille à une autre. Pour actualiser l'arborescence de l'index, vous devez le recompiler.

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

  • Opérations Alter table nécessitant un algorithme de copie.
  • Opérations ALTER TABLE qui nécessitent la reconstruction 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 utilisez pour effectuer des recherches de similarité vectorielle approximatives du voisin le plus proche (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 magnitudes de vecteur correspondantes.
  • Distance L2 au carré : mesure la distance euclidienne entre deux vecteurs en additionnant la distance au carré sur chaque dimension.

La 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 calcule la distance entre le vecteur de requête et chaque embedding 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. Elle calcule la distance entre ces deux vecteurs. Vous utilisez vector_distance dans une instruction SELECT. Pour en savoir plus, consultez Rechercher les k plus proches voisins (KNN).

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

La 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 seulement une partie des vecteurs de votre ensemble de données. Pour ce faire, Cloud SQL organise les données en clusters ou 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 privilégient la vitesse de recherche plutôt que le rappel parfait. Dans Cloud SQL, le type d'index TREE_SQ est utilisé pour les recherches ANN.

Pour effectuer une recherche ANN, vous utilisez la fonction approx_distance avec une option de mesure de 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 filtrer vos résultats de recherche après coup. Pour en savoir plus, consultez Rechercher les plus proches voisins approximatifs (ANN).

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

Conditions requises

Cloud SQL vous demande d'activer les embeddings vectoriels sur l'instance à l'aide de l'indicateur cloudsql_vector avant d'ajouter des embeddings vectoriels. Pour en savoir plus, consultez Activer et désactiver les embeddings vectoriels 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 index 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 et 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 index vectoriel est présent, vous ne pouvez pas ajouter de contrainte à la clé primaire de la table de base.
  • Lorsque un index vectoriel est présent sur une table, certaines opérations LDD ne peuvent pas être effectuées. Pour en savoir plus, consultez Opérations LDD non compatibles avec les tables comportant 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 les fonctions vectorielles approx_distance.

Bonnes pratiques pour l'utilisation des index vectoriels

Cette section présente les bonnes pratiques relatives à l'utilisation des 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 d'avoir au moins 100 vecteurs par feuille pour obtenir le meilleur rappel.

Étapes suivantes