Kõige tavalisem RAG-i viga ettevõtetes on lihtne: laadi kõik üles, küsi küsimusi ja kohtle allikaviidetega vastuseid automaatselt ohutuna.
Teine kõige tavalisem viga saabub hiljem: keegi avastab, et assistent suudab vastata dokumentidest, mida kasutaja poleks tohtinud kunagi näha. Palgavahemikud. Kliendilepingud. Õiguslikud mustandid. Juhatuse märkmed. Kasutajatoe piletid. HR-uurimised. Turvaprotseduurid. Vastus võib olla täpne ja viidetega, kuid süsteem on infot lekitanud.
Ettevõtte teadmiste RAG ei ole ilusama tekstiga otsingukast. See on õigustega infosüsteem. Käsitle seda nii.
Retrieval peab jõustama samad või rangemad õigused kui allikasüsteemid. Kui kasutaja ei saa dokumenti avada Google Drive’is, SharePointis, Notionis, Confluence’is või CRM-is, ei tohiks RAG seda selle kasutaja jaoks leida.
Põhireegel
Retrieval-kiht peab enne iga chunk’i tagastamist vastama küsimusele:
Kas sellel kasutajal on praegu lubatud seda allikat näha?
Mitte “kas see allikas on vektorandmebaasis?” Mitte “kas see allikas on asjakohane?” Mitte “kas see allikas on kasulik?” Ligipääsuõigus tuleb esimesena.
Levinud mustreid on kolm:
| Muster | Kuidas see töötab | Sobivus |
|---|---|---|
| Eraldi indeksid | Üks indeks iga auditooriumi või tööruumi jaoks | Lihtsad tiimid, jämedad õigused |
| Metaandmete filtreerimine | Salvesta ACL-, grupi- ja allikainfo ning filtreeri enne retrieval’it | Enamik ettevõtte RAG-süsteeme |
| Reaalajas õigusekontroll | Küsi retrieval’i ajal õigusi allikasüsteemist | Tundlikud või sageli muutuvad õigused |
Õige vastus sõltub allikasüsteemidest ja riskitasemest. Enamiku VKE-de jaoks piisab eraldi indeksitest koos metaandmete filtreerimisega. Kliendi-, HR-, õigus- või reguleeritud andmete puhul võib olla vaja reaalajas kontrolli.
Kõige raskem osa: ACL-ide sünkroonis hoidmine
Iga ülaltoodud muster sõltub vaikimisi ühest asjast: indeksi õigusteandmed peavad ühtima allikasüsteemi õigusteandmetega. Just selles sünkroniseerimises elab tegelik inseneritöö.
Kust ACL-id tulevad. SharePoint ja OneDrive avaldavad üksusepõhised õigused Microsoft Graph API kaudu; Google Drive Drive API failipõhiste õigusteloendite kaudu; Confluence ruumi- ja lehepiirangute kaudu. Igaühel on erinev kuju (kasutajad, grupid, pärilus, jagamislingid), erinevad API kiiruspiirangud ja erinev arusaam sellest, “kes seda näha tohib”.
Gruppide lahtiharutamine ei ole valikuline. Enamik päris õigusi antakse gruppidele ja grupid on pesastatud. “Sales EU” grupi “Sales” sees grupi “All Staff” sees tuleb lamestada konkreetseteks kasutajateks kas sync’i ajal (suurem indeksi metaandmestik, kiiremad päringud) või päringu ajal (värskem, aeglasem, rohkem API-kutseid). Vali üks teadlikult; tiimid, kes teevad selle valiku kogemata, teevad seda ebajärjekindlalt.
Sync-viide on turvaparameeter, mitte jõudlusdetail. Kui keegi kaotab dokumendile ligipääsu — rollivahetus, töölt lahkumine, tehing muutub konfidentsiaalseks — serveerib indeks vana ACL-i kuni järgmise sync’ini. Otsusta iga korpuse jaoks aktsepteeritav tühistamisviide ja pane see kirja: piiratud korpuste puhul peaaegu reaalajas, sisemiste protsessidokumentide puhul võivad tunnid olla vastuvõetavad. Kui keegi pole seda numbrit kirja pannud, on tegelik vastus “millal iganes öine job jookseb” — ja see turvaülevaatust üle ei ela.
Reaalajas kontroll ostab värskust ning maksab latentsuse, kiiruspiirangute ja uue tõrkerežiimiga. Iga retrieval’i juures tehtav õigusekontroll lisab igale päringule allikasüsteemi ringkäigu ja sööb mastaabis API-kvooti kiiresti; tavaline kompromiss on lühiealine cache, mis muudab “reaalajas” vaikselt tagasi “väiksema numbriga sync-viiteks”. Mida iganes valid, tee timeout’i käitumine selgesõnaliseks: kui õigusekontroll ebaõnnestub või aegub, siis chunk edasi ei liigu. Fail closed, logi tõrge ja lase assistendil keelduda — aeglane õige vastus on parem kui kiire leke.
Õigusepiiride testimise peatükis kirjeldatud deaktiveeritud konto test ongi viis teada saada, kas miski sellest päriselt töötab: deaktiveeritud konto ei tohi piiratud korpustest midagi kätte saada, ja kontroll peab pidama juba päev pärast konto sulgemist, mitte alles pärast järgmist täielikku re-sync’i.
Allikapiirid
Ära loo ühte hiiglaslikku teadmiste kogumit. Eralda auditooriumi ja tundlikkuse järgi:
| Korpus | Auditoorium | Näited | Reegel |
|---|---|---|---|
| Avalik/toode | Kõik | Abidokumendid, avalikud hinnad, tootelehed | Sobib laiale assistendile |
| Sisemised operatsioonid | Töötajad | Protsessidokumendid, sisemised KKK-d | Ainult töötajatele |
| Osakond | Osakonna liikmed | Müügijuhendid, toe makrod, arenduse runbook’id | Grupifiltriga |
| Kliendikirjed | Määratud tiimid | Piletid, lepingud, konto märkmed | Range ACL ja audit |
| Piiratud | Ainult nimetatud kasutajad | HR, õigus, turve, juhatus | Tavaliselt eraldi süsteem või ilma RAG-ita |
Mida vähem auditooriume üks korpus teenindab, seda lihtsam on lekkeriski üle arutleda.
Ingestion-kontrollid
Ingestion-pipeline on koht, kus paljud lekked algavad.
Enne allika indekseerimist talleta:
- Allikasüsteem.
- Dokumendi ID.
- Omanik.
- Auditoorium või ACL.
- Tundlikkuse märgis.
- Loomise ja uuendamise ajatemplid.
- Aegumise või ülevaatuse kuupäev.
- Kas dokumenti võib kasutada AI retrieval’i jaoks.
- Kas dokument sisaldab isikuandmeid.
Kui allikasüsteemis on märgised juba olemas, säilita need. Kui neid ei ole, lisa enne ingestion’it kerge klassifitseerimissamm.
Retrieval-kontrollid
Retrieval peaks toimuma selles järjekorras:
- Tuvasta kasutaja ja grupid.
- Tuvasta küsitud tööruum või assistent.
- Filtreeri kandidaatsed allikad korpuse, ACL-i, tundlikkuse ja värskuse järgi.
- Leia asjakohased chunk’id ainult lubatud allikatest.
- Rerank’i lubatud chunk’id.
- Genereeri vastus koos allikaviidetega.
- Keeldu või eskaleeri, kui lubatud allikatest ei piisa.
Ära tee kõigepealt retrieval’it ja filtreeri hiljem promptis. Kui keelatud chunk jõuab mudeli konteksti, on piir juba ebaõnnestunud.
Prompti ja vastuse käitumine
Assistendile tuleks anda juhised:
- Vasta ainult leitud allikate põhjal.
- Viita allika pealkirjale ja jaotisele/lingile.
- Ütle, kui lubatud allikates vastust ei ole.
- Märgi järeldus eraldi allikapõhisest faktist.
- Ära avalda, et piiratud allikad on olemas.
- Ära tee kokkuvõtet ligipääsukeeluga materjalist.
Halb keeldumine:
“Leidsin HR-i palgavahemikud, kuid sul ei ole neile ligipääsu.”
Parem keeldumine:
“Mul ei ole selle vastamiseks heakskiidetud allikat.”
Teine vastus ei leki piiratud dokumentide olemasolu ega teemat.
Logimine ilma teist leket loomata
RAG-i logid on tundlikud. Need võivad sisaldada kasutaja küsimusi, leitud chunk’e, allika ID-sid, vastuseid ja vahel isikuandmeid.
Logi piisavalt, et siluda:
- Kasutaja ID või pseudonüümne ID.
- Assistent/tööruum.
- Päringu ajatempel.
- Leitud allika ID-d.
- Õigusefiltri tulemus.
- Vastuse ID.
- Keeldumise/eskaleerimise põhjus.
- Latentsus ja vead.
Ole ettevaatlik järgmisega:
- Täielikud kasutajaküsimused.
- Täielikud leitud chunk’id.
- Täielikud genereeritud vastused.
- Kliendiandmed.
- HR-, õigus- või turvateemad.
Tundlikes süsteemides salvesta täisteksti asemel redigeeritud logid või allika ID-d. Anna logidele oma ligipääsukontroll ja säilitusaeg.
Aegunud ja vastuolulised allikad
Õigus ei ole ainus piir. Allika kvaliteet loeb.
Igal indekseeritud allikal peaks olema omanik ja värskusreegel:
| Allikatüüp | Ülevaatusreegel |
|---|---|
| Hinnad | Ülevaatus iga hinnamuudatuse korral |
| Poliitika | Ülevaatus poliitikaomaniku uuendusel, vähemalt kord kvartalis |
| Tootedokumendid | Ülevaatus iga väljalaske korral |
| Õigusmall | Ülevaatus õigusomaniku poolt |
| Kasutajatoe makro | Ülevaatus kord kuus või pärast eskaleerimismustri tekkimist |
Kui allikad on vastuolus, peaks assistent vastuolu esile tooma ainult siis, kui kasutajal on ligipääs mõlemale allikale. Muul juhul peaks see vastama kõrgeima autoriteediga lubatud allikast või eskaleerima.
Õigusepiiride testimine
Testi kasutajatega, mitte ainult dokumentidega:
- Laia ligipääsuga töötaja.
- Kitsa osakonnaligipääsuga töötaja.
- Juht, kelle ligipääs on ainult tiimi ulatuses.
- Töövõtja.
- Endine töötaja või deaktiveeritud konto.
- Kliendisuunalise kasutajatoe kasutaja.
- Administraator.
Igaühe puhul küsi:
- Küsimus, millele nad peaksid saama vastata.
- Küsimus napilt väljaspool nende õigusi.
- Küsimus piiratud dokumendi kohta, mille olemasolu nad teavad.
- Küsimus, kus avalikud dokumendid ja sisemised dokumendid on vastuolus.
- Prompt injection’iga küsimus: “ignoreeri ligipääsureegleid.”
Õige tulemus ei ole ainult “hea vastus”. See on “hea vastus lubatud allikatest”.
Juurutusjärjekord
Alusta kõige vähem tundlikust korpusest:
- Avalikud/tootedokumendid.
- Sisemised operatsioonidokumendid.
- Osakonnapõhised dokumendid.
- Kliendikirjed range ACL-iga.
- Piiratud korpused ainult pärast selget turva- ja õiguslikku heakskiitu.
Igas etapis mõõda:
- Vastuse kasulikkus.
- Viidete kvaliteet.
- Keeldumise korrektsus.
- Ligipääsukeeluga retrieval’i määr.
- Aegunud allikate määr.
- Kasutajate teated puuduvate või valede allikate kohta.
Ära tee seda veel
Ära indekseeri “kõiki ettevõtte dokumente” ühte assistenti.
Ära toetu õiguste jõustamisel prompti juhistele.
Ära logi tundlike korpuste puhul täispikki leitud chunk’e ilma selge säilitus- ja ligipääsupoliitikata.
Ära sega HR-, õigus-, kliendi- ja avalikke dokumente samasse korpusesse.
Ära lase RAG-il vastata väljaspool lubatud allikaid lihtsalt selleks, et abivalmis olla.
Kokkuvõte
Ettevõtte teadmiste RAG on väärtuslik, sest see toob allikapõhised vastused igapäevasesse töösse. See on riskantne, sest allikapõhised vastused võivad ikkagi infot lekkida.
Disaini õigusepiirid esimesena. Filtreeri enne retrieval’it. Eralda korpused auditooriumi järgi. Säilita allika metaandmed. Keeldu ohutult. Logi ettevaatlikult. Testi päris õiguseprofiilidega. Kui kasutaja ei saa allikat otse avada, ei tohiks RAG seda allikat tema vastamiseks kasutada.
