Sok belső tudásbázis-kereső RAG-elven működik: a nyelvi modell a kérdés mellé megkapja a szervezet saját dokumentumaiból kikeresett részleteket, és ezekből fogalmazza meg a választ. Így a modell olyasmiről is tud beszélni, ami sosem szerepelt a tanítóadatai között, például a belső szabályzatokról, a műszaki leírásokról vagy a tavalyi projektek dokumentációjáról.
A gyakorlatban a nehezebb kérdés az, hogy a válaszba kinek a dokumentumai kerülhetnek. A forrásrendszerekben a jogosultságok évek alatt alakultak ki mappánként, csoportonként és kivételenként. Ha a kereső ezt nem követi pontosan, a beszélgetőablak olyan adatot is kiad, amelyet a kérdező a fájlszerveren sosem nyithatna meg. Ez a cikk végigveszi, hol dől el a hozzáférés egy RAG-rendszerben, és melyik ponton kell a jogosultságokat érvényesíteni.
Hogyan működik a RAG
A RAG (retrieval-augmented generation, keresővel kiegészített szöveggenerálás) két külön folyamatból áll. Az egyik előre, a háttérben fut és felépíti az indexet, a másik minden kérdésnél lefut.
Indexelés
Egy betöltő folyamat végigolvassa a forrásrendszereket: a dokumentumtárat, a wikit, a jegykezelőt, a levelezés egy részét. A dokumentumokat kisebb, néhány bekezdésnyi darabokra (chunkokra) vágja, és minden darabból egy beágyazási modell vektort készít. Ez a vektor a szöveg jelentését számokként írja le, így a hasonló tartalmú darabok a vektortérben közel kerülnek egymáshoz. A vektorok a szövegdarabbal és néhány leíró adattal együtt egy vektoradatbázisba kerülnek.
Lekérdezés
Amikor a felhasználó kérdez, a rendszer a kérdésből is vektort készít, és megkeresi a hozzá leginkább hasonló darabokat. Sok megoldás ezt kulcsszavas kereséssel egészíti ki, majd egy újrarangsoroló lépéssel kiválasztja a legjobb néhány találatot. Ezek a darabok a kérdéssel együtt a nyelvi modell elé kerülnek, amely belőlük írja meg a választ.
A modell bármit felhasználhat, ami a kontextusába került. Jogosultságot nem ismer, és nem tudja, hogy egy szövegdarab honnan jött vagy ki láthatja, így amit a keresés odaadott neki, arról beszélhet is.
A kockázat: a válasz többet mutat, mint amit a kérdező láthat
Az első prototípusoknál a betöltő folyamat jellemzően egy technikai fiókkal fut, amely mindent olvashat, hiszen mindent indexelnie kell. Ha a lekérdezés is ezzel a fiókkal, szűrés nélkül keres, akkor minden felhasználó a teljes indexből kap találatot. Egy ártatlan kérdés a szabadságolásról így előhozhatja a bértáblázat egy sorát vagy egy folyamatban lévő munkaügyi vizsgálat jegyzőkönyvét.
A szivárgáshoz a teljes dokumentum sem kell. Elég, ha a modell egyetlen mondatot átvesz belőle, vagy a választ úgy fogalmazza meg, hogy abból kikövetkeztethető egy döntés, egy összeg vagy egy név. Az OWASP a nagy nyelvi modelleken alapuló alkalmazások 2025-ös kockázati listáján (OWASP Top 10 for LLM Applications 2025) külön kategóriaként tartja számon az érzékeny információ kiadását a válaszban (LLM02) és a vektortárak, beágyazások gyengeségeit (LLM08).
A rendszerprompt nem hozzáférés-szabályozás
Gyakori egyszerűsítés, hogy a fejlesztők a modell utasításai közé beírják: bizalmas adatot ne adjon ki. A modell azonban nem tudja megítélni, hogy egy adat bizalmas-e az adott kérdező számára, és egy ügyesen megfogalmazott kérdés vagy egy dokumentumba rejtett utasítás felülírhatja ezt a kérést. Az utóbbit a fogalomtár prompt-injekció szócikke magyarázza. A jogosultság kérdését a keresésnek kell eldöntenie, mielőtt bármi a modellhez jut.
Ami eddig rejtve maradt
A RAG egy régi hibát is felszínre hoz. A fájlszerveren rengeteg mappa van túl tágan megosztva, de amíg senki nem tudta, hogy ott van, a túlzott megosztásnak nem volt következménye. Egy jól működő kereső ezeket a dokumentumokat is megtalálja, és pontosan annak mutatja meg, aki rákérdez. Ezért a bevezetés előtt a forrásrendszerek megosztásait is át kell nézni, a legkisebb jogosultság elve szerint.
Jogosultságszűrés a keresés előtt
A jogosultságot a lekérdezés több pontján is lehet ellenőrizni. A különbség abban áll, hogy a tiltott tartalom eljut-e egyáltalán a rendszer további részeibe.
| Megoldás | Hogyan működik | Gyengesége |
|---|---|---|
| Szűrés a modellnél | A modell utasítást kap, hogy ne használja a tiltott részleteket. | Megkerülhető, a tiltott szöveg már a kontextusban van. |
| Utószűrés | A keresés a teljes indexből adja vissza a legjobb találatokat, ezekből utólag törlik, amit a kérdező nem láthat. | A tiltott darabok bejárják a keresési láncot, és ha a legjobb találatok mind tiltottak, a válasz üres vagy gyenge lesz. |
| Előszűrés | A keresés eleve csak azok között a darabok között fut, amelyekhez a kérdezőnek joga van. | A darabokon pontos és naprakész jogosultsági adat kell. |
| Ellenőrzés a forrásnál | A kiválasztott találatokat a rendszer a forrásrendszerben, a kérdező nevében újra lekéri vagy ellenőrzi. | Lassabb, és minden forrásrendszerhez külön illesztés kell. |
A megbízható megoldás az előszűrés, és ahol a forrásrendszer engedi, a végső néhány találat ellenőrzése a forrásnál. A végső találatoknál így az index késése sem okoz szivárgást: ha valakitől tegnap elvették a jogot, a forrásrendszer ma már nem adja oda neki a dokumentumot, akkor sem, ha az index még nem frissült.
A kérdező személyazonossága
Az előszűréshez és a forrásnál végzett ellenőrzéshez is az kell, hogy a keresés tudja, ki kérdez. Az alkalmazásnak a bejelentkezett felhasználó azonosságát kell továbbadnia a keresőnek, és a csoporttagságot a központi identitáskezelőtől kell vennie, a felhasználó böngészőjéből érkező adatban megbízni nem szabad. A technikai fiók maradjon a betöltés eszköze, a lekérdezés pedig a kérdező jogaival fusson.
Származtatott tartalom
Egyes rendszerek nemcsak darabokat tárolnak, hanem előre elkészített összefoglalókat, gyakori kérdésekre adott válaszokat vagy gyorsítótárat is. Ha egy összefoglaló több dokumentumból készült, csak az láthatja, aki mindegyik forráshoz hozzáfér. A gyorsítótárazott választ sem szabad egy másik felhasználónak visszaadni, ha ő kevesebbet láthat, mint az, akinek eredetileg készült.
A forrásrendszerek jogosultságainak szinkronizálása
Az előszűrés csak annyira jó, amennyire az index jogosultsági adata megfelel a forrásrendszer valós állapotának. A jogosultságok viszont folyamatosan változnak: valaki átkerül egy másik osztályra, egy projektmappát lezárnak, egy dokumentumot visszavonnak.
- Változáskövetés. Ahol a forrásrendszer értesítést küld a módosításokról, a betöltő folyamat dolgozza fel ezeket, és ne csak a tartalom, hanem a jogosultság változására is frissítse az érintett darabokat.
- Időszakos teljes egyeztetés. Az értesítések elveszhetnek, ezért időnként a teljes indexet össze kell vetni a forrással, és a különbségeket javítani.
- Törlés. Ha egy dokumentumot a forrásban törölnek, minden belőle készült darabnak, összefoglalónak és gyorsítótár-bejegyzésnek is el kell tűnnie.
- Csoportok feloldása. Ha az index a csoportokat tárolja és a kérdező csoporttagságát a lekérdezéskor oldja fel, egy csoporttagság változásához nem kell az indexet újraírni. A beágyazott csoportokat és a tiltó bejegyzéseket a feloldásnak is kezelnie kell.
Külön figyelmet kérnek a forrásrendszer azon megosztási formái, amelyeknek nincs egyértelmű megfelelője az indexben, például a hivatkozással bárki számára megnyitható dokumentumok vagy a külső vendégeknek adott jog. Ha a betöltő nem tudja egy dokumentum jogosultságát biztosan leképezni, ne indexelje, vagy csak egy szűk, kifejezetten engedélyezett körnek tegye elérhetővé.
A szinkronizálást tesztelni is kell. Néhány ismert jogosultságú tesztfiókkal rögzíthető, melyik kérdésre melyik dokumentum nem jelenhet meg, és ezt minden módosítás után újra le kell futtatni.
Vektoradatbázis és metaadatok
Az előszűrés a darabokhoz tárolt metaadatokra épül. Egy darab mellett legalább a forrásdokumentum azonosítója, a forrásrendszer, a jogosultsági lista (a dokumentumot olvasható felhasználók és csoportok), az érzékenységi besorolás és az utolsó módosítás ideje szerepeljen. A szűrés ezekre a mezőkre fut, a hasonlósági keresés pedig csak a megmaradt darabok között.
Hiba esetén ne adjon hozzáférést
A metaadatokat a betöltő folyamat írja, a lekérdező oldal nem módosíthatja őket. Az a darab, amelynél a jogosultsági mező üres vagy értelmezhetetlen, senkinek ne jelenjen meg. Ha a szabály fordított, egy hibás betöltés csendben mindenki számára elérhetővé teszi a dokumentumokat.
Egy index vagy több
Ha a rendszer több szervezetet vagy egymástól élesen elválasztott egységet szolgál ki, biztonságosabb külön gyűjteményt vagy névteret használni egységenként, mint egyetlen közös indexben szűrni. Ugyanez igaz a legérzékenyebb adatokra, például a személyügyi vagy a jogi dokumentumokra: ezeket érdemes külön indexben tartani, amelyhez csak a jogosult alkalmazás fér hozzá, mert akkor egy hibás szűrőfeltétel sem teszi elérhetővé a teljes tartalmat.
A vektor is adat
A beágyazási vektorokból az eredeti szöveg egy része visszafejthető, a vektortár mellett pedig általában maga a szövegdarab is ott van. A vektoradatbázis ezért ugyanazt a védelmet igényli, mint a forrásrendszer: szűk adminisztrátori hozzáférést, titkosítást, védett mentéseket. Aki a vektortárat közvetlenül lekérdezheti, az a jogosultsági szűrést teljesen megkerüli.
Naplózás és forrásmegjelölés
Egy RAG-rendszer naplójából vissza kell tudni követni, ki mit kérdezett, mely darabokat adta vissza a keresés, ezek közül melyik jutott el a modellig, és mit válaszolt a modell. Ha később kiderül, hogy egy dokumentum jogosultsága hibás volt, ebből látszik, kik kaptak belőle részletet.
A napló maga is érzékeny, hiszen a kérdések és a válaszok bizalmas tartalmat hordozhatnak. Hozzáférése legyen szűk, a megőrzési ideje meghatározott, és ha a kérdések szövegét nem szükséges tárolni, elég lehet a dokumentum-azonosítók naplózása. Hogy egy biztonsági eseményhez általában mit érdemes gyűjteni, azt a naplózásról szóló cikk foglalja össze.
Forrásmegjelölés a válaszban
Jó gyakorlat, hogy a válasz alatt a rendszer felsorolja, mely dokumentumokból dolgozott, hivatkozással a forrásrendszerre. A felhasználó így ellenőrizheti, hogy a modell nem talált-e ki valamit, a hivatkozás megnyitásakor pedig a forrásrendszer még egyszer ellenőrzi a jogosultságát. A forrásmegjelölés a hibát is láthatóvá teszi: ha valaki olyan dokumentumot lát a listában, amelyhez nem lenne szabad hozzáférnie, azt jelezni tudja.
Riasztás
A naplóra érdemes néhány egyszerű riasztást építeni. Gyanús, ha egy felhasználó rövid idő alatt sok különböző dokumentumot hoz elő egy számára szokatlan területről, vagy ha a keresés a szűrés után feltűnően gyakran üres, mert ez jogosultsági vagy szinkronizálási hibára utalhat. Az AI-bevezetés többi kockázatáról a vállalati AI-bevezetés biztonsági kockázatairól szóló cikk ír.
Kapcsolódó szolgáltatás: Biztonságos AI-megoldás fejlesztése →
