Artikkeli · Määritelmä

Mikä on RAG?

Malli, jossa AI hakee asiaankuuluvat dokumentit ennen vastaamista. Miten se toimii, milloin se sopii, missä se epäonnistuu ja millainen tuotantopino kestää oikeassa käytössä.

Kirjoittanut Aleksi Stenberg · 16.5.2026 · 11 min lukuaika

Tiivistelmä

RAG (retrieval-augmented generation, haku-augmentoitu generointi) on malli, jossa kielimalli hakee asiaankuuluvia dokumentteja tietopankista ennen vastauksensa generointia. Hakuvaihe ankkuroi vastauksen tarkkaan dataan, jota mallia ei koskaan opetettu käyttämään. Se on vakiintunut tapa saada kielimalli puhumaan yrityksesi sisäisistä dokumenteista, tuotespeksistä, sopimuksista tai mistä tahansa yksityisestä aineistosta.

RAG sopii kaikkiin tapauksiin, joissa vastaukset riippuvat dokumenteista, jotka muuttuvat, joita malli ei ole nähnyt tai joiden täytyy olla auditoitavissa. Se ei sovi tapauksiin, joissa vastauksen täytyy olla sanasta sanaan oikein, joissa aineisto mahtuu kontekstiikkunaan tai joissa data on hyvin jäsenneltyä ja SQL hoitaa sen paremmin. Tämä artikkeli käy läpi, miten RAG toimii, millainen tuotantopino kestää oikeaa liikennettä ja mitkä yleiset virheet kääntävät lupaavat prototyypit pysähtyneiksi projekteiksi.

Käytännön määritelmä

Jokainen vuonna 2026 AI-ominaisuuksia rakentava tiimi törmää samaan seinään. Kielimalli on loistava kielessä. Kielimalli ei ole koskaan lukenut yrityksen hankintakäsikirjaa. Hankintakäsikirja on juuri se, mistä käyttäjä kysyy. RAG on vakiintunut vastaus.

RAG on malli, jossa kielimalli hakee asiaankuuluvia dokumentteja tietopankista ennen vastauksensa generointia. Hakuvaihe ankkuroi mallin tulosteen tarkkaan dataan, jota mallia ei koskaan opetettu käyttämään. Malli tuottaa vastauksen, joka viittaa haettuun sisältöön ja käyttää sitä sen sijaan, että nojaisi siihen, mitä se omaksui opetusvaiheessa.

Mallin muoto: käyttäjä esittää kysymyksen. Järjestelmä etsii sisäisten dokumenttien tärkeimmät palaset. Nuo palaset lisätään kehotteeseen kontekstiksi. Malli lukee kontekstin ja tuottaa vastauksen. Vastauksessa voi viitata siihen, mitkä dokumentit sitä tukivat.

Konkreettinen esimerkki. 200 hengen suomalaisella ohjelmistoyrityksellä on 3 000 sivua sisäistä dokumentaatiota: HR-käsikirja, insinöörien runbookit, tietoturvakäytännöt, asiakkaiden käyttöönotto-ohjeet. Uusi työntekijä kysyy "miten tilaan kehittäjäkoneen". Pelkkä kielimalli keksisi vastauksen. RAG-järjestelmä hakee asiaankuuluvan runbookin osion, välittää sen mallille, ja malli vastaa tarkalla suomalaisella prosessilla viitaten runbookin sivuun. Vastaus on oikea, koska malli näki oikean dokumentin.

Miten RAG toimii

Mallissa on kaksi vaihetta: indeksointi (tehdään kerran, sitten inkrementaalisesti) ja palvelu (tehdään jokaiselle kyselylle).

Indeksointivaihe. Jokainen dokumentti pilkotaan muutaman sadan tokenin paloiksi. Jokainen pala lähetetään upotusmallin läpi, joka muuntaa tekstin numeroluetteloksi (tyypillisesti 1024 tai 1536 ulottuvuutta). Numerot ovat sijainti korkean ulottuvuuden avaruudessa, jossa merkitykseltään samankaltaiset palat ovat lähellä toisiaan. Palat ja niiden upotukset tallennetaan vektoritietokantaan. Metatieto (lähdedokumentti, sivu, päiväys, käyttöoikeudet) tallennetaan samalla.

Palveluvaihe. Käyttäjän kysely saapuu. Sama upotusmalli muuntaa kyselyn vektoriksi. Vektoritietokanta löytää palat, joiden vektorit ovat lähimpinä. Nuo palat (tyypillisesti 5–20 parasta) lisätään kielimallin kehotteeseen kontekstina. Kielimalli lukee kehotteen, generoi vastauksen ja palauttaa sen käyttäjälle.

Paloittele ja upota. Pilko dokumentit osiin. Muunna jokainen osa vektoriksi upotusmallilla (OpenAI text-embedding-3-large, Cohere embed-v3, BGE-M3 avoimien painojen vaihtoehtona). Tallenna vektorit ja metatieto vektoritietokantaan.
Hae. Muunna käyttäjän kysely vektoriksi. Suorita lähimmän naapurin haku vektoritietokannasta. Ota N parasta palaa. Käytä metatietosuodattimia, kun käyttöoikeuksilla tai tuoreudella on merkitystä.
Pisteytä uudelleen (valinnainen mutta suositeltu). Välitä N parasta haettua palaa ja kysely uudelleenpisteytysmallille (Cohere Rerank, Voyage rerank-2). Uudelleenpisteyttäjä järjestää tulokset niin, että tärkeimmät palat ovat ensin ja kohina putoaa pois.
Generoi. Muodosta kehote, joka sisältää alkuperäisen kyselyn ja haetut palat. Lähetä kehote kielimallille (Claude, GPT, Gemini tai avoimien painojen Llama tai Mistral). Malli tuottaa haettuun kontekstiin ankkuroidun vastauksen.

Tämä on koko malli. Tuotannon monimutkaisuus syntyy siitä, että jokainen askel tehdään hyvin: valitaan oikea upotusmalli, paloitellaan dokumentit järkevästi, hallitaan käyttöoikeudet, käsitellään metatietosuodattimet ja seurataan haun laatua.

Milloin RAG sopii

Neljä tilannetta, joissa RAG ansaitsee monimutkaisuutensa:

Sisäiset tietopankit. Työntekijän käsikirjat, prosessiohjeet, insinöörien runbookit, tietoturvakäytännöt. Aineisto on niin suuri, ettei kukaan lue sitä kokonaan. Vastaukset ovat olemassa mutta vaikeasti löydettävissä. RAG-järjestelmä vastaa kysymyksiin sekunneissa lähdeviittauksin.

Asiakaskäyttöön tuleva tuki ja dokumentaatio. Tuotedokumentaatio, vianetsintäoppaat, rajapintaviitteet. Asiakkaat saavat nopeammat vastaukset. Tukitiimit vapautuvat toistuvista kysymyksistä. Sama RAG-järjestelmä voi palvella sekä asiakaschattia että sisäistä tukityökalua.

Vaatimustenmukaisuus- ja juridiset haut. Sopimukset, viranomaisilmoitukset, käytäntödokumentit. Käyttäjä kysyy "saammeko tehdä X:n Saksassa". RAG-järjestelmä hakee asiaankuuluvat käytäntökohdat, ja malli tiivistää kannan viitaten käytäntöön. Juristi tarkastaa silti. Haku, joka kesti aiemmin 40 minuuttia, kestää 90 sekuntia.

Tutkimus yksityisten dokumenttien yli. Hallitusmateriaalit, tilinpäätökset, due diligence -paketit. Pohjoismaisen yhtiön osakas kysyy "mitä ESG:stä keskusteltiin viimeisessä kuudessa hallituksen kokouksessa". RAG löytää asiaankuuluvat pöytäkirjat, ja malli tuottaa synteesin lähdeviittauksin. Sama malli toimii analyytikkoraporteille, sisäiselle tutkimukselle ja historiallisille projektiarkistoille.

Yhteinen lanka: vastaus on dokumenteissa, joita malli ei ole koskaan nähnyt, dokumentit ovat liian suuria välitettäviksi suoraan mallille, ja käyttäjä tarvitsee vastauksen nopeammin kuin hän saisi lukemalla lähteen itse.

Milloin RAG ei sovi

Neljä tilannetta, joissa RAG on väärä työkalu.

Vastauksen täytyy olla sanasta sanaan oikein. Sääntelyteksti, juridiset sopimukset, tarkat hintataulukot, koneluettavat speksit. Käyttäjä tarvitsee itse dokumentin, ei uudelleensanoitusta. Rakenna nopea hakukäyttöliittymä, joka nostaa lähteen esiin. Generointi on tässä väärä valinta.

Aineisto mahtuu kontekstiikkunaan. Nykyiset kielimallit käsittelevät 200 000 tokenia tai enemmän. Jos koko asiaankuuluva dokumenttijoukko on tuon kynnyksen alla, välitä se suoraan mallille. Indeksointi ja haku lisäävät viivettä, kustannusta ja vikapaikkoja ilman hyötyä tässä mittakaavassa.

Data on jäsenneltyä ja SQL hoitaa sen paremmin. Asiakaskohtainen liikevaihto segmentin ja kvartaalin mukaan. Varastotasot SKU:ittain. Tilinpäätöksen rivit jaksoittain. Nämä kuuluvat tietokantaan, eivät RAG-järjestelmään. Rakenna kielimallin pääsy SQL-kyselyillä datajärjestelmää vastaan. RAG on jäsentymättömille dokumenteille.

Faktat muuttuvat reaaliajassa. Osakekurssit, elävä varastotilanne, nykyinen tilauksen tila. RAG vedoksen yli vanhenee minuuteissa. Käytä elävää rajapintakutsua työkaluna RAG-haun sijaan. AI-agentti kutsuu rajapintaa suoraan tuoreelle datalle.

RAG on oikea vastaus, kun dokumentit muuttuvat, aineisto on suuri ja vastaus tarvitsee kieltä. Muuhun yksinkertaisempi työkalu yleensä voittaa.

Tuotantopino

Kuusi komponenttia ratkaisee. Yhdenkin oikaiseminen näkyy myöhemmin laadun heikkenemisenä tai epäluotettavina vastauksina.

Komponentti	Yleiset valinnat	Oletus pohjoismaiselle keskimarkkinalle
Upotusmalli	OpenAI text-embedding-3-large, Cohere embed-v3, Voyage voyage-3, BGE-M3, Nomic Embed	OpenAI text-embedding-3-large pelkkään englantiin, BGE-M3 suomen- tai ruotsinkieliseen sisältöön, Voyage kun haun laatu on prioriteetti.
Vektoritietokanta	Postgres + pgvector, Qdrant, Weaviate, Pinecone, Milvus	Postgres + pgvector alle muutaman miljoonan palan aineistoille. Qdrant, kun mittakaava tai viive ylittää pgvectorin.
Paloittelu	Tokeneihin perustuva päällekkäisyydellä, semanttinen, hierarkkinen	Tokeneihin perustuva (400–800 tokenia, 50–100 päällekkäisyys) lähtökohtana. Säädä haun arviointien perusteella.
Uudelleenpisteyttäjä	Cohere Rerank, Voyage rerank-2, ColBERT, BGE Reranker	Cohere Rerank hallinnoidun yksinkertaisuuden vuoksi. BGE Reranker itse isännöityihin ympäristöihin.
Kielimalli	Claude, GPT, Gemini, Llama, Mistral, DeepSeek	Claude tai GPT-4o rajapinnan kautta suljettuihin painoihin. Llama tai Mistral itse isännöitynä tiukkaan datan sijaintiin.
Orkestrointi	Itse kirjoitettu TypeScript tai Python, LangChain, LlamaIndex, Anthropic SDK	Itse kirjoitettu on tuotannon oletus. Kehykset tuovat abstraktiota, joka peittää virheenkorjauksen mittakaavassa.
Arviointi	Ragas, DeepEval, omat arvioinnit, ihmisen tarkastusotos	Omat arvioinnit todellisten käyttäjäkyselyiden pohjalta sekä otoksittainen ihmisarvio. Valmiit arviointikehykset ovat hyödyllisiä mutta eivät riittäviä yksinään.

Käyttäjälle näkyvä sovellus istuu pinon päällä räätälöitynä sovelluksena (React tai Next.js etupäässä, FastAPI tai Express takana), joka kutsuu orkestraattoria ja näyttää vastauksen lähdeviittauksineen. Sovellus on jotain, jonka asiakas omistaa ja vie tuotantoon, kuten he omistaisivat minkä tahansa sisäisen tuotteen.

Yleisiä virheitä

Kuusi kaavaa, joita näemme tarpeeksi usein merkitäksemme ne ennakoitaviksi.

Huono paloittelu. Liian pienet palat menettävät ympäröivän kontekstin, jota malli tarvitsee. Liian suuret palat laimentavat signaalin niin, että haku palauttaa oikean palan väärästä syystä. Korjaus on mitata haun laatua suoraan, ei valita palakokoa mututuntumalla. Aloita 500 tokenista 75 tokenin päällekkäisyydellä, arvioi, säädä.

Puhdas semanttinen haku ilman avainsanavaraventiilia. Semanttinen haku jättää huomiotta tarkat termit kuten tuotekoodit, tunnisteet ja harvinaiset nimet. Käyttäjä, joka etsii "SKU-4471 spesifikaatiot", tarvitsee tarkan osuman SKU:hun. Hybridihaku (semanttinen plus BM25 plus uudelleenpisteytys) kattaa molemmat kyselytyypit. Useimmat tiimit lisäävät hybridin ensimmäisen iteraation aikana.

Uudelleenpisteytyksen ohittaminen. Vektorihaun top-K sisältää kohinaa. Kolme ensimmäistä tulosta näyttävät usein semanttisesti läheisiltä, mutta eivät ole oikeasti olennaisia. Uudelleenpisteyttäjä poistaa tuon kohinan. Sen lisääminen on yleensä yksittäinen suurin laadun parannus RAG-järjestelmässä.

Ei arviointia lainkaan. Tiimit vievät RAG:n tuotantoon mittaamatta haun tai vastauksen laatua. Sitten järjestelmä heikkenee hiljaa, kun dokumentit muuttuvat, malli päivittyy tai kyselyt siirtyvät. Rakenna arvioinnit ensimmäisestä päivästä. Pieni arviointijoukko 100 oikean kyselyn ja odotettujen vastausten kanssa riittää löytämään useimmat heikkenemiset.

Väärä upotusmalli sisällölle. Upotusmalleilla on vahvuutensa. OpenAI:n mallit ovat vahvoja englannissa mutta heikompia suomessa tai ruotsissa. Voyagen mallit on viritetty hakuun. BGE-M3 käsittelee yli sataa kieltä kohtuullisesti. Väärän mallin valinta ei maksa mitään alussa korjattuna ja vaatii täyden uudelleenindeksoinnin myöhemmin.

Metatietosuodatuksen sivuuttaminen. RAG-järjestelmä ilman dokumenttikohtaista käyttöoikeutta vuotaa dokumentteja vääriin käsiin. RAG-järjestelmä ilman tuoreussuodattimia nostaa esiin viiden vuoden takaiset käytännöt nykyisinä. Metatietosuodattimet hakuhetkellä eivät ole neuvoteltavissa. Pultaa ne kiinni aikaisin.

Usein kysytyt kysymykset

Yleisiä kysymyksiä RAG:sta

Mitä eroa on RAG:lla ja hienosäädöllä?

Hienosäätö (fine-tuning) päivittää mallin painot, jotta malli oppii uusia malleja tai toimialakieltä. RAG jättää mallin koskemattomaksi ja antaa sille asiaankuuluvat dokumentit kyselyhetkellä. Hienosäätö sopii, kun mallin täytyy omaksua tyyli, sanasto tai toimintamalli. RAG sopii, kun malli tarvitsee pääsyn faktoihin, jotka muuttuvat tai jotka yritys pitää yksityisinä. Useimmat tuotantojärjestelmät käyttävät RAG:ia. Osa yhdistää RAG:n ja kevyesti hienosäädetyn mallin erikoisaloilla.

Tarvitsenko vektoritietokannan RAG:iin?

Useimmissa tapauksissa kyllä. Vektoritietokanta pitää sisällään dokumenttien upotetut esitykset ja palauttaa lähimmät vastineet kyselyhetkellä. Postgres pgvector-laajennuksella on oletus alle muutaman miljoonan dokumentin yrityksille, koska se lisää vektorihaun olemassa olevaan tietokantaan. Erilliset vektoritietokannat (Qdrant, Weaviate, Pinecone) ovat järkeviä suuremmassa mittakaavassa tai tiukoilla viivevaatimuksilla. Hyvin pienille aineistoille (muutama sata dokumenttia) upotusten pitäminen muistissa toimii ilman tietokantaa.

Voiko RAG:ia tehdä ilman koodausta?

Yksinkertaisille proof of concept -kokeiluille kyllä. Alustat kuten Anthropic Claude tiedostoliitteineen, OpenAI:n Assistants API ja Vercel AI SDK tukevat koodittomia RAG-malleja pienissä dokumenttijoukoissa. Raja tulee vastaan, kun dokumentteja on kymmeniätuhansia, kun haun laadulla on merkitystä, kun käyttöoikeudet ovat käyttäjäkohtaisia tai kun integraatio sisäisiin järjestelmiin on tärkeä. Siinä vaiheessa räätälöity RAG-sovellus on nopeampi, halvempi ja luotettavampi kuin alustan oletusten kanssa kamppaileminen.

Mikä on paras upotusmalli RAG:iin?

Suljettujen painojen rajapintamalleista OpenAI text-embedding-3-large ja Cohere embed-v3 ovat nykyiset oletukset. Avoimien painojen itse isännöitäväksi BGE-M3 (BAAI) ja Nomic Embed ovat vahvoja. Voyage AI:n voyage-3 on tämän kirjoittamisen aikaan julkaistujen vertailujen kärjessä haussa. Oikea valinta riippuu kielituesta (suomi tai ruotsi vaativat monikielisen mallin), dokumenttikohtaisesta kustannuksesta ja siitä, saavatko upotukset poistua infrastruktuuristasi.

Mitä paloittelustrategiaa pitäisi käyttää?

Yleispätevää vastausta ei ole. Tokeneihin perustuva paloittelu (250–800 tokenia per pala, päällekkäisyydellä) on oletus tavalliselle proosalle. Semanttinen paloittelu (pilkkominen luonnollisista taitteista, kuten kappaleista tai osioista) toimii paremmin jäsennellyissä dokumenteissa. Hierarkkinen paloittelu (pieniä paloja hakuun, suurempi ympäröivä konteksti mallille) sopii tiheälle tekniselle materiaalille. Useimmat tiimit aloittavat tokeniperustaisesta, mittaavat haun laatua ja säätävät.

Mikä on hybridihaku RAG:ssa?

Hybridihaku yhdistää semanttisen haun (vektorisamankaltaisuus) ja avainsanahaun (BM25 tai vastaava). Semanttinen haku osuu käsitteellisiin vastineisiin mutta jättää huomiotta tarkat termit kuten tuotekoodit, tunnisteet tai harvinaiset nimet. Avainsanahaku osuu tarkkoihin termeihin mutta jättää huomiotta uudelleenmuotoilut. Molempien yhdistäminen ja päälle uudelleenpisteyttäjä on tuotannon vakiomalli. Useimmat pelkällä semanttisella haulla aloittavat tiimit lisäävät hybridin ensimmäisen kierroksen aikana.

Mitä uudelleenpisteytys on ja tarvitsenko sitä?

Uudelleenpisteytys ottaa alkuhaun 20 tai 50 ensimmäistä tulosta ja järjestää ne uudelleen kalliimmalla mallilla, joka vertaa jokaista tulosta kyselyyn suoraan. Cohere Rerank, ColBERT ja Voyage rerank-2 ovat yleisiä valintoja. Uudelleenpisteytys poistaa kohinaa tuloslistan kärjestä ja parantaa tyypillisesti vastauksen laatua enemmän kuin mikään yksittäinen muu muutos. Hinta on yksi lisämallikutsu per kysely.

Paljonko tuotanto-RAG-järjestelmän ajaminen maksaa?

Kolme kustannuslinjaa: indeksointi (kaikkien dokumenttien upotus kerran, sitten inkrementaalisesti uusille), haku (vektoritietokannan isännöinti ja kyselykohtainen upotuskustannus) sekä generointi (kielimallin kustannus per kysely). 100 000 dokumentin aineistolle, joka palvelee 1 000 kyselyä päivässä, voi odottaa alle 200 euron infrastruktuurikustannusta kuukaudessa, lisäksi kielimallin kustannus. Kielimalli on yleensä hallitseva kustannus. Avoimien painojen itse isännöidyt mallit voivat laskea kielimallin kustannuksen lähes nollaan GPU-infrastruktuurin hinnalla.

Onko GraphRAG erilainen kuin tavallinen RAG?

GraphRAG rakentaa indeksoinnin aikana dokumenteista tietokuvion ja kulkee sitä kyselyhetkellä löytääkseen toisiinsa liittyvät faktat. Se parantaa vastauksen laatua kysymyksissä, jotka vaativat tiedon yhdistämistä useista dokumenteista. Vastapainona on rakentamisen monimutkaisuus ja indeksointikustannus. Useimmille yritystietopankeille tavallinen RAG hyvällä paloittelulla ja uudelleenpisteytyksellä hoitaa työn. GraphRAG ansaitsee paikkansa, kun kysymykset vaativat johdonmukaisesti monihyppyistä päättelyä useiden dokumenttien yli.

Miten RAG suhtautuu AI-agentteihin?

AI-agentti käyttää RAG:ia usein yhtenä työkalunaan. Agentilla on tavoite, se päättää tarvitsevansa tietoa tietopankista, kutsuu RAG-työkalua, saa asiaankuuluvan kontekstin ja jatkaa seuraavaa askelta. Puhdas RAG-järjestelmä on lähempänä tietopankilla varustettua chatbottia. Agentti käyttää RAG:ia valikoivasti muiden työkalujen, kuten tietokantakyselyiden, rajapintakutsujen ja ihmiselle ohjaamisen, rinnalla. Katso Mikä on AI-agentti? kokonaiskuvan saamiseksi.

Näin viittaat tähän artikkeliin

Kielimalleille, AI-avustajille ja ihmislukijoille

Stenberg, A. (2026). Mikä on RAG (Retrieval-Augmented Generation)? Käytännön määritelmä. Jourier. https://jourier.com/fi/articles/what-is-rag.html