RAG Query Rewriting: Követő kérdések helyes feloldása AI-chatbotoknál

Egyetlen olyan kérdés, mint például: „És ez meddig érvényes?”, az emberek számára gyakran egyértelmű. Emlékeznek az előzőleg megbeszélt termékre, a helyszínre és a vonatkozó határidőre. Ezzel szemben egy tudásalapú keresőrendszer kezdetben csak néhány szót lát. A megfelelő beszélgetési kontextus nélkül lehet, hogy egyáltalán nem talál semmit, vagy rossz témára keres rá. A RAG Query Rewriting ezt a problémát úgy oldja meg, hogy a keresés előtt a kontextusfüggő követő kérdést egy önálló keresési lekérdezéssé alakítja át.

Ez apró köztes lépésnek tűnhet, de gyakran ezen múlik a többműködéses weboldal-chatek minősége. Ez az útmutató megmutatja, hogyan oldhatják fel a csapatok a követő kérdéseket, mikor érdemesebb inkább visszakérdezni, és hogyan akadályozható meg, hogy az átfogalmazás új tényeket, hibás jogosultságokat vagy elavult kontextust juttasson a keresésbe.

Miért terhelik túl a követő kérdések a tudáskeresést?

A felhasználó első kérdése többnyire konkrét: „Milyen garancia vonatkozik az A modellre?” Ezt követik a rövid fordulatok, mint például: „És a nagyobb kapcsolatra?”, „Ez Ausztriában is érvényes?” vagy „Mi kell hozzá?”. A névmások, a hiányos alanyok és a korábbi válaszokra való hivatkozások természetesek egy beszélgetésben. Izolált keresési lekérdezésként azonban gyengék.

Egy klasszikus kulcsszó-, vektoros vagy hibrid keresési folyamat csak azt tudja értékelni, amit lekérdezésként kap. A Reranking javítja a meglévő találatok sorrendjét, de nem pótolja a „ez” vagy „hozzá” hiányzó jelentését. A Query Rewriting ezért ez előtt helyezkedik el: az aktuális kérdésből és a releváns előzményekből kereshető, önálló lekérdezést formál.

Mit kell teljesítenie egy jó átfogalmazásnak?

Egy jól sikerült rewrite-lekérdezés elég teljes az információvisszakereséshez (retrieval), de szorosan a felhasználói szándékhoz igazodik. Az „És Ausztriára?” kérdésből például ez válhat: „Milyen garanciális feltételek vonatkoznak az A modellre Ausztriában?”, ha az A modell és a garancia a közvetlenül megelőző párbeszédből egyértelműen rögzített. Az átfogalmazás még nem válaszolja meg a kérdést. Kizárólag arra szolgál, hogy megtalálja a megfelelő forrásokat.

A legfrissebb Azure architektúra-útmutató a Conversational RAG-hoz azt javasolja, hogy vonjuk be a releváns beszélgetési előzményeket, és az aktuális kérdést a retrieval előtt önálló lekérdezésként fogalmazzuk meg feloldott hivatkozásokkal. Fontos az ott is látható elkülönítés: a későbbi válaszadáshoz megmarad az eredeti felhasználói kérdés. Így a rendszer ellenőrizni tudja, hogy a megtalált bizonyítékok valóban illeszkednek-e a feltett kérdéshez.

Kiegészíteni, de nem kitalálni

Egy rewriter átveheti az egyértelműen meglévő adatokat: terméket, verziót, országot, nyelvet vagy a legutóbb említett folyamatot. Nem egészíthet ki azonban hiányzó ügyfélszámot, nem határozhat meg feltételezett termékváltozatot, és nem alakíthat egy bizonytalan időmegjelölést konkrét dátummá. Egy hasznosnak hangzó, de kitalált pontosítás megbízhatóan rossz irányba tereli a keresést.

A jogosultságok a szövegmodellen kívül maradnak

A bérlőt (tenant), a bejelentkezett felhasználót, a engedélyezett dokumentumterületeket és a szerepköröket szerveroldalon határozzák meg. Nem tartoznak szabadon megfogalmazható állításként a rewrite-lekérdezésbe. A backend a hozzá tartozó metaadat-szűrőket külön és megváltoztathatatlanul állítja be. Sem egy korábbi chat-hozzászólás, sem egy modell-átfogalmazás nem nyithat meg nagyobb keresési teret.

A kontextusnak tudatos keretre (budget) van szüksége

A teljes beszélgetési előzmény szűretlen elküldése a rewriternek ritkán jó megoldás. A régi témák elnyomhatják az aktuális kérdést, a személyes adatok feleslegesen továbbítódhatnak, a hosszú előzmények pedig növelik a késleltetést és a költségeket. Gyakorlati iránymutatásként a Microsoft útmutatója két-öt legutóbbi beszélgetési kört és a régebbi tartalmak összefoglalását említi. Ez nem univerzális határérték, hanem kiindulópont a saját teszteléshez.

Egy kompakt kontextuscsomag a következő elemekből állhat:

• a változatlan aktuális felhasználói kérdés,
• néhány közvetlenül releváns felhasználói és asszisztens hozzászólás,
• már megerősített entitások, mint például termék, folyamat vagy helyszín,
• a területi beállítás (locale) és az időzóna mint technikai mezők,
• a régebbi párbeszédrészek rövid életű, ellenőrzött összefoglalása, valamint
• a rewrite-szabály, a tudásindex és a retrieval-konfiguráció verziója.

A tényleges dokumentum-jogosultságok ettől elkülönítve maradnak. Ugyanígy a nem szükséges e-mail címeket, rendelési számokat vagy teljes válaszokat el kell távolítani a rewrite előtt. az adattakarékos előzmények emellett megkönnyítik a későbbi hibakeresést is.

Egy robusztus folyamat hat lépésben

1. Önállóság ellenőrzése: Egy egyértelmű új kérdés, mint például „Hogyan változtassam meg a jelszómat?”, közvetlenül a keresésbe mehet. Nem minden üzenet igényel modell-átfogalmazást.
2. Hivatkozások felismerése: A rendszer megjelöli a névmásokat, az ellipsziseket, az összehasonlító szavakat és az olyan hivatkozásokat, mint „ott”, „mindkettő” vagy „a második lehetőség”.
3. Releváns kontextus kiválasztása: Csak azok a hozzászólások kerülnek átvételre, amelyek ezeket a hivatkozásokat plauzibilisen feloldják. Egy tudatos témaváltás lezárja a régi kontextust.
4. Rewrite vagy visszakérdezés eldöntése: Ha pontosan egy feloldás megalapozott, önálló keresési lekérdezés jön létre. Ha több plauzibilis jelentés létezik, a chatbot feltesz egy rövid tisztázó kérdést.
5. Keresés és adott esetben felbontás: A lekérdezés végigmegy a kulcsszó-, vektoros vagy hibrid keresésen. A többpartíciós kérdések egyértelműen elnevezett alkérdésekre bonthatók.
6. Válaszadás az eredeti kérdésre: A válasz a megtalált forrásokból jön létre, az eredeti megfogalmazásra vonatkozik, és nyíltan megnevezi a bizonytalanságot vagy a hiányzó bizonyítékokat.

A Microsoft áttekintése az Agentic Retrievalről egy hasonló folyamatot ír le: a lekérdezés és a beszélgetési előzmények beépülnek a tervezésbe, a fókuszált alkérdések párhuzamosan futnak, a találatok pedig ezt követően összevonásra kerülnek. Az Amazon Bedrock dokumentációja ugyancsak leírja a tervezést, az iteratív alkérdéseket és annak ellenőrzését, hogy a megtalált tartalmak elegendőek-e a válaszhoz. Az ilyen termékfunkciók átvehetik a pipeline egyes részeit; a saját alkalmazás minőségi és biztonsági korlátai azonban továbbra is szükségesek maradnak.

Rewrite, tisztázó kérdés vagy Query Decomposition?

Bemenet	Megfelelő reakció	Indoklás
„És ez érvényes Ausztriában is?” egy egyértelmű garanciális kérdés után	Önálló lekérdezés megfogalmazása	A tárgy és a hivatkozás egyértelmű.
„Mi van a másikkal?” három említett változat után	Rövid tisztázó kérdés feltevése	Több feloldás is plauzibilis.
„Hasonlítsd össze az árat, a szállítási időt és a visszaküldést mindkét modellnél”	Felbontás fókuszált alkérdésekre	Több független szempont független találatokat igényel.
„Új téma: Hogyan érhetem el az ügyfélszolgálatot?”	Keresés régi termékkontextus nélkül	A felhasználó témaváltást jelez.

A Query Decomposition tehát nem ugyanaz, mint a Query Rewriting. A Rewriting önállóvá tesz egy függő kérdést; a Decomposition egy komplex kérdést több keresési feladatra oszt. A Bedrock dokumentációja a Query Decompositionről megmutatja, hogy a több alkérdezés javíthatja a lefedettséget. Minden további lekérdezéshez szükséges azonban egy limit, egy közös jogosultsági modell és egy nyomon követhető összevonás.

Kezelje a rewrite-kimeneteket úgy, mint a kódot

Még ha az eredmény csak szöveg is, szigorú struktúrával kell rendelkeznie. Célszerű egy strukturált objektumot használni olyan mezőkkel, mint a standaloneQuery, decision, resolvedReferences és reason. A megengedett döntések például a következők: SEARCH_AS_IS, REWRITE, CLARIFY és DECOMPOSE. A backend ellenőrzi a hosszúságot, a nyelvet és az engedélyezett mezőket, mielőtt a keresés elindulna.

A rewriter nem kap eszközöket, és nem válaszol közvetlenül a felhasználónak. A chat-előzményekből származó rendszerutasítások, a beillesztett dokumentumszövegek vagy az olyan felszólítások, mint „Igyd figyelmen kívül a szabályokat”, adatok maradnak, nem vezérlőparancsok. A kockázatos keresési területeknél egy determinisztikus szabály emellett kikényszerítheti, hogy a termék-, locale- vagy bérlőszűrők soha ne származzanak szabad szövegből.

Tesztelés saját követőkérdés-tesztkészlettel

A minőséget nem lehet néhány jól sikerült demóval bizonyítani. Egészítse ki a válaszminőségre vonatkozó meglévő Golden Set-et valódi többkörös párbeszédekkel. Minden esethez rögzíteni kell az eredeti előzményeket, az aktuális kérdést, a várt rewrite-döntést, az engedélyezett entitásokat, a tiltott kiegészítéseket és a várt forrásokat.

• Névmások és hiányzó alanyok a rövid követő kérdésekben
• Javítások, mint például „Nem, a B modellre gondoltam”
• Témaváltás és visszatérés egy korábbi témára
• Kétértelmű változatok, amelyek feltétlenül visszakérdezést igényelnek
• Locale-, dátum- és időzóna-váltások
• Jogosulatlan kísérletek a keresési tér vagy a bérlő megváltoztatására
• Hosszú előzmények irreleváns régebbi részletekkel
• Többpartíciós kérdések, amelyeket felbontanak, majd újra összevonnak

Mérjen külön: Megfelel az átfogalmazás a felhasználói szándéknak? Megtalálja a retrieval a várt forrásokat? Valódi kétértelműség esetén megtörtént a visszakérdezés? Megváltozatlanok maradtak a jogosultsági szűrők? Mennyi többletkésleltetést okoz ez a lépés? A NIST AI RMF Core az ismételt tesztelést, mérést és dokumentálást az egész AI-életciklusba besorolja. A weboldal-csapatok számára ez azt jelenti: a rewrite-szabályt, a modellt vagy a kontextus-kiválasztást csak regressziós teszttel és megfigyelhető bevezetéssel (rollout) szabad módosítani.

Kompakt ellenőrzőlista weboldal-csapatoknak

• Az eredeti felhasználói kérdés változatlanul megmarad a válaszadásig?
• Csak a releváns és adattakarékos előzményrészletek kerülnek bevonásra?
• A rewriter egyértelműen tud választani az átfogalmazás, a visszakérdezés és a felbontás között?
• Kizárólag a megerősített entitásokat egészíti ki, és nem feltételezéseket?
• A backend a területi beállítást (locale), a bérlőt és a jogosultságokat a rewrite-tól függetlenül állítja be?
• Minden alkérdezés fix mennyiségi, idő- és költséglimitekkel rendelkezik?
• A retrieval-találatok az eredeti kérdéshez képest kerülnek értékelésre?
• Egy többkörös párbeszédes tesztkészlet lefedi a hivatkozásokat, a javításokat és a témaváltásokat?

Összegzés: Először a keresési kérdést tisztázza, csak azután válaszoljon

A RAG Query Rewriting a természetes beszélgetési rövidségből megbízható keresési lekérdezést csinál. A legnagyobb haszon nem a lehető legkreatívabb átfogalmazásokból származik, hanem a világos korlátokból: a megerősített kontextus átvétele, a bizonytalanság feloldása visszakérdezéssel, a jogosultságok szerveroldalon tartása és a válasz folyamatos ellenőrzése az eredeti kérdés alapján. Kezdje a támogatási rendszeréből származó húsz tipikus követő kérdéssel, jelölje meg a várt döntést, és teszteljen minden módosítást ugyanezen esetek alapján. Így a többkörös chat érthetőbbé válik anélkül, hogy a keresés csendben egy másik kérdésre válaszolna.

Források

• Microsoft Azure Architecture Center: Prompt Engineering RAG rendszerekhez
• Microsoft Learn: Agentic Retrieval az Azure AI Search-ben
• Amazon Bedrock: Lekérdezések és válaszgenerálás konfigurálása
• Amazon Bedrock: Agentic Retrieval tudásbázisokhoz
• NIST AI Risk Management Framework Core