Ettevõtte teadmiste RAG: õigused, lekked ja allikapiirid

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:

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

Sünkroonimisviivitus on turvaparameeter, mitte jõudluse pisiasi. Kui keegi kaotab dokumendile juurdepääsu rollivahetuse, töölt lahkumise või tehingu konfidentsiaalseks muutumise tõttu, kasutab indeks vana juurdepääsuloendit järgmise sünkroonimiseni. Määra igale korpusele vastuvõetav õiguste tühistamise viivitus: piiratud korpuse puhul peaaegu reaalajas, sisemiste protsessidokumentide puhul võivad sobida tunnid. Kui seda väärtust pole kirja pandud, tähendab tegelik vastus „siis, kui öine töö juhtub käivituma“, mis ei läbi turvaülevaatust.

Reaalajas kontroll tagab värskuse latentsuse, kiiruspiirangute ja uue tõrkerežiimi hinnaga. Iga otsingu ajal tehtav õigusekontroll lisab päringule allikasüsteemi edasi-tagasi kutse ning kulutab suure mahu korral kiiresti API-kvooti. Tavaline kompromiss on lühikese elueaga vahemälu, mille tõttu „reaalajas“ tähendab tegelikult lühemat sünkroonimisviivitust. Määra igal juhul ajalõpu käitumine selgelt: kui õigusekontroll ebaõnnestub või aegub, ei tohi tekstilõik edasi liikuda. Keela vaikimisi ligipääs, logi tõrge ja lase assistendil vastamisest keelduda — aeglane õige vastus on parem kui kiire andmeleke.

Õ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:

Mida vähem auditooriume üks korpus teenindab, seda lihtsam on lekkeriski üle arutleda.

Andmete sisestamise kontrollid

Paljud lekked saavad alguse andmete sisestamise töövoost.

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-põhiseks otsinguks.
• Kas dokument sisaldab isikuandmeid.

Kui allikasüsteemis on märgised juba olemas, säilita need. Kui neid ei ole, lisa enne andmete sisestamist lihtne klassifitseerimissamm.

Otsingu juurdepääsukontrollid

Otsing peaks toimuma järgmises järjekorras.

1. Tuvasta kasutaja ja grupid.
2. Tuvasta küsitud tööruum või assistent.
3. Filtreeri võimalikud allikad korpuse, pääsuloendi, tundlikkuse ja värskuse järgi.
4. Otsi asjakohaseid tekstiosi ainult lubatud allikatest.
5. Reasta lubatud tekstiosad ümber.
6. Koosta vastus koos allikaviidetega.
7. Keeldu vastamast või suuna juhtum edasi, kui lubatud allikatest ei piisa.

Ära otsi kõigepealt kõigist allikatest ega filtreeri tulemusi alles hiljem promptis. Kui keelatud tekstiosa jõuab mudeli konteksti, on juurdepääsupiir juba rikutud.

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.
• Leitud tekstiosad täismahus.
• 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:

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.
• Promptisüstiga 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:

1. Avalikud/tootedokumendid.
2. Sisemised operatsioonidokumendid.
3. Osakonnapõhised dokumendid.
4. Kliendikirjed range ACL-iga.
5. 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.

Õigusepiirid ennekõike

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.