Vektorové databázy — infraštruktúra sémantického AI

Vektorové databázy sú špecializované úložiská, ktoré umožňujú AI systémom vyhľadávať podľa významu, nie podľa kľúčových slov — a stali sa základnou stavebnou jednotkou každého seriózneho RAG systému či sémantickej aplikácie.

1. Prečo nestačí bežná databáza

Tradičné databázy (PostgreSQL, MySQL, MongoDB) vyhľadávajú záznamy podľa presných hodnôt alebo jednoduchých indexov. Ak hľadáte „auto", nenájdete dokumenty obsahujúce „vozidlo" alebo „sedan" — pokiaľ ich explicitne nesúvislostí sami.

AI modely však pracujú inak. Každý text, obrázok alebo zvuk môže byť reprezentovaný ako vektor — zoznam čísel (napr. 1 536 čísel pri OpenAI text-embedding-3-small), ktorý zachytáva sémantický obsah. Dva texty s podobným významom budú mať blízke vektory v multidimenzionálnom priestore, aj keď nezdieľajú ani jedno slovo.

Vektorová databáza rieši jeden špecifický problém: rýchlo nájsť K najbližších vektorov k danému dopytu spomedzi miliónov alebo miliárd uložených záznamov.

Kľúčové pojmy:

  • Embedding — numerická reprezentácia objektu v latentnom priestore.
  • Similarity search — vyhľadávanie podľa vzdialenosti (cosine, dot product, L2).
  • ANN (Approximate Nearest Neighbor) — algoritmus, ktorý hľadá približne najbližších susedov rýchlo, nie presne pomaly.

2. Ako vektorové vyhľadávanie funguje

Keď vložíte text do vektorovej databázy, postup je nasledovný:

  1. Embedding model (napr. text-embedding-3-large, nomic-embed-text, bge-m3) prevedie text na vektor.
  2. Vektor sa uloží spolu s metadátami (ID, dátum, kategória, zdroj…).
  3. Pri dopyte sa vstupný text tiež prevedie na vektor.
  4. Databáza spustí ANN algoritmus — najčastejšie HNSW (Hierarchical Navigable Small World) alebo IVF (Inverted File Index).
  5. Vrátia sa záznamy zoradené podľa podobnosti.

HNSW buduje hierarchickú sieť grafov — každý uzol je prepojený s najbližšími susedmi na viacerých úrovniach abstrakcie. Vyhľadávanie začína „zhora" a postupne sa zúžuje — rýchlosť O(log n) aj pri miliardách vektorov.

Hybridné vyhľadávanie kombinuje vektorovú podobnosť s klasickým BM25 (kľúčové slová) a výsledky zlúči cez RRF (Reciprocal Rank Fusion). Tento prístup v praxi prekonáva čistý vektor aj čistý keyword search.

3. Porovnanie hlavných vektorových databáz

Databáza Typ Hybridné vyhľadávanie Self-hosted Silná stránka
Pinecone Managed cloud Áno (serverless) Nie Jednoduchosť, škálovanie
Qdrant Open-source / cloud Áno Áno Výkon, Rust jadro, filtrovanie
Weaviate Open-source / cloud Áno Áno GraphQL API, modulárne
Chroma Open-source Čiastočne Áno Rýchly prototype, Python-natívny
pgvector PostgreSQL extension Cez SQL Áno Existujúca Postgres infraštruktúra
Milvus Open-source Áno Áno Veľmi veľké datasety, Kubernetes
LanceDB Embedded / cloud Áno Áno Bez servera, lokálne súbory

Odporúčanie podľa veľkosti projektu:

  • Prototyp / experiment → Chroma alebo LanceDB (nula infraštruktúry).
  • Produkcia, malý tím → Qdrant self-hosted alebo Pinecone serverless.
  • Enterprise, existujúci Postgres → pgvector s HNSW indexom (od verzie 0.7.0 výrazne rýchlejší).
  • Miliardy vektorov → Milvus alebo Pinecone dedikovaný cluster.

4. Praktické využitie

RAG (Retrieval-Augmented Generation) Najrozšírenejší use-case. Dokumenty sa rozrežú na chunky, každý sa embeduje a uloží do vektorovej databázy. Pri otázke používateľa sa nájde K najpodobnejších chunkrov a vložia sa do kontextu LLM, ktorý potom generuje odpoveď podloženú faktami.

# Minimálny príklad s Qdrant + OpenAI
from qdrant_client import QdrantClient
from openai import OpenAI

client = QdrantClient(":memory:")
ai = OpenAI()

def embed(text: str) -> list[float]:
    return ai.embeddings.create(
        input=text, model="text-embedding-3-small"
    ).data[0].embedding

# Vloženie dokumentu
client.upsert("docs", points=[{
    "id": 1,
    "vector": embed("Kvantizácia redukuje pamäťové nároky modelu."),
    "payload": {"text": "Kvantizácia redukuje pamäťové nároky modelu."}
}])

# Vyhľadávanie
hits = client.search("docs", query_vector=embed("ako ušetriť GPU pamäť"), limit=3)

Ďalšie use-casy:

  • Sémantické vyhľadávanie v e-commerce (hľadám „niečo na grilovanie" → nájde grily, marinovačky, uhlíky).
  • Odporúčacie systémy — nájdi produkty podobné tým, čo používateľ kúpil.
  • Detekcia duplicít — nájdi podobné tikety, články, bugové reporty.
  • Multimodálne vyhľadávanie — text → obrázok, obrázok → text (pomocou CLIP embeddingov).
  • Anomaly detection — záznamy ďaleko od všetkých ostatných sú anomálie.

5. Limity, riziká a čo ďalej

Limity:

  • Kvalita výsledkov závisí od kvality embeddingov — zlý embedding model = zlé vyhľadávanie bez ohľadu na databázu.
  • ANN je aproximácia — pri malom datasete môže byť brute-force presnejší.
  • Chunking stratégia (ako deliť dokumenty) dramaticky ovplyvňuje kvalitu RAG. Neexistuje univerzálne pravidlo.
  • Aktualizácia vektorov je drahá — zmena embedding modelu vyžaduje re-embedovanie celého korpusu.

Bezpečnosť:

  • Vektorové databázy bývajú podceňované z pohľadu prístupu — obsahujú embeddingy, z ktorých možno čiastočne rekonštruovať pôvodný text (embedding inversion attacks).
  • Pri citlivých dátach (zdravotné záznamy, právne dokumenty) treba šifrovanie aj na úrovni payloadu.

Trendy 2026:

  • Matryoshka embeddings (MRL) — jeden model produkuje vektory rôznych dĺžok; kratší vektor = rýchlejší hrubý filtering, dlhší = presné re-ranking.
  • Sparse + dense hybrid sa stáva štandardom — databázy ako Qdrant a Weaviate ho majú natívne.
  • GraphRAG — okrem vektorovej podobnosti sa buduje znalostný graf vzťahov medzi entitami; Microsoft, Anthropic aj Google experimentujú s kombináciou.
  • Embedded databázy (LanceDB, DuckDB+vss) umožňujú vektorové vyhľadávanie bez servera priamo v aplikácii.

Zhrnutie: Vektorové databázy sú nevyhnutná infraštruktúra pre každú AI aplikáciu, ktorá pracuje s vlastnými dátami — od RAG cez odporúčania až po sémantické vyhľadávanie. Voľba konkrétneho riešenia závisí od škály, tímu a existujúcej infraštruktúry, pričom hybridné vyhľadávanie (vektor + kľúčové slová) dnes prekonáva oba prístupy samostatne.