Meilleures pratiques pour les index vectoriels

Les recommandations suivantes vous aident à concevoir des index vectoriels précis, performants et économiques.

Choisissez d'abord votre modèle et vos dimensions d'intégration

Le modèle d'intégration que vous utilisez détermine le nombre de dimensions de vos vecteurs, et vous le définissez Dimensions lors de la création de l'index. Vous ne pouvez pas modifier le nombre de dimensions après la création. Choisissez un modèle d'intégration avant de créer l'index et utilisez le même modèle pour générer à la fois des vecteurs stockés et des vecteurs de requête. La réduction des dimensions réduit les coûts de recherche, d'écriture et de stockage, mais les modèles de plus grande dimension peuvent capturer plus de détails sémantiques. Choisissez le plus petit nombre de dimensions qui répond à vos exigences de pertinence. Consultez Génération d'intégrations vectorielles.

Adaptez la fonction de distance à vos encastrements

Choisissez la fonction de distance qui correspond à la façon dont votre modèle d'intégration représente la similitude. COSINEcompare la direction et ignore la magnitude, ce qui convient à la plupart des modèles d'intégration de texte. EUCLIDEANmesure la distance absolue et est sensible à la magnitude. DOT_PRODUCTest également sensible à la magnitude. Si vous l'utilisez, normalisez vos intégrations à la longueur unitaire afin que les scores reflètent la direction plutôt que la longueur vectorielle. Vous ne pouvez pas modifier la fonction de distance après avoir créé l'index, alors validez d'abord votre choix par rapport à un ensemble de données représentatif. Consultez Comment les fonctions de distance classent les résultats.

Choisissez une clé de partition qui correspond à vos modèles de requête

Une clé de partition limite chaque SearchVectors appel à la partie de l'index vectoriel qui appartient à une seule valeur de clé de partition. L'appel ne recherche pas l'intégralité de l'index. La recherche de moins de données permet de réduire les coûts, d'améliorer la latence et le rappel, et d'adapter horizontalement le débit en fonction des valeurs clés de partition.

Vous devez fournir la valeur de la clé de partition SearchConditionExpression à chaque recherche. Chaque recherche est limitée à une seule valeur de clé de partition. Choisissez une clé de partition qui correspond aux modèles de requête pris en charge par votre application.

Par exemple, si vous stockez des données géolocalisées par État américain, vous disposez d'environ 50 valeurs de clé de partition. Chaque état contient un nombre significatif de vecteurs pour un bon rappel. Les 50 partitions offrent une mise à l'échelle horizontale du débit jusqu'à environ 50 fois. Cela fonctionne lorsque chaque recherche cible un seul État.

Évitez l'extrême cardinalité dans les deux sens :

• Trop élevé (par exemple, un identifiant d'article unique) : chaque partition contient un seul élément sans aucun voisin à comparer, ce qui entraîne un mauvais rappel.

• Trop faible (par exemple, une valeur booléenne) : la plupart des éléments atterrissent sur une seule partition, ce qui limite la mise à l'échelle du débit, réduit la latence et réduit les avantages en termes de coûts.

Pour filtrer davantage au sein d'une partition, utilisez les attributs de filtre intégrés.

Exemple de débit. Prenons l'exemple d'un modèle d'intégration à 768 dimensions (tel que Cohere Embed v3) avec 1 Ko de données d'éléments non vectorielles, ce qui donne une taille totale d'élément d'environ 4 Ko (768 dimensions × 4 octets + 1 Ko). Avec cette taille d'élément, les limites par clé de partition se traduisent par :

• Recherche : 1 Gbit/s ÷ 4 Ko ≈ 250 000 vecteurs examinés par seconde par valeur de clé de partition. À mesure que le nombre de vecteurs dans une partition augmente, chaque recherche examine de plus en plus de données et vous vous rapprocherez de cette limite plus rapidement.

• Écriture : 10 Mo/s ÷ 4 Ko ≈ 2 500 écritures vectorielles par seconde par valeur de clé de partition

La répartition de vos données sur un plus grand nombre de valeurs clés de partition multiplie ces limites. Par exemple, 50 valeurs de clé de partition fournissent jusqu'à 50 fois le débit de recherche et d'écriture agrégé. Si votre charge de travail dépasse ces limites par clé de partition, contactez le support. AWS

Synchroniser les intégrations avec le contenu source

DynamoDB ne recalcule pas les intégrations pour vous. Chaque fois que vous modifiez le contenu source représenté par une intégration, régénérez le vecteur avec le même modèle d'intégration et réinscrivez-le dans l'élément. Dans le cas contraire, l'indice continue à renvoyer des résultats basés sur le vecteur obsolète. Envisagez de capturer les modifications de contenu avec DynamoDB Streams et d'utiliser un processus en aval pour régénérer et réécrire les intégrations concernées.

Projetez uniquement les attributs dont vous avez besoin

SearchVectorsne peut pas renvoyer d'attributs qui ne sont pas projetés dans l'index vectoriel. La projection d'un plus grand nombre d'attributs augmente le stockage des index et les coûts d'écriture. Projetez les attributs que votre application lit directement à partir des résultats de recherche et récupérez le reste avec un suivi GetItem ou BatchGetItem sur le tableau de base lorsque vous en avez besoin.

Utilisez plusieurs index pour comparer les modèles d'intégration

Vous pouvez créer jusqu'à 5 index vectoriels sur une seule table. Utilisez des index distincts pour évaluer côte à côte différents modèles d'intégration ou versions de modèles. Stockez les intégrations de chaque modèle dans un attribut vectoriel différent et créez un index vectoriel pour chacun. Cela vous permet de comparer la qualité de recherche entre les modèles par rapport aux mêmes données sous-jacentes sans migrer votre index de production.

Par exemple, lors de la mise à niveau d'une version de modèle à une autre, créez un deuxième index avec les dimensions et la fonction de distance du nouveau modèle. Complétez-le avec des intégrations issues du nouveau modèle, exécutez des requêtes de test sur les deux index et comparez la pertinence. Une fois que vous êtes satisfait, migrez votre application vers le nouvel index et supprimez l'ancien.