Definizione
Un vector database è un sistema di storage ottimizzato per salvare, indicizzare e interrogare vettori ad alta dimensionalità (embedding). L’operazione fondamentale è la similarity search: dato un vettore query, trovare i k vettori più simili nel database.
È l’infrastruttura core per sistemi RAG, ricerca semantica, recommendation e altre applicazioni AI che richiedono retrieval basato su significato invece che keyword matching.
Come funziona
Indexing: i vettori vengono organizzati in strutture dati che permettono ricerca efficiente. Algoritmi comuni: HNSW (Hierarchical Navigable Small World), IVF (Inverted File Index), PQ (Product Quantization).
Similarity search: dato un vettore query, l’indice identifica i candidati più probabili e calcola la distanza effettiva. Metriche comuni: cosine similarity, euclidean distance, dot product.
Approximate Nearest Neighbor (ANN): per scalare a milioni/miliardi di vettori, si sacrifica precisione per velocità. Il database restituisce risultati “sufficientemente vicini”, non garantitamente i più vicini in assoluto.
Soluzioni principali
Database specializzati: Pinecone, Weaviate, Qdrant, Milvus, Chroma. Ottimizzati per vector workload, managed o self-hosted.
Estensioni di database esistenti: pgvector (PostgreSQL), Atlas Vector Search (MongoDB), OpenSearch. Permettono vector search senza infrastruttura aggiuntiva.
In-memory: FAISS (Facebook), Annoy (Spotify). Librerie per vector search, non database completi. Adatte per prototipi o dataset che entrano in RAM.
Criteri di scelta
Scala: quanti vettori? Migliaia (in-memory bastano), milioni (database specializzato), miliardi (soluzioni enterprise).
Latency requirements: p99 latency accettabile? HNSW offre bassa latenza, IVF è più memory-efficient ma più lento.
Filtering: serve filtrare per metadata oltre alla similarity? Non tutte le soluzioni gestiscono bene hybrid search (vector + filter).
Managed vs self-hosted: Pinecone è fully managed, Qdrant/Milvus richiedono ops. Trade-off costo vs controllo.
Costi: modelli di pricing variano. Per-query, per-vector-stored, per-compute. A scala, le differenze sono significative.
Considerazioni pratiche
Dimensionalità: vettori a 1536 dimensioni (OpenAI) occupano ~6KB ciascuno. 10 milioni di vettori = ~60GB solo per i vettori, più indici e metadata.
Index build time: costruire l’indice HNSW su milioni di vettori richiede ore. Pianificare per update incrementali o re-indexing periodico.
Recall vs latency trade-off: parametri dell’indice (ef_construction, M per HNSW) bilanciano accuratezza e velocità. Tuning specifico per use case.
Fraintendimenti comuni
”Ho bisogno di un vector database per ogni progetto RAG”
Per prototipi o corpus piccoli, FAISS in-memory o pgvector su un PostgreSQL esistente possono bastare. Il database dedicato serve quando la scala o i requisiti di latency lo giustificano.
”Tutti i vector database sono uguali”
Le differenze in performance, feature (hybrid search, multi-tenancy, filtering), operational complexity e costi sono significative. Benchmarkare sul proprio use case.
”La similarity search è esatta”
La maggior parte delle implementazioni production usa ANN, che è approssimata. Il recall (quanti dei veri nearest neighbor vengono trovati) è configurabile ma raramente 100%.
Termini correlati
- Embeddings: i vettori che vengono salvati
- RAG: pattern architetturale che usa vector database per retrieval
Fonti
- ANN Benchmarks: confronto algoritmi e implementazioni
- Malkov, Y. & Yashunin, D. (2018). Efficient and Robust Approximate Nearest Neighbor using Hierarchical Navigable Small World Graphs. IEEE TPAMI