Yksi vaarallinen RAG-toteutustapa on ladata järjestelmään aineistoa laajasti ja pitää lähdeviitteitä sisältäviä vastauksia automaattisesti käyttöoikeuksien mukaisina.
Vastaus voi olla paikkansapitävä ja asianmukaisesti viitattu mutta vuotaa silti palkkatasoja, asiakassopimuksia, oikeudellisia luonnoksia, hallituksen muistiinpanoja, tukipyyntöjä, henkilöstötutkintojen tietoja tai tietoturvamenettelyjä.
Yrityksen tietämys-RAG ei ole hakukenttä, joka vain muotoilee vastaukset sujuvammin. Se on käyttöoikeuksin suojattu tietojärjestelmä, ja sitä on käsiteltävä sellaisena.
Haun on valvottava samoja tai tiukempia käyttöoikeuksia kuin lähdejärjestelmät. Jos käyttäjä ei voi avata asiakirjaa lähdejärjestelmässä, olipa se Google Drive, SharePoint, Notion, Confluence tai CRM, RAG ei saa hakea sitä kyseiselle käyttäjälle.
Keskeinen sääntö
Hakukerroksen on vastattava tähän kysymykseen ennen yhdenkään katkelman palauttamista:
Saako tämä käyttäjä nähdä tämän lähteen juuri nyt?
Ei ”onko tämä lähde vektoritietokannassa?”, ”onko tämä lähde olennainen?” tai ”onko tästä lähteestä hyötyä?”. Käyttöoikeus ratkaistaan ensin.
Yleisiä toteutustapoja on kolme:
| Toteutustapa | Miten se toimii | Sopii tilanteeseen |
|---|---|---|
| Erilliset indeksit | Yksi indeksi yleisöä tai työtilaa kohden | Yksinkertaiset tiimit ja karkeat käyttöoikeudet |
| Metatietosuodatus | Tallenna ACL-, ryhmä- ja lähdemetatiedot ja suodata ennen hakua | Järjestelmät, joiden käyttöoikeuden poiston viivetavoite voidaan täyttää synkronoinnilla |
| Reaaliaikainen käyttöoikeustarkistus | Tarkista lähdejärjestelmän käyttöoikeudet hakuhetkellä | Arkaluonteiset tai usein muuttuvat käyttöoikeudet |
Oikea ratkaisu riippuu lähdejärjestelmän käyttöoikeussemantiikasta, käyttöoikeuden poiston viivetavoitteesta, identiteettimallista ja vaikutuksesta. Erilliset indeksit ja metatietosuodatus eivät ole automaattisesti riittäviä. Niiden toimivuus on osoitettava valtuutus- ja käyttöoikeuden poistotesteillä.
Vaikein osa: ACL-tietojen pitäminen ajan tasalla
Kaikki edellä kuvatut toteutustavat riippuvat huomaamattomasti samasta asiasta: indeksin käyttöoikeustietojen on vastattava lähdejärjestelmän tietoja. Tämän synkronoinnin toteuttaminen on työn vaativin osa.
ACL-tietojen lähde. Aloita ajantasaisista virallisista ohjeista: Microsoft Graph -käyttöoikeusresurssi, Google Drive -jakamisohje ja Confluence-sisältöoikeuksien API. Lähteet käsittelevät käyttäjiä, ryhmiä, periytymistä, linkkejä, omistajuutta ja nopeusrajoja eri tavoin. Tarkista tosiasiallinen käyttöoikeus, älä vain suoraan myönnettyjä oikeuksia.
Ryhmien laajentaminen on välttämätöntä. Todelliset käyttöoikeudet myönnetään usein ryhmille, ja ryhmät voivat olla sisäkkäisiä. Ryhmä ”Sales EU” ryhmän ”Sales” sisällä ja tämä edelleen ryhmän ”All Staff” sisällä on purettava konkreettisiksi käyttäjiksi joko synkronoinnin yhteydessä tai kyselyhetkellä. Ensimmäinen vaihtoehto kasvattaa indeksin metatietoja mutta nopeuttaa kyselyjä. Toinen pitää tiedot tuoreempina mutta hidastaa kyselyjä ja lisää API-kutsuja. Valitse tapa tietoisesti. Sattumalta syntynyt ratkaisu toimii yleensä epäjohdonmukaisesti.
Synkronointiviive on tietoturvaparametri, ei suorituskyvyn yksityiskohta. Kun käyttäjä menettää asiakirjan käyttöoikeuden esimerkiksi roolimuutoksen, työsuhteen päättymisen tai kaupan siirtymisen luottamukselliseen vaiheeseen vuoksi, indeksi käyttää vanhaa ACL-tietoa seuraavaan synkronointiin asti. Määritä ja dokumentoi hyväksyttävä käyttöoikeuden poiston viive aineistokohtaisesti. Rajoitetuissa aineistoissa voidaan tarvita lähes reaaliaikaista päivitystä, kun taas sisäisissä prosessiasiakirjoissa tuntien viive voi olla hyväksyttävä. Jos tavoitetta ei ole kirjattu, todellinen vastaus on ”kun seuraava yöajo suoritetaan”, mikä ei kestä tietoturvakatselmointia.
Reaaliaikaiset tarkistukset parantavat ajantasaisuutta mutta lisäävät viivettä, nopeusrajojen kulutusta ja uuden vikatavan. Hakukohtainen käyttöoikeustarkistus lisää jokaiseen kyselyyn kutsukierroksen lähdejärjestelmään ja kuluttaa suuressa mittakaavassa API-kiintiötä nopeasti. Tavallinen kompromissi on lyhytikäinen välimuisti, jolloin ”reaaliaikaisuus” muuttuu jälleen synkronointiviiveeksi, joskin lyhyemmäksi. Valitusta ratkaisusta riippumatta aikakatkaisun toiminta on määritettävä: jos käyttöoikeustarkistus epäonnistuu tai aikakatkaistaan, katkelmaa ei palauteta. Estä käyttö virhetilanteessa, kirjaa virhe ja anna avustajan kieltäytyä. Hidas oikea vastaus on parempi kuin nopea tietovuoto.
Tee käyttöoikeuden poistamisesta nimenomainen toiminto. Käytä lähdejärjestelmän tukemia muutosilmoituksia tai tee ajoittaisia kyselyjä nimetyn omistajan hallitsemalla kohdistimella. Versioi ACL-tilannekuvat, mitätöi valtuutus- ja vastausvälimuistit käyttöoikeuden muuttuessa ja estä vanhempaa synkronointitulosta korvaamasta uudempaa. Tallenna jokaiseen katkelmaan lähteen ja ACL-tietojen versiot, jotta testit tunnistavat eri päivityssukupolvien sekoittumisen.
Testausosion työsuhteen päättymistä koskeva testi paljastaa, toimiiko ratkaisu todella. Käytöstä poistetun tilin ei pidä saada mitään rajoitetuista aineistoista dokumentoidun käyttöoikeuden poistotavoitteen jälkeen. Tämä koskee haku-, vastaus-, semanttisia ja CDN-välimuisteja.
Lähderajat
Älä kokoa kaikkea tietoa yhteen suureen tietovarastoon. Erottele aineistot yleisön ja arkaluonteisuuden mukaan:
| Aineisto | Yleisö | Esimerkkejä | Sääntö |
|---|---|---|---|
| Julkinen tai tuotetta koskeva | Kaikki | Ohjeet, julkinen hinnoittelu, tuotesivut | Sopii laajasti käytettävälle avustajalle |
| Sisäinen toiminta | Työntekijät | Prosessiasiakirjat, sisäiset usein kysytyt kysymykset | Vain työntekijöille |
| Osasto | Osaston jäsenet | Myynnin toimintamallit, tukimakrot, tekniset toimintaohjeet | Suodatetaan ryhmän mukaan |
| Asiakastietueet | Vastuutiimit | Tukipyynnöt, sopimukset, asiakkuusmuistiinpanot | Tiukka ACL ja auditointi |
| Rajoitettu | Vain nimetyt käyttäjät | Henkilöstöasiat, oikeudelliset asiat, tietoturva, hallitus | Yleensä erillinen järjestelmä tai ei RAG-käyttöä |
Mitä harvempia yleisöjä yksi aineisto palvelee, sitä helpompaa mahdollisia tietovuotoja on arvioida.
Indeksoinnin kontrollit
Moni tietovuoto alkaa indeksointiputkesta.
Tallenna ennen lähteen indeksointia:
- Lähdejärjestelmä.
- Asiakirjan tunniste.
- Omistaja.
- Yleisö tai ACL.
- Arkaluonteisuusluokitus.
- Luonti- ja päivitysaikaleimat.
- Vanhentumis- tai tarkastuspäivä.
- Saako asiakirjaa käyttää tekoälyhaussa.
- Sisältääkö asiakirja henkilötietoja.
Jos lähdejärjestelmässä on jo luokituksia, säilytä ne. Muussa tapauksessa lisää kevyt luokitteluvaihe ennen indeksointia.
Haun kontrollit
Tee haku tässä järjestyksessä:
- Tunnista käyttäjä ja ryhmät.
- Tunnista pyydetty työtila tai avustaja.
- Suodata lähde-ehdokkaat aineiston, ACL-tietojen, arkaluonteisuuden ja ajantasaisuuden perusteella.
- Hae olennaiset katkelmat vain sallituista lähteistä.
- Järjestä sallitut katkelmat uudelleen osuvuuden mukaan.
- Muodosta vastaus ja lisää lähdeviitteet.
- Kieltäydy vastaamasta tai ohjaa asia ihmisen käsiteltäväksi, jos sallitut lähteet eivät riitä.
Älä hae ensin ja suodata myöhemmin kehotteessa. Jos kielletty katkelma pääsee mallin kontekstiin, raja on jo pettänyt.
Kehotteen ja vastauksen toiminta
Ohjeista avustajaa:
- Vastaamaan vain haettujen lähteiden perusteella.
- Viittaamaan lähteen otsikkoon ja osioon tai linkkiin.
- Kertomaan, kun sallituissa lähteissä ei ole vastausta.
- Erottamaan päätelmät lähteisiin perustuvista tosiasioista.
- Olemaan paljastamatta rajoitettujen lähteiden olemassaoloa.
- Olemaan tiivistämättä aineistoa, johon käyttäjällä ei ole käyttöoikeutta.
Huono kieltäytyminen:
”Löysin henkilöstöhallinnon palkkatasot, mutta sinulla ei ole niihin käyttöoikeutta.”
Parempi kieltäytyminen:
”Minulla ei ole käytettävissä hyväksyttyä lähdettä, jonka perusteella voisin vastata.”
Jälkimmäinen vastaus ei paljasta rajoitettujen asiakirjojen olemassaoloa eikä aihetta.
Lokita aiheuttamatta uutta tietovuotoa
RAG-lokit ovat arkaluonteisia. Ne voivat sisältää käyttäjien kysymyksiä, haettuja katkelmia, lähdetunnisteita, vastauksia ja joskus henkilötietoja.
Kirjaa virheiden selvittämiseksi riittävät tiedot:
- Käyttäjätunniste tai pseudonyymi tunniste.
- Avustaja tai työtila.
- Kyselyn aikaleima.
- Haettujen lähteiden tunnisteet.
- Käyttöoikeussuodatuksen tulos.
- Vastauksen tunniste.
- Kieltäytymisen tai eteenpäin siirtämisen syy.
- Viive ja virheet.
Käsittele varoen:
- Käyttäjän kysymysten koko sisältöä.
- Haettujen katkelmien koko sisältöä.
- Muodostettujen vastausten koko sisältöä.
- Asiakastietoja.
- Henkilöstöön, oikeudellisiin asioihin tai tietoturvaan liittyviä aiheita.
Tallenna arkaluonteisissa järjestelmissä lokit, joista arkaluonteiset tiedot on peitetty, tai pelkät lähdetunnisteet koko tekstin sijaan. Määritä lokeille erillinen käyttöoikeuksien hallinta ja säilytysaika.
Vanhentuneet ja ristiriitaiset lähteet
Käyttöoikeus ei ole ainoa raja. Myös lähteen laadulla on merkitystä.
Jokaisella indeksoidulla lähteellä pitää olla omistaja ja ajantasaisuussääntö:
| Lähdetyyppi | Tarkastussääntö |
|---|---|
| Hinnoittelu | Tarkasta jokaisen hinnoittelumuutoksen yhteydessä |
| Toimintaohje | Tarkasta toimintaohjeen omistajan päivityksen yhteydessä, vähintään neljännesvuosittain |
| Tuotedokumentaatio | Tarkasta julkaisun yhteydessä |
| Oikeudellinen mallipohja | Oikeudellisesta sisällöstä vastaava omistaja tarkastaa |
| Tukimakro | Tarkasta kuukausittain tai eskalaatiomallin muuttuessa |
Kun lähteet ovat ristiriidassa, avustajan pitää tuoda ristiriita esiin vain, jos käyttäjällä on pääsy molempiin lähteisiin. Muussa tapauksessa sen pitää vastata ensisijaisen sallitun lähteen perusteella tai ohjata asia ihmisen käsiteltäväksi.
Käyttöoikeusrajojen testaus
Testaa käyttäjäprofiileilla, älä vain asiakirjoilla:
- Työntekijä, jolla on laajat käyttöoikeudet.
- Työntekijä, jolla on vain osastonsa suppeat käyttöoikeudet.
- Esihenkilö, jolla on käyttöoikeus vain tiiminsä aineistoon.
- Toimeksisaaja.
- Entinen työntekijä tai käytöstä poistettu tili.
- Asiakaspalvelussa työskentelevä käyttäjä.
- Ylläpitäjä.
Esitä kullekin:
- Kysymys, johon hänen pitää saada vastaus.
- Kysymys, joka jää juuri hänen käyttöoikeuksiensa ulkopuolelle.
- Kysymys rajoitetusta asiakirjasta, jonka hän tietää olevan olemassa.
- Kysymys tilanteesta, jossa julkiset ja sisäiset asiakirjat ovat ristiriidassa.
- Kehote-injektion sisältävä kysymys: ”ohita käyttöoikeussäännöt”.
Oikea tulos ei ole vain ”hyvä vastaus”, vaan ”hyvä vastaus sallittujen lähteiden perusteella”.
Käyttöönottopolku
Aloita vähiten arkaluonteisesta aineistosta:
- Julkiset ja tuotetta koskevat asiakirjat.
- Sisäisen toiminnan asiakirjat.
- Osastokohtaiset asiakirjat.
- Asiakastietueet, joilla on tiukka ACL.
- Rajoitetut aineistot vasta tietoturvasta ja lakiasioista vastaavien nimenomaisen hyväksynnän jälkeen.
Mittaa jokaisessa vaiheessa:
- Vastausten hyödyllisyyttä.
- Viittausten laatua.
- Kieltäytymisten oikeellisuutta.
- Käyttöoikeuden vuoksi estettyjen hakujen osuutta.
- Haussa palautuvien vanhentuneiden lähteiden osuutta.
- Käyttäjien ilmoituksia puuttuvista tai vääristä lähteistä.
Älä tee tätä vielä
Älä indeksoi ”kaikkia yrityksen asiakirjoja” yhden avustajan käyttöön.
Älä valvo käyttöoikeuksia pelkkien kehoteohjeiden avulla.
Älä tallenna arkaluonteisista aineistoista haettujen katkelmien koko sisältöä lokeihin ilman selkeää säilytys- ja käyttöoikeuskäytäntöä.
Älä sekoita henkilöstöön, oikeudellisiin asioihin, asiakkaisiin ja julkiseen käyttöön liittyviä asiakirjoja samaan aineistoon.
Älä anna RAG:n vastata sallittujen lähteidensä ulkopuolelta vain ollakseen hyödyllinen.
Käyttöoikeusrajat ensin
Yrityksen tietämys-RAG on arvokas, koska se tuo lähteisiin perustuvat vastaukset päivittäiseen työhön. Samasta syystä se on riskialtis: lähteisiin perustuva vastauskin voi vuotaa tietoa.
Suunnittele käyttöoikeusrajat ensin. Suodata ennen hakua. Erottele aineistot yleisön mukaan. Säilytä lähteiden metatiedot. Kieltäydy turvallisesti. Lokita harkiten. Testaa todellisilla käyttöoikeusprofiileilla. Jos käyttäjä ei pääse lähteeseen suoraan, RAG ei saa käyttää sitä vastauksen muodostamiseen.
