Amazon S3 Vectors: cercare per similarità senza un database dedicato - init.d
EN

# Amazon S3 Vectors: cercare per similarità senza un database dedicato

Alessandro Corbelli~7 min read min
Table of Contents

Quando si cerca qualcosa in un archivio, di solito si cercano parole esatte: chi scrive “fattura” trova i documenti che contengono la parola “fattura”, non quelli che parlano di “ricevuta” o “nota di pagamento”. Le applicazioni basate sull’intelligenza artificiale hanno bisogno di un altro tipo di ricerca: trovare i contenuti simili per significato, anche quando le parole sono diverse. Per farlo serve un modo di conservare e confrontare i dati chiamato database vettoriale. Il 2 dicembre 2025, durante la conferenza re:Invent , AWS ha reso disponibile a tutti - in “disponibilità generale”, cioè fuori dalla fase di anteprima riservata - Amazon S3 Vectors, che porta questa capacità dentro S3, il suo servizio di archiviazione più diffuso.

Cosa sono i vettori e perché servono

Per capire l’annuncio conviene partire dai vettori, o embedding. Un embedding è un elenco di numeri che rappresenta il significato di un contenuto: una frase, un documento, un’immagine. A produrlo è un modello di intelligenza artificiale, che trasforma il testo o l’immagine in una lunga sequenza di cifre. L’idea di fondo è semplice: due contenuti simili per significato producono vettori “vicini”, due contenuti che parlano di cose diverse producono vettori “lontani”. La vicinanza si misura con un calcolo geometrico, come la distanza tra due punti.

Con questo trucco, cercare diventa un’operazione diversa. Invece di confrontare parole, si confrontano numeri: si prende la domanda dell’utente, la si trasforma nel suo vettore e si cercano i vettori più vicini nell’archivio. Il risultato è la ricerca semantica, cioè per significato. Chi cerca “come proteggo il server dagli accessi non autorizzati” può ottenere un documento intitolato “hardening SSH”, anche se non contiene nessuna delle parole digitate.

Il collegamento con l’AI: il RAG

Questo meccanismo è il cuore di una tecnica molto usata con i modelli linguistici, il RAG (dall’inglese Retrieval Augmented Generation, “generazione con recupero di informazioni”). Un modello come quelli che alimentano gli assistenti conversazionali sa molte cose in generale, ma non conosce i documenti interni di un’azienda né le informazioni aggiornate a ieri. Il RAG colma questa lacuna: prima di rispondere, il sistema cerca nei propri archivi i passaggi più pertinenti alla domanda - usando proprio la ricerca per similarità tra vettori - e li passa al modello come contesto. Così la risposta si basa su documenti reali e verificabili, non solo su ciò che il modello ha imparato durante l’addestramento.

Per fare tutto questo servono due cose: un posto dove salvare i vettori e un modo veloce per trovare i più vicini a un vettore di riferimento. È il compito di un database vettoriale. Fino a poco tempo fa significava adottare un software specializzato, da installare e mantenere, oppure un servizio dedicato a parte, con un costo che cresce insieme al numero di vettori.

Cosa cambia mettendo i vettori dentro S3

Amazon S3 è lo storage a oggetti di AWS: un posto dove depositare file di ogni tipo - immagini, backup, log, documenti - pagando poco per grandi quantità di spazio. È uno dei mattoni più comuni delle infrastrutture su cloud, lo stesso servizio che gestisce anche le impostazioni di cifratura lato server. L’idea di S3 Vectors è aggiungere a questo storage la capacità di conservare vettori e di cercarli per similarità, senza affiancargli un database separato.

In pratica si crea un vector bucket, un contenitore simile ai normali bucket S3 ma pensato per i vettori, e al suo interno uno o più vector index (indici vettoriali). Quando si crea un indice si dichiarano poche cose: la dimensione dei vettori, cioè quanti numeri contiene ciascuno, e la metrica di distanza con cui misurare la vicinanza, che può essere il coseno o la distanza euclidea. A ogni vettore si possono associare dei metadati, cioè informazioni aggiuntive come la data o la fonte del documento, utili per filtrare i risultati: fino a 50 chiavi di metadati per vettore.

Il servizio è serverless, proprio come già succede con altri database serverless di AWS. “Senza server” non vuol dire che i server non esistano, ma che non è chi usa il servizio a doverli scegliere, dimensionare o aggiornare: se ne occupa AWS. Non c’è un cluster da tenere acceso e da pagare a ore: si paga per lo spazio occupato dai vettori e per le operazioni di scrittura e di interrogazione effettivamente fatte.

Il vantaggio che AWS mette in primo piano è il costo. La stima ufficiale parla di una riduzione fino al 90% del costo totale per caricare, conservare e interrogare i vettori rispetto a soluzioni di database vettoriale dedicate. È un dato dichiarato dal fornitore e, come sempre, il risparmio reale dipende da come si usa il servizio; ma indica la direzione: rendere la ricerca per similarità un’opzione economica anche per archivi molto grandi.

Quanto scala e con quali limiti

La disponibilità generale arriva con numeri più alti rispetto all’anteprima. Ogni indice può contenere fino a 2 miliardi di vettori, quaranta volte il limite di 50 milioni della fase di prova, e ogni vector bucket può ospitare fino a 10.000 indici. Sono cifre che spostano il servizio dalla dimostrazione all’uso in produzione su grandi collezioni di documenti.

Sul fronte dei tempi di risposta, AWS indica che le interrogazioni poco frequenti tornano un risultato in meno di un secondo, mentre quelle frequenti scendono intorno ai 100 millisecondi o meno. Ogni interrogazione può restituire fino a 100 risultati (erano 30 in anteprima), e in scrittura si arriva fino a 1.000 vettori al secondo quando si aggiornano gli indici un vettore alla volta.

Vale la pena essere onesti sul rovescio della medaglia. S3 Vectors è pensato per costare poco e reggere volumi enormi, non per essere lo strumento più rapido in assoluto: un centinaio di millisecondi va benissimo per un archivio di documenti, meno per scenari che richiedono risposte in pochi millisecondi su traffico molto intenso. Non a caso AWS lo presenta anche in coppia con OpenSearch, il suo motore di ricerca: si possono tenere i vettori usati di rado, e più economici, dentro S3 Vectors, spostando su OpenSearch solo quelli che richiedono le prestazioni più alte.

Le integrazioni

Con la disponibilità generale diventano stabili anche alcune integrazioni utili. S3 Vectors si collega alle Amazon Bedrock Knowledge Bases, il servizio con cui AWS costruisce applicazioni RAG: si può usare S3 Vectors come archivio dei vettori per abbassare il costo di un assistente che risponde attingendo a una base documentale. È disponibile l’integrazione con Amazon OpenSearch, per l’architettura a due livelli descritta sopra. Ci sono poi il supporto a CloudFormation per creare le risorse in modo automatico e ripetibile, PrivateLink per la connessione su rete privata, l’assegnazione di una chiave di cifratura dedicata per singolo indice e i tag per il controllo degli accessi e la ripartizione dei costi.

Alla data dell’annuncio il servizio è attivo in 14 regioni AWS, contro le 5 dell’anteprima, comprese Irlanda, Londra, Parigi, Francoforte e Stoccolma in Europa.

Quando ha senso

S3 Vectors è una buona opzione quando i vettori sono tanti, le interrogazioni non sono continue e il costo conta più della latenza minima: archivi di documentazione, basi di conoscenza per assistenti interni, ricerca semantica su cataloghi. In questi casi evita di dover installare, aggiornare e pagare un database vettoriale a parte, e tiene i vettori vicino ai dati che spesso sono già su S3.

Il ragionamento opposto vale altrettanto. Se un’applicazione ha bisogno di risposte nell’ordine dei pochi millisecondi su un flusso costante di richieste, o di funzioni avanzate offerte da un motore specializzato, un database vettoriale dedicato - o l’accoppiata con OpenSearch - resta più adatto. Come sempre, la scelta dipende dai requisiti concreti di volume, frequenza e velocità, non dalla novità in sé.

Fonti

Tux versione Gandalf, mascotte del blog init.d

init.d è il team di Alessandro Corbelli, sistemista Linux e sviluppatore backend con oltre vent’anni di esperienza. Progetta e gestisce infrastrutture cloud (Google Cloud, AWS, Azure), server farm e architetture ad alta disponibilità, e sviluppa software su misura in Laravel/PHP e Vue - dalla piattaforma di food delivery Take2Me ai gestionali dei nostri clienti. Su questo blog condividiamo note tecniche su Linux, sistemistica, sviluppo, DevOps ed e-commerce.


Altri articoli