Vector database szakzsargon nélkül

Mit csinál egy vektoros index?

A beágyazás minden szövegdarabot számsorrá alakít — jellemzően 768, 1 024 vagy 1 536 számmá. A keresés ezután geometria: melyik számsor van legközelebb a kérdésedéhez. Erről a lépésről az embedding és a vektoros keresés című írás szól bővebben.

A probléma egyetlen mondatban: ha egymillió darabod van, akkor egymillió távolságot kellene kiszámolni minden kérdésnél. A vektoros index arra való, hogy ezt ne kelljen.

Három megközelítés létezik, és érdemes tudni, melyik mit áldoz fel:

A gráfalapú megoldás a legelterjedtebb, és a szerzők saját hasonlatával könnyű megérteni: olyan, mint egy több szintes térkép. A legfelső szinten kevés pont van, hosszú ugrásokkal; lefelé haladva egyre több pont, egyre rövidebb lépések. A keresés fent kezd, nagyokat ugrik, aztán egyre finomabban közelít.

A lényeg, amit ebből érdemes elvinni: mindegyik közelítés, kivéve az elsőt. A vektoros keresés nem garantálja, hogy a legjobb találatot adja — csak azt, hogy nagyon gyorsan ad egy nagyon jó találatot. Ez általában elég, de nem mindig; erről szól a hybrid search című írás.

A memóriaszámítás, ami eldönti a kérdést

Itt van a cikk legfontosabb táblázata. [Saját számítás] a gyártó hivatalos kapacitástervezési képletéből, 1 536 dimenziós vektorokkal:

vektor / darab = 1 536 dimenzió × 4 bájt = 6 144 bájt ≈ 6 KB
index  / darab = 16 × 2 × 4 bájt × 1,2   = 154 bájt

Ebből az egyetlen táblából kiolvasható, hol vannak a fájdalomküszöbök:

• 10 ezer vektor: 75 MB. Elfér bárhol. Nem kell semmi különleges.
• 1 millió vektor: 7,5 GB. Kis virtuális gépbe már nem fér, normál szerverbe igen. Itt kezd számítani a kvantálás.
• 10 millió: 75 GB. Itt a memória lesz a fő költségtétel, és itt kezd értelme lenni a lemezes indexnek.
• 100 millió: 755 GB. Memóriában tartani ésszerű pénzért már nem járható út.

És figyeld meg az index oszlopát: ebben a példában mindenhol a teljes méret 2-3%-a — a gyártó saját, 768 dimenziós példájában 5%. A „drága a vektoros index" tévhit onnan jön, hogy összekeverik az indexet a vektorokkal.

Két szorzó, ami a leggyakrabban kimarad a tervezésből: a replikáció duplázza a memóriát, és a dimenziószám lineárisan szorozza. Utóbbi a legerősebb, amit szabadon állíthatsz — 1 536-ról 512 dimenzióra váltva a memória harmadára esik.

Kvantálással pedig tovább csökken: félpontossággal a felére, nyolcbites kvantálással a negyedére — a gyártó mérése szerint gyakorlatilag nulla pontosságvesztéssel. A kvantálásról a quantization című írás szól részletesen.

Kell egyáltalán külön adatbázis?

Ez a fejlesztő olvasó valódi kérdése, és 2026-ban a válasz megváltozott.

Azért van egyáltalán választás, mert a vektoros keresés nem adatbázisfajta, hanem képesség. Ugyanaz a relációs adatbázis, amelyik a cég valódi adatait tárolja, meg tudja tanulni: a Postgreshez van egy pgvector nevű kiterjesztés, ami ad neki egy vektor oszloptípust és hozzá közelségi indexeket. Ettől a szövegdarab és a beágyazása ugyanabban a táblában, egymás mellett ül, a keresés pedig sima SQL — a metaadat-szűréssel egy lekérdezésben.

És a pgvector felzárkózott. A 2026 júliusi kiadás tudja a gráfalapú és a klaszteres indexet, a nyolcbites és a bináris kvantálást, a félpontosságot — és 2024 vége óta tudja azt is, ami a legrégebbi panasz volt ellene: a szűréssel kombinált keresést, ahol korábban túl kevés találat jött vissza.

Egy fontos korlátot viszont érdemes előre tudni: az alap vektortípus legfeljebb 2 000 dimenziót indexel. A ma elterjedt nagyobb beágyazó modellek 3 072 dimenziót adnak — ez nem fér bele. Két megoldás van: félpontosságú típus (4 000-ig), vagy a beágyazás dimenziószámának csökkentése, amit a nagyobb modellek támogatnak.

NEM KELL KÜLÖN VEKTORADATBÁZIS, HA

- a Postgresed már ott van, és a vektorok elférnek;
- a méret még nem indokolja az indexet (százezres
  nagyságrendig a pontos keresés gyakran elég);
- a metaadat-szűrés a fő művelet - a relációs
  szűrés plusz kis vektorhalmaz egyszerűbb.

KELL, HA

- a memóriaigény meghaladja a géped kapacitását,
  és lemezes vagy rétegzett tárolás az egyetlen út;
- a lekérdezés/másodperc az elsődleges szempont;
- natívan kell hibrid keresés, egy indexben.

A tranzakció és a JOIN olyasmi, amit egy relációs adatbázis tud, egy vektoradatbázis pedig nem — ez a szempont a legtöbb összehasonlításból kimarad.

Mit mond a mérés?

Van egy nyilvános összehasonlítás hét rendszerről, azonos havi költségkeret mellett, egymillió vektoron. Négy sor belőle:

Két dolgot érdemes leolvasni. Az egyik: azonos költségkeret mellett nagyságrendi különbség van a lekérdezési kapacitásban — 1 147-től 13 316-ig.

A másik a fontosabb: a leggyorsabb rendszer nem a legjobb találatokat adja. A C rendszer háromszor nagyobb késleltetéssel dolgozik, de a legmagasabb recallt hozza. Ha az számít, hogy megtaláld a helyes választ — és RAG-nél pont az számít —, akkor a benchmark-győztes nem feltétlenül a te nyertesed.

(A mérést az egyik szereplő végezte, saját nyílt forrású keretrendszerével, és a saját terméke nyer. A kód nyílt és van független változata is. A mérés dátuma az oldalon nem szerepel — ez önmagában fenntartás.)

Amit ebből NEM lehet leírni: hogy a pgvector hányszor lassabb a dedikált rendszereknél. Ilyen független, 2026-os mérést nem találtam — a kiterjesztés a hivatkozott összehasonlításban nem is szerepel.

Négy árazási logika, ami összehasonlíthatatlan

Ez a cikk legpraktikusabb része, mert a szolgáltatók árlistái nem összevethetők:

És a gyakorlati következmény, amit a legtöbb kalkulációból kihagynak: a belépő csomagok havi minimuma 16 és 250 dollár között mozog. Egy tízezer dokumentumos tudásbázis fogyasztása ennek töredéke. A minimumdíj a valódi költséged, nem a fogyasztás — vagyis egy kicsi rendszer aránytalanul drága.

A piac 2026-ban: mi él, mi tűnt el

Ez a fejezet azért van itt, mert ez a szektor gyorsabban változik, mint bármelyik másik, és emlékezetből írni róla garantált tévedés.

Megszűnt önálló termékként: az egyik korai szereplőt 2024 júniusában felvásárolta egy nagy modellfejlesztő, és a meglévő felhasználók 90 napot kaptak másik megoldásra váltani.

Névváltás, ami csapda: az egyik idősoros adatbázist fejlesztő cég 2025 júniusában nevet váltott — de a kiterjesztései nem. Aki fejből ír, vagy a régi cégnevet írja, vagy átnevezi a kiterjesztést is. Mindkettő rossz.

Felvásárolva, de tovább él: két ismert beágyazó- és újrarangsoroló-fejlesztő is gazdát cserélt, 2025 februárjában és októberében. A modellek elérhetők maradtak.

És a kategória zászlóshajója bajban: vezetőt váltott 2025 szeptemberében, és sajtóértesülések szerint eladást fontolgat. (Ez [sajtóértesülés], nem a cég bejelentése. A termék 2026 szeptemberében működik, elérhető, van árlistája — ezt ellenőriztem.)

A tágabb kép, ami ezt magyarázza: a beépült szereplők — a relációs adatbázisok, a keresőmotorok, a felhőplatformok — mind hozzáadták a vektorkeresést. Ezzel elvették a fő érvet, hogy egy egész új adatbázist kelljen bevezetni.

Késleltetés: két szám ugyanarról a rendszerről

Egy szolgáltató saját adatai, ugyanazon a 10 millió dokumentumos adaton:

Hatvanszoros különbség, ugyanabban a rendszerben. Ez jól mutatja, hogy egy architektúra nem egyformán olcsó minden művelettípusra — és hogy ha hibrid keresést tervezel, a szöveges oldal lehet a szűk keresztmetszet.

A how-to

1. SZÁMOLD KI A MÉRETET, MIELŐTT VÁLASZTASZ
   darab × dimenzió × 4 bájt. Ha az eredmény
   egy gigabájt alatt van, ne bonyolítsd.

2. NÉZD MEG, MI VAN MÁR NÁLAD
   Ha fut Postgres, valószínűleg megoldja.
   Egy adatbázissal kevesebb, tranzakcióval több.

3. ELLENŐRIZD A DIMENZIÓKORLÁTOT
   A nagy beágyazó modellek 3072 dimenziója nem
   fér az alap vektortípusba indexelve.

4. A DIMENZIÓSZÁM A LEGERŐSEBB SZORZÓ
   1536-ról 512-re: harmadára esik a memória.
   Előbb ezt próbáld, mint az architektúraváltást.

5. KVANTÁLÁS ELŐBB, NAGYOBB GÉP UTÁNA
   Nyolcbites kvantálás negyedére viszi a memóriát,
   alig mérhető pontosságvesztéssel.

6. NE A LEGGYORSABBAT VÁLASZD, HANEM A LEGPONTOSABBAT
   A mérésben a leggyorsabb rendszer nem adta a
   legjobb találatokat. RAG-nél a találat számít.

7. A HAVI MINIMUMOT NÉZD, NE AZ EGYSÉGÁRAT
   Kis tudásbázisnál a minimumdíj a teljes költség.

8. AMIT MA VÁLASZTASZ, NE LEGYEN VISSZAFORDÍTHATATLAN
   Ebben a szektorban két év alatt volt megszűnés,
   névváltás, három felvásárlás és egy vezetőváltás.

A nyolcadik pont ebben a kategóriában nem óvatoskodás. Tartsd meg a nyers szövegdarabokat és a metaadatot a saját tárolódban is: a beágyazást bármikor újra le tudod futtatni, a dokumentumaidat viszont nem tudod visszaszerezni egy leállított szolgáltatásból.

Tipikus félreértések

• „A vektoros index sok memóriát eszik." A hivatalos képlet szerint a gráf a teljes memória néhány százaléka. A vektorok esznek.
• „A vektoros keresés megtalálja a legjobb találatot." Csak a pontos keresés garantálja ezt. A gyors indexek mind közelítenek.
• „Kell egy vektoradatbázis, ha RAG-et építek." Százezres nagyságrendig a meglévő adatbázisod jellemzően elég. Ez skálázási eszköz, nem belépőfeltétel.
• „A benchmark-győztes a legjobb választás." Ugyanabban a mérésben a leggyorsabb rendszer alacsonyabb recallt adott, mint egy háromszor nagyobb késleltetésű.
• „A tárolás a fő költség." A tárolás fillér. A havi minimumdíj és a válaszadás modellköltsége a valódi tétel.
• „Ezt egyszer eldöntöm, és kész." Két év alatt volt ebben a szektorban megszűnés, cégnévváltás és több felvásárlás. Tervezz kilépési utat.

Amit érdemes elvinni

A vektoros keresés matematikája egyszerűbb, mint a marketingje. Amit tudni kell: a memória a vektoroktól nő, nem az indextől, a dimenziószám a legerősebb szabályozód, és a százezres nagyságrendig gyakran nincs szükség semmi különlegesre.

A választás előtt érdemes egyetlen sort kiszámolni: darabszám × dimenzió × 4 bájt. Ha az eredmény egy gigabájt alatt van — és tízezer dokumentumnál általában az —, akkor a kérdés nem az, melyik vektoradatbázist válaszd, hanem hogy kell-e egyáltalán.

És egy dolog, ami a technológiaválasztásnál fontosabb: tartsd meg a nyers szövegeidet. A beágyazás újraszámolható, egy megszűnt szolgáltatásból kimentett tudásbázis nem. Hogy egyáltalán miért és hogyan darabolj, arról a chunking témájú poszt szól, a teljes képről pedig a RAG-magyarázat című pillércikk.