Hibrid keresés és reranking AI-chatbotokhoz: jobb RAG-találatok

A weboldali chatbotok ritkán akadnak el amiatt, mert a tudásbázis egyáltalán nem tartalmaz információt. Gyakoribb, hogy az információ-visszakeresési (retrieval) lépés nem találja meg azt a szakaszt, amely illeszkedik a kérdéshez és a konkrét kontextushoz. A látogatók termékneveket, hibaüzeneteket és cikkszámokat használnak, de ugyanígy szabadon is fogalmaznak: „Miért a rossz tarifát mutatja a chatbot?” vagy „Módosíthatom még a már elküldött rendelést?” Ehhez a keverékhez sem a tisztán kulcsszavas, sem a tisztán vektoros keresés nem elegendő általános válaszként. A Hybrid Search mindkét jelet összekapcsolja, hogy a RAG-chatbot megbízhatóbb forrásokat kapjon a válaszadási kontextusába.

A kulcsszavas és a vektoros keresés eltérő feladatokat lát el

A kulcsszavas keresés akkor erős, ha a szavaknak pontosan kell szerepelniük. Ez érvényes a rendelési számokra, termékmegnevezésekre, konkrét hibaüzenetekre, szerződésnevekre vagy olyan verziókra, mint a „2.4”. Érthetően meg tudja mutatni, miért illeszkedik egy dokumentum: a keresett szó szerepel a címben, egy címsorban vagy a szakaszban. Gyengesége a mindennapi nyelvben, a szinonimákban és a hiányos megfogalmazásokban mutatkozik meg. Egy látogatói kérdés a „számlamásolatra” vonatkozóan nem feltétlenül talál meg egy olyan oldalt, amely csak a „bizonylat letöltése” kifejezést használja.

A vektoros keresés ezt a hiányt pótolja. A kérdést és a tartalmat szemantikai közelségként ábrázolja, ezért képes hasonló szándékokat találni, még akkor is, ha ugyanazok a kifejezések hiányoznak. Ez segít a természetesen megfogalmazott ügyfélszolgálati kérdéseknél, a többnyelvű változatoknál és az ugyanarra a folyamatra használt eltérő megnevezéseknél. A szemantikai közelség önmagában azonban nem jelent szabadkártyát: egy szakasz lehet hasonló a témához, de vonatkozhat egy másik termékverzióra, egy másik piacra vagy egy lejárt szabályra. Pontosan ezért tartozik a kontextusellenőrzés a retrieval-folyamatba, és nem csak a nyelvi modellhez.

Miért ésszerű kiindulópont a hibrid keresés

A Microsoft a hibrid keresést olyan közös lekérdezésként írja le, amely teljes szöveges és vektoros részből áll. Mindkét lekérdezés párhuzamosan fut, és az eredménylistáikat ezt követően egyesítik. Ez vonzó a vállalati weboldalak számára, mivel a pontos kifejezések megmaradnak, és ezzel egyidejűleg a kapcsolódó, jól megfogalmazott tartalmak is elérhetővé válnak. A chatbotnak nem kell választás elé állítania a látogatókat a „technikai” és a „szemantikai” keresés között. A kiválasztás a háttérben történik, és minden kérdésnél ugyanazzal a minőségi folyamattal ellenőrizhető.

A Hybrid Search javítja a jelöltek halmazát; de nem hoz létre igazságot. A chatbot csak olyan tartalmakat használhat, amelyek az adott helyzetben engedélyezve vannak. A nyilvános weboldalak, a belső piszkozatok és a védett ügyféladatok nem tartozhatnak egy közös, ellenőrizetlen kontextusba. Ugyanilyen fontos a világos viselkedés, ha nem áll rendelkezésre megfelelő forrás: a visszakérdezés, a kapcsolati oldalra mutató hivatkozás vagy a Human Handoff biztonságosabb, mint egy folyékonyan megfogalmazott feltételezés.

RRF érthetően: rangsorok egyesítése

A teljes szöveges és a vektoros keresésből származó pontszámok (score-ok) eltérő jelentéssel és skálával rendelkeznek. Ezek közvetlen összeadása vagy egy fix határérték kitalálása gyakran instabil eredményekhez vezet. A Reciprocal Rank Fusion, röviden RRF, ezért a dokumentum egyes rangsorokban elfoglalt pozíciójával dolgozik. Egy dokumentum, amely mindkét listán elöl szerepel, erős kombinált jelet kap. Egy olyan dokumentum, amely csak az egyik listán látható, szintén figyelembe vehető, de nem szorít ki automatikusan minden mást.

Az RRF nem egy mágikus alapértelmezett érték, és nem helyettesítő képlet a szakmai tesztekre. Az, hogy az egyes keresésekből hány jelölt kerül a fúzióba, milyen szűrők lépnek életbe előtte, és mikor számít egy eredmény egyáltalán használhatónak, a tartalomtól és a kockázattól függ. Gyakori termékkérdések esetén egy kicsi, fókuszált ablak lehet ésszerű. Összetett útmutatókhoz vagy hibadiagnosztikához esetleg több jelöltre van szükség. A döntő az, hogy a változtatást valódi kérdésekkel hasonlítsuk össze egy tesztkészleten, ahelyett hogy átvennénk egy univerzális paramétert egy példából.

Szemantikus reranking mint második, korlátozott szint

Egy jó előválogatás után a reranker a szűkebb jelölthalmazt ismét értékelheti a teljes kérdéshez viszonyítva. A Microsoft a szemantikus rangsorolást másodlagos rangsorolásként határozza meg egy már előre rangsorolt eredményletöltés felett. Az Amazon Bedrock ennek megfelelően írja le a rerankinget, mint a szöveges dokumentumok relevanciájának értékelését a lekérdezéshez. Ez a második szint több feltételt tartalmazó kérdésekhez alkalmas: például hogy lehetséges-e a tarifaváltás, miután a rendelést már elküldték, és egy bizonyos szerződéstípus áll fenn.

A rerankinget tudatosan korlátozni kell. További latenciával jár, és a szolgáltatástól függően költségköteles lehet. Ezért ne adja át a teljes tudásbázist egy rerankernek, hanem csak a már megszűrt és egyesített legjobb halmazt. Határozzon meg egy időkeretet és egy tartalék megoldást (fallback). Ha az időkeretet túllépik, a chatbot megmutathatja például a legmegbízhatóbb forráslistát, pontosítást kérhet, vagy átadhatja a beszélgetést egy ügyfélszolgálati csapatnak. A reranker nem javítja ki az elavult, hiányzó vagy nem engedélyezett tartalmakat.

A metaadatszűrők védik a kontextust

A metaadatok gyakran lényegesebben döntik el a válaszminőséget, mint egy újabb modellopció. Ápolja forrásonként legalább a nyelvet, a terméket vagy szolgáltatást, a verzióállapotot, a piacot, a célcsoportot és az érvényességet, amennyiben ezek az adatok relevánsak a használathoz. A megfelelő ügyfél- vagy jogosultsági területre vonatkozó szűrőnek a kiadás előtt kell életbe lépnie. Egy nyilvános weboldalnál a chatbot csak nyilvános tartalmakat érhet el; egy bejelentkezett területnél emellett ellenőrizhető jogosultságok érvényesek.

Az idő is metaadatkérdés. Az árlistáknak, szállítási feltételeknek és útmutatóknak világos frissítési dátummal vagy ellenőrzött érvényességi státusszal kell rendelkezniük. Ha a forrás már nem megbízható, ki kell venni az indexből, vagy egy külön ellenőrzési útvonalra kell helyezni. A szűrőknek a látogatók számára érthető követelményeket kell leképezniük, nem pedig titokban manipulálniuk a sorrendet. Ezért dokumentálja, hogy mely szűrők mely kérdésosztályokra érvényesek, és hogyan ellenőrzi a csapat a változtatásokat.

Egy konkrét folyamat (pipeline) a lekérdezéstől a kontextusig

1. Kérdés normalizálása: Ismerje fel a nyelvet és a nyilvánvaló kontextust, anélkül hogy a személyes adatokat feleslegesen tárolná vagy módosítaná.
2. Hozzáférés és metaadatok ellenőrzése: A retrieval előtt határozza meg, hogy mely források engedélyezettek a termék, a piac, a szerepkör és az érvényességi időszak alapján.
3. Párhuzamos lekérés: Hajtsa végre a teljes szöveges és a vektoros keresést ugyanarra az engedélyezett forráshalmazra.
4. Rangsorok egyesítése: Kombinálja a listákat RRF-fel, és jelöltenként őrizze meg a származási jeleket a hibakereséshez (debugging).
5. Korlátozott reranking: A relevanciaértékelést csak a kis top-halmazon hajtsa végre, és mérje a latenciát.
6. Kontextus biztosítása: Ellenőrizze a duplikációkat, a forrásstátuszt és a megfelelő terjedelmet, mielőtt a szakaszok a válaszmodellhez kerülnének.
7. Válasz korlátokkal: Támassza alá forrásokkal, jelölje a bizonytalanságot, és szükség esetén használjon biztonságos átadást.

Gyakorlati példa: szállítási státusz és tarifaváltás

Tételezzük fel, hogy egy látogató megkérdezi: „Módosíthatom még a tarifámat, annak ellenére, hogy a csomag már úton van?” A kulcsszavas keresés esetleg talál egy oldalt a „tarifamódosításról” és egy ügyfélszolgálati cikket a „csomag úton van” témában. A vektoros keresés talál egy útmutatót, amely a folyamatot a feladás utáni módosításként írja le. Az RRF azokat a dokumentumokat hozza előre, amelyek mindkét szempontot összekapcsolják. Egy reranker ezután ellenőrizheti, hogy a releváns szakasz valóban tartalmazza-e a tarifa és a szállítás kombinációját.

A válaszadás előtt szűrjön az érintett piacra, a termékvonalra és az aktuális érvényességi státuszra. Ha a források ellentmondásosak vagy hiányoznak a szükséges részletek, a chatbot nem vonhat le következtetést hasonló esetekből. Átláthatóan megmondhatja, melyik feltétel nyitott, és a látogatót egy megfelelő, ellenőrzött kapcsolattartási lehetőséghez irányíthatja. Így a beszélgetés hasznos marad, anélkül hogy megalapozatlan ígéretet találna ki.

No-result esetek és score-debugging

A No-result gyakran tudáshiányra utaló jel, nem pedig a hibás keresésre. Ezért különböztessen meg legalább négy esetet: nincs engedélyezett forrás, vannak források, de nincs megfelelően illeszkedő találat, a kérdés kétértelmű, vagy technikai hiba akadályozza a retrieval-t. Minden esetnek saját, érthető reakcióra van szüksége. „Ezt illetően az engedélyezett információkban nem találok megbízható választ” őszintébb, mint egy általános mondat következő lépés nélkül.

A hibakereséshez a végső pontszámok önmagukban nem elegendőek. Tesztkérdésenként a csapatoknak látniuk kellene, hogy mely szűrők léptek életbe, mely dokumentumok származtak a kulcsszavas és a vektoros keresésből, hogyan egyesítették őket, és hogy a reranking módosította-e a sorrendet. Ennek során csak a minőséghez szükséges, adatminimizáltan előkészített adatokat tárolja. Keressen mintákat: hiányoznak bizonyos szinonimák? Egy régi forrás felülírja az új tartalmakat? Egy locale kilép a metaadat-logikából? Csak a konkrét ok dönt arról, hogy a chunkingot, a metaadatokat, a forrásgondozást vagy a rangsorolást kell-e módosítani.

Tesztkészlet, metrikák és költségkeret

Egy 30–50 realisztikus kérdésből álló kis Golden Set jó kezdet. Rögzítse kérdésenként az elvárt forrásokat, a nem megengedett forrásokat és a kívánt reakciót hiányzó tudás esetén. Mérje külön, hogy a helyes forrás a jelöltek között van-e, elég magasan szerepel-e a rangsorban, és hogy a végleges válasz csak alátámasztott információkat használ-e. Tudatosan egészítse ki gépelési hibákkal, pontos kifejezésekkel, természetes megfogalmazásokkal, többnyelvűséggel és kritikus negatív esetekkel.

Tesztfutamonként csak egy változót módosítson: egy szűrőt, a jelöltek számát, a reranking-mélységet vagy a chunk-szerkezetet. Emellett jegyezze fel a válaszidőt és a külső modellhívások számát. A magasabb relevanciaérték használhatatlan lehet, ha a válasz túl későn érkezik, vagy a gyakori standard kérdések költségei emelkednek. Ezért határozzon meg egy latencia- és költségkeretet kérdésosztályonként. A gyors, jól alátámasztott standard válaszok és a konzervatív átadások sok weboldal számára értékesebbek, mint egy maximálisan összetett rangsorolás.

Jellemző hibák a bevezetés során

• A nyers kulcsszavas és vektoros score-ok közvetlen összehasonlítása, bár a skáláik nem egyformák.
• Piszkozatok, régi árlisták vagy védett tartalmak indexelése státusz- és jogosultsági szűrők nélkül.
• A reranking alkalmazása túl sok jelöltre, ezáltal a latencia és a költségek ellenőrzésének elvesztése.
• Egy néhány jó kérdésből álló demó elégséges minőségi bizonyítékként való kezelése.
• Hiányzó forrás esetén egy plauzibilis válasz generálása a bizonytalanság, visszakérdezés vagy handoff biztosítása helyett.
• A források, a chunking és a rangsorolás változtatásai verziókövetésének elmaradása, ami miatt azok később nem magyarázhatók meg.

Bevezetési ellenőrzőlista

• Az engedélyezett források és jogosultsági határok rögzítése az indexelés előtt.
• A nyelv, termék, verzió, piac és érvényesség metaadatainak karbantartása.
• A teljes szöveges és a vektoros keresés párhuzamos lekérése, majd egyesítése RRF segítségével.
• A reranking alkalmazása csak egy kis, engedélyezett jelölthalmazra.
• A forráshivatkozások, a No-result válaszok és a Human Handoff értékelése a tesztkészletben.
• A latencia, a költségek és a kritikus hibás válaszok mérése változtatásonként.

Összegzés

A Hybrid Search robusztus kiindulópont a különböző kérdésformákkal rendelkező weboldali chatbotok számára. A kulcsszavas keresés megőrzi a pontos jeleket, a vektoros keresés feltárja a hasonló szándékokat, az RRF összekapcsolja a rangsoraikat, és egy korlátozott reranker javíthatja a szűkebb választékot. A fenntartható minőségnövekedés azonban a gondozott forrásokból, a megfelelő metaadatokból, az érthető tesztekből és egy olyan válaszlogikából adódik, amely nyíltan vállalja a korlátait. Így a retrieval ellenőrizhetővé válik, ahelyett hogy csak technikailag lenne lenyűgöző.

Források és további tudnivalók

• Microsoft Learn: Hybrid Search
• Microsoft Learn: Relevancia és RRF a Hybrid Search esetében
• Microsoft Learn: Semantic Ranking
• Amazon Bedrock: Reranking
• ChatReact: RAG-Chunking für KI-Chatbots
• ChatReact: Antwortqualität mit Golden Set testen
• ChatReact: Wissensbasis aktuell halten