RAG-verwijderingsconcept voor AI-chatbots: Inhoud uit index, cache en antwoorden verwijderen

Een prijslijst is verlopen, een veiligheidsinstructie is ingetrokken of een klant eist de verwijdering van persoonsgegevens. In het bronsysteem is het betreffende bestand snel verwijderd. Toch kan een website-chatbot nog minuten, uren of zelfs langer teruggrijpen op de oude inhoud: een kopie bevindt zich misschien nog in het importgebied, het bestand is opgedeeld in meerdere tekstfragmenten, de embeddings daarvan staan in de vectorindex en een antwoordcache houdt een reeds geformuleerde uitspraak gereed. Een betrouwbaar RAG-verwijderingsconcept behandelt daarom niet alleen het bronbestand, maar de gehele afleidingsketen.

Het doel is daarbij niet om lukraak alles direct te vernietigen. Gevraagd is een gecontroleerd proces dat verouderde of ingetrokken inhoud onverwijld uit het actieve antwoordpad haalt, rekening houdt met wettelijke en operationele bewaarplichten en vervolgens aantoont dat retrieval en antwoorden de inhoud niet meer gebruiken. Precies deze bewijsvoering scheidt een blootvoets verwijderingsactie van een betrouwbare bedrijfsprocedure.

Waarom verwijderen in een RAG-systeem meertraps is

Retrieval-Augmented Generation verbindt een taalmodel met externe kennis. Tussen de originele bron en het antwoord liggen meerdere technische toestanden: crawler of upload, genormaliseerd bestand, tekstherkenning, chunks, metadata, embeddings, vector- en full-text index, query-cache, geselecteerde resultaten en het daaruit gegenereerde antwoord. Sommige systemen slaan bovendien sessieverlopen, kwaliteitssamples of traces op. Als alleen de eerste toestand wordt verwijderd, kunnen nageschakelde kopieën vindbaar blijven.

Daarbij komt een tijdprobleem. Een verwijdering kan asynchroon worden verwerkt terwijl er parallel nieuwe vragen binnenkomen. Een nachtelijke herindexering is dan niet voldoende: tot die run zou de chatbot de ingetrokken informatie kunnen blijven tonen. Omgekeerd mag een latere import de bron niet per ongeluk herstellen. Daarom heeft elke verwijdering zowel een snelle blokkade in het aanvraagpad als een volledige opschoning op de achtergrond nodig.

De omvang van de verwijdering vooraf eenduidig definiëren

Aan het begin staat een stabiele bronidentiteit. Een bestandsnaam of URL alleen is vaak te zwak, omdat deze kan wijzigen of meerdere keren kan voorkomen. Zinvol zijn een interne bron-ID, versie, tenant, taal, toegangsbereik en een hash van de geïmporteerde inhoud. Elke chunk en elke indexvermelding moet herleidbaar zijn tot deze identiteit. Pas dan kan betrouwbaar worden vastgesteld welke afgeleide gegevens bij een bron horen.

Daarna wordt vastgelegd wat "verwijderd" in het concrete geval betekent. Voor verouderde productinformatie kan het volstaan om deze te deactiveren in de actieve kennisbank en te vervangen door een nieuwe versie. Bij een herroeping, een privacyverzoek of het einde van een licentie kunnen strengere termijnen en aanvullende opslaglocaties betrokken zijn. Back-ups, beveiligingslogs en wettelijk vereiste bewijzen hebben vaak eigen regels. De beslissing moet daarom verantwoordelijken voor data, beheer en bij persoonsgegevens of gereguleerde inhoud ook privacy- of juridische experts betrekken.

Een veilig verwijderingsproces in zeven stappen

1. Aanvraag registreren en verifiëren: Noteer bron-ID, versie, aanleiding, gevraagde termijn, betrokken tenants en de persoon of rol die heeft goedgekeurd. Bij gevoelige verwijderingen moet de autorisatie worden gecontroleerd voordat gegevens worden gewijzigd.
2. Tombstone instellen: Markeer de bron direct als geblokkeerd. Retrieval-filters moeten deze status meenemen, zodat bijbehorende chunks niet meer in nieuwe antwoorden terechtkomen, zelfs als de fysieke opschoning nog loopt.
3. Afhankelijkheden oplossen: Stel ruwe kopieën, parser-resultaten, chunks, embeddings, full-text documenten, caches, vooraf gegenereerde antwoordbouwstenen en eventuele testdatasets vast. De bron-ID dient als gemeenschappelijke sleutel.
4. Actieve indexen opschonen: Verwijder of deactiveer alle betrokken records in de vector- en keyword-index. Controleer de terugkoppeling van de betreffende dienst; een geaccepteerde opdracht is nog geen bewijs voor een voltooide verwijdering.
5. Caches invalideren: Leeg gerichte retrieval-, query- en antwoordcaches. Waar selectieve invalidatie niet mogelijk is, helpen versiesleutels of een nieuwe namespace, zodat oude items niet meer bereikbaar zijn.
6. Controles en bewijs uitvoeren: Voer zoekopdrachten uit op bekende formuleringen, documenttitels, zeldzame begrippen en semantisch vergelijkbare varianten. Een directe opvraging via bron-ID en een steekproef in de chatbot mogen beide geen resultaten opleveren.
7. Proces afronden: Sla een beknopt verwijderingsprotocol op met tijdstip, omvang, systeemantwoorden, testresultaat en openstaande bewaartermijnen. Het protocol moet de handeling bewijzen, maar de verwijderde inhoud niet onnodig kopiëren.

Waarom de tombstone vóór de fysieke verwijdering komt

Deze volgorde voorkomt twee typische fouten. Ten eerste kan een crawler een verwijderd bronbestand niet altijd zuiver koppelen aan een bestaande indexvermelding. Sommige indexeerders verwachten een soft-delete-signaal zolang de bron nog herkenbaar is. Ten tweede kunnen lopende jobs tussen bronverwijdering en indexopschoning opnieuw gegevens schrijven. Een centrale tombstone blokkeert deze heropname. Deze moet zelfs behouden blijven als de eigenlijke gebruiksgegevens al zijn verwijderd – echter alleen met de minimaal noodzakelijke metadata en een duidelijke bewaartermijn.

Versionering maakt cacheverwijdering beheersbaar

Caches zijn bijzonder foutgevoelig als sleutels alleen uit de gebruikersvraag bestaan. Beter is een sleutel die aanvullend de versie van de kennisbank, tenant, taal en autorisatiecontext bevat. Na een verwijdering wordt de versie opgehoogd. Zelfs als een individueel cache-item technisch nog bestaat tot de vervaldatum, kan de actieve toepassing er niet meer op matchen. Dit vervangt gerichte invalidatie niet in alle gevallen, maar vermindert het risico dat oude antwoorden weer opduiken.

HTTP-caches volgen op hun beurt eigen regels. De standaard RFC 9111 beschrijft wanneer opgeslagen antwoorden vers, verouderd of te invalideren zijn. Voor RAG-toepassingen volgt hieruit: CDN-, API- en applicatiecache moeten afzonderlijk worden bekeken. Een nieuwe databaseversie alleen leegt geen antwoordcache die aan de edge wordt geserveerd.

Concreet voorbeeld: Een ingetrokken montagehandleiding

Stel dat een fabrikant versie 3 van een montagehandleiding intrekt omdat een werkstap is gewijzigd. Versie 4 is al vrijgegeven. Het systeem plaatst voor bron V3 direct een tombstone en publiceert V4 onder een nieuwe versie-ID. De retriever filtert uitsluitend vrijgegeven bronnen en geeft de voorkeur aan de actuele versie. Parallel verwijdert een worker alle V3-chunks uit de vector- en full-text index en invalideert caches waarvan de afhankelijkheidslijst deze bron-ID bevat.

Kwaliteitsborging stelt nu niet alleen de vraag "Hoe monteer ik het onderdeel?". Ze gebruikt ook een markante formulierung uit V3, een geherformuleerde vraag en een vraag die voorheen alleen met V3 kon worden beantwoord. Verwacht wordt ofwel het onderbouwde antwoord uit V4, ofwel een duidelijke melding dat er geen vrijgegeven informatie beschikbaar is. Een bronvermelding naar V3, een letterlijk fragment of een antwoord zonder actueel resultaat geldt als een fout. Hoe bronnen in antwoorden zichtbaar worden gemaakt, legt het artikel Chatbot-Antworten mit Quellen belegen uit.

Controleren of de verwijdering daadwerkelijk werkt

Een groene API-status is niet voldoende. De controle moet op meerdere niveaus plaatsvinden. Op opslagniveau wordt gezocht naar bron-ID, chunk-ID's en bekende hashes. Op retrieval-niveau worden testvragen uitgevoerd en de geretourneerde resultaten gecontroleerd. Op antwoordniveau wordt gecontroleerd of de oude uitspraak nog letterlijk of inhoudelijk verschijnt. Ten slotte is er een heropstarttest nodig: na een crawler-run, index-rebuild of het terugzetten van een back-up mag de bron niet terugkeren.

Bewaar voor elke kritieke kenniscategorie een kleine 'Golden Set' bestaande uit positieve en negatieve gevallen. Positieve gevallen bewijzen dat de vervangende bron correct wordt gevonden; negatieve gevallen tonen aan dat geblokkeerde informatie niet meer opduikt. Deze procedure is een aanvulling op de lopende QA für eine aktuelle KI-Chatbot-Wissensbasis. Bij grotere indexwijzigingen helpt bovendien een parallelle heropbouw met gecontroleerde omschakeling, zoals beschreven in de gids over het Wechsel eines RAG-Embedding-Modells.

Checklist voor de dagelijkse praktijk

• Elke bron heeft een stabiele ID, versie, herkomst, taal en een verantwoordelijke eigenaar.
• Chunks, embeddings, indexdocumenten en caches zijn herleidbaar tot deze bron-ID.
• Een tombstone blokkeert de bron direct in de retrieval en voorkomt hernieuwde import.
• De verwijderingsopdracht werkt idempotent: herhaling veroorzaakt geen fouten of nieuwe records.
• Workers melden niet alleen "geaccepteerd", mear een afgeronde status met foutdetails.
• Retrieval- en antwoordcaches kunnen selectief worden geïnvalideerd of via versies worden ontkoppeld.
• Direct zoeken, semantisch zoeken, antwoordtest en heropstarttest zijn gedocumenteerd.
• Back-ups en logs hebben gedefinieerde bewaartermijnen en een proces voor latere herstelacties.
• Het verwijderingsprotocol bevat alleen noodzakelijke metadata en geen onnodige kopie van de verwijderde inhoud.
• Verantwoordelijkheid, escalatie en maximale verwerkingstijd zijn vastgelegd en worden regelmatig geoefend.

Governance en privacy niet door elkaar halen

Een technisch verwijderingsconcept beantwoordt hoe een bron veilig uit het actieve RAG-traject verdwijnt. Of en wanneer deze moet worden verwijderd, is een andere vraag. De Algemene Verordening Gegevensbescherming (AVG) bevat in artikel 17 het recht op gegevenswissing onder bepaalde voorwaarden, evenals uitzonderingen. Een algemene bewering zoals "elke aanvraag verwijdert direct elke back-up" zou daarom net zo risicovol zijn als een onbeperkte opslag zonder doel. De doorslaggevende rechtsgrond en termijn moeten voor de specifieke toepassing worden vastgelegd; de officiële verordeningstekst is raadpleegbaar via EUR-Lex.

Organisatorisch hoort het proces thuis in Content Governance: wie mag inhoud intrekken? Wie bevestigt de opschoning? Wat gebeurt er als een externe vectordienst niet bereikbaar is? Het artikel KI-Chatbot Content Governance toont hoe eigenaren, goedkeuringen en change control samenwerken. Voor hoge risico's wordt een vier-ogen-principe aanbevolen; voor normale updates kan een geautomatiseerde, volledig geprotocolleerde workflow volstaan.

Officiële bronnen en technische referenties

• Microsoft Learn: Erkennung geänderter und gelöschter Blobs in Azure AI Search
• Microsoft Learn: Documents API für Azure AI Search
• Google Cloud: Dateien und Korpora in Vertex AI RAG Engine verwalten
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Datenschutz-Grundverordnung

Conclusie: Verwijderbaarheid is een kwaliteitsfunctie

Een RAG-kennisbank is alleen betrouwbaar als inhoud niet alleen kan worden opgenomen, maar ook gecontroleerd kan worden ingetrokken. Stabiele bron-ID's, tombstones, afhankelijkheidslijsten, geversioneerde caches en herhaalbare tests maken van een onzekere losse actie een beheersbaar proces. Wie daarbij inhoudelijke goedkeuring, technische opschoning en aantoonbare QA verbindt, vermindert verouderde antwoorden en legt de basis voor een chatbot waarvan de kennis bewust kan worden gestuurd.