Referință rapidă

Baze de date vectoriale și arhitectură de regăsire: fișă de referință (concepte, indecși, cuantizare și selecție)

Ghid de referință dens pentru baze de date vectoriale și căutare semantică: formule de distanță, algoritmi de indexare ANN (HNSW, IVF, DiskANN, ScaNN), estimarea memoriei cu cuantizare, filtrare inline, fuziune RRF și comparație pe niveluri între soluții native, extensii și servicii cloud.

· Publicat

O bază de date vectorială stochează embedding-uri dense și rare (sparse) de înaltă dimensionalitate împreună cu metadate, oferind căutare de similaritate prin cei mai apropiați vecini aproximativi (ANN) în milisecunde ca strat de memorie și regăsire pentru RAG, căutare semantică și agenți AI.

Sarcină / Constrângere Categorie recomandată Soluții reprezentative De ce se potrivește
Stivă PostgreSQL existentă, sub ~10M vectori Extensie BD relațională pgvector (+ halfvec / HNSW) Reutilizează tranzacții ACID, JOIN-uri SQL și operarea curentă fără infrastructură nouă
Căutare hibridă full-text BM25 + vectori Extensie motor de căutare Elasticsearch / OpenSearch / Vespa Ecosistem matur de indecși inversați și clasare hibridă în mai multe etape
Serviciu dedicat cu QPS ridicat și filtre complexe BD vectorială distribuită dedicată Qdrant / Milvus / Weaviate Motor de stocare specializat, filtrare rapidă pe payload și scalare orizontală
Dezvoltare locală, aplicații edge/desktop sau data lake BD încorporată / columnară LanceDB / Chroma / FAISS Execuție in-process cu integrare zero-copy Apache Arrow / Parquet
Volume uriașe cold/warm la cost minim de stocare SaaS nativ pe object storage Turbopuffer Object storage (S3/GCS) ca sursă de adevăr + cache local NVMe/RAM
Serverless fără mentenanță integrat în cloud public Serviciu cloud complet gestionat Pinecone / Vertex AI Vector Search / Azure AI Search Scalare serverless elastică și integrare nativă cu IAM și monitorizare

🔗 Fișe conexe: Concepte LLM & Agenți AI · Algoritmi AI moderni · Comenzi PostgreSQL · Comenzi Redis · Comenzi MongoDB


1. Concepte de bază și metrici de distanță

1.1 Terminologie esențială

Termen Definiție Aspecte de inginerie
Embedding Tablou de numere reale cu lungime fixă care codifică semantica textului, imaginilor sau sunetului Dimensiuni uzuale: 384 / 768 / 1024 / 1536 / 3072; RAM-ul și calculul cresc liniar
ANN (Approximate Nearest Neighbor) Căutare indexată care cedează un recall infim (95%–99%) pentru accelerare 100×–1000× Compromisul central latență vs recall, opus scanării exacte k-NN
Metadata Filtering Limitarea căutării vectoriale prin atribute scalare (tenant, dată, ACL, categorie) Distingeți între Pre-filtering, Single-stage / Inline și Post-filtering
Hybrid Search Combinarea vectorilor denși (semantică) cu vectori rari / BM25 (potrivire lexicală) Rezolvă scăpările căutării pur semantice pe coduri SKU, erori și acronime
Sparse Vector Vector de mare dimensiune cu majoritatea valorilor 0 (ex. SPLADE, ponderi BM25) Stochează doar indicii și ponderile nenule; completează natural căutarea densă

1.2 Trei metrici fundamentale de distanță și similaritate

Cosine(u, v) = (u · v) / (‖u‖₂ · ‖v‖₂)
IP(u, v)     = u · v = ∑ᵢ (uᵢ × vᵢ)
L₂(u, v)     = √( ∑ᵢ (uᵢ − vᵢ)² )
Metrică Semnificație Echivalență matematică Cazuri tipice de utilizare
Similaritatea cosinusului (Cosine) Măsoară doar unghiul ignorând magnitudinea (−1 la 1; distanță = 1 - cos) Clasament identic cu produsul scalar pentru vectori normalizați L₂ Căutare semantică text, RAG, embedding-uri de propoziții (implicit)
Produs scalar (IP / Dot) Reflectă unghiul și magnitudinea; cel mai mic cost de calcul Pe vectori unitari înlocuiește Cosine fără radicali și împărțiri Sisteme de recomandare two-tower, embedding-uri normalizate (ex. OpenAI)
Distanța euclidiană (L₂) Distanță geometrică în linie dreaptă; mai mic = mai aproape Pentru vectori unitari: L₂² = 2 − 2 · cos(u, v) Embedding-uri imagini/fețe, clustering spațial, trăsături sensibile la normă

2. Algoritmi de indexare ANN și cuantizare

2.1 Comparația indecșilor vectoriali

Tip index Mecanism Consum RAM Latență și Recall Scară și motoare reprezentative
Flat (Scanare exactă) Calcul exhaustiv al distanței față de toți vectorii Moderat (doar vectorii bruți/cuantizați) 100% recall; latența crește brusc peste ~100k Seturi mici (<100k) și benchmark-uri de referință
IVF-Flat (Fișier inversat) Clustering K-Means în nlist găleți; scanează cele mai apropiate nprobe Scăzut (fără overhead de graf) Reglabil prin nprobe; recall mediu–ridicat 1M–10M rânduri cu buget RAM restrâns (FAISS / Milvus / pgvector)
IVF-PQ (IVF + Product Quantization) Partiționare în găleți plus compresie pe subspații cu codebook-uri Foarte scăzut (de 16×–64× mai mic) Ultrarapid; recall inițial mai mic (necesită rescoring) 100M+ în memorie (FAISS / Milvus / LanceDB)
HNSW (Graf ierarhic) Graf multistrat tip skip-list (straturi de sus grosiere, bază fină) Ridicat (vectori + muchii în RAM sau mmap fierbinte) Milisecunde + 95%–99% recall; standard industrial 1M–100M+ latență redusă în timp real (Qdrant / Milvus / Weaviate / pgvector)
DiskANN (Graf Vamana) Graf pentru SSD: vectori comprimați în RAM, graf complet pe NVMe Scăzut (RAM redus de 5×–10×) 100M+ per nod în ms; depinde de IOPS NVMe rapid 100M–1B+ cu memorie limitată (Milvus / LanceDB / Azure)
ScaNN Cuantizare vectorială anizotropă + partiționare arborescentă Scăzut–Moderat Cea mai bună curbă recall/latență la produs scalar Căutare și recomandări la scară mare (Vertex AI Vector Search / OSS)

Parametri principali de reglaj HNSW:

  • M (nr. max de legături bidirecționale per nod, uzual 16–64): un M mai mare crește recall-ul la dimensiuni mari, dar mărește RAM-ul și timpul de construire.
  • efConstruction (lungimea listei de candidați la indexare, uzual 100–400): afectează doar timpul de construcție și îmbunătățește calitatea grafului.
  • efSearch (lățimea căutării la interogare, ≥ top_k): singurul parametru reglabil per interogare; creșterea ridică recall-ul și scade QPS-ul.

2.2 Cuantizare și estimarea memoriei

Referință pentru 10 milioane de vectori × 1536 dimensiuni (FP32 necomprimat):

Dimensiune brută ≈ N × D × 4 Octeți   (graful HNSW adaugă ~1,2×–1,5× overhead RAM)
Cuantizare Lățime / dim Compresie Dimensiune 10M × 1536-dim Compromis precizie și utilizare
FP32 (Necomprimat) 32 biți (4 B) 1× ~57,2 GB Precizie de referință; costisitor de ținut rezident în RAM
FP16 / BF16 (Semiprecizie) 16 biți (2 B) 2× ~28,6 GB Recall practic fără pierderi (ex. pgvector halfvec), ROI excelent
SQ8 (Cuantizare scalară Int8) 8 biți (1 B) 4× ~14,3 GB Păstrează de regulă 97%+ recall; standard de producție
PQ (Product Quantization) Subspații 16×–64× ~1–4 GB Necesită antrenare codebook; de combinat cu oversampling + rescore
BQ (Cuantizare binară 1-bit) 1 bit 32× ~1,79 GB Scanare Hamming ultrarapidă; rescore 3×–5× recomandat (≥1024 dim)

3. Comparație pe niveluri a sistemelor

3.1 Baze de date vectoriale native dedicate

Produs Licență / Implementare Limbaj și Stocare Indecși și capabilități Scenariu ideal
Qdrant Apache 2.0 / Self-hosted & Cloud Rust; în memorie, mmap pe disc și cuantizare pe disc HNSW + SQ8/BQ; vectori rari nativi și indecși rapizi pe payload Serviciu independent high-QPS, multi-tenancy, filtre complexe
Milvus Apache 2.0 / Distribuit & Zilliz Cloud Control plane Go + execuție C++; object storage + MQ decuplate IVF, HNSW, DiskANN, GPU CAGRA; partiții multi-tenant Platforme enterprise la scara miliardelor
Weaviate BSD-3-Clause (unele funcții enterprise închise) Go; object storage + index inversat integrate HNSW + cuantizare dinamică/PQ/BQ; GraphQL/REST, module vectorizare Aplicații RAG cu pipeline integrat de embedding
Chroma Apache 2.0 / Încorporată & Client-Server Nucleu Python / Rust; SQLite + stocare locală sau distribuită HNSW; API minimal, integrare strânsă LangChain / LlamaIndex Prototipare rapidă și RAG Python mic/mediu
LanceDB Apache 2.0 / Încorporată & Enterprise Rust; format columnar Lance și Apache Arrow IVF-PQ, HNSW, DiskANN; I/O zero-copy, multimodal nativ (audio/video/tabele) Aplicații locale încorporate, citire serverless S3, data lakes
Pinecone SaaS Serverless proprietar Motor distribuit gestionat (evoluat de la Pods la Serverless) Index proprietar decuplat; hibrid sparse-dense, izolare Namespace Echipe cloud zero-ops axate pe simplitate gestionată
Turbopuffer SaaS proprietar / BYOC Rust; object storage (S3/GCS) ca sursă + cache NVMe/RAM Index pe centroizi (stil SPFresh) evitând salturile aleatoare I/O; text + vector Date masive cold/warm (ex. indexare cod) la cost minim

3.2 Biblioteci de căutare vectorială (nu BD complete)

Produs Licență Scop și limite Cazuri de utilizare
FAISS (Meta) MIT Bibliotecă de similaritate C++ / Python (fără persistență metadate, tranzacții distribuite sau server auth); CPU SIMD & multi-GPU Procesare batch offline, cercetare ML, nucleu integrat în motoare proprii

3.3 Extensii ale bazelor de date și motoarelor de căutare clasice

Produs Bază Capabilități vectoriale Puncte forte și limite
pgvector Extensie PostgreSQL (incl. Supabase) Tipuri vector / halfvec / sparsevec / bit; HNSW și IVFFlat Pro: ACID, JOIN SQL, zero operațiuni noi; Contra: amplificare la scriere și RAM >10M–50M rânduri
Elasticsearch / OpenSearch Index inversat Lucene + HNSW Hibrid nativ Dense Vector + BM25, fuziune RRF, filtre imbricate Pro: reutilizează echipele search existente; Contra: consum ridicat JVM off-heap RAM și merge-uri
Redis (Query Engine) Stocare KV în memorie Flat & HNSW, latență sub-milisecundă, streaming în timp real Pro: ideal pentru cache semantic și feature stores; Contra: cost mare de RAM la scară
MongoDB Atlas Search BD orientată pe documente (Atlas / Local CLI) HNSW bazat pe Lucene alături de documentele BSON Pro: elimină scrierea dublă doc/vector; Contra: funcțiile principale legate de Atlas
SingleStore BD SQL HTAP distribuită SQL + funcții vectoriale native (dot / L₂), columnstore + rowstore Sarcini enterprise ce îmbină analitica SQL în timp real și tranzacțiile
Vespa Motor big-data Apache 2.0 HNSW + hibrid exact/aproximativ, clasare ML multifazică (Tensor/XGBoost/ONNX) Platforme masive de căutare/recomandare; curbă operațională mai abruptă

3.4 Servicii cloud complet gestionate

Serviciu Furnizor Arhitectură și puncte cheie
Vertex AI Vector Search (fost Matching Engine) Google Cloud (GCP) Bazat pe ScaNN; actualizări streaming la scara miliardelor și hibrid sparse-dense
Amazon OpenSearch Serverless / Aurora pgvector AWS Clustere serverless gestionate și extensii RDS/Aurora cu integrare nativă Amazon Bedrock
Azure AI Search Microsoft Azure Semantic Ranker integrat, pipeline-uri de vectorizare și control RBAC enterprise pe documente

4. Strategii de filtrare și căutare hibridă

4.1 Moduri de execuție a filtrării pe metadate

Strategie Ordine de execuție Mod de eșec și soluție
Pre-filtering Evaluează indexul scalar pentru a genera un bitmap de ID-uri, apoi rulează căutarea vectorială La filtre foarte selective (<1%), graful se deconectează; Soluție: fallback automat la scanare exactă
Post-filtering Extrage Top-K global, apoi elimină elementele ce nu respectă filtrul Riscă să returneze mai puțin de K rezultate (sau zero); Soluție: nu folosiți izolat fără oversampling masiv
Single-stage / Inline Verifică dinamic bitmap-ul filtrului la fiecare pas în graful HNSW Standardul modern (Qdrant / Milvus / Weaviate / pgvector 0.8+ iterative scan), echilibrând recall și latență

4.2 Reciprocal Rank Fusion (RRF)

Deoarece scorurile de căutare densă și BM25 au scale diferite, RRF combină clasamentele direct după poziție, fără calibrare:

RRF_Score(d) = ∑_{r ∈ R} 1 / (k + rank_r(d))     (constantă standard de netezire k = 60)

5. Fragmente pregătite pentru producție

5.1 Schemă pgvector, index HNSW și scanare iterativă (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 economisește 50% RAM față de 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 de distanță pgvector: <-> Euclidiană (L₂) · <=> Distanță cosinus (1 - cos) · <#> Produs scalar negativ · <+> Manhattan (L₁).

5.2 Qdrant: cuantizare binară și filtrare 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

Subiecte conexe