Hybrid Search ja Reranking AI-chatboteille: paremmat RAG-tulokset

Verkkosivujen chatbotit epäonnistuvat harvoin sen vuoksi, ettei tietopohja sisältäisi lainkaan tietoa. Useammin tiedonhaun eli Retrieval-vaiheen ongelmana on se, ettei se löydä tekstitatetta, joka sopisi tiettyyn kysymykseen ja konkreettiseen kontekstiin. Kävijät käyttävät tuotenimiä, virheilmoituksia ja artikkelinumeroita, mutta muotoilevat asiansa myös vapaamuotoisesti: ”Miksi chatbot näyttää väärän hinnan?” tai ”Voinko vielä muuttaa jo lähetettyä tilausta?” Tälle yhdistelmälle ei pelkkä avainsanahaku tai pelkkä vektorihaku riitä yleisratkaisuksi. Hybrid Search yhdistää molemmat signaalit, jotta RAG-chatbot saa vastauskontekstiinsa luotettavampia lähteitä.

Avainsanahaku ja vektorihaku täyttävät eri tehtäviä

Avainsanahaku on vahvoilla silloin, kun sanojen on esiinnyttävä täsmälleen oikein. Tämä koskee tilausnumeroita, tuotenimiä, konkreettisia virheilmoituksia, sopimusnimikkeitä tai versioita, kuten ”2.4”. Se pystyy osoittamaan läpinäkyvästi, miksi dokumentti täsmää: etsitty sana on otsikossa, väliotsikossa tai tekstikappaleessa. Sen heikkous näkyy arkikielessä, synonyymeissä ja puutteellisissa muotoiluissa. Kävijän kysymys ”kuittikopiosta” ei välttämättä löydä sivua, jossa puhutaan vain ”tositteen lataamisesta”.

Vektorihaku täydentää tätä aukkoa. Se edustaa kysymystä ja sisältöä semanttisena läheisyytenä ja voi siksi löytää samankaltaisia tarpeita, vaikka samat termit puuttuisivat. Tämä auttaa luonnollisesti muotoilluissa tukikysymyksissä, monikielisissä varianteissa ja saman toiminnon eri nimityksissä. Semanttinen läheisyys yksinään ei kuitenkaan ole vapaalippu: tekstitate voi olla aiheltaan samanlainen, mutta koskea eri tuoteversiota, eri markkina-aluetta tai vanhentunutta sääntöä. Juuri siksi kontekstin tarkistus kuuluu Retrieval-putkeen eikä vasta kielimallille.

Miksi Hybrid Search on järkevä lähtökohta

Microsoft kuvailee Hybrid Searchia yhteiskyseksi, jossa on teksti- ja vektoriosa. Molemmat kyselyt ajetaan rinnakkain, ja niiden tuloslistat yhdistetään sen jälkeen. Tämä on houkuttelevaa yritysten verkkosivustoille, koska tarkat termit säilyvät samalla kun asiaan liittyvät, hyvin muotoillut sisällöt tulevat saavutettaviksi. Chatbotin ei tarvitse laittaa kävijöitä valitsemaan ”teknisen” ja ”semanttisen” haun välillä. Valinta tapahtuu taustalla ja se voidaan tarkistaa kaikille kysymyksille samalla laatuprosessilla.

Hybrid Search parantaa ehdokasjoukkoa; se ei luo lopullista totuutta. Chatbot saa käyttää vain sisältöjä, jotka on hyväksytty kyseiseen tilanteeseen. Julkiset verkkosivut, sisäiset luonnokset ja suojatut asiakastiedot eivät kuulu yhteiseen hallitsemattomaan kontekstiin. Yhtä tärkeää on selkeä toiminta silloin, kun sopivaa lähdettä ei ole saatavilla: jatkokysymys, linkki yhteystietosivulle tai yhdistäminen asiakaspalvelijalle (Human Handoff) ovat turvallisempia kuin sujuvasti muotoiltu arvaus.

RRF selitettynä: tuloslistojen yhdistäminen

Teksti- ja vektorihakujen pisteytyksillä (scores) on eri merkitykset ja asteikot. Niiden suora yhteenlaskeminen tai kiinteän kynnysarvon keksiminen niille johtaa usein epävakaisiin tuloksiin. Reciprocal Rank Fusion eli RRF hyödyntää siksi dokumentin sijaintia kummallakin sijoituslistalla. Dokumentti, joka näkyy molempien listojen kärjessä, saa vahvan yhdistetyn signaalin. Dokumentti, joka näkyy vain toisella listalla, voidaan myös ottaa huomioon, mutta se ei syrjäytä automaattisesti kaikkea muuta.

RRF ei ole maaginen vakioarvo eikä korvaava kaava ammatilliselle testaukselle. Se, kuinka monta ehdokasta kumpaankin hakuun otetaan mukaan fuusioon, mitkä suodattimet vaikuttavat ensin ja milloin tulosta pidetään ylipäänsä käyttökelpoisena, riippuu sisällöstä ja riskeistä. Yleisiin tuotekysymyksiin pieni ja tarkennettu ikkuna voi olla järkevä. Monimutkaisiin ohjeisiin tai vianmääritykseen tarvitaan mahdollisesti enemmän ehdokkaita. Olennaista on verrata muutosta aitoihin kysymyksiin testijoukkoa (Test Set) vastaan sen sijaan, että omaksuttaisiin yleismallinen parametri jostain esimerkistä.

Semanttinen Reranking toisena, rajoitettuna vaiheena

Hyvän esivalinnan jälkeen uudelleenjärjestelijä (Reranker) voi arvioida suppeamman ehdokasjoukon uudelleen koko kysymykseen nähden. Microsoft määrittelee semanttisen järjestämisen toissijaiseksi järjestämiseksi jo esijärjestetyn tuloslistan päällä. Amazon Bedrock kuvailee Rerankingia samalla tavalla tekstidokumenttien relevanssin arviointina suhteessa kyselyyn. Tämä toinen vaihe sopii kysymyksiin, joissa on useita ehtoja: esimerkiksi voidaanko liittymätyyppiä vaihtaa sen jälkeen, kun tilaus on jo lähetetty ja kyseessä on tietty sopimustyyppi.

Rerankingia tulee rajoittaa tietoisesti. Se lisää viivettä (latenssia) ja voi palvelusta riippuen olla maksullista. Älä siis syötä koko tietopohjaa Rerankerille, vaan ainoastaan jo suodatettu ja fuusioitu kärkijoukko (Top-set). Määritä aikabudjetti ja varasuunnitelma (fallback). Jos budjetti ylittyy, chatbot voi näyttää vaikkapa luotettavimman lähdelistan, pyytää tarkennusta tai siirtää keskustelun tukitiimille. Reranker ei korjaa vanhentuneita, puuttuvia tai hyväksymättömiä sisältöjä.

Metatietosuodattimet suojaavat kontekstia

Metatiedot ratkaisevat vastausten laadun usein tehokkaammin kuin uusi mallivaihtoehto. Ylläpidä jokaisesta lähteestä vähintään kieltä, tuotetta tai palvelua, versiota, markkina-aluetta, kohderyhmää ja voimassaoloa, sikäli kuin nämä tiedot ovat olennaisia käytön kannalta. Suodattimen oikeaan asiakkuuteen (tenant) tai käyttöoikeusalueeseen on vaikutettava ennen tulostusta. Julkisella verkkosivustolla chatbot voi hakea vain julkista sisältöä; kirjautuneessa osiossa pätevät lisäksi tarkistettavat käyttöoikeudet.

Aika on myös metatietokysymys. Hinnastoissa, toimitusehdoissa ja ohjeissa tulisi olla selkeä päivityspäivämäärä tai hallittu voimassaolostatus. Jos lähde ei ole enää luotettava, se kuuluu poistaa indeksistä tai siirtää erilliseen tarkistuspolkuun. Suodattimien on vastattava käyttäjien ymmärrettäviä vaatimuksia, ei salaa manipuloida järjestystä. Dokumentoi siksi, mitkä suodattimet pätevät mihinkin kysymysluokkaan ja miten tiimi tarkistaa muutokset.

Konkreettinen putki kyselystä kontekstiin

1. Normalisoi kysymys: Tunnista kieli ja ilmeinen konteksti tallentamatta tai muuttamatta henkilötietoja tarpeettomasti.
2. Tarkista pääsy ja metatiedot: Määritä ennen Retrieval-vaihetta, mitkä lähteet ovat sallittuja tuotteen, markkinan, roolin ja voimassaoloajan osalta.
3. Hae rinnakkain: Suorita teksti- ja vektorihaku samaa sallittua lähdejoukkoa vastaan.
4. Yhdistä tuloslistat: Yhdistä listat RRF:llä ja säilytä kunkin ehdokkaan alkuperäissignaalit vianmääritystä (debugging) varten.
5. Rerankkaa rajoitetusti: Suorita relevanssiarviointi vain pienelle kärkijoukolle ja mittaa viive.
6. Varmista konteksti: Tarkista duplikaatit, lähteiden tila ja riittävä pituus ennen kuin kappaleet lähetetään vastausmallille.
7. Vastaa rajoitukset huomioiden: Viittaa lähteisiin, merkitse epävarmuus ja käytä tarvittaessa turvallista siirtoa ihmiselle.

Käytännön esimerkki: Toimitustila ja liittymän vaihto

Oletetaan, että kävijä kysyy: ”Voinko vielä vaihtaa liittymääni, vaikka paketti on jo matkalla?” Avainsanahaku saattaa löytää sivun aiheesta ”vaihda liittymää” ja tukiartikkelin hakusanalla ”paketti matkalla”. Vektorihaku löytää oppaan, jossa prosessia kuvataan muutoksena lähetyksen jälkeen. RRF nostaa kärkeen dokumentteja, jotka yhdistävät molemmat näkökulmat. Reranker voi sen jälkeen tarkistaa, sisältääkö olennainen tekstitate todella sekä liittymän että lähetyksen yhdistelmän.

Ennen vastaamista suodatetaan tulokset kyseessä olevan markkinan, tuotelinjan ja nykyisen voimassaolostatuksen mukaan. Jos lähteet ovat ristiriitaisia tai tarvittavia yksityiskohtia puuttuu, chatbotin ei pitäisi tehdä johtopäätöksiä samankaltaisista tapauksista. Se voi sanoa läpinäkyvästi, mikä ehto on auki, ja ohjata kävijän sopivaan, varmistettuun yhteydenottotapaan. Näin keskustelu pysyy hyödyllisenä ilman, että keksitään luvattomia lupauksia.

No-result-tapaukset ja tulosten vianmääritys

Ei tuloksia (No-result) on usein merkki tietovaateesta tai aukosta tiedossa, ei rikkoutuneesta hausta. Erota siksi toisistaan vähintään neljä tapausta: sallittua lähdettä ei ole, lähteitä on mutta ei riittävän sopivaa osumaa, kysymys on moniselitteinen tai tekninen virhe estää tiedonhaun. Jokainen tapaus tarvitsee oman, ymmärrettävän reaktionsa. ”En löydä tähän luotettavaa vastausta hyväksytyistä tiedoista” on rehellisempi kuin geneerinen lause ilman seuraavaa askelta.

Vianmäärityksessä pelkät lopulliset pisteet (scores) eivät riitä. Jokaisen testikysymyksen kohdalla tiimien pitäisi nähdä, mitkä suodattimet vaikuttivat, mitkä dokumentit tulivat avainsana- ja vektorihakuista, miten ne yhdistettiin ja muuttiko Reranking järjestystä. Tallenna vain laadun kannalta välttämättömät ja tietosuojaa kunnioittaen käsitellyt tiedot. Etsi kaavoja: Puuttuuko tiettyjä synonyymejä? Peittääkö vanha lähde uutta sisältöä? Poikkeaako jokin kieliversio metatietologiikasta? Vasta konkreettinen syy ratkaiseekin, pitääkö muuttaa paloittelua (Chunking), metadataa, lähteiden ylläpitoa vai järjestämistä (Ranking).

Testijoukko, metriikat ja kustannusbudjetti

Pieni Golden Set -testijoukko, jossa on 30–50 realistista kysymystä, on hyvä alku. Määritä jokaiselle kysymykselle oletetut lähteet, kielletyt lähteet ja haluttu reaktio puuttuvan tiedon kohdalla. Mittaa erikseen, onko oikea lähde ehdokkaiden joukossa, sijoittuuko se riittävän korkealle ja käyttääkö lopullinen vastaus vain vahvistettuja tietoja. Täydennä testejä tietoisesti kirjoitusvirheillä, tarkoilla termeillä, luonnollisilla muotoiluilla, monikielisyydellä ja kriittisillä negatiivisilla tapauksilla.

Muuta vain yhtä muuttujaa testiajoa kohden: yhtä suodatinta, ehdokkaiden määrää, Reranking-syvyyttä tai Chunk-rakennetta. Kirjaa ylös myös vastausaika ja ulkoisten mallikutsujen määrä. Korkeampi relevanssiarvo voi olla hyödytön, jos vastaus tulee liian myöhään tai yleisten vakiokysymysten kustannukset nousevat. Määritä siksi viive- ja kustannusbudjetti kysymysluokkakohtaisesti. Nopeat, hyvin perustellut vakiovastaukset ja konservatiiviset siirrot ihmiselle ovat monille verkkosivustoille arvokkaampia kuin mahdollisimman monimutkainen järjestäminen.

Tyypilliset virheet käyttöönotossa

• Raakojen avainsana- ja vektoripisteiden suora vertailu, vaikka niiden asteikot eivät ole samat.
• Luonnosten, vanhojen hinnastojen tai suojattujen sisältöjen indeksointi ilman tila- ja käyttöoikeussuodattimia.
• Rerankingin soveltaminen liian moneen ehdokkaaseen, jolloin viivettä ja kustannuksia ei voida hallita.
• Muutaman hyvän kysymyksen demon pitäminen riittävänä laatuosoituksena.
• Uskottavan vastauksen generointi puuttuvan lähteen kohdalla sen sijaan, että ilmoitettaisiin epävarmuudesta, esitettäisiin jatkokysymys tai siirrettäisiin asia asiakaspalvelijalle.
• Lähde-, Chunking- ja Ranking-muutosten versioinnin laiminlyönti, jolloin niitä ei voida selittää myöhemmin.

Käyttöönoton tarkistuslista

• Määritä sallitut lähteet ja käyttöoikeusrajat ennen indeksointia.
• Ylläpidä metatietoja kielelle, tuotteelle, versiolle, markkinalle ja voimassaololle.
• Hae täysteksti- ja vektorihakua rinnakkain, yhdistä sen jälkeen RRF:llä.
• Käytä Rerankingia vain pienelle, sallitulle ehdokasjoukolle.
• Arvioi lähdelinkit, No-result-vastaukset ja siirrot ihmiselle testijoukossa.
• Mittaa viive, kustannukset ja kriittiset virhevastaukset jokaisen muutoksen kohdalla.

Yhteenveto

Hybrid Search on vankka lähtökohta verkkosivustojen chatboteille, joille esitetään monenlaisia kysymyksiä. Avainsanahaku säilyttää tarkat signaalit, vektorihaku tavoittaa samankaltaiset tarpeet, RRF yhdistää niiden tuloslistat ja rajoitettu Reranker voi parantaa suppeampaa valikoimaa. Kestävä laadunparannus syntyy kuitenkin hoidetuista lähteistä, sopivista metatiedoista, läpinäkyvistä testeistä ja vastauslogiikasta, joka tuotuo rajoituksensa esiin. Näin tiedonhausta tulee tarkistettavaa pelkän teknisen vaikuttavuuden sijaan.

Lähteet ja lisätiedot

• Microsoft Learn: Hybrid Search
• Microsoft Learn: Relevanssi ja RRF Hybrid Searchissa
• Microsoft Learn: Semantic Ranking
• Amazon Bedrock: Reranking
• ChatReact: RAG-Chunking AI-chatboteille
• ChatReact: Vastauslaadun mittaaminen Golden Setillä
• ChatReact: Tietopohjan pitäminen ajan tasalla