A gondolat, ami az egészet mozgatja
Képzelj el egy térképet, amin nem városok vannak, hanem jelentések. Az egymáshoz közeli pontok hasonlót jelentenek.
Az embedding az a művelet, ami egy szövegrészletnek megadja a koordinátáit ezen a térképen. A koordináta nem kettő szám, mint egy valódi térképen, hanem több száz vagy néhány ezer — de az elv ugyanaz: a hasonló jelentésű szövegek közel kerülnek egymáshoz.
Innen már egyszerű. Ha keresel valamit, a keresőkifejezésedet is elhelyezed ezen a térképen, és megnézed, mi van a közelében. Ez a vector search.
Miért jobb ez a kulcsszavas keresésnél?
Mert nem a szavakat hasonlítja össze, hanem a jelentést.
A „hogyan mondhatom fel a szerződést" kérdésre a kulcsszavas kereső azokat a bekezdéseket hozza, amikben szerepel a „felmond" szó. A vector search megtalálja azt is, ami így kezdődik: „A megállapodás megszüntetése iránti nyilatkozatot…" — pedig egyetlen közös szó sincs benne.
Ez a különbség egy céges tudásbázis nál nem árnyalat, hanem az egész működés alapja. A dokumentumaid a jogász, a mérnök és az értékesítő nyelvén íródtak; a kérdéseket pedig ügyfelek teszik fel, a maguk nyelvén.
Hogyan néz ki a gyakorlatban?
Négy lépés, és mind a négyben lehet hibázni.
1. Feldarabolás. A dokumentumokat kisebb részletekre bontod. Egy 40 oldalas szerződésnek nincs egyetlen jelentése — a felmondási idő és a szavatosság két külön pont a térképen.
2. Beágyazás. Minden darabra lefuttatsz egy embedding modellt, és eltárolod a kapott számsort.
3. Tárolás. A számsorokat olyan adatbázisba teszed, ami gyorsan megtalálja a legközelebbi pontokat. Ez a vector database.
4. Keresés. A kérdésre ugyanazzal a modellel számolsz embeddinget, és lekéred a hozzá legközelebbi néhány darabot.
A négy buktató
1. A darabolás dönt el mindent
Ez a leggyakoribb hibaforrás, és a legkevésbé látványos. Ha egy gondolat kettévágódik két darab közé, egyik darab sem lesz jó válasz — és a kereső mindkettőt gyengének fogja találni.
Gyakorlati szabály: a darab határa kövesse a dokumentum szerkezetét — bekezdést, szakaszcímet, listaelemet —, ne pedig egy fix karakterszámot. És legyen átfedés a szomszédos darabok között, hogy a határon lévő mondat mindkettőben megmaradjon.
2. A keresésnek és a tárolásnak ugyanaz a modell kell
Ha az adatbázist az egyik embedding modellel töltötted fel, a kérdést is azzal kell beágyazni. Két különböző modell két különböző térképet rajzol, és a koordinátáknak semmi közük egymáshoz.
Ebből következik egy üzemeltetési következmény: ha embedding modellt váltasz, az egész adatbázist újra kell építeni. Ezt érdemes előre betervezni, mert nem kicsi munka.
3. A magyar nyelv nem magától jó
Nem minden embedding modell többnyelvű, és amelyik igen, az sem egyformán erős minden nyelven. Mielőtt bármit építesz, teszteld le magyar szövegen: vegyél húsz kérdés-bekezdés párt, ahol tudod a helyes választ, és nézd meg, megtalálja-e.
Az is előfordulhat, hogy egy angol nyelvű modell magyarul gyengébb, mint egy kisebb, de kifejezetten többnyelvű társa. Ez nem a méreten múlik.
4. A jelentés önmagában kevés
A vector search jelentésre keres, és ezért rossz a pontos azonosítókban: cikkszám, rendelésszám, jogszabályi hivatkozás, dátum. Ezekre a régi jó kulcsszavas keresés pontosabb.
A megoldás nem választás, hanem összeadás: hybrid search — kulcsszavas és jelentés alapú keresés együtt, az eredmények összefésülésével. A legtöbb rendszeren ez az egyetlen változtatás javít a legtöbbet.
Hol kapcsolódik mindez az AI-hoz?
Az embedding és a vector search nem generatív technológia — nem ír semmit, csak megtalál. A nyelvi modell akkor lép be, amikor a megtalált részletekből választ fogalmaz. Ezt a párost hívjuk RAG-nak, és arról külön cikk szól: Fine-tuning, RAG vagy jobb prompt?
Érdemes ezt szétválasztva tartani a fejedben, mert a legtöbb rossz válasz nem a modell hibája, hanem a keresésé. Ha rossz bekezdést adtál oda, a legjobb modell sem tud jó választ adni belőle.
Egy fél napos próba, mielőtt bármit építesz
Vegyél harminc valódi kérdést, amit az ügyfeleid vagy a kollégáid tényleg feltettek. Írd le mindegyikhez, melyik dokumentumban és melyik bekezdésben van a válasz.
Aztán építs egy egyszerű indexet, és nézd meg: hány esetben van a helyes bekezdés az első ötben?
Ha ez a szám nyolcvan százalék alatt van, ne is menj tovább a nyelvi modellig — előbb a keresést kell rendbe tenni. Ha efölött van, a nehezén túl vagy.
Amit érdemes elvinni
Az embedding a jelentést számmá alakítja, a vector search pedig ebben keres. Egy RAG-rendszer minősége nyolcvan százalékban a daraboláson és a keresésen múlik, nem a generáláson — és épp ezért ezen a két lépésen érdemes időt tölteni.