Snabbreferens

Vektordatabaser & retrieval-arkitektur: lathund (koncept, index, kvantisering & val)

Kompakt referensguide för vektordatabaser och semantisk sökning: avståndsmetrik, ANN-index (HNSW, IVF, DiskANN, ScaNN), minnesberäkning med kvantisering, inline-filtrering, RRF-hybridsökning och skiktad jämförelse av inbyggda motorer, tillägg och molntjänster.

· Publicerad

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, typiskt 16–64): högre M ger bättre recall vid höga dimensioner men kostar RAM och byggtid.
  • efConstruction (kandidatlistans längd vid bygge, typiskt 100–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

Relaterade ämnen