Vector database: Pinecone, Qdrant, l'era degli LLM

Per le ultime sei lezioni abbiamo categorizzato i data store in base alla forma dei loro dati: tabelle, documenti, coppie chiave-valore, colonne, grafi, time series. Ognuna di queste categorie esisteva già prima che la precedente diventasse di moda, e ognuna risolve bene un certo tipo di query. Questa lezione parla di una categoria che, prima del 2022, non esisteva davvero come linea di prodotto separata, e che oggi tutta l’industria considera un requisito minimo per qualsiasi applicazione costruita sopra un large language model. La categoria è il vector database, e la sua ascesa è uno degli spostamenti più bruschi nella storia dell’infrastruttura dati.

Il motivo per cui è apparso così all’improvviso è che il workload che serve, prima, non esisteva su scala. Il workload è “data questa query, trova i documenti semanticamente più simili in un corpus di milioni o miliardi di item, in meno di cento millisecondi.” Quella query, formulata così, è il cavallo da battaglia di ogni pipeline di retrieval-augmented generation, di ogni search box semantico moderno, di ogni feature “trovami prodotti simili a questo”, e di una lunga lista di casi d’uso meno ovvi. La tecnologia che rende quella query abbastanza economica da poter essere un building block è il tema di questa lezione.

Il modello dei dati: le righe sono punti nello spazio

Un vector database memorizza righe in cui ogni riga è, in primo luogo, un array di float ad alta dimensionalità. Gli array hanno tipicamente tra 384 e 3072 dimensioni, a seconda del modello di embedding che li ha prodotti. Un vettore a 384 dimensioni è quello che ti dà all-MiniLM-L6-v2 di sentence-transformers. Un vettore a 1536 dimensioni è quello che produceva il vecchio text-embedding-ada-002 di OpenAI. Un vettore a 3072 dimensioni è quello che produce text-embedding-3-large a piena dimensione. I Voyage embeddings di Anthropic, embed-v3 di Cohere, text-embedding-005 di Google: stessa idea, dimensioni diverse, corpora di training diversi.

Insieme al vettore, ogni riga porta con sé dei metadati: un identificatore, il testo originale o un puntatore a esso, tag, timestamp, qualunque cosa tu voglia poter filtrare. I metadati sono ciò che ti permette di dire “trovami i K vettori più vicini, ma solo tra i documenti taggati ‘pricing’ e modificati negli ultimi trenta giorni.”

La query non è “dammi la riga con primary key X.” È “dammi le K righe i cui vettori sono più vicini a questo vettore di query.” La vicinanza si misura con una di tre distanze:

Cosine similarity: l’angolo tra due vettori, ignorando la magnitudine. La scelta più comune per gli embedding di testo, perché la magnitudine di un embedding non porta significato, lo porta solo la direzione.
Distanza euclidea (L2): la distanza in linea retta tra due punti. Utile quando la magnitudine conta, per esempio quando il modello di embedding è stato addestrato pensando a L2.
Dot product: cosine similarity moltiplicata per le magnitudini. Più veloce della cosine perché non c’è il passo di normalizzazione. Alcuni modelli sono esplicitamente addestrati per essere interrogati con il dot product.

Se scegli la distanza sbagliata per il tuo modello, i tuoi risultati silenziosamente peggiorano ma non si rompono in modo evidente, che è il tipo peggiore di bug. Leggi la documentazione del modello di embedding, usa la distanza che raccomanda, e scrivi un test che verifica che la raccomandazione non sia cambiata quando aggiorni.

Perché i vettori sono diventati importanti

Il motivo per cui questa cosa ha smesso di essere una curiosità da ricerca ed è diventata una categoria di prodotto è che gli embedding di testo sono diventati buoni. Prima del 2020 circa, trasformare un paragrafo in un vettore di dimensione fissa che ne catturasse il significato era difficile e i risultati erano deboli. I vettori si raggruppavano per topic, in linea di massima, ma non potevi affidarti al fatto che “questi due paragrafi parlano della stessa cosa” fosse una proprietà di “i loro vettori sono vicini.” Adesso puoi. Sentence-transformers, la linea di embedding di OpenAI, Cohere, Voyage, le opzioni open-weights come BGE e Nomic: ognuna di queste produce embedding in cui la similarità semantica nel testo si mappa in modo affidabile sulla vicinanza geometrica nello spazio vettoriale.

Una volta che quella mappatura è affidabile, una lunga lista di applicazioni diventa una one-liner sopra un indice vettoriale:

Retrieval-augmented generation (RAG): prima di chiedere all’LLM “riassumi la nostra refund policy”, incorpora la domanda, prendi i top K passaggi più simili dalla tua knowledge base, e passali all’LLM come contesto. L’LLM smette di allucinare perché sta leggendo la policy reale. RAG è, entro il 2026, l’architettura di default per qualsiasi chatbot o assistente ancorato a dati privati.
Ricerca semantica: la search box sul tuo sito di documentazione smette di richiedere all’utente di indovinare le tue keyword. “Come faccio a cancellare il mio abbonamento” trova la pagina intitolata “Terminare il piano” perché gli embedding sanno che parlano della stessa cosa.
Raccomandazioni: “prodotti simili a quello che hai appena visualizzato” diventa una query di nearest-neighbor sugli embedding del catalogo prodotti. Niente più cold-start, niente più regole di similarità basate su tassonomie costruite a mano.
Similarità di immagini e audio: lo stesso trucco funziona per dati non testuali. I modelli stile CLIP incorporano le immagini nello stesso tipo di spazio vettoriale. Puoi fare deduplica di una libreria di foto, trovare sosia, fare ricerca inversa per immagini, tutto con la stessa primitiva nearest-neighbor.
Anomaly detection: clusterizza i vettori dei tuoi eventi normali. Qualunque cosa che cade lontano da ogni cluster è una candidata anomalia. Utile per frodi, intrusion detection, item difettosi su una linea di produzione.

L’osservazione unificante è che “cose che significano roba simile” diventano “vettori che sono vicini tra loro”, e un vector database è l’indice che rende economico “trova quelli vicini”.

ANN: approximate nearest neighbor

La ricerca esatta del nearest-neighbor in alta dimensionalità è costosa. Per trovare il vettore singolo più vicino a una query in un corpus di un milione di vettori a 1536 dimensioni, devi calcolare un milione di distanze, ognuna delle quali è un dot product di 1536 elementi. Sull’hardware moderno è fattibile ma lento. Farlo a una latenza p99 sotto i 50 millisecondi, per migliaia di query al secondo, su un corpus di un miliardo di vettori, non lo è.

Il trucco che rende la ricerca vettoriale praticabile è rinunciare al nearest-neighbor esatto e accettare il nearest-neighbor approssimato (ANN). Costruisci un indice che, per qualsiasi query, restituisce i K vettori più vicini con altissima probabilità, ma con una piccola probabilità di mancarne uno e di includerne al suo posto uno leggermente più lontano. In cambio, la query diventa ordini di grandezza più veloce.

L’algoritmo ANN dominante nel 2026 è HNSW (Hierarchical Navigable Small World). L’intuizione: costruisci un grafo a strati in cui lo strato superiore connette punti lontani tra loro e ogni strato inferiore aggiunge connessioni più fini. Per cercare, parti dall’alto, cammini avidamente verso la query, scendi di uno strato, ripeti. La struttura del grafo significa che ogni query tocca un piccolo numero di vettori invece di tutti. HNSW è ciò che Pinecone, Qdrant, Weaviate, e pgvector usano di default, in implementazioni leggermente diverse.

Vengono fuori altri due algoritmi. IVF (Inverted File) clusterizza i vettori con k-means, poi al momento della query cerca solo nei pochi cluster più vicini. Più veloce da costruire di HNSW, leggermente meno accurato a parità di recall. Spesso combinato con la product quantization (PQ) per comprimere i vettori stessi. ScaNN, di Google, è un design più recente che combina partitioning, anisotropic quantization, e un passo di re-ranking accurato. ScaNN è ciò che BigQuery e Vertex AI usano sotto il cofano.

L’implicazione pratica è che regoli due manopole. La prima è il recall, la frazione dei veri nearest-neighbor che l’indice ANN restituisce davvero. Il 95% di recall è tipico in produzione. Il 99%+ è raggiungibile ma più lento. La seconda è la latenza, che è inversamente correlata al recall. Scegli un punto sulla curva che si adatta alla tua applicazione e misuri entrambe.

Il panorama dei vector database 2024-2026

La categoria si è consolidata attorno a una manciata di opzioni.

Pinecone. Il primo vector database a essere un prodotto commerciale serio. Completamente managed, solo hosted. API piacevole, forte sull’affidabilità. Costoso su scala, e il lock-in è reale perché non c’è un Pinecone che puoi far girare da te. La scelta giusta quando vuoi zero carico operativo e il tuo volume di vettori è abbastanza piccolo da rendere la fattura accettabile. La scelta sbagliata quando il tuo numero di vettori supera le decine di milioni e la fattura inizia a dominare i tuoi costi infrastrutturali.

Qdrant. Open-source, scritto in Rust. Self-host o usa il managed Qdrant Cloud. Veloce, ben documentato, con un’API di filtering pulita che combina ricerca vettoriale con predicati sui metadati in modo efficiente. Il modello open-source-con-opzione-cloud è il pattern dominante in questa generazione di vector DB, e Qdrant è una delle implementazioni più solide.

Weaviate. Open-source, interfaccia di query basata su GraphQL, supporto built-in per la ricerca ibrida (similarità vettoriale combinata con la ricerca tradizionale per keyword via BM25). Per ricerca focalizzata sul testo dove gli utenti a volte digitano domande e a volte digitano termini esatti, la qualità dei risultati ibridi è significativamente migliore della pura vettoriale o della pura keyword. Weaviate include anche moduli vectoriser che ti permettono di saltare il passo “embedda il testo da te”, che è comodo per il prototyping e un coupling non necessario per la produzione.

Milvus. Open-source, architettura distribuita progettata fin dall’inizio per miliardi di vettori. La complessità è proporzionalmente più alta: più parti in movimento, più superficie operativa. La scelta giusta se hai un workload da un miliardo di vettori e il team per far girare un sistema distribuito. La scelta sbagliata per una startup che non ha ancora raggiunto i dieci milioni di vettori.

pgvector. Un’estensione Postgres che aggiunge un tipo di colonna vector, operatori di distanza, e un indice HNSW. Se sei già su Postgres, e il tuo volume di vettori è sotto i 50 milioni circa, pgvector è la risposta giusta quasi di default. Ottieni la ricerca vettoriale a fianco dei tuoi dati relazionali esistenti, nella stessa transazione, con la stessa storia di backup, replica e access control. Le performance sono competitive con i vector database dedicati a questa scala. Sopra i 100M di vettori i sistemi dedicati prendono il largo, ma la maggior parte delle applicazioni non raggiunge mai quel tetto.

Elasticsearch e OpenSearch. Entrambi hanno aggiunto tipi di campo vettoriali nativi e indici HNSW. L’immagine speculare della storia di pgvector: se fai già girare Elasticsearch, aggiungere la ricerca vettoriale allo stesso cluster è semplice e il supporto per le query ibride è genuinamente buono. Se non sei già su Elasticsearch, non adottarlo solo per i vettori.

L’albero decisionale, semplificato:

Già su Postgres, sotto i 50M di vettori: pgvector.
Già su Elasticsearch o OpenSearch, vuoi ricerca ibrida: i loro campi vettoriali nativi.
Hai bisogno di ricerca ibrida e non sei su nessuno dei due sopra: Weaviate.
Hai bisogno di un servizio managed e la fattura va bene: Pinecone.
Self-hosting, vuoi semplicità: Qdrant.
Miliardi di vettori, team dedicato: Milvus.

Una pipeline RAG, end to end

La forma più comune di un deployment di un vector database nel 2026 è una pipeline di retrieval-augmented generation. La meccanica:

flowchart LR
    subgraph Ingest
        A[Source documents] --> B[Chunker]
        B --> C[Embedding model]
        C --> D[(Vector DB)]
    end
    subgraph Query
        Q[User question] --> E[Embedding model]
        E --> F[Vector DB lookup]
        F --> G[Top K passages]
        G --> H[LLM with context]
        H --> R[Answer]
    end
    D -.-> F

Due metà: la pipeline di ingest, che gira ogni volta che i documenti cambiano, e il percorso di query, che gira a ogni domanda dell’utente. L’ingest spezza i documenti lunghi in chunk (comunemente da 200 a 800 token ciascuno, con sovrapposizione), incorpora ogni chunk, e scrive il vettore più il testo del chunk e i metadati nel database. La query incorpora la domanda dell’utente con lo stesso modello, prende i top K chunk più simili, e li passa all’LLM come contesto.

I dettagli contano. La dimensione del chunk influenza la qualità del retrieval: troppo piccolo e i chunk mancano di contesto, troppo grande e contenuto irrilevante diluisce il segnale rilevante. Lo stesso modello deve essere usato sia per l’ingest sia per la query, altrimenti i vettori vivono in spazi diversi e la distanza non ha senso. K è di solito tra 3 e 20 a seconda della context window dell’LLM e della tolleranza dell’applicazione al rumore. Il system prompt deve istruire l’LLM ad ancorare la sua risposta nel contesto fornito e a dire “non lo so” quando il contesto non contiene la risposta, altrimenti il problema dell’allucinazione torna.

I vettori non sostituiscono il relazionale

L’inquadramento che mi ha aiutato quando stavo prendendo confidenza con questa categoria è stato: un vector database non è un sostituto del tuo database relazionale, è un indice in più per un tipo di query in più. I tuoi dati transazionali appartengono ancora a Postgres. Il tuo inventario, i tuoi utenti, i tuoi ordini, il tuo audit log: come prima. Il vector database tiene gli embedding delle parti di quei dati che vuoi cercare semanticamente, più puntatori di metadati che riportano alle righe sorgente.

Un deployment comune è Postgres come system of record, con un vector database (o pgvector dentro lo stesso Postgres) come indice secondario. I documenti cambiano, un job in background li re-incorpora e aggiorna il vector store. Il vector store non è mai autoritativo per nulla; è un indice di ricerca. Trattalo così e l’architettura resta pulita.

La prossima lezione affronta la domanda più ampia che questa solleva: quando ha senso far girare più data store specializzati come questi, e quando il costo operativo della polyglot persistence è più alto del beneficio? Il modulo 3 finisce lì.

Citazioni e letture aggiuntive

Pinecone documentation, https://docs.pinecone.io (consultato 2026-05-01). Il riferimento per la versione managed-service della categoria.
Qdrant documentation, https://qdrant.tech/documentation/ (consultato 2026-05-01). Copre l’implementazione di HNSW, il filtering, e la decisione managed-vs-self-hosted.
Weaviate documentation, https://weaviate.io/developers/weaviate (consultato 2026-05-01). Il riferimento per la ricerca ibrida e l’interfaccia di query in stile GraphQL.
pgvector, https://github.com/pgvector/pgvector (consultato 2026-05-01). L’estensione Postgres che ha silenziosamente disrupto il mercato dei vector DB standalone.
Yu A. Malkov and D. A. Yashunin, “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs”, IEEE TPAMI 2020. Il paper di HNSW.
Google Research, “Accelerating Large-Scale Inference with Anisotropic Vector Quantization”, 2020. Il paper di ScaNN.