Un database vettoriale memorizza embedding densi e sparsi ad alta dimensionalità insieme ai metadati, offrendo ricerca di similarità tramite Approximate Nearest Neighbor (ANN) in millisecondi come livello base di memoria e retrieval per RAG, ricerca semantica e agenti IA.
| Carico di lavoro / Vincolo | Categoria consigliata | Soluzioni rappresentative | Perché sceglierla |
|---|---|---|---|
| Stack PostgreSQL esistente, sotto ~10M vettori | Estensione DB relazionale | pgvector (+ halfvec / HNSW) | Riutilizza transazioni ACID, JOIN SQL e operatività esistente senza nuova infrastruttura |
| Ricerca ibrida full-text BM25 + vettori | Estensione motore di ricerca | Elasticsearch / OpenSearch / Vespa | Ecosistema maturo di indici invertiti e ranking ibrido multi-fase |
| Servizio dedicato ad alto QPS con filtri complessi | DB vettoriale distribuito dedicato | Qdrant / Milvus / Weaviate | Storage engine dedicato, filtraggio payload rapido e scalabilità orizzontale |
| Sviluppo locale, app edge/desktop o lettura diretta su data lake | DB embedded / colonnare | LanceDB / Chroma / FAISS | Esecuzione in-process con integrazione zero-copy Apache Arrow / Parquet |
| Grandi volumi cold/warm al minimo costo di storage | SaaS nativo su object storage | Turbopuffer | Object Storage (S3/GCS) come fonte di verità + cache locale NVMe/RAM |
| Serverless zero-ops integrato nel cloud pubblico | Servizio cloud gestito | Pinecone / Vertex AI Vector Search / Azure AI Search | Scaling serverless elastico e integrazione nativa IAM e monitoring |
🔗 Guide rapide correlate: Concetti LLM e Agenti IA · Algoritmi IA moderni · Comandi PostgreSQL · Comandi Redis · Comandi MongoDB
1. Concetti fondamentali e metriche di distanza
1.1 Terminologia essenziale
| Termine | Definizione | Aspetti ingegneristici |
|---|---|---|
| Embedding | Array di float a lunghezza fissa che codifica la semantica di testo, immagini o audio | Dimensioni comuni: 384 / 768 / 1024 / 1536 / 3072; RAM e calcolo crescono linearmente |
| ANN (Approximate Nearest Neighbor) | Ricerca su indice che scambia un minimo recall (95%–99%) per accelerazione 100×–1000× | Compromesso chiave latenza vs recall, opposto alla scansione esatta k-NN |
| Metadata Filtering | Filtraggio della ricerca vettoriale tramite attributi scalari (tenant, data, ACL, categoria) | Distinguere Pre-filtering, Single-stage / Inline e Post-filtering |
| Hybrid Search | Combinazione di vettori densi (semantica) e vettori sparsi / BM25 (corrispondenza esatta) | Compensa i limiti semantici su codici SKU, codici errore e acronimi |
| Sparse Vector | Vettore ad alta dimensione composto quasi solo da zeri (es. SPLADE, pesi BM25) | Memorizza solo indici e pesi non nulli; si affianca naturalmente ai vettori densi |
1.2 Tre metriche chiave di distanza e similarità
Cosine(u, v) = (u · v) / (‖u‖₂ · ‖v‖₂)
IP(u, v) = u · v = ∑ᵢ (uᵢ × vᵢ)
L₂(u, v) = √( ∑ᵢ (uᵢ − vᵢ)² )
| Metrica | Significato | Equivalenza matematica | Casi d'uso tipici |
|---|---|---|---|
| Similarità del coseno (Cosine) | Misura solo l'angolo ignorando la norma (−1 a 1; distanza = 1 - cos) |
Ordinamento identico al prodotto interno con vettori normalizzati L₂ | Ricerca semantica testuale, RAG, embedding di frasi (scelta predefinita) |
| Prodotto interno (IP / Dot) | Riflette angolo e ampiezza; costo computazionale minimo | Su vettori unitari sostituisce Cosine evitando radici e divisioni | Recommender a due torri, embedding normalizzati (es. OpenAI) |
| Distanza euclidea (L₂) | Distanza geometrica in linea retta; minore = più vicino | Per vettori unitari: L₂² = 2 − 2 · cos(u, v) |
Embedding immagini/volti, clustering spaziale, feature sensibili alla norma |
2. Algoritmi di indicizzazione ANN e quantizzazione
2.1 Confronto tra indici vettoriali
| Tipo di indice | Meccanismo | Uso RAM | Latenza e Recall | Scala e motori tipici |
|---|---|---|---|---|
| Flat (Scansione esatta) | Calcolo esaustivo della distanza su tutti i vettori | Moderato (solo vettori grezzi/quantizzati) | 100% recall; latenza esplode oltre ~100k righe | Piccoli dataset (<100k) e benchmark di riferimento |
| IVF-Flat (File invertito) | Clustering K-Means in nlist bucket; scansiona i nprobe più vicini |
Basso (nessun overhead di grafo) | Regolabile via nprobe; recall medio-alto |
1M–10M righe con RAM limitata (FAISS / Milvus / pgvector) |
| IVF-PQ (IVF + Product Quantization) | Partizionamento in bucket + compressione per sottospazi con codebook | Molto basso (16×–64× più piccolo) | Ultraveloce; recall iniziale inferiore (richiede rescoring) | 100M+ in memoria (FAISS / Milvus / LanceDB) |
| HNSW (Grafo gerarchico) | Grafo multilivello stile skip-list (strati alti grezzi, base fine) | Alto (vettori + archi in RAM o mmap caldo) | Millisecondi + 95%–99% recall; standard industriale | 1M–100M+ bassa latenza real-time (Qdrant / Milvus / Weaviate / pgvector) |
| DiskANN (Grafo Vamana) | Grafo per SSD: vettori compressi in RAM, grafo completo su NVMe | Basso (RAM ridotta 5×–10×) | 100M+ per nodo in ms; dipende da IOPS NVMe veloci | 100M–1B+ con RAM contenuta (Milvus / LanceDB / Azure) |
| ScaNN | Quantizzazione vettoriale anisotropica + partizionamento ad albero | Basso–Moderato | Miglior curva recall/latenza con prodotto interno | Ricerca e raccomandazione su larga scala (Vertex AI Vector Search / OSS) |
Parametri principali di tuning HNSW:
M(max collegamenti bidirezionali per nodo, tipicamente16–64): valori più alti migliorano il recall in alta dimensione ma aumentano RAM e tempo di build.efConstruction(dimensione lista candidati durante la costruzione, tipicamente100–400): incide solo sul tempo di build e migliora la qualità del grafo.efSearch(ampiezza di ricerca a query time, ≥top_k): unico parametro regolabile per query; aumentarlo alza il recall e riduce il QPS.
2.2 Quantizzazione e stima della memoria
Base di riferimento per 10 milioni di vettori × 1536 dimensioni (FP32 non compresso):
Dimensione grezza ≈ N × D × 4 Byte (il grafo HNSW aggiunge ~1,2×–1,5× di overhead RAM)
| Quantizzazione | Bit / dim | Compressione | Dimensione 10M × 1536-dim | Compromesso precisione e uso |
|---|---|---|---|---|
| FP32 (Non compresso) | 32 bit (4 B) | 1× | ~57,2 GB | Precisione di riferimento; costoso da tenere in RAM |
| FP16 / BF16 (Mezza precisione) | 16 bit (2 B) | 2× | ~28,6 GB | Praticamente senza perdita di recall (es. pgvector halfvec), ottimo ROI |
| SQ8 (Quantizzazione scalare Int8) | 8 bit (1 B) | 4× | ~14,3 GB | Mantiene in genere 97%+ di recall; standard di produzione |
| PQ (Product Quantization) | Sottospazi | 16×–64× | ~1–4 GB | Richiede training del codebook; abbinare a oversampling + rescore |
| BQ (Quantizzazione binaria 1 bit) | 1 bit | 32× | ~1,79 GB | Scansione Hamming ultrarapida; usare rescore 3×–5× (ideale ≥1024 dim) |
3. Confronto stratificato delle soluzioni
3.1 Database vettoriali nativi dedicati
| Prodotto | Licenza / Deploy | Linguaggio e Storage | Indici e punti chiave | Scenario ideale |
|---|---|---|---|---|
| Qdrant | Apache 2.0 / Self-hosted & Cloud | Rust; in-memory, mmap su disco e quantizzazione su disco | HNSW + SQ8/BQ; vettori sparsi nativi e indici rapidi su payload | Servizio standalone ad alto QPS, multi-tenant, filtri complessi |
| Milvus | Apache 2.0 / Distribuito & Zilliz Cloud | Control plane Go + esecuzione C++; object storage + MQ disaccoppiati | IVF, HNSW, DiskANN, GPU CAGRA; partizioni multi-tenant | Piattaforme enterprise su scala del miliardo |
| Weaviate | BSD-3-Clause (alcuni extra enterprise chiusi) | Go; object storage + indice invertito integrati | HNSW + quantizzazione dinamica/PQ/BQ; GraphQL/REST, moduli vectorizer | App RAG con pipeline di embedding integrata |
| Chroma | Apache 2.0 / Embedded & Client-Server | Core Python / Rust; SQLite + storage locale o distribuito | HNSW; API minimale, forte integrazione LangChain / LlamaIndex | Prototipazione rapida e RAG Python medio-piccolo |
| LanceDB | Apache 2.0 / Embedded & Enterprise | Rust; formato colonnare Lance e Apache Arrow | IVF-PQ, HNSW, DiskANN; I/O zero-copy, multimodale nativo (audio/video/tabelle) | App locali embedded, lettura serverless da S3, data lake multimodali |
| Pinecone | SaaS Serverless proprietario | Motore distribuito gestito (evoluto da Pod a Serverless) | Indice proprietario disaccoppiato; ibrido sparse-dense, isolamento Namespace | Team cloud zero-ops che privilegiano semplicità gestita |
| Turbopuffer | SaaS proprietario / BYOC | Rust; object storage (S3/GCS) come verità + cache NVMe/RAM | Indice a centroidi (stile SPFresh) evitando salti random I/O; testo + vettore | Enormi volumi cold/warm (es. indicizzazione codice) a costi minimi |
3.2 Librerie di ricerca vettoriale (non DB completi)
| Prodotto | Licenza | Ambito e limiti | Casi d'uso |
|---|---|---|---|
| FAISS (Meta) | MIT | Libreria di similarità C++ / Python (niente persistenza metadati, transazioni distribuite o server auth); CPU SIMD & multi-GPU | Calcolo batch offline, ricerca ML, motore embedded in architetture custom |
3.3 Estensioni di database e motori di ricerca tradizionali
| Prodotto | Base | Funzionalità vettoriali | Punti di forza e limiti |
|---|---|---|---|
| pgvector | Estensione PostgreSQL (incl. Supabase) | Tipi vector / halfvec / sparsevec / bit; HNSW e IVFFlat |
Pro: ACID, JOIN SQL, zero nuova ops; Contro: write amplification e RAM >10M–50M righe |
| Elasticsearch / OpenSearch | Indice invertito Lucene + HNSW | Ibrido nativo Dense Vector + BM25, fusione RRF, filtri annidati | Pro: riusa team e stack search esistenti; Contro: alto uso RAM off-heap JVM e merge segmenti |
| Redis (Query Engine) | KV store in memoria | Flat & HNSW, latenza sub-millisecondo, aggiornamenti real-time | Pro: ideale per cache semantica e feature store; Contro: costi RAM elevati su larga scala |
| MongoDB Atlas Search | DB documentale (Atlas / Local CLI) | HNSW basato su Lucene insieme ai documenti BSON | Pro: elimina doppia scrittura doc/vettore; Contro: ricerca principale legata ad Atlas |
| SingleStore | DB SQL HTAP distribuito | SQL + funzioni vettoriali native (dot / L₂), colonne + righe | Carichi aziendali misti tra analytics real-time e transazioni |
| Vespa | Motore big-data Apache 2.0 | HNSW + ibrido esatto/approssimato, ranking ML multifase (Tensor/XGBoost/ONNX) | Piattaforme massive ricerca/raccomandazione; curva operativa più ripida |
3.4 Servizi cloud completamente gestiti
| Servizio | Provider | Architettura e punti salienti |
|---|---|---|
| Vertex AI Vector Search (ex Matching Engine) | Google Cloud (GCP) | Basato su ScaNN; aggiornamenti streaming su scala miliardi e ibrido sparse-dense |
| Amazon OpenSearch Serverless / Aurora pgvector | AWS | Cluster serverless gestiti ed estensioni RDS/Aurora integrate con Amazon Bedrock |
| Azure AI Search | Microsoft Azure | Semantic Ranker integrato, pipeline di vettorizzazione e controllo accessi RBAC enterprise |
4. Strategie di filtraggio e ricerca ibrida
4.1 Modalità di esecuzione dei filtri sui metadati
| Strategia | Ordine di esecuzione | Criticità e mitigazione |
|---|---|---|
| Pre-filtering | Valuta l'indice scalare per produrre una bitmap ID, poi cerca i vettori | Con filtri molto selettivi (<1%) il grafo si frammenta; Mitigazione: fallback automatico a scansione esatta |
| Post-filtering | Estrae il Top-K globale e scarta gli elementi fuori filtro | Rischia di restituire meno di K risultati (o zero); Mitigazione: mai usare da solo senza ampio oversampling |
| Single-stage / Inline | Verifica dinamicamente la bitmap del filtro a ogni salto del grafo HNSW | Standard attuale (Qdrant / Milvus / Weaviate / pgvector 0.8+ iterative scan) per bilanciare recall e latenza |
4.2 Reciprocal Rank Fusion (RRF)
Poiché i punteggi di ricerca densa e BM25 usano scale diverse, RRF fonde direttamente le classifiche senza calibrazione:
RRF_Score(d) = ∑_{r ∈ R} 1 / (k + rank_r(d)) (costante standard di smoothing k = 60)
5. Snippet pronti per la produzione
5.1 Schema pgvector, indice HNSW e scansione iterativa (SQL)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
tenant_id INT NOT NULL,
content TEXT NOT NULL,
embedding halfvec(1536), -- float16 riduce la RAM del 50% rispetto a float32
fts tsvector GENERATED ALWAYS AS (to_tsvector('simple', content)) STORED
);
CREATE INDEX idx_docs_emb_hnsw ON documents
USING hnsw (embedding halfvec_cosine_ops)
WITH (m = 16, ef_construction = 128);
CREATE INDEX idx_docs_fts ON documents USING gin (fts);
SET hnsw.ef_search = 100;
SET hnsw.iterative_scan = relaxed_order;
SELECT id, content, 1 - (embedding <=> $1::halfvec) AS cosine_sim
FROM documents
WHERE tenant_id = 42
ORDER BY embedding <=> $1::halfvec
LIMIT 10;
Operatori di distanza pgvector:
<->Euclidea (L₂) ·<=>Distanza coseno (1 - cos) ·<#>Prodotto interno negativo ·<+>Manhattan (L₁).
5.2 Qdrant: quantizzazione binaria e filtro Payload (Python)
from qdrant_client import QdrantClient, models
client = QdrantClient(url="http://localhost:6333")
client.create_collection(
collection_name="knowledge_base",
vectors_config=models.VectorParams(
size=1536,
distance=models.Distance.COSINE,
on_disk=True,
),
quantization_config=models.BinaryQuantization(
binary=models.BinaryQuantizationConfig(always_ram=True)
),
)
client.create_payload_index(
collection_name="knowledge_base",
field_name="tenant_id",
field_schema=models.PayloadSchemaType.KEYWORD,
)
hits = client.query_points(
collection_name="knowledge_base",
query=[0.012, -0.045, ...],
query_filter=models.Filter(
must=[models.FieldCondition(key="tenant_id", match=models.MatchValue(value="org_a"))]
),
search_params=models.SearchParams(
quantization=models.QuantizationSearchParams(rescore=True, oversampling=3.0)
),
limit=10,
).points