RAG-paloittelu tekoäly-chatboteille: Sisällön järkevä jakaminen

Verkkosivuston chatbot voi vastata luotettavasti vain silloin, kun se löytää oikealla hetkellä sopivan sisällön. Juuri tässä RAG-paloittelu (chunking) ratkaisee: pitkät sivut, käsikirjat ja ohjetekstit jaetaan pienempiin yksiköihin, joita hakukomponentti voi hakea täsmällisesti. Liian suuret lohkot sisältävät paljon epäolennaista asiaa. Liian pienet lohkot menettävät asiayhteyden. Hyvä jakaminen ei siksi seuraa sokeasti jotain tiettyä lukua, vaan sisällön rakennetta, merkitystä ja myöhempää käyttöä.

Tämä opas on suunnattu verkkosivusto-, tuki- ja sisältötiimeille. Se selittää, miten jaat sisällöt semanttisesti, säilytät metastat, vähennät päällekkäisyyksiä ja varmistat realistisilla hakukysymyksillä, toimiiko valittu strategia. Lähestymistapa on toimittajarippumaton, ja sitä voidaan soveltaa niin perinteiseen vektorihakuun kuin hybridimallisiin hakumenetelmiin (retrieval).

Miksi RAG-paloittelu määrittää vastausten laatua

RAG-järjestelmässä (Retrieval-Augmented Generation) järjestelmä hakee ensin asiaankuuluvat tietopalat ja välittää ne sen jälkeen kielimallille. Palojen (chunk) rajat määrittävät siten sen, mitä ylipäänsä voidaan löytää yhdessä ja käyttää kontekstina. Jos hintaehto erotetaan sen poikkeuksesta, muodollisesti oikea haku voi silti tarjota puutteellisen pohjan. Jos pala taas sisältää kokonaisen tuotesivun navigaatioineen, muunnelmineen ja alatunnisteineen, ratkaiseva kohta joutuu kilpailemaan suuren kohinamäärän kanssa.

Paloittelu vaikuttaa useaan laatu-ulottuvuuteen samanaikaisesti:

• Löydettävyys: Sopiko haettu väite selkeästi tiiviiseen yksikköön?
• Asiayhteys: Pysyvätkö otsikko, selitys, rajoitus ja esimerkki yhdessä?
• Tarkkuus: Sisältääkö osuma mahdollisimman vähän aiheen vierestä olevaa painolastia?
• Jäljitettävyys: Voidaanko katkelma yhdistää voimassa olevaan lähteeseen, kieleen ja versioon?

Microsoft kuvailee kiinteitä, muuttuvia ja semanttisia menetelmiä ja korostaa, että otsikoita sekä muita muotoiluvihjeitä voidaan hyödyntää järkevien rajojen luomiseen. Myös AWS erottelee kiinteät, hierarkkiset ja semanttiset strategiat. Yhteinen käytännön oppi: teknisen jaon tulisi seurata sisällöllistä jaksotusta aina, kun sellainen on luotettavasti saatavilla.

Aloita semanttisista osioista mielivaltaisten leikkausten sijaan

Hyvä lähtökohta on sivun olemassa oleva rakenne. H2- ja H3-otsikot, kappaleet, luettelot, FAQ-kysymykset, taulukot ja selkeästi erotetut huomautukset kantavat jo merkitystä. Palautusrajoja käsittelevän osion ei pitäisi päättyä keskellä lausetta tai säännön ja poikkeuksen välissä. FAQ-kysymys kuuluvat vastauksineen samaan palaan. Ohjeissa toimintavaiheen, edellytyksen ja varoituksen tulee pysyä mahdollisuuksien mukaan yhdessä.

Käytännön rajalogiikka

1. Jakaa ensin dokumentti-, sivu- ja pääotsikoiden kohdalta.
2. Tarkista, käsitteleekö osio täsmälleen yhtä ymmärrettävää pääaihetta.
3. Paloittele vain ne osiot, jotka ovat liian suuria hakua tai mallin kontekstia varten.
4. Yhdistä erittäin lyhyet pirstaleet sopivaan viereiseen osioon.
5. Liitä otsikko ja rakennepolku kontekstiksi jokaiseen osaan.

Siistissä HTML- tai Markdown-muodossa tämä menetelmä on helppo automatisoida. Strukturoimattomat PDF-tiedostot, epäyhtenäiset viennit ja skannatut asiakirjat vaativat usein esikäsittelynä asettelu- tai tekstintunnistusta. Tarkista tällöin erityisesti taulukot, sarakkeet, alatunnisteet ja sivunvaihdot: se, mikä on visuaalisesti vierekkäin, voi päätyä tekstinlukuun väärässä järjestyksessä.

Käsittele palakokoa testiarvona, älä dogmina

Yhtä yleispätevää ihanteellista palakokoa ei ole olemasassa. Microsoft mainitsee 512 tokenia 25 prosentin limityksellä mahdollisena aloitustehtävänä tietyissä skenaarioissa, mutta huomauttaa, että optimaalinen asetus riippuu sisällöstä ja mallista. Myös AWS dokumentoi määritettävissä olevia kokoja ja limityksiä. Tällaiset arvot ovat hyviä lähtöhypoteeseja – eivät laatuosoitus.

Lyhyet FAQ-vastaukset toimivat usein itsenäisinä yksiköinä. Yksityiskohtaiset toimintaohjeet vaativat enemmän kontekstia. Oikeudelliset tai sopimukselliset tekstit eivät saa erottaa sääntöä, soveltamisalaa ja poikkeusta toisistaan. Tuotevertailut puolestaan voivat olla järkeviä riveittäin tai osioittain, kunhan sarakeotsikot ja tuotesidos kulkevat mukana.

Mistä tunnistat liian suuret tai liian pienet palat

Pala on tyypillisesti liian suuri, jos siihen on sekoittunut useita hakuaikeita, olennainen lause hukkuu navigaation ja sivutiedon väliin tai monet hakutulokset palauttavat saman laajan lohkon. Liian pieni se taas on silloin, kun pronomineilla ei ole enää viittausta, otsikot puuttuvat, ehdot erotetaan väitteistä tai tarvitaan useita katkelmia yksinkertaisen kysymyksen ymmärtämiseen.

Vertaa siksi vähintään kahta tai kolmea eri vaihtoehtoa samalla kysymyssarjalla. Muuta kerrallaan vain yhtä parametria, kuten tavoitekokoa tai rajalogiikkaa. Näin näet selvästi, mikä todella parantaa osumalaatua ja vastausten lähteitä.

Limitys suojaa kontekstia – ja luo samalla kaksoiskappaleita

Pieni limitys (overlap) voi estää ratkaisevan lauseen katoamisen suoraan palan rajalla. Se on erityisen hyödyllinen silloin, kun tekninen jakaminen pituuden mukaan on välttämätöntä. Liiallisella limityksellä on kuitenkin sivuvaikutuksia: lähes identtiset osumat vievät useita tulospeilauksia, kasvattavat kontekstin määrää ja voivat dominoida väitettä keinotekoisesti.

Käytä limitystä siksi harkiten. Rakenneperusteisissa osioissa riittää usein otsikon, rakennepolun ja lyhyen siirtymän ottaminen mukaan. Pidemmissä juoksevissa teksteissä pieni osuus edellisestä osiosta voi olla hyödyllinen. Mittaa sen jälkeen, pysyvätkö eri asiaankuuluvat lähteet kärkiosumissa vai syrjäyttävätkö kaksoiskappaleet ne.

Metatiedot tekevät palasta toimintavarmaa

Pelkkä teksti riittää harvoin tuotantokäytössä olevaan tietopohjaan. Jokaisen palan tulee säilyttää alkuperänsä ja soveltamisalueensa. AWS kuvailee metatietoja kyselyiden suodatuksen perustaksi. Verkkosivuston tietopohjassa erityisesti seuraavat kentät ovat hyödyllisiä:

• Kanoninen lähde-URL ja sivun otsikko,
• Otsikkopolku sivun sisällä,
• Kieli tai locale,
• Sisältötyyppi, kuten FAQ, ohje, linjaus tai tuotetieto,
• Julkaisu- tai muokkauspäivämäärä,
• Tuote, alue tai kohderyhmä, mikäli alakohtaisesti olennaista,
• Käyttöoikeus- ja hyväksyntätila ei-julki-sisällöissä.

Tämän avulla voidaan suorittaa hakuja esimerkiksi vain suomenkielisestä, ajantasaisesti hyväksytystä tukisisällöstä. Lähde voidaan myös linkittää vastauksessa ja käsitellä täsmällisesti uudelleen myöhemmässä päivityksessä. Miten varmistat ajantasaisuuden järjestelmällisesti, siitä kerrotaan oppaassa Tekoäly-chatbotin tietopohjan pitäminen ajantasaisena.

Poista toistuva vakioteksti (boilerplate) ja duplikaatit ennen indeksointia

Navigaatio, evästehuomautukset, toistuvat yhteystietolohkot ja globaalit alatunnisteet eivät kuulu jokaiseen palaan. Muuten syntyy satoja lähes identtisiä merkintöjä, jotka voivat syrjäyttää varsinaiset sisällöt. Poista toistuvat sivuelementit ennen paloittelua ja normalisoi turhat välilyönnit, koristemerkit sekä tekniset pirstaleet.

Myös sisällölliset duplikaatit vaativat huomiota. Jos sama palautussääntö on muotoiltu eri tavalla ohje-, tuote- ja toimitussivuilla, on määriteltävä vastuullinen ensisijainen lähde. Vanhentuneet kopiot poistetaan, ohjataan uudelleen tai niiden prioriteettia lasketaan selvästi. Paloittelumenetelmä ei pysty muuttamaan ristiriitaisia lähteitä luotettavaksi tiedoksi.

Käsittele erikoistapaukset tietoisesti

FAQ-sisällöt

Tallenna kysymys ja vastaus yhdessä. Jos vastaukset ovat erittäin lyhyitä, täydennä niitä ylemmän tason aihealueella. Saman kysymyksen eri muunnelmat voivat olla hyödyllisiä hakua varten, mutta niitä ei pitäisi indeksoida useana eri vastaustekstinä.

Taulukot ja luettelot

Taulukkorivi ilman sarakeotsikoita on yleensä käsittämätön. Toista tai viittaa siksi asiaankuuluviin otsikkotermeihin palassa. Pitkissä luetteloissa jokaisen osan tulee säilyttää luettelon otsikko ja yhteinen johdanto. Tarkista uuttamisen jälkeen, että arvot liittyvät edelleen oikeaan ominaisuuteen.

Monikieliset sivut

Erota sisällöt kielialueen (locale) mukaan ja tallenna kieli metatietona. Suomenkielisen kyselyn ei pitäisi vahingossa saada vanhentunutta englanninkielistä osiota vain siksi, että siinä esiintyy samanlaisia termejä. Yhteiset käännös- tai sivutunnisteet auttavat yhdistämään muunnelmat toisiinsa sekoittamatta niitä samaan tekstilohkoon.

Suorita hakutestit ennen vastaustestia

Arvioi ensin, tuottaako haku oikean kohdan. Vasta sen jälkeen arvioit kielimallin muotoilua. Pienen todellisista käyttäjäkysymyksistä koostuvan testijoukon (Golden Set) tulisi sisältää selkeitä kysymyksiä, synonymeja, moniosaisia pyyntöjä, rajatapauksia ja kysymyksiä, joihin ei ole vahvistettua vastausta. Määritä jokaiselle kysymykselle etukäteen, mitä lähdettä tai osiota odotetaan.

Tarkista vähintään:

• ilmestyykö odotettu osio ensimmäisten osumien joukkoon,
• syrjäyttävätkö epäolennaiset tai kaksinkertaiset osumat tärkeitä lähteitä,
• ovatko kaikki tarvittavat ehdot ja poikkeukset mukana saadussa kontekstissa,
• pysyvätkö lähde ja sen ajantasaisuustila jäljitettävinä,
• jättääkö järjestelmä varmasti vastaamatta, jos tietoa puuttuu (eikä keksi sitä).

Artikkeli Tekoäly-chatbotin vastauslaadun mittaaminen Golden Set -joukolla ja RAG-testeillä kuvaa sopivan testausprosessin. Näkyvien todisteiden osalta opas Chatbotin vastausten perustelu lähteillä täydentää näkökulmaa linkkitarkistukseen ja epävarmuuteen.

Tarkistuslista käyttöönottoa varten

1. Kartoita sisällöt: Rekisteröi sivutyypit, kielet, muodot ja vastuulliset lähteet.
2. Tarkista uuttaminen: Tarkista otsikot, taulukot ja lukujärjestys edustavista esimerkeistä.
3. Määritä rajat: Suosi semanttisia osioita ja käytä kiinteitä kokoja vain vararatkaisuna.
4. Säilytä konteksti: Liitä mukaan sivun otsikko, otsikkopolku ja tarvittavat siirtymät.
5. Suunnittele metatiedot: Tallenna URL, locale, ajantasaisuus, sisältötyyppi ja hyväksyntä rakenteellisesti.
6. Poista duplikaatit: Puhdista toistuva teksti (boilerplate) ja ristiriitaiset kopiot ennen indeksointia.
7. Testaa muunnelmia: Vertaa kokoja ja limitystä samalla Golden Set -joukolla.
8. Valvo toimintaa: Analysoi puuttuvat osumat, vanhentuneet lähteet ja käyttäjäpalaute säännöllisesti.

Yhteenveto: Hyvät palat ovat ymmärrettäviä tietoyksiköitä

RAG-paloittelu ei ole kertaluonteinen tekninen asetus, vaan koneellisen haun sisältöarkkitehtuuria. Hyvät palat vastaavat selkeästi rajattuun osakysymykseen, säilyttävät tarvittavan kontekstinsa ja ovat yhdistettävissä voimassa olevaan lähteeseen. Otsikot, metatiedot ja hallittu limitys ovat tällöin yhtä tärkeitä kuin pelkkä pituus.

Aloita muutamista edustavista sisältötyypeistä, mittaa hakua ennen vastaustyyliä ja dokumentoi jokainen muutos. Jos haluat sen jälkeen rakentaa verkkosivuston chatbotin strukturoidun tietopohjan varaan, löydät sopivan aloituksen ChatReact-ominaisuuksien yleiskatsauksesta.

Lähteet

• Microsoft Learn: Chunk large documents for vector search solutions in Azure AI Search
• Microsoft Learn: Chunk and vectorize by document layout
• AWS Bedrock: How content chunking works for knowledge bases
• AWS Bedrock: Include metadata in a data source