Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Recherche vectorielle La recherche vectorielle pour MemoryDB étend les fonctionnalités de MemoryDB. La recherche vectorielle peut être utilisée conjointement avec les fonctionnalités existantes de MemoryDB. Les applications qui n'utilisent pas la recherche vectorielle ne sont pas affectées par sa présence. La recherche vectorielle est disponible dans toutes les régions où MemoryDB est disponible. La recherche vectorielle simplifie l'architecture de votre application tout en fournissant une recherche vectorielle à haut débit. La recherche vectorielle pour MemoryDB est idéale pour les cas d'utilisation où les performances optimales et l'évolutivité sont les critères de sélection les plus importants. Vous pouvez utiliser vos données MemoryDB existantes, ou une API Valkey ou Redis OSS, pour créer des cas d'utilisation de l'apprentissage automatique et de l'IA générative. Cela inclut la génération augmentée par extraction, la détection des anomalies, la récupération de documents et les recommandations en temps réel. Depuis le 26/06/2024, AWS MemoryDB offre les performances de recherche vectorielle les plus rapides avec les taux de rappel les plus élevés parmi les bases de données vectorielles les plus populaires sur. AWS **Topics** + [Aperçu de la recherche vectorielle](vector-search-overview.md) + [Cas d’utilisation](vector-search-examples.md) + [Caractéristiques et limites de la recherche vectorielle](vector-search-limits.md) + [Création d'un cluster activé pour la recherche vectorielle](vector-search-cluster.md) + [Commandes de recherche vectorielle](vector-search-commands.md) # Aperçu de la recherche vectorielle La recherche vectorielle repose sur la création, la maintenance et l'utilisation d'index. Chaque opération de recherche vectorielle spécifie un seul index et son opération est limitée à cet index, c'est-à-dire que les opérations sur un index ne sont pas affectées par les opérations sur un autre index. À l'exception des opérations de création et de destruction d'index, un certain nombre d'opérations peuvent être effectuées sur n'importe quel index à tout moment, ce qui signifie qu'au niveau du cluster, plusieurs opérations sur plusieurs index peuvent être en cours simultanément. Les index individuels sont des objets nommés qui existent dans un espace de noms unique, distinct des autres espaces de noms Valkey et Redis OSS : clés, fonctions, etc. Chaque index est conceptuellement similaire à une table de base de données classique dans la mesure où il est structuré en deux dimensions : colonne et lignes. Chaque ligne du tableau correspond à une clé. Chaque colonne de l'index correspond à un membre ou à une partie de cette clé. Dans ce document, les termes clé, ligne et enregistrement sont identiques et utilisés de manière interchangeable. De même, les termes colonne, champ, chemin et membre sont essentiellement identiques et sont également utilisés de manière interchangeable. Il n'existe aucune commande spéciale pour ajouter, supprimer ou modifier des données indexées. Au contraire, **JSON** les commandes existantes **HASH** ou qui modifient une clé figurant dans un index mettent également automatiquement à jour l'index. **Topics** + [Les index et le keyspace Valkey et Redis OSS](#vector-search-indexes-keyspaces) + [Types de champs d'index](#vector-search-index-field-types) + [Algorithmes d'index vectoriel](#vector-search-index-algorithms) + [Expression de requête de recherche vectorielle](#vector-search-query-expression) + [commande INFO](#vector-search-ft.info) + [Sécurité de la recherche vectorielle](#vector-search-security) ## Les index et le keyspace Valkey et Redis OSS Les index sont construits et gérés sur un sous-ensemble de l'espace de touches Valkey et Redis OSS. Plusieurs index peuvent choisir des sous-ensembles disjoints ou superposés de l'espace-clé sans limitation. L'espace-clé de chaque index est défini par une liste de préfixes clés fournis lors de la création de l'index. La liste des préfixes est facultative et si elle est omise, l'espace clé entier fera partie de cet index. Les index sont également saisis dans la mesure où ils ne couvrent que les clés dont le type correspond. Actuellement, seuls les index JSON et HASH sont pris en charge. Un index HASH indexe uniquement les clés HASH couvertes par sa liste de préfixes. De même, un index JSON indexe uniquement les clés JSON couvertes par sa liste de préfixes. Les clés de la liste de préfixes d'espaces de touches d'un index qui n'ont pas le type désigné sont ignorées et n'affectent pas les opérations de recherche. Lorsqu'une commande HASH ou JSON modifie une clé qui se trouve dans un espace clé d'un index, cet index est mis à jour. Ce processus consiste à extraire les champs déclarés pour chaque index et à mettre à jour l'index avec la nouvelle valeur. Le processus de mise à jour est effectué dans un fil de discussion en arrière-plan, ce qui signifie que les index ne sont cohérents qu'en fin de compte avec le contenu de leur espace clavier. Ainsi, l'insertion ou la mise à jour d'une clé ne sera pas visible dans les résultats de recherche pendant une courte période. Pendant les périodes de forte charge du système et de and/or forte mutation des données, le délai de visibilité peut s'allonger. La création d'un index est un processus en plusieurs étapes. La première étape consiste à exécuter la commande [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) qui définit l'index. L'exécution réussie d'une création initie automatiquement la deuxième étape : le remblayage. Le processus de remplissage s'exécute dans un fil d'arrière-plan et analyse l'espace des touches à la recherche de clés figurant dans la liste de préfixes du nouvel index. Chaque clé trouvée est ajoutée à l'index. Finalement, l'espace clé entier est scanné, complétant ainsi le processus de création de l'index. Notez que lorsque le processus de remplissage d'index est en cours d'exécution, les mutations de clés indexées sont autorisées, il n'y a aucune restriction et le processus de remplissage d'index ne sera pas terminé tant que toutes les clés ne seront pas correctement indexées. Les opérations de requête tentées alors qu'un index est en cours de remblayage ne sont pas autorisées et se terminent par une erreur. L'achèvement du processus de remblayage peut être déterminé à partir de la sortie de la `FT.INFO` commande pour cet index ('backfill\$1status'). ## Types de champs d'index Chaque champ (colonne) d'un index possède un type spécifique déclaré lors de la création de l'index et un emplacement dans une clé. Pour les clés HASH, l'emplacement est le nom du champ dans le HASH. Pour les clés JSON, l'emplacement est une description du chemin JSON. Lorsqu'une clé est modifiée, les données associées aux champs déclarés sont extraites, converties dans le type déclaré et stockées dans l'index. Si les données sont manquantes ou ne peuvent pas être converties correctement dans le type déclaré, ce champ est omis de l'index. Il existe quatre types de champs, comme expliqué ci-dessous : + Les **champs numériques** contiennent un seul chiffre. Pour les champs JSON, les règles numériques des numéros JSON doivent être respectées. Pour le HASH, le champ doit contenir le texte ASCII d'un nombre écrit au format standard pour les nombres fixes ou à virgule flottante. Quelle que soit la représentation dans la clé, ce champ est converti en un nombre à virgule flottante de 64 bits pour être stocké dans l'index. Les champs numériques peuvent être utilisés avec l'opérateur de recherche par plage. Comme les nombres sous-jacents sont stockés en virgule flottante avec ses limites de précision, les règles habituelles relatives aux comparaisons numériques pour les nombres à virgule flottante s'appliquent. + Les **champs de balises** contiennent zéro ou plusieurs valeurs de balise codées sous la forme d'une seule chaîne UTF-8. La chaîne est analysée en valeurs de balise à l'aide d'un caractère séparateur (la valeur par défaut est une virgule mais peut être remplacée), les espaces blancs de début et de fin étant supprimés. Un seul champ de balise peut contenir autant de valeurs de balise que vous le souhaitez. Les champs de balises peuvent être utilisés pour filtrer les requêtes relatives à l'équivalence des valeurs de balises par une comparaison entre majuscules et minuscules. + Les **champs de texte** contiennent un blob d'octets qui n'ont pas besoin d'être conformes à la norme UTF-8. Les champs de texte peuvent être utilisés pour décorer les résultats des requêtes avec des valeurs pertinentes pour l'application. Par exemple, une URL ou le contenu d'un document, etc. + Les **champs vectoriels** contiennent un vecteur de nombres, également appelé incorporation. Les champs vectoriels prennent en charge la recherche du plus proche voisin (KNN) de vecteurs de taille fixe à l'aide d'un algorithme et d'une métrique de distance spécifiés. Pour les index HASH, le champ doit contenir le vecteur entier codé au format binaire (*little-endian* IEEE 754). Pour les clés JSON, le chemin doit faire référence à un tableau de taille correcte rempli de nombres. Notez que lorsqu'un tableau JSON est utilisé comme champ vectoriel, la représentation interne du tableau dans la clé JSON est convertie dans le format requis par l'algorithme sélectionné, ce qui réduit la consommation de mémoire et la précision. Les opérations de lecture ultérieures à l'aide des commandes JSON produiront la valeur de précision réduite. ## Algorithmes d'index vectoriel Deux algorithmes d'index vectoriel sont fournis : + **Plat** — L'algorithme Flat est un traitement linéaire par force brute de chaque vecteur de l'indice, fournissant des réponses exactes dans les limites de précision des calculs de distance. En raison du traitement linéaire de l'indice, les temps d'exécution de cet algorithme peuvent être très élevés pour les grands indices. + **HNSW (Hierarchical Navigable Small Worlds)** — L'algorithme HNSW est une alternative qui fournit une approximation de la bonne réponse en échange de temps d'exécution nettement plus courts. L'algorithme est contrôlé par trois paramètres`M`, `EF_CONSTRUCTION` et`EF_RUNTIME`. Les deux premiers paramètres sont spécifiés au moment de la création de l'index et ne peuvent pas être modifiés. Le `EF_RUNTIME` paramètre possède une valeur par défaut qui est spécifiée lors de la création de l'index, mais qui peut ensuite être remplacée lors de n'importe quelle opération de requête individuelle. Ces trois paramètres interagissent pour équilibrer la consommation de mémoire et de processeur lors des opérations d'ingestion et de requête, ainsi que pour contrôler la qualité de l'approximation d'une recherche KNN exacte (connue sous le nom de ratio de rappel). Les deux algorithmes de recherche vectorielle (Flat et HNSW) prennent en charge un `INITIAL_CAP` paramètre facultatif. Lorsqu'il est spécifié, ce paramètre préalloue de la mémoire aux index, ce qui permet de réduire la charge de gestion de la mémoire et d'augmenter les taux d'ingestion de vecteurs. Les algorithmes de recherche vectorielle tels que HNSW peuvent ne pas gérer efficacement la suppression ou le remplacement de vecteurs précédemment insérés. L'utilisation de ces opérations peut entraîner une consommation excessive de mémoire d'index et une and/or dégradation de la qualité du rappel. La réindexation est une méthode permettant de rétablir un rappel optimal de l'utilisation and/or de la mémoire. ## Expression de requête de recherche vectorielle Les commandes [FT.SEARCH](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.search.html) et [FT.AGGREGATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.aggregate.html) nécessitent une expression de requête. Cette expression est un paramètre de chaîne unique composé d'un ou de plusieurs opérateurs. Chaque opérateur utilise un champ de l'index pour identifier un sous-ensemble des clés de l'index. Plusieurs opérateurs peuvent être combinés à l'aide de combineurs booléens ainsi que de parenthèses pour améliorer ou restreindre davantage le jeu de clés collecté (ou le jeu de résultats). ### Caractère générique L'opérateur générique, l'astérisque (« \$1 »), correspond à toutes les clés de l'index. ### Plage numérique La syntaxe de l'opérateur de plage numérique est la suivante : ``` ::= '@' ':' '[' ']' ::= | '(' ::= | | | 'Inf' | '-Inf' | '+Inf' ``` Le < numeric-field-name > doit être un champ de type déclaré`NUMERIC`. Par défaut, la borne est inclusive, mais une parenthèse ouverte initiale ['('] peut être utilisée pour rendre une borne exclusive. La recherche par plage peut être convertie en une comparaison relationnelle unique (<, <=, >, >=) en utilisant `Inf` `+Inf` ou `-Inf` comme l'une des limites. Quel que soit le format numérique spécifié (entier, virgule fixe, virgule flottante, infini), le nombre est converti en virgule flottante de 64 bits pour effectuer des comparaisons, réduisant ainsi la précision en conséquence. **Example Exemples** ``` @numeric-field:[0 10] // 0 <= <= 10 @numeric-field:[(0 10] // 0 < <= 10 @numeric-field:[0 (10] // 0 <= < 10 @numeric-field:[(0 (10] // 0 < < 10 @numeric-field:[1.5 (Inf] // 1.5 <= value ``` ### Tag : comparer La syntaxe de l'opérateur de comparaison de balises est la suivante : ``` ::= '@' ':' '{' [ '|' ]* '}' ``` Si l'une des balises de l'opérateur correspond à l'une des balises du champ de balise de l'enregistrement, l'enregistrement est inclus dans le jeu de résultats. Le champ conçu par le `` doit être un champ de l'index déclaré avec type`TAG`. Voici des exemples de comparaison de balises : ``` @tag-field:{ atag } @tag-field: { tag1 | tag2 } ``` ### Combinaisons booléennes Les ensembles de résultats d'un opérateur numérique ou d'un opérateur de balise peuvent être combinés à l'aide de la logique booléenne : and/or. Parentheses can be used to group operators and/or modifiez l'ordre d'évaluation. La syntaxe des opérateurs de logique booléenne est la suivante : ``` ::= | '|' | '(' ')' ::= | ::= | | '*' ``` Plusieurs termes combinés dans une phrase sont « et ». Les phrases multiples combinées avec le tube (« \$1 ») sont de type « ou ». ### Recherche vectorielle Les index vectoriels prennent en charge deux méthodes de recherche différentes : le voisin le plus proche et le range. Une recherche dans le plus proche voisin permet de localiser un certain nombre, K, des vecteurs de l'index les plus proches du vecteur (de référence) fourni. C'est ce que l'on appelle communément KNN pour « K » voisins les plus proches. La syntaxe d'une recherche KNN est la suivante : ``` ::= '=>[KNN' '@' '$' ']' ::= [ 'EF_RUNTIME' ] [ 'AS' ] ``` Une recherche KNN vectorielle n'est appliquée qu'aux vecteurs qui répondent aux critères, `` qui peuvent être n'importe quelle combinaison des opérateurs définis ci-dessus : caractères génériques, recherche par plage, recherche par balises, combinaisons and/or booléennes de ces deux types de combinaisons. + ``est un entier spécifiant le nombre de vecteurs les plus proches voisins à renvoyer. + ``doit spécifier un champ de type déclaré`VECTOR`. + ``le champ indique l'une des entrées de la `PARAM` table de la `FT.AGGREGATE` commande `FT.SEARCH` ou. Ce paramètre est la valeur du vecteur de référence pour les calculs de distance. La valeur du vecteur est codée dans la `PARAM` valeur au format binaire *IEEE 754 little-endian* (même encodé que pour un champ vectoriel HASH) + Pour les index vectoriels de type HNSW, la `EF_RUNTIME` clause facultative peut être utilisée pour remplacer la valeur par défaut du `EF_RUNTIME` paramètre établi lors de la création de l'index. + L'option `` fournit un nom de champ pour le jeu de résultats afin qu'il contienne la distance calculée entre le vecteur de référence et la clé localisée. Une recherche par plage permet de localiser tous les vecteurs situés à une distance (rayon) spécifiée par rapport à un vecteur de référence. La syntaxe d'une recherche par plage est la suivante : ``` ::= ‘@’ ‘:’ ‘[’ ‘VECTOR_RANGE’ ( | ‘$’ ) $ ‘]’ [ ‘=’ ‘>’ ‘{’ ‘}’ ] ::= | , ::= [ ‘$yield_distance_as’ ‘:’ ] [ ‘$epsilon’ ‘:’ ] ``` Où : + ``est le nom du champ vectoriel à rechercher. + ` or $`est la limite de distance numérique pour la recherche. + `$ `est le nom du paramètre qui contient le vecteur de référence. La valeur du vecteur est codée dans la valeur PARAM au format binaire IEEE 754 little-endian (même encodage que pour un champ vectoriel HASH) + L'option `` fournit un nom de champ pour le jeu de résultats afin qu'il contienne la distance calculée entre le vecteur de référence et chaque clé. + L'option permet de ` ` contrôler les limites de l'opération de recherche, les vecteurs situés à distance ` * (1.0 + ) ` sont parcourus à la recherche de résultats candidats. La valeur par défaut est 0,01. ## commande INFO La recherche vectorielle complète les commandes Valkey et Redis OSS [INFO](https://valkey.io/commands/info/) avec plusieurs sections supplémentaires de statistiques et de compteurs. Une demande de récupération de la section `SEARCH` permet de récupérer toutes les sections suivantes : ### `search_memory` Section | Nom | Description | | --- | --- | | search\$1used\$1memory\$1bytes | Nombre d'octets de mémoire consommés dans toutes les structures de données de recherche | | search\$1used\$1memory\$1human | Version lisible par l'homme de ce qui précède | ### `search_index_stats` Section | Nom | Description | | --- | --- | | numéro\$1de\$1index\$1de\$1recherche | Nombre d'index créés | | search\$1num\$1fulltext\$1indexes | Nombre de champs non vectoriels dans tous les index | | search\$1num\$1vector\$1indexes | Nombre de champs vectoriels dans tous les index | | search\$1num\$1hash\$1indexes | Nombre d'index sur les clés de type HASH | | search\$1num\$1json\$1indexes | Nombre d'index sur les clés de type JSON | | search\$1total\$1indexed\$1keys | Nombre total de clés dans tous les index | | search\$1total\$1indexed\$1vector | Nombre total de vecteurs dans tous les index | | search\$1total\$1indexed\$1hash\$1keys | Nombre total de clés de type HASH dans tous les index | | search\$1total\$1indexed\$1json\$1keys | Nombre total de clés de type JSON dans tous les index | | search\$1total\$1index\$1size | Octets utilisés par tous les index | | search\$1total\$1fulltext\$1index\$1size | Octets utilisés par les structures d'index non vectorielles | | search\$1total\$1vector\$1index\$1size | Octets utilisés par les structures d'index vectoriels | | search\$1max\$1index\$1lag\$1ms | Délai d'ingestion lors de la dernière mise à jour du lot d'ingestion | ### `search_ingestion` Section | Nom | Description | | --- | --- | | search\$1background\$1indexing\$1status | État de l'ingestion. NO\$1ACTIVITYsignifie inactif. D'autres valeurs indiquent que des clés sont en cours d'ingestion. | | search\$1ingestion\$1paused | Sauf lors du redémarrage, cela doit toujours être « non ». | ### `search_backfill` Section **Note** Certains des champs documentés dans cette section ne sont visibles que lorsqu'un remblayage est en cours. | Nom | Description | | --- | --- | | search\$1num\$1active\$1backfills | Nombre d'activités de remblayage en cours | | search\$1backfills\$1paused | Sauf en cas de manque de mémoire, cela doit toujours être « non ». | | search\$1current\$1backfill\$1progress\$1percentage | % d'achèvement (0-100) du remblai actuel | ### `search_query` Section | Nom | Description | | --- | --- | | search\$1num\$1active\$1queries | Nombre de commandes en cours FT.SEARCH et FT.AGGREGATE commandes en cours | ## Sécurité de la recherche vectorielle Les mécanismes de sécurité [ACL (Access Control Lists)](https://valkey.io/topics/acl/) pour l'accès aux commandes et aux données sont étendus pour contrôler la fonction de recherche. Le contrôle ACL des commandes de recherche individuelles est entièrement pris en charge. Une nouvelle catégorie ACL`@search`,, est fournie et de nombreuses catégories existantes (`@fast`,, `@read``@write`, etc.) sont mises à jour pour inclure les nouvelles commandes. Les commandes de recherche ne modifient pas les données clés, ce qui signifie que le mécanisme ACL existant pour l'accès en écriture est préservé. Les règles d'accès pour les opérations HASH et JSON ne sont pas modifiées par la présence d'un index ; le contrôle d'accès normal au niveau des clés est toujours appliqué à ces commandes. L'accès aux commandes de recherche avec index est également contrôlé via ACL. Les contrôles d'accès sont effectués au niveau de l'index complet, et non au niveau de chaque clé. Cela signifie que l'accès à un index n'est accordé à un utilisateur que s'il est autorisé à accéder à toutes les clés possibles dans la liste des préfixes d'espace-touches de cet index. En d'autres termes, le contenu réel d'un index ne contrôle pas l'accès. C'est plutôt le contenu théorique d'un index tel que défini par la liste de préfixes qui est utilisé pour le contrôle de sécurité. Il peut être facile de créer une situation dans laquelle un utilisateur dispose d'un accès en lecture et en and/or écriture à une clé mais ne peut pas accéder à un index contenant cette clé. Notez que seul l'accès en lecture au keyspace est requis pour créer ou utiliser un index ; la présence ou l'absence d'accès en écriture n'est pas prise en compte. Pour plus d'informations sur l'utilisation ACLs de MemoryDB, voir [Authentification des utilisateurs avec des listes de contrôle d'accès](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html) (). ACLs # Cas d’utilisation Vous trouverez ci-dessous des cas d'utilisation de la recherche vectorielle. ## Génération augmentée de récupération (RAG) Retrieval Augmented Generation (RAG) utilise la recherche vectorielle pour récupérer des passages pertinents à partir d'un vaste corpus de données afin d'enrichir un grand modèle de langage (LLM). Plus précisément, un encodeur intègre le contexte d'entrée et la requête de recherche dans des vecteurs, puis utilise une recherche approximative du plus proche voisin pour trouver des passages sémantiquement similaires. Ces passages récupérés sont concaténés avec le contexte d'origine pour fournir des informations pertinentes supplémentaires au LLM afin de renvoyer une réponse plus précise à l'utilisateur. ![\[Graphique du flux de génération augmentée de récupération\]](http://docs.aws.amazon.com/fr_fr/memorydb/latest/devguide/images/RAG.png) ## Cache sémantique durable La mise en cache sémantique est un processus visant à réduire les coûts de calcul en stockant les résultats précédents du FM. En réutilisant les résultats précédents issus d'inférences antérieures au lieu de les recalculer, la mise en cache sémantique réduit la quantité de calcul requise lors de l'inférence via le. FMs MemoryDB permet une mise en cache sémantique durable, ce qui évite la perte de données de vos inférences passées. Cela permet à vos applications d'IA générative de répondre en quelques millisecondes à un chiffre avec des réponses à des questions sémantiquement similaires antérieures, tout en réduisant les coûts en évitant les inférences LLM inutiles. ![\[Schéma de flux de travail illustrant le processus du modèle de base.\]](http://docs.aws.amazon.com/fr_fr/memorydb/latest/devguide/images/FM.png) + Résultat de **recherche sémantique** : si la requête d'un client est sémantiquement similaire sur la base d'un score de similarité défini à une question précédente, la mémoire tampon FM (MemoryDB) renverra la réponse à la question précédente à l'étape 4 et n'appellera pas le FM pendant les étapes 3. Cela permettra d'éviter la latence du modèle de base (FM) et les coûts encourus, offrant ainsi une expérience plus rapide au client. + Erreur **de recherche sémantique** : si la requête d'un client n'est pas sémantiquement similaire, sur la base d'un score de similarité défini, à une requête précédente, le client appellera le FM pour lui fournir une réponse à l'étape 3a. La réponse générée par le FM sera ensuite stockée sous forme de vecteur dans MemoryDB pour les futures requêtes (étape 3b) afin de minimiser les coûts du FM sur des questions sémantiquement similaires. Dans ce flux, l'étape 4 ne serait pas invoquée car il n'y avait aucune question sémantiquement similaire pour la requête d'origine. ## Détection des fraudes La détection des fraudes, une forme de détection des anomalies, représente les transactions valides sous forme de vecteurs tout en comparant les représentations vectorielles des nouvelles transactions nettes. Une fraude est détectée lorsque ces nouvelles transactions nettes présentent une faible similitude avec les vecteurs représentant les données transactionnelles valides. Cela permet de détecter la fraude en modélisant un comportement normal, plutôt que d'essayer de prévoir tous les cas de fraude possibles. MemoryDB permet aux entreprises de le faire en période de débit élevé, avec un minimum de faux positifs et une latence d'un chiffre en millisecondes. ![\[Schéma de flux de travail illustrant le processus de détection des fraudes.\]](http://docs.aws.amazon.com/fr_fr/memorydb/latest/devguide/images/fraud-detection.png) ## Autres cas d’utilisation + **Les moteurs de recommandation** peuvent trouver des produits ou des contenus similaires aux utilisateurs en représentant les éléments sous forme de vecteurs. Les vecteurs sont créés en analysant les attributs et les modèles. Sur la base des modèles et des attributs des utilisateurs, de nouveaux éléments invisibles peuvent être recommandés aux utilisateurs en trouvant les vecteurs les plus similaires déjà notés positivement et alignés sur l'utilisateur. + **Les moteurs de recherche de documents** représentent les documents texte sous forme de vecteurs denses de nombres, capturant le sens sémantique. Au moment de la recherche, le moteur convertit une requête de recherche en vecteur et trouve les documents contenant les vecteurs les plus similaires à la requête en utilisant une recherche approximative du plus proche voisin. Cette approche de similarité vectorielle permet de faire correspondre les documents en fonction de leur signification plutôt que de simplement faire correspondre des mots clés. # Caractéristiques et limites de la recherche vectorielle ## Disponibilité de la recherche vectorielle La configuration MemoryDB activée par la recherche vectorielle est prise en charge sur les types de nœuds R6g, R7g et T4g et est disponible dans toutes les régions où MemoryDB est disponible. AWS Les clusters existants ne peuvent pas être modifiés pour permettre la recherche. Toutefois, les clusters activés pour la recherche peuvent être créés à partir de clichés de clusters dont la recherche est désactivée. ## Restrictions paramétriques Le tableau suivant indique les limites applicables aux différents éléments de recherche vectorielle : | Élément | Valeur maximale | | --- | --- | | Nombre de dimensions dans un vecteur | 32768 | | Nombre d'index pouvant être créés | 10 | | Nombre de champs dans un index | 50 | | Clause FT.SEARCH et FT.AGGREGATE TIMEOUT (millisecondes) | 10 000 | | Nombre d'étapes du pipeline dans la commande FT.AGGREGATE | 32 | | Nombre de champs dans la clause FT.AGGREGATE LOAD | 1 024 | | Nombre de champs dans la clause FT.AGGREGATE GROUPBY | 16 | | Nombre de champs dans la clause FT.AGGREGATE SORTBY | 16 | | Nombre de paramètres dans la clause FT.AGGREGATE PARAM | 32 | | Paramètre HNSW M | 512 | | Paramètre HNSW EF\$1CONSTRUCTION | 4096 | | Paramètre HNSW EF\$1RUNTIME | 4096 | ## Limites d'échelle La recherche vectorielle pour MemoryDB est actuellement limitée à une seule partition et la mise à l'échelle horizontale n'est pas prise en charge. La recherche vectorielle prend en charge le dimensionnement vertical et le dimensionnement des répliques. ## Restrictions opérationnelles **Persistance de l'indice et remblayage** La fonction de recherche vectorielle conserve la définition des index et le contenu de l'index. Cela signifie que lors de toute demande ou événement opérationnel entraînant le démarrage ou le redémarrage d'un nœud, la définition et le contenu de l'index sont restaurés à partir du dernier instantané et toutes les transactions en attente sont lues dans le journal des transactions multi-AZ. Aucune action de l'utilisateur n'est requise pour lancer cette opération. La reconstruction est effectuée sous forme d'opération de remblayage dès que les données sont restaurées. Cela équivaut fonctionnellement à l'exécution automatique par le système d'une commande [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) pour chaque index défini. Notez que le nœud devient disponible pour les opérations des applications dès que les données sont restaurées, mais probablement avant la fin du remplissage des index, ce qui signifie que les remplissages redeviendront visibles pour les applications. Par exemple, les commandes de recherche utilisant des index de remblayage peuvent être rejetées. Pour plus d'informations sur le remblayage, voir[Aperçu de la recherche vectorielleLes index et le keyspace Valkey et Redis OSS](vector-search-overview.md#vector-search-indexes-keyspaces). L'achèvement du remplissage de l'index n'est pas synchronisé entre un index principal et un réplica. Ce manque de synchronisation peut devenir visible de manière inattendue pour les applications. Il est donc recommandé aux applications de vérifier que le remblayage est terminé sur les primaires et sur toutes les répliques avant de lancer des opérations de recherche. ## Instantané import/export et migration en direct La présence d'index de recherche dans un fichier RDB limite la transportabilité compatible de ces données. Le format des index vectoriels défini par la fonctionnalité de recherche vectorielle de MemoryDB n'est compris que par un autre cluster activé par les vecteurs de MemoryDB. De plus, les fichiers RDB des clusters de prévisualisation peuvent être importés par la version GA des clusters MemoryDB, qui reconstruira le contenu de l'index lors du chargement du fichier RDB. Toutefois, les fichiers RDB qui ne contiennent pas d'index ne sont pas restreints de cette manière. Ainsi, les données d'un cluster de prévisualisation peuvent être exportées vers des clusters non prévisualisés en supprimant les index avant l'exportation. ## Consommation de mémoire La consommation de mémoire est basée sur le nombre de vecteurs, le nombre de dimensions, la valeur M et la quantité de données non vectorielles, telles que les métadonnées associées au vecteur ou d'autres données stockées dans l'instance. La mémoire totale requise est une combinaison de l'espace nécessaire pour les données vectorielles réelles et de l'espace requis pour les indices vectoriels. L'espace requis pour les données vectorielles est calculé en mesurant la capacité réelle requise pour stocker les vecteurs dans les structures de données HASH ou JSON et le surdébit jusqu'aux tranches de mémoire les plus proches, pour des allocations de mémoire optimales. Chacun des index vectoriels utilise des références aux données vectorielles stockées dans ces structures de données et utilise des optimisations de mémoire efficaces pour supprimer toute copie dupliquée des données vectorielles dans l'index. Le nombre de vecteurs dépend de la façon dont vous décidez de représenter vos données sous forme de vecteurs. Par exemple, vous pouvez choisir de représenter un seul document en plusieurs parties, chaque partie représentant un vecteur. Vous pouvez également choisir de représenter l'ensemble du document sous la forme d'un vecteur unique. Le nombre de dimensions de vos vecteurs dépend du modèle d'intégration que vous choisissez. Par exemple, si vous choisissez d'utiliser le modèle d'intégration [AWS Titan](https://aws.amazon.com/bedrock/titan/), le nombre de dimensions sera de 1536. Le paramètre M représente le nombre de liens bidirectionnels créés pour chaque nouvel élément lors de la construction de l'index. MemoryDB définit cette valeur par défaut sur 16 ; vous pouvez toutefois la remplacer. Un paramètre M élevé fonctionne mieux pour des exigences de rappel and/or élevées en dimensionnalité, tandis que des paramètres M faibles fonctionnent mieux pour des exigences de rappel and/or faibles en dimensionnalité. La valeur M augmente la consommation de mémoire à mesure que l'indice augmente, ce qui augmente la consommation de mémoire. Dans le cadre de l'expérience console, MemoryDB permet de choisir facilement le type d'instance approprié en fonction des caractéristiques de votre charge de travail vectorielle après avoir coché la case Activer la recherche vectorielle dans les paramètres du cluster. ![\[Paramètres du cluster de recherche vectorielle dans la AWS console.\]](http://docs.aws.amazon.com/fr_fr/memorydb/latest/devguide/images/vector-search-cluster-settings-console.png) **Exemple de charge de travail** Un client souhaite créer un moteur de recherche sémantique basé sur ses documents financiers internes. Ils détiennent actuellement 1 million de documents financiers qui sont découpés en 10 vecteurs par document à l'aide du modèle d'intégration Titan de 1536 dimensions et ne contiennent aucune donnée non vectorielle. Le client décide d'utiliser la valeur par défaut de 16 comme paramètre M. + Vecteurs : 1 M\$1 10 morceaux = 10 millions de vecteurs + Dimensioni : 1536 + Données non vectorielles (Go) : 0 Go + Paramètre M : 16 Avec ces données, le client peut cliquer sur le bouton Utiliser un calculateur vectoriel dans la console pour obtenir un type d'instance recommandé en fonction de ses paramètres : ![\[Le type de nœud recommandé par le calculateur vectoriel, en fonction de l'entrée dans le calculateur.\]](http://docs.aws.amazon.com/fr_fr/memorydb/latest/devguide/images/vector-calc1.png) ![\[Le calculateur vectoriel avec les valeurs saisies.\]](http://docs.aws.amazon.com/fr_fr/memorydb/latest/devguide/images/vector-calc2.png) Dans cet exemple, le calculateur vectoriel recherchera le plus petit [type de nœud MemoryDB r7g](https://aws.amazon.com/memorydb/pricing/) capable de contenir la mémoire requise pour stocker les vecteurs en fonction des paramètres fournis. Notez qu'il s'agit d'une approximation et que vous devez tester le type d'instance pour vous assurer qu'il répond à vos besoins. Sur la base de la méthode de calcul ci-dessus et des paramètres de l'échantillon de charge de travail, ces données vectorielles nécessiteraient 104,9 Go pour stocker les données et un index unique. Dans ce cas, le type d'`db.r7g.4xlarge`instance est recommandé car il dispose de 105,81 Go de mémoire utilisable. Le type de nœud le plus petit suivant serait trop petit pour supporter la charge de travail vectorielle. Comme chacun des index vectoriels utilise des références aux données vectorielles stockées et ne crée pas de copies supplémentaires des données vectorielles dans l'index vectoriel, les index consommeront également relativement moins d'espace. Cela est très utile pour créer plusieurs index, ainsi que dans les situations où des parties des données vectorielles ont été supprimées et où la reconstruction du graphe HNSW permettrait de créer des connexions de nœuds optimales pour des résultats de recherche vectorielle de haute qualité. ## Mémoire insuffisante pendant le remblayage À l'instar des opérations d'écriture de Valkey et Redis OSS, le remplissage d'index est soumis à des limitations. out-of-memory Si la mémoire du moteur est pleine alors qu'un remblayage est en cours, tous les remplissages sont interrompus. Si de la mémoire devient disponible, le processus de remblayage est repris. Il est également possible de supprimer et d'indexer lorsque le remblayage est suspendu en raison d'un manque de mémoire. ## Transactions Les commandes`FT.CREATE`,`FT.DROPINDEX`, `FT.ALIASADD``FT.ALIASDEL`, et `FT.ALIASUPDATE` ne peuvent pas être exécutées dans un contexte transactionnel, c'est-à-dire pas dans un MULTI/EXEC bloc ou dans un script LUA ou FUNCTION. # Création d'un cluster activé pour la recherche vectorielle Vous pouvez créer un cluster activé pour la recherche vectorielle en utilisant le AWS Management Console, ou le AWS Command Line Interface. Selon l'approche, les considérations relatives à l'activation de la recherche vectorielle doivent être prises en compte. ## À l'aide du AWS Management Console Pour créer un cluster activé pour la recherche vectorielle dans la console, vous devez activer la recherche vectorielle dans les paramètres du **cluster**. La recherche vectorielle est disponible pour MemoryDB version 7.1 dans une configuration de partition unique. ![\[L'affichage des paramètres du cluster avec l'option « Activer la recherche vectorielle » cochée fournit des informations sur la version spécifique et le support de configuration.\]](http://docs.aws.amazon.com/fr_fr/memorydb/latest/devguide/images/vs-2.png) Pour plus d'informations sur l'utilisation de la recherche vectorielle avec le AWS Management Console, voir[Création d'un cluster (console)](getting-started.md#clusters.createclusters.viewdetails.cluster). ## À l'aide du AWS Command Line Interface Pour créer un cluster MemoryDB compatible avec la recherche vectorielle, vous pouvez utiliser la commande MemoryDB [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-cluster.html) en transmettant un groupe `default.memorydb-redis7.search` de paramètres immuable pour activer les fonctionnalités de recherche vectorielle. ``` aws memorydb create-cluster \ --cluster-name \ --node-type \ --engine redis \ --engine-version 7.1 \ --num-shards 1 \ --acl-name \ --parameter-group-name default.memorydb-redis7.search ``` Vous pouvez éventuellement créer un nouveau groupe de paramètres pour activer la recherche vectorielle, comme illustré dans l'exemple suivant. Pour en savoir plus sur les groupes de paramètres, [cliquez ici](parametergroups.management.md). ``` aws memorydb create-parameter-group \ --parameter-group-name my-search-parameter-group \ --family memorydb_redis7 ``` Ensuite, mettez à jour le paramètre activé pour la recherche de paramètres sur Oui dans le groupe de paramètres nouvellement créé. ``` aws memorydb update-parameter-group \ --parameter-group-name my-search-parameter-group \ --parameter-name-values "ParameterName=search-enabled,ParameterValue=yes" ``` Vous pouvez désormais utiliser ce groupe de paramètres personnalisé au lieu du groupe de paramètres par défaut pour activer la recherche vectorielle sur vos clusters MemoryDB. # Commandes de recherche vectorielle Voici une liste des commandes prises en charge pour la recherche vectorielle. **Topics** + [FT.CREATE](vector-search-commands-ft.create.md) + [FT.SEARCH](vector-search-commands-ft.search.md) + [AGRÉGAT DE PIEDS](vector-search-commands-ft.aggregate.md) + [FT.DROPINDEX](vector-search-commands-ft.dropindex.md) + [FT.INFO](vector-search-commands-ft.info.md) + [PIEDS. \$1LISTE](vector-search-commands-ft.list.md) + [FT.ALIASADD](vector-search-commands-ft.aliasadd.md) + [FT. ALIASDEL](vector-search-commands-ft.aliasdel.md) + [MISE À JOUR DE FT.ALIAS](vector-search-commands-ft.aliasupdate.md) + [PIEDS. \$1ALIASLIST](vector-search-commands-ft.aliaslist.md) + [FT.PROFILE](vector-search-commands-ft.profile.md) + [FT.EXPLAIN](vector-search-commands-ft.explain.md) + [FT.EXPLAINCLI](vector-search-commands-ft.explain-cli.md) # FT.CREATE Crée un index et lance un remblayage de cet index. Pour plus d'informations, voir [Vue d'ensemble de la recherche vectorielle](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html) pour plus de détails sur la construction d'index. **Syntaxe** ``` FT.CREATE ON HASH | JSON [PREFIX [...]] SCHEMA ( [AS ] NUMERIC | TAG [SEPARATOR ] [CASESENSITIVE] | TEXT | VECTOR [HNSW|FLAT] [ ]) )+ ``` **Schema** (Schéma) + Identifiant du champ : + Pour les clés de hachage, l'identifiant du champ est un nom de champ. + Pour les clés JSON, l'identifiant du champ est un chemin JSON. Pour de plus amples informations, veuillez consulter [Types de champs d'index](vector-search-overview.md#vector-search-index-field-types). + Types de champs : + TAG : Pour plus d'informations, voir [Tags](https://redis.io/docs/interact/search-and-query/advanced-concepts/tags/). + NUMÉRIQUE : Le champ contient un nombre. + TEXTE : Le champ contient n'importe quel blob de données. + VECTEUR : champ vectoriel qui permet la recherche vectorielle. + Algorithme : il peut être HNSW (Hierarchical Navigable Small World) ou FLAT (force brute). + `attr_count`— le nombre d'attributs qui seront transmis en tant que configuration de l'algorithme, y compris les noms et les valeurs. + `{attribute_name} {attribute_value}`— key/value paires spécifiques à l'algorithme qui définissent la configuration de l'index. Pour l'algorithme FLAT, les attributs sont les suivants : Obligatoire : + DIM — Nombre de dimensions du vecteur. + DISTANCE\$1METRIC — Peut être l'un des [L2 \$1 IP \$1 COSINE]. + TYPE — Type de vecteur. Le seul type pris en charge est`FLOAT32`. Facultatif : + INITIAL\$1CAP — La capacité vectorielle initiale de l'index affecte la taille d'allocation de mémoire de l'index. Pour l'algorithme HNSW, les attributs sont les suivants : Obligatoire : + TYPE — Type de vecteur. Le seul type pris en charge est`FLOAT32`. + DIM — Dimension du vecteur, spécifiée sous la forme d'un entier positif. Maximum : 32 768 + DISTANCE\$1METRIC — Peut être l'un des [L2 \$1 IP \$1 COSINE]. Facultatif : + INITIAL\$1CAP — La capacité vectorielle initiale de l'index affecte la taille d'allocation de mémoire de l'index. La valeur par défaut est 1024. + M — Nombre maximum d'arêtes sortantes autorisées pour chaque nœud du graphe dans chaque couche. Sur la couche zéro, le nombre maximal d'arêtes sortantes sera de 2 millions. La valeur par défaut est 16. Le maximum est 512. + EF\$1CONSTRUCTION — contrôle le nombre de vecteurs examinés lors de la construction de l'indice. Des valeurs plus élevées pour ce paramètre amélioreront le taux de rappel au détriment de délais de création d'index plus longs. La valeur par défaut est 200. La valeur maximale est 4096. + EF\$1RUNTIME — contrôle le nombre de vecteurs examinés lors des opérations de requête. Des valeurs plus élevées pour ce paramètre peuvent améliorer le rappel au détriment de la durée des requêtes. La valeur de ce paramètre peut être modifiée au cas par cas. Valeur par défaut : 10. La valeur maximale est 4096. **Retour** Renvoie un message OK ou une réponse d'erreur sous forme de chaîne simple. **Exemples** **Note** L'exemple suivant utilise des arguments natifs de [valkey-cli](https://valkey.io/topics/cli/), tels que le déguillement et le déséchappement des données, avant de les envoyer à Valkey ou Redis OSS. Pour utiliser d'autres clients utilisant d'autres langages de programmation (Python, Ruby, C\$1, etc.), suivez les règles de gestion de ces environnements pour traiter les chaînes et les données binaires. Pour plus d'informations sur les clients pris en charge, voir [Outils sur lesquels s'appuyer AWS](https://aws.amazon.com/developer/tools/) **Example 1 : Créez des index** Création d'un index pour les vecteurs de taille 2 ``` FT.CREATE hash_idx1 ON HASH PREFIX 1 hash: SCHEMA vec AS VEC VECTOR HNSW 6 DIM 2 TYPE FLOAT32 DISTANCE_METRIC L2 OK ``` Créez un index JSON en 6 dimensions à l'aide de l'algorithme HNSW : ``` FT.CREATE json_idx1 ON JSON PREFIX 1 json: SCHEMA $.vec AS VEC VECTOR HNSW 6 DIM 6 TYPE FLOAT32 DISTANCE_METRIC L2 OK ``` **Example Exemple 2 : renseigner certaines données** Les commandes suivantes sont formatées de manière à pouvoir être exécutées en tant qu'arguments du programme de terminal redis-cli. Les développeurs utilisant des clients utilisant un langage de programmation (tels que Python, Ruby, C\$1, etc.) devront suivre les règles de gestion de leur environnement pour traiter les chaînes et les données binaires. Création de certaines données de hachage et de json : ``` HSET hash:0 vec "\x00\x00\x00\x00\x00\x00\x00\x00" HSET hash:1 vec "\x00\x00\x00\x00\x00\x00\x80\xbf" JSON.SET json:0 . '{"vec":[1,2,3,4,5,6]}' JSON.SET json:1 . '{"vec":[10,20,30,40,50,60]}' JSON.SET json:2 . '{"vec":[1.1,1.2,1.3,1.4,1.5,1.6]}' ``` Notez ce qui suit : + Les clés du hachage et des données JSON ont les préfixes de leurs définitions d'index. + Les vecteurs se trouvent aux chemins appropriés des définitions d'index. + Les vecteurs de hachage sont saisis sous forme de données hexadécimales tandis que les données JSON sont entrées sous forme de nombres. + Les vecteurs ont les longueurs appropriées, les entrées du vecteur de hachage bidimensionnel contiennent deux flottants de données hexadécimales, les entrées vectorielles json à six dimensions comportent six nombres. **Example Exemple 3 : Supprimer et recréer un index** ``` FT.DROPINDEX json_idx1 OK FT.CREATE json_idx1 ON JSON PREFIX 1 json: SCHEMA $.vec AS VEC VECTOR FLAT 6 DIM 6 TYPE FLOAT32 DISTANCE_METRIC L2 OK ``` Notez que le nouvel index JSON utilise l'`FLAT`algorithme au lieu de l'`HNSW`algorithme. Notez également qu'il réindexera les données JSON existantes : ``` FT.SEARCH json_idx1 "*=>[KNN 100 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 3 2) "json:2" 3) 1) "__VEC_score" 2) "11.11" 3) "$" 4) "[{\"vec\":[1.1, 1.2, 1.3, 1.4, 1.5, 1.6]}]" 4) "json:0" 5) 1) "__VEC_score" 2) "91" 3) "$" 4) "[{\"vec\":[1.0, 2.0, 3.0, 4.0, 5.0, 6.0]}]" 6) "json:1" 7) 1) "__VEC_score" 2) "9100" 3) "$" 4) "[{\"vec\":[10.0, 20.0, 30.0, 40.0, 50.0, 60.0]}]" ``` # FT.SEARCH Utilise l'expression de requête fournie pour localiser les clés dans un index. Une fois localisé, le and/or contenu du nombre de champs indexés dans ces clés peut être renvoyé. Pour plus d'informations, voir [Expression de requête de recherche vectorielle](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression). Pour créer des données à utiliser dans ces exemples, consultez la commande [FT.CREATE.](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) **Syntaxe** ``` FT.SEARCH [RETURN ( [AS ])+] [TIMEOUT timeout] [PARAMS [ ]] [LIMIT ] [COUNT] ``` + RETURN : Cette clause identifie les champs d'une clé qui sont renvoyés. La clause AS facultative de chaque champ remplace le nom du champ dans le résultat. Seuls les champs déclarés pour cet index peuvent être spécifiés. + LIMITE : Cette clause fournit une fonctionnalité de pagination dans la mesure où seules les clés correspondant aux valeurs de décalage et de comptage sont renvoyées. Si cette clause est omise, la valeur par défaut est « LIMIT 0 10 », c'est-à-dire que seul un maximum de 10 clés seront renvoyées. + PARAMS : deux fois le nombre de paires clé-valeur. Les key/value paires de paramètres peuvent être référencées depuis l'expression de requête. Pour plus d'informations, voir [Expression de requête de recherche vectorielle](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression). + COUNT : Cette clause supprime le renvoi du contenu des clés, seul le nombre de clés est renvoyé. Il s'agit d'un alias pour « LIMIT 0 0 ». **Retour** Renvoie un tableau ou une réponse d'erreur. + Si l'opération aboutit, elle renvoie un tableau. Le premier élément est le nombre total de clés correspondant à la requête. Les autres éléments sont des paires de nom de clé et de liste de champs. La liste de champs est un autre tableau comprenant des paires de nom de champ et de valeurs. + Si l'index est en cours de remplissage à nouveau, la commande renvoie immédiatement une réponse d'erreur. + Si le délai est dépassé, la commande renvoie une réponse d'erreur. **Exemple : effectuez des recherches** **Note** L'exemple suivant utilise des arguments natifs de [valkey-cli](https://valkey.io/topics/cli/), tels que le déguillement et le déséchappement des données, avant de les envoyer à Valkey ou Redis OSS. Pour utiliser d'autres clients utilisant d'autres langages de programmation (Python, Ruby, C\$1, etc.), suivez les règles de gestion de ces environnements pour traiter les chaînes et les données binaires. Pour plus d'informations sur les clients pris en charge, voir [Outils sur lesquels s'appuyer AWS](https://aws.amazon.com/developer/tools/) **Une recherche par hachage** ``` FT.SEARCH hash_idx1 "*=>[KNN 2 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 2 2) "hash:0" 3) 1) "__VEC_score" 2) "0" 3) "vec" 4) "\x00\x00\x00\x00\x00\x00\x00\x00" 4) "hash:1" 5) 1) "__VEC_score" 2) "1" 3) "vec" 4) "\x00\x00\x00\x00\x00\x00\x80\xbf" ``` Cela produit deux résultats, triés en fonction de leur score, qui est la distance par rapport au vecteur de requête (entrée sous forme hexadécimale). **Recherches JSON** ``` FT.SEARCH json_idx1 "*=>[KNN 2 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 2 2) "json:2" 3) 1) "__VEC_score" 2) "11.11" 3) "$" 4) "[{\"vec\":[1.1, 1.2, 1.3, 1.4, 1.5, 1.6]}]" 4) "json:0" 5) 1) "__VEC_score" 2) "91" 3) "$" 4) "[{\"vec\":[1.0, 2.0, 3.0, 4.0, 5.0, 6.0]}]" ``` Cela produit les deux résultats les plus proches, triés en fonction de leur score, et notez que les valeurs vectorielles JSON sont converties en valeurs flottantes et que le vecteur de requête est toujours des données vectorielles. Notez également que le `KNN` paramètre étant 2, il n'y a que deux résultats. Une valeur plus élevée renverra plus de résultats : ``` FT.SEARCH json_idx1 "*=>[KNN 100 @VEC $query_vec]" PARAMS 2 query_vec "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" DIALECT 2 1) (integer) 3 2) "json:2" 3) 1) "__VEC_score" 2) "11.11" 3) "$" 4) "[{\"vec\":[1.1, 1.2, 1.3, 1.4, 1.5, 1.6]}]" 4) "json:0" 5) 1) "__VEC_score" 2) "91" 3) "$" 4) "[{\"vec\":[1.0, 2.0, 3.0, 4.0, 5.0, 6.0]}]" 6) "json:1" 7) 1) "__VEC_score" 2) "9100" 3) "$" 4) "[{\"vec\":[10.0, 20.0, 30.0, 40.0, 50.0, 60.0]}]" ``` # AGRÉGAT DE PIEDS Il s'agit d'un sur-ensemble de la commande FT.SEARCH qui permet un traitement supplémentaire substantiel des clés sélectionnées par l'expression de requête. **Syntaxe** ``` FT.AGGREGATE index query [LOAD * | [count field [field ...]]] [TIMEOUT timeout] [PARAMS count name value [name value ...]] [FILTER expression] [LIMIT offset num] [GROUPBY count property [property ...] [REDUCE function count arg [arg ...] [AS name] [REDUCE function count arg [arg ...] [AS name] ...]] ...]] [SORTBY count [ property ASC | DESC [property ASC | DESC ...]] [MAX num]] [APPLY expression AS name] ``` + Les clauses FILTER, LIMIT, GROUPBY, SORTBY et APPLY peuvent être répétées plusieurs fois dans n'importe quel ordre et être librement mélangées. Ils sont appliqués dans l'ordre spécifié, la sortie d'une clause alimentant l'entrée de la clause suivante. + Dans la syntaxe ci-dessus, une « propriété » est soit un champ déclaré dans la commande [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) pour cet index, SOIT la sortie d'une clause APPLY ou d'une fonction REDUCE précédente. + La clause LOAD est limitée au chargement des champs déclarés dans l'index. « LOAD \$1 » chargera tous les champs déclarés dans l'index. + Les fonctions de réduction suivantes sont prises en charge : COUNT, COUNT\$1DISTINCTISH, SUM, MIN, MAX, AVG, STDDEV, QUANTILE, TOLIST, FIRST\$1VALUE et RANDOM\$1SAMPLE. Pour plus d'informations, voir [Agrégations](https://redis.io/docs/interact/search-and-query/search/aggregations/) + LIMITE : Conserve les enregistrements commençant à et se poursuivant jusqu'à, tous les autres enregistrements sont supprimés. + PARAMS : deux fois le nombre de paires clé-valeur. Les key/value paires de paramètres peuvent être référencées depuis l'expression de requête. **Retour** Renvoie un tableau ou une réponse d'erreur. + Si l'opération aboutit, elle renvoie un tableau. Le premier élément est un entier sans signification particulière (doit être ignoré). Les autres éléments sont les résultats de la dernière étape. Chaque élément est un tableau de paires de noms de champs et de valeurs. + Si l'index est en cours de remplissage à nouveau, la commande renvoie immédiatement une réponse d'erreur. + Si le délai est dépassé, la commande renvoie une réponse d'erreur. # FT.DROPINDEX Supprime un index. La définition de l'index et le contenu associé sont supprimés. Les clés ne sont pas affectées. **Syntaxe** ``` FT.DROPINDEX ``` **Retour** Renvoie un message OK sous forme de chaîne simple ou une réponse d'erreur. # FT.INFO **Syntaxe** ``` FT.INFO ``` La sortie de la page FT.INFO est un tableau de paires clé-valeur, comme décrit dans le tableau suivant : | Clé | Type de la valeur | Description | | --- | --- | --- | | nom\$1index | chaîne | Nom de l'index | | creation\$1timestamp | entier | Horodatage de style Unix de l'heure de création | | type\$1clé | chaîne | HASH ou JSON | | key\$1prefixes | tableau de chaînes | Préfixes clés pour cet index | | fields | ensemble d'informations sur le terrain | Champs de cet index | | utilisation de l'espace | entier | Octets de mémoire utilisés par cet index | | Fullext\$1space\$1usage | entier | Octets de mémoire utilisés par les champs non vectoriels | | utilisation de l'espace vectoriel | entier | Octets de mémoire utilisés par les champs vectoriels | | num\$1docs | entier | Nombre de clés actuellement contenues dans l'index | | num\$1indexed\$1vector | entier | Nombre de vecteurs actuellement contenus dans l'index | | current\$1lag | entier | Retard d'ingestion récent (millisecondes) | | backfill\$1status | chaîne | L'un des suivants : terminé InProgres, suspendu ou échoué | Le tableau suivant décrit les informations relatives à chaque champ : | Clé | Type de la valeur | Description | | --- | --- | --- | | identifiant | chaîne | nom du champ | | nom\$1champ | chaîne | Nom du membre de hachage ou chemin JSON | | type | chaîne | l'un des suivants : numérique, balise, texte ou vecteur | | option | chaîne | ignore | Si le champ est de type Vector, des informations supplémentaires seront présentes en fonction de l'algorithme. Pour l'algorithme HNSW : | Clé | Type de la valeur | Description | | --- | --- | --- | | automatique | chaîne | HNSW | | data\$1type | chaîne | FLOAT32 | | métrique de distance | chaîne | l'un des suivants : L2, IP ou Cosine | | capacité\$1initiale | entier | Taille initiale de l'indice du champ vectoriel | | capacité\$1actuelle | entier | Taille actuelle de l'indice du champ vectoriel | | arêtes maximales | entier | Paramètre M lors de la création | | ef\$1construction | entier | Paramètre EF\$1CONSTRUCTION lors de la création | | ef\$1runtime | entier | Paramètre EF\$1RUNTIME lors de la création | Pour l'algorithme FLAT : | Clé | Type de la valeur | Description | | --- | --- | --- | | automatique | chaîne | APPARTEMENT | | data\$1type | chaîne | FLOAT32 | | métrique de distance | chaîne | l'un des suivants : L2, IP ou Cosine | | capacité\$1initiale | entier | Taille initiale de l'indice du champ vectoriel | | capacité\$1actuelle | entier | Taille actuelle de l'indice du champ vectoriel | # PIEDS. \$1LISTE Répertoriez tous les index. **Syntaxe** ``` FT._LIST ``` **Retour** Renvoie un tableau de noms d'index # FT.ALIASADD Ajoutez un alias pour un index. Le nouveau nom d'alias peut être utilisé partout où un nom d'index est requis. **Syntaxe** ``` FT.ALIASADD ``` **Retour** Renvoie un message OK sous forme de chaîne simple ou une réponse d'erreur. # FT. ALIASDEL Supprimez un alias existant pour un index. **Syntaxe** ``` FT.ALIASDEL ``` **Retour** Renvoie un message OK sous forme de chaîne simple ou une réponse d'erreur. # MISE À JOUR DE FT.ALIAS Mettez à jour un alias existant pour qu'il pointe vers un autre index physique. Cette commande n'affecte que les futures références à l'alias. Les opérations actuellement en cours (FT.SEARCH, FT.AGGREGATE) ne sont pas affectées par cette commande. **Syntaxe** ``` FT.ALIASUPDATE ``` **Retour** Renvoie un message OK sous forme de chaîne simple ou une réponse d'erreur. # PIEDS. \$1ALIASLIST Répertoriez les alias d'index. **Syntaxe** ``` FT._ALIASLIST ``` **Retour** Renvoie un tableau de la taille du nombre d'alias actuels. Chaque élément du tableau est la paire alias-index. # FT.PROFILE Exécutez une requête et renvoyez les informations de profil relatives à cette requête. **Syntaxe** ``` FT.PROFILE SEARCH | AGGREGATE [LIMITED] QUERY ``` **Retour** Un tableau à deux éléments. Le premier élément est le résultat de la `FT.AGGREGATE` commande `FT.SEARCH` or profilée. Le deuxième élément est un ensemble d'informations sur les performances et le profilage. # FT.EXPLAIN Analyse une requête et renvoie des informations sur la façon dont cette requête a été analysée. **Syntaxe** ``` FT.EXPLAIN ``` **Retour** Chaîne contenant les résultats analysés. # FT.EXPLAINCLI Identique à la commande FT.EXPLAIN sauf que les résultats sont affichés dans un format différent, plus utile avec le redis-cli. **Syntaxe** ``` FT.EXPLAINCLI ``` **Retour** Chaîne contenant les résultats analysés.