Amit a fel­hasz­ná­ló nem tud sza­vak­ba ön­te­ni

Nem szeretek kutatgatni a vakvilágba, igazi ügyfelek valós problémáin dolgozni számomra sokkal motiválóbb.

A Safeguarding Resource and Support Hub (RSH) küldetése, hogy biztonságosabbá tegye a humanitárius segítségnyújtás világát – mind a rászorulók, mind a területen dolgozó munkatársak számára. Ingyenes, többnyelvű és helyi viszonyokra szabott segédanyagokkal, online képzésekkel, mentorprogramokkal és szakértői tanácsadással segítenek megelőzni és kezelni a szexuális kizsákmányolás, bántalmazás és zaklatás eseteit. Jobb hellyé teszik a világot, tisztelettel és csodálattal figyelem a munkájukat.

A weboldaluk megújítása során az a probléma merült fel, hogy felhasználóik sokszor egészen meglepő módon használják a - hagyományos, kulcsszavas - keresőt. Ez fakad egyrészt abból, hogy sok esetben nem rendelkeznek azokkal az alapvető digitális kompetenciákkal, melyek itt Európában magától értetődőek, másrészt sokszor nincsenek meg a megfelelő szavaik sem abúzus, sem visszaélés és hasonló esetek megnevezésére, körülírására.

Az informatika nyelvén szólva: ki kell egészíteni az eddigi keresőt szemantikus (vektoros) keresővel, egy hibrid megoldást alkalmazva, hogy ne csak kulcsszavak egyezésekor adjon releváns találatot, hanem szinonimákra, vagy akár hosszabb kérdésekre, körülírásokra is. Feltétel volt továbbá, hogy a megoldás működjön arab, urdu és bangla nyelven is.

Hogy működik egy vektoros kereső?

Nagyon leegyszerűsítve: a szövegekből egy sokdimenziós térben egy-egy szakaszt képezünk. (Ami két dimenzióban szakasz, azt hívjuk sokdimenziós térben vektornak, a folyamat neve pedig a beágyazás, angol nevén embedding). Minél közelebb van egymáshoz két ilyen szakasz ebben a térben, annál közelebb áll egymáshoz a szövegek jelentése, amelyekből képeztük őket. Ahhoz hasonlít, mint amikor a könyvtárban téma szerint osztályozzák a könyveket: a hasonló tematikájú könyvek egymáshoz közel, egy polcra kerülnek. Amikor keresünk, a kérdést is egy ilyen szakasszá alakítjuk, és megkeressük a hozzá legközelebb eső szakaszokat, akárcsak a könyveket a megfelelő polcon.

A könyvtári rendszerben az ETO segít kategorizálni a könyveket, meghatározni, mi melyik polcra való. Az informatikában a beágyazást nagy nyelvi modellek segítségével végezzük, ez adja nekünk azt a függvényt, ami a szövegből vektort készít.

Ha már itt tartunk, ejtsünk egy szót arról is, mi az a RAG?

Képzeljük el, hogy szeretnénk megtudni valamit a könyvtárban található könyvekből. Ahelyett, hogy mi keresnénk ki a választ, odamegyünk a könyvtároshoz, és megkérdezzük tőle. Ő leemeli a releváns 5 kötetet a polcról, összefoglalja nekünk a választ a kérdésünkre és megmutatja a könyvekben az erre vonatkozó részeket.

A RAG a Retrieval-Augmented Generation rövidítése, a Retrieval rész, amikor a könyvtáros kiválasztja a számunkra fontos könyveket, az Augmented Generation pedig, amikor ezen könyvek és a saját tudása alapján megfogalmaz számunkra egy választ. A Google is hasonló összefoglalót generál számunkra a kereséseinkkor.

Bár esetünkben erre nem volt igény, a RAG természetes módon illeszthető a vektoros keresés architektúrájára: egy újabb réteget adva hozzá, amelyben a találatok nem csupán megjelennek, hanem értelmezve is lesznek a felhasználó számára.

Hogyan préseljünk bele egy hosszú, akár 50 oldalas, több témát felölelő dokumentumot egyetlen, fix méretű vektorba?

Több módszer létezik, lássuk őket néhány - kisarkított - példán keresztül.

• Csonkolás: csak a szöveg egy fix méretű darabját ágyazzuk be. Gyors megoldás, de képzeljük el, hogy találná meg a felhasználó például az Édes Annát az első fejezete alapján.
• LLM-alapú összegzés: a teljes szövegből keresési célra optimalizált fix méretű összefoglalót készítünk, és ezt az összefoglalót ágyazzuk be. Melyik könyv összefoglalója lehet ez a mondat: "Egy totalitárius jövőbeli társadalomban egy férfi fellázad a rendszer ellen, de elbukik.”
  1984? Szép új világ? Vagy épp a Fahrenheit 451? Ez alapján még bármelyik lehet.
• Mintavétel: a szöveget fix méretű darabokra bontjuk, kiválasztunk belőle néhány darabot, ezeket beágyazzuk és átlagoljuk egyetlen vektorrá. De vegyük például a Wikipédiáról a "Második világháború" szócikket: katonai hadműveletek, gazdasági háttér, politikai szövetségek, holokauszt, kulturális hatás, technológiai fejlesztések, utóhatások. Mindegyik szakasz külön-külön egy sűrű szemantikai mag. Az átlaguk: "valami nagy történelmi esemény". Használhatatlanul általános.

Ezek mindegyike ugyanabból a sebből vérzik: a szemantikai jel elmosódik, nem fejezi ki jól a tartalom egészét vagy épp fontos részleteit. Lehet őket különböző módszerekkel tovább finomítani, de az újabb lépéseket, erőforrást kíván.

Olyan megoldást kerestem, ahol az információ ha nem is teljes egészében, de a lehető legnagyobb mélységében megmarad. Drupalban ez még nem megoldott, így saját megoldást kellett fejleszteni e célra. Az összes dokumentumomat feldaraboltam fix méretű szövegekre, ezekből mind vektort képeztem, és hozzá kapcsoltam őket egy közös “szülőhöz”, ami a dokumentum metaadatait tartalmazza (cím, szerző, stb.).

Amikor a felhasználó beír a keresőbe egy kifejezést, akkor két dolog történik párhuzamosan:

1. A kulcsszavas keresés a megszokott módon fut a dokumentum tartalmára és a metaadatokra – gyors, pontos a szó szerinti egyezésekre.
2. A szemantikus keresés a felhasználó kérdését ugyanabba a vektortérbe ágyazza be, mint amibe a tartalmakat ágyaztuk, és megkeresi azokat a vektorokat, szövegrészeket, amelyek jelentésükben a legközelebb állnak hozzá. Minden ilyen találat szülője bekerül a találati listába, egy olyan pontszámmal együtt, amely a szemantikai egyezés erősségét tükrözi.

Ezután a két találati listát összefésüljük – és itt jön az a pont, ahol a megoldás igazán a projektre szabott lesz. A kulcsszavas és a vektoros találatok súlyozása nem általános képlet kérdése: a tartalmak jellege, a felhasználók keresési szokásai, a projekt célja mind befolyásolja, mi a jó arány. Ha például jogi szövegeket böngészünk, akkor a pontos egyezések sokkal-sokkal relevánsabbak, mintha egy életmód blog tartalmaiban merülnénk el.

A hibrid kereső előnyei:

• A kulcsszavas keresés verhetetlen a szó szerinti egyezésekben, azonosítók és nevek esetén. A vektoros keresés verhetetlen az átfogalmazásokra és a fogalmi egyezésekre. A kettő kombinálása mindkét megközelítés előnyeit egyesíti magában.
• A vektoros keresés a megfelelő modellválasztással átlépi a nyelvi határokat is. Az RSH esetében ez azt jelenti, hogy egy angol nyelvű kérdés külön fordítási lépés nélkül megtalál egy releváns arab, urdu vagy bangla szöveget. A támogatott nyelvek köre a választott beágyazási modelltől függ.
• Ha a vektorba ágyazás szolgáltatása épp nem érhető el, akkor sincs olyan hibaforgatókönyv, amelyben a keresés üres vagy hibás találati listát adna vissza. A kulcsszavas keresés mindig elérhető. A beágyazás pedig megtörténik akkor, amikor a szolgáltatás ismét elérhetővé válik.

Az eredmény meggyőző volt, a keresés gyors, a találatok teljes mértékben relevánsak, a nyelvkezelés a várt módon működik. Ami pedig a legfontosabb: azok sem maradnak majd segítség nélkül, akik nem tudják pontosan, mit keressenek – pedig pont nekik lenne a legnagyobb szükségük rá.

A projekt jelenleg még nem az éles oldalon fut; a mostani publikus RSH weboldal továbbra is a régi keresőt használja.