Wektorowa baza danych przechowuje wysokowymiarowe embeddingi gęste i rzadkie wraz z metadanymi, oferując w milisekundach przybliżone wyszukiwanie najbliższych sąsiadów (ANN) jako warstwę pamięci i retrieval dla RAG, wyszukiwania semantycznego oraz agentów AI.
| Obciążenie / Ograniczenie | Zalecana kategoria | Reprezentatywne rozwiązania | Dlaczego pasuje |
|---|---|---|---|
| Istniejący stos PostgreSQL, poniżej ~10M wektorów | Rozszerzenie relacyjnej BD | pgvector (+ halfvec / HNSW) | Wykorzystuje transakcje ACID, SQL JOIN i obecne ops bez nowej infrastruktury |
| Wyszukiwanie hybrydowe pełnotekstowe BM25 + wektory | Rozszerzenie wyszukiwarki | Elasticsearch / OpenSearch / Vespa | Dojrzały ekosystem indeksów odwróconych i wieloetapowego rankingu hybrydowego |
| Samodzielna usługa high-QPS ze złożonym filtrowaniem | Dedykowana rozproszona baza wektorowa | Qdrant / Milvus / Weaviate | Specjalizowany silnik zapisu, szybkie filtrowanie payloadów i skalowanie poziome |
| Rozwój lokalny, aplikacje edge/desktop lub odczyt data lake | Baza wbudowana / kolumnowa | LanceDB / Chroma / FAISS | Działanie in-process z integracją zero-copy Apache Arrow / Parquet |
| Ogromne zbiory cold/warm przy minimalnych kosztach dysku | SaaS natywny dla object storage | Turbopuffer | Object storage (S3/GCS) jako źródło prawdy + lokalny cache NVMe/RAM |
| Bezobsługowy serverless w ekosystemie chmurowym | W pełni zarządzana usługa chmurowa | Pinecone / Vertex AI Vector Search / Azure AI Search | Elastyczne skalowanie serverless i natywna integracja z IAM oraz monitoringiem |
🔗 Powiązane ściągawki: Koncepcje LLM i agentów AI · Nowoczesne algorytmy AI · Polecenia PostgreSQL · Polecenia Redis · Polecenia MongoDB
1. Podstawowe pojęcia i metryki odległości
1.1 Kluczowa terminologia
| Pojęcie | Definicja | Aspekty inżynieryjne |
|---|---|---|
| Embedding | Tablica floatów o stałej długości kodująca znaczenie tekstu, obrazu lub dźwięku | Typowe wymiary: 384 / 768 / 1024 / 1536 / 3072; RAM i obliczenia rosną liniowo |
| ANN (Approximate Nearest Neighbor) | Wyszukiwanie indeksowe wymieniające minimalny recall (95%–99%) na przyspieszenie 100×–1000× | Główny kompromis opóźnienie vs recall w kontraście do dokładnego skanu k-NN |
| Metadata Filtering | Ograniczanie wyszukiwania wektorowego atrybutami skalarnymi (tenant, czas, ACL, kategoria) | Rozróżniaj Pre-filtering, Single-stage / Inline i Post-filtering |
| Hybrid Search | Łączenie wektorów gęstych (semantyka) i wektorów rzadkich / BM25 (dokładne słowa) | Usuwa braki czystej semantyki przy kodach SKU, błędach i akronimach |
| Sparse Vector | Wektor wysokowymiarowy złożony głównie z zer (np. SPLADE, wagi BM25) | Przechowuje tylko niezerowe indeksy i wagi; naturalnie uzupełnia wektory gęste |
1.2 Trzy główne metryki odległości i podobieństwa
Cosine(u, v) = (u · v) / (‖u‖₂ · ‖v‖₂)
IP(u, v) = u · v = ∑ᵢ (uᵢ × vᵢ)
L₂(u, v) = √( ∑ᵢ (uᵢ − vᵢ)² )
| Metryka | Znaczenie | Równoważność matematyczna | Typowe zastosowania |
|---|---|---|---|
| Podobieństwo cosinusowe (Cosine) | Mierzy wyłącznie kąt bez długości (−1 do 1; dystans = 1 - cos) |
Identyczny ranking z iloczynem skalarnym dla wektorów znormalizowanych L₂ | Wyszukiwanie semantyczne tekstu, RAG, embeddingi zdań (domyślnie) |
| Iloczyn skalarny (IP / Dot) | Uwzględnia kąt i długość; najniższy koszt obliczeń | Na wektorach jednostkowych zastępuje Cosine bez pierwiastków i dzieleń | Systemy rekomendacji two-tower, znormalizowane embeddingi (np. OpenAI) |
| Odległość euklidesowa (L₂) | Odległość geometryczna w linii prostej; mniejsza = bliżej | Dla wektorów jednostkowych: L₂² = 2 − 2 · cos(u, v) |
Embeddingi obrazów/twarzy, klasteryzacja przestrzenna, cechy wrażliwe na normę |
2. Algorytmy indeksowania ANN i kwantyzacja
2.1 Porównanie indeksów wektorowych
| Typ indeksu | Mechanizm | Zużycie RAM | Opóźnienie i Recall | Skala i typowe silniki |
|---|---|---|---|---|
| Flat (Skan dokładny) | Wyczerpujące obliczenie odległości wobec wszystkich wektorów | Umiarkowane (tylko wektory surowe/skwantyzowane) | 100% recall; opóźnienie rośnie gwałtownie >~100k | Małe zbiory (<100k) i benchmarki referencyjne |
| IVF-Flat (Plik odwrócony) | Grupowanie K-Means na nlist kubełków; skanuje nprobe najbliższych |
Niskie (bez narzutu grafu) | Regulowane przez nprobe; recall średni–wysoki |
1M–10M przy ograniczonym RAM (FAISS / Milvus / pgvector) |
| IVF-PQ (IVF + Product Quantization) | Podział na kubełki plus kompresja podprzestrzeni przez codebooki | Bardzo niskie (16×–64× mniejsze) | Ultraszybkie; niższy recall pierwszego przejścia (wymaga rescoring) | 100M+ w pamięci (FAISS / Milvus / LanceDB) |
| HNSW (Graf hierarchiczny) | Wielowarstwowy graf sąsiedztwa typu skip-list (góra zgrubna, dół dokładny) | Wysokie (wektory + krawędzie w RAM lub gorącym mmap) | Milisekundy + 95%–99% recall; standard branżowy | 1M–100M+ w czasie rzeczywistym (Qdrant / Milvus / Weaviate / pgvector) |
| DiskANN (Graf Vamana) | Graf dla SSD: skompresowane wektory w RAM, pełny graf na NVMe | Niskie (5×–10× mniej RAM) | 100M+ na węzeł w ms; wymaga szybkich IOPS NVMe | 100M–1B+ przy ograniczonej pamięci (Milvus / LanceDB / Azure) |
| ScaNN | Anizotropowa kwantyzacja wektorów + partycjonowanie drzewiaste | Niskie–Umiarkowane | Najlepsza krzywa recall/latencja przy iloczynie skalarnym | Wielkoskalowe wyszukiwanie i rekomendacje (Vertex AI Vector Search / OSS) |
Kluczowe parametry strojenia HNSW:
M(maks. dwukierunkowych krawędzi na węzeł, zwykle16–64): większeMpoprawia recall w wysokich wymiarach kosztem RAM i czasu budowy.efConstruction(rozmiar listy kandydatów przy budowie, zwykle100–400): wpływa wyłącznie na czas budowy i podnosi jakość grafu.efSearch(szerokość przeszukiwania przy zapytaniu, ≥top_k): jedyny parametr regulowany per zapytanie; wyższy zwiększa recall i obniża QPS.
2.2 Kwantyzacja i szacowanie pamięci
Baza odniesienia dla 10 milionów wektorów × 1536 wymiarów (surowe FP32):
Surowy rozmiar ≈ N × D × 4 Bajty (graf HNSW dodaje ok. 1,2×–1,5× narzutu RAM)
| Kwantyzacja | Szerokość / wym. | Kompresja | Rozmiar 10M × 1536-dim | Kompromis dokładności i użycie |
|---|---|---|---|---|
| FP32 (Bez kompresji) | 32 bit (4 B) | 1× | ~57,2 GB | Precyzja bazowa; kosztowna w stałym RAM |
| FP16 / BF16 (Półprecyzja) | 16 bit (2 B) | 2× | ~28,6 GB | Praktycznie bezstratny recall (np. pgvector halfvec), świetny ROI |
| SQ8 (Kwantyzacja skalarna Int8) | 8 bit (1 B) | 4× | ~14,3 GB | Zwykle zachowuje 97%+ recall; standard produkcyjny |
| PQ (Product Quantization) | Podprzestrzenie | 16×–64× | ~1–4 GB | Wymaga treningu codebooka; łączyć z oversamplingiem + rescore |
| BQ (Kwantyzacja binarna 1-bit) | 1 bit | 32× | ~1,79 GB | Ekspresowy skan Hamminga; zalecany rescore 3×–5× (≥1024 dim) |
3. Warstwowe porównanie baz i silników
3.1 Dedykowane natywne bazy wektorowe
| Produkt | Licencja / Wdrożenie | Język i Silnik zapisu | Indeksy i możliwości | Zastosowanie |
|---|---|---|---|---|
| Qdrant | Apache 2.0 / Self-hosted & Cloud | Rust; pamięć, mmap na dysku i kwantyzacja dyskowa | HNSW + SQ8/BQ; natywne wektory rzadkie i szybkie indeksy payloadów | Samodzielna usługa high-QPS, multi-tenancy, złożone filtry |
| Milvus | Apache 2.0 / Rozproszona & Zilliz Cloud | Control plane Go + wykonanie C++; rozdzielone object storage + MQ | IVF, HNSW, DiskANN, GPU CAGRA; partycje multi-tenant | Platformy korporacyjne skali miliardowej |
| Weaviate | BSD-3-Clause (część dodatków enterprise zamknięta) | Go; wbudowany object storage + indeks odwrócony | HNSW + kwantyzacja dynamiczna/PQ/BQ; GraphQL/REST, moduły wektoryzacji | Aplikacje RAG ze zintegrowanym pipeline embeddingów |
| Chroma | Apache 2.0 / Wbudowana & Client-Server | Rdzeń Python / Rust; SQLite + zapis lokalny lub rozproszony | HNSW; proste API, ścisła integracja LangChain / LlamaIndex | Szybkie prototypowanie i małe/średnie RAG w Pythonie |
| LanceDB | Apache 2.0 / Wbudowana & Enterprise | Rust; format kolumnowy Lance i Apache Arrow | IVF-PQ, HNSW, DiskANN; zero-copy I/O, natywny multimodal (audio/wideo/tabele) | Lokalne aplikacje embedded, odczyt S3 serverless, data lake |
| Pinecone | Własnościowy Serverless SaaS | Zarządzany silnik rozproszony (od Pods do Serverless) | Rozdzielony indeks własnościowy; hybryda sparse-dense, izolacja Namespace | Zespoły chmurowe zero-ops stawiające na usługę zarządzaną |
| Turbopuffer | Własnościowy SaaS / BYOC | Rust; object storage (S3/GCS) jako źródło prawdy + cache NVMe/RAM | Indeks centroidowy (styl SPFresh) unikający losowych skoków I/O; tekst + wektor | Ogromne dane cold/warm (np. indeksowanie kodu) przy minimalnych kosztach |
3.2 Biblioteki wyszukiwania wektorowego (nie pełne BD)
| Produkt | Licencja | Zakres i ograniczenia | Zastosowania |
|---|---|---|---|
| FAISS (Meta) | MIT | Biblioteka podobieństwa C++ / Python (brak trwałości metadanych, transakcji rozproszonych i serwera auth); CPU SIMD & multi-GPU | Obliczenia wsadowe offline, badania ML, rdzeń wbudowany we własne silniki |
3.3 Rozszerzenia tradycyjnych baz i wyszukiwarek
| Produkt | Podstawa | Możliwości wektorowe | Zalety i ograniczenia |
|---|---|---|---|
| pgvector | Rozszerzenie PostgreSQL (w tym Supabase) | Typy vector / halfvec / sparsevec / bit; HNSW i IVFFlat |
Zalety: ACID, SQL JOIN, zero nowego ops; Wady: amplifikacja zapisu i RAM >10M–50M wierszy |
| Elasticsearch / OpenSearch | Indeks odwrócony Lucene + HNSW | Natywna hybryda Dense Vector + BM25, fuzja RRF, filtry zagnieżdżone | Zalety: wykorzystuje obecne zespoły search; Wady: duże zużycie RAM off-heap JVM i scalanie segmentów |
| Redis (Query Engine) | Magazyn KV w pamięci | Flat i HNSW, opóźnienia poniżej milisekundy, aktualizacje real-time | Zalety: idealny do semantic cache i feature store; Wady: wysokie koszty RAM w dużej skali |
| MongoDB Atlas Search | Baza dokumentowa (Atlas / Local CLI) | HNSW oparty na Lucene obok dokumentów BSON | Zalety: brak podwójnego zapisu doc/wektor; Wady: kluczowe funkcje powiązane z Atlas |
| SingleStore | Rozproszona baza SQL HTAP | SQL + natywne operacje wektorowe (dot / L₂), zapis kolumnowy + wierszowy | Obciążenia łączące analitykę SQL w czasie rzeczywistym i transakcje |
| Vespa | Silnik big-data Apache 2.0 | HNSW + hybryda dokładna/przybliżona, wieloetapowy ranking ML (Tensor/XGBoost/ONNX) | Wielkie platformy search i rekomendacji; wyższy próg wejścia |
3.4 W pełni zarządzane usługi chmurowe
| Usługa | Dostawca | Architektura i wyróżniki |
|---|---|---|
| Vertex AI Vector Search (dawniej Matching Engine) | Google Cloud (GCP) | Oparta na ScaNN; aktualizacje strumieniowe w skali miliardów i hybryda sparse-dense |
| Amazon OpenSearch Serverless / Aurora pgvector | AWS | Zarządzane klastry serverless i rozszerzenia RDS/Aurora z integracją Amazon Bedrock |
| Azure AI Search | Microsoft Azure | Wbudowany Semantic Ranker, potoki wektoryzacji i kontrola uprawnień RBAC |
4. Strategie filtrowania i wyszukiwanie hybrydowe
4.1 Tryby wykonywania filtrów metadanych
| Strategia | Kolejność wykonania | Ryzyko i przeciwdziałanie |
|---|---|---|
| Pre-filtering | Najpierw wyznacza bitmapę ID z indeksu skalarnego, potem przeszukuje wektory | Przy bardzo wąskich filtrach (<1%) graf ulega rozłączeniu; Rozwiązanie: automatyczny fallback do skanu dokładnego |
| Post-filtering | Pobiera globalne Top-K wektorów, a następnie odrzuca niespełniające warunku | Grozi zwróceniem mniej niż K wyników (lub zera); Rozwiązanie: nie używać solo bez dużego oversamplingu |
| Single-stage / Inline | Dynamicznie sprawdza bitmapę filtra w każdym kroku przejścia po grafie HNSW | Współczesny standard (Qdrant / Milvus / Weaviate / pgvector 0.8+ iterative scan) łączący recall i szybkość |
4.2 Reciprocal Rank Fusion (RRF)
Ponieważ wyniki wyszukiwania gęstego i BM25 mają różne skale, RRF łączy listy bezpośrednio po pozycjach bez kalibracji ocen:
RRF_Score(d) = ∑_{r ∈ R} 1 / (k + rank_r(d)) (standardowa stała wygładzająca k = 60)
5. Fragmenty gotowe na produkcję
5.1 Schemat pgvector, indeks HNSW i skan iteracyjny (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 oszczędza 50% pamięci względem 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;
Operatory odległości pgvector:
<->Euklidesowa (L₂) ·<=>Odległość cosinusowa (1 - cos) ·<#>Ujemny iloczyn skalarny ·<+>Manhattan (L₁).
5.2 Qdrant: kwantyzacja binarna i filtrowanie 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