Database vettoriale: cosa memorizza e come cerca per somiglianza

Che cos’è un database vettoriale

Un database vettoriale è un sistema che memorizza vettori — elenchi di numeri che rappresentano dati — e permette di cercare quelli più vicini a un vettore di query secondo una determinata metrica. Il suo scopo è facilitare la ricerca per somiglianza in insiemi di rappresentazioni numeriche, per esempio per recuperare testi, prodotti o immagini correlati a una query.

Il database lavora sui vettori che riceve. In genere, un modello o un altro componente trasforma il dato originale in una rappresentazione numerica chiamata embedding. La generazione dell’embedding e la ricerca successiva sono operazioni distinte: memorizzare vettori non significa che il database abbia creato quelle rappresentazioni, compreso il contenuto o verificato che due elementi siano equivalenti.

In un’applicazione, di solito il vettore è associato a un identificativo e può essere accompagnato da metadati, per esempio una categoria o una data, e da un riferimento al dato originale. Il contenuto completo può risiedere nello stesso sistema oppure altrove. I tipi di dati accettati, le funzioni disponibili e il modo in cui vengono implementate dipendono dal prodotto: «database vettoriale» non identifica un’unica architettura.

Cosa contiene un record e come si esegue una query

Un record vettoriale può includere un identificativo, il vettore, metadati e un riferimento all’oggetto associato. Per esempio, per un frammento di documentazione si potrebbero memorizzare il suo vettore, un identificativo del documento, la lingua e la posizione del frammento. Il testo originale può trovarsi nel database oppure essere recuperato da un altro sistema di archiviazione.

Il flusso tipico si articola in più fasi. L’applicazione recupera il dato da indicizzare e lo invia a un modello di embedding; riceve un vettore e lo memorizza insieme a un identificativo. Quando arriva una query, il sistema genera — oppure riceve da un altro componente — un vettore di query compatibile e richiede i vicini più prossimi. In seguito, l’applicazione può recuperare i dati originali, applicare regole di business o presentare i risultati.

La compatibilità tra i vettori memorizzati e quello della query è importante. Se sono prodotti con modelli diversi, configurazioni incompatibili o spazi di rappresentazione non corrispondenti, il confronto potrebbe non essere utile. Il database non può correggere automaticamente una rappresentazione inadeguata.

Come si misura la vicinanza

Per effettuare una ricerca serve una regola per confrontare i vettori. Tra le misure più comuni ci sono la similarità coseno, il prodotto scalare e la distanza euclidea. Non sono termini intercambiabili: calcolano relazioni diverse e i risultati possono essere ordinati o interpretati in modi differenti.

La similarità coseno confronta l’orientamento dei vettori; la distanza euclidea misura la separazione tra i loro punti; il prodotto scalare combina le componenti e può dipendere dalla grandezza dei vettori. La scelta non dovrebbe basarsi soltanto sull’abitudine. Deve essere coerente con il modello, con il modo in cui i vettori sono stati generati o normalizzati e con l’obiettivo dell’applicazione.

È opportuno verificare la configurazione end-to-end: quale metrica offre l’implementazione, quale viene usata nell’indice e come sono ordinati o presentati i risultati. Un’etichetta come «similarità» non garantisce che due prodotti calcolino lo stesso valore né che un valore alto abbia la stessa interpretazione in entrambi.

Ricerca esatta e ricerca approssimata

In una ricerca esatta, il sistema confronta la query con tutti i vettori dell’insieme considerato e restituisce i migliori risultati secondo la metrica. È un riferimento chiaro per valutare la qualità, ma il lavoro può aumentare al crescere della raccolta.

La ricerca approssimata dei vicini più prossimi, spesso abbreviata in ANN, usa strutture di indicizzazione per esplorare una parte dello spazio anziché confrontare in modo esaustivo ogni vettore. Può ridurre il tempo di query, ma non garantisce di trovare sempre gli stessi vicini di una ricerca esaustiva. Il grado di approssimazione e il costo dipendono dall’indice, dai suoi parametri e dal carico di lavoro.

HNSW è un esempio di indice per la ricerca approssimata basato su grafi gerarchici. Non è un requisito per ogni database vettoriale né l’unico modo per indicizzare. La documentazione dei singoli sistemi può descrivere indici e compromessi diversi; perciò il solo nome dell’indice non basta a prevedere le prestazioni in un’applicazione reale.

Un confronto utile consiste nell’eseguire query rappresentative con una ricerca esatta e con l’indice approssimato, osservando sia la qualità del recupero sia la latenza. Misurare soltanto la velocità può nascondere i risultati mancanti; misurare soltanto la corrispondenza con la ricerca esatta non dice se il sistema risponde alle esigenze degli utenti.

Filtri e ricerca combinata

I metadati descrivono aspetti del record che non sono necessariamente codificati nel vettore. Un filtro può limitare la ricerca a una categoria, una lingua, una data o agli elementi disponibili. In questo modo, una query per somiglianza può operare su un sottoinsieme pertinente, se l’implementazione e l’applicazione supportano questa combinazione.

Anche il comportamento pratico di una query può cambiare a causa dei filtri. Per esempio, se un filtro lascia pochi candidati o seleziona una porzione molto specifica dell’indice, il sistema potrebbe aver bisogno di una strategia diversa per recuperare i risultati. Non si deve presumere che tutti i prodotti applichino i filtri nello stesso momento, con le stesse garanzie o con effetti identici sull’indice.

In un’applicazione, la ricerca vettoriale può essere combinata con la ricerca lessicale, che individua corrispondenze tra parole, e con regole esplicite. Può essere utile quando contano sia la somiglianza concettuale sia termini esatti, identificativi o vincoli. Non bisogna dare per scontato che la ricerca ibrida sia disponibile ovunque: potrebbe richiedere funzioni specifiche o un coordinamento nell’applicazione stessa.

Tre esempi di applicazione

I casi che seguono descrivono possibili usi, non risultati garantiti. In tutti, la ricerca recupera candidati sulla base di rappresentazioni; l’interpretazione e la validazione spettano al sistema e al contesto d’uso.

Che cosa non fa un database vettoriale

Un database vettoriale non genera necessariamente gli embedding. Questo compito spetta di norma a un modello o a un componente separato, che trasforma dati come testo, immagini o audio in vettori. Il database riceve e confronta tali rappresentazioni secondo la configurazione adottata.

Inoltre, il sistema non garantisce che la somiglianza numerica coincida con la rilevanza per l’utente. Due elementi possono essere vicini nello spazio vettoriale senza essere equivalenti, corretti o utili per uno specifico obiettivo. La qualità dei risultati dipende dal modello, dai dati, dalla metrica, dai filtri e dalle regole dell’applicazione.

Infine, la ricerca non redige da sola una risposta in linguaggio naturale. Un sistema generativo può usare i risultati recuperati come contesto, ma questa fase è distinta dalla memorizzazione e dalla ricerca dei vettori. È utile mantenere separati il recupero dei candidati, la loro valutazione e l’eventuale generazione di una risposta.

Confusioni frequenti e concetti correlati

Un embedding è una rappresentazione numerica, non il database che la memorizza. La ricerca semantica è un obiettivo o una modalità di ricerca: può usare embedding e vettori, ma non è sinonimo del componente di archiviazione. Un database relazionale con supporto per vettori può memorizzare dati strutturati e offrire anche funzioni di ricerca vettoriale; non è necessario che esista un prodotto separato per ogni caso d’uso.

L’espressione «archivio di vettori» descrive in modo generico un sistema che conserva vettori, ma non dice da sola quali siano le sue funzioni di query, filtraggio, aggiornamento o gestione dei dati. Un database vettoriale può includere capacità più ampie, ma le caratteristiche dipendono dal prodotto. A sua volta, un sistema RAG coordina il recupero di informazioni e la generazione di risposte: un database vettoriale può essere una sua componente, ma non coincide con l’intero sistema.

Anche la frammentazione dei documenti è un passaggio distinto: determina come suddividere il contenuto prima di rappresentarlo e indicizzarlo. Quantizzazione e inferenza sono altri concetti correlati, rispettivamente legati a possibili modi di rappresentare o elaborare vettori e al funzionamento dei modelli. Per approfondire, consulta le voci del glossario su [embedding], [ricerca semantica], [RAG], [frammentazione dei documenti], [quantizzazione] e [inferenza], oltre alla sezione generale del [glossario]. Questi collegamenti aiutano a distinguere i componenti, senza spostare il focus dalla funzione del database vettoriale.

Limiti e criteri per scegliere una soluzione

La qualità del modello di rappresentazione è un limite fondamentale: se i vettori non catturano le caratteristiche rilevanti per il compito, la ricerca può restituire risultati poco utili anche quando il database funziona come previsto. Occorre inoltre scegliere una metrica compatibile con il modello e valutare il compromesso tra recall e latenza quando si usa un indice approssimato.

I filtri selettivi, gli aggiornamenti dei dati e i costi di memoria possono influire sul comportamento e sull’operatività del sistema. Anche permessi e privacy richiedono attenzione: la ricerca per somiglianza non sostituisce controlli di accesso, politiche di conservazione o valutazioni sui dati utilizzati. Questi aspetti vanno progettati e verificati per l’implementazione concreta.

Non esiste una soglia universale di dimensione o prestazioni che imponga di adottare un database specializzato. Una base di dati general-purpose con supporto vettoriale può bastare, mentre in altri casi può essere utile valutare un sistema dedicato. La scelta dovrebbe considerare le esigenze del prodotto, la gestione dei dati, i requisiti operativi e i risultati misurati con query reali, anziché basarsi soltanto sull’etichetta del prodotto.

Per verificare una soluzione concreta, esamina la documentazione della versione effettivamente usata: quali metriche e indici supporta, come implementa i filtri, quali garanzie offre per aggiornamenti e permessi e se consente di combinare ricerca vettoriale e lessicale. Le capacità descritte per un prodotto non vanno estese automaticamente a tutti gli altri.

Concetti correlati