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, uzual16–64): unMmai 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, uzual100–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