Co je vektorová databáze?

Vektorová databáze odpovídá na jednu otázku, velmi rychle

Dejte jí seznam čísel a ona vrátí uložené seznamy, které jsou mu nejblíže. To je celé rozhraní.

Těmi seznamy jsou embeddingy. Embedding model převede pasáž, popis produktu nebo obrázek na několik set až několik tisíc čísel umístěných tak, aby si podobné významy byly blízko, a co jsou embeddingy v AI popisuje jak. Vektorová databáze je místo, kde tyto seznamy žijí, jakmile jich máte hodně. Ukládá každý z nich s ID a nějakými metadaty, buduje nad nimi index a odpovídá na vyhledávání nejbližších sousedů: "tady je dotazový vektor, dej mi deset nejbližších."

Tou obtížnou částí je slovo rychle. Porovnat dotaz s milionem uložených vektorů po 1 536 číslech znamená 1,5 miliardy násobení, a dělat to při každém stisku klávesy neškáluje. Vektorové databáze proto používají přibližné indexy nejbližších sousedů, nejčastěji HNSW, grafovou strukturu z práce Malkova a Jašunina z roku 2016, která projde jen několik set kandidátů místo celého milionu a téměř vždy vrátí správnou odpověď. To "téměř" je ten kompromis: trocha přesnosti za tisícinásobné zrychlení.

Vaše stávající databáze hledá slova, vektorová databáze hledá význam

Relační databáze najde řádky, jejichž hodnoty odpovídají: WHERE customer_id = 4127. Fulltextový index najde dokumenty obsahující slova: refund AND policy. Vektorová databáze najde položky, jejichž význam je blízký: dotaz "jak dostanu své peníze zpět" vrátí pasáž s názvem "Vracení peněz a reklamace", přestože ty dva texty nesdílejí žádné slovo.

Poslední řádek ukazuje, jak rozostřená ta kategorie je. pgvector přidává vektorové sloupce a HNSW index do běžného Postgresu a Elasticsearch nese vektorové pole už od verze 7.0 z roku 2019 a HNSW vyhledávání od verze 8.0 z roku 2022. "Vektorová databáze" je často schopnost uvnitř databáze, kterou už provozujete, nikoli nový produkt, a samostatné produkty spolu soupeří na škále a provozní vyladěnosti, ne v tom, že by uměly něco, co Postgres neumí.

Chatování s vašimi dokumenty je vektorové vyhledávání s modelem na konci

Retrieval-augmented generation, kterou popisuje co je RAG, má krok vyhledávání a krok psaní. Vektorová databáze je ten krok vyhledávání.

1. Rozdělte každý dokument na pasáže o několika stovkách až tisíci tokenech.
2. Vytvořte embedding každé pasáže a uložte vektory spolu s textem pasáže a jejím zdrojem do vektorové databáze.
3. Když přijde dotaz, vytvořte jeho embedding a požádejte databázi o nejbližší pasáže.
4. Předejte tyto pasáže jazykovému modelu spolu s dotazem a nechte ho napsat odpověď.

Kroky 1 a 2 proběhnou jednou, když se dokumenty přidávají. Kroky 3 a 4 probíhají u každého dotazu. Jazykový model nikdy nevidí celou kolekci, vidí jen pět až deset pasáží, které databáze vybrala. Proto je odpověď jen tak dobrá jako vyhledávání: pokud je nejbližší vektor špatná pasáž, model sebejistě odpoví na špatnou otázku, což co je halucinace u AI řadí spíš jako minutí při vyhledávání než jako výmysl.

Kdy ji potřebujete a kdy je lepší poslat celý soubor

Rozhodnutí je otázkou velikosti. Model dokáže najednou zvážit jen své kontextové okno a každý token uvnitř se platí při každém tahu. Vektorová databáze existuje proto, aby modelu předložila jen relevantní výřez. U jednoho dokumentu, který se vejde, je vyhledávání krok, který lze přeskočit; u kolekce, která se nevejde, je to jediná možnost.

Porovnejme oba návrhy cenově na 300 000tokenové zprávě, tedy několika stovkách stran, kdy je položeno deset otázek a vždy se vyhledá pět 1 000tokenových pasáží. Posílání celého souboru pokaždé znamená 3 miliony vstupních tokenů. Vyhledání pěti pasáží po 1 000 tokenech na otázku znamená 50 000. Při ceníkových vstupních sazbách z indexu cen AI modelů, staženého z OpenRouter dne 2026-08-20, je rozdíl 60násobný u každého modelu. Cache promptů, tam kde ji poskytovatel nabízí, účtuje opakované čtení stejného souboru za desetinu až polovinu ceníkové ceny, což zúží rozdíl na přibližně 6x až 30x. Vyhledávání pořád vyhrává, jen o méně.

Návrh s celým souborem za ty peníze něco přináší, pokud se soubor vejde do rozpočtu: 60stránková smlouva, zhruba 40 000 tokenů, umožní modelu odpovídat na otázky, které vyžadují celý dokument najednou, například "neodporuje si tu něco s klauzulí 14", což vyhledávání položit nemůže, protože nikdy nevidí klauzuli 14 a ten rozpor ve stejné dávce. Z toho plyne pravidlo: jeden dokument, nebo hrstka, jde vcelku; knihovna jde přes vektorovou databázi. Mezi těmito dvěma variantami rozdělte nahrávaný obsah podle tématu, aby model dostal tu část, kterou potřebuje.

Whizi posílá text samotný, až do 40 000tokenového tahu

Whizi pro váš chat žádnou vektorovou databázi neprovozuje. Když přiložíte soubor, cesta nahrávání dokumentů extrahuje text a pošle ho modelu jako text promptu, až do pevného rozpočtu 40 000 tokenů na tah; delší nahrávka se ořízne, s upozorněním a značkou přímo ve zprávě, která to oznámí. Soubory projektů fungují stejně: funkce projekty připne až 10 souborů a jejich text znovu vloží do promptu při každé zprávě, s limitem 32 000 znaků na soubor a 120 000 pro celý blok projektu.

Limity jsou hranicí tohoto návrhu. Připnutý soubor nad 32 000 znaků se zkrátí, příloha nad rozpočet 40 000 tokenů na tah se ořízne a projekt je složka, ne prohledávatelná knihovna. Tento kompromis je záměrný: u smlouvy nebo práce, která se vejde do rozpočtu tahu, je lepší mít text přítomný než prohledávaný, a kontrola, na které záleží, tedy požádat model o citaci pasáže, kterou použil, funguje, protože ta pasáž tam je. Pro tisíc dokumentů je správným nástrojem vektorová databáze a chatovací aplikace tím špatným.

Z tohoto mechanismu vyplývají dva návyky. Pojmenujte soubor v otázce, jakmile je jich přiloženo víc, protože jinak si model vybírá potichu. A u každé odpovědi, podle které budete jednat, si vyžádejte citaci. Systém pro vyhledávání může vrátit špatnou pasáž, systém s celým souborem může odpovědět z paměti místo ze souboru. Citace odhalí obojí.