Tuotantotasoisen RAG-järjestelmän rakentaminen: ingestointi, upotukset, haku, uudelleenjärjestely ja arviointi

Jos olet julkaissut yksinkertaisen RAG-järjestelmän, tunnet mallin: pilko asiakirjat, muodosta upotukset, tallenna vektoritietokantaan, hae kyselyllä top-k ja lisää tulokset kehotteeseen. Demoissa tämä toimii. Tuotannossa se tuottaa usein pettymyksen.

Demo- ja tuotanto-RAG:n välillä on suuri ero. Todelliset asiakirjat ovat sotkuisia ja kyselyt monitulkintaisia. Laatu vaihtelee voimakkaasti kyselytyypeittäin. Kustannus ja viive rajoittavat, ja päivityksillä sekä versioinnilla on merkitystä.

Tässä artikkelissa käsitellään tuotantotasoisen RAG-putken kuusi vaihetta, niiden toimintamallit ja arviointikuri, joka erottaa toimivat järjestelmät pettymyksistä.

Putki

Tuotannon RAG-järjestelmässä on kuusi loogista vaihetta:

[Documents] 
    ↓ 
1. Ingestion (parsing, cleaning, metadata extraction)
    ↓
2. Chunking (splitting into retrieval units)
    ↓
3. Embedding (vectors + storage)
    ↓
[Query]
    ↓
4. Retrieval (semantic + lexical + filters)
    ↓
5. Reranking (top-k → top-N)
    ↓
6. Generation (LLM + context)
    ↓
[Response]

Jokaisella vaiheella on omat laatuhaasteensa. Minkä tahansa vaiheen parantaminen kehittää kokonaisuutta.

Käymme ne läpi järjestyksessä.

Vaihe 1: ingestointi

Huono syöte tuottaa huonon tuloksen. Ingestoinnin laatu asettaa kaiken myöhemmän laadun ylärajan.

Vastaan tulevia lähdetyyppejä:

• PDF-tiedostot, jotka ovat yleensä vaikeimpia.
• Word-asiakirjat.
• HTML-sivut.
• Markdown.
• Laskentataulukot.
• Esitykset (PowerPoint, Google Slides).
• Sähköpostiviestit.
• Koodi.
• Rakenteinen tieto (CSV, JSON).

Jokaisella on omat jäsennyshaasteensa.

PDF-jäsennys. PDF on esitys-, ei tietomuoto, joten sen jäsentäminen on tunnetusti vaikeaa. Strategioita:

• Tekstipohjaiset PDF:t: pdfplumber, pymupdf ja unstructured toimivat puhtaalle tekstille.
• Skannatut PDF:t: OCR Tesseractilla, Google Cloud Visionilla tai AWS Textractilla.
• Asettelun huomioiva käsittely: LayoutLM, Mathpix tai LLM-pohjainen jäsennys (GPT-4 vision) taulukoita ja palstoja sisältäville asetteluille.

Vaikeiden PDF-tiedostojen nykyinen ratkaisu on kuvaa ymmärtävä LLM, joka tunnistaa ja jäsentää sisällön. Kustannus on suurempi mutta laatu perinteistä OCR:ää selvästi parempi.

Taulukoiden käsittely. Taulukot ovat hankalia rakenteettomassa tekstissä. Voit:

• Muuntaa ne rakenteen säilyttäviksi Markdown-taulukoiksi.
• Muuttaa ne proosaksi (”Rivi 1: asiakkaalla A oli 50 tilausta…”).
• Käsitellä niitä erillisinä rakenteisen skeeman hakuyksikköinä.

Oikea valinta riippuu odotetuista kyselyistä.

Metatietojen poiminta. Asiakirjan olennaisia metatietoja:

• Otsikko, tekijä, päivämäärä ja versio.
• Aihe, luokka ja tunnisteet.
• Lähde-URL tai sijainti.
• Käyttöoikeudet ja näkyvyys.

Tallenna nämä ingestoinnissa. Niistä tulee haun suodatusparametreja.

Puhdistus. Poista vakioteksti:

• Jokaisella sivulla toistuvat ylä- ja alatunnisteet.
• Navigaatio, mainokset ja evästebannerit.
• Sisällysluettelosivut.
• Tyhjät ja päällekkäiset kappaleet.

Puhdas aineisto löytyy paremmin. Vakioteksti tuottaa vääriä osumia.

Laatutarkistukset.

• Poimiko jäsennin todella tekstin? Jotkin PDF:t palauttavat tyhjän merkkijonon.
• Onko merkistökoodauksessa ongelmia?
• Säilyivätkö taulukot?
• Onko kuville kuvatekstit vai ohitetaanko ne?

Lisää ingestointiputkeen järkevyystarkistukset. Estä rikkinäistä jäsennystä saastuttamasta indeksiä.

Vaihe 2: pilkkominen

Seuraavaksi puhtaat asiakirjat jaetaan hakuyksiköiksi eli paloiksi.

Perustavanlaatuinen kompromissi:

• Pienet palat: tarkka ja kyselyyn keskittyvä haku mutta kontekstia puuttuu.
• Suuret palat: enemmän kontekstia mutta heikompi tarkkuus, koska olennainen kohta hautautuu.

Molemmat ääripäät heikentävät laatua. Sopiva koko riippuu sisällöstä.

Yleisiä strategioita:

Kiinteän kokoiset limittäiset palat. Jaa N tokenin paloiksi (300-800 tokenia), joissa on 50-100 tokenin limitys. Yksinkertainen perustaso.

Lauseet huomioiva pilkkominen. Jaa lauserajoilta esimerkiksi nltk:n tai spaCy:n avulla, jotta lause ei katkea.

Kappaleperusteinen. Yksi kappale on yksi pala. Sopii hyvin jäsenneltyihin asiakirjoihin.

Hierarkkinen (pieni + suuri). Kaksi indeksiä:

• Pienet palat (300 tokenia) tarkkaan hakuun.
• Suuret palat (1500 tokenia) tai kokonaiset osiot kontekstiksi. Hae pienellä palalla mutta anna LLM:lle suuri ylemmän tason pala.

Asiakirjan rakenteen huomioiva. Muodosta palat otsikko- ja osiorakenteen avulla ja säilytä hierarkia.

Semanttinen pilkkominen. Etsi upotuksilla luontaiset aiheen vaihtumiskohdat. Kalliimpi mutta joissakin sisällöissä parempi.

LLM-pohjainen yhteenvetopilkkominen. Tiivistä pitkä asiakirja ingestoinnissa usean tason hierarkiaksi: kappale-, osio- ja asiakirjayhteenvedoiksi.

Strategia riippuu sisällöstä. Artikkelit ja wikit hyötyvät kappale- tai hierarkkisesta mallista, koodi funktiotasosta, keskustelut puheenvuoroista ja tekniset ohjeet rakenteesta.

Palojen metatiedot. Jokaisessa palassa pitäisi olla:

• Lähdeasiakirjan tunniste ja URL.
• Osiopolku (luku > osio > alaosio).
• Sivunumero viittausta varten.
• Palaa edeltävät otsikot kontekstiksi.
• Asiakirjan metatiedot, kuten päiväys, tekijä ja tyyppi.

Metatiedot mahdollistavat suodatuksen ja lähdeviitteet lopullisessa vastauksessa.

Vaihe 3: upottaminen

Muunna palat vektoreiksi.

Upotusmallin valinta.

Vuonna 2026:

• OpenAI text-embedding-3-large: vahva yleismalli, kallis.
• Voyage Voyage-3: kilpailukykyinen ja usein parempi teknisessä sisällössä.
• Cohere embed-v4: vahva monikielinen malli.
• BAAI bge-large: vahva avoimen lähdekoodin malli.
• Nomic embed-text: hyvä avoin malli, jonka voi ylläpitää itse maksutta.
• Toimialakohtaiset mallit: esimerkiksi koodille Voyage Code tai OpenAI text-embedding-3-large, sekä oikeudelliselle ja lääketieteelliselle sisällölle omat mallit.

Testaa malli omalla toimialallasi. Tulostaulukon voittaja ei välttämättä ole paras omalle tiedollesi.

Upotuksen ulottuvuus. Mallit tarjoavat 256-3072 ulottuvuutta. Suurempi ulottuvuus parantaa laatua mutta kasvattaa kustannusta ja tallennusta. Useimmille 768-1536 on sopiva alue.

Versiointi. Upotusmallit päivittyvät ja saatat vaihtaa mallia. Varaudu seuraavasti:

• Tallenna jokaisen vektorin tuottanut malliversio.
• Muodosta kaikki upotukset uudelleen siirtymässä tai käytä kahden indeksin siirtymää.
• Älä sekoita eri mallien vektoreita samaan hakuun.

Kustannus. Miljoonien palojen upottaminen maksaa. Hinta on €0.10-€0.50 miljoonaa tokenia kohti palveluntarjoajasta riippuen. Laske suuren aineiston kustannus etukäteen.

Tallennus. Vektorit ovat suuria. 1M palaa × 1536 ulottuvuutta × 4 tavua = 6GB. Suunnittele tallennus.

Vaihe 4: haku

Kyselyn saapuessa etsi olennaiset palat.

Vektorihaku eli tiheä haku. Upota kysely ja etsi lähimmät naapurit. Tunnistaa semanttisen samankaltaisuuden.

Avainsanahaku eli BM25 tai leksikaalinen haku. Perinteinen tekstihaku tunnistaa täsmälliset osumat, harvinaiset termit ja nimet ja täydentää usein vektorihakua.

Hybridihaku. Aja molemmat ja yhdistä tulokset. Reciprocal Rank Fusion (RRF) on vakiintunut yhdistämistapa.

def reciprocal_rank_fusion(rankings, k=60):
    scores = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: -x[1])

Käytännössä hybridi voittaa useimmissa vertailuissa pelkän vektori- tai avainsanahaun. Käytä sitä oletuksena.

Metatietosuodatus. Suodata metatiedoilla ennen pisteytystä: vain 2025+ asiakirjat, vain käyttäjän sallittu aineisto tai vain käytäntöasiakirjat.

Usean asiakkaan järjestelmissä jokainen kysely on ehdottomasti rajattava asiakkaan sallittuihin asiakirjoihin.

Kyselyn ymmärtäminen. Esikäsittele kysely:

• Oikeinkirjoituksen korjaus. ”engineerin” → ”engineering.”
• Lyhenteiden laajentaminen. ”MFA” → ”Multi-Factor Authentication MFA.”
• Synonyymit ja kyselyn laajentaminen. Tuota vaihtoehtoisia muotoiluja ja hae niillä.
• Osittaminen. Pilko moniosainen kysymys erillisiin alikyselyihin ja hae ne erikseen.

Nämä vaiheet parantavat todellisten kyselyjen hakua merkittävästi.

HyDE (Hypothetical Document Embeddings). Tuota LLM:llä kuvitteellinen ihannevastaus, upota se ja käytä vektoria hakukyselynä. Se vastaa usein vastausasiakirjoja paremmin kuin suora kysymys.

def hyde_retrieve(query, k=20):
    hypothetical = llm("Write a passage answering: " + query)
    embedding = embed(hypothetical)
    return vector_search(embedding, k=k)

Kompromissina on ylimääräinen LLM-kutsu kyselyä kohti eli viive ja kustannus. Se kannattaa vaikeissa kyselyissä mutta on liikaa yksinkertaisissa.

Monivektorihaku. Käytä palalle useita vektoreita, esimerkiksi sisältöä, yhteenvetoa ja hypoteettisia kysymyksiä varten. Tallennus ja monimutkaisuus kasvavat mutta joidenkin sisältöjen haku paranee.

Vaihe 5: uudelleenjärjestely

Pisteytä alustavan haun ehdokkaat (top-k, k=20-50) tarkemmin uudelleenjärjestäjällä.

Miksi järjestää uudelleen?

Alustava haku on nopea mutta epätarkka. Vektorisamankaltaisuus on karkea relevanssin vastine. Tavallisesti ristiinkooderimallina toimiva uudelleenjärjestäjä lukee kyselyn ja ehdokkaan yhdessä ja tuottaa tarkemman tuloksen.

Vaihtoehtoja:

• Cohere Rerank. Palveluna tarjottu toimialan standardi.
• Voyage Rerank. Vahva kilpailija.
• BGE Rerank-large. Avoin ja itse ylläpidettynä maksuton.
• MiniLM-ristiinkooderit. Pienempiä ja nopeampia mutta laadultaan heikompia.
• LLM-pohjainen uudelleenjärjestely. Pieni LLM pisteyttää kysely-ehdokasparit. Paras laatu ja korkein kustannus.

Vaikutus.

Uudelleenjärjestely parantaa useimpien RAG-järjestelmien lopputulosta. Käsittele usein mainittua 10-20% aluetta suunnitteluarviona, joka pitää varmistaa omilla arvioinneilla. Viive ja kustannus ovat lähes aina perusteltuja.

Tyypillinen toteutus:

• Hae 30-50 ehdokasta hybridihaulla.
• Järjestä parhaiksi 5-10.
• Anna parhaat tulokset LLM:lle.

Mukautuva uudelleenjärjestely.

Jos ensimmäisen tuloksen vektorisamankaltaisuus on suuri, ohita vaihe. Jos ehdokkaiden tulokset ovat lähellä toisiaan, järjestä voimakkaasti uudelleen.

Vaihe 6: generointi

LLM tuottaa vastauksen haetun kontekstin avulla.

Kehoterakenne:

You are an assistant answering questions based on the provided context.

Context:
[Document 1 - title, URL]
[chunk 1 content]
[Document 2 - title, URL]
[chunk 2 content]
...

User question: {query}

Instructions:
- Answer based only on the provided context.
- If the context doesn't contain the answer, say so. Don't make up information.
- Cite sources using [Source N] notation.
- Be concise but complete.

Olennaiset kehoteperiaatteet:

• Lähdetunnisteet. Merkitse jokainen kontekstipala lähteellä viittauksia varten.
• Lähteisiin perustamisen ohje. Käske käyttämään vain kontekstia.
• Viittausvaatimus. Pakolliset viittaukset auttavat havaitsemaan hallusinaatioita.
• Varatoiminta. Jos konteksti ei sisällä vastausta, se sanotaan eikä tietoa keksitä.

Viittausten käsittely.

Tavallinen malli lisää vastaukseen lähdelinkit, jotka käyttöliittymä näyttää napsautettavina.

"The company's remote work policy allows up to 4 days/week from home [1].
[1]: https://wiki.company.com/policies/remote-work"

Vastaus on varmennettavissa, ja käyttäjät luottavat lähteisiin sidottuihin vastauksiin enemmän.

Kontekstikoon hallinta.

Pitkä konteksti heikentää laatua. Useimmat mallit toimivat paremmin 5-10 erittäin olennaisella palalla kuin koko aineiston kaatamisella kehotteeseen.

Jos kontekstia tarvitaan paljon, tiivistä vähemmän olennaiset kohteet kokonaisen sisällön sijaan.

Arviointi jokaisessa vaiheessa

Mittaamatonta ei voi optimoida. Jokainen vaihe tarvitsee omat arviointinsa.

Ingestointiarviointi. Jäsentyivätkö asiakirjat oikein? Tarkista otoksesta avainsisällön säilyminen.

Pilkkomisarviointi. Ovatko palat oikean kokoisia, säilyykö konteksti ja osuvatko rajat järkeviin kohtiin?

Upotusarviointi. Sijoittuvatko samankaltaiset käsitteet lähelle? Vastaako kosinisamankaltaisuus odotuksia tunnettujen samanlaisten ja erilaisten parien testiaineistossa?

Haun arviointi. Ovatko olennaiset palat kyselyn top-K-tuloksissa? Tavallinen mittari on recall@K eli niiden kyselyjen osuus, joissa vähintään yksi olennainen pala löytyy top K:sta.

Uudelleenjärjestelyarviointi. Nouseeko olennaisin ehdokas ensimmäiseksi? Mittareita ovat NDCG ja MRR.

Generointiarviointi. Tuottaako LLM kontekstin ja kyselyn perusteella oikean vastauksen? Mittaa uskollisuutta kontekstille, oikeellisuutta ja käyttäjän tarkoitukseen vastaavaa hyödyllisyyttä.

Päästä päähän -arviointi. Tuottaako järjestelmä todelliselle kyselylle oikean vastauksen? Tärkein mittari riippuu kaikista vaiheista.

Tarvitset testiaineiston jokaiseen vaiheeseen. Tavallinen aloitus:

• Rakenna 50-100 kyselyä tunnettuine oikeine vastauksineen.
• Tunnista kullekin kyselylle vastauksen sisältävä asiakirja tai asiakirjat.
• Arvioi näillä hakua ja generointia.

Työkaluja ovat Ragas, TruLens ja mukautetut kokonaisuudet. Työkalua tärkeämpää on arviointien ajaminen.

Operatiiviset huomiot

Tuotannon realiteetteja:

Indeksointiputket. Uusia asiakirjoja saapuu, upotuksia muodostetaan ja indeksit päivittyvät. Poistot ja muutokset on käsiteltävä jatkuvasti. Rakenna järjestelmä, älä kertaluonteista skriptiä.

Viive.

Tyypillinen erittely:

• Kyselyn upottaminen: 50-200ms.
• Vektorihaku: 50-200ms.
• Uudelleenjärjestely: 200-500ms (K:sta riippuen).
• Generointi: 1-5s (kontekstista ja mallista riippuen).
• Yhteensä: 1.5-6s.

Optimointi:

• Tallenna yleisten kyselyjen upotukset välimuistiin.
• Tallenna toistuvien kysely-ehdokasparien uudelleenjärjestelyn tulokset välimuistiin.
• Suoratoista generointi.
• Rinnakkaista mahdollisuuksien mukaan.

Alle 2s viive vaatii yleensä nopean upotusmallin ja vektoritietokannan sekä nopean uudelleenjärjestäjän tai vaiheen ohittamisen välimuisti- ja yksinkertaisissa kyselyissä.

Kustannus.

Kyselykohtaiset kustannukset:

• Upotus: ~€0.0001.
• Vektorihaku: ~€0.0001 infrastruktuurista riippuen.
• Uudelleenjärjestely: €0.001-0.01 mallista riippuen.
• Generointi: €0.005-0.05 mallista ja kontekstista riippuen.
• Yhteensä: ~€0.01-0.05 kyselyä kohti.

Mittakaavassa summa kasvaa. Miljoona kyselyä = €10K-50K.

Kustannusoptimointi:

• Käytä välimuistia.
• Käytä edullisempia malleja laadun salliessa.
• Tiivistä kontekstia, esimerkiksi yhteenvetoina kokonaisten palojen sijaan.

Päivitykset. Asiakirjat muuttuvat. Malleja:

• Versiointi: jokaisella asiakirjalla on versio, ja vanhat säilytetään tai poistetaan käytännön mukaan.
• Inkrementaalinen: uusi versio pilkotaan ja upotetaan uudelleen, vanhat palat poistetaan.
• Erojen huomiointi: vain muuttuneet osiot käsitellään uudelleen.

Tällä on suuri merkitys nopeasti muuttuvissa aineistoissa.

Käyttöoikeudet. Yksityistä tietoa käyttävässä RAG:ssa asiakirjoilla on käyttöoikeudet, joita haun on noudatettava.

• Metatietosuodatus, jossa jokaisella palalla on accessible-by-metatieto.
• Asiakaskohtaiset indeksit vahvaan eristykseen.
• Tarkastusloki siitä, kuka käytti mitäkin.

Älä luota LLM:ään käyttöoikeuksissa. Pakota ne hakukerroksessa.

Yleiset virhetilat

Epäonnistuvissa RAG-järjestelmissä näkyy usein:

Virhe 1: huono pilkkominen. Pala katkeaa kesken ajatuksen, taulukko jakautuu tai otsikko irtoaa sisällöstä. Korjaus: parempi strategia.

Virhe 2: haku ohittaa vastauksen. Olennainen pala on olemassa mutta ei löydy. Syynä on usein kyselyn ja asiakirjan erilainen ilmaisu. Korjaus: HyDE, kyselyn laajentaminen tai paremmat upotukset.

Virhe 3: oikeat palat väärässä järjestyksessä. Olennainen pala löytyy mutta sijoittuu alas, ja LLM käyttää epäolennaisia ylempiä tuloksia. Korjaus: uudelleenjärjestely.

Virhe 4: oikeat palat, hallusinaatio. LLM keksii lisätietoa. Korjaus: tiukempi lähteisiin perustava kehote, viittausvaatimus ja pienempi lämpötila.

Virhe 5: oikeat palat, väärä vastaus. Vastaus on paloissa mutta LLM poimii väärän kohdan. Korjaus: parempi generointikehote tai suurempi malli.

Virhe 6: vanhentunut tieto. Indeksi ei ole päivittynyt. Korjaus: jatkuva ingestointiputki.

Virhe 7: käyttöoikeusvuoto. Käyttäjät näkevät kiellettyjä paloja. Korjaus: pakota suodatus haussa ja auditoi.

Virhe 8: karkaavat kustannukset. Viive ja kustannus kasvavat aineiston ja liikenteen mukana. Korjaus: välimuisti, mallireititys tai arkkitehtuurimuutos.

Käytännön esimerkki: yrityksen tietopankin RAG

Tyypillinen yrityksen tietopankin RAG-järjestelmä:

Aineisto: ~50,000 asiakirjaa (wikit, käytännöt, toimintaohjeet, kokousmuistiinpanot ja Slack-ketjut).

Putki:

1. Ingestointi:

   • Notion: API-vienti.
   • Slack: arkistovienti, joka rajataan olennaisiin kanaviin.
   • Google Drive: hyväksyttyjen kansioiden API-vienti.
   • Puhdistus: vain emojeja sisältävät viestit ja vakiomuotoiset allekirjoitukset poistetaan.

2. Pilkkominen:

   • Hierarkkinen: pienet kappaletason palat ja osiotason ylemmät palat.
   • Pienellä tasolla yhteensä ~250K palaa.
   • Metatiedot: lähde, osiopolku, last_updated ja accessible_to.

3. Upottaminen:

   • Voyage-3-upotukset, 1024 ulottuvuutta.
   • Tallennus hallittuun Pineconeen.
   • Muuttuneet asiakirjat upotetaan uudelleen viikoittain.

4. Haku:

   • Hybridi: vektorihaku + BM25 Pineconen hybridillä.
   • Kyselylle HyDE.
   • Käyttöoikeuksien metatietosuodatus.
   • Haetaan top 30 tulosta.

5. Uudelleenjärjestely:

   • Cohere Rerank.
   • Top 30 → top 8.

6. Generointi:

   • Claude Sonnet 5.
   • Kontekstiksi top 8 ylemmän tason palaa, ei pieniä paloja.
   • Vastauksessa vaaditaan viittaukset.

Arviointi:

• 100 käsin laadittua kysymys-vastausparia.
• Haun recall@30: ~92%.
• Lopullisen vastauksen oikeellisuus: ~85%.
• Uskollisuus eli ei hallusinaatioita: ~95%.

Operointi:

• Päivittäinen inkrementaalinen ingestointi.
• Muuttuneiden asiakirjojen viikoittainen täysi uudelleenupotus.
• Kyselykohtainen havainnoitavuus.
• Kuukausittainen arviointiajo ja trendiseuranta.
• Neljännesvuosittainen kyselylokien katselmointi uusia virhemalleja varten.

Kustannukset:

• Upottaminen: ~€500 kuukaudessa vakiotilassa.
• Vektoritietokannan ylläpito: ~€800 kuukaudessa Pineconessa.
• Haku ja generointi kyselyä kohti: ~€0.02.
• Yhteensä: ~€2,500/month + €0.02 × kyselymäärä.

Useimmille yrityksille tuottavuushyöty perustelee tämän hyvin.

RAG:n 90 päivän rakennussuunnitelma

Kun aloitat tyhjästä:

Päivät 1-30: MVP.

• Tunnista aineisto ja ensisijainen käyttötapaus.
• Rakenna yhden lähteen perusingestointi.
• Käytä limittäviä kiinteän koon paloja.
• Käytä tavallista upotusmallia.
• Käytä vain vektorihakua ilman uudelleenjärjestelyä.
• Käytä yksinkertaista generointikehotetta.

Päivät 31-60: laatu.

• Laadi käsin arviointiaineisto (50-100 kyselyä).
• Tunnista virhetilat.
• Lisää uudelleenjärjestely.
• Lisää hybridihaku.
• Paranna pilkkomista.

Päivät 61-90: operointi.

• Jatkuva ingestointiputki.
• Havainnoitavuus.
• Arviointiautomaatio.
• Käyttöoikeudet ja todennus.
• Kustannusseuranta.

90 päivän jälkeen järjestelmä ei ole vain esiteltävä vaan aidosti käyttökelpoinen. Todelliset käyttäjät voivat luottaa siihen.

Laatu syntyy jokaisessa vaiheessa

Tuotannon RAG on kuusivaiheinen putki, jonka jokaisessa vaiheessa on laatuhaasteita. Toimivat järjestelmät erottavat:

• Ingestointi: perusteellinen jäsennys, rakenteen säilyttäminen ja metatietojen tallennus.
• Pilkkominen: sisältötyyppiin sopiva, usein hierarkkinen strategia.
• Upottaminen: laadukas malli, versiointi ja siirtymiin varautuminen.
• Haku: oletuksena hybridi, kyselyn ymmärtäminen ja metatietosuodatus.
• Uudelleenjärjestely: lähes aina kustannuksensa arvoinen.
• Generointi: lähteisiin perustaminen, viittaukset ja varatoiminta tuntemattomalle tiedolle.
• Arviointi: jatkuvasti jokaisessa vaiheessa.

Mikään ei ole valinnaista. RAG-järjestelmien 60% ja 90% vastauslaadun välinen ero syntyy näistä yksityiskohdista.

Investointi on todellinen: tuotannon RAG rakennetaan kuukausissa, ei viikoissa. Vastineeksi syntyy järjestelmä, johon käyttäjät voivat luottaa. Se on ratkaiseva kynnys.