Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Búsqueda vectorial
La búsqueda vectorial de MemoryDB amplía la funcionalidad de MemoryDB. La búsqueda vectorial se puede utilizar junto con las funciones existentes de MemoryDB. La presencia de la búsqueda vectorial no afecta a las aplicaciones que no la utilizan. La búsqueda vectorial está disponible en todas las regiones donde MemoryDB está disponible.
La búsqueda vectorial simplifica la arquitectura de la aplicación al mismo tiempo que ofrece una búsqueda vectorial de alta velocidad. La búsqueda vectorial de MemoryDB es ideal para casos de uso en los que el máximo rendimiento y la escalabilidad son los criterios de selección más importantes. Puede usar sus datos de MemoryDB existentes, o una API de Valkey o Redis OSS, para crear casos de uso de machine learning e IA generativa. Esto incluye la generación aumentada de recuperación, la detección de anomalías, la recuperación de documentos y las recomendaciones en tiempo real.
A partir del 26 de junio de 2024, AWS MemoryDB ofrece el rendimiento de búsqueda vectorial más rápido con las tasas de recuperación más altas entre las bases de datos vectoriales más populares. AWS
**Topics**
+ [Información general de la búsqueda vectorial](vector-search-overview.md)
+ [Casos de uso](vector-search-examples.md)
+ [Características y límites de la búsqueda vectorial](vector-search-limits.md)
+ [Crear un clúster habilitado para la búsqueda vectorial](vector-search-cluster.md)
+ [Comandos de búsqueda vectorial](vector-search-commands.md)
# Información general de la búsqueda vectorial
La búsqueda vectorial está basada en la creación, el mantenimiento y el uso de índices. Cada operación de búsqueda vectorial especifica un índice único y su operación se limita a ese índice, es decir, las operaciones de un índice no afectan las operaciones de ningún otro índice. A excepción de las operaciones de creación y destrucción de índices, se puede realizar cualquier cantidad de operaciones en cualquier índice en cualquier momento, lo que significa que, a nivel de clúster, pueden estar en ejecución varias operaciones en varios índices simultáneamente.
Los índices individuales son objetos con nombre que existen en un espacio de nombres único y separado de los demás espacios de nombres de Valkey y Redis OSS: claves, funciones, etc. Cada índice es conceptualmente similar a una tabla de base de datos convencional, dada su estructura en dos dimensiones: columnas y filas. Cada fila en la tabla corresponde a una clave. Cada columna del índice corresponde a un miembro o a una parte de esa clave. En este documento, los términos clave, fila y registro son idénticos y se usan indistintamente. Del mismo modo, los términos columna, campo, ruta y miembro son idénticos en esencia y también se usan indistintamente.
No existen comandos especiales para añadir, eliminar o modificar los datos indexados. Por el contrario, los comandos **HASH** o **JSON** existentes que modifican una clave que está en un índice también lo actualizan automáticamente.
**Topics**
+ [Los índices y el espacio de claves de Valkey y Redis OSS](#vector-search-indexes-keyspaces)
+ [El campo de índice escribe](#vector-search-index-field-types)
+ [Algoritmos de índice vectorial](#vector-search-index-algorithms)
+ [Expresión de consulta de búsqueda vectorial](#vector-search-query-expression)
+ [Comando INFO](#vector-search-ft.info)
+ [Seguridad de búsqueda vectorial](#vector-search-security)
## Los índices y el espacio de claves de Valkey y Redis OSS
Los índices se construyen y mantienen en un subconjunto del espacio de claves de Valkey y Redis OSS. Los índices múltiples pueden elegir subconjuntos disociados o superpuestos del espacio de claves sin limitación alguna. Durante la creación del índice se proporciona una lista de prefijos clave que definen el espacio de claves de cada índice. La lista de prefijos es opcional y, si se omite, todo el espacio de claves formará parte de ese índice. Los índices también están tipificados en el sentido de que solo incluyen las claves de tipo coincidente. Actualmente, solo se admiten los índices JSON y HASH. Un índice HASH solo indexa las claves HASH incluidas en su lista de prefijos y, de manera semejante, un índice JSON solo indexa las claves JSON incluidas en su lista de prefijos. Las claves incluidas en la lista de prefijos del espacio de claves de un índice que no poseen el tipo designado se ignoran y no afectan a las operaciones de búsqueda.
Cuando un comando HASH o JSON modifica una clave que se encuentra dentro del espacio de claves de un índice, dicho índice se actualiza. Este proceso implica la extracción de los campos declarados para cada índice y la actualización del índice con el nuevo valor. El proceso de actualización ocurre en un subproceso en segundo plano, lo que significa que en última instancia los índices solo son coherentes con el contenido de su espacio de claves. Por lo tanto, la inserción o actualización de una clave no será visible en los resultados de búsqueda durante un breve período de tiempo. Durante los períodos en los que el sistema está and/or sobrecargado de datos y se producen muchas mutaciones, el retraso en la visibilidad puede prolongarse.
La creación de un índice es un proceso de varios pasos. El primer paso es ejecutar el comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) que define el índice. Al ejecutarse correctamente el comando create, se inicia automáticamente el segundo paso: la reposición. El proceso de reposición se ejecuta en un subproceso en segundo plano y analiza el espacio de claves en busca de claves que estén dentro de la lista de prefijos del nuevo índice. Cada clave que se encuentra se agrega al índice. Finalmente, se analiza todo el espacio de claves y se completa el proceso de creación del índice. Tenga en cuenta que mientras el proceso de reposición está en marcha, se permiten las mutaciones de las claves indexadas, no hay restricciones y el proceso de reposición del índice no finalizará hasta que todas las claves estén indexadas correctamente. No se permiten las operaciones de consulta realizadas mientras se está rellenando un índice y se las finaliza con un error. La finalización del proceso de reposición se puede determinar a partir del resultado del comando `FT.INFO` para ese índice ('backfill\$1status').
## El campo de índice escribe
Cada campo (columna) de un índice tiene un tipo específico que se declara durante la creación del índice y una ubicación dentro de una clave. En Claves HASH, la ubicación es el nombre del campo dentro del HASH. En Claves JSON, la ubicación es una descripción de la ruta JSON. Al modificar una clave, los datos asociados a los campos declarados se extraen, se convierten al tipo declarado y se almacenan en el índice. Si faltan los datos o no se pueden convertir correctamente al tipo declarado, ese campo se omite del índice. Hay cuatro tipos de campos, según se explica a continuación:
+ **Los campos numéricos** contienen un solo número. En Campos JSON, se deben seguir las reglas numéricas de los números JSON. En HASH, se espera que el campo contenga el texto ASCII de un número escrito en el formato estándar para números de punto fijo o flotante. Independientemente de la representación que contenga la clave, este campo se convierte en un número de punto flotante de 64 bits para almacenarlo en el índice. Los campos numéricos se pueden utilizar con el operador de búsqueda por rangos. Como los números subyacentes se almacenan en punto flotante con sus limitaciones de precisión, se aplican las reglas habituales sobre las comparaciones numéricas de números de punto flotante.
+ **Los campos de etiquetas** contienen cero o más valores de etiqueta codificados como una sola cadena UTF-8. La cadena se analiza en valores de etiqueta mediante un carácter separador (el valor predeterminado es una coma, pero se puede anular) y se eliminan los espacios en blanco iniciales y finales. Se puede incluir cualquier número de valores de etiqueta en un único campo de etiqueta. Los campos de etiquetas se pueden usar para filtrar las consultas y determinar la equivalencia de los valores de las etiquetas mediante una comparación que distinga entre mayúsculas y minúsculas o que no distinga entre mayúsculas y minúsculas.
+ **Los campos de texto** contienen una masa de bytes que no deben ser necesariamente compatibles con UTF-8. Los campos de texto se pueden usar para decorar los resultados de las consultas con valores significativos para la aplicación. Por ejemplo, una URL o el contenido de un documento, etc.
+ **Los campos vectoriales** contienen un vector de números, también conocido como una incrustación. Los campos vectoriales admiten la búsqueda del k vecino más cercano (KNN) de vectores de tamaño fijo mediante un algoritmo y una métrica de distancia específicos. En Índices HASH, el campo debe contener todo el vector codificado en formato binario (*IEEE 754 del tipo little-endian*). En Claves JSON, la ruta debe hacer referencia a una matriz del tamaño correcto llena de números. Tenga en cuenta que cuando se utiliza una matriz JSON como campo vectorial, la representación interna de la matriz dentro de la clave JSON se convierte al formato exigido por el algoritmo seleccionado, lo que reduce el consumo y la precisión de memoria. Las operaciones de lectura posteriores con los comandos JSON darán como resultado el valor de precisión reducido.
## Algoritmos de índice vectorial
Se proporcionan dos algoritmos de índice vectorial:
+ **FLAT**: el algoritmo Flat es un procesamiento lineal de fuerza bruta de cada vector del índice, que da como resultado respuestas exactas dentro de los límites de la precisión de los cálculos de distancia. Debido al procesamiento lineal del índice, los tiempos de ejecución de este algoritmo pueden ser muy altos para índices grandes.
+ **HNSW (mundo pequeño navegable jerárquicamente)**: el algoritmo HNSW es una alternativa que proporciona una aproximación de la respuesta correcta a cambio de tiempos de ejecución considerablemente más bajos. El algoritmo está controlado por tres parámetros, `M` `EF_CONSTRUCTION` y `EF_RUNTIME`. Los dos primeros parámetros se especifican en el momento de la creación del índice y no se pueden cambiar. El parámetro `EF_RUNTIME` tiene un valor predeterminado que se especifica al crear el índice, pero se puede anular posteriormente en cualquier operación de consulta individual. Estos tres parámetros interactúan para equilibrar el consumo de memoria y de CPU durante las operaciones de incorporación y consulta, así como para controlar la calidad de la aproximación de una búsqueda KNN exacta (conocida como relación de recuperación).
Ambos algoritmos de búsqueda vectorial (FLAT y HNSW) admiten un parámetro `INITIAL_CAP` opcional. Si se especifica, este parámetro asigna previamente memoria a los índices, lo que da como resultado una reducción de la sobrecarga de administración de la memoria y aumenta las tasas de incorporación vectorial.
Es posible que los algoritmos de búsqueda vectorial, como el HNSW, no gestionen de manera eficiente la eliminación o la sobrescritura de los vectores previamente insertados. El uso de estas operaciones puede provocar un consumo excesivo de memoria indexada y and/or degradar la calidad de la recuperación. La reindexación es un método para restaurar la recuperación del uso óptimo de la memoria. and/or
## Expresión de consulta de búsqueda vectorial
Los comandos [FT.SEARCH](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.search.html) y [FT.AGGREGATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.aggregate.html) exigen una expresión de consulta. que es un parámetro de cadena única que se compone de uno o varios operadores. Cada operador utiliza un campo del índice para identificar un subconjunto de las claves del índice. Se pueden combinar varios operadores mediante combinadores booleanos y paréntesis para mejorar o restringir aún más el conjunto de claves (o conjunto de resultados) recopilado.
### Comodín
El operador comodín, el asterisco ('\$1'), coincide con todas las claves del índice.
### Rango numérico
El operador de rango numérico tiene la siguiente sintaxis:
```
::= '@' ':' '[' ']'
::= | '('
::= | | | 'Inf' | '-Inf' | '+Inf'
```
El campo < numeric-field-name > debe ser un campo de tipo declarado. `NUMERIC` De forma predeterminada, el límite es inclusivo, pero se puede usar un paréntesis abierto inicial ['('] para hacer que un límite sea exclusivo. La búsqueda por rangos se puede convertir en una comparación relacional (<, <=, > > =) única mediante `Inf`, `+Inf` o `-Inf` como uno de los límites. Independientemente del formato numérico especificado (entero, punto fijo, punto flotante, infinito), el número se convierte en punto flotante de 64 bits para realizar comparaciones y, en consecuencia, reducir la precisión.
**Example Ejemplos**
```
@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
```
### Comparación de etiquetas
El operador de comparación de etiquetas tiene la siguiente sintaxis:
```
::= '@' ':' '{' [ '|' ]* '}'
```
Si alguna de las etiquetas del operador coincide con alguna de las etiquetas del campo de etiquetas del registro, este se incluye en el conjunto de resultados. El campo diseñado por el `` debe ser un campo del índice declarado con el tipo `TAG`. Algunos ejemplos de una comparación de etiquetas son los siguientes:
```
@tag-field:{ atag }
@tag-field: { tag1 | tag2 }
```
### Combinaciones booleanas
Los conjuntos de resultados de un operador numérico o de etiquetas se pueden combinar mediante la lógica booleana: and/or. Parentheses can be used to group operators and/or cambie el orden de evaluación. La sintaxis de los operadores lógicos booleanos es la siguiente:
```
::= | '|' | '(' ')'
::= |
::= | | '*'
```
Los términos múltiples combinados en una frase son anexados con “y”. Las frases múltiples combinadas con la barra vertical ('\$1') se relacionan con “o”.
### Búsqueda vectorial
Los índices vectoriales admiten dos métodos de búsqueda diferentes: vecino más cercano y rango. La búsqueda de vecino más cercano localiza un número, K, de los vectores del índice que están más cerca del vector proporcionado (de referencia); esto se denomina coloquialmente KNN para “K” vecinos más cercanos. La sintaxis de una búsqueda KNN es la siguiente:
```
::= '=>[KNN' '@' '$' ']'
::= [ 'EF_RUNTIME' ] [ 'AS' ]
```
La búsqueda vectorial KNN solo se aplica a los vectores que cumplen los requisitos, `` que pueden ser cualquier combinación de los operadores definidos anteriormente: comodín, búsqueda por rangos, búsqueda por etiquetas, combinaciones booleanas de los mismos. and/or
+ `` es un número entero que especifica el número de vectores vecinos más cercanos que se van a devolver.
+ `` debe especificar un campo de tipo `VECTOR` declarado.
+ El campo `` especifica una de las entradas de la tabla `PARAM` del comando `FT.SEARCH` o `FT.AGGREGATE`. Este parámetro es el valor vectorial de referencia para los cálculos de distancia. El valor del vector está codificado en el valor `PARAM` del formato binario *IEEE 754 del tipo little-endian* (con la misma codificación que para un campo vectorial HASH)
+ Para los índices vectoriales de tipo HNSW, la cláusula `EF_RUNTIME` opcional se puede utilizar para anular el valor predeterminado del parámetro `EF_RUNTIME` que se estableció cuando se creó el índice.
+ La `` opcional proporciona un nombre de campo para que el conjunto de resultados contenga la distancia calculada entre el vector de referencia y la clave ubicada.
Una búsqueda por rango localiza todos los vectores dentro de una distancia (radio) especificada con respecto a un vector de referencia. La sintaxis de una búsqueda por rango es la siguiente:
```
::= ‘@’ ‘:’ ‘[’ ‘VECTOR_RANGE’ ( | ‘$’ ) $ ‘]’ [ ‘=’ ‘>’ ‘{’ ‘}’ ]
::= | ,
::= [ ‘$yield_distance_as’ ‘:’ ] [ ‘$epsilon’ ‘:’ ]
```
Donde:
+ `` es el nombre del campo vectorial que se va a buscar.
+ ` or $` es el límite de distancia numérico para la búsqueda.
+ `$ ` es el nombre del parámetro que contiene el vector de referencia. El valor del vector está codificado en el valor PARAM del formato binario IEEE 754 del tipo little-endian (con la misma codificación que para un campo vectorial HASH)
+ La `` opcional proporciona un nombre de campo para que el conjunto de resultados contenga la distancia calculada entre el vector de referencia y cada clave.
+ La opción ` ` controla el límite de la operación de búsqueda, los vectores situados dentro de la distancia ` * (1.0 + ) ` se recorren en busca de resultados candidatos. El valor predeterminado es .01.
## Comando INFO
La búsqueda vectorial amplía el comando [INFO](https://valkey.io/commands/info/) de Valkey y Redis OSS con varias secciones adicionales de estadísticas y contadores. Al solicitar la recuperación de la sección `SEARCH`, se recuperarán todas las secciones siguientes:
### Sección de `search_memory`
| Name | Description (Descripción) |
| --- | --- |
| search\$1used\$1memory\$1bytes | Número de bytes de memoria consumidos en todas las estructuras de datos de búsqueda |
| search\$1used\$1memory\$1human | Versión legible por seres humanos de lo anterior |
### Sección de `search_index_stats`
| Name | Description (Descripción) |
| --- | --- |
| search\$1number\$1of\$1indexes | Número de índices creados |
| search\$1num\$1fulltext\$1indexes | Número de campos no vectoriales en todos los índices |
| search\$1num\$1vector\$1indexes | Número de campos vectoriales en todos los índices |
| search\$1num\$1hash\$1indexes | Número de índices en las claves de tipo HASH |
| search\$1num\$1json\$1indexes | Número de índices en las claves de tipo JSON |
| search\$1total\$1indexed\$1keys | Número total de claves en todos los índices |
| search\$1total\$1indexed\$1vectors | Número total de vectores en todos los índices |
| search\$1total\$1indexed\$1hash\$1keys | Número total de claves de tipo HASH en todos los índices |
| search\$1total\$1indexed\$1json\$1keys | Número total de claves de tipo JSON en todos los índices |
| search\$1total\$1index\$1size | Bytes utilizados por todos los índices |
| search\$1total\$1fulltext\$1index\$1size | Bytes utilizados por estructuras de índices no vectoriales |
| search\$1total\$1vector\$1index\$1size | Bytes utilizados por estructuras de índices vectoriales |
| search\$1max\$1index\$1lag\$1ms | Retraso de incorporación durante la última actualización del lote de incorporación |
### Sección de `search_ingestion`
| Name | Description (Descripción) |
| --- | --- |
| search\$1background\$1indexing\$1status | Estado de la incorporación. NO\$1ACTIVITY significa inactivo. Otros valores indican que hay claves en proceso de incorporación. |
| search\$1ingestion\$1paused | A menos que se reinicie, siempre debe ser “no”. |
### Sección de `search_backfill`
**nota**
Algunos de los campos documentados en esta sección solo están visibles cuando hay una reposición en curso.
| Name | Description (Descripción) |
| --- | --- |
| search\$1num\$1active\$1backfills | Número de actividades de reposición actuales |
| search\$1backfills\$1paused | Excepto cuando se agote la memoria, siempre debe ser “no”. |
| search\$1current\$1backfill\$1progress\$1percentage | % de finalización (0-100) de la reposición actual |
### Sección de `search_query`
| Name | Description (Descripción) |
| --- | --- |
| search\$1num\$1active\$1queries | Número de comandos FT.SEARCH y FT.AGGREGATE actualmente en curso |
## Seguridad de búsqueda vectorial
Los mecanismos de seguridad de [ACL (listas de control de acceso)](https://valkey.io/topics/acl/) para el acceso a los comandos y a los datos se han ampliado para controlar la función de búsqueda. El control ACL de los comandos de búsqueda individuales es totalmente compatible. Se proporciona una nueva categoría de ACL, `@search`, y muchas de las categorías existentes (`@fast`, `@read`, `@write`, etc.) se actualizan para incluir los nuevos comandos. Los comandos de búsqueda no modifican los datos clave, lo que significa que se conserva la maquinaria ACL existente para el acceso de escritura. La presencia de un índice no modifica las reglas de acceso para las operaciones HASH y JSON; se sigue aplicando el control de acceso normal a nivel de clave a estos comandos.
El acceso de los comandos de búsqueda con un índice también se controla mediante la ACL. Las comprobaciones de acceso se realizan a nivel de índice completo, no al nivel de la clave. Esto significa que el acceso a un índice se garantiza a un usuario solo si ese usuario tiene permiso para acceder a todas las claves posibles de la lista de prefijos del espacio de claves de ese índice. En otras palabras, el contenido real de un índice no controla el acceso. Más bien, es el contenido teórico de un índice, tal como se define en la lista de prefijos, el que se utiliza para el control de seguridad. Puede ser fácil crear una situación en la que un usuario tenga acceso de lectura y and/or escritura a una clave, pero no pueda acceder a un índice que contenga esa clave. Tenga en cuenta que solo se requiere acceso de lectura al espacio de claves para crear o usar un índice; no se tiene en cuenta la presencia o ausencia del acceso de escritura.
Para obtener más información sobre el uso ACLs de MemoryDB, consulte [Autenticación de usuarios con listas de control de acceso](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html) (). ACLs
# Casos de uso
A continuación se presentan algunos casos de uso de búsqueda vectorial.
## Generación aumentada de recuperación (RAG)
La generación aumentada de recuperación (RAG) aprovecha la búsqueda vectorial para recuperar pasajes relevantes de un gran corpus de datos para aumentar modelo de lenguaje grande (LLM). En concreto, un codificador incrusta el contexto de entrada y la consulta de búsqueda en vectores y, a continuación, utiliza la búsqueda aproximada de vecino más cercano para encontrar pasajes semánticamente similares. Estos pasajes recuperados se concatenan con el contexto original para proporcionar información adicional pertinente al LLM y devolver una respuesta más precisa al usuario.
![\[Gráfico del flujo de generación aumentada de recuperación\]](http://docs.aws.amazon.com/es_es/memorydb/latest/devguide/images/RAG.png)
## Caché semántica duradera
El almacenamiento en caché semántico es un proceso para reducir los costos computacionales mediante el almacenamiento de los resultados anteriores de la FM. Al reutilizar los resultados anteriores de inferencias anteriores en lugar de volver a calcularlos, el almacenamiento semántico en caché reduce la cantidad de cálculos necesarios durante la inferencia mediante el. FMs MemoryDB permite un almacenamiento en caché semántico duradero, lo que evita la pérdida de datos de inferencias anteriores. Esto permite que sus aplicaciones de IA generativa respondan en cuestión de milisegundos de un solo dígito a preguntas anteriores semánticamente similares, al tiempo que reduce los costes al evitar inferencias de LLM innecesarias.
![\[Diagrama de flujo de trabajo que muestra el proceso del modelo fundacional.\]](http://docs.aws.amazon.com/es_es/memorydb/latest/devguide/images/FM.png)
+ **Resultado de la búsqueda semántica**: si la consulta de un cliente es semánticamente similar en función de una puntuación de similitud definida con una pregunta anterior, la memoria intermedia del FM (MemoryDB) devolverá la respuesta a la pregunta anterior en el paso 4 y no llamará al FM en los pasos 3. Esto evitará la latencia del modelo fundacional (FM) y los costos incurridos, lo que permitirá al cliente disfrutar de una experiencia más rápida.
+ **Fallo en la búsqueda semántica**: si la consulta de un cliente no es semánticamente similar en función de una puntuación de similitud definida con respecto a una consulta anterior, el cliente llamará al FM para responderle en el paso 3a. La respuesta generada por el FM se almacenará luego como vector en MemoryDB para consultas futuras (paso 3b) a fin de minimizar los costos del FM en preguntas semánticamente similares. En este flujo, no se invocaría el paso 4 porque no había una pregunta semánticamente similar para la consulta original.
## Detección de fraudes
La detección de fraudes, una forma de detección de anomalías, representa las transacciones válidas como vectores al tiempo que compara las representaciones vectoriales de las nuevas transacciones netas. El fraude se detecta cuando estas nuevas transacciones netas tienen una baja similitud con los vectores que representan los datos transaccionales válidos. Esto permite detectar el fraude al modelar el comportamiento normal, en lugar de intentar predecir todas las posibles instancias de fraude. MemoryDB permite a las organizaciones hacerlo en períodos de alto rendimiento, con un mínimo de falsos positivos y una latencia de milisegundos de un solo dígito.
![\[Diagrama de flujo de trabajo que muestra el proceso de detección de fraudes.\]](http://docs.aws.amazon.com/es_es/memorydb/latest/devguide/images/fraud-detection.png)
## Otros casos de uso
+ **Los motores de recomendación** pueden encontrar productos o contenidos similares para los usuarios al representar los elementos como vectores. Los vectores se crean mediante el análisis de atributos y patrones. Según los patrones y atributos del usuario, se pueden recomendar nuevos elementos invisibles a los usuarios al encontrar los vectores más similares que ya hayan sido puntuados positivamente y alineados con el usuario.
+ **Los motores de búsqueda de documentos** representan los documentos de texto como vectores densos de números que capturan su significado semántico. En el momento de la búsqueda, el motor convierte una consulta de búsqueda en un vector y encuentra los documentos con los vectores más similares a la consulta mediante una búsqueda aproximada del vecino más cercano. Este enfoque de similitud vectorial permite coincidir los documentos en función del significado en lugar de simplemente hacer coincidir las palabras clave.
# Características y límites de la búsqueda vectorial
## Disponibilidad de búsqueda vectorial
La configuración de MemoryDB, que permite la búsqueda vectorial, es compatible con los tipos de nodos R6g, R7g y T4g y está disponible en todas las regiones donde está disponible MemoryDB. AWS
Los clústeres existentes no se pueden modificar para habilitar la búsqueda. Sin embargo, los clústeres habilitados para la búsqueda se pueden crear a partir de instantáneas de clústeres con la búsqueda deshabilitada.
## Restricciones paramétricas
En la siguiente tabla se muestran los límites de varios elementos de búsqueda vectorial:
| Elemento | Valor máximo |
| --- | --- |
| Cantidad de dimensiones de un vector | 32768 |
| Cantidad de índices que se pueden crear | 10 |
| Cantidad de campos de un índice | 50 |
| Cláusula de tiempo de espera FT.SEARCH y FT.AGGREGATE (milisegundos) | 10000 |
| Cantidad de etapas de canalización en el comando FT.AGGREGATE | 32 |
| Cantidad de campos de la cláusula FT.AGGREGATE LOAD | 1024 |
| Cantidad de campos de la cláusula FT.AGGREGATE GROUPBY | 16 |
| Cantidad de campos de la cláusula FT.AGGREGATE SORTBY | 16 |
| Cantidad de parámetros en la cláusula FT.AGGREGATE PARAM | 32 |
| Parámetro HNSW M | 512 |
| Parámetro HNSW EF\$1CONSTRUCTION | 4096 |
| Parámetro HNSW EF\$1RUNTIME | 4096 |
## Límites de escalado
La búsqueda vectorial de MemoryDB está limitada actualmente a una única partición y no se admite el escalado horizontal. La búsqueda vectorial admite el escalado vertical y de réplica.
## Restricciones operativas
**Persistencia y reposición de índices**
La característica de búsqueda vectorial conserva la definición de los índices y el contenido del índice. Esto significa que, durante cualquier solicitud o evento operativo que provoque el inicio o el reinicio de un nodo, la definición y el contenido del índice se restauran a partir de la última instantánea y cualquier transacción pendiente se lee del registro de transacciones Multi-AZ. Para iniciar esta operación no se requiere ninguna acción por parte del usuario. La reconstrucción se realiza como una operación de reposición tan pronto como se restauran los datos. Esto equivale funcionalmente a que el sistema ejecute automáticamente un comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) para cada índice definido. Tenga en cuenta que el nodo estará disponible para las operaciones de la aplicación tan pronto como se restauren los datos, pero probablemente antes de que se complete la reposición del índice, lo que significa que las aplicaciones volverán a estar visibles para las aplicaciones. Por ejemplo, es posible que se rechacen los comandos de búsqueda que utilicen índices de reposición. Para obtener más información sobre la reposición, consulte [Información general de la búsqueda vectorialLos índices y el espacio de claves de Valkey y Redis OSS](vector-search-overview.md#vector-search-indexes-keyspaces).
La finalización de la reposición del índice no se sincroniza entre una reposición principal y una réplica. Esta falta de sincronización puede pasar a ser visible para las aplicaciones de forma inesperada, por lo que se recomienda que las aplicaciones verifiquen que esté finalizada la reposición en las principales y todas las réplicas antes de iniciar las operaciones de búsqueda.
## Migración instantánea import/export y en vivo
La presencia de índices de búsqueda en un archivo RDB limita la transportabilidad compatible de esos datos. El formato de los índices vectoriales definido por la funcionalidad de búsqueda vectorial de MemoryDB solo lo entiende otro clúster de MemoryDB habilitado para vectores. Además, los archivos RDB de los clústeres de vista previa se pueden importar desde la versión de GA de los clústeres de MemoryDB, que reconstruirá el contenido del índice al cargar el archivo RDB.
Sin embargo, los archivos RDB que no contienen índices no están restringidos de esta manera. Por lo tanto, los datos de un clúster de vista previa se pueden exportar a clústeres que no sean de vista previa mediante la eliminación de los índices antes de la exportación.
## Consumo de memoria
El consumo de memoria se basa en el número de vectores, el número de dimensiones, el valor M y la cantidad de datos no vectoriales, como los metadatos asociados al vector u otros datos almacenados en la instancia.
La memoria total necesaria es una combinación del espacio necesario para los datos vectoriales reales y el espacio necesario para los índices vectoriales. El espacio necesario para los datos vectoriales se calcula midiendo la capacidad real necesaria para almacenar los vectores dentro de las estructuras de datos HASH o JSON y la sobrecarga a los slabs de memoria más cercanos, para lograr asignaciones de memoria óptimas. Cada uno de los índices vectoriales utiliza referencias a los datos vectoriales almacenados en estas estructuras de datos y utiliza optimizaciones de memoria eficientes para eliminar cualquier copia duplicada de los datos vectoriales del índice.
El número de vectores depende de cómo se decida representar los datos como vectores. Por ejemplo, puede elegir representar un único documento en varios fragmentos, donde cada fragmento represente un vector. Como alternativa, puede optar por representar todo el documento como un único vector.
El número de dimensiones de los vectores depende del modelo de incrustación que se elija. Por ejemplo, si opta por utilizar el modelo de incrustación [AWS Titan](https://aws.amazon.com/bedrock/titan/), el número de dimensiones sería 1536.
El parámetro M representa el número de enlaces bidireccionales creados para cada elemento nuevo durante la construcción del índice. MemoryDB establece este valor de forma predeterminada en 16, pero puede anular este valor. Un parámetro M más alto funciona mejor para requisitos de alta dimensionalidad y and/or alta recuperación, mientras que los parámetros M bajos funcionan mejor para requisitos de baja dimensionalidad y and/or baja recuperación. El valor M aumenta el consumo de memoria a medida que el índice aumenta, lo que aumenta el consumo de memoria.
En la experiencia de la consola, MemoryDB ofrece una forma sencilla de elegir el tipo de instancia adecuado en función de las características de la carga de trabajo vectorial, tras seleccionar la opción Habilitar la búsqueda vectorial en la configuración del clúster.
![\[Configuración del clúster de búsqueda vectorial en la AWS consola.\]](http://docs.aws.amazon.com/es_es/memorydb/latest/devguide/images/vector-search-cluster-settings-console.png)
**Ejemplo de carga de trabajo**
Un cliente desea crear un motor de búsqueda semántica basado en sus documentos financieros internos. Actualmente tiene un millón de documentos financieros divididos en 10 vectores por documento utilizando el modelo de incrustación Titan con 1536 dimensiones y no tiene datos que no sean vectoriales. El cliente decide usar el valor predeterminado de 16 como parámetro M.
+ Vectores: 1 M \$1 10 fragmentos = 10 M vectores
+ Dimensiones: 1536
+ Datos no vectoriales (GB): 0 GB
+ Parámetro M: 16
Con estos datos, el cliente puede hacer clic en el botón Usar calculadora vectorial de la consola para obtener un tipo de instancia recomendado en función de sus parámetros:
![\[La calculadora vectorial recomienda el tipo de nodo en función de la entrada de la calculadora.\]](http://docs.aws.amazon.com/es_es/memorydb/latest/devguide/images/vector-calc1.png)
![\[Calculadora vectorial con los valores introducidos.\]](http://docs.aws.amazon.com/es_es/memorydb/latest/devguide/images/vector-calc2.png)
En este ejemplo, la calculadora vectorial buscará el [tipo de nodo MemoryDB r7g](https://aws.amazon.com/memorydb/pricing/) más pequeño que pueda almacenar la memoria necesaria para almacenar los vectores en función de los parámetros proporcionados. Tenga en cuenta que se trata de una aproximación y que debe probar el tipo de instancia para asegurarse de que se ajuste a sus requisitos.
Según el método de cálculo anterior y los parámetros de la carga de trabajo de la muestra, estos datos vectoriales necesitarían 104,9 GB para almacenar los datos y un índice único. En este caso, se recomendaría el tipo de instancia `db.r7g.4xlarge`, ya que tiene 105,81 GB de memoria útil. El siguiente tipo de nodo más pequeño sería demasiado pequeño para contener la carga de trabajo vectorial.
Como cada uno de los índices vectoriales utiliza referencias a los datos vectoriales almacenados y no crea copias adicionales de los datos vectoriales en el índice vectorial, los índices también consumirán relativamente menos espacio. Esto resulta muy útil para crear varios índices y también en situaciones en las que se han eliminado partes de los datos vectoriales y la reconstrucción del gráfico HNSW ayudaría a crear conexiones de nodos óptimas para obtener resultados de búsqueda vectorial de alta calidad.
## Falta de memoria durante la reposición
Al igual que las operaciones de escritura en OSS de Valkey y Redis, el relleno de índices está sujeto a limitaciones. out-of-memory Si la memoria del motor se llena mientras hay una reposición en curso, todas las reposiciones se pausan. Si queda memoria disponible, se reanuda el proceso de reposición. También es posible eliminar e indexar cuando la reposición está en pausa por falta de memoria.
## Transacciones
Los comandos`FT.CREATE`,, `FT.DROPINDEX` `FT.ALIASADD``FT.ALIASDEL`, y `FT.ALIASUPDATE` no se pueden ejecutar en un contexto transaccional, es decir, no dentro de un MULTI/EXEC bloque o dentro de un script LUA o FUNCTION.
# Crear un clúster habilitado para la búsqueda vectorial
Puede crear un clúster que esté habilitado para la búsqueda vectorial utilizando el Consola de administración de AWS, o el. AWS Command Line Interface Dependiendo del enfoque, se deben habilitar las consideraciones para habilitar la búsqueda vectorial.
## Usando el Consola de administración de AWS
Para crear un clúster que permita la búsqueda vectorial en la consola, debe habilitar la búsqueda vectorial en los ajustes de configuración **Clúster**. La búsqueda vectorial está disponible con la versión 7.1 de MemoryDB en una configuración de partición única.
![\[Al ver la configuración del clúster con la opción “Habilitar la búsqueda vectorial” marcada, se obtiene información sobre la compatibilidad con versiones y configuraciones específicas.\]](http://docs.aws.amazon.com/es_es/memorydb/latest/devguide/images/vs-2.png)
Para obtener más información sobre el uso de la búsqueda vectorial con Consola de administración de AWS, consulte[Creación de un clúster (consola)](getting-started.md#clusters.createclusters.viewdetails.cluster).
## Uso del AWS Command Line Interface
Para crear un clúster de MemoryDB habilitado para la búsqueda vectorial, puede utilizar el comando [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-cluster.html) de MemoryDB pasando un grupo de parámetros inmutables `default.memorydb-redis7.search` para habilitar las capacidades de búsqueda vectorial.
```
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
```
Opcionalmente, también puede crear un nuevo grupo de parámetros para habilitar la búsqueda vectorial, como se muestra en el ejemplo siguiente. Puede obtener más información sobre los grupos de parámetros [aquí](parametergroups.management.md).
```
aws memorydb create-parameter-group \
--parameter-group-name my-search-parameter-group \
--family memorydb_redis7
```
A continuación, actualice el parámetro habilitado para búsqueda a Yes en el grupo de parámetros recién creado.
```
aws memorydb update-parameter-group \
--parameter-group-name my-search-parameter-group \
--parameter-name-values "ParameterName=search-enabled,ParameterValue=yes"
```
Ahora puede usar este grupo de parámetros personalizado en lugar del grupo de parámetros predeterminado para habilitar la búsqueda vectorial en los clústeres de MemoryDB.
# Comandos de búsqueda vectorial
A continuación se muestra una lista de comandos compatibles para la búsqueda vectorial.
**Topics**
+ [FT.CREATE](vector-search-commands-ft.create.md)
+ [FT.SEARCH](vector-search-commands-ft.search.md)
+ [FT.AGGREGATE](vector-search-commands-ft.aggregate.md)
+ [FT.DROPINDEX](vector-search-commands-ft.dropindex.md)
+ [FT.INFO](vector-search-commands-ft.info.md)
+ [FT.\$1LIST](vector-search-commands-ft.list.md)
+ [FT.ALIASADD](vector-search-commands-ft.aliasadd.md)
+ [FT.ALIASDEL](vector-search-commands-ft.aliasdel.md)
+ [FT.ALIASUPDATE](vector-search-commands-ft.aliasupdate.md)
+ [FT.\$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
Crea un índice e inicia la reposición de ese índice. Para obtener más información, consulte la [descripción general de la búsqueda vectorial](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html) para obtener más detalles sobre la construcción del índice.
**Sintaxis**
```
FT.CREATE
ON HASH | JSON
[PREFIX [...]]
SCHEMA
( [AS ]
NUMERIC
| TAG [SEPARATOR ] [CASESENSITIVE]
| TEXT
| VECTOR [HNSW|FLAT] [ ])
)+
```
**Esquema**
+ Identificador del campo:
+ En Claves hash, el identificador de campo es Un nombre de campo.
+ En Claves JSON, el identificador de campo es Una ruta JSON.
Para obtener más información, consulte [El campo de índice escribe](vector-search-overview.md#vector-search-index-field-types).
+ Tipos de campo:
+ ETIQUETA: Para obtener más información, consulte [Etiquetas](https://redis.io/docs/interact/search-and-query/advanced-concepts/tags/).
+ NUMÉRICO: el campo contiene un número.
+ TEXTO: El campo contiene cualquier bloque de datos.
+ VECTOR: campo vectorial que admite la búsqueda vectorial.
+ Algoritmo: puede ser HNSW (mundo pequeño navegable jerárquicamente) o FLAT (fuerza bruta).
+ `attr_count`: cantidad de atributos que se transferirán como configuración del algoritmo, que incluye tanto los nombres como los valores.
+ `{attribute_name} {attribute_value}`— key/value pares específicos del algoritmo que definen la configuración del índice.
Para el algoritmo FLAT, los atributos son:
Obligatorio
+ DIM: la cantidad de dimensiones del vector.
+ DISTANCE\$1METRIC: puede ser uno de los siguientes: [L2 \$1 IP \$1 COSINE].
+ TYPE: tipo de vector. El único tipo admitido es `FLOAT32`.
Opcional:
+ INITIAL\$1CAP: capacidad vectorial inicial del índice que afecta al tamaño de asignación de memoria del índice.
Para el algoritmo HNSW, los atributos son:
Obligatorio
+ TYPE: tipo de vector. El único tipo admitido es `FLOAT32`.
+ DIM: dimensión vectorial, especificada como un entero positivo. Máximo: 32768
+ DISTANCE\$1METRIC: puede ser uno de los siguientes: [L2 \$1 IP \$1 COSINE].
Opcional:
+ INITIAL\$1CAP: capacidad vectorial inicial del índice que afecta al tamaño de asignación de memoria del índice. El valor predeterminado es 1024.
+ M: cantidad máxima de bordes salientes permitidos para cada nodo del gráfico en cada capa. En la capa cero, el número máximo de bordes salientes será de 2 millones. El valor predeterminado es 16 y el máximo es 512.
+ EF\$1CONSTRUCTION: controla la cantidad de vectores examinados durante la construcción del índice. Los valores más altos de este parámetro mejorarán la tasa de recuperación a costa de prolongar los tiempos de creación del índice. El valor predeterminado es 200. El valor máximo es 4096.
+ EF\$1RUNTIME: controla la cantidad de vectores examinados durante las operaciones de consulta. Los valores más altos de este parámetro darán una tasa de recuperación mejorada a costa de tiempos de consulta prolongados. El valor de este parámetro se puede anular según cada consulta. El valor predeterminado es 10. El valor máximo es 4096.
**Devolución**
Devuelve un mensaje de OK de cadena simple o una respuesta de error.
**Ejemplos**
**nota**
En el siguiente ejemplo, se utilizan argumentos nativos de [valkey-cli](https://valkey.io/topics/cli/), como eliminar las comillas y los valores de escape de los datos, antes de enviarlos a Valkey o Redis OSS. Para usar otros clientes de lenguajes de programación (Python, Ruby, C\$1, etc.), siga las reglas de manejo de esos entornos para tratamiento de cadenas y datos binarios. Para obtener más información sobre los clientes compatibles, consulte [Herramientas](https://aws.amazon.com/developer/tools/) sobre las que basarse AWS
**Example 1: Crear algunos índices**
Cree un índice para vectores de tamaño 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
```
Cree un índice JSON de 6 dimensiones mediante el algoritmo 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 Ejemplo 2: Rellenar algunos datos**
Los siguientes comandos utilizan un formato que permite que se ejecuten como argumentos en el programa de terminal redis-cli. Los desarrolladores que utilicen otros clientes de lenguajes de programación (Python, Ruby, C\$1, etc.) deberán seguir las reglas de control de esos entornos para el tratamiento de cadenas y datos binarios.
Creación de algunos datos hash y 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]}'
```
Tenga en cuenta lo siguiente:
+ Las claves de los datos HASH y JSON tienen los prefijos de sus definiciones de índice.
+ Los vectores se encuentran en las rutas apropiadas de las definiciones del índice.
+ Los vectores HASH se ingresan como datos hexadecimales, mientras que los datos JSON se ingresan como números.
+ Los vectores tienen las longitudes adecuadas, las entradas del vector HASH bidimensional tienen dos valores flotantes de datos hexadecimales y las entradas vectoriales json de seis dimensiones tienen seis números.
**Example Ejemplo 3: Eliminar y volver a crear un índice**
```
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
```
Tenga en cuenta que el nuevo índice JSON usa el algoritmo `FLAT` en lugar del algoritmo `HNSW`. Tenga en cuenta también que volverá a indexar los datos JSON existentes:
```
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
Utiliza la expresión de consulta proporcionada para localizar las claves dentro de un índice. Una vez localizados, se puede devolver el and/or contenido del recuento de los campos indexados dentro de esas claves. Para obtener más información, consulte [Expresión de consulta de búsqueda vectorial](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).
Para crear datos para utilizarlos en estos ejemplos, consulte el comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html).
**Sintaxis**
```
FT.SEARCH
[RETURN ( [AS ])+]
[TIMEOUT timeout]
[PARAMS [ ]]
[LIMIT ]
[COUNT]
```
+ RETURN: esta cláusula identifica qué campos de una clave se devuelven. La cláusula AS opcional de cada campo anula el nombre del campo en el resultado. Solo se pueden especificar los campos que se han declarado para este índice.
+ LIMIT: : Esta cláusula proporciona capacidad de paginación, ya que solo se devuelven las claves que cumplen los valores de compensación y recuento. Si se omite esta cláusula, el valor predeterminado es “LIMIT 0 10”, es decir, solo se devolverá un máximo de 10 claves.
+ PARAMS: dos veces la cantidad de pares de valores clave. Se puede hacer referencia a los key/value pares de parámetros desde la expresión de consulta. Para obtener más información, consulte [Expresión de consulta de búsqueda vectorial](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).
+ COUNT: esta cláusula impide que se devuelva el contenido de las claves, solo se devuelve la cantidad de claves. Es un alias para “LIMIT 0 0”.
**Devolución**
Devuelve una matriz o una respuesta de error.
+ Si la operación se completa correctamente, devuelve una matriz. El primer elemento es la cantidad total de claves que coinciden con la consulta. Los elementos restantes son pares de nombre de clave y la lista de campos. La lista de campos es otra matriz que comprende pares de nombres y valores de campo.
+ Si el índice está en proceso de reposición, el comando devuelve inmediatamente una respuesta de error.
+ Si se agota el tiempo de espera, el comando devuelve una respuesta de error.
**Ejemplo: haz algunas búsquedas**
**nota**
En el siguiente ejemplo, se utilizan argumentos nativos de [valkey-cli](https://valkey.io/topics/cli/), como eliminar las comillas y los valores de escape de los datos, antes de enviarlos a Valkey o Redis OSS. Para usar otros clientes de lenguajes de programación (Python, Ruby, C\$1, etc.), siga las reglas de manejo de esos entornos para tratamiento de cadenas y datos binarios. Para obtener más información sobre los clientes compatibles, consulte [Herramientas sobre las que basarse AWS](https://aws.amazon.com/developer/tools/)
**Una búsqueda HASH**
```
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"
```
Esto produce dos resultados, ordenados por su puntuación, que es la distancia desde el vector de consulta (ingresado como hexadecimal).
**Búsquedas 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]}]"
```
Esto produce los dos resultados más cercanos, ordenados por su puntuación. Tenga en cuenta que los valores vectoriales JSON se convierten en flotantes y el vector de consulta sigue constando de datos vectoriales. Tenga en cuenta también que, dado que el parámetro `KNN` es 2, solo hay dos resultados. Un valor mayor devolverá más resultados:
```
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.AGGREGATE
Como superconjunto del comando FT.SEARCH, permite un procesamiento adicional sustancial de las claves seleccionadas por la expresión de consulta.
**Sintaxis**
```
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]
```
+ Las cláusulas FILTER, LIMIT, GROUPBY, SORTBY y APPLY se pueden repetir varias veces en cualquier orden y mezclarse libremente. Se aplican en el orden especificado y el resultado de una cláusula alimenta la entrada de la siguiente cláusula.
+ En la sintaxis anterior, una “propiedad” es un campo declarado en el comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) para este índice O el resultado de una cláusula APPLY o función REDUCE anterior.
+ La cláusula LOAD se limita a cargar campos que se han declarado en el índice. “LOAD \$1” cargará todos los campos declarados en el índice.
+ Se admiten las siguientes funciones reductoras: COUNT, COUNT\$1DISTINCTISH, SUM, MIN, MAX, AVG, STDDEV, QUANTILE, TOLIST, FIRST\$1VALUE y RANDOM\$1SAMPLE. Para obtener más información, consulte [Agregaciones](https://redis.io/docs/interact/search-and-query/search/aggregations/).
+ LIMIT : conserva los registros que comienzan en y continúan hasta , todos los demás registros se descartan.
+ PARAMS: dos veces la cantidad de pares de valores clave. Se puede hacer referencia a los key/value pares de parámetros desde la expresión de consulta.
**Devolución**
Devuelve una matriz o una respuesta de error.
+ Si la operación se completa correctamente, devuelve una matriz. El primer elemento es un número entero sin ningún significado particular (debe ignorarse). Los elementos restantes son los resultados obtenidos en la última etapa. Cada elemento es una matriz de pares de nombre y valor de campo.
+ Si el índice está en proceso de reposición, el comando devuelve inmediatamente una respuesta de error.
+ Si se agota el tiempo de espera, el comando devuelve una respuesta de error.
# FT.DROPINDEX
Elimine un índice. Se eliminan la definición del índice y el contenido asociado. Las claves no se ven afectadas.
**Sintaxis**
```
FT.DROPINDEX
```
**Devolución**
Devuelve un mensaje de OK de cadena simple o una respuesta de error.
# FT.INFO
**Sintaxis**
```
FT.INFO
```
El resultado de la página FT.INFO es una matriz de pares de valores clave, tal como se describe en la siguiente tabla:
| Key | Tipo de valor | Description (Descripción) |
| --- | --- | --- |
| index\$1name | cadena | Nombre del índice |
| creation\$1timestamp | entero | Marca temporal de la hora de creación de estilo Unix |
| key\$1type | cadena | HASH o JSON |
| key\$1prefixes | matriz de cadenas | Prefijos clave para este índice |
| campos | matriz de información de campo | Campos de este índice |
| space\$1usage | entero | Bytes de memoria utilizados por este índice |
| fullext\$1space\$1usage | entero | Bytes de memoria utilizados por campos no vectoriales |
| vector\$1space\$1usage | entero | Bytes de memoria utilizados por campos vectoriales |
| num\$1docs | entero | Número de claves que contiene actualmente el índice |
| num\$1indexed\$1vectors | entero | Número de vectores que contiene actualmente el índice |
| current\$1lag | entero | Retraso reciente de la incorporación (milisegundos) |
| backfill\$1status | cadena | Uno de los siguientes: completado InProgres, pausado o fallido |
La tabla siguiente describe información para cada campo:
| Key | Tipo de valor | Description (Descripción) |
| --- | --- | --- |
| identificador | cadena | nombre del campo |
| field\$1name | cadena | Nombre del miembro del HASH o ruta JSON |
| type | cadena | uno de los siguientes: numérico, de etiqueta, de texto o vectorial |
| option | cadena | ignore |
Si el campo es del tipo Vector, habrá información adicional en función del algoritmo.
Para el algoritmo HNSW:
| Key | Tipo de valor | Description (Descripción) |
| --- | --- | --- |
| algoritmo | cadena | HNSW |
| data\$1type | cadena | FLOAT32 |
| distance\$1metric | cadena | uno de los siguientes: L2, IP o Cosine |
| initial\$1capacity | entero | Tamaño inicial del índice de campo vectorial |
| current\$1capacity | entero | Tamaño actual del índice de campo vectorial |
| maximum\$1edges | entero | Parámetro M en el momento de la creación |
| ef\$1construction | entero | Parámetro EF\$1CONSTRUCTION en el momento de la creación |
| ef\$1runtime | entero | Parámetro EF\$1RUNTIME en el momento de la creación |
Para el algoritmo FLAT:
| Key | Tipo de valor | Description (Descripción) |
| --- | --- | --- |
| algoritmo | cadena | FLAT |
| data\$1type | cadena | FLOAT32 |
| distance\$1metric | cadena | uno de los siguientes: L2, IP o Cosine |
| initial\$1capacity | entero | Tamaño inicial del índice de campo vectorial |
| current\$1capacity | entero | Tamaño actual del índice de campo vectorial |
# FT.\$1LIST
Enumera todos los índices.
**Sintaxis**
```
FT._LIST
```
**Devolución**
Devuelve una matriz de nombres de índice
# FT.ALIASADD
Añada un alias para un índice. El nuevo nombre de alias se puede usar en cualquier lugar donde se requiera un nombre de índice.
**Sintaxis**
```
FT.ALIASADD
```
**Devolución**
Devuelve un mensaje de OK de cadena simple o una respuesta de error.
# FT.ALIASDEL
Elimine un alias existente para un índice.
**Sintaxis**
```
FT.ALIASDEL
```
**Devolución**
Devuelve un mensaje de OK de cadena simple o una respuesta de error.
# FT.ALIASUPDATE
Actualice un alias existente para que apunte a un índice físico diferente. Este comando solo afecta a las futuras referencias sobre el alias. Este comando no afecta a las operaciones actualmente en curso (FT.SEARCH, FT.AGGREGATE).
**Sintaxis**
```
FT.ALIASUPDATE
```
**Devolución**
Devuelve un mensaje de OK de cadena simple o una respuesta de error.
# FT.\$1ALIASLIST
Enumera los alias del índice.
**Sintaxis**
```
FT._ALIASLIST
```
**Devolución**
Devuelve una matriz del tamaño del número de alias actuales. Cada elemento de la matriz es el par alias-índice.
# FT.PROFILE
Ejecuta una consulta y devuelve la información de perfil sobre esa consulta.
**Sintaxis**
```
FT.PROFILE
SEARCH | AGGREGATE
[LIMITED]
QUERY
```
**Devolución**
Matriz de dos elementos. El primer elemento es el resultado del comando `FT.SEARCH` o `FT.AGGREGATE` que se perfiló. El segundo elemento es una matriz de información de rendimiento y creación de perfiles.
# FT.EXPLAIN
Analiza una consulta y devuelve información sobre cómo se analizó esa consulta.
**Sintaxis**
```
FT.EXPLAIN
```
**Devolución**
Una cadena que contiene los resultados analizados.
# FT.EXPLAINCLI
Igual que el comando FT.EXPLAIN, excepto que los resultados se muestran en un formato diferente, más útil con redis-cli.
**Sintaxis**
```
FT.EXPLAINCLI
```
**Devolución**
Una cadena que contiene los resultados analizados.