I “Vector Databases” (o più in generale: “Vector Stores”) sono una tipologia di database particolarmente in voga nell’ultimo periodo, poiché molto legati al sempre più crescente settore dell’Intelligenza Artificiale. Alcune persone si riferiscono ai vector databases come “Databases for the A.I. Era”.
Uno degli approcci più comuni per archiviare e ricercare dati non strutturati (e.g. immagini, video, audio, testo, …) è quello di calcolare e archiviare una loro rappresentazione vettoriale. Durante la fase di ricerca, la query non strutturata viene trasformata in un vettore di embeddings e quindi confrontata con i vettori di embeddings archiviati per trovare quelli che sono più simili alla query.
Nel caso specifico dell’Intelligenza Artificiale, l’elaborazione e la gestione efficiente dei dati sta diventando sempre più cruciale; soprattutto per le applicazioni che coinvolgono grandi modelli linguistici (LLM), AI generativa e ricerca semantica.
La maggioranza di queste applicazioni si basano sull’uso di embeddings per rappresentare i dati, spesso contenenti cruciali informazioni semantiche per i modelli. Tali dati spesso rappresentano la memoria a lungo termine a cui attingere per eseguire compiti complessi.
Gli embeddings vengono generalmente generati dai modelli di AI (e.g. LLM) e hanno un gran numero di attributi o caratteristiche, rendendo la loro rappresentazione difficile da gestire con tecniche tradizionali. Ogni embedding è un vettore con un certo numero di dimensioni, che possono variare da decine a migliaia, a seconda della complessità e della granularità dei dati.
In risposta alla necessità di gestire grandi volumi di embeddings e la loro intrinseca complessità, nascono i vector databases/stores. I database di questo tipo sono progettati appositamente per la gestione di vettori di grandi dimensioni, offrendo funzionalità di archiviazione e interrogazione ottimizzate per questa specifica tipologia di dati.
A differenza dei database scalari tradizionali, i database vettoriali sono in grado di gestire efficacemente la complessità e la scala dei dati vettoriali, consentendo di estrarre informazioni e analizzare i dati in tempo reale. L’utilizzo di un database vettoriale consente di aggiungere agilmente funzionalità avanzate ai modelli di IA, come il recupero di informazioni semantiche e una memoria a lungo termine.
Segue uno schema di esempio di utilizzo per LLM:
Immagine da: https://www.pinecone.io/learn/vector-database/
Innanzitutto, utilizziamo il modello per creare degli embeddings vettoriali per il contenuto che vogliamo indicizzare, ad esempio dei documenti testuali (nel caso dei LLM).
- L’embedding vettoriale viene inserito nel database vettoriale, con un riferimento al contenuto originale dal quale è stato creato l’embedding (ad esempio l’id del documento).
- Quando l’applicazione emette una query, utilizziamo lo stesso modello per creare degli embeddings per la query e utilizziamo tale rappresentazione per effettuare una ricerca nel database alla ricerca di quelli simili. Come già accennato, tali embeddings simili sono associati al contenuto originale dal quale sono stati creati. Il vector DB ci permetterà di effettuare tali controlli di similarità in modo efficace e efficiente.
Traditional vs Vector DB
L’idea alla base è che, mentre un database tradizionale (e.g. relazionale) è ottimizzato per archiviare e interrogare dati tabellari composti da stringhe, numeri e altri dati scalari, i database vettoriali sono ottimizzati per operare su dati di tipo vettoriale.
Nei database tradizionali, di solito si effettuano ricerche di righe nel database dove il valore di un determinato campo corrisponde esattamente a dei filtri della nostra query.
Nei database vettoriali, invece, applichiamo una metrica di similarità per trovare un vettore che sia il più simile possibile alla nostra query.
Se ad esempio nel nostro db abbiamo una serie di embeddings relativi a documenti testuali, potremmo essere interessati al documento più simile alla nostra query. In questo caso dovremmo confrontare il vettore degli embedding rappresentanti la query con tutti quelli dei documenti, e trovare il più simile (secondo una metrica).
Un database vettoriale utilizza una combinazione di diversi algoritmi con lo scopo ultimo di effettuare una ricerca di similarità A.N.N. (Approximate Nearest Neighbor). Questi algoritmi ottimizzano la ricerca tramite hashing, quantizzazione o ricerca basata su grafi.
La similarità invece viene ad esempio calcolata con:
- Cosine similarity
- Euclidean distance
- Dot product
Esempio di tecniche utilizzate dai Vector DB:
- Random Projection: è un metodo di riduzione della dimensionalità che prevede la proiezione di vettori ad alta dimensionalità in uno spazio a bassa dimensionalità utilizzando una matrice di proiezione casuale. Questo processo consente di mantenere la similarità tra i vettori originali, ma con un numero inferiore di dimensioni. Quando si effettua una query, viene utilizzata la stessa matrice di proiezione per proiettare la query nello spazio a bassa dimensionalità e cercare i vettori più simili nel database. Grazie alla riduzione della dimensionalità dei dati, il processo di ricerca è significativamente più veloce rispetto alla ricerca nello spazio ad alta dimensionalità completo.
- Product Quantization: è una tecnica di compressione “lossy” per vettori ad alta dimensionalità. Il processo di PQ prevede la suddivisione del vettore originale in segmenti più piccoli, semplificando la rappresentazione di ciascun segmento creando un “codice” rappresentativo e riunendo tutti i segmenti. Il numero di rappresentanti nel codice rappresentativo è un compromesso tra l’accuratezza della rappresentazione e il costo computazionale della ricerca. Quando si effettua una query, il vettore viene suddiviso in sotto-vettori e quantizzato utilizzando lo stesso codice rappresentativo. In seguito viene utilizzato per trovare i vettori più vicini al vettore di interrogazione.
- Locality-Sensitive Hashing (LSH): è una tecnica di indicizzazione nell’ambito di una ricerca approssimata dei vicini più simili. È ottimizzata per la velocità pur fornendo un risultato approssimativo e non esaustivo. LSH mappa vettori simili in “bucket” utilizzando un insieme di funzioni di hashing. Per trovare i vicini più vicini per un dato vettore di interrogazione, utilizziamo le stesse funzioni di hashing utilizzate per ottenere i bucket di vettori simili. Il vettore di interrogazione viene hashato in una tabella specifica e quindi confrontato con gli altri vettori in quella stessa tabella per trovare le corrispondenze più vicine. In questo modo, LSH consente di effettuare ricerche efficienti di vicini approssimativi in grandi collezioni di dati ad alta dimensionalità.
- Hierarchical Navigable Small World (HNSW): crea una struttura gerarchica simile a un albero, in cui ogni nodo rappresenta un insieme di vettori. Gli archi tra i nodi rappresentano la similarità tra i vettori. L’algoritmo inizia creando un insieme di nodi, ognuno con un piccolo numero di vettori. Ciò può essere fatto casualmente o raggruppando i vettori con algoritmi come k-means, in cui ogni cluster diventa un nodo. Successivamente, l’algoritmo esamina i vettori di ogni nodo e crea un collegamento tra quel nodo e i nodi che hanno i vettori più simili a quelli del nodo in questione. Quando effettuiamo una query su un indice HNSW, questo utilizza il grafo per navigare nell’albero, visitando i nodi che probabilmente contengono i vettori più vicini al vettore di interrogazione.
Esempi di Vector DB
Una lista esaustiva di vector DB (Vector Stores) è quella relativa alle integrazioni supportate/incluse in langchain: sezione “integrations”. https://python.langchain.com/docs/integrations/vectorstores/
I più diffusi/popolari (Luglio 2023):
- Supabase: 54k ⭐ il prodotto più diffuso e popolare, è l’alternativa open-source a firebase e include anche funzionalità da vector-db. Sia self-hosted che managed-cloud-service.
- Milvus: 21.5k ⭐ il database di tipo vector-store più diffuso. Il principale punto di forza risiede nella capacità di utilizzare la GPU per effettuare query di similarità su quantità di dati molto grandi. Sia self-hosted che managed-cloud-service.
- Qdrant: 11.8k ⭐ Sia self-hosted che managed-cloud-service.
- Chroma: 7.5 k ⭐ Per ora disponibile solo come libreria “in-memory single-process”.
- Weaviate: 6.9k ⭐ Sia self-hosted che managed-cloud-service.
Bibliografia / fonti utili di approfondimento
- Langchain Vector Stores
- Pinecone, what is a vector DB
- Top 5 Vector Databases
- Microsoft: What is a vector database?
- Vector Databases in Action: Real-World Use Cases and Benefits (Medium.com)
- Explaining Vector Databases in 3 Levels of Difficulty
- Vector Databases simply explained! (Embeddings & Indexes)
- OpenAI Embeddings and Vector Databases Crash Course