En vektordatabas lagrar högdimensionella täta och glesa embeddings tillsammans med metadata och ger likhetssökning via Approximate Nearest Neighbor (ANN)-index på millisekundnivå som minnes- och retrievallager för RAG, semantisk sökning och AI-agenter.
| Arbetslast / Begränsning | Rekommenderad kategori | Representativa lösningar | Varför den passar |
|---|---|---|---|
| Befintlig PostgreSQL-stack, under ~10M vektorer | Relationsdatabas-tillägg | pgvector (+ halfvec / HNSW) | Återanvänder ACID-transaktioner, SQL JOINs och befintlig drift utan ny infrastruktur |
| Fulltext BM25 + vektorbaserad hybridrankning | Sökmotortillägg | Elasticsearch / OpenSearch / Vespa | Moget ekosystem för inverterade index och flerstegs hybridrankning |
| Fristående high-QPS-tjänst med tung filtrering | Dedikerad distribuerad vektor-DB | Qdrant / Milvus / Weaviate | Specialbyggd lagringsmotor, snabb payload-filtrering och horisontell skalning |
| Lokal utveckling, edge/desktop-appar eller data lake | Inbäddad / kolumnbaserad DB | LanceDB / Chroma / FAISS | Körning in-process med zero-copy-integration mot Apache Arrow / Parquet |
| Massiva cold/warm-datamängder till minimal lagringskostnad | Object-storage-native SaaS | Turbopuffer | Object storage (S3/GCS) som sanningskälla + lokal NVMe/RAM-cache |
| Driftfri serverless djupt integrerad i publikt moln | Fullt hanterad molntjänst | Pinecone / Vertex AI Vector Search / Azure AI Search | Elastisk serverless-skalning med inbyggd moln-IAM och övervakning |
🔗 Relaterade lathundar: LLM- & AI-agentkoncept · Moderna AI-algoritmer · PostgreSQL-kommandon · Redis-kommandon · MongoDB-kommandon
1. Grundkoncept & avståndsmetrik
1.1 Central terminologi
| Term | Definition | Tekniska överväganden |
|---|---|---|
| Embedding | Flyttalsarray med fast längd som kodar semantik för text, bild eller ljud | Vanliga dimensioner: 384 / 768 / 1024 / 1536 / 3072; RAM och beräkning skalar linjärt |
| ANN (Approximate Nearest Neighbor) | Indexbaserad sökning som byter minimal recall (95%–99%) mot 100×–1000× snabbhet | Central avvägning mellan latens och recall jämfört med exakt k-NN-skanning |
| Metadata Filtering | Begränsar vektorsökningen via skalära attribut (tenant, datum, ACL, kategori) | Skilj på Pre-filtering, Single-stage / Inline och Post-filtering |
| Hybrid Search | Kombinerar täta vektorer (semantik) med glesa vektorer / BM25 (exakta termer) | Löser missar från ren semantisk sökning på artikelnummer, felkoder och akronymer |
| Sparse Vector | Högdimensionell vektor där nästan alla värden är 0 (t.ex. SPLADE, BM25-vikter) | Lagrar endast nollskilda index och vikter; kompletterar tät sökning naturligt |
1.2 Tre centrala avstånds- och likhetsmått
Cosine(u, v) = (u · v) / (‖u‖₂ · ‖v‖₂)
IP(u, v) = u · v = ∑ᵢ (uᵢ × vᵢ)
L₂(u, v) = √( ∑ᵢ (uᵢ − vᵢ)² )
| Mått | Betydelse | Matematisk ekvivalens | Typiska användningsområden |
|---|---|---|---|
| Cosinuslikhet (Cosine) | Mäter endast vinkel och ignorerar längd (−1 till 1; avstånd = 1 - cos) |
Identisk rankning med skalärprodukt för L₂-normaliserade vektorer | Semantisk textsökning, RAG, meningsembeddings (standardval) |
| Skalärprodukt (IP / Dot) | Speglar både vinkel och längd; lägst beräkningskostnad | På enhetsvektorer ersätter IP Cosine utan rötter eller divisioner | Two-tower-rekommendationer, normaliserade embeddings (t.ex. OpenAI) |
| Euklidiskt avstånd (L₂) | Rakt geometriskt avstånd; mindre = närmare | För enhetsvektorer: L₂² = 2 − 2 · cos(u, v) |
Bild-/ansiktsembeddings, rumslig klustring, längdkänsliga särdrag |
2. ANN-indexalgoritmer & kvantisering
2.1 Jämförelse av vektorindex
| Indextyp | Mekanism | RAM-åtgång | Latens & Recall | Skala & typiska motorer |
|---|---|---|---|---|
| Flat (Exakt skanning) | Fullständig avståndsberäkning mot alla vektorer | Måttlig (endast råa/kvantiserade vektorer) | 100% recall; latensen skenar över ~100k rader | Små datamängder (<100k) och facit-benchmarks |
| IVF-Flat (Inverterad fil) | K-Means-klustring i nlist hinkar; skannar nprobe närmaste |
Låg (ingen graf-overhead) | Justerbar via nprobe; medel till hög recall |
1M–10M rader vid stram RAM-budget (FAISS / Milvus / pgvector) |
| IVF-PQ (IVF + Product Quantization) | Hinkuppdelning plus delrymdskompression med kodböcker | Mycket låg (16×–64× mindre) | Blixtsnabb; lägre initial recall (kräver rescoring) | 100M+ i minnet (FAISS / Milvus / LanceDB) |
| HNSW (Hierarkisk graf) | Flerskikts skip-list-närhetsgraf (grov topp, fin bas) | Hög (vektorer + grafkanter i RAM eller varm mmap) | Millisekunder + 95%–99% recall; branschstandard | 1M–100M+ realtid med låg latens (Qdrant / Milvus / Weaviate / pgvector) |
| DiskANN (Vamana-graf) | SSD-optimerad graf: komprimerade vektorer i RAM, full graf på NVMe | Låg (5×–10× mindre RAM) | 100M+ per nod på ms; kräver snabba NVMe-IOPS | Minnesbegränsade 100M–1B+ dataset (Milvus / LanceDB / Azure) |
| ScaNN | Anisotrop vektorkvantisering + trädpartitionering | Låg–Måttlig | Bäst recall-per-latens under skalärprodukt | Storskalig sökning & rekommendation (Vertex AI Vector Search / OSS) |
Viktigaste HNSW-parametrarna:
M(max dubbelriktade länkar per nod, typiskt16–64): högreMger bättre recall vid höga dimensioner men kostar RAM och byggtid.efConstruction(kandidatlistans längd vid bygge, typiskt100–400): påverkar bara byggtiden och höjer grafens kvalitet.efSearch(sökbredd vid fråga, ≥top_k): enda parametern som kan justeras per fråga; högre värde ökar recall och sänker QPS.
2.2 Kvantisering & minnesuppskattning
Referensbas för 10 miljoner vektorer × 1536 dimensioner (rå FP32):
Rå vektorstorlek ≈ N × D × 4 Byte (HNSW-grafen lägger till ~1,2×–1,5× RAM-overhead)
| Kvantisering | Bredd / dim | Kompression | Storlek 10M × 1536-dim | Precisionsavvägning & användning |
|---|---|---|---|---|
| FP32 (Okomprimerad) | 32-bit (4 B) | 1× | ~57,2 GB | Referensprecision; dyrt att hålla helt i RAM |
| FP16 / BF16 (Halvprecision) | 16-bit (2 B) | 2× | ~28,6 GB | Nästan förlustfri recall (t.ex. pgvector halfvec), hög avkastning |
| SQ8 (Skalär kvantisering Int8) | 8-bit (1 B) | 4× | ~14,3 GB | Behåller oftast 97%+ recall; standard i produktion |
| PQ (Product Quantization) | Delrymder | 16×–64× | ~1–4 GB | Kräver kodboksträning; kombineras med oversampling + rescore |
| BQ (Binär kvantisering 1-bit) | 1-bit | 32× | ~1,79 GB | Ultrasnabb Hamming-skanning; 3×–5× rescore rekommenderas (≥1024 dim) |
3. Skiktad jämförelse av databaser och sökmotorer
3.1 Dedikerade inbyggda vektordatabaser
| Produkt | Licens / Drift | Språk & Lagring | Index & Funktioner | Bäst för |
|---|---|---|---|---|
| Qdrant | Apache 2.0 / Self-hosted & Cloud | Rust; i minnet, mmap-disk & diskkvantisering | HNSW + SQ8/BQ; inbyggda glesa vektorer och snabba payload-filterindex | Fristående high-QPS-tjänst, multi-tenancy, komplexa filter |
| Milvus | Apache 2.0 / Distribuerad & Zilliz Cloud | Go kontrollplan + C++ exekvering; frikopplat object storage + MQ | IVF, HNSW, DiskANN, GPU CAGRA; multi-tenant-partitioner | Företagsplattformar på miljardskala |
| Weaviate | BSD-3-Clause (vissa enterprise-tillägg stängda) | Go; inbyggt object storage + inverterat index | HNSW + dynamisk/PQ/BQ-kvantisering; GraphQL/REST, vectorizer-moduler | RAG-appar med integrerad embedding-pipeline |
| Chroma | Apache 2.0 / Inbäddad & Client-Server | Python / Rust-kärna; SQLite + lokal eller distribuerad lagring | HNSW; minimalt API, tät LangChain / LlamaIndex-integration | Snabb prototypning och mindre/medelstor Python-RAG |
| LanceDB | Apache 2.0 / Inbäddad & Enterprise | Rust; kolumnformatet Lance & Apache Arrow | IVF-PQ, HNSW, DiskANN; zero-copy I/O, inbyggt multimodalt (ljud/video/tabeller) | Lokala inbäddade appar, serverless S3-läsning, data lakes |
| Pinecone | Proprietär Serverless SaaS | Hanterad distribuerad motor (från Pods till Serverless) | Frikopplat proprietärt index; sparse-dense hybrid, Namespace-isolering | Molnteam utan driftkrav som prioriterar hanterad enkelhet |
| Turbopuffer | Proprietär SaaS / BYOC | Rust; object storage (S3/GCS) som källa + NVMe/RAM-cache | Centroid-index (SPFresh-stil) utan slumpmässiga grafhopp på disk; text + vektor | Enorma cold/warm-mängder (t.ex. kodindexering) till lägsta kostnad |
3.2 Vektor-sökbibliotek (ej kompletta databaser)
| Produkt | Licens | Omfattning & Gränser | Användningsområden |
|---|---|---|---|
| FAISS (Meta) | MIT | C++ / Python likhetsbibliotek (ingen metadatapersistens, distribuerade transaktioner eller auth-server); CPU SIMD & multi-GPU | Offline batch-beräkningar, ML-forskning, inbäddad kärna i egna motorer |
3.3 Tillägg till traditionella databaser & sökmotorer
| Produkt | Grund | Vektorfunktioner | Styrkor & Begränsningar |
|---|---|---|---|
| pgvector | PostgreSQL-tillägg (inkl. Supabase) | Typerna vector / halfvec / sparsevec / bit; HNSW & IVFFlat |
Fördelar: ACID, SQL JOINs, noll ny drift; Nackdelar: write amplification & RAM-tryck >10M–50M rader |
| Elasticsearch / OpenSearch | Inverterat Lucene-index + HNSW | Inbyggd Dense Vector + BM25 hybrid, RRF-fusion, nästlade filter | Fördelar: återanvänder befintliga sökteam; Nackdelar: tung JVM off-heap RAM och segment-merges |
| Redis (Query Engine) | KV-lager i minnet | Flat & HNSW, submillisekund-latens, realtidsströmning | Fördelar: perfekt för semantisk cache & feature stores; Nackdelar: hög RAM-kostnad i skala |
| MongoDB Atlas Search | Dokument-DB (Atlas / Local CLI) | Lucene-baserad HNSW bredvid BSON-dokument | Fördelar: eliminerar dubbelskrivning doc/vektor; Nackdelar: kärnfunktioner bundna till Atlas |
| SingleStore | Distribuerad HTAP SQL-DB | SQL + inbyggda vektorfunktioner (dot / L₂), columnstore + rowstore | Företagslaster som blandar realtidsanalys i SQL och transaktioner |
| Vespa | Apache 2.0 big-data-motor | HNSW + exakt/approximativ hybrid, flerstegs ML-rankning (Tensor/XGBoost/ONNX) | Massiva sök- och rekommendationsplattformar; brantare driftkurva |
3.4 Fullt hanterade molntjänster
| Tjänst | Molnleverantör | Arkitektur & Höjdpunkter |
|---|---|---|
| Vertex AI Vector Search (tidigare Matching Engine) | Google Cloud (GCP) | Drivs av ScaNN; strömmande uppdateringar i miljardskala och sparse-dense hybrid |
| Amazon OpenSearch Serverless / Aurora pgvector | AWS | Hanterade serverless-kluster och RDS/Aurora-tillägg med inbyggd Amazon Bedrock-koppling |
| Azure AI Search | Microsoft Azure | Inbyggd Semantic Ranker, vektoriseringspipelines och RBAC-dokumentbehörigheter |
4. Filtreringsstrategier & hybridsökning
4.1 Exekveringslägen för metadatafiltrering
| Strategi | Exekveringsordning | Risk & Åtgärd |
|---|---|---|
| Pre-filtering | Utvärderar skalärt index för att skapa ID-bitmap och kör sedan vektorsökningen | Vid snäva filter (<1% träff) bryts grafen upp; Åtgärd: automatisk fallback till exakt skanning |
| Post-filtering | Hämtar globalt Top-K och tar bort träffar som inte klarar filtret | Riskerar att ge färre än K resultat (eller noll); Åtgärd: använd aldrig ensam utan stor oversampling |
| Single-stage / Inline | Kontrollerar filter-bitmapen dynamiskt vid varje hopp i HNSW-grafen | Dagens standard (Qdrant / Milvus / Weaviate / pgvector 0.8+ iterative scan) för bästa recall och latens |
4.2 Reciprocal Rank Fusion (RRF)
Eftersom poäng från tät sökning och BM25 har olika skalor slår RRF ihop rankningarna direkt utan kalibrering:
RRF_Score(d) = ∑_{r ∈ R} 1 / (k + rank_r(d)) (standardkonstant för utjämning k = 60)
5. Produktionsklara kodexempel
5.1 pgvector-schema, HNSW-index & iterativ skanning (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 sparar 50% minne jämfört med 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;
pgvector-avståndsoperatorer:
<->Euklidiskt (L₂) ·<=>Cosinusavstånd (1 - cos) ·<#>Negativ skalärprodukt ·<+>Manhattan (L₁).
5.2 Qdrant: binär kvantisering & Payload-filtrering (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