

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Ricerca vettoriale
<a name="vector-search"></a>

La ricerca vettoriale per MemoryDB estende le funzionalità di MemoryDB. La ricerca vettoriale può essere utilizzata insieme alle funzionalità MemoryDB esistenti. Le applicazioni che non utilizzano la ricerca vettoriale non sono influenzate dalla sua presenza. La ricerca vettoriale è disponibile in tutte le regioni in cui è disponibile MemoryDB.

La ricerca vettoriale semplifica l'architettura dell'applicazione offrendo al contempo una ricerca vettoriale ad alta velocità. La ricerca vettoriale per MemoryDB è ideale per i casi d'uso in cui le massime prestazioni e la scalabilità sono i criteri di selezione più importanti. È possibile utilizzare i dati MemoryDB esistenti o un'API Valkey o Redis OSS per creare casi d'uso di machine learning e intelligenza artificiale generativa. Ciò include la generazione potenziata dal recupero, il rilevamento delle anomalie, il recupero dei documenti e i consigli in tempo reale.

A partire dal 26/06/2024, AWS MemoryDB offre le prestazioni di ricerca vettoriale più veloci con i tassi di richiamo più elevati tra i database vettoriali più diffusi su. AWS

**Topics**
+ [Panoramica della ricerca vettoriale](vector-search-overview.md)
+ [Casi d’uso](vector-search-examples.md)
+ [Caratteristiche e limiti della ricerca vettoriale](vector-search-limits.md)
+ [Crea un cluster abilitato per la ricerca vettoriale](vector-search-cluster.md)
+ [Comandi di ricerca vettoriale](vector-search-commands.md)

# Panoramica della ricerca vettoriale
<a name="vector-search-overview"></a>

La ricerca vettoriale si basa sulla creazione, la manutenzione e l'uso di indici. Ogni operazione di ricerca vettoriale specifica un singolo indice e il suo funzionamento è limitato a quell'indice, ovvero le operazioni su un indice non sono influenzate dalle operazioni su nessun altro indice. Ad eccezione delle operazioni di creazione e distruzione degli indici, è possibile eseguire un numero qualsiasi di operazioni su qualsiasi indice in qualsiasi momento, il che significa che a livello di cluster è possibile eseguire più operazioni su più indici contemporaneamente.

I singoli indici sono oggetti denominati che esistono in uno spazio dei nomi univoco, separato dagli altri spazi dei nomi Valkey e Redis OSS: chiavi, funzioni, ecc. Ogni indice è concettualmente simile a una tabella di database convenzionale in quanto è strutturato in due dimensioni: colonna e righe. Ogni riga della tabella corrisponde a una chiave. Ogni colonna dell'indice corrisponde a un membro o a una parte di quella chiave. All'interno di questo documento i termini chiave, riga e record sono identici e utilizzati in modo intercambiabile. Allo stesso modo, i termini colonna, campo, percorso e membro sono essenzialmente identici e sono anche usati in modo intercambiabile.

Non esistono comandi speciali per aggiungere, eliminare o modificare i dati indicizzati. Piuttosto, anche **JSON** i comandi esistenti **HASH** o che modificano una chiave presente in un indice aggiornano automaticamente l'indice.

**Topics**
+ [Indici e keyspace Valkey e Redis OSS](#vector-search-indexes-keyspaces)
+ [Tipi di campi dell'indice](#vector-search-index-field-types)
+ [Algoritmi di indice vettoriale](#vector-search-index-algorithms)
+ [Espressione di interrogazione di ricerca vettoriale](#vector-search-query-expression)
+ [Comando INFO](#vector-search-ft.info)
+ [Sicurezza della ricerca vettoriale](#vector-search-security)

## Indici e keyspace Valkey e Redis OSS
<a name="vector-search-indexes-keyspaces"></a>

Gli indici sono costruiti e gestiti su un sottoinsieme dello spazio di chiavi Valkey e Redis OSS. Più indici possono scegliere sottoinsiemi disgiunti o sovrapposti dello spazio chiave senza limitazioni. Lo spazio chiave per ogni indice è definito da un elenco di prefissi chiave forniti al momento della creazione dell'indice. L'elenco dei prefissi è facoltativo e, se omesso, l'intero spazio delle chiavi farà parte di quell'indice. Gli indici vengono inoltre digitati in quanto coprono solo le chiavi che hanno un tipo corrispondente. Attualmente sono supportati solo gli indici JSON e HASH. Un indice HASH indicizza solo le chiavi HASH incluse nel relativo elenco di prefissi e analogamente un indice JSON indicizza solo le chiavi JSON incluse nel relativo elenco di prefissi. Le chiavi all'interno dell'elenco dei prefissi dello spazio dei tasti di un indice che non hanno il tipo designato vengono ignorate e non influiscono sulle operazioni di ricerca.

Quando un comando HASH o JSON modifica una chiave che si trova all'interno di uno spazio chiave di un indice, tale indice viene aggiornato. Questo processo prevede l'estrazione dei campi dichiarati per ogni indice e l'aggiornamento dell'indice con il nuovo valore. Il processo di aggiornamento viene eseguito in un thread in background, il che significa che gli indici sono coerenti solo alla fine con il contenuto del loro keyspace. Pertanto l'inserimento o l'aggiornamento di una chiave non sarà visibile nei risultati di ricerca per un breve periodo di tempo. Durante i periodi di intenso carico di sistema ( and/or forte mutazione dei dati), il ritardo di visibilità può aumentare.

La creazione di un indice è un processo in più fasi. Il primo passo consiste nell'eseguire il comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) che definisce l'indice. L'esecuzione corretta di una creazione avvia automaticamente il secondo passaggio: il backfilling. Il processo di riempimento viene eseguito in un thread in background e analizza lo spazio chiave alla ricerca di chiavi che si trovano all'interno dell'elenco di prefissi del nuovo indice. Ogni chiave trovata viene aggiunta all'indice. Alla fine viene scansionato l'intero keyspace, completando il processo di creazione dell'indice. Nota che mentre il processo di riempimento dell'indice è in esecuzione, le mutazioni delle chiavi indicizzate sono consentite, non ci sono restrizioni e il processo di riempimento dell'indice non verrà completato finché tutte le chiavi non saranno indicizzate correttamente. Le operazioni di interrogazione tentate mentre un indice è in fase di riempimento non sono consentite e vengono terminate con un errore. Il completamento del processo di riempimento può essere determinato dall'output del `FT.INFO` comando per quell'indice ('backfill\$1status').

## Tipi di campi dell'indice
<a name="vector-search-index-field-types"></a>

Ogni campo (colonna) di un indice ha un tipo specifico che viene dichiarato al momento della creazione dell'indice e una posizione all'interno di una chiave. Per le chiavi HASH, la posizione è il nome del campo all'interno dell'HASH. Per le chiavi JSON, la posizione è una descrizione del percorso JSON. Quando una chiave viene modificata, i dati associati ai campi dichiarati vengono estratti, convertiti nel tipo dichiarato e memorizzati nell'indice. Se i dati mancano o non possono essere convertiti correttamente nel tipo dichiarato, quel campo viene omesso dall'indice. Esistono quattro tipi di campi, come spiegato di seguito: 
+ **I campi numerici** contengono un solo numero. Per i campi JSON, è necessario seguire le regole numeriche dei numeri JSON. Per HASH, il campo dovrebbe contenere il testo ASCII di un numero scritto nel formato standard per numeri a virgola fissa o mobile. Indipendentemente dalla rappresentazione all'interno della chiave, questo campo viene convertito in un numero a virgola mobile a 64 bit per la memorizzazione all'interno dell'indice. I campi numerici possono essere utilizzati con l'operatore di ricerca per intervalli. Poiché i numeri sottostanti sono memorizzati in virgola mobile con i relativi limiti di precisione, si applicano le normali regole sui confronti numerici per i numeri in virgola mobile.
+ **I campi tag** contengono zero o più valori di tag codificati come una singola stringa UTF-8. La stringa viene analizzata in valori di tag utilizzando un carattere separatore (l'impostazione predefinita è una virgola ma può essere sovrascritta) con gli spazi bianchi iniziali e finali rimossi. Qualsiasi numero di valori di tag può essere contenuto in un singolo campo di tag. I campi tag possono essere utilizzati per filtrare le query per l'equivalenza dei valori dei tag con un confronto con o senza distinzione tra maiuscole e minuscole.
+ **I campi di testo** contengono una serie di byte che non devono necessariamente essere conformi a UTF-8. I campi di testo possono essere utilizzati per decorare i risultati delle query con valori significativi per l'applicazione. Ad esempio un URL o il contenuto di un documento, ecc.
+ **I campi vettoriali** contengono un vettore di numeri noto anche come incorporamento. I campi vettoriali supportano la ricerca K-Nearest Neighbor Searching (KNN) di vettori di dimensioni fisse utilizzando un algoritmo e una metrica di distanza specificati. *Per gli indici HASH, il campo deve contenere l'intero vettore codificato in formato binario (Little-endian IEEE 754).* Per le chiavi JSON, il percorso deve fare riferimento a un array della dimensione corretta pieno di numeri. Nota che quando un array JSON viene utilizzato come campo vettoriale, la rappresentazione interna dell'array all'interno della chiave JSON viene convertita nel formato richiesto dall'algoritmo selezionato, riducendo il consumo di memoria e la precisione. Le successive operazioni di lettura che utilizzano i comandi JSON produrranno un valore di precisione ridotto.

## Algoritmi di indice vettoriale
<a name="vector-search-index-algorithms"></a>

Sono disponibili due algoritmi di indice vettoriale:
+ **Flat** — L'algoritmo Flat è un'elaborazione lineare a forza bruta di ogni vettore dell'indice, che fornisce risposte esatte entro i limiti della precisione dei calcoli della distanza. Grazie all'elaborazione lineare dell'indice, i tempi di esecuzione di questo algoritmo possono essere molto elevati per indici di grandi dimensioni.
+ **HNSW (Hierarchical Navigable Small Worlds)** — L'algoritmo HNSW è un'alternativa che fornisce un'approssimazione della risposta corretta in cambio di tempi di esecuzione notevolmente inferiori. L'algoritmo è controllato da tre parametri e. `M` `EF_CONSTRUCTION` `EF_RUNTIME` I primi due parametri vengono specificati al momento della creazione dell'indice e non possono essere modificati. Il `EF_RUNTIME` parametro ha un valore predefinito che viene specificato al momento della creazione dell'indice, ma può essere sovrascritto in ogni singola operazione di interrogazione in seguito. Questi tre parametri interagiscono per bilanciare il consumo di memoria e CPU durante le operazioni di inserimento e interrogazione, nonché per controllare la qualità dell'approssimazione di una ricerca KNN esatta (nota come rapporto di richiamo).

Entrambi gli algoritmi di ricerca vettoriale (Flat e HNSW) supportano un parametro opzionale. `INITIAL_CAP` Quando specificato, questo parametro prealloca la memoria per gli indici, con conseguente riduzione del sovraccarico di gestione della memoria e aumento delle velocità di ingestione vettoriale.

Gli algoritmi di ricerca vettoriale come HNSW potrebbero non gestire in modo efficiente l'eliminazione o la sovrascrittura dei vettori precedentemente inseriti. L'uso di queste operazioni può comportare un consumo eccessivo di memoria indicizzata, un deterioramento della qualità di richiamo. and/or La reindicizzazione è un metodo per ripristinare il recupero ottimale dell'utilizzo della memoria. and/or 

## Espressione di interrogazione di ricerca vettoriale
<a name="vector-search-query-expression"></a>

I comandi [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) richiedono un'espressione di interrogazione. Questa espressione è un parametro a stringa singola composto da uno o più operatori. Ogni operatore utilizza un campo dell'indice per identificare un sottoinsieme delle chiavi dell'indice. È possibile combinare più operatori utilizzando combinatori booleani e parentesi per migliorare o limitare ulteriormente il set di chiavi (o set di risultati) raccolto.

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

L'operatore jolly, l'asterisco ('\$1'), corrisponde a tutte le chiavi dell'indice. 

### Intervallo numerico
<a name="vector-search-query-expression-numeric-range"></a>

L'operatore di intervallo numerico ha la seguente sintassi:

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

< numeric-field-name > deve essere un campo di tipo dichiarato. `NUMERIC` Per impostazione predefinita, il limite è inclusivo, ma è possibile utilizzare una parentesi aperta iniziale ['('] per rendere esclusivo un limite. La ricerca per intervallo può essere convertita in un unico confronto relazionale (<, <=, >, > =) utilizzando `Inf` `+Inf` o `-Inf` come uno dei limiti. Indipendentemente dal formato numerico specificato (intero, a virgola fissa, a virgola mobile, infinito), il numero viene convertito in virgola mobile a 64 bit per eseguire confronti, riducendo di conseguenza la precisione.

**Example Esempi**  

```
@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
```

### Tag: confronta
<a name="vector-search-query-expression-tag-compare"></a>

L'operatore di confronto dei tag ha la seguente sintassi:

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

Se uno qualsiasi dei tag nell'operatore corrisponde a uno dei tag nel campo dei tag del record, il record viene incluso nel set di risultati. Il campo progettato da `<tag-field-name>` deve essere un campo dell'indice dichiarato con type. `TAG` Esempi di confronto tra tag sono:

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

### Combinazioni booleane
<a name="vector-search-query-expression-boolean-combinations"></a>

I set di risultati di un operatore numerico o di tag possono essere combinati utilizzando la logica booleana: and/or. Parentheses can be used to group operators and/or modifica l'ordine di valutazione. La sintassi degli operatori logici booleani è:

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

Più termini combinati in una frase sono «and» -ed. Le frasi multiple combinate con la pipe ('\$1') sono «or» -ed.

### Ricerca vettoriale
<a name="vector-search-query-expression-vector-search"></a>

Gli indici vettoriali supportano due diversi metodi di ricerca: il più vicino e l'intervallo. Una ricerca del vicino più prossimo individua un numero, K, dei vettori dell'indice che sono i più vicini al vettore fornito (di riferimento): questo è chiamato colloquialmente KNN per «K» dei vicini più vicini. La sintassi per una ricerca KNN è:

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

Una ricerca vettoriale KNN viene applicata solo ai vettori che soddisfano il WHC può essere una qualsiasi combinazione degli operatori sopra definiti: wildcard, range search, tag search, tag search e relative combinazioni booleane. `<expression>` and/or 
+ `<k>`è un numero intero che specifica il numero di vettori vicini più prossimi da restituire.
+ `<vector-field-name>`deve specificare un campo di tipo dichiarato. `VECTOR`
+ `<parameter-name>`field specifica una delle voci della `PARAM` tabella del `FT.AGGREGATE` comando `FT.SEARCH` or. Questo parametro è il valore vettoriale di riferimento per il calcolo della distanza. Il valore del vettore è codificato nel `PARAM` valore in formato binario *IEEE 754 di little-endian* (stessa codifica utilizzata per un campo vettoriale HASH)
+ Per gli indici vettoriali di tipo HNSW, la `EF_RUNTIME` clausola opzionale può essere utilizzata per sovrascrivere il valore predefinito del parametro stabilito al momento della creazione dell'indice. `EF_RUNTIME`
+ L'opzione `<distance-field-name>` fornisce un nome di campo per il set di risultati che contiene la distanza calcolata tra il vettore di riferimento e la chiave individuata.

Una ricerca per intervallo individua tutti i vettori entro una distanza (raggio) specificata da un vettore di riferimento. La sintassi per una ricerca per intervallo è:

```
<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> ]
```

Dove:
+ `<vector-field-name>`è il nome del campo vettoriale da cercare.
+ `<radius> or $<radius-parameter>`è il limite numerico di distanza per la ricerca.
+ `$<reference-vector-parameter> `è il nome del parametro che contiene il vettore di riferimento. Il valore del vettore è codificato nel valore PARAM in formato binario IEEE 754 di little-endian (stessa codifica utilizzata per un campo vettoriale HASH)
+ L'opzione `<distance-field-name>` fornisce un nome di campo per il set di risultati che contiene la distanza calcolata tra il vettore di riferimento e ciascuna chiave.
+ L'opzione opzionale `<epsilon-value> ` controlla il limite dell'operazione di ricerca, i vettori all'interno della distanza `<radius> * (1.0 + <epsilon-value>) ` vengono attraversati alla ricerca di risultati candidati. L'impostazione predefinita è .01.

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

La ricerca vettoriale amplia il comando Valkey e Redis OSS [INFO](https://valkey.io/commands/info/) con diverse sezioni aggiuntive di statistiche e contatori. Una richiesta di recupero della sezione `SEARCH` recupererà tutte le seguenti sezioni:

### Sezione `search_memory`
<a name="vector-search-ft.info-search-memory"></a>


| Nome | Description | 
| --- | --- | 
| search\$1used\$1memory\$1bytes | Numero di byte di memoria consumati in tutte le strutture di dati di ricerca | 
| search\$1used\$1memory\$1human | Versione leggibile dall'uomo di cui sopra | 

### Sezione `search_index_stats`
<a name="vector-search-ft.info-search_index_stats"></a>


| Nome | Description | 
| --- | --- | 
| numero\$1di\$1indici\$1di ricerca | Numero di indici creati | 
| search\$1num\$1fulltext\$1indexes | Numero di campi non vettoriali in tutti gli indici | 
| search\$1num\$1vector\$1indexes | Numero di campi vettoriali in tutti gli indici | 
| search\$1num\$1hash\$1indexes | Numero di indici su chiavi di tipo HASH | 
| search\$1num\$1json\$1indexes | Numero di indici su chiavi di tipo JSON | 
| search\$1total\$1indexed\$1keys | Numero totale di chiavi in tutti gli indici | 
| search\$1total\$1indexed\$1vectors | Numero totale di vettori in tutti gli indici | 
| search\$1total\$1indexed\$1hash\$1keys | Numero totale di chiavi di tipo HASH in tutti gli indici | 
| search\$1total\$1indexed\$1json\$1keys | Numero totale di chiavi di tipo JSON in tutti gli indici | 
| search\$1total\$1index\$1size | Byte utilizzati da tutti gli indici | 
| search\$1total\$1fulltext\$1index\$1size | Byte utilizzati da strutture indicizzate non vettoriali | 
| search\$1total\$1vector\$1index\$1size | Byte utilizzati dalle strutture degli indici vettoriali | 
| search\$1max\$1index\$1lag\$1ms | Ritardo di inserimento durante l'ultimo aggiornamento del batch di importazione | 

### Sezione `search_ingestion`
<a name="vector-search-ft.info-search_ingestion"></a>


| Nome | Description | 
| --- | --- | 
| search\$1background\$1indexing\$1status | Stato di ingestione. NO\$1ACTIVITYsignifica inattivo. Altri valori indicano che ci sono chiavi in fase di ingestione. | 
| search\$1ingestion\$1paused | Tranne durante il riavvio, questo dovrebbe sempre essere «no». | 

### Sezione `search_backfill`
<a name="vector-search-ft.info-search_backfill"></a>

**Nota**  
Alcuni dei campi documentati in questa sezione sono visibili solo quando è attualmente in corso un riempimento.


| Nome | Description | 
| --- | --- | 
| search\$1num\$1active\$1backfills | Numero di attività di riempimento correnti | 
| search\$1backfills\$1paused | Tranne quando la memoria è esaurita, dovrebbe sempre essere «no». | 
| search\$1current\$1backfill\$1progress\$1percentage | % di completamento (0-100) dell'attuale riempimento | 

### Sezione `search_query`
<a name="vector-search-ft.info-search_query"></a>


| Nome | Description | 
| --- | --- | 
| search\$1num\$1active\$1queries | Numero di comandi and attualmente in corso FT.SEARCH FT.AGGREGATE | 

## Sicurezza della ricerca vettoriale
<a name="vector-search-security"></a>

I meccanismi di sicurezza [ACL (Access Control Lists)](https://valkey.io/topics/acl/) per l'accesso ai comandi e ai dati sono stati estesi per controllare la funzione di ricerca. Il controllo ACL dei singoli comandi di ricerca è completamente supportato. Viene fornita una nuova categoria ACL e molte delle categorie esistenti (`@fast`, `@read``@write`, ecc.) vengono aggiornate per includere i nuovi comandi. `@search` I comandi di ricerca non modificano i dati chiave, il che significa che il meccanismo ACL esistente per l'accesso in scrittura viene preservato. Le regole di accesso per le operazioni HASH e JSON non vengono modificate dalla presenza di un indice; a tali comandi viene comunque applicato il normale controllo dell'accesso a livello di chiave.

L'accesso ai comandi di ricerca con un indice è inoltre controllato tramite ACL. I controlli di accesso vengono eseguiti a livello dell'intero indice, non a livello di chiave. Ciò significa che l'accesso a un indice viene concesso a un utente solo se tale utente è autorizzato ad accedere a tutte le chiavi possibili all'interno dell'elenco dei prefissi dello spazio chiave di quell'indice. In altre parole, il contenuto effettivo di un indice non controlla l'accesso. Piuttosto, sono i contenuti teorici di un indice, come definito dall'elenco dei prefissi, che viene utilizzato per il controllo di sicurezza. Può essere facile creare una situazione in cui un utente disponga dell'accesso in lettura e and/or scrittura a una chiave ma non sia in grado di accedere a un indice contenente quella chiave. Tieni presente che per creare o utilizzare un indice è necessario solo l'accesso in lettura allo spazio delle chiavi: la presenza o l'assenza di accesso in scrittura non viene considerata. 

Per ulteriori informazioni sull'utilizzo ACLs con MemoryDB, vedete [Authenticating users with Access](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html) Control Lists (). ACLs

# Casi d’uso
<a name="vector-search-examples"></a>

Di seguito sono riportati i casi d'uso della ricerca vettoriale.

## Retrieval Augmented Generation (RAG)
<a name="vector-search-examples-retrieval-augmented-generation"></a>

Retrieval Augmented Generation (RAG) sfrutta la ricerca vettoriale per recuperare i passaggi pertinenti da un ampio corpus di dati per ampliare un ampio modello linguistico (LLM). In particolare, un codificatore incorpora il contesto di input e la query di ricerca in vettori, quindi utilizza la ricerca approssimativa del vicino più vicino per trovare passaggi semanticamente simili. Questi passaggi recuperati vengono concatenati con il contesto originale per fornire ulteriori informazioni pertinenti all'LLM e restituire una risposta più accurata all'utente.

![\[Grafica del flusso Retrieval Augmented Generation\]](http://docs.aws.amazon.com/it_it/memorydb/latest/devguide/images/RAG.png)


## Cache semantica durevole
<a name="vector-search-examples-durable-semantic-cache"></a>

Il caching semantico è un processo per ridurre i costi di calcolo memorizzando i risultati precedenti dell'FM. Riutilizzando i risultati precedenti delle inferenze precedenti anziché ricalcolarli, la memorizzazione nella cache semantica riduce la quantità di calcolo richiesta durante l'inferenza tramite. FMs MemoryDB consente un caching semantico duraturo, che evita la perdita di dati delle inferenze passate. Ciò consente alle applicazioni di intelligenza artificiale generativa di rispondere entro millisecondi a una cifra con risposte a domande semanticamente simili precedenti, riducendo al contempo i costi evitando inferenze LLM non necessarie.

![\[Diagramma del workflow che mostra il processo del Foundation Model.\]](http://docs.aws.amazon.com/it_it/memorydb/latest/devguide/images/FM.png)

+ Risultato della **ricerca semantica**: se la query di un cliente è semanticamente simile a una domanda precedente sulla base di un punteggio di somiglianza definito, la memoria buffer FM (MemoryDB) restituirà la risposta alla domanda precedente nel passaggio 4 e non richiamerà l'FM durante i passaggi 3. In questo modo si eviteranno la latenza del modello di base (FM) e i costi sostenuti, garantendo un'esperienza più rapida per il cliente.
+ **Ricerca semantica non riuscita**: se la query di un cliente non è semanticamente simile in base a un punteggio di somiglianza definito a una query precedente, un cliente chiamerà l'FM per fornire una risposta al cliente nella fase 3a. La risposta generata dalla FM verrà quindi archiviata come vettore in MemoryDB per le query future (fase 3b) per ridurre al minimo i costi FM su domande semanticamente simili. In questo flusso, il passaggio 4 non verrebbe richiamato in quanto non esisteva una domanda semanticamente simile per la query originale. 

## Rilevamento di attività fraudolente
<a name="vector-search-examples-fraud-detection"></a>

Il rilevamento delle frodi, una forma di rilevamento delle anomalie, rappresenta le transazioni valide come vettori confrontando le rappresentazioni vettoriali delle nuove transazioni nette. La frode viene rilevata quando queste nuove transazioni nette hanno una bassa somiglianza con i vettori che rappresentano i dati transazionali validi. Ciò consente di rilevare le frodi modellando il comportamento normale, anziché cercare di prevedere ogni possibile caso di frode. MemoryDB consente alle organizzazioni di eseguire questa operazione in periodi di elevata produttività, con falsi positivi minimi e una latenza di un millisecondo.

![\[Diagramma del flusso di lavoro che mostra il processo di rilevamento delle frodi\]](http://docs.aws.amazon.com/it_it/memorydb/latest/devguide/images/fraud-detection.png)


## Altri casi d'uso
<a name="vector-search-engines"></a>
+ **I motori di raccomandazione** possono trovare agli utenti prodotti o contenuti simili rappresentando gli elementi come vettori. I vettori vengono creati analizzando attributi e modelli. In base ai modelli e agli attributi degli utenti, è possibile consigliare agli utenti nuovi elementi invisibili trovando i vettori più simili già valutati positivamente allineati all'utente.
+ **I motori di ricerca di documenti rappresentano i** documenti di testo come vettori densi di numeri, che catturano il significato semantico. Al momento della ricerca, il motore converte una query di ricerca in un vettore e trova i documenti con i vettori più simili alla query utilizzando la ricerca approssimativa del vicino più prossimo. Questo approccio alla somiglianza vettoriale consente di abbinare i documenti in base al significato anziché semplicemente alle parole chiave.

# Caratteristiche e limiti della ricerca vettoriale
<a name="vector-search-limits"></a>

## Disponibilità della ricerca vettoriale
<a name="vector-search-availability"></a>

La configurazione MemoryDB abilitata alla ricerca vettoriale è supportata sui tipi di nodi R6g, R7g e T4g ed è disponibile in tutte le regioni in cui è disponibile MemoryDB. AWS 

I cluster esistenti non possono essere modificati per abilitare la ricerca. Tuttavia, i cluster abilitati alla ricerca possono essere creati da istantanee di cluster con la ricerca disattivata.

## Restrizioni parametriche
<a name="parameter-restrictions"></a>

La tabella seguente mostra i limiti per vari elementi di ricerca vettoriale:


| Elemento | Valore massimo | 
| --- | --- | 
| Numero di dimensioni in un vettore | 32768 | 
| Numero di indici che possono essere creati | 10 | 
| Numero di campi in un indice | 50 | 
| Clausole FT.SEARCH e FT.AGGREGATE TIMEOUT (millisecondi) | 10000 | 
| Numero di fasi della pipeline nel comando FT.AGGREGATE | 32 | 
| Numero di campi nella clausola FT.AGGREGATE LOAD | 1.024 | 
| Numero di campi nella clausola FT.AGGREGATE GROUPBY | 16 | 
| Numero di campi nella clausola FT.AGGREGATE SORTBY | 16 | 
| Numero di parametri nella clausola FT.AGGREGATE PARAM | 32 | 
| Parametro HNSW M | 512 | 
| Parametro HNSW EF\$1CONSTRUCTION | 4096 | 
| Parametro HNSW EF\$1RUNTIME | 4096 | 

## Limiti di scalabilità
<a name="scaling-restrictions"></a>

La ricerca vettoriale per MemoryDB è attualmente limitata a un singolo frammento e la scalatura orizzontale non è supportata. La ricerca vettoriale supporta il ridimensionamento verticale e di replica.

## Restrizioni operative
<a name="operational-restrictions"></a>

**Persistenza e riempimento dell'indice**

La funzione di ricerca vettoriale mantiene la definizione degli indici e il contenuto dell'indice. Ciò significa che durante qualsiasi richiesta o evento operativo che causa l'avvio o il riavvio di un nodo, la definizione e il contenuto dell'indice vengono ripristinati dall'istantanea più recente e tutte le transazioni in sospeso vengono lette dal registro delle transazioni Multi-AZ. Non è richiesta alcuna azione da parte dell'utente per avviare questa operazione. La ricostruzione viene eseguita come operazione di riempimento non appena i dati vengono ripristinati. Dal punto di vista funzionale, ciò equivale all'esecuzione automatica da parte del sistema di un comando [FT.CREATE per ogni indice](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) definito. Si noti che il nodo diventa disponibile per le operazioni dell'applicazione non appena i dati vengono ripristinati, ma probabilmente prima del completamento del riempimento dell'indice, il che significa che i backfill diventeranno nuovamente visibili alle applicazioni; ad esempio, i comandi di ricerca che utilizzano gli indici di riempimento potrebbero essere rifiutati. Per ulteriori informazioni sul backfilling, vedere. [Panoramica della ricerca vettorialeIndici e keyspace Valkey e Redis OSS](vector-search-overview.md#vector-search-indexes-keyspaces)

Il completamento del riempimento dell'indice non è sincronizzato tra un primario e una replica. Questa mancanza di sincronizzazione può diventare inaspettatamente visibile alle applicazioni, pertanto è consigliabile che le applicazioni verifichino il completamento del backfill sui file primari e su tutte le repliche prima di iniziare le operazioni di ricerca.

## Istantanea e migrazione in tempo reale import/export
<a name="snapshot-restrictions"></a>

La presenza di indici di ricerca in un file RDB limita la trasportabilità compatibile di tali dati. Il formato degli indici vettoriali definiti dalla funzionalità di ricerca vettoriale di MemoryDB è compreso solo da un altro cluster abilitato ai vettori di MemoryDB. Inoltre, i file RDB dei cluster di anteprima possono essere importati dalla versione GA dei cluster MemoryDB, che ricostruirà il contenuto dell'indice durante il caricamento del file RDB. 

Tuttavia, i file RDB che non contengono indici non sono soggetti a restrizioni in questo modo. Pertanto i dati all'interno di un cluster di anteprima possono essere esportati in cluster non di anteprima eliminando gli indici prima dell'esportazione.

## Consumo di memoria
<a name="memory-consumption"></a>

 Il consumo di memoria si basa sul numero di vettori, sul numero di dimensioni, sul valore M e sulla quantità di dati non vettoriali, come i metadati associati al vettore o altri dati memorizzati all'interno dell'istanza. 

La memoria totale richiesta è una combinazione dello spazio necessario per i dati vettoriali effettivi e dello spazio richiesto per gli indici vettoriali. Lo spazio richiesto per i dati vettoriali viene calcolato misurando la capacità effettiva richiesta per archiviare i vettori all'interno di strutture di dati HASH o JSON e il sovraccarico delle lastre di memoria più vicine, per allocazioni di memoria ottimali. Ciascuno degli indici vettoriali utilizza riferimenti ai dati vettoriali memorizzati in queste strutture di dati e utilizza ottimizzazioni di memoria efficienti per rimuovere eventuali copie duplicate dei dati vettoriali nell'indice.

Il numero di vettori dipende da come decidete di rappresentare i dati come vettori. Ad esempio, puoi scegliere di rappresentare un singolo documento in più blocchi, in cui ogni blocco rappresenta un vettore. In alternativa, puoi scegliere di rappresentare l'intero documento come un unico vettore. 

Il numero di dimensioni dei vettori dipende dal modello di incorporamento scelto. Ad esempio, se scegli di utilizzare il modello di incorporamento [AWS Titan](https://aws.amazon.com/bedrock/titan/), il numero di dimensioni sarebbe 1536. 

Il parametro M rappresenta il numero di link bidirezionali creati per ogni nuovo elemento durante la costruzione dell'indice. Il valore predefinito di MemoryDB è 16; tuttavia, è possibile sovrascriverlo. Un parametro M più alto funziona meglio per requisiti di richiamo elevati ad and/or alta dimensionalità, mentre parametri M bassi funzionano meglio per requisiti di richiamo bassi. and/or Il valore M aumenta il consumo di memoria man mano che l'indice aumenta, aumentando il consumo di memoria. 

Nell'esperienza della console, MemoryDB offre un modo semplice per scegliere il tipo di istanza giusto in base alle caratteristiche del carico di lavoro vettoriale dopo aver selezionato Abilita la ricerca vettoriale nelle impostazioni del cluster. 

![\[Impostazioni del cluster di ricerca vettoriale nella console. AWS\]](http://docs.aws.amazon.com/it_it/memorydb/latest/devguide/images/vector-search-cluster-settings-console.png)




**Esempio di carico di lavoro**

Un cliente desidera creare un motore di ricerca semantico basato sui propri documenti finanziari interni. Attualmente detengono 1 milione di documenti finanziari suddivisi in 10 vettori per documento utilizzando il modello di incorporamento Titan con 1536 dimensioni e non contengono dati non vettoriali. Il cliente decide di utilizzare il valore predefinito di 16 come parametro M. 
+ Vettori: 1 M \$1 10 blocchi = 10 milioni di vettori
+ Dimensioni: 1536
+ Dati non vettoriali (GB): 0 GB
+ Parametro M: 16

Con questi dati, il cliente può fare clic sul pulsante Usa calcolatrice vettoriale all'interno della console per ottenere un tipo di istanza consigliato in base ai relativi parametri:

![\[Il tipo di nodo consigliato dalla calcolatrice vettoriale, in base all'input della calcolatrice.\]](http://docs.aws.amazon.com/it_it/memorydb/latest/devguide/images/vector-calc1.png)


![\[La calcolatrice vettoriale con i valori inseriti.\]](http://docs.aws.amazon.com/it_it/memorydb/latest/devguide/images/vector-calc2.png)


In questo esempio, la calcolatrice vettoriale cercherà il [tipo di nodo MemoryDB r7g](https://aws.amazon.com/memorydb/pricing/) più piccolo in grado di contenere la memoria necessaria per archiviare i vettori in base ai parametri forniti. Tieni presente che si tratta di un'approssimazione e dovresti testare il tipo di istanza per assicurarti che soddisfi i tuoi requisiti.



In base al metodo di calcolo sopra riportato e ai parametri del carico di lavoro di esempio, questi dati vettoriali richiederebbero 104,9 GB per archiviare i dati e un singolo indice. In questo caso, il tipo di `db.r7g.4xlarge` istanza è consigliato in quanto dispone di 105,81 GB di memoria utilizzabile. Il successivo tipo di nodo più piccolo sarebbe troppo piccolo per contenere il carico di lavoro vettoriale.

Poiché ciascuno degli indici vettoriali utilizza riferimenti ai dati vettoriali memorizzati e non crea copie aggiuntive dei dati vettoriali nell'indice vettoriale, gli indici occuperanno anche uno spazio relativamente inferiore. Ciò è molto utile per creare più indici e anche in situazioni in cui parti dei dati vettoriali sono state eliminate e la ricostruzione del grafico HNSW aiuterebbe a creare connessioni tra i nodi ottimali per risultati di ricerca vettoriali di alta qualità.

## Memoria insufficiente durante il riempimento
<a name="out-of-memory-backfill"></a>

Analogamente alle operazioni di scrittura di Valkey e Redis OSS, un riempimento dell'indice è soggetto a limitazioni. out-of-memory Se la memoria del motore è piena mentre è in corso un riempimento, tutti i riempimenti vengono messi in pausa. Se la memoria diventa disponibile, il processo di riempimento viene ripreso. È anche possibile eliminare e indicizzare quando il riempimento è in pausa a causa dell'esaurimento della memoria.

## Transazioni
<a name="transactions"></a>

I comandi`FT.CREATE`,, `FT.DROPINDEX` `FT.ALIASADD``FT.ALIASDEL`, e `FT.ALIASUPDATE` non possono essere eseguiti in un contesto transazionale, cioè non all'interno di un MULTI/EXEC blocco o all'interno di uno script LUA o FUNCTION. 

# Crea un cluster abilitato per la ricerca vettoriale
<a name="vector-search-cluster"></a>

È possibile creare un cluster abilitato per la ricerca vettoriale utilizzando il Console di gestione AWS, o il. AWS Command Line Interface A seconda dell'approccio, è necessario abilitare le considerazioni per abilitare la ricerca vettoriale.

## Usando il Console di gestione AWS
<a name="vector-search-console"></a>

Per creare un cluster abilitato alla ricerca vettoriale all'interno della console, è necessario abilitare la ricerca vettoriale nelle impostazioni del **cluster**. La ricerca vettoriale è disponibile per MemoryDB versione 7.1 in una configurazione a singolo shard.

![\[La visualizzazione delle impostazioni del cluster con l'opzione «Abilita ricerca vettoriale» selezionata fornisce informazioni sulla versione specifica e sul supporto per la configurazione.\]](http://docs.aws.amazon.com/it_it/memorydb/latest/devguide/images/vs-2.png)


Per ulteriori informazioni sull'utilizzo della ricerca vettoriale con Console di gestione AWS, vedere. [Creazione di un cluster (Console)](getting-started.md#clusters.createclusters.viewdetails.cluster)

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

Per creare un cluster MemoryDB abilitato alla ricerca vettoriale, è possibile utilizzare il comando MemoryDB [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-cluster.html) passando un gruppo di parametri immutabile per abilitare le funzionalità di ricerca vettoriale. `default.memorydb-redis7.search`

```
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
```

Facoltativamente, è anche possibile creare un nuovo gruppo di parametri per abilitare la ricerca vettoriale, come mostrato nell'esempio seguente. [Puoi saperne di più sui gruppi di parametri qui.](parametergroups.management.md)

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

Successivamente, aggiorna il parametro search-enabled su yes nel gruppo di parametri appena creato.

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

È ora possibile utilizzare questo gruppo di parametri personalizzato anziché il gruppo di parametri predefinito per abilitare la ricerca vettoriale nei cluster di MemoryDB.

# Comandi di ricerca vettoriale
<a name="vector-search-commands"></a>

Di seguito è riportato un elenco di comandi supportati per la ricerca vettoriale. 

**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. \$1LISTA](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. \$1LISTA DI ALIAS](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>

 Crea un indice e avvia un riempimento di tale indice. Per ulteriori informazioni, consulta [Panoramica della ricerca vettoriale](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html) per i dettagli sulla costruzione dell'indice.

**Sintassi**

```
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>])

)+
```

**Schema**
+ Identificatore di campo:
  + Per le chiavi hash, l'identificatore di campo è un nome di campo.
  + Per le chiavi JSON, l'identificatore di campo è un percorso JSON.

  Per ulteriori informazioni, consulta [Tipi di campi dell'indice](vector-search-overview.md#vector-search-index-field-types).
+ Tipi di campo:
  + TAG: per ulteriori informazioni, consulta [Tag](https://redis.io/docs/interact/search-and-query/advanced-concepts/tags/).
  + NUMERICO: Il campo contiene un numero.
  + TESTO: Il campo contiene qualsiasi blob di dati.
  + VECTOR: campo vettoriale che supporta la ricerca vettoriale.
    + Algoritmo: può essere HNSW (Hierarchical Navigable Small World) o FLAT (forza bruta). 
    + `attr_count`— numero di attributi che verranno passati come configurazione dell'algoritmo, che include sia nomi che valori. 
    + `{attribute_name} {attribute_value}`— key/value coppie specifiche dell'algoritmo che definiscono la configurazione dell'indice. 

      Per l'algoritmo FLAT, gli attributi sono:

      Campo obbligatorio:
      + DIM — Numero di dimensioni nel vettore.
      + DISTANCE\$1METRIC — Può essere uno dei [L2 \$1 IP \$1 COSINE].
      + TYPE — Tipo di vettore. L'unico tipo supportato è`FLOAT32`.

      Facoltativo:
      + INITIAL\$1CAP — La capacità vettoriale iniziale dell'indice influisce sulla dimensione di allocazione della memoria dell'indice.

      Per l'algoritmo HNSW, gli attributi sono:

      Campo obbligatorio:
      + TYPE: tipo vettoriale. L'unico tipo supportato è`FLOAT32`.
      + DIM: dimensione vettoriale, specificata come numero intero positivo. Massimo: 32768
      + DISTANCE\$1METRIC — Può essere uno dei [L2 \$1 IP \$1 COSINE].

      Facoltativo:
      + INITIAL\$1CAP — La capacità vettoriale iniziale dell'indice influisce sulla dimensione di allocazione della memoria dell'indice. Il valore predefinito è 1024.
      + M — Numero massimo di bordi in uscita consentiti per ogni nodo del grafico in ogni livello. Sul livello zero il numero massimo di bordi in uscita sarà 2M. Il valore predefinito è 16. Il massimo è 512.
      + EF\$1CONSTRUCTION — controlla il numero di vettori esaminati durante la costruzione dell'indice. Valori più elevati per questo parametro miglioreranno il rapporto di richiamo a scapito di tempi più lunghi di creazione dell'indice. Il valore predefinito è 200. Il valore massimo è 4096.
      + EF\$1RUNTIME: controlla il numero di vettori esaminati durante le operazioni di interrogazione. Valori più elevati per questo parametro possono migliorare il richiamo a scapito di tempi di interrogazione più lunghi. Il valore di questo parametro può essere sovrascritto in base alla singola query. Il valore predefinito è 10. Il valore massimo è 4096.

**Valori restituiti**

Restituisce una semplice stringa di messaggio OK o una risposta all'errore.

**Esempi**

**Nota**  
L'esempio seguente utilizza argomenti nativi di [valkey-cli](https://valkey.io/topics/cli/), come la dequotazione e l'eliminazione dell'escape dei dati, prima di inviarli a Valkey o Redis OSS. Per utilizzare altri client in linguaggi di programmazione (Python, Ruby, C\$1, ecc.), segui le regole di gestione di tali ambienti per la gestione di stringhe e dati binari. [Per ulteriori informazioni sui client supportati, consulta Strumenti su cui costruire AWS](https://aws.amazon.com/developer/tools/)

**Example 1: Crea alcuni indici**  
Crea un indice per vettori di dimensione 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
```
Crea un indice JSON a 6 dimensioni utilizzando l'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 Esempio 2: popolare alcuni dati**  
I seguenti comandi sono formattati in modo da poter essere eseguiti come argomenti del programma terminale redis-cli. Gli sviluppatori che utilizzano client in linguaggio di programmazione (come Python, Ruby, C\$1, ecc.) dovranno seguire le regole di gestione del loro ambiente per gestire stringhe e dati binari.  
Creazione di alcuni dati 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]}'
```
Tenere presente quanto segue:  
+ Le chiavi dei dati hash e JSON hanno i prefissi delle relative definizioni di indice.
+ I vettori si trovano nei percorsi appropriati delle definizioni degli indici.
+ I vettori hash vengono immessi come dati esadecimali mentre i dati JSON vengono immessi come numeri.
+ I vettori hanno le lunghezze appropriate, le voci vettoriali hash bidimensionali hanno due float di dati esadecimali, le voci vettoriali json a sei dimensioni hanno sei numeri.

**Example Esempio 3: eliminare e ricreare un indice**  

```
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
```
Nota che il nuovo indice JSON utilizza l'`FLAT`algoritmo anziché l'`HNSW`algoritmo. Tieni inoltre presente che reindicizzerà i dati JSON esistenti:  

```
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>

Utilizza l'espressione di interrogazione fornita per individuare le chiavi all'interno di un indice. Una volta individuato, è possibile restituire il and/or contenuto del conteggio dei campi indicizzati all'interno di tali chiavi. Per ulteriori informazioni, vedere Espressione di interrogazione di [ricerca vettoriale](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).

Per creare dati da utilizzare in questi esempi, vedete il comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html).

**Sintassi**

```
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: Questa clausola identifica quali campi di una chiave vengono restituiti. La clausola AS opzionale su ogni campo sostituisce il nome del campo nel risultato. È possibile specificare solo i campi dichiarati per questo indice.
+ LIMIT: <offset><count>: Questa clausola fornisce la funzionalità di impaginazione in quanto vengono restituite solo le chiavi che soddisfano i valori di offset e count. Se questa clausola viene omessa, il valore predefinito è «LIMIT 0 10", ovvero verranno restituite solo un massimo di 10 chiavi. 
+ PARAMETRI: due volte il numero di coppie chiave-valore. È possibile fare riferimento alle key/value coppie di parametri dall'interno dell'espressione di query. Per ulteriori informazioni, vedete Espressione di interrogazione di [ricerca vettoriale](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).
+ COUNT: questa clausola elimina la restituzione del contenuto delle chiavi, viene restituito solo il numero di chiavi. Questo è un alias per «LIMIT 0 0".

**Valori restituiti**

Restituisce una matrice o una risposta di errore.
+ Se l'operazione viene completata correttamente, restituisce un array. Il primo elemento è il numero totale di chiavi corrispondenti alla query. Gli elementi rimanenti sono coppie di nomi di chiavi ed elenchi di campi. L'elenco dei campi è un altro array che comprende coppie di nomi di campo e valori. 
+ Se l'indice è in corso di riempimento, il comando restituisce immediatamente una risposta di errore.
+ Se viene raggiunto il timeout, il comando restituisce una risposta di errore.

**Esempio: esegui alcune ricerche**

**Nota**  
L'esempio seguente utilizza argomenti nativi di [valkey-cli](https://valkey.io/topics/cli/), come la dequotazione e la rimozione dell'escape dei dati, prima di inviarli a Valkey o Redis OSS. Per utilizzare altri client in linguaggi di programmazione (Python, Ruby, C\$1, ecc.), segui le regole di gestione di tali ambienti per la gestione di stringhe e dati binari. [Per ulteriori informazioni sui client supportati, consulta Strumenti su cui costruire AWS](https://aws.amazon.com/developer/tools/)

**Una ricerca 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"
```

Ciò produce due risultati, ordinati in base al punteggio, che è la distanza dal vettore di query (immessa come esadecimale).

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

Ciò produce i due risultati più vicini, ordinati in base al punteggio, e nota che i valori vettoriali JSON vengono convertiti in float e il vettore di query è ancora costituito da dati vettoriali. Nota anche che, poiché il `KNN` parametro è 2, ci sono solo due risultati. Un valore maggiore restituirà più risultati:

```
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>

Un superset del comando FT.SEARCH, consente un'elaborazione aggiuntiva sostanziale delle chiavi selezionate dall'espressione di query.

**Sintassi**

```
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]
```
+ Le clausole FILTER, LIMIT, GROUPBY, SORTBY e APPLY possono essere ripetute più volte in qualsiasi ordine e possono essere mescolate liberamente. Vengono applicate nell'ordine specificato con l'output di una clausola che alimenta l'input della clausola successiva.
+ Nella sintassi precedente, una «proprietà» è un campo dichiarato nel comando [FT.CREATE](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-commands-ft.create.html) per questo indice OPPURE l'output di una precedente clausola APPLY o funzione REDUCE.
+ La clausola LOAD si limita al caricamento di campi dichiarati nell'indice. «LOAD \$1» caricherà tutti i campi dichiarati nell'indice. 
+ Sono supportate le seguenti funzioni di riduzione: COUNT, COUNT\$1DISTINCTISH, SUM, MIN, MAX, AVG, STDDEV, QUANTILE, TOLIST, FIRST\$1VALUE e RANDOM\$1SAMPLE. [Per ulteriori informazioni, vedere Aggregazioni](https://redis.io/docs/interact/search-and-query/search/aggregations/)
+ LIMITE <offset><count>: Conserva i record a partire da <offset>e fino a<count>, tutti gli altri record vengono eliminati.
+ PARAMETRI: due volte il numero di coppie chiave-valore. È possibile fare riferimento alle key/value coppie di parametri dall'interno dell'espressione di query.

**Valori restituiti**

Restituisce una matrice o una risposta di errore.
+ Se l'operazione viene completata correttamente, restituisce un array. Il primo elemento è un numero intero senza un significato particolare (deve essere ignorato). Gli elementi rimanenti sono i risultati prodotti dall'ultima fase. Ogni elemento è una matrice di coppie di nomi di campo e valori.
+ Se l'indice è in corso di riempimento, il comando restituisce immediatamente una risposta di errore.
+ Se viene raggiunto il timeout, il comando restituisce una risposta di errore.

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

Eliminare un indice. La definizione dell'indice e il contenuto associato vengono eliminati. Le chiavi non vengono modificate.

**Sintassi**

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

**Valori restituiti**

Restituisce un semplice messaggio OK in formato stringa o una risposta di errore.

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

**Sintassi**

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

L'output della pagina FT.INFO è un array di coppie chiave-valore, come descritto nella tabella seguente:


| Chiave | Value type (Tipo di valore) | Description | 
| --- | --- | --- | 
| nome\$1indice | stringa | Nome dell'indice | 
| creation\$1timestamp | intero | Timestamp dell'ora di creazione in stile Unix | 
| tipo\$1chiave | stringa | HASH o JSON | 
| key\$1prefixes | matrice di stringhe | Prefissi chiave per questo indice | 
| campi | matrice di informazioni sul campo | Campi di questo indice | 
| space\$1usage | intero | Byte di memoria utilizzati da questo indice | 
| fullext\$1space\$1usage | intero | Byte di memoria utilizzati dai campi non vettoriali | 
| vector\$1space\$1usage | intero | Byte di memoria usati dai campi vettoriali | 
| num\$1docs | intero | Numero di chiavi attualmente contenute nell'indice | 
| num\$1indexed\$1vectors | intero | Numero di vettori attualmente contenuti nell'indice | 
| current\$1lag | intero | Ritardo di ingestione recente (millisecondi) | 
| backfill\$1status | stringa | Uno dei seguenti: Completato, Sospeso o InProgres Non riuscito  | 

La tabella seguente descrive le informazioni per ogni campo:


| Chiave | Value type (Tipo di valore) | Description | 
| --- | --- | --- | 
| identificatore | stringa | nome del campo | 
| field\$1name | stringa | Nome del membro hash o percorso JSON | 
| tipo | stringa | uno tra: Numerico, Tag, Testo o Vettore | 
| option | stringa | ignora | 

Se il campo è di tipo Vector, saranno presenti informazioni aggiuntive a seconda dell'algoritmo. 

Per l'algoritmo HNSW:


| Chiave | Value type (Tipo di valore) | Description | 
| --- | --- | --- | 
| Algoritmo | stringa | HNSW | 
| data\$1type | stringa | FLOAT32 | 
| distanza\$1metrica | stringa | uno tra: L2, IP o Cosine | 
| capacità\$1iniziale | intero | Dimensione iniziale dell'indice del campo vettoriale | 
| capacità\$1corrente | intero | Dimensione attuale dell'indice dei campi vettoriali | 
| massimum\$1edges | intero | Parametro M alla creazione | 
| ef\$1construction | intero | Parametro EF\$1CONSTRUCTION alla creazione | 
| ef\$1runtime | intero | parametro EF\$1RUNTIME alla creazione | 

Per l'algoritmo FLAT:


| Chiave | Value type (Tipo di valore) | Description | 
| --- | --- | --- | 
| Algoritmo | stringa | APPARTAMENTO | 
| data\$1type | stringa | FLOAT32 | 
| distanza\$1metrica | stringa | uno tra: L2, IP o Cosine | 
| capacità\$1iniziale | intero | Dimensione iniziale dell'indice del campo vettoriale | 
| capacità\$1corrente | intero | Dimensione attuale dell'indice dei campi vettoriali | 

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

Elenca tutti gli indici.

**Sintassi**

```
FT._LIST 
```

**Valori restituiti**

Restituisce una matrice di nomi di indici

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

Aggiungi un alias per un indice. Il nuovo nome alias può essere utilizzato ovunque sia richiesto un nome di indice.

**Sintassi**

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

**Valori restituiti**

Restituisce un semplice messaggio OK in formato stringa o una risposta di errore.

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

Elimina un alias esistente per un indice.

**Sintassi**

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

**Valori restituiti**

Restituisce un semplice messaggio OK in formato stringa o una risposta di errore.

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

Aggiorna un alias esistente in modo che punti a un indice fisico diverso. Questo comando ha effetto solo sui riferimenti futuri all'alias. Le operazioni attualmente in corso (FT.SEARCH, FT.AGGREGATE) non sono influenzate da questo comando.

**Sintassi**

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

**Valori restituiti**

Restituisce una semplice stringa di messaggio OK o una risposta di errore.

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

Elenca gli alias dell'indice.

**Sintassi**

```
FT._ALIASLIST
```

**Valori restituiti**

Restituisce un array della dimensione del numero di alias correnti. Ogni elemento dell'array è la coppia alias-indice.

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

Esegui una query e restituisci le informazioni sul profilo relative a tale query.

**Sintassi**

```
FT.PROFILE 

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

**Valori restituiti**

Un array a due elementi. Il primo elemento è il risultato del `FT.AGGREGATE` comando `FT.SEARCH` or a cui è stato profilato. Il secondo elemento è una serie di informazioni sulle prestazioni e sulla profilazione.

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

Analizza una query e restituisce informazioni su come tale query è stata analizzata.

**Sintassi**

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

**Valori restituiti**

Una stringa contenente i risultati analizzati.

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

Uguale al comando FT.EXPLAIN tranne per il fatto che i risultati vengono visualizzati in un formato diverso, più utile con redis-cli.

**Sintassi**

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

**Valori restituiti**

Una stringa contenente i risultati analizzati.