Hibridinė paieška ir perrikiavimas dirbtinio intelekto pokalbių botams: geresni RAG rezultatai

Svetainių pokalbių botai retai patiria nesėkmę dėl to, kad žinių bazėje visai nėra informacijos. Dažniau atrankos (retrieval) žingsnis neranda ištraukos, kuri atitinka klausimą ir konkretų kontekstą. Lankytojai naudoja produktų pavadinimus, klaidų pranešimus ir straipsnių numerius, tačiau taip pat formuluoja laisvai: „Kodėl pokalbių botas rodo neteisingą tarifą?“ arba „Ar galiu dar pakeisti jau išsiųstą užsakymą?“ Šiam mišiniui nepakanka vien raktinių žodžių ar vien vektorių paieškos kaip universalaus atsakymo. Hibridinė paieška sujungia abu signalus, kad RAG pokalbių botas į savo atsakymo kontekstą gautų patikimesnius šaltinius.

Raktinių žodžių ir vektorių paieška atlieka skirtingas užduotis

Raktinių žodžių paieška yra stipri, kai žodžiai turi sutapti tiksliai. Tai galioja užsakymų numeriams, produktų pavadinimams, konkretiems klaidų pranešimams, sutarčių pavadinimams arba tokioms versijoms kaip „2.4“. Ji gali aiškiai parodyti, kodėl dokumentas tinka: ieškomas žodis yra pavadinime, antraštėje arba ištraukoje. Jos silpnybė pasireiškia kasdienėje kalboje, sinonimuose ir neišsamiose formuluotėse. Lankytojo klausimas apie „sąskaitos kopiją“ nebūtinai ras puslapį, kuriame kalbama tik apie „atsisiųsti kvitą“.

Vektorių paieška užpildo šią spragą. Ji pavaizduoja klausimą ir turinį kaip semantinį artumą, todėl gali rasti panašias užklausas, nors tų pačių sąvokų ir trūksta. Tai padeda natūraliai suformuluotiems palaikymo klausimams, daugiakalbiams variantams ir skirtingiems to paties proceso pavadinimams. Tačiau vien semantinis artumas nėra garantija: ištrauka gali būti panaši į temą, bet liesti kitą produkto versiją, kitą rinką arba pasibaigusią taisyklę. Būtent todėl konteksto tikrinimas priklauso atrankos konvejeriui (pipeline), o ne tik kalbos modeliui.

Kodėl hibridinė paieška yra prasmingas starto taškas

Microsoft apibūdina hibridinę paiešką kaip bendrą užklausą su pilno teksto ir vektorių dalimi. Abi užklausos vykdomos lygiagrečiai, o jų rezultatų sąrašai vėliau sujungiami. Tai patrauklu įmonių svetainėms, nes išsaugomos tikslios sąvokos ir kartu tampa pasiekiamas susijęs, gerai suformuluotas turinys. Pokalbių botas neturi priversti lankytojų rinktis tarp „techninės“ ir „semantinės“ paieškos. Pasirinkimas vyksta fone ir gali būti patikrintas naudojant tą patį kokybės procesą visiems klausimams.

Hibridinė paieška pagerina kandidatų rinkinį; ji nesukuria tiesos. Pokalbių botas gali naudoti tik tą turinį, kuris yra patvirtintas konkrečiai situacijai. Vieši tinklalapiai, vidiniai juodraščiai ir apsaugoti klientų duomenys nepriklauso bendram nekontroliuojamam kontekstui. Taip pat svarbus aiškus elgesys, kai nėra tinkamo šaltinio: papildomas klausimas, nuoroda į kontaktų puslapį arba perdavimas žmogui (Human Handoff) yra saugiau nei sklandžiai suformuluota prielaida.

RRF suprantamai: reitingų sąrašų sujungimas

Pilno teksto ir vektorių paieškos įverčiai (scores) turi skirtingas reikšmes ir skales. Tiesioginis jų sudėjimas arba fiksuotos ribinės vertės išradimas dažnai lemia nestabilius rezultatus. Todėl Reciprocal Rank Fusion, sutrumpintai RRF, dirba su dokumento pozicija kiekviename reitingų sąraše. Dokumentas, kuris abiejuose sąrašuose yra aukštai, gauna stiprų kombinuotą signalą. Dokumentas, kuris matomas tik viename sąraše, taip pat gali būti įvertintas, tačiau neautomatiškai išstumti visa kita.

RRF nėra stebuklinga standartinė vertė ir nėra profesinių testų pakaitalas. Kiek kandidatų iš kiekvienos paieškos patenka į fuziją, kokie filtrai taikomi prieš tai ir kada rezultatas apskritai laikomas naudingu, priklauso nuo turinio ir rizikos. Dažniems klausimams apie produktus gali būti prasmingas mažas, tikslingas langas. Sudėtingoms instrukcijoms ar klaidų diagnostikai gali prireikti daugiau kandidatų. Svarbiausia – palyginti pakeitimą su tikrais klausimais iš bandomojo rinkinio, o ne perimti universalų parametrą iš pavyzdžio.

Semantinis perrikiavimas kaip antrasis, apribotas etapas

Po geros išankstinės atrankos perrikiavimo įrankis (reranker) gali dar kartą įvertinti siauresnį kandidatų rinkinį pagal visą klausimą. Microsoft semantinį reitingavimą apibrėžia kaip antrinį reitingavimą virš jau iš anksto sureitinguoto rezultatų sąrašo. Amazon Bedrock atitinkamai apibūdina perrikiavimą kaip teksto dokumentų atitikimo užklausai įvertinimą. Šis antrasis etapas tinka klausimams su keliomis sąlygomis: pavyzdžiui, ar galimas tarifo keitimas po to, kai užsakymas jau išsiųstas ir galioja tam tikras sutarties tipas.

Perrikiavimas turėtų būti sąmoningai apribotas. Jis reikalauja papildomo vėlinimo (latenčios) ir, priklausomai nuo paslaugos, gali kainuoti. Todėl perrikiavimo įrankiui pateikite ne visą žinių bazę, o tik jau išfiltruotą ir sujungtą geriausių rezultatų rinkinį. Apibrėžkite laiko biudžetą ir atsarginį variantą (fallback). Jei biudžetas viršijamas, pokalbių botas gali, pavyzdžiui, parodyti patikimiausią šaltinių sąrašą, paprašyti patikslinti arba perduoti pokalbį palaikymo komandai. Perrikiavimo įrankis neištaiso pasenusio, trūkstamo ar nepatvirtinto turinio.

Metaduomenų filtrai saugo kontekstą

Metaduomenys dažnai labiau lemia atsakymo kokybę nei dar viena modelio parinktis. Kiekvienam šaltiniui prižiūrėkite bent kalbą, produktą ar paslaugą, versiją, rinką, tikslinę grupę ir galiojimą, jei šie duomenys yra svarbūs naudojimui. Filtravimas pagal teisingą klientą (mandantą) arba teisių sritį turi suveikti prieš išvedimą. Viešoje svetainėje pokalbių botas gali gauti tik viešą turinį; prisijungusioje srityje papildomai galioja patikrinamos teisės.

Laikas taip pat yra metaduomenų klausimas. Kainoraščiai, pristatymo sąlygos ir instrukcijos turėtų turėti aiškią atnaujinimo datą arba kontroliuojamą galiojimo būseną. Jei šaltinis nebėra patikimas, jis turi būti pašalintas iš indekso arba perkeltas į atskirą patikrinimo kelią. Filtrai turi atspindėti lankytojams suprantamus reikalavimus, o ne slapta manipuluoti eiliškumu. Todėl dokumentuokite, kokie filtrai taikomi kuriai klausimų klasei ir kaip komanda tikrina pakeitimus.

Konkretus konvejeris nuo užklausos iki konteksto

1. Normalizuoti klausimą: Atpažinkite kalbą ir akivaizdų kontekstą be bereikalingo asmens duomenų išsaugojimo ar keitimo.
2. Patikrinti prieigą ir metaduomenis: Prieš atranką nustatykite, kurie šaltiniai leidžiami produktui, rinkai, rolei ir galiojimo laikotarpiui.
3. Gauti lygiagrečiai: Atlikite pilno teksto ir vektorių paiešką pagal tą patį leidžiamų šaltinių rinkinį.
4. Sujungti reitingų sąrašus: Sujunkite sąrašus naudodami RRF ir išsaugokite kiekvieno kandidato kilmės signalus derinimo (debugging) tikslais.
5. Apribotai perrikiuoti: Atitikimo įvertinimą atlikite tik su mažu geriausių rezultatų rinkiniu ir matuokite vėlinimą.
6. Apsaugoti kontekstą: Patikrinkite dublikatus, šaltinių būseną ir tinkamą ilgį prieš perduodami ištraukas atsakymo modeliui.
7. Atsakymas su ribomis: Pagrįskite šaltinius, pažymėkite neapibrėžtumą ir, jei reikia, naudokite saugų perdavimą.

Praktinis pavyzdys: siuntimo būsena ir tarifo keitimas

Tarkime, lankytojas paklausia: „Ar galiu dar pakeisti savo tarifą, nors siunta jau pakeliui?“ Raktinių žodžių paieška gali rasti puslapį apie „tarifo keitimą“ ir palaikymo straipsnį su „siunta pakeliui“. Vektorių paieška randa vadovą, kuriame procesas aprašomas kaip keitimas po išsiuntimo. RRF į viršų iškelia dokumentus, kurie sujungia abu aspektus. Perrikiavimo įrankis po to gali patikrinti, ar svarbioje ištraukoje tikrai yra tarifo ir siuntimo derinys.

Prieš atsakydami išfiltruokite pagal atitinkamą rinką, produkto liniją ir esamą galiojimo būseną. Jei šaltiniai prieštaringi arba trūksta reikiamų detalių, pokalbių botas neturėtų daryti išvadų iš panašių atvejų. Jis gali skaidriai pasakyti, kuri sąlyga yra atvira, ir nukreipti lankytoją į tinkamą, patikrintą kontakto galimybę. Taip pokalbis išlieka naudingas, nesukuriant nepagrįsto pažado.

Atvejai be rezultatų ir įverčių derinimas

Rezultato nebuvimas (no-result) dažnai yra žinių spragos, o ne sugedusios paieškos signalas. Todėl skirkite bent keturis atvejus: nėra leidžiamo šaltinio, yra šaltinių, bet nėra pakankamai atitinkančio rezultato, klausimas dviprasmiškas arba techninė klaida trukdo atrankai. Kiekvienam atvejui reikia atskiros, suprantamos reakcijos. „Apie tai patvirtintoje informacijoje nerandu patikimo atsakymo“ yra sąžiningiau nei bendrinis sakinys be kito žingsnio.

Derinimui (debugging) vien galutinių įverčių nepakanka. Kiekvienam bandomajam klausimui komandos turėtų matyti, kokie filtrai suveikė, kokie dokumentai gauti iš raktinių žodžių ir vektorių paieškos, kaip jie buvo sujungti ir ar perrikiavimas pakeitė eiliškumą. Išsaugokite tik kokybei reikalingus, duomenis taupančiu būdu paruoštus duomenis. Išsiaiškinkite šablonus: ar trūksta tam tikrų sinonimų? Ar senas šaltinis užgožia naują turinį? Ar tam tikra kalbos versija (locale) nukrypsta nuo metaduomenų logikos? Tik konkreti priežastis nustato, ar reikia keisti suskirstymą (chunking), metaduomenis, šaltinių priežiūrą ar reitingavimą.

Bandomasis rinkinys, metrikos ir išlaidų biudžetas

Mažas „Auksinis rinkinys“ (Golden Set) iš 30–50 realistiškų klausimų yra gera pradžia. Kiekvienam klausimui nurodykite tikėtinus šaltinius, neleistinus šaltinius ir pageidaujamą reakciją trūkstant žinių. Atskirai matuokite, ar teisingas šaltinis yra tarp kandidatų, ar jis reitinguojamas pakankamai aukštai ir ar galutiniame atsakyme naudojama tik pagrįsta informacija. Sąmoningai papildykite rašybos klaidomis, tiksliomis sąvokomis, natūraliomis formuluotėmis, daugiakalbyste ir kritiniais neigiamais atvejais.

Kiekvieno bandymo metu keiskite tik vieną kintamąjį: filtrą, kandidatų skaičių, perrikiavimo gylį arba teksto gabalų (chunk) struktūrą. Taip pat užsirašykite atsakymo laiką ir išorinių modelio kvietimų skaičių. Didesnė atitikimo vertė gali būti nenaudinga, jei atsakymas ateina per vėlai arba išauga dažnų standartinių klausimų kainos. Todėl apibrėžkite vėlinimo ir išlaidų biudžetą kiekvienai klausimų klasei. Greiti, gerai pagrįsti standartiniai atsakymai ir konservatyvus perdavimas daugeliui svetainių yra vertingesni nei maksimaliai sudėtingas reitingavimas.

Tipiškos klaidos diegiant

• Tiesioginis neapdorotų raktinių žodžių ir vektorių įverčių palyginimas, nors jų skalės nevienodos.
• Juodraščių, senų kainoraščių ar apsaugoto turinio indeksavimas be būsenos ir teisių filtrų.
• Perrikiavimo taikymas per dideliam kandidatų skaičiui, dėl ko nekontroliuojamas vėlinimas ir išlaidos.
• Demonstracijos su keliais gerais klausimais laikymas pakankamu kokybės įrodymu.
• Įtikimo atsakymo generavimas trūkstant šaltinio, vietoj to, kad būtų numatytas neapibrėžtumas, papildomas klausimas arba perdavimas žmogui.
• Šaltinių, suskirstymo (chunking) ir reitingavimo pakeitimų neversijavimas, dėl ko vėliau neįmanoma jų paaiškinti.

Diegimo kontrolinis sąrašas

• Prieš indeksavimą nustatyti leidžiamus šaltinius ir prieigos teisių ribas.
• Prižiūrėti kalbos, produkto, versijos, rinkos ir galiojimo metaduomenis.
• Lygiagrečiai gauti pilno teksto ir vektorių paieškos rezultatus, vėliau juos sujungti naudojant RRF.
• Perrikiavimą naudoti tik mažam, leidžiamam kandidatų rinkiniui.
• Bandomajame rinkinyje įvertinti šaltinių nuorodas, atsakymus be rezultatų ir perdavimą žmogui (Human Handoff).
• Matuoti vėlinimą, išlaidas ir kritinius klaidingus atsakymus po kiekvieno pakeitimo.

Išvada

Hibridinė paieška yra tvirtas starto taškas svetainių pokalbių botams su įvairiomis klausimų formomis. Raktinių žodžių paieška išsaugo tikslius signalus, vektorių paieška atskleidžia panašias užklausas, RRF sujungia jų reitingų sąrašus, o apribotas perrikiavimo įrankis gali pagerinti siauresnę atranką. Tačiau tvarus kokybės pagerėjimas atsiranda dėl sutvarkytų šaltinių, tinkamų metaduomenų, suprantamų testų ir atsakymų logikos, kuri atskleidžia savo ribas. Taip atranka (retrieval) tampa patikrinama, o ne tik techniškai įspūdinga.

Šaltiniai ir papildomos nuorodos

• Microsoft Learn: Hybrid Search
• Microsoft Learn: Relevanz und RRF bei Hybrid Search
• 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