

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Pesquisa vetorial
<a name="vector-search"></a>

A pesquisa vetorial do MemoryDB amplia a funcionalidade do MemoryDB. Ela pode ser usada em conjunto com a funcionalidade existente do MemoryDB. As aplicações que não usam a pesquisa vetorial não são afetadas por sua presença. A pesquisa vetorial está disponível em todas as regiões em que o MemoryDB está disponível.

A pesquisa vetorial simplifica a arquitetura da aplicação e, ao mesmo tempo, oferece uma pesquisa vetorial de alta velocidade. A pesquisa vetorial para MemoryDB é ideal para casos de uso em que performance e escala máximas são os critérios de seleção mais importantes. Você pode usar seus dados existentes do MemoryDB, ou uma API do Valkey ou Redis, para criar casos de uso de machine learning e IA generativa. Isso inclui geração aumentada de recuperação, detecção de anomalias, recuperação de documentos e recomendações em tempo real.

Em 26/06/2024, o AWS MemoryDB oferece o desempenho de pesquisa vetorial mais rápido com as maiores taxas de recall entre os bancos de dados vetoriais populares em. AWS

**Topics**
+ [Visão geral sobre a pesquisa vetorial](vector-search-overview.md)
+ [Casos de uso](vector-search-examples.md)
+ [Atributos e limites da pesquisa vetorial](vector-search-limits.md)
+ [Criar um cluster habilitado para pesquisa vetorial](vector-search-cluster.md)
+ [Comandos de pesquisa vetorial](vector-search-commands.md)

# Visão geral sobre a pesquisa vetorial
<a name="vector-search-overview"></a>

A pesquisa vetorial baseia-se na criação, na manutenção e no uso de índices. Cada operação de pesquisa vetorial especifica um único índice e está confinada a esse índice, ou seja, as operações em um índice não são afetadas pelas operações em nenhum outro índice. Com exceção das operações para criar e destruir índices, qualquer número de operações pode ser emitido em qualquer índice a qualquer momento, o que significa que, no nível do cluster, várias operações em vários índices podem estar em andamento simultaneamente.

Índices individuais são objetos nomeados existentes em um namespace exclusivo, que é separado dos outros namespaces do Valkey e Redis OSS: chaves, funções etc. Cada índice é conceitualmente semelhante a uma tabela de banco de dados convencional, pois está estruturado em duas dimensões: coluna e linhas. Cada linha da tabela corresponde a uma chave. Cada coluna no índice corresponde a um membro ou a uma parte dessa chave. Neste documento, os termos chave, linha e registro são idênticos e usados de maneira intercambiável. Da mesma forma, os termos coluna, campo, caminho e membro são essencialmente idênticos e também são usados de maneira intercambiável.

Não há comandos especiais para adicionar, excluir ou modificar dados indexados. Em vez disso, os comandos **HASH** ou **JSON** existentes que modificam uma chave em um índice também atualizam automaticamente esse índice.

**Topics**
+ [Índices e o espaço de chaves do Valkey e Redis OSS](#vector-search-indexes-keyspaces)
+ [Tipos de campos de índice](#vector-search-index-field-types)
+ [Algoritmos de índice vetorial](#vector-search-index-algorithms)
+ [Expressão de consulta de pesquisa vetorial](#vector-search-query-expression)
+ [Comando INFO](#vector-search-ft.info)
+ [Segurança da pesquisa vetorial](#vector-search-security)

## Índices e o espaço de chaves do Valkey e Redis OSS
<a name="vector-search-indexes-keyspaces"></a>

Índices são construídos e mantidos em um subconjunto do espaço de chaves do Valkey e Redis OSS. Vários índices podem escolher subconjuntos separados ou sobrepostos do espaço de chaves, sem limitação. O espaço de chaves para cada índice é definido por uma lista de prefixos de chave que são fornecidos quando esse índice é criado. A lista de prefixos é opcional e, se omitida, todo o espaço de chaves fará parte desse índice. Os índices também são digitados, pois cobrem apenas as chaves que têm um tipo correspondente. Atualmente, apenas há suporte para índices JSON e HASH. Um índice HASH indexa somente as chaves HASH cobertas por sua lista de prefixos e, da mesma maneira, um índice JSON indexa somente as chaves JSON cobertas por sua lista de prefixos. As chaves na lista de prefixos do espaço de chaves de um índice que não têm o tipo designado são ignoradas e não afetam as operações de pesquisa.

Quando um comando HASH ou JSON modifica uma chave que está dentro de um espaço de chaves de um índice, esse índice é atualizado. Esse processo envolve a extração dos campos declarados para cada índice e a atualização do índice com o novo valor. O processo de atualização é feito em um thread em segundo plano, o que significa que os índices são consistentes apenas eventualmente com o conteúdo do espaço de chaves. Assim, a inserção ou atualização de uma chave não ficará visível nos resultados da pesquisa por um curto período. Durante períodos de grande carga do sistema (mutação and/or intensa de dados), o atraso na visibilidade pode se tornar maior.

A criação de um índice é um processo em várias etapas. A primeira delas é executar o comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html), que define o índice. A execução bem-sucedida de uma criação inicia automaticamente a segunda etapa: o preenchimento. O processo de preenchimento é executado em um thread em segundo plano e verifica o espaço de chaves em busca de chaves que estejam na lista de prefixos do novo índice. Cada chave encontrada é adicionada ao índice. Por fim, todo o espaço de chaves é verificado, concluindo o processo de criação do índice. Enquanto o processo de preenchimento está em execução, são permitidas mutações das chaves indexadas, não há restrições, e o processo de preenchimento do índice não será concluído até que todas as chaves estejam devidamente indexadas. Tentativas de operações de consulta feitas enquanto um índice está sendo preenchido não são permitidas e serão encerradas com um erro. A conclusão do processo de preenchimento pode ser determinada pela saída do comando `FT.INFO` desse índice ('backfill\$1status').

## Tipos de campos de índice
<a name="vector-search-index-field-types"></a>

Cada campo (coluna) de um índice tem um tipo específico que é declarado quando esse índice é criado e um local dentro de uma chave. Para chaves HASH, a localização é o nome do campo dentro do HASH. Para chaves JSON, a localização é uma descrição do caminho do JSON. Quando uma chave é modificada, os dados associados aos campos declarados são extraídos, convertidos no tipo declarado e armazenados no índice. Se os dados estiverem ausentes ou não puderem ser convertidos com êxito no tipo declarado, esse campo será omitido do índice. Há quatro tipos de campos, conforme explicado a seguir: 
+ **Campos numéricos** contêm um único número. Para campos JSON, devem ser seguidas as regras numéricas de números JSON. Para HASH, espera-se que o campo contenha o texto ASCII de um número escrito no formato padrão para números fixos ou de pontos flutuantes. Independentemente da representação na chave, esse campo é convertido em um número de pontos flutuantes de 64 bits para armazenamento no índice. Campos numéricos podem ser usados com o operador de pesquisa de intervalo. Como os números subjacentes são armazenados em ponto flutuante com suas limitações de precisão, as regras comuns sobre comparações numéricas para números de pontos flutuantes são aplicáveis.
+ **Campos de etiqueta** contêm zero ou mais valores de etiqueta codificados como uma única string UTF-8. A string é analisada em valores de etiquetas usando um caractere separador (o padrão é uma vírgula, mas pode ser substituído) com espaços em branco à esquerda e à direita removidos. Qualquer número de valores de etiquetas pode estar contido em um único campo de etiqueta. Campos de etiquetas podem ser usados para filtrar consultas de equivalência de valores de etiquetas com comparação com ou sem distinção entre maiúsculas e minúsculas.
+ **Campos de texto** contêm um blob de bytes que não precisa ser compatível com UTF-8. Esses campos podem ser usados para decorar resultados de consultas com valores significativos para a aplicação. Por exemplo, um URL ou o conteúdo de um documento etc.
+ **Campos vetoriais** contêm um vetor de números, também conhecido como incorporação. Esses campos oferecem suporte à pesquisa do vizinho mais próximo (KNN) de vetores com tamanho fixo usando um algoritmo e uma métrica de distância especificados. No caso de índices HASH, o campo deve conter todo o vetor codificado em formato binário (*little-endian* IEEE 754). No caso de chaves JSON, o caminho deve fazer referência a uma matriz do tamanho correto preenchida com números. Quando uma matriz JSON é usada como um campo vetorial, a representação interna dessa matriz na chave JSON é convertida no formato exigido pelo algoritmo selecionado, reduzindo o consumo e a precisão da memória. Operações de leitura subsequentes usando os comandos JSON produzirão o valor de precisão reduzido.

## Algoritmos de índice vetorial
<a name="vector-search-index-algorithms"></a>

São fornecidos dois algoritmos de índice vetorial:
+ **Flat**: o algoritmo Flat é um processamento linear por força bruta de cada vetor no índice, produzindo respostas exatas dentro dos limites da precisão dos cálculos de distância. Devido ao processamento linear do índice, os tempos de execução desse algoritmo podem ser muito altos para índices grandes.
+ **HNSW (Hierarchical Navigable Small Worlds)**: o algoritmo HNSW é uma alternativa que fornece uma aproximação da resposta correta em troca de tempos de execução substancialmente menores. O algoritmo é controlado por três parâmetros: `M`, `EF_CONSTRUCTION` e `EF_RUNTIME`. Os dois primeiros parâmetros são especificados no momento da criação do índice e não podem ser alterados. O parâmetro `EF_RUNTIME` tem um valor padrão que é especificado no momento da criação do índice, mas pode ser substituído mais tarde em qualquer operação de consulta individual. Esses três parâmetros interagem para equilibrar o consumo de memória e CPU durante operações de ingestão e consulta, bem como para controlar a qualidade da aproximação de uma pesquisa KNN exata (conhecida como taxa de recall).

Ambos os algoritmos de pesquisa vetorial (Flat e HNSW) aceitam um parâmetro opcional `INITIAL_CAP`. Quando especificado, esse parâmetro pré-aloca memória para os índices, resultando na redução da sobrecarga de gerenciamento de memória e no aumento das taxas de ingestão de vetores.

Algoritmos de pesquisa vetorial, como o HNSW, podem não lidar de maneira eficiente com a exclusão ou substituição de vetores inseridos anteriormente. O uso dessas operações pode resultar em consumo excessivo de memória de índice, and/or degradando a qualidade de recall. A reindexação é um método para restaurar a recuperação ideal do uso da memória. and/or 

## Expressão de consulta de pesquisa vetorial
<a name="vector-search-query-expression"></a>

Os comandos [FT.SEARCH](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.search.html) e [FT.AGGREGATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.aggregate.html) exigem uma expressão de consulta. Essa expressão é um único parâmetro de cadeia de caracteres que é composto por um ou mais operadores. Cada operador usa um campo no índice para identificar um subconjunto das chaves no índice. Vários operadores podem ser combinados usando combinadores boolianos e parênteses para aprimorar ou restringir ainda mais o conjunto coletado de chaves (ou o conjunto de resultados).

### Curinga
<a name="vector-search-query-expression-wildcard"></a>

O operador curinga, o asterisco ('\$1'), corresponde a todas as chaves no índice. 

### Intervalo numérico
<a name="vector-search-query-expression-numeric-range"></a>

O operador de intervalo numérico tem a sintaxe a seguir.

```
<range-search> ::= '@' <numeric-field-name> ':' '[' <bound> <bound> ']'
<bound>  ::= <number> | '(' <number>
<number> ::= <integer> | <fixed-point> | <floating-point> | 'Inf' | '-Inf' | '+Inf'
```

O < numeric-field-name > deve ser um campo do tipo declarado`NUMERIC`. O limite é inclusivo por padrão, mas um parêntese de abertura inicial ['('] pode ser usado para tornar um limite exclusivo. A pesquisa de intervalo pode ser convertida em uma única comparação relacional (<, <=, >, >=) usando `Inf`, `+Inf` ou `-Inf` como um dos limites. Independentemente do formato numérico especificado (inteiro, ponto fixo, ponto flutuante, infinito), o número é convertido em ponto flutuante de 64 bits para realizar comparações, reduzindo a precisão de acordo.

**Example Exemplos**  

```
@numeric-field:[0 10]                      // 0   <= <value> <= 10
@numeric-field:[(0 10]                     // 0   <  <value> <= 10
@numeric-field:[0 (10]                     // 0   <= <value> <  10
@numeric-field:[(0 (10]                    // 0   <  <value> <  10
@numeric-field:[1.5 (Inf]                  // 1.5 <= value
```

### Comparação de etiquetas
<a name="vector-search-query-expression-tag-compare"></a>

O operador de comparação de etiquetas tem a seguinte sintaxe.

```
<tag-search> ::= '@' <tag-field-name> ':' '{' <tag> [ '|' <tag> ]* '}'
```

Se alguma das etiquetas no operador corresponder a qualquer uma das etiquetas no campo de etiqueta do registro, este último será incluído no conjunto de resultados. O campo criado por `<tag-field-name>` deve ser um campo do índice declarado com o tipo `TAG`. Exemplos de comparação de etiquetas são:

```
@tag-field:{ atag }
@tag-field: { tag1 | tag2 }
```

### Combinações boolianas
<a name="vector-search-query-expression-boolean-combinations"></a>

Os conjuntos de resultados de um operador numérico ou de tag podem ser combinados usando a lógica booleana: and/or. Parentheses can be used to group operators and/or altere a ordem de avaliação. A sintaxe dos operadores lógicos boolianos é:

```
<expression> ::= <phrase> | <phrase> '|' <expression> | '(' <expression> ')'
<phrase> ::= <term> | <term> <phrase>
<term> ::= <range-search> | <tag-search> | '*'
```

Vários termos combinados em uma frase são indicados com “e”. Várias frases combinadas com a barra vertical ('\$1') são indicadas com “ou”.

### Pesquisa vetorial
<a name="vector-search-query-expression-vector-search"></a>

Os índices de vetores oferecem suporte a dois métodos de pesquisa diferentes: vizinho mais próximo e intervalo. Uma pesquisa do vizinho mais próximo localiza um número, K, dos vetores no índice que estão mais próximos do vetor fornecido (de referência). Isso é coloquialmente chamado de KNN para “K” vizinhos mais próximos. A sintaxe para uma pesquisa KNN é:

```
<vector-knn-search> ::= <expression> '=>[KNN' <k> '@' <vector-field-name> '$' <parameter-name> <modifiers> ']'
<modifiers> ::= [ 'EF_RUNTIME' <integer> ] [ 'AS' <distance-field-name>]
```

Uma pesquisa vetorial KNN só é aplicada aos vetores que satisfazem o `<expression>` que pode ser qualquer combinação dos operadores definidos acima: curinga, pesquisa por intervalo, pesquisa por tag, combinações and/or booleanas dos mesmos.
+ `<k>` é um número inteiro que especifica o número de vetores vizinhos mais próximos a serem retornados.
+ `<vector-field-name>` deve especificar um campo de tipo declarado `VECTOR`.
+ O campo `<parameter-name>` especifica uma das entradas para a tabela `PARAM` do comando `FT.SEARCH` ou `FT.AGGREGATE`. Esse parâmetro é o valor vetorial de referência para cálculos de distância. O valor do vetor é codificado no valor `PARAM` no formato binário *little-endian IEEE 754* (a mesma codificação de um campo vetorial HASH)
+ Para índices vetoriais do tipo HNSW, a cláusula `EF_RUNTIME` opcional pode ser usada para substituir o valor padrão do parâmetro `EF_RUNTIME` que foi estabelecido quando o índice foi criado.
+ O `<distance-field-name>` opcional fornece um nome de campo para o conjunto de resultados a fim de conter a distância calculada entre o vetor de referência e a chave localizada.

Uma pesquisa de intervalo localiza todos os vetores dentro de uma distância especificada (raio) de um vetor de referência. A sintaxe para uma pesquisa de intervalo é:

```
<vector-range-search> ::= ‘@’ <vector-field-name> ‘:’ ‘[’ ‘VECTOR_RANGE’ ( <radius> | ‘$’ <radius-parameter> )  $<reference-vector-parameter> ‘]’ [ ‘=’ ‘>’ ‘{’ <modifiers> ‘}’ ] 
<modifiers> ::= <modifier> | <modifiers>, <modifier> 
<modifer> ::= [ ‘$yield_distance_as’ ‘:’ <distance-field-name> ] [ ‘$epsilon’ ‘:’ <epsilon-value> ]
```

Em que:
+ `<vector-field-name>` é o nome do campo vetorial a ser pesquisado.
+ `<radius> or $<radius-parameter>` é o limite numérico de distância para pesquisa.
+ `$<reference-vector-parameter> ` é o nome do parâmetro que contém o vetor de referência. O valor do vetor é codificado no valor PARAM no formato binário little-endian IEEE 754 (a mesma codificação de um campo vetorial HASH).
+ O `<distance-field-name>` opcional fornece um nome de campo para o conjunto de resultados a fim de conter a distância calculada entre o vetor de referência e cada chave.
+ O `<epsilon-value> ` opcional controla o limite da operação de pesquisa, vetores dentro da distância `<radius> * (1.0 + <epsilon-value>) ` são percorridos em busca de resultados candidatos. O padrão é 0,01.

## Comando INFO
<a name="vector-search-ft.info"></a>

A pesquisa vetorial aumenta o comando [INFO](https://valkey.io/commands/info/) do Valkey e Redis OSS com várias seções adicionais de estatísticas e contadores. Uma solicitação para recuperar a seção `SEARCH` recuperará todas as seções a seguir:

### Seção `search_memory`
<a name="vector-search-ft.info-search-memory"></a>


| Name (Nome) | Description | 
| --- | --- | 
| search\$1used\$1memory\$1bytes | Número de bytes de memória consumidos em todas as estruturas de dados de pesquisa | 
| search\$1used\$1memory\$1human | Versão legível por humanos do valor acima | 

### Seção `search_index_stats`
<a name="vector-search-ft.info-search_index_stats"></a>


| Name (Nome) | Description | 
| --- | --- | 
| search\$1number\$1of\$1indexes | Número de índices criados | 
| search\$1num\$1fulltext\$1indexes | Número de campos não vetoriais em todos os índices | 
| search\$1num\$1vector\$1indexes | Número de campos vetoriais em todos os índices | 
| search\$1num\$1hash\$1indexes | Número de índices em chaves de tipo HASH | 
| search\$1num\$1json\$1indexes | Número de índices em chaves de tipo JSON | 
| search\$1total\$1indexed\$1keys | Número total de chaves em todos os índices | 
| vetores\$1indexados totais de pesquisa | Número total de vetores em todos os índices | 
| search\$1total\$1indexed\$1hash\$1keys | Número total de chaves de tipo HASH em todos os índices | 
| search\$1total\$1indexed\$1json\$1keys | Número total de chaves de tipo JSON em todos os índices | 
| search\$1total\$1index\$1size | Bytes usados por todos os índices | 
| search\$1total\$1fulltext\$1index\$1size | Bytes usados por estruturas de índices não vetoriais | 
| search\$1total\$1vector\$1index\$1size | Bytes usados por estruturas de índices vetoriais | 
| search\$1max\$1index\$1lag\$1ms | Atraso na ingestão durante a última atualização do lote de ingestão | 

### Seção `search_ingestion`
<a name="vector-search-ft.info-search_ingestion"></a>


| Name (Nome) | Description | 
| --- | --- | 
| search\$1background\$1indexing\$1status | Status da ingestão. NO\$1ACTIVITY significa ocioso. Outros valores indicam que há chaves em processo de ingestão. | 
| search\$1ingestion\$1paused | Exceto durante a reinicialização, sempre deve ser “no”. | 

### Seção `search_backfill`
<a name="vector-search-ft.info-search_backfill"></a>

**nota**  
Alguns dos campos documentados nesta seção apenas são visíveis quando um preenchimento está em andamento.


| Name (Nome) | Description | 
| --- | --- | 
| search\$1num\$1active\$1backfills | Número de atividades atuais de preenchimento | 
| search\$1backfills\$1paused | Exceto quando estiver sem memória, sempre deve ser “no”. | 
| search\$1current\$1backfill\$1progress\$1percentage | Percentual de conclusão (0 a 100) do preenchimento atual. | 

### Seção `search_query`
<a name="vector-search-ft.info-search_query"></a>


| Name (Nome) | Description | 
| --- | --- | 
| search\$1num\$1active\$1queries | Número de comandos FT.SEARCH e FT.AGGREGATE em andamento | 

## Segurança da pesquisa vetorial
<a name="vector-search-security"></a>

Os mecanismos de segurança de [ACL (listas de controle de acesso)](https://valkey.io/topics/acl/) para acesso a comandos e dados são estendidos para controlar o recurso de pesquisa. Há suporte total para o controle de ACL de comandos de pesquisa individuais. É fornecida uma nova categoria de ACL, `@search`, e muitas das categorias existentes (`@fast`, `@read`, `@write` etc.) são atualizadas para incluir os novos comandos. Os comandos de pesquisa não modificam os dados de chaves, o que significa que o mecanismo de ACL existente para acesso de gravação é preservado. As regras de acesso para operações HASH e JSON não são modificadas pela presença de um índice. O controle normal de acesso em nível de chave ainda é aplicado a esses comandos.

Comandos de pesquisa com um índice também têm o acesso controlado por meio da ACL. Verificações de acesso são realizadas no nível do índice inteiro, e não no nível por chave. Isso significa que o acesso a um índice será concedido a um usuário somente se este tiver permissão para acessar todas as chaves possíveis na lista de prefixos do espaço de chaves desse índice. Em outras palavras, o conteúdo real de um índice não controla o acesso. Pelo contrário, é o conteúdo teórico de um índice, conforme definido pela lista de prefixos, que é usado para a verificação de segurança. Pode ser fácil criar uma situação em que um usuário tenha acesso de leitura e and/or gravação a uma chave, mas não consiga acessar um índice contendo essa chave. Observe que somente o acesso para leitura ao espaço de chaves é necessário para criar ou usar um índice: a presença ou ausência do acesso para gravação não é levada em consideração. 

Para obter mais informações sobre como usar ACLs com o MemoryDB, consulte [Autenticação de usuários com listas de controle de acesso](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html) (). ACLs

# Casos de uso
<a name="vector-search-examples"></a>

Veja a seguir estão os casos de uso da pesquisa vetorial.

## Geração Aumentada de Recuperação (RAG)
<a name="vector-search-examples-retrieval-augmented-generation"></a>

A Retrieval Augmented Generation (RAG) aproveita a pesquisa vetorial para recuperar passagens relevantes de um grande corpus de dados para ampliar um grande modelo de linguagem (LLM). Especificamente, um codificador incorpora o contexto de entrada e a consulta de pesquisa em vetores e, em seguida, usa a pesquisa aproximada do vizinho mais próximo para encontrar passagens semanticamente semelhantes. Essas passagens recuperadas são concatenadas com o contexto original para fornecer informações adicionais relevantes ao LLM a fim de retornar uma resposta mais precisa ao usuário.

![\[Gráfico do fluxo da Retrieval Augmented Generation\]](http://docs.aws.amazon.com/pt_br/memorydb/latest/devguide/images/RAG.png)


## Cache de semântica durável
<a name="vector-search-examples-durable-semantic-cache"></a>

O armazenamento em cache de semântica é um processo para reduzir os custos computacionais, armazenando resultados anteriores do FM. Ao reutilizar resultados anteriores de inferências anteriores em vez de recalculá-los, o cache semântico reduz a quantidade de computação necessária durante a inferência por meio do. FMs O MemoryDB permite um armazenamento em cache de semântica durável, o que evita a perda de dados das inferências anteriores. Isso permite que as aplicações de IA generativa respondam em menos de 10 milissegundos com respostas a perguntas anteriores que apresentam semelhança semântica, ao mesmo tempo em que reduzem os custos ao evitar inferências desnecessárias de LLM.

![\[Diagrama de fluxo de trabalho mostrando o processo do modelo de base.\]](http://docs.aws.amazon.com/pt_br/memorydb/latest/devguide/images/FM.png)

+ **Acerto da pesquisa semântica**: se a consulta de um cliente for semanticamente semelhante com base em uma pontuação de semelhança definida com uma pergunta anterior, a memória de buffer do FM (MemoryDB) retornará a resposta à pergunta anterior na etapa 4 e não chamará o FM na etapa 3. Isso evitará a latência do modelo de base (FM) e os custos incorridos, proporcionando uma experiência mais rápida para o cliente.
+ **Erro na pesquisa semântica**: se a consulta de um cliente não for semanticamente semelhante com base em uma pontuação de semelhança definida com uma consulta anterior, o cliente chamará o FM para fornecer uma resposta ao cliente na etapa 3a. A resposta gerada do FM será então armazenada como um vetor no MemoryDB para futuras consultas (etapa 3b), para minimizar os custos de FM em questões semanticamente semelhantes. Nesse fluxo, a etapa 4 não seria invocada, pois não havia uma pergunta semanticamente semelhante para a consulta original. 

## Detecção de fraudes
<a name="vector-search-examples-fraud-detection"></a>

A detecção de fraudes, uma forma de detecção de anomalias, representa transações válidas como vetores enquanto compara as representações vetoriais de transações inéditas. A fraude é detectada quando essas transações inéditas têm baixa semelhança com os vetores que representam os dados transacionais válidos. Isso permite que a fraude seja detectada por meio da modelagem do comportamento normal, em vez de tentar prever todas as ocorrências possíveis de uma fraude. O MemoryDB permite que as organizações façam isso em períodos de alta throughput, com o mínimo de falsos positivos e latência de menos de 10 milissegundos.

![\[Diagrama de fluxo de trabalho mostrando o processo de detecção de fraude.\]](http://docs.aws.amazon.com/pt_br/memorydb/latest/devguide/images/fraud-detection.png)


## Outros casos de uso
<a name="vector-search-engines"></a>
+ Os **mecanismos de recomendação** podem encontrar produtos ou conteúdos semelhantes aos usuários representando itens como vetores. Os vetores são criados pela análise de atributos e padrões. Com base nos padrões e atributos do usuário, novos itens não vistos podem ser recomendados aos usuários, encontrando os vetores mais semelhantes já classificados positivamente alinhados ao usuário.
+ **Mecanismos de pesquisa de documentos** representam documentos de texto como vetores densos de números, capturando o significado semântico. No momento da pesquisa, o mecanismo converte uma consulta de pesquisa em um vetor e encontra documentos com os vetores mais semelhantes a essa consulta usando a pesquisa aproximada do vizinho mais próximo. Essa abordagem de semelhança vetorial permite combinar documentos com base no significado, em vez de apenas combinar palavras-chave.

# Atributos e limites da pesquisa vetorial
<a name="vector-search-limits"></a>

## Disponibilidade da pesquisa vetorial
<a name="vector-search-availability"></a>

A configuração do MemoryDB habilitada para pesquisa vetorial é suportada nos tipos de nós R6g, R7g e T4g e está disponível em todas as regiões em que o MemoryDB está disponível. AWS 

Não é possível modificar os clusters existentes para habilitar a pesquisa. No entanto, clusters habilitados para pesquisa podem ser criados com base em snapshots de clusters com a pesquisa desabilitada.

## Restrições paramétricas
<a name="parameter-restrictions"></a>

A tabela a seguir mostra os limites de vários itens de pesquisa vetorial:


| Item | Valor máximo | 
| --- | --- | 
| Número de dimensões em um vetor | 32768 | 
| Número de índices que podem ser criados | 10 | 
| Número de campos em um índice | 50 | 
| Cláusula TIMEOUT de FT.SEARCH e FT.AGGREGATE (milissegundos) | 10000 | 
| Número de estágios do pipeline no comando FT.AGGREGATE | 32 | 
| Número de campos na cláusula FT.AGGREGATE LOAD | 1024 | 
| Número de campos na cláusula FT.AGGREGATE GROUPBY | 16 | 
| Número de campos na cláusula FT.AGGREGATE SORTBY | 16 | 
| Número de parâmetros na cláusula FT.AGGREGATE PARAM | 32 | 
| Parâmetro HNSW M | 512 | 
| Parâmetro HNSW EF\$1CONSTRUCTION | 4096 | 
| Parâmetro HNSW EF\$1RUNTIME | 4096 | 

## Limites de escala
<a name="scaling-restrictions"></a>

Atualmente, a pesquisa vetorial para MemoryDB está limitada a um único fragmento, e não há suporte para escala horizontal. A pesquisa vetorial oferece suporte para escala vertical e de réplica.

## Restrições operacionais
<a name="operational-restrictions"></a>

**Persistência e preenchimento de índices**

O recurso de pesquisa vetorial mantém a definição de índices e o conteúdo do índice. Isso significa que, durante qualquer solicitação ou evento operacional que faça com que um nó seja iniciado ou reiniciado, a definição e o conteúdo do índice são restaurados a partir do snapshot mais recente e todas as transações pendentes são lidas do log de transações Multi-AZ. Nenhuma ação do usuário é necessária para iniciar isso. A reconstrução é executada como uma operação de preenchimento assim que os dados são restaurados. Isso é funcionalmente equivalente ao sistema executar automaticamente um comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) para cada índice definido. Observe que o nó fica disponível para operações do aplicativo assim que os dados são restaurados, mas provavelmente antes da conclusão do preenchimento do índice, o que significa que os preenchimentos voltarão a ficar visíveis para as aplicações. Por exemplo, comandos de pesquisa usando índices de preenchimento podem ser rejeitados. Para obter mais informações sobre preenchimento, consulte [Visão geral sobre a pesquisa vetorialÍndices e o espaço de chaves do Valkey e Redis OSS](vector-search-overview.md#vector-search-indexes-keyspaces).

A conclusão do preenchimento do índice não é sincronizada entre um primário e uma réplica. Essa falta de sincronização pode se tornar inesperadamente visível para as aplicações e, portanto, é recomendável que estas verifiquem a conclusão do preenchimento nos primários e em todas as réplicas antes de iniciar as operações de pesquisa.

## Instantâneo import/export e migração ao vivo
<a name="snapshot-restrictions"></a>

A presença de índices de pesquisa em um arquivo RDB limita a transportabilidade compatível desses dados. O formato dos índices de vetores definidos pela funcionalidade de pesquisa vetorial do MemoryDB somente é compreendido por outro cluster habilitado para vetores do MemoryDB. Além disso, os arquivos RDB dos clusters de pré-visualização podem ser importados pela versão GA dos clusters do MemoryDB, que reconstruirá o conteúdo do índice ao carregar o arquivo RDB. 

No entanto, arquivos RDB que não contêm índices não são restritos dessa maneira. Assim, os dados em um cluster de prévia podem ser exportados para clusters sem prévia, excluindo os índices antes da exportação.

## Consumo de memória
<a name="memory-consumption"></a>

 O consumo de memória é baseado no número de vetores, no número de dimensões, no valor M e na quantidade de dados não vetoriais, como metadados associados ao vetor ou outros dados armazenados na instância. 

A memória total necessária é uma combinação do espaço necessário para os dados vetoriais reais e o espaço necessário para os índices de vetores. O espaço necessário para dados vetoriais é calculado medindo a capacidade real necessária para armazenar vetores em estruturas de dados HASH ou JSON e a sobrecarga até as placas de memória mais próximas, para alocações de memória ideais. Cada um dos índices de vetores usa referências aos dados vetoriais armazenados nessas estruturas de dados e usa otimizações de memória eficientes para remover qualquer cópia duplicada dos dados vetoriais no índice.

O número de vetores depende de como você decide representar os dados como vetores. Por exemplo, você pode optar por representar um único documento em vários blocos, onde cada um representa um vetor. Como alternativa, você pode optar por representar o documento inteiro como um único vetor. 

O número de dimensões dos vetores depende do modelo de incorporação escolhido. Por exemplo, se você optar por usar o modelo de incorporação [AWS Titan](https://aws.amazon.com/bedrock/titan/), o número de dimensões será 1.536. 

O parâmetro M representa o número de links bidirecionais criados para cada novo elemento durante a construção do índice. O MemoryDB padroniza esse valor para 16, mas você pode substituí-lo. Um parâmetro M mais alto funciona melhor para requisitos de alta dimensionalidade e and/or alto recall, enquanto parâmetros M baixos funcionam melhor para requisitos de baixa dimensionalidade e and/or baixo recall. O valor M aumenta o consumo de memória à medida que o índice aumenta. 

Na experiência do console, o MemoryDB oferece uma maneira fácil de escolher o tipo de instância certo com base nas características da workload vetorial após marcar Habilitar pesquisa vetorial nas configurações do cluster. 

![\[Configurações do cluster de pesquisa vetorial no AWS console.\]](http://docs.aws.amazon.com/pt_br/memorydb/latest/devguide/images/vector-search-cluster-settings-console.png)




**Exemplo de workload**

Um cliente deseja criar um mecanismo de busca semântica baseado em seus documentos financeiros internos. Atualmente, ele tem 1 milhão de documentos financeiros que estão divididos em 10 vetores por documento usando o modelo de incorporação Titan com 1.536 dimensões, sem nenhum dado não vetorial. O cliente decide usar o padrão de 16 como parâmetro M. 
+ Vetores: 1M \$1 10 blocos = 10 milhões de vetores
+ Dimensions: 1.536
+ Dados não vetoriais (GB): 0 GB
+ Parâmetro M: 16

Com esses dados, o cliente pode clicar no botão Usar calculadora vetorial no console para obter um tipo de instância recomendado com base em seus parâmetros:

![\[A calculadora vetorial recomendou o tipo de nó com base na entrada recebida.\]](http://docs.aws.amazon.com/pt_br/memorydb/latest/devguide/images/vector-calc1.png)


![\[A calculadora vetorial com valores inseridos.\]](http://docs.aws.amazon.com/pt_br/memorydb/latest/devguide/images/vector-calc2.png)


Neste exemplo, a calculadora vetorial procurará o menor [tipo de nó r7g do MemoryDB](https://aws.amazon.com/memorydb/pricing/) que possa conter a memória necessária para armazenar os vetores com base nos parâmetros fornecidos. Observe que essa é uma aproximação e você deve testar o tipo de instância para garantir que ela atenda aos seus requisitos.



Com base no método de cálculo acima e nos parâmetros da workload da amostra, esses dados vetoriais exigiriam 104,9 GB para armazenamento e um único índice. Nesse caso, o tipo de instância `db.r7g.4xlarge` seria recomendado, pois tem 105,81 GB de memória utilizável. O próximo menor tipo de nó seria muito pequeno para conter a workload vetorial.

Como cada um dos índices de vetores usa referências aos dados vetoriais armazenados e não cria cópias adicionais dos dados vetoriais no índice de vetores, os índices também consumirão relativamente menos espaço. Isso é muito útil na criação de vários índices e também em situações em que partes dos dados vetoriais foram excluídos e quando a reconstrução do gráfico HNSW ajudaria a criar conexões de nós ideais para gerar resultados de pesquisa vetorial de alta qualidade.

## Sem memória durante o preenchimento
<a name="out-of-memory-backfill"></a>

Semelhante às operações de gravação do Valkey e do Redis OSS, um preenchimento de índice está sujeito a limitações. out-of-memory Se a memória do mecanismo ficar cheia enquanto um preenchimento estiver em andamento, todos os preenchimentos serão pausados. Se a memória ficar disponível, o processo de preenchimento será retomado. Também é possível excluir e indexar quando o preenchimento é pausado devido à falta de memória.

## Transações
<a name="transactions"></a>

Os comandos`FT.CREATE`,, `FT.DROPINDEX` `FT.ALIASADD``FT.ALIASDEL`, e `FT.ALIASUPDATE` não podem ser executados em um contexto transacional, ou seja, não dentro de um MULTI/EXEC bloco ou dentro de um script LUA ou FUNCTION. 

# Criar um cluster habilitado para pesquisa vetorial
<a name="vector-search-cluster"></a>

Você pode criar um cluster habilitado para pesquisa vetorial usando o Console de gerenciamento da AWS, ou AWS Command Line Interface o. Dependendo da abordagem, as considerações para habilitar a pesquisa vetorial devem estar habilitadas.

## Usando o Console de gerenciamento da AWS
<a name="vector-search-console"></a>

Para criar um cluster habilitado para pesquisa vetorial no console, é necessário habilitar a pesquisa vetorial nas configurações do **Cluster**. A pesquisa vetorial está disponível para o MemoryDB versão 7.1 em uma configuração de fragmento único.

![\[A visualização das configurações do cluster com a opção “Habilitar pesquisa vetorial” marcada fornece informações sobre suporte a versões e configurações específicas.\]](http://docs.aws.amazon.com/pt_br/memorydb/latest/devguide/images/vs-2.png)


Para obter mais informações sobre como usar a pesquisa vetorial com o Console de gerenciamento da AWS, consulte[Criação de um cluster (console)](getting-started.md#clusters.createclusters.viewdetails.cluster).

## Usando o AWS Command Line Interface
<a name="vector-search-cli"></a>

Para criar um cluster do MemoryDB habilitado para pesquisa vetorial, você pode usar o comando [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-cluster.html) do MemoryDB, enviando um grupo de parâmetros imutáveis `default.memorydb-redis7.search` para habilitar os recursos de pesquisa vetorial.

```
aws memorydb create-cluster \
  --cluster-name <value> \
  --node-type <value> \
  --engine redis \
  --engine-version 7.1 \
  --num-shards 1 \
  --acl-name <value> \
  --parameter-group-name default.memorydb-redis7.search
```

Opcionalmente, também é possível criar um grupo de parâmetros para habilitar a pesquisa vetorial, conforme mostrado no exemplo a seguir. Você pode aprender mais sobre os grupos de parâmetros [aqui](parametergroups.management.md).

```
aws memorydb create-parameter-group \
  --parameter-group-name my-search-parameter-group \
  --family memorydb_redis7
```

Depois, atualize o parâmetro “search-enabled” para “yes” no grupo de parâmetros recém-criado.

```
aws memorydb update-parameter-group \
  --parameter-group-name my-search-parameter-group \
  --parameter-name-values "ParameterName=search-enabled,ParameterValue=yes"
```

Agora você pode usar esse grupo de parâmetros personalizados em vez do grupo de parâmetros padrão para habilitar a pesquisa vetorial nos clusters do MemoryDB.

# Comandos de pesquisa vetorial
<a name="vector-search-commands"></a>

Veja a seguir uma lista dos comandos compatíveis com a pesquisa vetorial. 

**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
<a name="vector-search-commands-ft.create"></a>

 Cria um índice e inicia um preenchimento desse índice. Para obter mais informações, consulte [Visão geral da pesquisa vetorial](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html) para obter detalhes sobre a construção do índice.

**Sintaxe**

```
FT.CREATE <index-name>
ON HASH | JSON
[PREFIX <count> <prefix1> [<prefix2>...]]
SCHEMA 
(<field-identifier> [AS <alias>] 
  NUMERIC 
| TAG [SEPARATOR <sep>] [CASESENSITIVE] 
| TEXT
| VECTOR [HNSW|FLAT] <attr_count> [<attribute_name> <attribute_value>])

)+
```

**Esquema**
+ Identificador de campo:
  + Para chaves de hash, o identificador de campo é um nome de campo.
  + Para chaves JSON, o identificador de campo é um caminho JSON.

  Para obter mais informações, consulte [Tipos de campos de índice](vector-search-overview.md#vector-search-index-field-types).
+ Tipos de campos:
  + ETIQUETA: para obter mais informações, consulte [Etiquetas](https://redis.io/docs/interact/search-and-query/advanced-concepts/tags/).
  + NUMÉRICO: o campo contém um número.
  + TEXTO: o campo contém qualquer blob de dados.
  + VETOR: campo vetorial que oferece suporte para pesquisa vetorial.
    + Algoritmo: pode ser HNSW (Hierarchical Navigable Small World) ou FLAT (força bruta). 
    + `attr_count`: número de atributos que serão passados como configuração do algoritmo, incluindo nomes e valores. 
    + `{attribute_name} {attribute_value}`— key/value pares específicos de algoritmos que definem a configuração do índice. 

      Para o algoritmo FLAT, os atributos são:

      Obrigatório:
      + DIM: número de dimensões no vetor.
      + DISTANCE\$1METRIC: pode ser um dos [L2 \$1 IP \$1 COSINE].
      + TYPE: Tipo de vetor. O único tipo com suporte é `FLOAT32`.

      Opcional:
      + INITIAL\$1CAP: capacidade vetorial inicial no índice que afeta o tamanho da alocação de memória do índice.

      Para o algoritmo HNSW, os atributos são:

      Obrigatório:
      + TYPE: Tipo de vetor. O único tipo com suporte é `FLOAT32`.
      + DIM: dimensão de vetor, especificada como um número inteiro positivo. Máximo: 32768
      + DISTANCE\$1METRIC: pode ser um dos [L2 \$1 IP \$1 COSINE].

      Opcional:
      + INITIAL\$1CAP: capacidade vetorial inicial no índice que afeta o tamanho da alocação de memória do índice. O padrão é 1024.
      + M: número máximo de bordas de saída permitidas para cada nó no gráfico em cada camada. Na camada zero, o número máximo de bordas de saída será 2M. O padrão é 16 e o máximo é 512.
      + EF\$1CONSTRUCTION: controla o número de vetores examinados durante a construção do índice. Valores mais altos para esse parâmetro melhorarão a taxa de recall às custas de tempos mais longos de criação do índice. O valor padrão é 200. O valor máximo é 4096.
      + EF\$1RUNTIME: controla o número de vetores examinados durante as operações de consulta. Valores mais altos para esse parâmetro podem gerar melhor recuperação à custa de tempos de consulta mais longos. O valor desse parâmetro pode ser substituído para cada consulta. O valor padrão é 10 O valor máximo é 4096.

**Return**

Retorna uma mensagem simples de texto OK ou uma resposta de erro.

**Exemplos**

**nota**  
O exemplo a seguir usa argumentos nativos para [valkey-cli](https://valkey.io/topics/cli/), como remoção de aspas e remoção de escape de dados, antes de enviá-los ao Valkey ou Redis OSS. Para usar outros clientes de linguagem de programação (Python, Ruby, C\$1 etc.), siga as regras de manipulação desses ambientes para lidar com strings e dados binários. Para obter mais informações sobre clientes compatíveis, consulte [Ferramentas para desenvolver AWS](https://aws.amazon.com/developer/tools/)

**Example 1: Crie alguns índices**  
Crie um índice para vetores de tamanho 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
```
Crie um índice JSON de 6 dimensões usando o 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 Exemplo 2: preencha alguns dados**  
Os comandos a seguir são formatados para que possam ser executados como argumentos para o programa de terminal redis-cli. Os desenvolvedores que usam outros clientes de linguagem de programação (Python, Ruby, C\$1 etc.) precisarão seguir as regras de manipulação desses ambientes para lidar com strings e dados binários.  
Criação de alguns dados de hash e 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]}'
```
Observe o seguinte:  
+ As chaves dos dados de hash e JSON têm os prefixos de suas definições de índice.
+ Os vetores estão nos caminhos apropriados das definições do índice.
+ Os vetores de hash são inseridos como dados hexadecimais, enquanto os dados JSON são inseridos como números.
+ Os vetores têm os comprimentos apropriados, as entradas bidimensionais do vetor hash têm dois valores flutuantes de dados hexadecimais, as entradas vetoriais json de seis dimensões têm seis números.

**Example Exemplo 3: exclua e recrie um í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
```
Observe que o novo índice JSON usa o algoritmo `FLAT` em vez do algoritmo `HNSW`. Observe também que ele reindexará os dados 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
<a name="vector-search-commands-ft.search"></a>

Usa a expressão de consulta fornecida para localizar chaves em um índice. Depois de localizado, o and/or conteúdo da contagem dos campos indexados nessas chaves pode ser retornado. Para obter mais informações, consulte [Expressão de consulta de pesquisa vetorial](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).

Para criar os dados que serão usados nesses exemplos, consulte o comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html).

**Sintaxe**

```
FT.SEARCH <index-name> <query>
[RETURN <token_count> (<field-identifier> [AS <alias>])+]
[TIMEOUT timeout] 
[PARAMS <count> <name> <value> [<name> <value>]]
[LIMIT <offset> <count>]
[COUNT]
```
+ RETURN: essa cláusula identifica quais campos de uma chave são retornados. A cláusula AS opcional em cada campo substitui o nome do campo no resultado. Somente campos que foram declarados para esse índice podem ser especificados.
+ LIMIT: <offset><count>: essa cláusula fornece capacidade de paginação, pois somente as chaves que satisfazem os valores de deslocamento e contagem são retornadas. Se ela for omitida, o padrão será “LIMIT 0 10", ou seja, somente um máximo de 10 chaves serão retornadas. 
+ PARAMS: duas vezes o número de pares de valores-chave. Os key/value pares de parâmetros podem ser referenciados de dentro da expressão de consulta. Para obter mais informações, consulte [Expressão de consulta de pesquisa vetorial](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).
+ COUNT: essa cláusula suprime o retorno do conteúdo das chaves, somente o número de chaves é retornado. Ela é um alias para “LIMIT 0 0".

**Return**

Retorna uma matriz ou a resposta de erro.
+ Se a operação for concluída com êxito, retornará uma matriz. O primeiro elemento é o número total de chaves correspondentes à consulta. Os elementos restantes são pares de nome de chave e lista de campos. A lista de campos é outra matriz que compreende pares de nomes e valores de campo. 
+ Se o índice estiver em andamento para preenchimento, o comando retornará imediatamente uma resposta de erro.
+ Se o tempo limite for atingido, o comando retornará uma resposta de erro.

**Exemplo: faça algumas pesquisas**

**nota**  
O exemplo a seguir usa argumentos nativos para [valkey-cli](https://valkey.io/topics/cli/), como remoção de aspas e remoção de escape de dados, antes de enviá-los ao Valkey ou Redis OSS. Para usar outros clientes de linguagem de programação (Python, Ruby, C\$1 etc.), siga as regras de manipulação desses ambientes para lidar com strings e dados binários. Para obter mais informações sobre clientes compatíveis, consulte [Ferramentas para desenvolver AWS](https://aws.amazon.com/developer/tools/)

**Uma pesquisa de 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"
```

Produz dois resultados, classificados por sua pontuação, que é a distância do vetor de consulta (inserido como hexadecimal).

**Pesquisas 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]}]"
```

Produz os dois resultados mais próximos, classificados por sua pontuação. Observe que os valores vetoriais JSON são convertidos em flutuantes e o vetor de consulta ainda é um dado vetorial. Observe também que, como o parâmetro `KNN` é 2, há apenas dois resultados. Um valor maior retornará mais 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
<a name="vector-search-commands-ft.aggregate"></a>

Um superconjunto do comando FT.SEARCH, permite um processamento adicional substancial das chaves selecionadas pela expressão de consulta.

**Sintaxe**

```
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]
```
+ Cláusulas FILTER, LIMIT, GROUPBY, SORTBY e APPLY podem ser repetidas várias vezes em qualquer ordem e ser misturadas livremente. São aplicados na ordem especificada com a saída de uma cláusula alimentando a entrada da próxima cláusula.
+ Na sintaxe acima, uma “propriedade” é um campo declarado no comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) para esse índice OU a saída de uma cláusula APPLY ou função REDUCE anterior.
+ A cláusula LOAD é restrita ao carregamento de campos que foram declarados no índice. “LOAD \$1” carregará todos os campos declarados no índice. 
+ As seguintes funções redutoras têm suporte: COUNT, COUNT\$1DISTINCTISH, SUM, MIN, MAX, AVG, STDDEV, QUANTILE, TOLIST, FIRST\$1VALUE e RANDOM\$1SAMPLE. Para obter mais informações, consulte [Agregações](https://redis.io/docs/interact/search-and-query/search/aggregations/).
+ LIMIT <offset><count>: retém registros começando em <offset> e continuando por até <count>, todos os outros registros são descartados.
+ PARAMS: duas vezes o número de pares de valores-chave. Os key/value pares de parâmetros podem ser referenciados de dentro da expressão de consulta.

**Return**

Retorna uma matriz ou a resposta de erro.
+ Se a operação for concluída com êxito, retornará uma matriz. O primeiro elemento é um número inteiro sem significado específico (deve ser ignorado). Os elementos restantes são os resultados gerados pelo último estágio. Cada elemento é uma matriz de nomes de campos e pares de valores.
+ Se o índice estiver em andamento para preenchimento, o comando retornará imediatamente uma resposta de erro.
+ Se o tempo limite for atingido, o comando retornará uma resposta de erro.

# FT.DROPINDEX
<a name="vector-search-commands-ft.dropindex"></a>

Drop an index. A definição do índice e o conteúdo associado são excluídos. As chaves não são afetadas.

**Sintaxe**

```
FT.DROPINDEX <index-name>
```

**Return**

Retorna uma mensagem simples de texto OK ou uma resposta de erro.

# FT.INFO
<a name="vector-search-commands-ft.info"></a>

**Sintaxe**

```
FT.INFO <index-name>
```

A saída da página FT.INFO é uma matriz de pares de valores-chave, conforme descrito na tabela a seguir:


| Chave | Tipo de valor | Description | 
| --- | --- | --- | 
| nome\$1índice | string | Nome do índice | 
| creation\$1timestamp | integer | Carimbo de data e hora da criação no estilo UNIX | 
| key\$1type | string | HASH ou JSON | 
| key\$1prefixes | matriz de strings | Prefixos principais para este índice | 
| fields | matriz de informações de campo | Campos desse índice | 
| space\$1usage | integer | Bytes de memória usados por esse índice | 
| fullext\$1space\$1usage | integer | Bytes de memória usados por campos não vetoriais | 
| vector\$1space\$1usage | integer | Bytes de memória usados por campos vetoriais | 
| num\$1docs | integer | Número de chaves atualmente contidas no índice | 
| num\$1indexed\$1vectors | integer | Número de vetores atualmente contidos no índice | 
| current\$1lag | integer | Atraso recente na ingestão (milissegundos) | 
| backfill\$1status | string | Um dos seguintes: Concluído InProgres, Pausado ou Falha  | 

A tabela a seguir descreve as informações de cada campo:


| Chave | Tipo de valor | Description | 
| --- | --- | --- | 
| Identifier | string | nome do campo | 
| field\$1name | string | Nome do membro de hash ou caminho JSON | 
| type | string | um dos seguintes: Numérico, Tag, Texto ou Vetor | 
| option | string | ignorar | 

Se o campo for do tipo Vector, informações adicionais estarão presentes dependendo do algoritmo. 

Para o algoritmo HNSW:


| Chave | Tipo de valor | Description | 
| --- | --- | --- | 
| algoritmo | string | HNSW | 
| data\$1type | string | FLOAT32 | 
| distance\$1metric | string | um dos seguintes: L2, IP ou Cosine | 
| capacidade\$1inicial | integer | Tamanho inicial do índice do campo vetorial | 
| current\$1capacity | integer | Tamanho atual do índice do campo vetorial | 
| maximum\$1edges | integer | Parâmetro M na criação | 
| ef\$1construction | integer | Parâmetro EF\$1CONSTRUCTION na criação | 
| ef\$1runtime | integer | Parâmetro EF\$1RUNTIME na criação | 

Para o algoritmo FLAT:


| Chave | Tipo de valor | Description | 
| --- | --- | --- | 
| algoritmo | string | FLAT | 
| data\$1type | string | FLOAT32 | 
| distance\$1metric | string | um dos seguintes: L2, IP ou Cosine | 
| capacidade\$1inicial | integer | Tamanho inicial do índice do campo vetorial | 
| current\$1capacity | integer | Tamanho atual do índice do campo vetorial | 

# FT.\$1LIST
<a name="vector-search-commands-ft.list"></a>

Liste todos os índices.

**Sintaxe**

```
FT._LIST 
```

**Return**

Retorna uma matriz de nomes de índice

# FT.ALIASADD
<a name="vector-search-commands-ft.aliasadd"></a>

Adicione um alias para um índice. O novo nome do alias pode ser usado em qualquer lugar em que seja necessário um nome de índice.

**Sintaxe**

```
FT.ALIASADD <alias> <index-name> 
```

**Return**

Retorna uma mensagem simples de texto OK ou uma resposta de erro.

# FT.ALIASDEL
<a name="vector-search-commands-ft.aliasdel"></a>

Exclua um alias existente para um índice.

**Sintaxe**

```
FT.ALIASDEL <alias>
```

**Return**

Retorna uma mensagem simples de texto OK ou uma resposta de erro.

# FT.ALIASUPDATE
<a name="vector-search-commands-ft.aliasupdate"></a>

Atualize um alias existente para apontar para um índice físico diferente. Esse comando afeta somente referências futuras ao alias. As operações atualmente em andamento (FT.SEARCH, FT.AGGREGATE) não são afetadas por esse comando.

**Sintaxe**

```
FT.ALIASUPDATE <alias> <index>
```

**Return**

Retorna uma mensagem simples de texto OK ou uma resposta de erro.

# FT.\$1ALIASLIST
<a name="vector-search-commands-ft.aliaslist"></a>

Liste os aliases do índice.

**Sintaxe**

```
FT._ALIASLIST
```

**Return**

Retorna uma matriz do tamanho do número de aliases atuais. Cada elemento da matriz é o par alias/índice.

# FT.PROFILE
<a name="vector-search-commands-ft.profile"></a>

Execute uma consulta e retorne informações de perfil sobre essa consulta.

**Sintaxe**

```
FT.PROFILE 

<index>
SEARCH | AGGREGATE 
[LIMITED]
QUERY <query ....>
```

**Return**

Uma matriz de dois elementos. O primeiro elemento é o resultado do comando `FT.SEARCH` ou `FT.AGGREGATE` cujo perfil foi definido. O segundo elemento é uma matriz de informações de desempenho e definição de perfil.

# FT.EXPLAIN
<a name="vector-search-commands-ft.explain"></a>

Analise uma consulta e retorne informações sobre como essa consulta foi analisada.

**Sintaxe**

```
FT.EXPLAIN <index> <query>
```

**Return**

Uma string contendo os resultados analisados.

# FT.EXPLAINCLI
<a name="vector-search-commands-ft.explain-cli"></a>

O mesmo que o comando FT.EXPLAIN, exceto que os resultados são exibidos em um formato diferente, mais útil com o redis-cli.

**Sintaxe**

```
FT.EXPLAINCLI <index> <query>
```

**Return**

Uma string contendo os resultados analisados.