Bazy wektorowe (Vector DBs & ANN Search)

1. Przegląd koncepcji i problem systemowy

Wraz z popularyzacją embeddingów inżynierowie stanęli przed nowym wyzwaniem: jak przechowywać i szybko przeszukiwać dane w przestrzeni wektorowej, gdzie wymiarowość każdego rekordu wynosi setki lub tysiące współrzędnych:

1. Nieprzydatność klasycznych indeksów B-Tree: Tradycyjne indeksy B-Tree skutecznie sortują jednowymiarowe liczby czy ciągi znaków, ale są matematycznie bezradne wobec geometrycznych wektorów o wymiarze 1536 (tzw. „Klątwa wymiarowości” / Curse of Dimensionality).
2. Ogromne zapotrzebowanie na pamięć: Przechowywanie tablic liczb zmiennoprzecinkowych float32 wymaga gigabajtów RAM-u oraz specjalistycznego przyspieszenia sprzętowego (instrukcje AVX-512, SIMD lub CUDA).
3. Potrzeba powiązania z metadanymi: Samo znalezienie wektora to za mało – system musi natychmiast zwrócić powiązany tekst, autora, datę, URL źródła oraz poziom dostępu użytkownika.

Bazy danych wektorowych (Vector Databases) przekształciły semantyczne wyszukiwanie wektorowe w niezawodny prymityw infrastrukturalny, zdolny do znajdowania najbardziej podobnych encji wśród miliardów rekordów w ciągu milisekund.

2. Taksonomia architektoniczna i model mentalny

W świecie magazynów wektorowych dominują dwa modele koncepcyjne organizacji danych oraz odpowiadające im struktury indeksów:

• 1. Indeks HNSW (Hierarchical Navigable Small World): Złoty standard wyszukiwania wektorowego. Buduje wielowarstwowy graf analogiczny do algorytmu Skip-List: górne warstwy zawierają długie krawędzie umożliwiające szybkie przeskoczenie do właściwego klastra przestrzeni, a dolna warstwa (Layer 0) zapewnia szczegółową nawigację między najbliższymi sąsiadami. Oferuje najlepszy balans między szybkością a kompletnością wyników (Recall > 98%).
• 2. Indeks IVF (Inverted File Index): Przestrzeń jest dzielona na komórki Voronoi poprzez klastering K-Means. Zapytanie najpierw identyfikuje kilka najbliższych centroidów, a następnie skanuje wyłącznie wektory znajdujące się wewnątrz tych klastrów. Wymaga mniej pamięci operacyjnej niż HNSW, ale charakteryzuje się niższą precyzją.
• 3. Formaty architektoniczne baz:
  • Dedykowane autonomiczne bazy wektorowe (Dedicated Vector DBs): Qdrant (Rust), Milvus (Go/C++), Chroma, Pinecone. Zoptymalizowane pod kątem skalowalności, shardingu i równoległych obliczeń GPU.
  • Relacyjne rozszerzenia wektorowe (Integrated Extensions): pgvector dla PostgreSQL, sqlite-vec / Turso dla SQLite. Zapewniają zachowanie transakcji ACID oraz znajomy składnik SQL.
• 4. Kwantyzacja i kompresja pamięci: Wykorzystanie Scalar Quantization (SQ) lub Product Quantization (PQ) w celu kompresji wektorów w pamięci do reprezentacji 8-bitowych lub 1-bitowych.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia zapisu i wyszukiwania w bazie wektorowej:

1. Ingestion & Payload Attachment (Zapis i przypięcie ładunku użytecznego): Klient przesyła wektor wraz z metadanymi JSON (text, document_id, created_at, tenant_id).
2. Graph Insertion & Edge Linking (Wbudowanie w strukturę HNSW): Algorytm wyszukuje najbliższych sąsiadów dla nowego wektora na każdej warstwie grafu i tworzy dwukierunkowe krawędzie połączeń, uwzględniając limit stopnia wierzchołka $M$.
3. Query Ingestion & Multi-layer Traversal (Zapytanie wyszukiwawcze): Po otrzymaniu wektora zapytania algorytm rozpoczyna przeszukiwanie zachłanne (Greedy Search) od najwyższej warstwy, schodząc na niższe poziomy w miarę lokalizowania odpowiedniego klastra.
4. Single-Stage Filtered Retrieval (Pobieranie z filtrowaniem): Jeśli zapytanie zawiera filtr SQL/JSON, weryfikacja zgodności metadanych następuje bezpośrednio podczas traversowania grafu (Filtered HNSW), co gwarantuje zwrot wyłącznie ściśle relewantnych rekordów.

4. Praktyczne scenariusze inżynierskie w środowisku produkcyjnym

01. Pamięć długoterminowa agentów (Agent Memory Storage)

Autonomiczny agent przechowuje fakty dotyczące dewelopera w kolekcji Qdrant lub pgvector: [vector, payload: { user_id: 104, fact: "preferuje bun zamiast npm" }]. Przed rozpoczęciem sesji agent wyodrębnia 5 najbardziej relewantnych faktów.

02. Produkcyjne RAG dla wsparcia technicznego

Baza wektorowa przechowuje 500 000 chunków dokumentacji. Zapytanie klienta w czasie 12 milisekund znajduje 20 najbardziej relewantnych fragmentów instrukcji, które są następnie przekazywane do rerankera.

03. Katalog e-commerce z filtrowaniem fasetowym

Wyszukiwanie odzieży dla zapytania: „lekka kurtka do biegania na jesień” z obligatoryjnym wcześniejszym filtrem price <= 3000 AND in_stock = true AND size = 'L'.

5. Pułapki, typowe błędy i bezpieczeństwo

• Niezgodność wymiarowości (Dimension Mismatch Error): Próba wykonania wyszukiwania wektorem modelu OpenAI (1536 wymiarów) w indeksie utworzonym dla modelu Cohere (1024 wymiary) prowadzi do fatalnego błędu runtime bazy danych.
• Szczyt zużycia pamięci podczas budowy indeksu (HNSW Build RAM Spike): Tworzenie indeksu HNSW dla 5 milionów wektorów wymaga 2–3 razy więcej pamięci RAM podczas procesu budowy niż do finalnego przechowywania. Buduj indeksy z uwzględnieniem bufora RAM lub wykorzystaj kwantyzację dyskową zewnętrzną.
• Zapominanie o vacuumingu i defragmentacji: Częste operacje UPDATE i DELETE tworzą w grafach wektorowych puste węzły-sieroty. Regularnie uruchamiaj optymalizację indeksów (Vacuum / Segment Compaction).