A vektoradatbázis, PostgreSQL és pgvector

Mi az a beágyazás

A beágyazás, angolul embedding, az a lépés, amelyben egy szöveget, egy mondatot vagy akár egy egész bekezdést számok sorozatává, azaz egy vektorrá alakítunk. Ez a vektor nem véletlenszerű. Egy erre betanított modell úgy állítja elő, hogy a hasonló jelentésű tartalmak vektorai közel essenek egymáshoz, a teljesen más jelentésűek pedig távol kerüljenek. Ha az egyik mondat a szabadság kérelmezéséről szól, a másik pedig a szabadnap igényléséről, a vektoraik közel esnek egymáshoz, még akkor is, ha alig van bennük közös szó. Ez a lényeg. Nem a szavak egyezését keressük, hanem a jelentés közelségét. Így a rendszer akkor is megtalálja a releváns tartalmat, ha a kérdés egészen más szavakkal fogalmaz, mint a tárolt dokumentum.

Miért nem elég a kulcsszavas keresés

Sok cégnél a keresés máig a pontos szavak egyezésére épül. Ez akkor működik jól, ha a felhasználó ugyanazt a kifejezést írja be, amit a dokumentum is használ. A gyakorlatban azonban ritkán van így. Az egyik ember távmunkát ír, a másik home office-t, a harmadik otthoni munkavégzést. Ugyanarról beszélnek, mégis más szavakkal. A kulcsszavas kereső ilyenkor elszalasztja a releváns találatot, mert nem tudja, hogy a kifejezések egy tőről fakadnak. A beágyazás pontosan ezt a hézagot tölti be. Mivel a jelentést és nem a betűket fogja meg, a hasonló értelmű megfogalmazásokat is összekapcsolja. Ez az oka annak, hogy a vektoros keresés sok belső tudásbázisnál érezhetően jobb élményt ad, mint a hagyományos szókeresés.

Mit csinál a vektoradatbázis

A vektoradatbázis feladata egyszerűen leírható. Adott egy kérdés vektora, és meg kell találni a tárolt vektorok közül azt a néhányat, amelyik a legközelebb esik hozzá. A közelséget matematikai távolsággal mérjük. A leggyakoribb a koszinusz hasonlóság, amely a két vektor által bezárt szöget nézi, és az euklideszi távolság, amely a hagyományos térbeli távolság általánosítása több dimenzióra. A gyakorlatban ez annyit tesz, hogy a rendszer a beérkező kérdéshez sorba rendezi a tárolt tartalmakat, elöl a leghasonlóbbakkal, és visszaadja az első néhányat. A nehézség a méretben van. Ha nagyon sok tárolt vektor van, akkor mindegyikkel egyesével összevetni a kérdést lassú lenne. Ezért a vektoradatbázisok indexet építenek, amely a keresést felgyorsítja azzal, hogy nem kell minden egyes vektort végignézni ahhoz, hogy a legközelebbieket megtaláljuk.

Az index működésének van egy fontos velejárója, amit érdemes ismerni. A gyorsítás ára az, hogy a legtöbb vektoros index nem a matematikailag tökéletes legközelebbi találatokat adja vissza, hanem a nagyon jó közelítéseket. Ezt hívják közelítő legközelebbi szomszéd keresésnek. A gyakorlatban ez szinte sosem gond, mert a pontosság apró csökkenéséért cserébe a keresés sokszorosan gyorsul, és a végeredmény minőségét a felhasználó rendszerint észre sem veszi. Vezetői szemmel ez azt jelenti, hogy a sebesség és a pontosság között van egy állítható gomb, amit a feladathoz lehet igazítani.

Mi az a pgvector

A pgvector egy kiegészítés, angolul extension, a PostgreSQL adatbázishoz. A PostgreSQL egy régóta létező, széles körben használt, nyílt forrású relációs adatbázis, amely nagyon sok cégnél amúgy is fut, gyakran a fő üzleti adatok tárolására. A pgvector-rel ez a meglévő adatbázis képessé válik arra, hogy vektorokat tároljon egy külön oszloptípusban, és hasonlóság alapján keressen köztük, indexeléssel gyorsítva. Ez azt jelenti, hogy nem kell új, önálló rendszert üzembe helyezni és üzemeltetni. A vektorok ugyanabban a Postgres-ben élnek, mint a cég többi adata. Egy táblában együtt lehet a dokumentum szövege, a hozzá tartozó vektor, és bármilyen egyéb mező, például a forrás, a jogosultsági szint vagy a dátum. A keresés egyetlen SQL lekérdezés, amely a kérdés vektorához legközelebbi sorokat adja vissza, ugyanazokkal az eszközökkel, amiket a fejlesztők a cégnél már ismernek.

Egy magyar céges példa

Vegyünk egy fiktív, de tipikus esetet. Egy hazai középvállalatnál évek alatt felgyűlt több száz belső dokumentum, szabályzat, folyamatleírás és korábbi ügyfélválasz. A munkatársak sokszor nem találják meg, amit keresnek, mert a hagyományos kereső csak a pontosan beírt szavakra illeszkedik. A cél egy belső tudásbázis kereső, amelynek hétköznapi nyelven fel lehet tenni egy kérdést, és a rendszer megtalálja a legrelevánsabb dokumentumrészleteket, akkor is, ha a kérdés más szavakkal fogalmaz, mint az irat. Ehhez a dokumentumokat egyszer beágyazzuk, a vektorokat eltároljuk, és minden kérdésnél a kérdés vektorához legközelebbi részleteket kérjük vissza. Ha a cégnek már van PostgreSQL adatbázisa, ehhez a feladathoz jó eséllyel nem kell mást tenni, mint bekapcsolni a pgvector kiegészítést. Az alábbi lépéssor mutatja, hogyan áll össze ez a folyamat.

Egy dolgot érdemes még tisztázni a példa kapcsán. A dokumentumokat a gyakorlatban nem egészben ágyazzuk be, hanem kisebb, összefüggő részletekre bontjuk, és minden részletet külön vektorral tárolunk. Így a keresés nem egy egész húszoldalas szabályzatot ad vissza, hanem éppen azt a bekezdést, amelyik a kérdésre válaszol. Ez a felbontás pontosabb találatokat és rövidebb, célzottabb szövegrészeket eredményez. Ugyanabban a Postgres táblában ott lehet a részlet szövege, a vektora és a forrás megjelölése, így a válasz mellé az is odaadható, hogy melyik dokumentumból származik. A cég számára ez azért fontos, mert a munkatárs nemcsak a választ látja, hanem a hivatkozott forrást is ellenőrizheti.

Mikor elég a pgvector és mikor kell dedikált vektoradatbázis

A fő üzenet, hogy a feladatok nagy részére a pgvector bőven elég. Ha a tárolt vektorok száma nem extrém magas, és a másodperc körüli válaszidő is megfelel, akkor a meglévő Postgres a pgvector kiegészítéssel ellátja a munkát, és nem kell külön rendszert bevezetni. Van azonban néhány eset, amikor indokolt lehet egy dedikált, kifejezetten vektorkeresésre tervezett adatbázis. Ilyen a nagyon nagy méret, amikor a vektorok száma olyan magas, hogy a specializált tárolás és index érdemi előnyt ad. Ilyen az extrém alacsony késleltetés igénye, amikor minden ezredmásodperc számít, például nagy forgalmú, valós idejű felhasználásnál. És ilyen az az eset, amikor speciális indextípusokra vagy keresési képességekre van szükség, amit a dedikált rendszerek finomabban kínálnak. A döntéshez az alábbi összevetés ad támpontot.

A vezetői tanulság, a felesleges túlköltés

Itt van a lecke leglényegesebb üzenete a döntéshozónak. A vektoradatbázis az elmúlt években divatos téma lett, és sok cég ennek nyomán vezet be külön, önálló vektoradatbázist, gyakran fizetős, felhő alapú szolgáltatásként, holott a meglévő eszköze elég lenne. Ez tipikus túlköltés. Nem azért születik, mert a feladat megköveteli, hanem mert a piaci zaj azt sugallja, hogy egy AI projekthez mindenképp külön vektoradatbázis kell. A gyakorlatban a legtöbb belső keresési és RAG feladatnál a már meglévő PostgreSQL a pgvector kiegészítéssel megoldja a problémát, új szerződés és új üzemeltetett rendszer nélkül. A helyes sorrend ezért az, hogy először megnézzük, mi van már a háznál, és csak akkor lépünk tovább egy dedikált rendszerre, ha a méret, a késleltetés vagy egy speciális igény ezt valóban indokolja. Ez a szemlélet sok cégnél elkerülhető költséget és felesleges bonyolultságot spórol meg.

A döntést egyetlen kérdéssorral fel lehet gyorsítani. Fut már PostgreSQL a cégnél. Kezelhető méretű a tárolt tartalom. Elég a másodperc körüli válaszidő. Ha ezekre a válasz igen, akkor a pgvector nagy valószínűséggel elég, és nem éri meg új rendszert bevezetni. Egy dedikált vektoradatbázis nem rossz eszköz, sőt a maga helyén kifejezetten értékes, csak ritkábban van rá szükség, mint amennyit a piaci kommunikáció sugall. A vezetői feladat itt nem az, hogy a legmodernebbnek tűnő eszközt válassza, hanem hogy a feladat valós igényeihez mérje a döntést, és ne fizessen olyan képességért, amit a cég a gyakorlatban nem használ ki.