Tuotannon RAG-suunnittelu: aineiston tuonti, 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ämä on tuotantosuunnittelun tarkistuslista, jossa on kuusi loogista vaihetta ja kunkin vaiheen tarvitsemat mittaukset. Kyse ei ole toistettavasta AIExpertin vertailutestistä. Aloita alkuperäisestä RAG-tutkimuksesta, tutustu mittarivalintoihin heterogeenisen BEIR-hakuvertailun avulla ja rakenna omasta aineistostasi yksityinen arviointijoukko ennen komponenttien valintaa.

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 kuvaa ymmärtävä LLM 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.

Kumpikin ääripää voi heikentää laatua joillakin kyselyjakaumilla. Valitse palojen rajat ja ylemmän tason konteksti merkittyjen haku- ja vastaustulosten perusteella asiakirja- ja kyselyosituksittain.

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.

Mahdollisia malliperheitä ovat OpenAI:n upotusmallit, Voyagen upotukset, Cohere Embed sekä avoimen painon BGE- ja Nomic-mallit. Nimet, ulottuvuudet, lisenssit, hinnat ja tuetut syötetyypit muuttuvat. Kokoa lyhytlista nykyisestä OpenAI:n upotusoppaasta, Voyagen dokumentaatiosta, Cohere Embedin dokumentaatiosta ja kunkin avoimen painon mallin mallikortista.

Mallin valinta: testaa se omalla toimialallasi. Älä oleta, että tulostaulukon voittaja on paras omalle tiedollesi.

Upotuksen ulottuvuus. Ulottuvuus vaikuttaa tallennus- ja indeksointikustannukseen, mutta suurempi vektori ei takaa parempaa hakua. Osa rajapinnoista tukee lyhentämistä, osa malleista käyttää kiinteää ulottuvuutta. Vertaa tuettuja ulottuvuuksia samoilla merkityillä kyselyillä ja ota indeksin koko ja viive mukaan päätökseen.

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. Laske alkuindeksointi ja muutosvolyymi mitatuista tokeneista, päivätystä palveluntarjoajan hinnasta, uudelleenyritysten osuudesta, OCR- ja jäsennyslaskennasta, vektoritallennuksesta, replikoista ja uudelleenupotusten tiheydestä. Säilytä lähteen URL ja voimaantulopäivä laskelman vieressä; tämä artikkeli ei tarkoituksella toista hintaa, joka vanhenee.

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 voi parantaa ehdokkaiden järjestystä, mutta hyöty riippuu ensimmäisen vaiheen hakijasta, ehdokkaiden määrästä, korpuksesta, kyselyjakaumasta ja mittarista. Pidä se mukana vain, jos merkitty arviointi osoittaa laatuhyödyn perustelevan viiveen ja kustannuksen.

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:

Olet avustaja, joka vastaa kysymyksiin annetun kontekstin pohjalta.

Konteksti:
[Asiakirja 1 - otsikko, URL]
[palan 1 sisältö]
[Asiakirja 2 - otsikko, URL]
[palan 2 sisältö]
...

Käyttäjän kysymys: {query}

Ohjeet:
- Vastaa vain annetun kontekstin pohjalta.
- Jos konteksti ei sisällä vastausta, sano se. Älä keksi tietoa.
- Viittaa lähteisiin merkinnällä [Lähde N].
- Ole ytimekäs mutta kattava.

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.

"Yrityksen etätyökäytäntö sallii enintään 4 päivää viikossa kotoa [1].
[1]: https://docs.example.invalid/policies/remote-work"

Tämä tuo lähteen sijainnin näkyviin. Se ei todista lähdettä ajantasaiseksi, valtuutetuksi tai oikein tulkituksi. Sovelluksen on avattava todellinen lähde-URL, johon nykyisellä käyttäjällä on oikeus. Edellä oleva .invalid-verkkotunnus on tarkoituksella toimimaton esimerkkiosoite.

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.

Mittaa erikseen kyselyn upottaminen, ehdokkaiden haku, uudelleenjärjestely, generoinnin aika ensimmäiseen tokeniin ja valmiiseen vastaukseen sekä verkon rasite. Raportoi kylmät ja lämpimät jakaumat suunnitellulla samanaikaisuudella; komponentin nimestä ei voi päätellä viiveen suuruusluokkaa.

Optimointi:

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

Jos tuotteella on viivetavoite, jaa mitattu budjetti kyselyn käsittelyyn, hakuun, uudelleenjärjestelyyn, generointiin ja verkon rasitteeseen. ”Alle kahden sekunnin” käyttäytymistä ei voi päätellä komponenttien nimistä; testaa kylmä ja lämmin polku odotetulla samanaikaisuudella.

Kustannus.

Kohdista jokaiselle arvioidulle kyselylle kyselyn upottaminen, haku- ja indeksikapasiteetti, uudelleenjärjestely, generoidut ja syötetyt tokenit, välimuistin tila sekä uudelleenyritykset. Yhdistä sitten havaittu jakauma – ei yhtä keskiarvoa – ennustetulla liikennemäärällä. Miljoonan kyselyn kustannus voi vaihdella radikaalisti asiakirjojen koon, ehdokkaiden määrän, mallin, tuotoksen pituuden, välimuistin käyttäytymisen ja infrastruktuurisitoumusten mukaan.

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.

Mallinnettu suunnitelma: yrityksen tietopankin RAG

Tämä on kokoonpanon suunnittelupohja, ei käyttöönotettu AIExpert-tulos tai väite tyypillisestä yrityksestä. Jokainen jäljempänä mainittu määrä, tuote, aikataulu ja ehdokassyvyys on havainnollistava oletus, joka on korvattava mitatuilla lähtötiedoilla.

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.

Arviointisuunnitelma (aseta raja-arvot liiketoiminnan virhebudjetista):

• 100 käsin laadittua kysymys-vastausparia.
• Haun recall valitulla ehdokassyvyydellä, raportoituna kyselyosituksittain; päätä vaadittu arvo ennen virittämistä.
• Lopullisen vastauksen oikeellisuus ja haun recall: raportoi molemmat ja tarkastele niiden eroa olettamatta, kumpi on matalampi.
• Uskollisuus eli ei hallusinaatioita: seuraa erillään oikeellisuudesta.

Havainnollistava operointirytmi (johda todellinen rytmi lähteiden muutostahdista ja riskistä):

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

Kustannusmalli (täytä päivätyillä laskuilla tai voimassa olevilla tarjouksilla):

• Ingestointi: muuttuneet tokenit × upotuksen hinta, sekä jäsennys- ja OCR-laskenta.
• Haun tallennus: indeksoidut tavut, replikat, varmuuskopiot sekä varattu tai käytön mukainen kyselykapasiteetti.
• Kyselyä kohti: upotus + haku + uudelleenjärjestely + mallin syöte ja tuotos + verkko- ja työkalumaksut.
• Operointi: insinöörityö, arviointien merkitseminen, häiriöiden käsittely ja tietolähteiden ylläpito.

Hyväksy kustannus vasta, kun mitattu tehtävätulos ja säästynyt työ perustelevat koko kustannusmallin; pelkät hakutulosmittarit eivät osoita tuottoa.

Vaiheportein etenevä RAG:n rakennussuunnitelma

Kun aloitat tyhjästä:

Vaihe 1: rajattu prototyyppi.

• 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.

Vaihe 2: laatunäyttö.

• Laadi merkitty arviointiaineisto, jonka koko säilyttää tärkeät kysely- ja riskiositukset.
• Tunnista virhetilat.
• Lisää uudelleenjärjestely.
• Lisää hybridihaku.
• Paranna pilkkomista.

Vaihe 3: operatiivinen hyväksyntä.

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

Älä liitä näihin vaiheisiin kalenterilupausta. Etene vasta, kun nykyisen vaiheen testit menevät läpi: ensin lähdeuskollisuus ja käyttöoikeudet, sitten haun ja vastausten laatu, sitten tietoturva, tuoreus, poistot, kapasiteetti, palautuminen ja operatiivinen omistajuus.

Laatu syntyy jokaisessa vaiheessa

Tuotannon RAG on kuusivaiheinen putki, jonka jokaisessa vaiheessa on laatuhaasteita. Toimivat järjestelmät erottuvat pettymyksistä näillä malleilla:

• 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: vertaa leksikaalista, tiheää ja hybridihakua, suodattimia ja kyselymuunnoksia merkityllä aineistolla.
• Uudelleenjärjestely: lisää se vasta, kun mitattu laatuhyöty perustelee viiveen, kustannuksen ja monimutkaisuuden.
• Generointi: lähteisiin perustaminen, viittaukset ja varatoiminta tuntemattomalle tiedolle.
• Arviointi: jatkuvasti jokaisessa vaiheessa.

Vaaditut kontrollit riippuvat työkuormasta ja riskistä, mutta jokaiselle ohitetulle vaiheelle tarvitaan nimenomainen perustelu ja korvaava testi. Julkaisu- tai käyttöönottoväitteissä on raportoitava arvioitu aineisto, kyselyositukset, mittarit, virhetapaukset, käyttöoikeusmalli ja päiväys – ei perustelematonta onnistumisprosenttia tai toimitusaikataulua.