Od slov k významu
Text se pomocí embedding modelu převede na vektor – číselnou reprezentaci jeho významových vlastností. Podobné významy by měly být ve vektorovém prostoru blíže u sebe.
Zjednodušeně:
„zapomenuté heslo“ → [0.12, -0.43, 0.87, …]
a
„problém s přihlašováním“ → [0.15, -0.39, 0.82, …]
Tato čísla sama o sobě příliš neznamenají. Pro systém ale určují pozici textu ve vektorovém prostoru. Vektorová databáze pak dokáže vyhledat vektory, které jsou danému dotazu nejpodobnější.
Výsledkem tedy není pouze:
„Najdi dokument obsahující tato slova.“
Ale spíše:
„Najdi obsah, který se významově nejvíce podobá tomuto dotazu.“
Co dělá vektorová databáze?
Vektorová databáze je systém určený k ukládání, indexování a vyhledávání vektorových reprezentací.
Představme si, že máme 500 000 dokumentů. Každý relevantní kus textu převedeme pomocí embedding modelu na vektor a uložíme ho spolu s původním obsahem a případnými metadaty.
Když uživatel položí otázku, vytvoří se embedding také z jeho dotazu.
Dotaz → embedding model → query vector → vector search → relevantní výsledky
Databáze následně vyhledá nejbližší vektory.
Tento princip je velmi důležitý například u RAG (Retrieval-Augmented Generation).
Vektorová databáze jako paměť pro AI
Samotný LLM nemusí znát vaše interní dokumenty. Místo toho může aplikace při každém dotazu nejprve vyhledat relevantní části firemní dokumentace.
Uživatel se například zeptá:
„Kolik dní dovolené máme po třech letech ve firmě?“
Vector search najde relevantní pasáž v HR dokumentaci, i když dotaz nepoužívá přesně stejná slova jako dokument.
Tato pasáž se následně vloží do kontextu promptu a LLM z ní vytvoří odpověď.
Zjednodušeně:
Uživatel → dotaz → embedding → vector search → relevantní dokumenty → LLM → odpověď
Vektorová databáze tedy není samotná AI. Je součástí systému, který AI umožňuje pracovat s externími daty.
Proč se dokumenty rozdělují na menší části?
V RAG systémech se dokumenty často rozdělují na menší části – chunks.
Pokud bychom například celý 100stránkový dokument reprezentovali jediným embeddingem, vyhledávání by získalo pouze velmi obecnou představu o jeho obsahu.
Místo toho může systém vytvořit:
Dokument → Chunk 1 → embedding
Dokument → Chunk 2 → embedding
Dokument → Chunk 3 → embedding
Při vyhledávání tak může najít konkrétní část dokumentu, která obsahuje relevantní informaci.
Velikost chunků je ale potřeba nastavit rozumně. Příliš malé části mohou ztratit kontext, příliš velké zase obsahují příliš mnoho nesouvisejících informací.
Jak se vyhledává mezi miliony vektorů?
Pokud máme velké množství vektorů, teoreticky bychom mohli každý nový query vector porovnat se všemi.
To by ale bylo pomalé a nákladné.
Proto vector search používá indexy a algoritmy pro Approximate Nearest Neighbor (ANN) search. Ty umožňují efektivně najít menší skupinu kandidátů, mezi kterými se pravděpodobně nacházejí nejrelevantnější výsledky.
Jedním z populárních přístupů je HNSW (Hierarchical Navigable Small World), který využívá vícevrstvý graf a umožňuje rychle se dostat do relevantní části vektorového prostoru.
Výsledkem je kompromis mezi rychlostí, využitím paměti a přesností vyhledávání.

Vektorová databáze nemusí být samostatný systém
Vector search neznamená, že musíte automaticky zavést úplně novou databázi.
Například pgvector umožňuje ukládat vektory přímo v PostgreSQL a podporuje approximate nearest-neighbor search i indexy jako HNSW a IVFFlat.
To může být praktické pro aplikace, které už PostgreSQL používají.
U větších nebo specifičtějších projektů existují také specializovaná řešení jako Weaviate nebo Milvus. FAISS je zase knihovna určená pro efektivní similarity search a clustering dense vectors.
A co přesnost?
Vector search neznamená, že systém vždy najde správnou odpověď.
Dokáže najít nejpodobnější výsledky, ale i ty mohou být ve skutečnosti nerelevantní.
Proto se v produkčních systémech používají například similarity thresholds, metadata filtry nebo další kroky hodnocení a rerankingu.
Stejně důležitá je kvalita samotných dat, chunkingu a embedding modelu.
Pokud retrieval najde nesprávný kontext, ani dobrý LLM z něj nemusí vytvořit správnou odpověď.
Keyword search vs. vector search
Vector search zároveň nemusí nahradit klasické vyhledávání.
Pokud uživatel hledá konkrétní kód:
„OBJ-2026-10482“
přesná shoda může být mnohem užitečnější než sémantická podobnost.
Proto moderní systémy často kombinují oba přístupy v rámci hybrid search.
Keyword search se postará o přesné výrazy a vector search o významovou podobnost. Jejich kombinace může být užitečná zejména u technických nebo firemních databází, kde uživatel přirozeně kombinuje běžný jazyk s přesnými názvy a identifikátory.
Kde se vektorové databáze používají?
Vector search má využití v mnoha AI aplikacích:
Inteligentní vyhledávání – uživatel nemusí znát přesný název dokumentu nebo produktu.
RAG aplikace – relevantní informace se vyhledají ve firemních datech a použijí jako kontext pro LLM.
Doporučovací systémy – systém může hledat produkty, články nebo obsah podobný tomu, co uživatele zajímá.
Vyhledávání obrázků a multimédií – embeddingy nemusí reprezentovat pouze text. Vector search lze použít také u obrázků, zvuku či dalších typů dat.
Vektorová databáze není kouzelná AI vrstva
Kvalita výsledného systému závisí na celém řetězci:
data → chunking → embedding model → index → retrieval → reranking → LLM
Pokud jsou data nekvalitní, vektorová databáze je nezachrání.
Pokud jsou chunky příliš velké nebo malé, může se zhoršit retrieval.
Pokud embedding model nerozumí dobře konkrétní doméně nebo jazyku, výsledky mohou být slabší.
A pokud systém najde nesprávný kontext, LLM může vytvořit přesvědčivě znějící odpověď založenou na nesprávných informacích.
Proto se při AI aplikacích nevyplatí hodnotit pouze samotnou databázi. Důležitý je celý retrieval pipeline.
Ne podle slova, ale podle významu
Největší změna, kterou vector search přináší, je jednoduchá.
U klasického vyhledávání se ptáme:
„Obsahuje tento dokument moje slova?“
U vector search:
„Je tento dokument významově podobný tomu, co hledám?“
Uživatel proto nemusí znát přesný název dokumentu ani terminologii, kterou databáze používá. Může jednoduše popsat svůj problém.
Vektorová databáze ale sama o sobě „nerozumí“ významu. Embedding model vytváří číselnou reprezentaci obsahu a vektorová databáze následně efektivně vyhledává podobné reprezentace.
A právě kombinace těchto technologií umožňuje AI aplikacím vyhledávat informace způsobem, který je mnohem bližší tomu, jak je hledá člověk.
Ne podle toho, jaké přesné slovo napsal.
Ale podle toho, co se pravděpodobně snažil najít.