Yleisin RAG-virhe yrityksissä on yksinkertainen: lataa kaikki, esitä kysymyksiä ja käsittele lähteisiin viittaavia vastauksia automaattisesti turvallisina.
Toiseksi yleisin virhe tulee myöhemmin: joku huomaa, että assistentti voi vastata asiakirjoista, joita käyttäjän ei olisi pitänyt nähdä. Palkkaluokat. Asiakassopimukset. Juridiset luonnokset. Hallituksen muistiinpanot. Tukitiketit. HR-tutkinnat. Tietoturvamenettelyt. Vastaus voi olla tarkka ja viitattu, mutta järjestelmä on vuotanut tietoa.
Yrityksen tietämyksen RAG ei ole hakukenttä hienommalla proosalla. Se on käyttöoikeuksin rajattu tietojärjestelmä. Käsittele sitä sen mukaisesti.
Haun on noudatettava samoja tai tiukempia käyttöoikeuksia kuin lähdejärjestelmien. Jos käyttäjä ei voi avata asiakirjaa Google Drivessa, SharePointissa, Notionissa, Confluencessa tai CRM:ssä, RAG:n ei pidä hakea sitä kyseiselle käyttäjälle.
Keskeinen sääntö
Hakukerroksen on vastattava tähän kysymykseen ennen minkään palan palauttamista:
Saako tämä käyttäjä nähdä tämän lähteen juuri nyt?
Ei ”onko tämä lähde vektoritietokannassa?” Ei ”onko tämä lähde relevantti?” Ei ”onko tämä lähde hyödyllinen?” Käyttöoikeus tulee ensin.
Kolme yleistä mallia:
| Malli | Toimintatapa | Sopivuus |
|---|---|---|
| Erilliset indeksit | Yksi indeksi yleisöä tai työtilaa kohden | Yksinkertaiset tiimit, karkeat käyttöoikeudet |
| Metatietosuodatus | Tallenna ACL-/ryhmä-/lähdemetatiedot ja suodata ennen hakua | Useimmat yrityksen RAG-järjestelmät |
| Reaaliaikainen käyttöoikeustarkistus | Kysy lähdejärjestelmän käyttöoikeuksia hakuaikana | Arkaluonteiset tai usein muuttuvat käyttöoikeudet |
Oikea vastaus riippuu lähdejärjestelmistä ja riskitasosta. Useimmille pk-yrityksille erilliset indeksit plus metatietosuodatus riittävät. Asiakas-, HR-, juridisen tai säännellyn datan kohdalla reaaliaikaiset tarkistukset voivat olla välttämättömiä.
Vaikea osa: ACL:ien pitäminen synkronissa
Jokainen yllä oleva malli riippuu hiljaa yhdestä asiasta: indeksin käyttöoikeustietojen on vastattava lähdejärjestelmän käyttöoikeustietoja. Tämä synkronointi on todellista suunnittelutyötä.
Mistä ACL:t tulevat. SharePoint ja OneDrive tarjoavat kohdekohtaiset käyttöoikeudet Microsoft Graph API:n kautta; Google Drive Drive API:n tiedostokohtaisten käyttöoikeuslistausten kautta; Confluence tila- ja sivurajoitusten kautta. Jokaisella on erilaiset muodot (käyttäjät, ryhmät, periytyminen, jakolinkit), erilaiset API-nopeusrajoitukset ja erilainen käsitys siitä, ”kuka voi nähdä tämän”.
Ryhmien laajennus ei ole valinnaista. Useimmat todelliset käyttöoikeudet myönnetään ryhmille, ja ryhmät sisäkkäistyvät. ”Sales EU” ryhmän ”Sales” sisällä ryhmän ”All Staff” sisällä on litistettävä konkreettisiksi käyttäjiksi joko synkronointiaikaan (suurempi indeksimetatieto, nopeammat kyselyt) tai kyselyaikaan (tuoreempi, hitaampi, enemmän API-kutsuja). Valitse yksi tietoisesti; tiimit, jotka tekevät sen sattumalta, tekevät sen epäjohdonmukaisesti.
Synkronoinnin viive on tietoturvaparametri, ei suorituskykytieto. Kun joku menettää pääsyn asiakirjaan — roolin muutos, työsuhteen päättyminen, kaupan muuttuminen luottamukselliseksi — indeksi jatkaa vanhan ACL:n tarjoamista seuraavaan synkronointiin asti. Päätä hyväksyttävä peruutusviive korpusta kohden ja kirjoita se ylös: lähes reaaliaikainen rajoitetuille korpuksille, tunnit voivat olla hyväksyttäviä sisäisille prosessiasiakirjoille. Jos kukaan ei ole kirjoittanut sitä lukua ylös, todellinen vastaus on ”aina kun yöajo ajetaan”, mikä ei selviä tietoturvakatselmuksesta.
Reaaliaikaiset tarkistukset ostavat tuoreutta ja maksavat viiveellä, nopeusrajoilla ja epäonnistumistavalla. Hakukohtainen käyttöoikeuskutsu lisää lähdejärjestelmän kierroksen jokaiseen kyselyyn ja kuluttaa API-kiintiötä nopeasti mittakaavassa; tavallinen kompromissi on lyhytikäinen välimuisti, joka muuttaa hiljaa ”reaaliaikaisen” takaisin ”synkronointiviiveeksi pienemmällä luvulla”. Mitä tahansa valitsetkin, tee aikakatkaisukäyttäytyminen eksplisiittiseksi: jos käyttöoikeustarkistus epäonnistuu tai aikakatkeaa, palaa ei lähetetä. Epäonnistu suljettuna, kirjaa epäonnistuminen ja anna assistentin kieltäytyä — hidas oikea vastaus voittaa nopean vuodon.
Testausosiossa oleva offboarding-testi paljastaa, toimiiko mikään tästä todella: poistetun tilin on haettava nolla rajoitetuista korpuksista, ja tarkistuksen on pidettävä päivä tilin poistamisen jälkeen, ei vain seuraavan täyden uudelleensynkronoinnin jälkeen.
Lähderajat
Älä luo yhtä jättimäistä tietovarantoa. Erota yleisön ja herkkyyden mukaan:
| Korpus | Yleisö | Esimerkkejä | Sääntö |
|---|---|---|---|
| Julkinen/tuote | Kaikki | Ohjeet, julkinen hinnoittelu, tuotesivut | Turvallinen laajalle assistentille |
| Sisäinen toiminta | Työntekijät | Prosessiasiakirjat, sisäiset FAQ:t | Vain työntekijät |
| Osasto | Osaston jäsenet | Myynnin playbookit, tuen makrot, kehityksen runbookit | Ryhmäsuodatettu |
| Asiakastietueet | Määrätyt tiimit | Tiketit, sopimukset, tilimuistiinpanot | Tiukka ACL ja auditointi |
| Rajoitettu | Vain nimetyt käyttäjät | HR, juridinen, tietoturva, hallitus | Yleensä erillinen järjestelmä tai ei RAG:ia |
Mitä harvemmalle yleisölle korpus palvelee, sitä helpompaa vuotojen päättely on.
Ingestoinnin kontrollit
Ingestointiputki on paikka, jossa monet vuodot alkavat.
Ennen lähteen indeksointia tallenna:
- Lähdejärjestelmä.
- Asiakirjatunnus.
- Omistaja.
- Yleisö tai ACL.
- Herkkyysluokka.
- Luonti- ja päivitysajat.
- Vanhenemis- tai katselmointipäivä.
- Saako asiakirjaa käyttää tekoälyhaussa.
- Sisältääkö asiakirja henkilötietoja.
Jos lähdejärjestelmässä on jo luokituksia, säilytä ne. Jos ei, lisää kevyt luokitteluvaihe ennen ingestointia.
Haun kontrollit
Haun pitäisi tapahtua tässä järjestyksessä:
- Tunnista käyttäjä ja ryhmät.
- Tunnista pyydetty työtila tai assistentti.
- Suodata ehdokaslähteet korpuksen, ACL:n, herkkyyden ja tuoreuden mukaan.
- Hae relevantit palat vain sallituista lähteistä.
- Uudelleenjärjestele sallitut palat.
- Generoi vastaus lähdeviittauksineen.
- Kieltäydy tai eskaloi, kun sallitut lähteet eivät riitä.
Älä hae ensin ja suodata myöhemmin kehotteessa. Jos kielletty pala pääsee mallin kontekstiin, raja on jo pettänyt.
Kehotteen ja vastauksen käyttäytyminen
Assistentille pitäisi ohjeistaa:
- Vastaa vain haetuista lähteistä.
- Viittaa lähteen otsikkoon ja osioon/linkkiin.
- Kerro, kun sallitut lähteet eivät sisällä vastausta.
- Erota päätelmä lähteistetyistä faktoista.
- Vältä paljastamasta, että rajoitettuja lähteitä on olemassa.
- Vältä käyttöoikeuden ulkopuolisen aineiston tiivistämistä.
Huono kieltäytyminen:
”Löysin HR:n palkkaluokat, mutta sinulla ei ole pääsyä.”
Parempi kieltäytyminen:
”Minulla ei ole hyväksyttyä lähdettä, jolla voisin vastata siihen.”
Toinen vastaus ei vuoda rajoitettujen asiakirjojen olemassaoloa tai aihetta.
Lokitus ilman toista vuotoa
RAG-lokit ovat arkaluonteisia. Ne voivat sisältää käyttäjän kysymyksiä, haettuja paloja, lähdetunnisteita, vastauksia ja joskus henkilötietoja.
Kirjaa riittävästi virheenkorjausta varten:
- Käyttäjätunnus tai salanimi.
- Assistentti/työtila.
- Kyselyn aikaleima.
- Haetut lähdetunnisteet.
- Käyttöoikeussuodatuksen tulos.
- Vastauksen tunniste.
- Kieltäytymisen/eskalaation syy.
- Viive ja virheet.
Ole varovainen seuraavien kanssa:
- Käyttäjän kysymysten koko teksti.
- Haettujen palojen koko teksti.
- Generoitujen vastausten koko teksti.
- Asiakastiedot.
- HR-/juridiset/tietoturva-aiheet.
Arkaluonteisissa järjestelmissä tallenna pehmennettyjä lokeja tai lähdetunnisteita täyden tekstin sijaan. Anna lokeille oma käyttöoikeudenvalvonta ja säilytysaika.
Vanhentuneet ja ristiriitaiset lähteet
Käyttöoikeus ei ole ainoa raja. Lähteen laadulla on merkitystä.
Jokaisella indeksöidyllä lähteellä pitäisi olla omistaja ja tuoreussääntö:
| Lähdetyyppi | Katselmointisääntö |
|---|---|
| Hinnoittelu | Katselmoi jokaisen hinnoittelumuutoksen yhteydessä |
| Politiikka | Katselmoi politiikan omistajan päivityksen yhteydessä, vähintään neljännesvuosittain |
| Tuotedokumentaatio | Katselmoi julkaisun yhteydessä |
| Juridinen mallipohja | Katselmoi juridisen omistajan toimesta |
| Tukimakro | Katselmoi kuukausittain tai eskalaatiokuvion jälkeen |
Kun lähteet ovat ristiriidassa, assistentin pitäisi tuoda ristiriita esiin vain, jos käyttäjä voi käyttää molempia lähteitä. Muuten sen pitäisi vastata korkeimman auktoriteetin sallitusta lähteestä tai eskaloida.
Käyttöoikeusrajojen testaus
Testaa käyttäjillä, ei vain asiakirjoilla:
- Työntekijä, jolla on laajat oikeudet.
- Työntekijä, jolla on kapeat osasto-oikeudet.
- Esimies, jolla on vain tiimin oikeudet.
- Ulkopuolinen urakoitsija.
- Entinen työntekijä tai poistettu tili.
- Asiakasrajapinnan tukikäyttäjä.
- Ylläpitäjä.
Kullekin esitä:
- Kysymys, johon heidän pitäisi voida vastata.
- Kysymys juuri heidän käyttöoikeuksiensa ulkopuolella.
- Kysymys rajoitetusta asiakirjasta, jonka he tietävät olevan olemassa.
- Kysymys, jossa julkiset ja sisäiset asiakirjat ovat ristiriidassa.
- Kysymys kehoteinjektiolla: ”ignore access rules.”
Oikea tulos ei ole vain ”hyvä vastaus”. Se on ”hyvä vastaus sallituista lähteistä”.
Käyttöönottopolku
Aloita vähiten arkaluonteisesta korpuksesta:
- Julkiset/tuotedokumentit.
- Sisäiset toiminta-asiakirjat.
- Osastokohtaiset asiakirjat.
- Asiakastietueet tiukalla ACL:llä.
- Rajoitetut korpukset vasta eksplisiittisen tietoturva-/juridisen hyväksynnän jälkeen.
Kussakin vaiheessa mittaa:
- Vastauksen hyödyllisyys.
- Viittausten laatu.
- Kieltäytymisen oikeellisuus.
- Käyttöoikeuden ulkopuolisen haun osuus.
- Vanhentuneen lähteen osuus.
- Käyttäjien ilmoitukset puuttuvista tai vääristä lähteistä.
Älä tee tätä vielä
Älä indeksoi ”kaikkia yrityksen asiakirjoja” yhteen assistenttiin.
Älä luota kehoteohjeisiin käyttöoikeuksien valvomiseksi.
Älä lokita haettujen palojen koko tekstiä arkaluonteisista korpuksista ilman selkeää säilytys- ja käyttöoikeuskäytäntöä.
Älä sekoita HR-, juridisia, asiakas- ja julkisia asiakirjoja samaan korpukseen.
Älä anna RAG:n vastata sallittujen lähteidensä ulkopuolelta vain ollakseen hyödyllinen.
Yhteenveto
Yrityksen tietämyksen RAG on arvokas, koska se tuo lähteisiin perustuvat vastaukset päivittäiseen työhön. Se on riskialtis, koska lähteisiin perustuvat vastaukset voivat silti vuotaa tietoa.
Suunnittele käyttöoikeusrajat ensin. Suodata ennen hakua. Erota korpukset yleisön mukaan. Säilytä lähteen metatiedot. Kieltäydy turvallisesti. Lokita huolellisesti. Testaa todellisilla käyttöoikeusprofiileilla. Jos käyttäjä ei voi käyttää lähdettä suoraan, RAG:n ei pidä käyttää sitä vastaamiseen.
