Vector Database e Embeddings — La Memoria Semantica dei Sistemi AI

Cos'è: Un vector database è un sistema di archiviazione ottimizzato per vettori numerici ad alta dimensionalità — le rappresentazioni matematiche del significato semantico prodotte dai modelli di embedding. È il componente che dà "memoria a lungo termine" ai sistemi RAG e agli agenti AI, permettendo ricerche per similarità semantica invece che per corrispondenza esatta di parole chiave.

Cosa sono gli Embedding: dal testo allo spazio vettoriale

Un embedding è la trasformazione di un oggetto — testo, immagine, audio — in un vettore numerico di dimensione fissa. Il principio fondamentale è che oggetti semanticamente simili producono vettori geometricamente vicini nello spazio ad alta dimensionalità.

Quando si invia la frase "il cane abbaia" a un modello di embedding, si ottiene un vettore di, ad esempio, 1536 numeri float. La frase "il labrador fa rumore" produrrà un vettore molto simile — la distanza tra i due sarà piccola. "La banca centrale alza i tassi" produrrà invece un vettore distante. Questa proprietà geometrica del significato è ciò che rende possibile la ricerca semantica.

Il modello text-embedding-ada-002 di OpenAI produce vettori a 1536 dimensioni ed è rimasto lo standard de facto per anni a un costo di $0.0001 per 1000 token. I modelli più recenti della famiglia text-embedding-3 offrono versioni a 256, 1536 e 3072 dimensioni con performance superiori e la possibilità di riduzione dimensionale senza perdita qualitativa significativa.

Similarità Coseno vs Keyword Search: perché cambia tutto

Un database relazionale tradizionale — o un motore full-text come Elasticsearch — trova documenti che contengono esattamente le parole cercate. La query "automobile elettrica" non restituirà documenti che parlano di "veicoli a batteria" a meno di configurazioni esplicite di sinonimia.

La ricerca vettoriale usa la similarità coseno (o il prodotto scalare, equivalente per vettori normalizzati) come metrica di distanza. Matematicamente, è il coseno dell'angolo tra due vettori: 1 significa identici, 0 ortogonali, -1 opposti. Questo permette di trovare documenti semanticamente pertinenti anche quando non condividono nessuna parola con la query.

Il limite della ricerca vettoriale pura è la precisione su valori esatti: date, codici prodotto, nomi propri poco frequenti. Per questo i sistemi di produzione spesso adottano hybrid search — una combinazione di ricerca vettoriale (recall semantico) e BM25 keyword search (precisione lessicale), con un reranker che fonde i risultati.

Vector Database per RAG: perché sono indispensabili

RAG (Retrieval-Augmented Generation) è il pattern architetturale dominante per dare ai LLM accesso a conoscenza esterna aggiornata senza fine-tuning. Il flusso è: (1) indicizzazione — i documenti vengono suddivisi in chunk, embedding-ati e salvati nel vector DB; (2) retrieval — la query dell'utente viene embedding-ata e si cercano i chunk più simili; (3) generation — i chunk recuperati vengono inseriti nel contesto del LLM come knowledge base.

Senza un vector database, il retrieval richiederebbe di calcolare la similarità tra la query e ogni singolo documento ogni volta — computazionalmente improponibile su corpus di milioni di elementi. I vector database usano indici specializzati per rispondere in millisecondi.

La qualità del RAG dipende criticamente da tre variabili: la qualità del modello di embedding, la strategia di chunking (dimensione e overlap dei segmenti), e la soglia di similarità usata per il retrieval. Un embedding poco espressivo o chunk troppo grandi degradano il recall anche con il miglior database.

I Player Principali: Pinecone, Weaviate, Chroma, pgvector

Pinecone è la soluzione managed più diffusa in produzione enterprise. Offre un'API semplice, sharding automatico, filtering per metadata, e latenze sub-10ms su miliardi di vettori. Il costo scala con il numero di vettori e le query al secondo; non esiste opzione self-hosted, il che è sia un vantaggio operativo che un rischio di vendor lock-in.

Weaviate è open source (Apache 2.0) e offre funzionalità avanzate: multi-tenancy nativa, moduli di embedding integrati (supporta OpenAI, Cohere, HuggingFace direttamente), hybrid search out-of-the-box, e GraphQL API. È la scelta preferita quando si vuole controllo totale sull'infrastruttura o si gestiscono dati sensibili che non possono uscire dal perimetro aziendale.

Chroma è il vector database leggero per sviluppo e prototipazione. Gira in-process come libreria Python, persiste su disco locale, e richiede zero configurazione. Non è progettato per uso production su larga scala, ma è la scelta ideale per MVP, notebook Jupyter e applicazioni con corpus sotto il milione di documenti.

pgvector è un'estensione per PostgreSQL che aggiunge il tipo di dato vector e operatori di similarità. Permette di fare ricerca vettoriale nello stesso database relazionale già usato dall'applicazione, eliminando un componente infrastrutturale. La performance è inferiore a soluzioni dedicate su dataset molto grandi, ma per applicazioni con meno di qualche milione di vettori è spesso la scelta più pragmatica.

HNSW: come funziona la ricerca approssimata

La ricerca esatta del vettore più vicino su milioni di elementi richiederebbe il confronto lineare con tutti — O(n). L'algoritmo HNSW (Hierarchical Navigable Small World) risolve il problema costruendo un grafo multi-livello: i livelli superiori sono sparse (pochi nodi, connessioni lunghe per navigazione veloce), i livelli inferiori sono densi (tutti i nodi, connessioni corte per precisione locale).

La ricerca inizia dai livelli alti, scende progressivamente, e termina con una ricerca locale nel vicinato del punto di atterraggio. Il risultato non è garantito essere il vettore esattamente più vicino (da cui "approssimata"), ma in pratica il recall@10 supera il 95% con latenze dell'ordine di microsecondi per vettore. Il parametro ef_construction controlla il tradeoff tra velocità di indicizzazione e qualità dell'indice; ef_search controlla il tradeoff tra latenza di query e recall.

Alternative includono IVF (Inverted File Index, più veloce da costruire ma recall inferiore) e ScaNN di Google (ottimizzato per hardware specifico). HNSW rimane lo standard de facto per la maggior parte dei casi d'uso.

---