Utilisation d'index vectoriels dans DynamoDB

Compare la direction et ignore la magnitude. Utiliser COSINE pour la similitude sémantique avec les modèles d'intégration de texte. Ces modèles codent le sens dans la direction, et la longueur du vecteur peut varier. Les exemples incluent Amazon Titan Text Embeddings et Cohere Embed.

COSINE convient parfaitement aux cas d'utilisation suivants :

COSINE est la valeur par défaut sécurisée lorsque vous ne savez pas quelle fonction utiliser.

DOT_PRODUCT est sensible à la fois à la direction et à l'amplitude (la longueur d'un vecteur). Choisissez DOT_PRODUCT lorsque la documentation de votre modèle d'intégration recommande un produit scalaire comme mesure de similarité, ou lorsque vous souhaitez que la longueur du vecteur influence le classement.

DOT_PRODUCT convient parfaitement aux cas d'utilisation suivants :

Nous vous recommandons de normaliser vos intégrations en fonction de la longueur unitaire. Une fois normalisé, DOT_PRODUCT classe les résultats de la même manière que COSINE. Ignorez la normalisation uniquement si vous souhaitez que l'ampleur affecte le classement.

Exemple de cas d'utilisation : un système de recommandation de produits dans lequel vous redimensionnez chaque produit intégré en fonction de son score de popularité. Les produits les plus populaires obtiennent des vecteurs plus longs et sont mieux classés dans les résultats de recherche.

Mesure la distance en ligne droite entre deux vecteurs. EUCLIDEAN est sensible à la magnitude. Utilisez-le lorsque la position absolue dans l'espace d'intégration est importante.

EUCLIDEAN convient parfaitement aux cas d'utilisation suivants :

Exemple de cas d'utilisation : recherche d'images quasi dupliquées à partir d'intégrations d'images.

Une clé de partition d'index vectoriel étend chaque recherche aux vecteurs qui partagent la même valeur pour un attribut que vous choisissez. Les éléments ayant la même valeur de clé de partition sont stockés ensemble, de sorte que la recherche ne lit que ce sous-ensemble au lieu de parcourir l'index dans son intégralité. À grande échelle, une clé de partition d'index vectoriel réduit la latence de recherche car celle-ci n'examine qu'un sous-ensemble de l'espace vectoriel. Utilisez des attributs dont la cardinalité est faible à moyenne, tels que Category ou Country. Vous pouvez spécifier au plus une clé de partition d'index vectoriel.

Si vous définissez une clé de partition d'index vectoriel dans SearchSchema, vous devez indiquer sa valeur dans le SearchConditionExpression quand tu appelles SearchVectors.

Un attribut de filtre intégré est un attribut non vectoriel normal dont DynamoDB enregistre la valeur dans l'index vectoriel à côté de chaque vecteur. Comme la valeur correspond au vecteur, DynamoDB ignore les vecteurs qui ne correspondent pas à votre filtre lors de la recherche dans l'index. Cela permet d'éviter de rechercher d'abord dans l'index complet, puis de rejeter les résultats qui ne correspondent pas.

Par exemple, si vous définissez un Language attribut en tant que filtre en ligne, une recherche qui filtre sur Language ne considère que les vecteurs dont Language les valeurs correspondent.

Les filtres en ligne prennent en charge l'opérateur d'égalité (=) dans SearchConditionExpression. Opérateurs de comparaison, de gamme et d'appartenance à un ensemble (<>, <, <=, >, >=, IN) ne sont pas encore disponibles. Contrairement aux clés de partition d'index vectoriel, les filtres intégrés sont facultatifs lors de la recherche.

Vous pouvez activer DynamoDB Streams sur une table dotée d'un index vectoriel, soit à l'aide du StreamSpecification paramètre lorsque vous créez la table ou via UpdateTable. Le flux capture les modifications apportées au niveau des éléments à la table de base et fonctionne indépendamment de l'indice vectoriel.

Vous pouvez ajouter un index vectoriel à une table globale, et vous pouvez convertir une table qui possède un index vectoriel en une table globale en ajoutant une réplique avec UpdateTable. La définition de l'indice vectoriel, y compris ses dimensions, sa fonction de distance, SearchSchema, et la projection, sont répliquées automatiquement dans chaque nouvelle région de réplication. Vous ne créez pas l'index vectoriel séparément dans la région du réplica.

Les éléments que vous écrivez dans n'importe quelle région de réplication sont répliqués dans les autres régions et y sont indexés. Une fois la réplication terminée, SearchVectors dans chaque région recherche le même ensemble de vecteurs. Étant donné que la recherche vectorielle utilise le voisin le plus proche approximatif (ANN), des recherches distinctes dans différentes régions peuvent renvoyer des résultats ou un ordre légèrement différents pour la même requête, même pour des données identiques. La réplication des tables entre les régions suit la garantie de cohérence de la table globale, y compris une cohérence élevée pour les tables mondiales multi-régions à cohérence forte (MRSC). L'indexation vectorielle s'effectue toutefois toujours de manière asynchrone après l'application d'une écriture à la table, dans chaque région, y compris la région dans laquelle vous avez écrit. La garantie MRSC couvre le tableau, pas l'indice vectoriel. Par conséquent, un délai se produit entre le moment où une écriture est confirmée et le moment où le vecteur devient consultable SearchVectors. Ce délai s'applique au niveau local ainsi qu'à l'ensemble des régions.

Lorsque vous restaurez une table à partir d'une restauration instantanée ou d'une sauvegarde à la demande, DynamoDB restaure les données de la table de base et la définition de l'index vectoriel. Comme pour les index secondaires globaux, DynamoDB reconstruit l'index vectoriel à partir des données restaurées de la table de base plutôt que de le copier octet par octet. L'index est donc soumis à un remplissage avant d'être prêt pour la recherche. Attendez que IndexStatus est ACTIVE et Backfilling n'est pas true sur l'index restauré avant de lancer SearchVectors.

Vous pouvez utiliser DynamoDB TTL sur une table dotée d'un index vectoriel. Lorsque TTL supprime un élément expiré de la table de base, DynamoDB supprime l'entrée correspondante de l'index vectoriel, comme le fait une suppression manuelle. Les articles expirés cessent donc d'apparaître dans SearchVectors résultats après la propagation de la suppression vers l'index.

Vous pouvez exporter un tableau contenant un index vectoriel vers Amazon S3 ; l'exportation contient les éléments de la table de base, y compris les attributs vectoriels qui y sont stockés. Lorsque vous importez des données depuis Amazon S3 dans une nouvelle table, définissez l'index vectoriel dans la demande d'importation de la même manière que vous le feriez avec CreateTable. DynamoDB indexe les éléments importés au fur et à mesure de leur écriture, et l'index vectoriel devient disponible une fois l'importation terminée.

L'accélérateur DynamoDB (DAX) ne prend pas en charge SearchVectors opération. Envoyer SearchVectors requêtes directement adressées à DynamoDB, même lorsque votre application utilise DAX pour d'autres opérations de lecture. La mise en cache DAX des lectures de la table de base n'est pas affectée par la présence d'un index vectoriel. Si vous avez besoin d'une couche de mise en cache pour les résultats de recherche vectorielle, vous pouvez mettre en cache SearchVectors réponses dans un cache externe, tel qu'Amazon ElastiCache pour Valkey. Vous êtes responsable du remplissage et de l'invalidation de ce cache.