RAG Query Rewriting: Jatkokysymysten oikea ratkaiseminen tekoälybotissa

Yksittäinen kysymys kuten ”Ja kuinka kauan se on voimassa?” on ihmiselle usein täysin selvä. Hän muistaa aiemmin käsitellyn tuotteen, sijainnin ja tarkoitetun määräajan. Tieto-osio näkee sen sijaan aluksi vain muutaman sanan. Ilman sopivaa keskustelukontekstia se ei välttämättä löydä mitään tai hakee väärästä aiheesta. RAG Query Rewriting ratkaisee tämän ongelman muuntamalla kontekstisidonnaisen jatkokysymyksen itsenäiseksi hakukyselyksi ennen hakuprosessia.

Tämä saattaa kuulostaa pieneltä välivaiheelta, mutta se ratkaisee usein monivaiheisen verkkosivuchatin laadun. Tämä opas näyttää, miten tiimit voivat ratkaista jatkokysymyksiä, milloin kannattaa kysyä tarkennusta ja miten estää uudelleenkirjoitusta syöttämästä hakuun uusia faktoja, vääriä käyttöoikeuksia tai vanhentunutta kontekstia.

Miksi jatkokysymykset ylikuormittavat tietohakua

Käyttäjän ensimmäinen kysymys on yleensä konkreettinen: ”Mikä takuu koskee mallia A?” Sitä seuraavat lyhyet ilaukset kuten ”Entä suurempi versio?”, ”Päteekö tämä myös Itävallassa?” tai ”Mitä tarvitsen sitä varten?”. Pronominit, poisjätetyt subjektit ja viittaukset aiempiin vastauksiin ovat keskustelussa luonnollisia. Eristettynä hakukyselynä ne ovat kuitenkin heikkoja.

Perinteinen avainsana-, vektori- tai Hybrid Search -putki voi arvioida vain sitä, mitä se saa kyselynä. Reranking parantaa olemassa olevien tulosten järjestystä, mutta se ei korvaa sanojen ”se” tai ”sitä varten” puuttuvaa merkitystä. Query Rewriting sijaitsee siksi ennen tätä: se muotoilee nykyisen kysymyksen ja olennaisen historian pohjalta haettavan, itsenäisen kyselyn.

Mitä hyvältä uudelleenkirjoitukselta vaaditaan

Onnistunut Rewrite-kysely on riittävän täydellinen tiedonhakua varten, mutta pysyy silti tiukasti käyttäjän aiotussa tarkoituksessa. Ilmauksesta ”Entä Itävallassa?” voi tulla esimerkiksi ”Mitkä takuuehdot koskevat mallia A Itävallassa?”, jos malli A ja takuu on vahvistettu yksiselitteisesti välittömästi edeltävässä keskustelussa. Uudelleenkirjoitus ei vielä vastaa kysymykseen. Sen ainoa tehtävä on löytää sopivat lähteet.

Nykyinen Azure-arkkitehtuuriohjeistus Conversational RAG -ratkaisuille suosittelee asiaankuuluvan keskusteluhistorian sisällyttämistä ja nykyisen kysymyksen muotoilemista ennen tiedonhakua itsenäiseksi kyselyksi ratkaistuine viittauksineen. Tärkeää on myös ohjeistuksessa näkyvä erottelu: myöhempää vastausta varten säilytetään alkuperäinen käyttäjän kysymys. Näin järjestelmä voi tarkistaa, sopivatko löydetyt lähteet todella esitettyyn kysymykseen.

Täydennä, älä keksi

Uudelleenkirjoittaja (Rewriter) saa ottaa mukaan yksiselitteisesti saatavilla olevat tiedot: tuotteen, version, maan, kielen tai viimeksi mainitun toiminnon. Se ei kuitenkaan saa täydentää puuttuvaa asiakasnumeroa, päättää oletettua tuoteversiota eikä muuttaa epävarmaa aika-arviota konkreettiseksi päivämääräksi. Hyödylliseltä kuulostava, mutta keksitty tarkennus ohjaa haun varmasti väärään suuntaan.

Käyttöoikeudet pidetään tekstimallin ulkopuolella

Tilaaja, kirjautunut käyttäjä, sallitut dokumenttialueet ja roolit määritetään palvelimen puolella. Ne eivät kuulu vapaasti muotoiltavina väittäminä Rewrite-kyselyyn. Taustajärjestelmä asettaa niihin liittyvät metatietosuodattimet erikseen ja muuttumattomasti. Aiempi chat-viesti tai mallin tekemä uudelleenkirjoitus ei saa avata suurempaa hakualuetta.

Konteksti tarvitsee tietoisen budjetin

Koko chat-historian lähettäminen suodattamattomana uudelleenkirjoittajalle on harvoin hyvä ratkaisu. Vanhat aiheet voivat peittää nykyisen kysymyksen, henkilötietoja saattaa siirtyä tarpeettomasti eteenpäin, ja pitkät keskusteluhistoriat kasvattavat viivettä sekä kustannuksia. Käytännön ohjenuorana Microsoftin ohjeistus mainitsee kahdesta viiteen tuoreinta keskustelukierrosta ja yhteenvedon vanhemmasta sisällöstä. Tämä ei ole universaali raja-arvo, vaan lähtökohta omille testeille.

Tiivis kontekstipaketti voi koostua seuraavista osista:

• muuttamaton nykyinen käyttäjän kysymys,
• muutama välittömästi olennainen käyttäjän ja avustajan viesti,
• jo vahvistetut entiteetit, kuten tuote, prosessi tai sijainti,
• Locale ja aikavyöhyke teknisinä kenttinä,
• lyhytkestoinen, tarkistettu yhteenveto vanhemmista keskustelun osista ja
• uudelleenkirjoitussäännön, tieto-indeksin ja hakukonfiguraation versio.

Varsinaiset dokumenttien käyttöoikeudet pidetään tästä erillään. Samoin tarpeettomat sähköpostiosoitteet, tilausnumerot tai kokonaiset vastaukset tulisi poistaa ennen uudelleenkirjoitusta. Tietoja säästävä historia helpottaa lisäksi myöhempää vianmääritystä.

Vankka prosessi kuudessa vaiheessa

1. Tarkista itsenäisyys: Selkeä uusi kysymys kuten ”Miten vaihdan salasanani?” voi mennä suoraan hakuun. Kaikki viestit eivät vaadi mallipohjaista uudelleenkirjoitusta.
2. Tunnista viittaukset: Järjestelmä merkitsee pronominit, ellipsit, vertailusanat ja viittaukset kuten ”siellä”, ”mlemmat” tai ”toinen vaihtoehto”.
3. Valitse olennainen konteksti: Vain ne viestit otetaan mukaan, jotka ratkaisevat nämä viittaukset uskottavasti. Tietoinen aiheenvaihto päättää vanhan kontekstin.
4. Päätä uudelleenkirjoituksesta tai tarkennuksesta: Jos tarkalleen yksi tulkinta on luotettava, muodostetaan itsenäinen hakukysely. Jos mahdollisia merkityksiä on useita, chattibotti esittää lyhyen tarkentavan kysymyksen.
5. Hae ja tarvittaessa jaa osiin: Kysely ajetaan avainsana-, vektori- tai Hybrid Search -haun läpi. Moniosaiset kysymykset voidaan jakaa selkeästi nimettyihin alakysymyksiin.
6. Vastaa alkuperäiseen kysymykseen: Vastaus luodaan löydetyistä lähteistä, se viittaa alkuperäiseen sanamuotoon ja tuo epävarmuuden tai puuttuvat lähteet avoimesti ilmi.

Microsoftin yleiskatsaus Agentic Retrieval -toiminnallisuudesta kuvaa vastaavaa prosessia: kysely ja keskusteluhistoria vaikuttavat suunnitteluun, kohdennetut alakyselyt suoritetaan rinnakkain ja tulokset yhdistetään sen jälkeen. Amazon Bedrock dokumentoi samoin suunnittelun, iteratiiviset alakyselyt ja tarkistuksen siitä, riittävätkö löydetyt sisällöt vastaukseen. Tällaiset tuoteominaisuudet voivat huolehtia putken osista; oman sovelluksen laatu- ja turvagates-tarkistukset ovat silti edelleen tarpeen.

Rewrite, tarkentava kysymys vai Query Decomposition?

n

Syöte	Sopiva reaktio	Perustelu
”Ja päteekö tämä Itävallassa?” selkeän takuukysymyksen jälkeen	Muotoile itsenäinen kysely	Aihe ja viite ovat yksiselitteisiä.
”Entä se toinen?” kolmen mainitun version jälkeen	Esitä lyhyt tarkentava kysymys	Useat tulkinnat ovat mahdollisia.
”Vertaa hintaa, toimitusaikaa ja palautusta molemmille malleille”	Jaa kohdennettuihin alakyselyihin	Useat riippumattomat näkökulmat vaativat luotettavia tuloksia.
”Uusi aihe: Miten tavoitan tuen?”	Hae ilman vanhaa tuotekontekstia	Käyttäjä ilmaisee aiheen vaihtuvan.

Query Decomposition ei siis ole sama asia kuin Query Rewriting. Rewriting tekee riippuvaisesta kysymyksestä itsenäisen; Decomposition jakaa monimutkaisen kysymyksen useiksi hakutehtäviksi. Bedrock-dokumentaatio Query Decomposition -toiminnosta osoittaa, että useat alakyselyt voivat parantaa kattavuutta. Jokainen lisäkysely vaatii kuitenkin rajoituksen, yhteisen käyttöoikeusmallin ja läpinäkyvän yhdistämisen.

Kohtele Rewrite-tulosteita kuten koodia

Vaikka tulos on vain tekstiä, sillä tulisi olla tiukka sopimus (contract). Järkevä ratkaisu on rakenteinen objekti, jossa on kentät kuten standaloneQuery, decision, resolvedReferences ja reason. Sallittuja päätöksiä ovat esimerkiksi SEARCH_AS_IS, REWRITE, CLARIFY ja DECOMPOSE. Taustajärjestelmä validoi pituuden, kielen ja sallitut kentät ennen haun käynnistämistä.

Uudelleenkirjoittaja ei saa työkaluja eikä vastaa suoraan käyttäjälle. Keskusteluhistoriasta tulevat järjestelmäohjeet, upotetut dokumenttitekstit tai kehotukset kuten ”Ota säännöt pois käytöstä” pysyvät datana, eivät ohjauskomentoina. Risdialttiita hakualueita varten deterministinen sääntö voi lisäksi pakottaa sen, että tuote-, Locale- tai tilaajasuodattimet eivät koskaan ole peräisin vapaasta tekstistä.

Testaa omalla jatkokysymysten testisetillä

Laatua ei voi osoittaa yksittäisillä onnistuneilla demoilla. Täydennä olemassa olevaa vastauslaadun Golden Setiä aidoilla monivaiheisilla keskusteluilla. Jokaisesta tapauksesta tallennetaan alkuperäinen historia, nykyinen kysymys, odotettu Rewrite-päätös, sallitut entiteetit, kielletyt täydennykset ja odotetut lähteet.

• Pronominit ja poisjätetyt subjektit lyhyissä jatkokysymyksissä
• Korjaukset kuten ”Ei, tarkoitin mallia B”
• Aiheen vaihdot ja paluu aiempaan aiheeseen
• Monitulkintaiset versiot, jotka vaativat ehdottomasti tarkennusta
• Locale-, päivämäärä- ja aikavyöhykemuutokset
• Luvattomat yritykset vaihtaa hakualuetta tai tilaajaa
• Pitkät keskusteluhistoriat epäolennaisilla vanhoilla yksityiskohdilla
• Moniosaiset kysymykset, jotka jaetaan ja yhdistetään uudelleen

Mittaa erikseen: Vastaako uudelleenkirjoitus käyttäjän tarkoitusta? Löytääkö haku odotetut lähteet? Kysyttiinkö tarkennusta todellisen monitulkintaisuuden kohdalla? Pysyivätkö käyttöoikeussuodattimet muuttumattomina? Kuinka paljon lisäviivettä vaihe aiheuttaa? NIST AI RMF Core sijoittaa toistuvan testauksen, mittaamisen ja dokumentoinnin osaksi tekoälyn koko elinkaarta. Verkkosivutiimeille tämä tarkoittaa: muuta Rewrite-sääntöä, mallia tai kontekstivalintaa vain regressiotestin ja valvotun julkaisun kautta.

Tiivis muistilista verkkosivutiimeille

• Säilyykö alkuperäinen käyttäjän kysymys muuttumattomana vastaukseen asti?
• Otetaanko mukaan vain olennaiset ja tietoja säästävät historian osat?
• Voiko rewriter valita selkeästi uudelleenkirjoituksen, tarkennuksen ja osiin jaon välillä?
• Täydentääkö se ainoastaan vahvistettuja entiteettejä eikä oletuksia?
• Asettaako taustajärjestelmä Localen, tilaajan ja käyttöoikeudet riippumattomasti uudelleenkirjoituksesta?
• Onko jokaisella alakyselyllä kiinteät määrä-, aika- ja kustannusrajat?
• Arvioidaanko hakutulokset alkuperäistä kysymystä vasten?
• Kattaako monivaiheisen keskustelun testisetti viittaukset, korjaukset ja aiheenvaihdot?

Yhteenveto: Selvitä ensin hakukysymys, vastaa vasta sitten

RAG Query Rewriting tekee luonnollisesta, tiiviistä keskustelusta luotettavan hakukyselyn. Suurin hyöty ei synny mahdollisimman luovista uudelleenkirjoituksista, vaan selkeistä rajoista: ota vahvistettu konteksti mukaan, ratkaise epävarmuus tarkentavalla kysymyksellä, pidä käyttöoikeudet palvelimen puolella ja arvioi vastausta edelleen alkuperäisen kysymyksen perusteella. Aloita kahdestakymmenestä tyypillisestä jatkokysymyksestä tukipalvelustasi, merkitse odotettu päätös ja testaa jokainen muutos samoja tapauksia vasten. Näin monivaiheisesta chatista tulee ymmärrettävämpi ilman, että haku vastaa hiljaisesti täysin toiseen kysymykseen.

Lähteet

• Microsoft Azure Architecture Center: Prompt Engineering for RAG
• Microsoft Learn: Agentic Retrieval in Azure AI Search
• Amazon Bedrock: Configure query and response generation
• Amazon Bedrock: Agentic Retrieval for knowledge bases
• NIST AI Risk Management Framework Core