RAG-törlési koncepció AI-chatbotokhoz: Tartalmak eltávolítása az indexből, a gyorsítótárból és a válaszokból

Egy árelőírás érvényét vesztette, egy biztonsági utasítást visszavontak, vagy egy ügyfél a személyes adatai törlését kéri. A forrásrendszerben az érintett fájlt gyorsan törlik. Ennek ellenére egy weboldali chatbot még perceken, órákon vagy akár hosszabb ideig is visszanyúlhat a régi tartalomhoz: Lehet, hogy egy másolat az importálási területen maradt, a fájlt több szövegrészletre (chunk) bontották, amelyek embeddingjei a vektorindexben szerepelnek, és egy válasz-gyorsítótár tárolja a már megfogalmazott kijelentést. Egy megbízható RAG-törlési koncepció ezért nemcsak a forrásfájlt, hanem a teljes származtatási láncot kezeli.

A cél nem az, hogy mindent azonnal és válogatás nélkül megsemmisítsünk. Egy ellenőrzött folyamatra van szükség, amely az elavult vagy visszavont tartalmakat haladéktalanul kiveszi az aktív válaszadási útvonalból, figyelembe veszi a törvényi és működési megőrzési kötelezettségeket, majd igazolja, hogy a retrieval és a válaszok már nem használják azt a tartalmat. Pontosan ez az igazolás az, ami elválasztja az egyszerű törlési akciót a megbízható üzemeltetési eljárástól.

Miért többlépcsős a törlés egy RAG-rendszerben?

A Retrieval-Augmented Generation a nyelvi modellt külső tudással kapcsolja össze. Eredeti forrás és válasz között több technikai állapot húzódik meg: crawler vagy feltöltés, normalizált fájl, szövegfelismerés, chunkok, metaadatok, embeddingek, vektor- és teljes szöveges index, lekérdezési gyorsítótár, kiválasztott találatok és az ezekből generált válasz. Egyes rendszerek ezenkívül munkafolyamat-előzményeket, minőségi mintákat vagy trace-eket is tárolnak. Ha csak az első állapotot távolítják el, a lejjebb lévő másolatok továbbra is megtalálhatók maradhatnak.

Ehhez társul még az időprobléma is. A törlés feldolgozása történhet aszinkron módon, miközben ezzel párhuzamosan új lekérdezések érkeznek. Egy éjszakai újraindexelés ilyenkor nem elég: a lefutásig a chatbot továbbra is kiadhatja a visszavont információt. És fordítva, egy későbbi importálás nem állíthatja vissza véletlenül a forrást. Ezért minden törléshez szükség van egy gyors tiltásra a lekérdezési útvonalon, valamint egy teljes tisztításra a háttérben.

A törlési terjedelem egyértelmű előzetes meghatározása

Kezdetben egy stabil forrásazonosítóra van szükség. A fájlnév vagy az URL önmagában gyakran túl gyenge, mivel megváltozhatnak, vagy többször is előfordulhatnak. Érdemes belső forrás-ID-t, verziót, bérlőt (tenant), nyelvet, hozzáférési kört és az importált tartalom hash-ét használni. Minden chunk-nak és minden indexbejegyzésnek visszavezethetőnek kell lennie erre az azonosítóra. Csak így állapítható meg megbízhatóan, hogy mely származtatások tartoznak egy adott forráshoz.

Ezután meg kell határozni, mit jelent a „törölve” a konkrét esetben. Egy elavult termékinformációnál elegendő lehet az aktív tudásbázisból való deaktiválás és egy új verzióra cserélés. Egy visszavonásnál, adatvédelmi kérelomnél vagy licenclejáratnál szigorúbb határidők és további tárolási helyek lehetnek érintettek. A biztonsági mentésekre, biztonsági naplókra és a törvényileg előírt igazolásokra gyakran saját szabályok vonatkoznak. A döntésbe ezért be kell vonni az adatfelelősöket, az üzemeltetést, személyes vagy szabályozott tartalmak esetén pedig az adatvédelmi, illetve jogi osztályt is.

Egy biztonságos törlési folyamat hét lépésben

1. Kérelem rögzítése és ellenőrzése: Jegyezze fel a forrás-ID-t, verziót, okot, a kért határidőt, az érintett bérlőket és a jóváhagyó személyt vagy szerepkört. Érzékeny törléseknél ellenőrizni kell a jogosultságot az adatok módosítása előtt.
2. Tombstone elhelyezése: Azonnal jelölje meg a forrást zároltként. A retrieval-szűrőknek figyelembe kell venniük ezt az állapotot, hogy a hozzá tartozó chunkok ne kerülhessenek be az új válaszokba, még akkor sem, ha a fizikai tisztítás még folyamatban van.
3. Függőségek feloldása: Határozza meg a nyers másolatokat, a parser-eredményeket, chunkokat, embeddingeket, teljes szöveges dokumentumokat, gyorsítótárakat, előre generált válaszelemeket és adott esetben a tesztadatkészleteket. A forrás-ID szolgál közös kulcsként.
4. Aktív indexek tisztítása: Törölje vagy deaktiválja az összes érintett adatrekordot a vektor- és kulcsszó-indexben. Ellenőrizze az adott szolgáltatás visszajelzéseit; egy elfogadott feladat még nem bizonyítja a törlés befejezését.
5. Gyorsítótárak érvénytelenítése: Célzottan ürítse ki a retrieval-, query- és válasz-gyorsítótárakat. Ahol a szelektív érvénytelenítés nem lehetséges, ott a verziókulcsok vagy egy új namespace segíthet, hogy a régi bejegyzések többé ne legyenek elérhetők.
6. Igazolások végrehajtása: Kérdezzen rá ismert megfogalmazásokra, dokumentumcímekre, ritka kifejezésekre és szemantikailag hasonló változatokra. A forrás-ID alapján történő közvetlen lekérdezésnek és a chatbotban végzett mintavételnek egyaránt találat nélkül kell maradnia.
7. Folyamat lezárása: Mentsen el egy tömör törlési jegyzőkönyvet az időponttal, a terjedelemmel, a rendszer válaszaival, a vizsgálat eredményével és a nyitott megőrzési határidőkkel. A jegyzőkönyvnek a folyamatot kell igazolnia, nem pedig szükségtelenül lemásolnia a törölt tartalmat.

Miért előzi meg a tombstone a fizikai törlést?

A sorrend két tipikus hibát akadályoz meg. Először is, a crawler nem mindig tudja tiszta módon hozzárendelni a törölt forrásfájlt egy meglévő indexbejegyzéshez. Néhány indexelő elvár egy soft-delete jelet, amíg a forrás még felismerhető. Másodszor, a futó feladatok a forrás törlése és az index tisztítása között újra adatokat írhatnak be. Egy központi tombstone blokkolja ezt az újrafelvételt. Magát a tombstone-t akkor is meg kell őrizni, ha a tényleges hasznos adatokat már eltávolították – viszont csak a minimálisan szükséges metaadatokkal és egy világos megőrzési határidővel.

A verziózás kezelhetővé teszi a gyorsítótár törlését

A gyorsítótárak különösen hibaérzékenyek, ha a kulcsok csak a felhasználói kérdésből állnak. Jobb megoldás az olyan kulcs, amely ezenkívül tartalmazza a tudásbázis verzióját, a bérlőt, a nyelvet és a jogosultsági kontextust. Törlés után a verziószám emelkedik. Még ha egy egyedi gyorsítótár-bejegyzés technikailag létezik is a lejáratáig, az aktív alkalmazás már nem tudja eltalálni. Ez nem helyettesíti minden esetben a célzott érvénytelenítést, de csökkenti annak kockázatát, hogy a régi válaszok ismét felbukkanjanak.

A HTTP-gyorsítótárakra viszont saját szabályok vonatkoznak. Az RFC 9111 szabvány leírja, mikor friss, elavult vagy érvénytelenítendő egy tárolt válasz. A RAG-alkalmazások esetében ebből az következik: a CDN-, API- és alkalmazás-gyorsítótárat külön kell tekinteni. Egy új adatbázis-verzió önmagában nem üríti ki a szélről (edge) kiszolgált válasz-gyorsítótárat.

Konkrét példa: Egy visszavont szerelési útmutató

Tegyük fel, hogy egy gyártó visszavonja a szerelési útmutató 3-as verzióját, mert egy munkalépés megváltozott. A 4-es verzió már jóvá van hagyva. A rendszer a V3 forráshoz azonnal beállít egy tombstone-t, és a V4-et egy új verzió-ID alatt teszi közzé. A retriever kizárólag a jóváhagyott forrásokat szűri ki, és az aktuális verziót részesíti előnyben. Ezzel párhuzamosan egy worker eltávolítja az összes V3-chunkot a vektor- és teljes szöveges indexből, és érvényteleníti azokat a gyorsítótárakat, amelyek függőségi listája tartalmazza ezt a forrás-ID-t.

A minőségbiztosítás most nemcsak azt a kérdést teszi fel, hogy „Hogyan szereljem össze az alkatrészt?”. Használ egy V3-ból származó jellegzetes megfogalmazást, egy átfogalmazott kérdést, valamint egy olyan kérdést is, amely korábban csak a V3 segítségével volt megválaszolható. A várt eredmény vagy a V4-ből származó alátámasztott válasz, vagy egy egyértelmű jelzés arra vonatkozóan, hogy nem áll rendelkezésre jóváhagyott információ. A V3-ra való forrásmegjelölés, egy szó szerinti töredék vagy egy aktuális találat nélküli válasz hibának minősül. A források válaszokban való megjelenítéséről a Chatbot-válaszok alátámasztása forrásokkal című cikk nyújt tájékoztatást.

Ellenőrzés: Valóban hatásos a törlés?

A zöld API-státusz nem elegendő. Az ellenőrzést több szinten kell elvégezni. Tárolási szinten forrás-ID, chunk-ID-k és ismert hash-ek alapján történik a keresés. Retrieval-szinten tesztkérdéseket futtatnak le, és ellenőrzik a visszakapott találatokat. Válasz-szinten megvizsgálják, hogy a régi kijelentés szó szerint vagy értelemszerűen megjelenik-e még. Végül szükség van egy újraindulási tesztre is: A crawler lefutása, az index újjáépítése vagy a biztonsági mentés visszaállítása után a forrás nem térhet vissza.

Őrizzen meg minden kritikus tudásosztályhoz egy kis Golden Set-et pozitív és negatív esetekből. A pozitív esetek igazolják, hogy a helyettesítő forrást a rendszer helyesen megtalálja; a negatív esetek megmutatják, hogy a zárolt információk többé nem bukkannak fel. Ez az eljárás kiegészíti a folyamatos QA-t a naprakész AI-chatbot tudásbázishoz. Nagyobb indexmódosítások esetén a párhuzamos újjáépítés és az ellenőrzött átváltás is segít, ahogyan az a RAG embedding modell váltása útmutatóban szerepel.

Ellenőrző lista a mindennapi üzemeltetéshez

• Minden forrás rendelkezik stabil ID-val, verzióval, eredettel, nyelvvel és egy felelős tulajdonossal (owner).
• A chunkok, embeddingek, indexdokumentumok és gyorsítótárak visszavezethetők erre a forrás-ID-ra.
• Egy tombstone azonnal zárolja a forrást a retrievalban, és megakadályozza az ismételt importálást.
• A törlési megbízás idempotens módon fut: Az ismétlés nem hoz létre sem hibát, sem új adatrekordokat.
• A workerek nemcsak azt jelzik, hogy „elfogadva”, hanem a befejezett státuszt is a hiba részleteivel.
• A retrieval- és válasz-gyorsítótárak szelektíven érvényteleníthetők, vagy verziókkal szétválaszthatók.
• A közvetlen keresés, a szemantikus keresés, a választeszt és az újraindulási teszt dokumentálva van.
• A biztonsági mentéseknek és naplóknak meghatározott megőrzési határidejük és a későbbi helyreállításokra vonatkozó folyamatuk van.
• A törlési jegyzőkönyv csak a szükséges metaadatokat tartalmazza, és nem tartalmazza az eltávolított tartalom felesleges másolatát.
• A felelősség, az eszkaláció és a maximális feldolgozási idő rögzítve van, és rendszeresen gyakorolják.

Ne keverjük össze a governance-t és az adatvédelmet

Egy technikai törlési koncepció arra ad választ, hogyan tűnik el egy forrás biztonságosan az aktív RAG-útvonalból. Az, hogy mikor és kell-e törölni, már egy másik kérdés. Az Általános Adatvédelmi Rendelet (GDPR) 17. cikke tartalmazza a törléshez való jogot bizonyos feltételek mellett, valamint a kivételeket is. Ezért egy olyan általános kijelentés, mint a „minden kérelem azonnal töröl minden biztonsági mentést”, éppolyan kockázatos lenne, mint a cél nélküli, határozatlan idejű tárolás. Az irányadó jogalapot és a határidőt az adott felhasználási esetre kell meghatározni; a hivatalos rendeletszöveg az EUR-Lex oldalon érhető el.

Szervezési szempontból a folyamat a Content Governance-hez tartozik: Ki vonhat vissza tartalmakat? Ki erősíti meg a tisztítást? Mi történik, ha egy külső vektorszolgáltatás nem érhető el? Az AI Chatbot Content Governance című cikk megmutatja, hogyan működik együtt a tulajdonos, a jóváhagyások és a Change Control. Magas kockázatok esetén négy szem elve javasolt; a normál frissítéseknél elegendő lehet egy automatizált, teljesen naplózott munkafolyamat is.

Hivatalos források és technikai hivatkozások

• Microsoft Learn: Módosított és törölt blobok észlelése az Azure AI Search-ben
• Microsoft Learn: Documents API az Azure AI Search-höz
• Google Cloud: Fájlok és korpuszok kezelése a Vertex AI RAG Engine-ben
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Általános adatvédelmi rendelet

Összegzés: A törölhetőség minőségi funkció

Egy RAG-tudásbázis csak akkor megbízható, ha a tartalmakat nemcsak felvenni, hanem ellenőrzött módon visszavonni is lehet. A stabil forrás-ID-k, tombstone-ok, függőségi listák, verziózott gyorsítótárak és megismételhető tesztek a bizonytalan egyedi akcióból kezelhető folyamatot csinálnak. Aki a szakmai jóváhagyást, a technikai tisztítást és az igazolható QA-t ötvözi, csökkenti az elavult válaszokat, és megteremti az alapot egy olyan chatbot számára, amelynek tudása tudatosan irányítható.