Vektoros keresőmotorok új kihívásokkal néznek szembe
Az információvisszakeresés sosem volt még ekkora üzlet. A berlini Qdrant, nyílt forráskódú vektorkereső vállalat a közelmúltban 17,5 milliárd forint (50 millió USD) tőkét vont be, két évvel korábbi 9,8 milliárd forintos (28 millió USD) befektetése után. Ugyanekkor megjelent a platform 1.17-es verziója is, ami jól mutatja: a visszakeresés problémája az ügynökök érkezésével nemhogy csökkent, hanem ugrásszerűen nőtt. Egy vállalatvezető szerint egy ember percenként néhány lekérdezést küld, míg egy ügynök akár másodpercenként több száz vagy ezer kérést generálhat, hogy döntést tudjon hozni.
Így a visszakereső réteg nem egyszerűen adatbázisfeladat, hanem kulcsfontosságú rendszerkomponens. Az MI-ügynökök folyamatosan változó adatokon, aktuális vállalati információkon és akár több millió frissülő dokumentumon dolgoznak, amelyekre kizárólag a visszakeresés révén tudnak hatékonyan reagálni.
Miért nem elég a memória?
Az ügynökök olyan adatokat is használnak, amelyekkel nem találkoztak a tanítás során. A belső memória vagy a kontextusablak csak a felhasználói munkamenetet kezeli, nem alkalmas nagy teljesítményű, minden releváns adatra kiterjedő keresésre, főleg, ha a lekérdezések száma vagy az adatbázis mérete teljesen új szintet ér el. Ráadásul, ha a visszakereső réteg nem speciális terheléshez készült, három fő problématípus jelentkezik: hiányos eredmények, lassú indexelés, illetve megnő a hibák valószínűsége, ha az infrastruktúra elosztott – például egy lassú másolat az összes párhuzamos lekérdezés válaszidejét növeli, ami egy ügynök számára nem tolerálható.
Az ilyen hibák kiküszöbölésére a Qdrant 1.17-es verziója több újítást is bevezetett, például relevanciaalapú visszacsatolást, amely a lekérdezéseket menet közben pontosítja, valamint egy új, klaszterszintű API-t, ami egységesen felügyeli a teljes rendszert.
Miért nem akarja többé vektoros adatbázisnak hívni magát a Qdrant?
Ma már szinte minden nagy adatbázis támogatja a vektoros adattípust – a nagy felhőszolgáltatóktól a hagyományos relációs rendszerekig. Ezzel a verseny érdemi része nem az adattípus megléte, hanem a visszakeresés minősége. Ezért a Qdrant vezetője szerint a cégük már nem vektoros adatbázist, hanem valódi visszakereső réteget épít az MI-korszak számára. Az adatbázisok elsősorban adatok tárolására valók, míg a keresési minőség valódi kulcsa egy erre specializált motor.
A kisebb cégeknek azt ajánlja: kezdjenek azzal, amit a rendszerükben elérhető, de a specializált megoldás elkerülhetetlen, amikor a skála vagy a keresési minőség igénye ezt kikényszeríti. Ezt erősíti, hogy a Qdrant a Rusttal, egy speciális és energiahatékony programnyelvvel dolgozik, így kiemelkedő teljesítményt tud elérni a fejlesztői közösség támogatásával.
Valódi példák: amikor a hagyományos adatbázis már kevés
Két, Qdrantot használó vállalat is alátámasztja, mennyire fontos a külön keresőréteg. A GlassDollar vállalat, amely nagyvállalatok (például a Siemens) számára segít startupokat értékelni, természetes nyelvi leírások alapján keres a milliós cégadatbázisban. A lekérdezések minden esetben több irányból, párhuzamosan végrehajtott keresésekből állnak, majd ezek eredményeit rangsorolják. Ez az ügynöki lekérdezési minta csak dedikált keresőinfrastruktúrával tartható fenn; a cég az Elasticsearchről állt át Qdrantra, az infrastruktúra költsége 40%-kal csökkent, a kulcsszavas keresés fenntartására már nem volt szükség, a felhasználói elkötelezettség pedig háromszorosára nőtt.
A másik példa a &AI vállalat, amely szabadalmi perekhez fejleszt infrastruktúrát. Andy nevű MI-ügynöke százmillió dokumentum között végez szemantikai keresést. Mivel ügyvédek kizárólag valós dokumentumokra alapozott eredménnyel dolgoznak, a keresés stabilitása és hitelessége az alap. Itt a keresés önálló réteg, amely közvetlenül kapcsolódik a valós adatokhoz, míg az ügynök csupán felhasználói felület.
Mikor érett meg a váltás?
Induláskor elegendő lehet a beépített vektorkeresés, de az áttérés az első igazi, kritikus pontnál elkerülhetetlen. Három jele van annak, hogy váltani kell: a keresési minőség üzleti sikert vagy bukást jelent; a lekérdezési minta összetett, párhuzamos végrehajtást igényel; vagy az adatmennyiség meghaladja a tízmilliós nagyságrendet.
Ilyenkor már nem az a kérdés, kell-e vektorkeresés, hanem az, mennyire átlátható a jelenlegi elosztott rendszer működése, és lépést tud-e tartani a növekvő MI-tevékenységgel. A keresési minőség mindig is kulcskérdés lesz ott, ahol az eredmény üzleti következményekkel jár – ezért önálló, specializált keresőmotor nélkül nem lehet tartós sikert elérni.
