Pilkkominen, uudelleenjärjestäminen ja hybridihaku: tee RAG:stä toimiva

Useimmat RAG-toteutukset toimivat huonosti. Malli kyllä toimii: Claude tai GPT-5 vastaa mielellään haettujen asiakirjojen perusteella. Haku epäonnistuu. Esität kysymyksen, järjestelmä palauttaa väärät tekstiosat ja malli tuottaa niiden perusteella itsevarman mutta väärään tietoon pohjautuvan vastauksen.

Tämä artikkeli on käytännön opas huonon haun kolmeen korjaukseen: pilkkomisstrategiaan, uudelleenjärjestämiseen ja hybridihakuun. Kun nämä ovat kunnossa, useimmat valitukset siitä, ettei RAG sovi käyttötapaukseen, katoavat.

Ohitamme syvällisen matematiikan ja keskitymme käytännön toimiin.

Miksi haku epäonnistuu

RAG:n oletusputki:

1. Jaa asiakirjat osiin.
2. Luo jokaisesta osasta upotus.
3. Kun kysymys saapuu, luo siitä upotus ja etsi samankaltaisimmat osat kosinisamankaltaisuuden avulla.
4. Välitä osat LLM:lle.

Jokainen vaihe voi epäonnistua:

Huono pilkkominen tuottaa osia, jotka ovat liian lyhyitä hyödyllisiksi tai liian pitkiä pysyäkseen johdonmukaisina. Pilkkominen voi myös katkaista loogisen ajatuksen keskeltä, jolloin kumpikaan puolikas ei löydy hyvin.

Naiivi samankaltaisuushaku löytää kyselyn kanssa samaa sanastoa käyttäviä mutta merkitykseltään epäolennaisia osia. Kysely ”miten peruutan tilaukseni” voi löytää jokaisen ”tilauksen” mainitsevan osan, myös asiaan liittymättömän markkinointitekstin.

Uudelleenjärjestämisen puuttuminen tarkoittaa, että LLM näkee suoraan samankaltaisuushaun tulokset. Samankaltaisin osa ei aina ole olennaisin.

Pelkkä semanttinen haku ohittaa joskus tärkeät täsmälliset avainsanaosumat. Kysely ”virhekoodi 503” voi ohittaa täsmälleen tekstin ”virhekoodi 503” sisältävän osan, jos kyselyn semanttinen vektori ei vastaa osan yleistä aihetta.

Kolme korjausta — parempi pilkkominen, uudelleenjärjestäminen ja hybridihaku — ratkaisevat nämä ongelmat.

Korjaus 1: parempi pilkkominen

Pilkkominen on RAG-putken yksittäisistä valinnoista vaikuttavin, mutta useimmat pohtivat sitä vasta tulosten osoittauduttua huonoiksi.

Useimpien koodittomien työkalujen naiivi oletus on pilkkoa kiinteällä tokenmäärällä, esimerkiksi 500 tokenin osiin 50 tokenin limityksellä. Tämä toimii kohtalaisesti mutta epäonnistuu usein.

Parempia strategioita:

Semanttinen pilkkominen

Jaa asiakirjat mielivaltaisten tokenmäärien sijaan semanttisista rajoista eli kohdista, joissa aihe vaihtuu. Useimmissa nykyaikaisissa kehyksissä, kuten LangChainissa ja LlamaIndexissä, on aiheen vaihtumisen tunnistavia semanttisia pilkkojia.

Hyöty: osat sisältävät kokonaisia ajatuksia. Malli saa johdonmukaista kontekstia puolikkaiden perustelujen sijaan.

Rakenteen huomioiva pilkkominen

Hyödynnä asiakirjojen luontaista rakennetta, kuten Markdown-otsikoita, HTML-osioita, PDF-lukuja tai koodin funktiorajoja. Pilko osioiden, älä tokenmäärän mukaan.

Markdownissa:

• Jokainen H2-osio on oma osa, jonka alkuun lisätään H1-konteksti.
• Pitkät H2-osiot pilkotaan edelleen, ja H2-otsikko toistetaan kontekstina.

Koodissa:

• Jokainen funktio tai luokka on oma osa.
• Osaan sisällytetään tiedostopolku ja tuonnit.

Tämä toimii kaikessa rakenteisessa sisällössä huomattavasti paremmin kuin sokea kiinteän koon pilkkominen.

Hierarkkinen pilkkominen

Uudemmasta RAG-tutkimuksesta peräisin oleva malli luo osia usealle tasolle:

• Pienet osat (200-500 tokenia) täsmälliseen hakuun.
• Keskikokoiset osat (1000-2000 tokenia) kontekstiksi.
• Asiakirjatiivistelmät (50-100 tokenia) ylätason vastaavuuden löytämiseen.

Haussa vastaavuus etsitään pienistä osista, mutta palautetaan niitä ympäröivä keskikokoinen osa. LLM saa sekä täsmällisen osuman että riittävästi kontekstia sen ymmärtämiseen.

Osan koon valitseminen

Suuntaa-antava sisältötyyppikohtainen sääntö:

Jos kooditon työkalusi piilottaa pilkkomisen, testaa sitä: esitä 10 kysymystä, joiden vastaukset tiedät aineistossa oleviksi. Jos oikea osa jää haussa säännöllisesti löytymättä, ongelma on pilkkomisessa.

Hyvin toimiva malli: ensin sivu tai osio, sitten kysymyspohjainen kuvaus

Useimmissa henkilökohtaisissa RAG-käyttötapauksissa toimii seuraava malli:

1. Pilko asiakirjan osioiden mukaan, kuten Markdownin H2-otsikoista tai PDF-luvuista.
2. Pilko yli ~2000 tokenin osat edelleen kappaleittain.
3. Lisää jokaisen osan alkuun asiakirjan nimi ja osion otsikko kontekstiksi.
4. Lisää loppuun lyhyt kuvaus siitä, millaisiin kysymyksiin osa vastaa. Nopea LLM voi tuottaa kuvauksen automaattisesti indeksoinnin aikana.

Automaattisesti tuotettu kuvaus osan vastaamista kysymyksistä on yllättävän vähän käytetty mutta tehokas menetelmä. Käyttäjien kyselyt ovat usein kysymysmuodossa, joten niiden vertaaminen kysymysmuotoiseen metatietoon on täsmällisempää kuin vertaaminen asiakirjan raakatekstiin.

Korjaus 2: uudelleenjärjestäminen

Alkuhaun palautettua tavallisesti 20-50 osaa vektorisamankaltaisuuden perusteella järjestä ne uudelleen kyselyn todellisen relevanssin mukaan.

Uudelleenjärjestäjä on erillinen, tavallisesti pieni erikoismalli, joka vastaanottaa kyselyn ja osan pareja ja antaa relevanssipisteen. Anna sille 20-50 parasta tulosta, järjestä ne uusien pisteiden mukaan ja välitä parhaat 3-5 LLM:lle.

Hyöty on huomattavasti parempi tarkkuus. Vektorisamankaltaisuus on nopea mutta ei erityisen tarkka; uudelleenjärjestäjä on hitaampi mutta paljon tarkempi. Yhdistelmä tarjoaa nopean haun ja tarkan järjestyksen.

Uudelleenjärjestäjävaihtoehtoja vuonna 2026:

• Cohere Rerank — vakiintunut rajapintapohjainen uudelleenjärjestäjä. $2.00 per 1,000 hakua (listahinta, tarkistettu 2026-07-10).
• Voyage AI rerank-2 — vahva kaupallinen vaihtoehto, joka toimii erikoisaloilla usein Coherea paremmin.
• bge-reranker-v2-m3 — avoimen lähdekoodin ratkaisu, jota voi käyttää paikallisesti tai edullisessa palvelinympäristössä.
• Jina Reranker — toinen vahva avoimen lähdekoodin vaihtoehto.

Tavallisessa putkessa:

1. Vektorihaku palauttaa 50 parasta osaa edullisesti ja nopeasti.
2. Uudelleenjärjestäjä pisteyttää kaikki 50 osaa kyselyä vasten kalliimmin ja hitaammin.
3. Parhaat 5 uudelleenjärjestämispisteet saanutta osaa välitetään LLM:lle.

Lisäviive on yhteensä noin ~200-500ms. Haun tarkkuus paranee usein 20-40% vertailutesteissä.

Koodittomissa työkaluissa, jotka eivät oletuksena sisällä uudelleenjärjestämistä, kuten NotebookLM:ssä ja useimmissa n8n:n perusratkaisuissa, tämä on vaikuttavin yksittäinen parannus. n8n:ssä on Cohere Rerank -solmu, ja LangChain sekä LlamaIndex sisältävät natiivit integraatiot uudelleenjärjestäjiin.

Korjaus 3: hybridihaku

Vektorisamankaltaisuus löytää semanttiset osumat. Avainsanahaku, kuten BM25, löytää täsmälliset osumat. Kumpikin löytää asioita, jotka toinen ohittaa.

Kyselyssä ”miten korjaan yhdyskäytävämme HTTP 503 -virheet”:

• Vektorihaku löytää HTTP-virheitä, yhdyskäytäväongelmia ja vianmääritystä käsitteleviä osia.
• Avainsanahaku löytää juuri ”503”-tekstin sisältävät osat, joista varsinainen vastaus saattaa löytyä.

Hybridihaku suorittaa molemmat haut ja yhdistää tulokset. Yhdistämiseen käytetään Reciprocal Rank Fusion -menetelmää (RRF). RRF muodostaa kummankin haun järjestyksistä yhdistetyn järjestyksen, joka huomioi molemmat signaalit.

Toteutus on useimmissa työkaluissa yksinkertainen:

• Suorita vektorihaku → saat järjestetyn luettelon A.
• Suorita BM25- tai avainsanahaku → saat järjestetyn luettelon B.
• Laske jokaiselle osalle RRF-piste = 1/(k + rank_in_A) + 1/(k + rank_in_B), jossa k saa arvon 60 useimmissa toteutuksissa.
• Järjestä yhdistettyjen pisteiden mukaan ja palauta parhaat tulokset.

Vuonna 2026, artikkelin kirjoitushetkellä, hybridihakua tukevat natiivisti:

• Weaviate eli vektoritietokanta tarjoaa hybridihakuominaisuuden suoraan.
• Qdrant tarjoaa hybridihaun suodatuksen kautta.
• Pinecone tarjoaa hybridihaun harvojen vektorien kautta.
• Elastic / OpenSearch yhdistää avainsana- ja vektorihaun.
• Useimmat n8n:n RAG-mallit käyttävät modernissa toteutuksessa oletuksena hybridihakua.

Hyöty on huomattavasti parempi saanti kyselyissä, jotka sisältävät täsmällisiä tunnisteita, koodeja, nimiä tai erikoissanastoa. Teknisessä sisällössä, kuten koodissa, virhekoodeissa, tuotenimissä ja säädösviittauksissa, hybridihaku on käytännössä välttämätön.

Jos kyselysi sisältävät usein täsmälleen vastaavia termejä, kuten numeroita, nimiä, koodeja tai tarkkoja ilmauksia, ota hybridihaku käyttöön. Kustannus on pieni ja hyöty suuri.

Menetelmien yhdistäminen

Edistynein RAG-putki vuonna 2026:

Query
  ↓
Query rewriter (optional — clean up the query, expand abbreviations)
  ↓
Hybrid retrieval: vector + keyword search
  ↓
Top 30-50 results
  ↓
Reranker
  ↓
Top 5 by reranker score
  ↓
LLM with retrieved chunks + query
  ↓
Cited answer

Jokainen vaihe on erikseen edullinen. Yhdessä ne tuottavat laadultaan aivan erilaisen haun kuin ”vektorisamankaltaisuus → 5 parasta → LLM”.

Muutama harvinaisempi mutta tehokas lisäys:

Kyselyn laajentaminen. Muotoile käyttäjän kyselystä useita versioita ja hae jokaisella. Näin löydät erilaisia sanamuotoja.

Monivaiheinen haku. Tee monimutkaisissa kysymyksissä useita hakuja. Ensimmäinen tunnistaa osakysymykset, toinen hakee vastaukset kuhunkin.

Keskusteleva haku. Käytä monivuoroisessa keskustelussa keskusteluhistoriaa haun ohjaamiseen: jos käyttäjä kysyi aiemmin X:stä, painota nyt X:ään liittyvää sisältöä.

Lähteiden suodattaminen. Rajaa haku metatietosuodattimilla esimerkiksi vain asiakirjoihin, joiden tunniste on ”EU regulations” ja päiväys on myöhempi kuin 2023.

Nämä ominaisuudet ovat yhä useammin saatavilla koodittomissa RAG-työkaluissa. Varmista silti ensin, että kolme perusasiaa — hyvä pilkkominen, uudelleenjärjestäjä ja hybridihaku — ovat kunnossa.

RAG:n laadun mittaaminen

Et voi parantaa sellaista, mitä et mittaa. Käytännön arviointistrategioita:

Kultaisten kysymysten testi. Valitse 20 kysymystä, joiden oikeat vastaukset tunnet. Suorita ne RAG:n läpi. Arvioi, löytyivätkö oikeat osat ja tuottiko malli oikean vastauksen. Tee testi kuukausittain.

Haun saanti arvolla K. Määritä jokaiselle kultaiselle kysymykselle vastauksen sisältävät osat. Tarkista sitten, palauttiko hakujärjestelmä jonkin niistä K parhaan joukossa (5, 10, 20). Mittaa osuus.

LLM tuomarina. Edistyneemmässä versiossa käytetään vahvaa mallia. Claude Opus tai GPT-5 voi arvioida vastauksen oikeellisuuden, lähdeviitteiden täsmällisyyden, kattavuuden ja lähdepohjaisuuden. Suorita arvio edustavalle kysymyserälle. Arvioinneista on oma artikkelinsa.

Käyttäjän kokema laatu. Lisää tiimi- tai tuotantotason RAG-ratkaisussa jokaiseen vastaukseen peukku ylös- ja peukku alas -painikkeet. Tutki kielteisten arvioiden malleja. Ne keskittyvät tiettyihin kysymystyyppeihin, jotka voit korjata.

Suurin virhe on jättää mittaaminen kokonaan tekemättä. ”Tuntuu riittävältä” ei ole mittaustulos. Ilman mittaamista et tiedä, toimivatko parannukset.

Käytännön esimerkki: heikosti toimivan RAG:n parantaminen

Oletetaan, että yrityksesi sisäisille ohjeille rakennettu henkilökohtainen RAG tuottaa keskinkertaisia tuloksia: noin 60% kysymyksistä saa hyödyllisen vastauksen. Tee parannukset tässä järjestyksessä:

Tarkasta ensin haku. Tutki kymmenen heikon vastauksen kohdalla haettuja osia. Löytyikö oikea osa? Jos löytyi, ongelma on mallissa tai kehotteessa. Jos ei löytynyt, ongelma on haussa.

Jos ongelma on haussa:

1. Tarkista pilkkominen. Ovatko osat johdonmukaisia? Katkeaako tärkeä ajatus keskeltä? Vaihda semanttiseen tai rakenteen huomioivaan pilkkomiseen.

2. Lisää uudelleenjärjestäjä. Jos käytät perusvektorihakua ja 5 parasta tulosta, lisää Cohere Rerank tai bge-reranker-v2-m3 haun ja LLM:n väliin. Parannus näkyy tavallisesti heti, mutta mittaa se omalla arviointiaineistollasi yleisten prosenttilupausten sijaan.

3. Lisää hybridihaku. Erityisesti silloin, kun kyselyissä esiintyy täsmällisiä termejä, kuten tuotenimiä, virhekoodeja tai erikoissanastoa.

4. Tutki indeksointia. Onko osiin liitetty metatietoja, kuten asiakirjatyyppi, osio ja päivämäärä? Käytä haussa metatietosuodattimia.

Jos ongelma on mallissa eli oikeat osat löytyvät mutta vastaus on väärä:

1. Tiukenna kehotetta. Ohjeista mallia täsmällisesti vastaamaan vain annetun kontekstin perusteella ja kertomaan, jos konteksti ei kata kysymystä.

2. Lisää lähdeviitteet. Vaadi mallia viittaamaan käyttämäänsä täsmälliseen osaan. Tämä auttaa virheenkorjauksessa ja vähentää hallusinaatioita.

3. Käytä vahvempaa mallia. Jos käytössä on pieni nopea malli, kokeile Claude Sonnet 4.5:tä. Toinen vaihtoehto on GPT-5.

Kahden tai kolmen tällaisen tutkimus- ja korjauskierroksen jälkeen useimmat RAG-toteutukset saavuttavat 85-90% hyödyllisten vastausten osuuden. Tällä tasolla käyttäjät todella omaksuvat järjestelmän ja luottavat siihen.

Yleiset virheet

Muutama toistuva sudenkuoppa:

Väärän sisällön indeksointi. Markkinointisivut, vanhentuneet ohjeet ja heikkolaatuiset blogit. Malli ei erota niitä, vaan käsittelee kaikkea indeksissä ensisijaisena totuutena. Valikoi armottomasti.

Indeksin päivittämättä jättäminen asiakirjojen muuttuessa. Vanhentunutta sisältöä käyttävä RAG antaa itsevarmasti vääriä vastauksia. Indeksoi säännöllisesti uudelleen tai käytä automaattisesti synkronoituvaa järjestelmää.

Arvioinnin sivuuttaminen. Useimmat RAG-ratkaisut otetaan käyttöön mittaamatta eikä niitä sen jälkeen paranneta. ”Tuntuu riittävältä” -vaihe jatkuu ikuisesti. Sisällytä arviointi ensimmäisestä päivästä lähtien.

Haun käsitteleminen mustana laatikkona. ”Se ei vain toimi” ei ole diagnoosi. Avaa haku ja tutki palautuvia tuloksia. Ongelma tulee lähes aina ilmeiseksi, kun näet ne.

Liiallinen suunnittelu alkuvaiheessa. Sinun ei tarvitse aloittaa edistyneimmällä putkella. Aloita NotebookLM:llä tai perusvektorihaulla. Lisää monimutkaisuutta vasta tunnistettuasi täsmällisen pullonkaulan.

Milloin tällä on merkitystä

Kolme korjausta — parempi pilkkominen, uudelleenjärjestäminen ja hybridihaku — ovat tärkeimmillään, kun:

• Aineisto on teknistä ja käyttää täsmällistä erikoissanastoa.
• Kyselyt vaativat täsmällisiä osumia, kuten koodeja, nimiä tai tunnisteita.
• Käyttäjille täsmällisyys on tärkeää esimerkiksi oikeudellisessa työssä, vaatimustenmukaisuudessa tai asiakaspalvelussa.
• Järjestelmää käytetään laajasti, jolloin pieni laatuhyöty merkitsee paljon 10,000 päivittäisessä suorituksessa.

Niillä on vähemmän merkitystä, kun:

• Aineisto on pieni, alle 100 asiakirjaa, ja hyvin järjestetty.
• Kyselyt ovat avoimia, kuten ”mikä on näkemyksemme X:stä”.
• Käyttäjät hyväksyvät iteroinnin vastauksen löytämiseksi.
• Käyttötapaus on tutkiva eikä täsmällinen.

Useimmissa henkilökohtaisissa ja pienten tiimien RAG-ratkaisuissa vaikuttavin parannus on siirtyminen perusvektorisamankaltaisuudesta vektorihaun ja uudelleenjärjestäjän yhdistelmään. Hybridihaku on seuraava lisäys. Pilkkomisella on merkitystä kaikissa mittakaavoissa.

Yhteenveto

Huono RAG johtuu lähes aina huonosta hausta, joka puolestaan liittyy lähes aina kolmeen asiaan: pilkkomiseen, uudelleenjärjestämiseen ja hakumenetelmään. Korjaa nämä kolme, niin useimmat RAG:n laatuongelmat poistuvat.

Menetelmien käyttö ei vaadi hakutekniikan asiantuntijuutta. Weaviate, Pinecone, Qdrant, n8n-mallit ja LangChain-integraatiot ovat tuoneet ne kaikkien ulottuville. Pullonkaula on nykyisin lähinnä menetelmien tunteminen ja harkittu soveltaminen.

Jos RAG ei toimi, älä syytä mallia. Tutki palautuvia osia, korjaa haku ja arvioi tulokset uudelleen.