Riferimento rapido

Database vettoriali e architettura di retrieval: guida rapida (concetti, indici, quantizzazione e scelta)

Riferimento ad alta densità per database vettoriali e ricerca semantica: formule di distanza, algoritmi di indicizzazione ANN (HNSW, IVF, DiskANN, ScaNN), stima RAM con quantizzazione, filtraggio inline, fusione RRF e confronto stratificato di motori nativi, estensioni e servizi cloud.

· Pubblicato

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, tipicamente 16–64): valori più alti migliorano il recall in alta dimensione ma aumentano RAM e tempo di build.
  • efConstruction (dimensione lista candidati durante la costruzione, tipicamente 100–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

Argomenti correlati