A RAG-adatmérgezés megelőzése: Forrásproveniencia, karantén és re-indexelési tesztek

Egy weboldali chatbot képes udvarias, nyelvileg meggyőző és technikailag hibátlan választ adni – miközben mégis egy mérgezett tudásbázisból dolgozik. RAG-adatmérgezés esetén nem elsősorban az egyes kérések megfogalmazását manipulálják. Ehelyett téves, hamisított vagy elégtelenül ellenőrzött tartalmak kerülnek be a tartós adatkezelési láncba: forrás, parser, chunk, metaadat, embedding és végül az éles keresési index. A hiba így számos munkameneten keresztül fennmarad, és a normális kérdéseket is hátrányosan befolyásolhatja.

A hatékony védelem ezért jóval a prompt előtt kezdődik. A csapatoknak minden egyes tudáselemről tudniuk kell: Honnan származik, ki a felelőse, melyik verziót dolgozták fel, milyen átalakítások történtek, és milyen ellenőrzés után engedélyezték a kereséshez? A forrásproveniencia biztosítja ezt a nyomvonalat. A technikailag elkülönített karantén megakadályozhatja, hogy az ellenőrizetlen módosítások azonnal lekérdezhetővé váljanak. A célzott re-indexelési tesztek ezt követően ellenőrzik, hogy a megtisztított tartalmak valóban felváltották-e a régi chunkokat.

Mi a RAG-adatmérgezés – és mi nem az

Az OWASP LLM04:2025 besorolás a Data and Model Poisoning témakörben az előtanítási, fine-tuning vagy embedding adatok manipulációját integritási kockázatként írja le. Egy weboldali chatbot esetében különösen az utóbbi változat kézzelfogható: egy dokumentumot beolvas a rendszer és szakaszokra bontja; ezeket a chunkokat beágyazza és vektorként eltárolja a keresési indexben. Ha ez a dokumentum szándékosan vagy véletlenül torzul, a megfelelő kérdéseknél látszólag releváns alapként jelenhet meg.

A kockázatokat meg kell különböztetni, de átfedésben lehetnek: a Prompt Injection a futási időben próbál meg utasításokat vagy adatokat betáplálni úgy, hogy a rendszer megváltoztassa a tervezett viselkedését; az indirekt Prompt Injection mindeközben a lekérdezett dokumentumokon keresztül is bekerülhet a kontextusba. Az adatmérgezés ezzel szemben a hosszabb élettartamú tudáskészletet vagy annak származékait módosítja. A hozzáférési jogosultságok is más problémát oldanak meg: meghatározzák, hogy melyik személy láthat egy dokumentumot. A proveniencia és a jóváhagyás dönt arról, hogy ez a dokumentum megbízható tudásforrásként bekerüljön-e az indexbe. Egy robusztus architektúrában mindhárom kockázat saját ellenőrzést és összehangolt átmeneteket igényel.

A támadási felület a teljes adatkezelési láncra kiterjed

Egy RAG-index ritkán jön létre egyetlen, manuálisan ellenőrzött gyűjteményből. A crawlerek weboldalakat olvasnak be, a konnektorok felhőmappákat szinkronizálnak, a felhasználók fájlokat töltenek fel, az interfészek pedig termékadatokat importálnak. Ehhez jönnek még a parserek, az OCR, a nyelvi tisztítás, a chunking és a metaadat-dúsítás. Minden egyes lépés átvehet hibás tartalmakat, vagy kiszakíthat egy eredetileg helyes kijelentést a környezetéből.

Jellemző okok a kompromittálódott forrásrendszer, egy újrahivatkozott tükör-dokumentum, egy véletlenül közzétett piszkozat, egy hibásan hozzárendelt bérlő (tenant), vagy egy parser-frissítés, amely a táblázatértékeket rossz címsorokhoz rendeli. A kriptográfiai tartalom-hash összehasonlítása egy megbízható referenciaértékkel azonosíthatja az eltéréseket; az egyező hash azonban nem bizonyítja sem a tartalom igazságtartalmát, sem annak naprakészségét vagy jóváhagyását.

Proveniencia mint ellenőrizhető adatrekord

Minden dokumentumhoz és az abból származtatott minden egyes chunkhoz tartoznia kell egy proveniencia-adatrekordnak. A gyakorlatban hasznos legalább egy stabil forrás-ID, a kanonikus származási URL, a felelős tulajdonos, a lekérdezés időpontja, a dokumentumverzió, a tartalom-hash, a jóváhagyási státusz, a megbízhatósági osztály, a parser-verzió, a chunking-verzió, az embedding-modell és az indexgeneráció. Manuális feltöltéseknél ehhez hozzáadódik a feltöltő személy szerepköre és az ellenőrzött licenc. Szinkronizált rendszereknél az is fontos, hogy a fájl melyik hitelesített konnektoron keresztül érkezett.

A NIST AI 600-1 Generative AI Profile a tartalom-provenienciát, a nyomon követhető dokumentációt, valamint a teszteket és értékeléseket a generatív MI kockázatkezelésének fontos építőköveiként kezeli. A RAG-rendszerekre átültetve ez azt jelenti: nem csak a jelenlegi index számít. A forrásverzió, a feldolgozási folyamat és a közzétett indexgeneráció közötti nyomon követhető kapcsolat is az üzemeltetési dokumentáció része.

A karantén elválasztja a felvételt és a közzétételt

Egy központi architektúra-elem a következetes elkülönítés: az új vagy módosított tartalmak nem válnak azonnal kereshetővé. Először egy fogadó zónába (staging) kerülnek. A csővezeték ott ellenőrzi a származást, a fájltípust, a méretet, az aláírást vagy a várt hasht, az engedélyezett bérlőt, a metaadatok teljességét és a módosítás terjedelmét. A szöveg és a chunkok csak ezután jönnek létre egy nem éles indexgenerációban.

A szabályoknak kockázatalapúnak kell lenniük. Egy hitelesített, belső felelősségi körbe tartozó GYIK-oldal módosítása az automatikus tesztek után jóváhagyható. Ezzel szemben egy új domain, egy szokatlanul terjedelmes szövegmódosítás, egy ismeretlen fájltulajdonos vagy egy felelős személy nélküli forrás karantént és emberi ellenőrzést vált ki. Ha egy kötelező információ hiányzik, a "fail closed" elv érvényesül: a régi, megerősített generáció marad aktív; az új állapot nem kerül csendben közzétételre.

Jóváhagyás mint megváltoztathatatlan indexgeneráció

Az ellenőrzés után nem az éles index kerül lépésről lépésre felülírásra. Jobb megoldás egy új, verziózott generáció manifesztummal: elvárt dokumentumok, elvárt chunkok, forrás-hashek, transzformációs verziók és időbélyegek. Csak ha a tesztek sikeresek (zöldek), akkor vált át egy alias vagy egy routing-konfiguráció atomi módon erre a generációra. A korábbi generáció egy korlátozott, meghatározott ideig visszagördíthető (rollback) marad.

Az eljárás egy ellenőrzött migrációra hasonlít. A RAG embedding modell váltásáról szóló cikkünk rámutat, miért hasznosak a párhuzamos indexgenerációk és az összehasonlító tesztek technikai változtatások esetén is. Mérgezés gyanúja esetén emellett felmerül a biztonsági kérdés is: Melyik forrásverziót és mely származtatott chunkokat kell zárolni?

Fiktív példaszcenárió: Hibás visszaküldési határidő éri el a support botot

Tételezzük fel, hogy egy kereskedő chatbotot üzemeltet termék- és ügyfélszolgálati kérdésekhez. A tudásbázis minden éjjel szinkronizálja a hivatalos súgót és néhány jóváhagyott gyártói portált. Egy hivatkozás változása után azonban az egyik konnektor átirányítást követ egy nem jóváhagyott tükör-oldalra. Ott egy vizuálisan hitelesnek tűnő PDF-ben 30 helyett 90 napos visszaküldési határidő szerepel. A fájlt szakaszokra bontja a rendszer; több részlet is magas szemantikai hasonlósággal kerül be az indexbe.

Másnap reggel a bot a visszaküldési kérdéseknél a hibás határidőt ígéri. A nyelvi modellt nem programozták át, és a felhasználók sem adtak meg káros utasítást. A lekérdezés egyszerűen hibás alapot szolgáltat. A monitoring riaszt, mert egy új domain jelenik meg válaszforrásként, és a visszaküldési határidőre vonatkozó Golden Set teszt eltér a várt bizonyítéktól.

Az ellenőrzött karantén és az újraindulás

1. A csapat csak az érintett adatfelvételi forrást állítja le, és befagyasztja a jelenlegi indexgenerációt a további módosítások elől.
2. A gyanús dokumentum-ID-t, az abból származtatott összes chunk-ID-t és azok válaszokban szereplő találatait rögzítik az incidensben.
3. A tükör-domain letiltásra kerül, a chunkjai pedig karanténba mozognak. A visszaküldési határidővel kapcsolatos kérdésekre a bot átmenetileg egy biztonságos utalást ad az emberi ügyfélszolgálatra vagy az igazolt szabályzati oldalra.
4. Az alias visszaállításra kerül az utolsó igazoltan tiszta indexgenerációra. Eközben a többi, nem érintett tudásterület elérhető marad.
5. A konnektor korlátozásra kerül a kanonikus forrásra. Ezt követően a csővezeték új generációt épít a megerősített manifesztumból.
6. Ez a generáció csak a re-indexelési tesztek és a szakmai jóváhagyás után áll élesbe.

Ez a sorrend korlátozza a kárt anélkül, hogy elhamarkodottan leállítaná a teljes chatbotot. A döntő tényező a származási adatok és a származékok összekapcsolása: A dokumentum és a chunkok közötti hozzárendelés nélkül nem lenne világos, hogy mely vektorokat kell eltávolítani.

A re-indexelési teszteknek a folyamat sikeres lefutásánál többet kell igazolniuk

A zöld feladatstátusz csak azt bizonyítja, hogy a folyamat technikailag befejeződött. Nem bizonyítja sem azt, hogy a régi chunkok eltűntek, sem azt, hogy a helyes források győznek a reális kérdéseknél. Egy robusztus tesztcsomag ezért ellenőrzi a készletet, a keresést és a válaszadási viselkedést.

1. Manifesztum- és törlésellenőrzés

Hasonlítsa össze az új generációt a jóváhagyott manifesztummal. Minden elvárt dokumentumverziónak jelen kell lennie; a zárolt dokumentum- és chunk-ID-k nem fordulhatnak elő. Különösen fontosak a "tombstone"-ok a törölt vagy lecserélt tartalmakhoz. Az új embeddingek puszta hozzáfűzése különben a régi, mérgezett találatokat továbbra is az indexben hagyja.

2. Keresési tesztek az elvárt forrásokkal

A kritikus kérdéseknél nem elég egy elvárt válasszöveg. Határozzon meg emellett engedélyezett és tiltott forrás-ID-kat, a találatok minimális számát és kizárási feltételeket. A visszaküldési határidőnek például a kanonikus szabályzatból kell származnia; a karanténba helyezett tükör-domain nem jelenhet meg sem a legfelső találatok között, sem a modell kontextusában. Az ilyen tesztkészletek felépítését a válaszminőség Golden Set és RAG tesztekkel foglalkozó cikk ismerteti.

3. Negatív és manipulációs tesztek

Egy izolált tesztkörnyezetben a csapatok betáplálhatnak egy egyértelműen megjelölt, nem jóváhagyott tesztforrást. A csővezetéknek ezt karanténban kell tartania; az éleshez hasonló keresés nem kérdezheti le. Ezenkívül tesztelésre kerülnek a szokatlan domainváltások, a hiányzó tulajdonosok, a szélsőséges tartalomeltérések és az ellentmondásos dátumadatok. A NIST AI 100-2 jelentés az Adversarial Machine Learning témájában a mérgezést taxonómiájában a támadási kategóriák közé sorolja, és hangsúlyozza, hogy az ellenintézkedéseket és azok korlátait szisztematikusan kell vizsgálni.

4. Összehasonlítás a váltás előtt és után

Futtassa le ugyanazokat a kérdéseket az utolsó tiszta és az új generáción. Hasonlítsa össze a találati forrásokat, a rangsort, a válaszbizonyítékokat, a válaszhiány arányát (no-answer rate) és a szakmai értékelést. Egy kis canary-hányad további éles környezeti jelzéseket adhat, amíg a felhasználók nem férnek hozzá az ellenőrizetlen forrásokhoz. Az éles váltásra csak a meghatározott biztonsági és minőségi határértékek betartása után kerül sor.

Monitoring: A rendellenességek korai felismerése

Ne csak a válaszértékeléseket figyelje. Sokatmondóak az új vagy ritka forrásdomainek, az ellenőrizetlen források aránya az adatfelvételi folyamatban, a szokatlan dokumentumméretek, a nagy hash- vagy szövegeltérések, egyetlen tulajdonos sok új chunkja, a top források változásai a Golden Setben és a megerősített bizonyíték nélküli válaszok. A metrikáknak a proveniencia-ID-kra kell hivatkozniuk, nem pedig a feleslegesen tárolt teljes felhasználói kérdésekre.

A naprakészség is releváns marad. Egy régi, rég lecserélt szabályzat nem szándékosan mérgezett, de ugyanolyan hatása lehet. A Tudásbázisok naprakészsége és Crawl-QA című cikk a biztonsági ellenőrzéseket a frissítési ütemezés, a felelősség és a törlési útvonalak témakörével egészíti ki.

Csekklista a biztonságos RAG-adatfelvételhez

• Minden forrás rendelkezik stabil ID-val, kanonikus származással, felelős személlyel és megbízhatósági osztállyal?
• A hash, a dokumentumverzió, a parser, a chunking és az embedding-modell együtt kerül naplózásra?
• Az új vagy erősen módosított források az ellenőrzésig az éles keresésen kívül maradnak?
• Az új domainek, a hiányzó aláírások vagy a valószínűtlen tartalomváltozások karantént vonnak maguk után?
• A jóváhagyott indexek verziózott generációkként, visszagördíthető aliasszal kerülnek közzétételre?
• A re-indexelés igazolhatóan eltávolítja a lecserélt chunkokat ahelyett, hogy csak új adatokat fűzne hozzá?
• A Golden Set ellenőrzi a válaszokat, valamint az elvárt és a tiltott forrásokat is?
• Létezik biztonsági tartalék (fallback) azon témákhoz, amelyek forrásait egy incidens során zárolták?
• A szerepkörök el vannak különítve az adatfelvétel, a szakmai jóváhagyás, az incidenskezelés és az újbóli közzététel esetén?
• Minden incidens után dokumentálásra kerül, hogy melyik ellenőrzés vallott kudarcot, és milyen regressziós teszttel egészült ki a rendszer?

Összegzés

A RAG-adatmérgezést nem lehet egyetlen prompt-szabállyal elhárítani. A védelem a tudás ellenőrizhető ellátási láncából adódik: a származás dokumentálása, a módosítások ellenőrzése karanténban, az indexek verziózása, a régi származékok biztonságos eltávolítása és a keresés tesztelése az elvárt forrásokkal. Kezdje a legmagasabb kockázatú dokumentumosztályokkal és egy kis Golden Set-tel. Már ez a kombináció is láthatóvá teszi, hogy melyik forrás hordozza a választ – és lehetővé teszi a célzott visszagördítési útvonalat, mielőtt egy hibás tudásállapot tartósan normálissá válna.

Források

• OWASP GenAI Security Project: LLM04:2025 Data and Model Poisoning
• NIST AI 600-1: Artificial Intelligence Risk Management Framework – Generative Artificial Intelligence Profile
• NIST AI 100-2: Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations