Mikä on RAG? Ratkaisu yrityksen dokumenteille: mitä se voi ja mitä ei

RAG voi hakea katkelmia yrityksen dokumenteista ja laatia lähteisiin sidottuja vastauksia, mutta se ei ole mallin koulutusta, totuuskone eikä käyttöoikeuksien korvike.

Maanantaiaamuna henkilöstöpäällikkö kysyy sisäiseltä avustajalta, kuinka kauan hakijoiden tietoja on säilytettävä, ja saa vakuuttavan vastauksen sekä linkin yrityksen politiikkaan; ainoa ongelma on, että löydetty versio lakkasi olemasta voimassa kahdeksan kuukautta sitten. Tällainen ratkaisu voi teknisesti olla tehnyt kaiken, mitä siltä pyydettiin, mutta jotta ymmärtää, mikä on RAG yrityksen dokumenttien yhteydessä, on huomattava, mitä se teki: se löysi semanttisesti samankaltaisen katkelman, liitti sen mallin kontekstiin ja kirjoitti sujuvan vastauksen. Se ei silti tarkistanut, onko tiedosto uusin hyväksytty versio, jos version tilaa ei ole merkitty indeksiin luotettavasti.

Lyhenne RAG tulee sanoista retrieval-augmented generation ja tarkoittaa generointia, johon liitetään haettua ulkoista kontekstia vastausta laadittaessa; siinä yrityksen dokumentteja ei opeteta mallin painoihin, eikä kyse ole erillisestä ”älykkyyskerroksesta”, joka tietäisi automaattisesti, mikä dokumentti on totta. Se muistuttaa pikemminkin kirjastoa, jossa on erittäin nopea kirjastonhoitaja ja lahjakas toimittaja: kirjastonhoitaja voi tuoda väärän niteen, mutta toimittaja kirjoittaa siitä silti vakuuttavan kappaleen; alkuperäinen RAG-tutkimus erottaa nimenomaisesti mallin parametrisen muistin ulkoa haetusta ei-parametrisesta lähteestä.

Käytännön hyöty on huomattava, kun rajat nimetään rehellisesti: järjestelmä voi etsiä sopivia katkelmia hallitusta dokumenttikokoelmasta, koota niistä kysymykseen sopivan kontekstin ja laatia luonnoksen, jossa on tarkistettava lähdeviite. Vastuun rajan on näyttävä myös käyttäjälle: käyttöliittymä ei saa antaa vaikutelmaa, että lähteen olemassaolo on juridinen hyväksyntä, ja virheistä tai epäselvyyksistä ilmoittamisen on oltava yhtä helppoa kuin kysymyksen esittämisen. RAG ei voi korjata heikkolaatuista dokumentaatiota, taata tosiasiallista oikeellisuutta, toteuttaa käyttöoikeuksia itsestään eikä korvata determinististä työnkulkua ja ihmisen hyväksyntää tilanteissa, joissa virhe aiheuttaa oikeudellisen, taloudellisen, turvallisuuteen tai ihmisoikeuksiin liittyvän riskin; tämä raja ratkaisee sekä arkkitehtuurin että sen, mitä pilotissa on mielekästä mitata.

Miksi vanha politiikka voidaan hakea voimassa olevana

Vanhaa politiikkaa koskeva poikkeama ei ala kielimallista vaan dokumenttien hallinnasta: yhteisellä levyllä ovat ”Henkilotiedot_final.docx”, ”Henkilotiedot_final2.docx” ja hyväksytty PDF, mutta millään tiedostolla ei ole yhdenmukaista voimaantulopäivää, tilaa tai korvatun version tunnistetta; indeksi näkee kolme sisällöltään samankaltaista ehdokasta, ja semanttinen haku voi arvioida vanhan dokumentin korkealle, koska sen sanamuoto vastaa kysymystä tarkemmin. Malli ei näe organisaation kokouksessa tehtyä päätöstä, jos päätöstä ei ole aineistossa, eikä tiedostonimi ”final” ole hallintamekanismi.

Seuraukset ovat petollisia, koska vastaus voi näyttää tavallista hakutulosta paremmalta: se on lyhyt, kieliopillisesti oikea ja viittaa todelliseen dokumenttiin, minkä vuoksi tarkistus vaikuttaa jo tehdyltä. Lähdelinkki todistaa vain, että tietty tiedosto on näytetty vastauksen yhteydessä tai liitetty siihen; se ei vielä todista, että jokainen väite seuraa siteeratusta katkelmasta, ettei katkelmaa ole irrotettu poikkeuksia käsittelevästä kohdasta tai että dokumentti on oikeutettu toimimaan auktoritatiivisena lähteenä. NISTin GenAI-profiili ei pidä tällaista luotettavaa vaikutelmaa riittävänä riskienhallintana, vaan korostaa hallintaa järjestelmän koko elinkaaren ajan.

Korjaus on julkaisutila, versioketju ja prioriteettisäännöt, ei pidempi prompti: indeksissä jokaisella dokumentilla on oltava omistaja, alkamis- ja päättymispäivä, tila, korvattu dokumentti, osasto, salassapitoluokka ja tarkistuspäivä. Hakusuodattimen on oletusarvoisesti suljettava pois luonnokset ja vanhentuneet versiot; jos lähteet ovat ristiriidassa, järjestelmän on näytettävä ristiriita ja jätettävä yksi varma vastaus esittämättä, ja vastuullisen omistajan on saatava tehtäväksi dokumenttikokoelman järjestäminen. RAG voi tuoda kaaoksen näkyviin, mutta se ei voi muuttaa kaaosta politiikaksi.

Vastauskäyttöliittymän on tällaisessa tilanteessa näytettävä dokumentin nimen lisäksi versio, voimassaolon tila, katkelma ja varoitus ristiriidasta; lokiin on tallennettava, mitkä ehdokkaat löytyivät ja miksi yksi valittiin, jotta virhe voidaan toistaa indeksin muututtua. Jos järjestelmä antaa myöhemmin toisen vastauksen, tiimin on kyettävä selvittämään, muuttuiko dokumentti, pilkkominen, hakumääritys vai malli; ilman tällaista jäljitettävyyttä laatupoikkeamasta tulee arvaus ”tekoälyn käyttäytymisestä” eikä korjattava järjestelmävirhe.

Mikä on RAG ja miten se toimii yrityksen dokumenteissa?

RAG-putki alkaa datan tuonnista eikä keskusteluikkunasta: tiedostot noudetaan määritetyistä tallennuspaikoista, niistä poimitaan teksti, taulukot ja käytettävissä oleva rakenne, ja skannatut dokumentit tarvitsevat optista tekstintunnistusta eli OCR:ää. Sen jälkeen sisältö jaetaan mielekkäisiin katkelmiin, joista jokainen säilyttää linkin dokumenttiin, sivuun, osioon ja hallintametadataan. Microsoftin ohjeissa pilkkominen kuvataan hakutulosten käyttökelpoisuuteen vaikuttavaksi valinnaksi: liian pieni katkelma kadottaa ajatuksen, liian suuri tuo paljon kohinaa, ja mekaaninen jako tietyn merkkimäärän kohdalta voi katkaista taulukon tai poikkeusehdon.

Indeksointivaiheessa katkelmista muodostetaan hakuun soveltuva esitys, jossa avainsanahaku yhdistetään tavallisesti numeerisiin vektoreihin perustuvaan semanttiseen vertailuun. Kun käyttäjä esittää kysymyksen, järjestelmä voi muuntaa sen useaksi hakukyselyksi, käyttää osasto-, päivämäärä- ja käyttöoikeussuodattimia, hakea ehdokkaat ja järjestää ne uudelleen; vasta sitten valitut katkelmat päätyvät mallin konteksti-ikkunaan yhdessä tehtävän kanssa: vastaa käytettävissä olevan näytön perusteella, ilmoita lähteet ja kerro, jos näyttö ei riitä. Tässä vaiheessa mitään ei ”opita ikuisesti”, vaan konteksti koskee kyseistä pyyntöä.

Viimeinen vaihe on generointi, jossa valmiiksi koulutettu kielimalli muuttaa katkelmat ymmärrettäväksi vastaukseksi; siksi se voi myös muotoilla asian kömpelösti, yhdistää yhteensopimattomia lähteitä tai lisätä uskottavan yksityiskohdan yleisestä tiedostaan. Tuloksessa on säilytettävä katkelman ja väitteen välinen yhteys eikä vain koristeellista lähdeluetteloa vastauksen lopussa. Jos kysymys vaatii toimintaa, esimerkiksi hinnan muuttamista CRM:ssä, mallille ei pidä antaa vapaata suoritusoikeutta: sovelluskoodi, käyttöoikeudet ja hyväksyntävaihe tarkistavat jäsennellyn työkalupyynnön. Haku auttaa löytämään perustelun; se ei ole lupa toimia.

Käytännössä hybridihaulla saadaan hyviä tuloksia: tarkkaa tuotekoodia tai politiikan numeroa haetaan avainsanana ja kysymyksen merkitystä semanttisesti, minkä jälkeen uudelleenjärjestäminen valitsee koko kysymykseen parhaiten vastaavat katkelmat. Tämä ketju on testattava aidoilla lyhenteillä, väärin kirjoitetuilla koodeilla, taivutusmuodoilla ja monikielisillä dokumenteilla, koska esittelykysymys on tavallisesti liian siisti. Jos tarvittava katkelma ei ilmesty ehdokkaisiin, generoiva malli ei voi palauttaa sitä kaunopuheisuudella, joten hakuvirhe on korjattava ennen promptin uudelleenmuotoilua.

Mihin dokumenttien käyttötapauksiin RAG sopii

Parhaita ehdokkaita ovat kysymykset, joiden vastaus on jo olemassa monissa hallituissa dokumenteissa mutta joiden löytäminen vie ihmiseltä liian kauan: sisäiset menettelyt, tuoteoppaat, tekniset ohjeet, laatudokumentaatio, sopimusmallien selitykset ja asiakastuen tietämyskanta. RAGin tehtävä ei ole keksiä uutta päätöstä, vaan löytää asiaankuuluva kohta, yhdistää muutama keskenään yhteensopiva katkelma ja laatia luonnos. Hyvä kysymys on ”missä ohjeessa tämä virhe kuvataan ja mitkä tarkistusvaiheet siinä annetaan?”, ei ”miten yrityksen pitää toimia missä tahansa poikkeustilanteessa?”; myös dokumenttien tutkiminen ennen ihmisen työtä on hyödyllinen kerros: projektipäällikkö voi löytää sopimuksista toimitusehdot, hankinta-asiantuntija vaatimusten maininnat ja huoltotyöntekijä aiemmat ratkaisut samankaltaiseen laitteeseen. Tällöin vastauksen on avattava lähteen oikea kohta, jotta käyttäjä voi tarkistaa asiayhteyden, ja järjestelmän on säilytettävä loki kyselystä, löydetyistä katkelmista ja käytetystä versiosta. Näin RAGista tulee navigointi- ja luonnostyökalu eikä nimetön tuomionantaja, jonka päätöspolkua ei voi myöhemmin palauttaa.

Huonoja ehdokkaita ovat tehtävät, joilla ei ole vakaata dokumenttipohjaa, jotka vaativat täsmällistä laskentaa tai sääntöjen toimeenpanoa tai joissa yksikin virhe käynnistää automaattisesti peruuttamattoman toiminnon. Palkanlaskentaa, käyttöoikeuden myöntämistä, maksun suorittamista ja lakisääteisen määräajan valvontaa ohjaavat koodi ja tarkistettavat liiketoimintasäännöt; RAG voi löytää menettelyn selityksen, mutta se ei voi korvata laskentamoottoria tai valtuutusketjua. Jos todellinen tavoite on yhdistää järjestelmiä ja siirtää dataa ennakoitavasti, kannattaa arvioida liiketoimintaprosessien automatisointia sen sijaan, että generoivasta vastauksesta tehdään prosessin keskeinen kytkin.

Sopivuuden ratkaisee myös vastuun omistaja: jokainen dokumenttikokoelma tarvitsee henkilön, joka hyväksyy lähteet, ratkaisee ristiriidat ja päättää sisällön poistamisesta indeksistä, ja jokainen käyttötapaus tarvitsee tiimin, joka käy virheet läpi ja muuttaa testijoukkoa. Jos kukaan ei ota tätä työtä vastuulleen, pilotista tulee muutamassa kuukaudessa vanhojen dokumenttien peili, vaikka itse malli ei olisi muuttunut; teknisesti yksinkertainen mutta hallittu tukiohje on siksi parempi ensimmäinen projekti kuin yrityksen koko levyn kytkeminen järjestelmään yhdessä illassa.

Mitä RAG voi tehdä yrityksen dokumenttiarjessa

RAG voi vähentää aikaa, jonka työntekijä käyttää oikean kansion ja avainsanojen arvaamiseen, sillä semanttinen haku voi löytää katkelman silloinkin, kun kysymyksen sanat eivät vastaa dokumentin terminologiaa. Se voi yhdistää vastaukseen useita yhteensopivia lähteitä, selittää vaikean ohjeen yksinkertaisemmin, laatia sähköpostin tai raportin luonnoksen ja näyttää, miltä sivuilta kukin olennainen väite on peräisin. OpenAI File Search ja Microsoftin hakuarkkitehtuuri ovat konkreettisia työkaluesimerkkejä, mutta tuotteen valinta ei poista tarvetta määritellä omien dokumenttien tiloja, suodattimia ja laatutarkistuksia. Järjestelmä voi myös paljastaa dokumentaatio-ongelmia, jotka tavallinen kansioiden selaaminen peittää: samaan kysymykseen löytyy kaksi ristiriitaista ohjetta, usein kysytylle asialle ei löydy lähdettä tai yhden osaston sisältö hallitsee tuloksia, koska sen tiedostot on jäsennelty paremmin. Näistä tapauksista on hyötyä vain, jos niitä ei piiloteta yhden sujuvan vastauksen taakse; puuttuvasta lähteestä ja ristiriidasta on tehtävä mitattava tapahtuma, jonka dokumentin omistaja näkee; silloin RAGin laatulokista tulee mallin suorituskykykäyrän lisäksi myös tiedonhallinnan työlista.

Toinen todellinen mahdollisuus on mukauttaa roolia ja kontekstia: teknikko saa yksityiskohtaisen ohjeen koodeineen, kun taas asiakasneuvoja saa lyhyemmän selityksen, jos molemmilla on oikeus nähdä samat lähteet. Esitystapa muuttuu, totuus ei, ja jokaisessa roolissa on säilytettävä sama lähteen tila ja sama kielto keksiä puuttuvaa tietoa. Työmme tekoälyratkaisujen parissa alkaa tällaisen käyttötapauksen ja riskirajan määrittelystä eikä mallin esittelystä, koska hyvä prototyyppi osoittaa konkreettisen työhyödyn omilla dokumenteillasi ja näyttää samalla, mihin kysymyksiin järjestelmän on vastattava ”en tiedä”.

Arjessa suurin hyöty syntyy, kun ihminen näkee, mitä järjestelmä teki hänen puolestaan ja mitä on vielä tarkistettava. Vastausluonnoksessa voidaan korostaa puutteellisesti perusteltuja väitteitä, ehdottaa liittyviä dokumentteja ja antaa mahdollisuus ilmoittaa väärästä versiosta yhdellä toiminnolla; tällainen palaute on arvokkaampi kuin pelkkä peukalokuvake. Korjaus on liitettävä kysymykseen, katkelmaan ja virhetyyppiin, jotta tiimi pystyy erottamaan puuttuvan lähteen kömpelöstä kielestä tai väärästä liiketoimintasäännöstä ja valitsemaan oikean korjauksen.

Mitä RAG ei voi tehdä, vaikka vastaus kuulostaisi vakuuttavalta

RAG ei voi taata totuutta, sillä virhe voi syntyä ennen generointia, sen aikana tai sen jälkeen: lähteessä voi olla väärä tieto, haku voi valita asiaankuulumattoman katkelman, kontekstista voi kadota poikkeus ja malli voi yhdistää oikeat kappaleet väärin. Lainaus vähentää sokean luottamuksen riskiä vain silloin, kun käyttäjä voi avata tarkan kohdan ja tarkistaa, seuraako väite todella siitä; linkki oikeaan PDF-tiedostoon ei ole laatuleima, aivan kuten virheellisen raportin lähdeluettelo ei tee johtopäätöksestä oikeaa.

RAG ei voi toteuttaa käyttöoikeuksien hallintaa itsestään: jos hakukerros ei ennen hakua suodata dokumentteja varmennetun käyttäjäidentiteetin ja dokumentin oikeuksien perusteella, mallin kontekstiin voi päätyä katkelma, jota käyttäjä ei saa nähdä, eikä myöhemmin promptiin kirjoitettu ”älä paljasta salaista tietoa” korjaa tätä arkkitehtuurivirhettä. Microsoftin dokumenttitason käyttöoikeusohjeissa käyttöoikeustiedot ja tietoturvasuodattimet kuuluvat itse hakupolkuun; käyttöliittymään piilotettu painike ei suojaa mitään, jos kyselyn voi tehdä toisella tavalla.

RAG ei myöskään tee epäluotettavasta sisällöstä turvallista: dokumentissa, verkkosivulla tai sähköpostissa voi olla ohje, joka yrittää kirjoittaa järjestelmän tarkoitetun toiminnan uusiksi eli tehdä prompt injection -hyökkäyksen. OWASP nostaa sen erilliseksi riskiksi, jota pelkkä järjestelmäpromptiin kirjoitettu kielto ei poista kokonaan. Siksi ulkoista sisältöä on käsiteltävä datana eikä käskyinä, työkalukutsut on sallittava suppeasti ja validoitava, ja suuren riskin toiminnon on jäätävä deterministisen säännön ja ihmisen hyväksynnän taakse; malli voi ehdottaa; järjestelmä myöntää valtuudet.

Rajoihin kuuluvat myös saatavuus ja toiminnan jatkuvuus: jos hakuindeksi ei ole käytettävissä, turvallinen järjestelmä ei teeskentele, että yrityksen lähteet ovat yhä sen saatavilla, vaan siirtyy selvästi virhetilaan tai rajattuun toimintatilaan. Muuten käyttäjä ei pysty erottamaan lähteisiin perustuvaa vastausta mallin vapaasta improvisoinnista; myös kustannus- ja pyyntörajat, hätäpysäytys sekä edellisen määrityksen palautus on suunniteltava. RAG-tuote on usean palvelun ketju, ja jokainen hiljainen vika voi muuttaa vastauksen merkitystä, vaikka keskusteluikkuna toimisi edelleen.

Dokumenttien valmius: OCR, metadata ja versionhallinta

Dokumenttikansion koko ei kerro valmiudesta: skannattu sopimus, jonka sivu on vinossa, taulukko ilman luettavaa otsikkoa, PDF-tiedosto väärässä tekstijärjestyksessä tai heikkokontrastinen valokuva voivat näyttää ihmisestä ymmärrettäviltä, vaikka OCR-poiminnassa katoaisi numero, sarakkeiden välinen yhteys tai kappaleen raja. Microsoftin OCR-rajoitusten kuvauksessa tulos sidotaan suoraan skannauksen laatuun, tarkkuuteen, kontrastiin, valaistukseen, kiertoon sekä tekstin ominaisuuksiin; siksi edustavat dokumentit on tarkistettava poiminnan jälkeen vertaamalla tekstiä, taulukoita, sivuviitteitä ja olennaisia kenttiä alkuperäiseen eikä luottamalla ilmoitukseen tiedoston ”onnistuneesta käsittelystä”.

Metadata antaa katkelmalle organisaation kontekstin: dokumenttityyppi, yksikkö, tuote, kieli, omistaja, hyväksyjä, salassapitotaso, voimaantuloaika ja version tila auttavat rajaamaan kyselyä ennen semanttisen samankaltaisuuden arviointia. Ilman niitä hakujärjestelmä vertaa lauseita, mutta ei tiedä, että varasto-ohje koskee vain Liettuaa tai että sopimusliite on korvattu uudemmalla. Tärkeimmät kentät on saatava luotettavasta järjestelmästä tai ihmisen on tarkistettava ne; generoitu arvaus dokumentin tilasta ei saa muuttua suodattimeksi, joka määrää seuraavan vastauksen.

Myös päivittäminen on osa tuotetta eikä kertaluonteinen tuontityö: on tiedettävä, kuinka nopeasti hyväksytty muutos päätyy indeksiin, miten peruttu katkelma poistetaan, mitä muuttuneelle tiedosto-osoitteelle tapahtuu ja näyttääkö järjestelmä häiriössä edelleen vanhaa versiota. Microsoftin indeksiä koskevissa ohjeissa täydentävät päivitykset erotetaan uudelleenindeksoinnista, joten jokainen lähde tarvitsee dokumentoidun synkronointi- ja virheidenhallintamenetelmän; ennen RAG-projektia kannattaa järjestää yksi auktoritatiivinen dokumenttivirta; muuten nopea haku vain kiihdyttää epäselvän hallinnan seurauksia.

Ennen ensimmäistä indeksointia kannattaa ottaa otos dokumenttien valmiudesta: mukaan valitaan eri tiedostotyyppejä, eri-ikäisiä ja erikielisiä aineistoja, taulukoita, skannauksia ja käyttöoikeusluokkia, minkä jälkeen jokaisesta tarkistetaan poimittu teksti, katkelmien rajat, metadata ja lähdelinkki. Virheiden osuutta ei pidä tiivistää yhdeksi keskiarvoksi, sillä ohjeesta kadonneen pilkun ja sopimuksesta kadonneen summan hinta on erilainen. Otos auttaa päättämään, mitkä muodot hyväksytään automaattisesti, mitkä tarvitsevat ihmisen tarkistuksen ja mitä ei toistaiseksi indeksoida; tämä työ parantaa laatua usein enemmän kuin toisen kielimallin valinta.

Käyttöoikeudet, tietosuoja ja käyttöympäristön valinta

Turvallinen arkkitehtuuri alkaa identiteetistä: kuka kysyy, mihin organisaatioon ja osastoon hän kuuluu, mitä dokumenttiluokkia hän saa nähdä ja tarkistetaanko nämä oikeudet jokaisessa hakupyynnössä. Käyttöoikeussuodattimen on toimittava ennen kuin katkelmat päätyvät mallin kontekstiin, ja lokeihin ei pidä tarpeettomasti kopioida kokonaisia kysymyksiä, vastauksia ja arkaluonteisia katkelmia. Myös rajatapaukset on testattava: työntekijä vaihtaa roolia, dokumentti muuttuu rajoitetuksi, käyttöoikeus perutaan tai yksi asiakas yrittää löytää toisen asiakkaan sisältöä. ”Keskusteluun pitää kirjautua” ei ole riittävä hyväksymiskriteeri.

Kysymykseen ”päätyvätkö tietoni mallin koulutukseen?” ei ole rehellistä yleisvastausta nimeämättä toimittajaa, tuotetta, tiliä ja asetuksia. OpenAI:n yritys- ja API-aineiston mukaan kyseisten yritystuotteiden dataa ei oletusarvoisesti käytetä mallien kouluttamiseen, kun taas API:n datanhallintadokumentaatiossa säilytys, väärinkäytön valvonta ja päätepistekohtaiset poikkeukset kuvataan erikseen. Myös Anthropic erottaa kaupallisten tuotteiden käsittelyn, tietoisen suostumuksen parantamiskäyttöön ja säilytysehdot; siksi sopimuksessa ja teknisessä suunnitelmassa tarkistetaan tietty palvelu eikä luoteta ilmaukseen ”yritys-API”.

Sijoittaminen EU-alueelle tai omaan infrastruktuuriin voi auttaa täyttämään tietyt datan sijaintia, hallintaa tai integraatioita koskevat vaatimukset, mutta se ei itsessään todista GDPR-vaatimustenmukaisuutta tai turvallisuutta. Käsittelyn tarkoitus ja oikeusperuste, tietojen minimointi, säilytysajat, alikäsittelijät, poistaminen, poikkeamaprosessi ja käyttöoikeuksien auditointi on silti määriteltävä; GDPR:n periaatteet koskevat koko ketjua eivätkä vain mallipalvelimen sijaintimaata. Joskus oikea päätös on jättää tietyt dokumentit kokonaan RAGin ulkopuolelle tai poistaa ennen indeksointia kentät, joita vastaukseen ei tarvita.

Uhkamallissa on uteliaan työntekijän lisäksi testattava virheellinen ryhmäsynkronointi, jaettu linkki, ylläpitäjän rooli, tallennettu välimuisti ja haitallisen ohjeen sisältävä dokumentti. Testikäyttäjien on katettava jokainen rooli ja kielletty rooliyhdistelmä, ja heidän on yritettävä kysyä suoraan, synonyymeillä sekä epäsuoralla tiivistyspyynnöllä. Tuloksessa ei saa näkyä katkelmaa, dokumentin nimeä eikä vastauksesta pääteltävää salaista yksityiskohtaa. Testi on toistettava oikeuksien muuttamisen jälkeen, sillä eilinen turvallinen suodatin voi jäädä välimuistiin; nämä tarkistukset ovat hyväksymiskriteereitä eivätkä myöhemmän tietoturva-auditoinnin koristeita.

Miten hakua, lähteisiin tukeutumista ja oikeellisuutta mitataan

Yksi RAG-järjestelmän ”tarkkuusluku” muistuttaa sairaalan yhtä keskimääräistä arvosanaa: numero voi näyttää hyvältä, vaikka kriittinen virheluokka jäisi näkymättömäksi; ensin mitataan haku erikseen: päätyikö tarvittava katkelma määritettyyn määrään parhaita tuloksia ja syrjäyttivätkö tarpeettomat katkelmat sen. Sen jälkeen mitataan kontekstin osuvuus kysymykseen, vastauksen tukeutuminen annettuihin katkelmiin, tosiasiallinen oikeellisuus hyväksyttyyn vertailukohtaan nähden, jokaisen lähdeviitteen vastaavuus tiettyyn väitteeseen sekä järjestelmän kyky jättää vastaamatta, kun lähdettä ei ole tai lähteet ovat ristiriidassa.

Microsoftin RAG-arvioijien dokumentaatio erottaa nämä ulottuvuudet, ja ARES-tutkimus erottaa vastaavasti kontekstin osuvuuden, vastauksen tukeutumisen lähteisiin ja vastauksen osuvuuden. Siksi käytännön testijoukossa jokainen aito kysymys tarvitsee ”oikean vastauksen” lisäksi pakollisen lähteen, hyväksyttävät muotoilut, kielletyt väitteet, roolin, dokumenttiversion ja odotetun toiminnan silloin, kun näyttö ei riitä; osa esimerkeistä muodostetaan usein kysytyistä asioista, osa kalliista poikkeuksista ja tarkoituksellisista ansoista.

Hyväksymiskynnys on asetettava jokaiselle ulottuvuudelle ja riskiluokalle ennen tulosten näkemistä, sillä muuten tiimi valitsee esittelyn jälkeen parhaimmalta näyttävän mittarin. Pilottimittauksissa on säilytettävä myös virheiden jakauma dokumenttityypin, osaston, kielen ja kysymystyypin mukaan, koska yleinen keskiarvo voi peittää sen, että käyttöoppaat toimivat hyvin mutta sopimusten taulukot huonosti. Automaattinen malliarvioija auttaa laajentamaan tarkistusta, mutta ihmisen on arvioitava otos ja kriittisiä vastauksia on verrattava auktoritatiiviseen lähteeseen eikä toisen mallin itsevarmuuteen.

Käyttöönoton jälkeen samoja ulottuvuuksia on mitattava hallitulla tuotanto-otoksella ja tietosuojaa säästävillä lokeilla. Dokumenttikokoelman, pilkkomisalgoritmin, vektorimallin, uudelleenjärjestämisen tai generoivan mallin muutos voi parantaa yhtä kysymysryhmää ja heikentää toista, joten jokainen versio tarvitsee regressiotestin ja vertailukelpoisen lähtötason, jonka arviointisäännöt pysyvät samoina koko testijoukolle. Hälytyksen ei pidä syntyä vain kokonaismittarin laskusta, vaan myös kriittisestä virheestä, kuten luvattomasta katkelmasta tai keksitystä vastauksesta siellä, missä järjestelmän piti jättää vastaamatta.

RAG, haku, pitkä konteksti, mallin hienosäätö ja agentit

Tavallinen kokotekstihaku on parempi, kun käyttäjä tietää tarkan nimen, koodin tai ilmauksen ja tarvitsee dokumentin eikä koottua vastausta; se on halvempi, ennakoitavampi ja helpompi auditoida. Semanttinen haku auttaa synonyymeissä ja epätarkoissa kysymyksissä, ja generointi voidaan lisätä vain silloin, kun tiivistelmä tuottaa todellista arvoa. RAG ei ole välttämätön jokaisessa yrityksen hakujärjestelmässä: joskus oikea tuote on hyvä hakusivu, jossa on suodattimet, katkelman esikatselu ja version tila, koska käyttäjä tekee itse johtopäätöksen koko dokumentista.

Koko dokumentin asettaminen pitkään konteksti-ikkunaan voi olla helppoa, kun aineistoa on vähän ja se on vakaata, mutta suuressa kokoelmassa kustannukset, kohina ja riski tärkeän kappaleen katoamisesta epäolennaisen sisällön sekaan kasvavat. Mallin lisämukautus eli fine-tuning voi puolestaan vakiinnuttaa muodon, tyylin tai tietyn tehtävän toimintatavan, mutta se ei ole kätevä tapa säilyttää usein muuttuvia hintoja, politiikkoja ja ohjeita, koska lähteen päivittäminen ja siteeraaminen muuttuvat vähemmän läpinäkyviksi. RAG mahdollistaa dokumenttikokoelman muuttamisen erillään mallin painojen koulutuksesta, mutta joustavuuden hintana on indeksin, versioiden ja haun laadun hallinta.

Automaatio suorittaa ennalta määritettyjä vaiheita, kun taas tekoälyagentti voi valita työkalun ja seuraavan vaiheen, joten sen vapaus edellyttää tiukempia valtuutus-, validointi- ja pysäytysrajoja. RAG voi antaa agentille tietoa, mutta ei oikeuksia: vaikka malli löytäisi lomapolitiikan, se ei vielä saa hyväksyä poissaoloa tai muuttaa palkkajärjestelmää. Jäsennelty funktiokutsu on vain ehdotus sovellukselle, joka tarkistaa skeeman, identiteetin, sallitun toiminnon, summat tai muut rajat sekä tarvittavan ihmisen hyväksynnän; teknologioiden vertailu alkaa prosessin riskistä eikä halusta käyttää uusinta nimitystä.

Valinnan voi muotoilla yksinkertaiseksi tarkistukseksi: jos tiedosto pitää löytää ja avata, aloita hausta; jos muutama muuttuva lähde pitää tiivistää viitteineen, arvioi RAGia; jos tarvitaan vakiintunutta muotoa tai luokittelukäyttäytymistä, mallin hienosäätö voi sopia; jos on suoritettava ennakoitava vaihesarja, rakenna automaatio. Lisää agentti vasta, kun seuraavaa vaihetta ei voi ohjelmoida turvallisesti ja hyöty ylittää lisäriskin; menetelmiä voi yhdistää, mutta jokaisella kerroksella on oltava oma tehtävä, mittari ja pysäytysraja, tai virheen syy katoaa sanan ”tekoäly” alle.

Miten rajattu pilotti rakennetaan aidoilla kysymyksillä

Pilotti alkaa yhdestä dokumenttikokoelmasta, yhdestä käyttäjäryhmästä ja yhdestä päätösrajasta, esimerkiksi teknisen tuen oppaista, jolloin järjestelmä vain etsii lähteet ja laatii vastausluonnoksen. Ennen kehitystä tiimi kerää aitoja kysymyksiä hakulokeista, sähköposteista ja työntekijähaastatteluista, liittää niihin oikeat lähteet ja sisällyttää tarkoituksella tapauksia, joihin ei voi vastata tai joissa aineisto on vanhentunutta, ristiriitaista tai luvatonta. Jokaiselle tapaukselle määritetään hyväksyttävä tulos: tarvittava katkelma löytyy, väite tukeutuu lähteeseen, viite johtaa oikeaan kohtaan, vastaus on tosiasiallisesti oikea eikä järjestelmä keksi turvallisen itsevarmasti puuttuvaa tietoa.

Kynnykset vahvistetaan ennen esittelyä ja jaetaan riskin mukaan: tavallisessa tietokysymyksessä voidaan hyväksyä korjattava luonnos, mutta henkilötietoja, sopimusta, turvallisuutta tai maksua koskeva kysymys tarvitsee tiukemman tarkistuksen ja ihmisen hyväksynnän. Pilotissa mitataan myös vastausaikaa, kustannusta pyyntöä kohden, käyttöoikeussuodattimien toimintaa, indeksipäivityksen viivettä sekä sitä, kuinka usein työntekijä avaa lähteen tai korjaa vastausta. Jos järjestelmä parantaa vain esittelyesimerkkejä mutta ei pärjää ennalta piilotetulle testijoukolle, tuotteen tulosta ei ole todistettu; on todistettu vain, että tiimi osaa valmistella esittelyn.

Tekoälyratkaisujemme toteutus maksaa alkaen 3 500 € ja kestää tavallisesti 3–8 viikkoa, ja toimivan pilotin omalla datallasi voimme toimittaa 2–3 viikossa; luvut kuvaavat palvelun aloitushintaa ja yleistä aikataulua eivätkä kiinteähintaista tarjousta, jonka laajuutta ei tunneta. Pilotin lopussa ei pidä olla vain keskusteluikkunaa, vaan versioitu dokumenttikokoelma, testikysymykset, erilliset laatumittarit, virheloki, käyttöoikeustarkistukset ja päätös siitä, mitä järjestelmä ei saa tehdä. Myöhemmät integraatiovaatimukset kannattaa kirjata yhtä selkeästi kuin muissakin digitaalisissa projekteissa noudattaen verkkosivujen tilaamisen virheitä käsittelevässä artikkelissa kuvattua periaatetta: hyväksymiskriteerit ja omistajat on määritettävä ennen koko käyttöönottoa eikä ensimmäisen näyttävän ruudun jälkeen.

Pilottia kannattaa jatkaa vain, jos se saavuttaa ennalta asetetut kynnykset testijoukon ennennäkemättömässä osassa, käsittelee luvattomat kysymykset ja kysymykset vailla vastausta turvallisesti sekä tuottaa mitattavaa hyötyä ihmisen työhön. Jos haku ei järjestelmällisesti löydä oikeaa lähdettä, korjataan ensin dokumentit, metadata ja indeksi; jos lähde on oikea mutta generointi vääristää sitä, muutetaan kontekstia, promptia tai mallia; jos virhe syntyy vain suuren riskin päätöksissä, päätökset jätetään deterministiselle järjestelmälle ja ihmiselle. Keskeytetty pilotti ei ole epäonnistuminen, vaan edullisesti saatu todiste siitä, että juuri tässä prosessissa RAGin rajat ovat tärkeämpiä kuin sen näyttävä esittelyvaikutus.