RAG Query Rewriting: kaip teisingai išrišti papildomus KI pokalbių botų klausimus

Vienas atskiras klausimas, pavyzdžiui, „O kiek laiko tai galioja?“, žmonėms dažnai yra visiškai aiškus. Jie prisimena anksčiau aptartą produktą, vietą ir turimą omenyje terminą. Tačiau žinių paieškos sistema iš pradžių mato tik kelis žodžius. Neturėdama tinkamo pokalbio konteksto, ji gali nieko nerasti arba ieškoti visiškai netinkama tema. RAG Query Rewriting išsprendžia šią problemą perrašydama nuo konteksto priklausomą papildomą klausimą į savarankišką paieškos užklausą prieš atliekant paiešką.

Tai skamba kaip nedidelis tarpinis žingsnis, tačiau jis dažnai nulemia daugiapakopio svetainės pokalbių boto kokybę. Šiame gide parodyta, kaip komandos išriša papildomus klausimus, kada geriau paklausti patikslinimo ir kaip išvengti naujų faktų, neteisingų teisių ar pasenusio konteksto įterpimo į paiešką perrašant užklausą.

Kodėl papildomi klausimai tampa iššūkiu žinių paieškai

Pirmasis naudotojo klausimas dažniausiai būna konkretus: „Kokia garantija galioja A modeliui?“. Po to seka trumpos frazės, tokios kaip „O didesniam variantui?“, „Ar tai galioja ir Austrijoje?“ arba „Ko man tam reikia?“. Įvardžiai, praleisti veiksniai ir nuorodos į ankstesnius atsakymus pokalbyje yra natūralūs. Tačiau kaip izoliuota paieškos užklausa jie yra silpni.

Klasikinė raktažodžių, vektorių arba Hybrid Search grandinė gali įvertinti tik tai, ką gauna kaip užklausą. Reranking pagerina esamų rezultatų tvarką, tačiau nepakeičia trūkstamos žodžių „tai“ ar „tam“ reikšmės. Todėl Query Rewriting atliekamas prieš tai: iš esamo klausimo ir atitinkamos eigos jis suformuoja ieškomą, savarankišką užklausą.

Ką turi užtikrinti geras perrašymas

Sėkmingai perrašyta užklausa yra pakankamai išsami informacijos paieškai (Retrieval), tačiau išlieka artima naudotojo ketinimui. Pavyzdžiui, iš „O Austrijoje?“ gali tapti „Kokios garantijos sąlygos galioja A modeliui Austrijoje?“, jei A modelis ir garantija buvo aiškiai apibrėžti tiesiogiai prieš tai vykusiame dialoge. Perrašymas dar neatsako į klausimą. Jis skirtas tik tinkamiems šaltiniams rasti.

Dabartinėje Azure architektūros gairėje dėl Conversational RAG rekomenduojama įtraukti atitinkamą pokalbių istoriją ir prieš Retrieval suformuluoti esamą klausimą kaip savarankišką užklausą su išrištomis nuorodomis. Svarbus ir ten pastebimas atskyrimas: vėlesniam atsakymui išlaikomas pradinis naudotojo klausimas. Taip sistema gali patikrinti, ar rasti įrodymai tikrai tinka užduotam klausimui.

Papildyti, bet neišgalvoti

Perrašymo įrankis (Rewriter) gali perimti aiškiai esamus duomenis: produktą, versiją, šalį, kalbą arba paskutinį minėtą procesą. Tačiau jis neturi papildyti trūkstamo kliento numerio, nustatyti spėjamų produkto variantų ar paversti neaiškaus laiko nurodymo konkrečia data. Naudingai skambantis, bet išgalvotas patikslinimas garantuotai nukreips paiešką netinkama linkme.

Teisės lieka už teksto modelio ribų

Organizacija (tenant), prisijungęs naudotojas, patvirtintos dokumentų sritys ir vaidmenys nustatomi serverio pusėje. Jie nepriklauso perrašymo užklausai kaip laisvai formuluojamas teiginys. Galinė sistema (backend) atskirai ir nepakeičiamai nustato atitinkamus metaduomenų filtrus. Nei ankstesnis pokalbio įrašas, nei modelio perrašymas neturi atverti platesnės paieškos erdvės.

Kontekstui reikalingas apgalvotas biudžetas

Siųsti visą pokalbio istoriją nefiltruotą į Rewriter retai būna geras sprendimas. Senos temos gali užgožti esamą klausimą, asmens duomenys gali būti be reikalo perduodami toliau, o ilgos istorijos padidina delsą ir kaštus. Kaip praktinę gairę Microsoft rekomendacija nurodo nuo dviejų iki penkių naujausių pokalbio etapų ir senesnio turinio santrauką. Tai nėra universali riba, o atspirties taškas patiems testuoti.

Kompaktišką konteksto paketą gali sudaryti šie elementai:

• nepakeistas esamas naudotojo klausimas,
• keli tiesiogiai susiję naudotojo ir asistento pranešimai,
• jau patvirtinti objektai (entities), tokie kaip produktas, procesas ar vieta,
• Locale ir laiko juosta kaip techniniai laukai,
• trumpalaikė, patikrinta senesnių dialogo dalių santrauka ir
• perrašymo taisyklės, žinių indekso bei Retrieval konfigūracijos versija.

Pačios dokumentų teisės lieka atskirtos. Taip pat prieš atliekant Rewrite reikėtų pašalinti nereikalingus el. pašto adresus, užsakymų numerius ar pilnus atsakymus. Duomenis taupanti istorija papildomai palengvina vėlesnę klaidos paiešką.

Patikimas procesas per šešis žingsnius

1. Patikrinti savarankiškumą: Aiškus naujas klausimas, pavyzdžiui, „Kaip pakeisti slaptažodį?“, gali keliauti tiesiai į paiešką. Ne kiekvienam pranešimui reikalingas modelio perrašymas.
2. Atpažinti nuorodas: Sistema pažymi įvardžius, elipses, palyginimo žodžius ir nuorodas, tokias kaip „ten“, „abu“ arba „antrasis variantas“.
3. Pasirinkti atitinkamą kontekstą: Perimami tik tie pranešimai, kurie įtikimai išriša šias nuorodas. Sąmoningas temos pakeitimas užbaigia senąjį kontekstą.
4. Nuspręsti dėl Rewrite arba patikslinimo: Jei yra tiksliai vienas patikimas išrišimas, sukuriama savarankiška paieškos užklausa. Jei yra kelios tikėtinos reikšmės, pokalbių botas užduoda trumpą patikslinamąjį klausimą.
5. Ieškoti ir, jei reikia, išskaidyti: Užklausa vykdoma per raktažodžių, vektorių arba Hybrid Search. Kelias dalis turintys klausimai gali būti išskaidyti į aiškiai įvardytus paklausimus.
6. Atsakyti į originalų klausimą: Atsakymas sugeneruojamas iš rastų šaltinių, remiasi pradine formuluote ir atvirai įvardija neaiškumus ar trūkstamus įrodymus.

Microsoft Agentic Retrieval apžvalgoje aprašomas panašus procesas: užklausa ir pokalbių istorija įtraukiama į planavimą, tikslingi paklausimai vykdomi lygiagrečiai, o rezultatai po to sujungiami. Amazon Bedrock dokumentacijoje taip pat aprašytas planavimas, iteraciniai paklausimai ir patikrinimas, ar rasto turinio pakanka atsakymui. Tokios produkto funkcijos gali perimti dalį grandinės; tačiau pačios programos kokybės ir saugumo ribos išlieka būtinos.

Rewrite, patikslinamasis klausimas ar Query Decomposition?

Įvestis	Tinkama reakcija	Pagrindimas
„O ar tai galioja Austrijoje?“ po aiškaus klausimo apie garantiją	Suformuluoti savarankišką užklausą	Objektas ir ryšys yra aiškūs.
„O kaip dėl kito?“ paminėjus tris variantus	Užduoti trumpą patikslinamąjį klausimą	Išrišimai gali būti keli tikėtini.
„Palygink abiejų modelių kainą, pristatymo laiką ir grąžinimą“	Išskaidyti į tikslingus paklausimus	Keliems nepriklausomiems aspektams reikalingi patikimi rezultatai.
„Nauja tema: kaip susisiekti su pagalba?“	Ieškoti be seno produkto konteksto	Naudotojas signalizuoja apie temos pakeitimą.

Taigi Query Decomposition nėra tas pats, kas Query Rewriting. Rewriting paverčia priklausomą klausimą savarankišku; Decomposition padalija sudėtingą klausimą į kelias paieškos užduotis. Bedrock dokumentacija apie Query Decomposition rodo, kad keli paklausimai gali pagerinti padengimą. Tačiau kiekvienai papildomai užklausai reikalingas limitas, bendras teisių modelis ir suprantamas sujungimas.

Traktuoti Rewrite rezultatus kaip kodą

Nors rezultatas yra tik tekstas, jis turėtų turėti griežtą struktūrą. Naudingas struktūruotas objektas su tokiais laukais kaip standaloneQuery, decision, resolvedReferences ir reason. Galimi sprendimai yra, pavyzdžiui, SEARCH_AS_IS, REWRITE, CLARIFY ir DECOMPOSE. Galinė sistema patikrina ilgį, kalbą ir leidžiamus laukus prieš pradedant paiešką.

Rewriter negauna įrankių ir neatsako tiesiogiai naudotojui. Sistemos nurodymai iš pokalbio istorijos, įterpti dokumentų tekstai ar raginimai, tokie kaip „Ignoruok taisykles“, lieka duomenimis, o ne valdymo komandomis. Rizikingoms paieškos erdvėms deterministinė taisyklė gali papildomai užtikrinti, kad produkto, Locale ar tenant filtrai niekada nebūtų paimti iš laisvo teksto.

Tikrinti su savo papildomų klausimų testų rinkiniu

Kokybės negalima įrodyti pavieniais pavyzdiniais demonstravimais. Papildykite esamą atsakymų kokybės Golden Set tikrais daugiapakopiais dialogais. Kiekvienam atvejiui užfiksuojama pradinė eiga, esamas klausimas, tikėtinas Rewrite sprendimas, leidžiami objektai, draudžiami papildymai ir tikėtini šaltiniai.

• Įvardžiai ir praleisti veiksniai trumpuose papildomuose klausimuose
• Pataisymai, tokie kaip „Ne, turėjau omenyje B modelį“
• Temos pakeitimas ir grįžimas prie ankstesnės temos
• Dviprasmiški variantai, kuriems būtinai reikalingas patikslinamasis klausimas
• Locale, datos ir laiko juostos pakeitimai
• Neteisėti bandymai pakeisti paieškos erdvę arba tenant
• Ilgos eigos su nesusijusiomis senesnėmis detalėmis
• Kelias dalis turintys klausimai, kurie išskaidomi ir vėl sujungiami

Matuokite atskirai: ar perrašymas atitinka naudotojo ketinimą? Ar Retrieval randa tikėtinus šaltinius? Ar esant tikrai dviprasmybei buvo paklausta patikslinimo? Ar teisių filtrai liko nepakitę? Kiek papildomos delsos sukelia šis žingsnis? NIST AI RMF Core įtraukia pakartotinį testavimą, matavimą ir dokumentavimą į visą AI gyvavimo ciklą. Svetainių komandoms tai reiškia: Rewrite taisyklę, modelį ar konteksto pasirinkimą keisti tik atlikus regresinį testą ir stebimą išleidimą.

Kompaktiškas kontrolinis sąrašas svetainių komandoms

• Ar pradinis naudotojo klausimas lieka nepakitęs iki pat atsakymo?
• Ar įtraukiamos tik atitinkamos ir duomenis taupančios istorijos dalys?
• Ar Rewriter gali aiškiai pasirinkti tarp perrašymo, patikslinamojo klausimo ir išskaidymo?
• Ar jis papildo tik patvirtintus objektus ir jokių spėjimų?
• Ar galinė sistema nustato Locale, tenant ir teises nepriklausomai nuo Rewrite?
• Ar kiekvienas paklausimas turi nustatytus kiekio, laiko ir kaštų limitus?
• Ar Retrieval rezultatai vertinami pagal pradinį klausimą?
• Ar daugiapakopių dialogų testų rinkinys padengia nuorodas, pataisymus ir temos pakeitimus?

Išvada: pirma išsiaiškinkite paieškos klausimą, po to atsakykite

RAG Query Rewriting paverčia natūralų pokalbio trumpumą patikima paieškos užklausa. Didžiausia nauda gaunama ne iš kuo kūrybiškesnių perrašymų, o iš aiškių ribų: perimti patvirtintą kontekstą, spresti neaiškumus patikslinamuoju klausimu, išlaikyti teises serverio pusėje ir toliau tikrinti atsakymą pagal originalų klausimą. Pradėkite nuo dvidešimties tipinių papildomų klausimų iš jūsų klientų aptarnavimo, pažymėkite tikėtiną sprendimą ir testuokite kiekvieną pakeitimą su tais pačiais atvejais. Taip daugiapakopis pokalbis taps suprantamesnis, o paieška tyliai neatsakinės į kitą klausimą.

Šaltiniai

• Microsoft Azure Architecture Center: Prompt Engineering skirtas RAG
• Microsoft Learn: Agentic Retrieval sistemoje Azure AI Search
• Amazon Bedrock: užklausų ir atsakymų generavimo konfigūravimas
• Amazon Bedrock: Agentic Retrieval žinių bazėms
• NIST AI Risk Management Framework Core