Abisearch: vektoros keresés magyar nyelvű dokumentumokon

Az elmúlt években több ügyfélszolgálati és tudásbázis-projektben futottunk bele ugyanabba a problémába: a keresés nem találja meg azt, amit a felhasználó keres, mert nem ugyanazokat a szavakat használja, mint a dokumentum. Magyar nyelven ez különösen fájdalmas. Ebből a tapasztalatból született az Abisearch, a saját SaaS vektoros keresési API-nk, amely az abisearch.abigel.ai címen érhető el. Ebben a bejegyzésben a technikai hátteret és a döntéseinket írjuk le.

Kulcsszavak helyett jelentés

A hagyományos, kulcsszavas keresés (fordított index, BM25 rangsorolás) akkor működik jól, ha a keresőkifejezés és a dokumentum szóalakja egyezik. A “kényelmes futócipő” kérdésre nem találja meg a “könnyű edzőcipő kocogáshoz” leírást, pedig a felhasználó pontosan ezt keresi.

A vektoros keresés más elven működik. Egy embedding modell minden szövegrészletet egy több száz dimenziós számvektorrá alakít úgy, hogy a hasonló jelentésű szövegek vektorai közel kerüljenek egymáshoz. A keresés ezután nem szóegyezést, hanem vektortávolságot néz. A modell többnyelvű, így a magyar kérdés megtalálja az angol dokumentumot is, és fordítva.

Ez nem váltja ki teljesen a kulcsszavas keresést: azonosítók, cikkszámok, pontos kifejezések esetén az egyezés továbbra is fontos. Ezért az Abisearch hibrid módon dolgozik: a vektoros találatokat kulcsszavas jelekkel egészíti ki, és a végső sorrendet a kettő kombinációja adja.

A magyar nyelv nehézségei

A magyar agglutináló nyelv: egyetlen szótőhöz toldalékok tucatjai kapcsolódhatnak, és a “cipő”, “cipőt”, “cipőben”, “cipőjükkel” alakok egy kulcsszavas rendszer számára négy különböző szó. A szótövezés (stemming) részben segít, de gyakran túl agresszív vagy hibás, az összetett szavak (“futócipő”, “edzőcipő”) pedig külön problémát jelentenek.

A többnyelvű embedding modellek ebben lényegesen jobbak, mert a tokenizálás szubszó-szintű, és a modell a jelentést tanulta, nem a szóalakot. Amit a gyakorlatban mégis kezelnünk kellett:

• a hosszú magyar mondatok több tokent használnak, mint az angol megfelelőjük, ezért a szövegdarabolás (chunking) méretét nyelvfüggően állítjuk,
• az ékezetes és ékezet nélküli írásmód (“cipo” és “cipő”) a kulcsszavas ágban normalizálást igényel,
• a rövid, egy-két szavas keresések vektora “zajos”, ezért ezeknél a kulcsszavas ág nagyobb súlyt kap.

Ezeket a szabályokat nem az ügyfélnek kell beállítania; az API a nyelvet felismeri és ennek megfelelően dolgozik.

Feltöltés és API

A célunk az volt, hogy gépi tanulási ismeret nélkül is használható legyen. Ezért az adatbetöltés két formátumot fogad: JSON-t (rekordok tömbje tetszőleges mezőkkel) és Excel-táblázatot (soronként egy rekord, oszloponként egy mező). A feltöltéskor megadható, mely mezők kerüljenek a keresési szövegbe, és melyek maradjanak metaadatként szűrhető formában.

A keresés egyetlen REST-végpont: a kérés a természetes nyelvű keresőkifejezés és opcionális szűrők, a válasz a találatok listája relevancia-pontszámmal és az eredeti rekorddal. cURL-ből, Pythonból, JavaScriptből vagy PHP-ból ugyanúgy hívható, mint bármely HTTP API. Az API-kulcs fejlécben megy, a válaszok tartalmazzák a hátralévő kvótát.

A háttérben a dokumentumok darabolása, az embeddingek kiszámítása és az index frissítése aszinkron, sorban történik, hogy egy nagy feltöltés ne lassítsa a többi ügyfél keresését. Ez ugyanaz a multi-tenant minta, amelyről korábban írtunk: bérlőnkénti korlátok és sorok, közös infrastruktúra.

Újrarangsorolás

A vektortávolság önmagában nem mindig adja a legjobb sorrendet: az első húsz találat között gyakran ott van a jó válasz, de nem feltétlenül az első helyen. Ezért opcionális újrarangsorolási (re-ranking) lépést kínálunk: a legjobb jelölteket egy nagy nyelvi modell (Gemini) újraértékeli a keresőkifejezés kontextusában, és a végső sorrendet ez adja.

Az újrarangsorolás lassabb és drágább, mint az alap keresés, ezért kérésenként kapcsolható. Tudásbázisnál és ügyfélszolgálati cikkeknél érdemes bekapcsolni; termékkatalógus gyors szűrésénél gyakran elég az alap találati lista.

Üzemeltetés, adatkezelés, árazás

Az Abisearch teljes egészében az Európai Unión belüli adatközpontban fut, a feltöltött adatok és az indexek is ott maradnak. Az adatkezelés a GDPR szerint történik; a feltöltött adathalmaz bármikor törölhető, és a törlés az indexből is eltávolítja.

Az árazás használatalapú: minden fiók naponta 100 kérést ingyen kap, e felett kérésenként 0,001 eurót számolunk. Nincs havi minimum, nincs csomag, amit előre meg kellene venni. Ez tudatos döntés: a kis projektek (egy belső dokumentumtár, egy néhány száz termékes webshop) így költség nélkül kipróbálhatják, a nagyobbak pedig a tényleges forgalom után fizetnek.

Ha valaki az abisearch.abigel.ai címen kipróbálja és bármilyen tapasztalatot vagy hibát szeretne megosztani, az info@procats.hu címen várjuk. A következő lépéseink a hangalapú rendszerek felé mutatnak, ahol a keresés csak egy komponens lesz a beszélgetésben.