RAG-sletningskoncept for AI-chatbots: Fjern indhold fra indeks, cache og svar

Et prisark er udløbet, en sikkerhedsanvisning er trukket tilbage, eller en kunde kræver sletning af personoplysninger. I kildesystemet er den pågældende fil hurtigt slettet. Alligevel kan en website-chatbot stadig i minutter, timer eller endda længere trække på det gamle indhold: En kopi ligger måske i importområdet, filen blev opdelt i flere tekstafsnit, hvis embeddings står i vektorindekset, og en svarcache har et allerede formuleret udsagn klar. Et robust RAG-sletningskoncept behandler derfor ikke kun kildefilen, men hele afledningskæden.

Målet er ikke at slette alt vilkårligt og med det samme. Der er brug for en kontrolleret proces, der straks tager forældet eller tilbagetrukket indhold ud af den aktive svarstrøm, tager højde for lovmæssige og driftsmæssige opbevaringspligter og efterfølgende dokumenterer, at retrieval og svar ikke længere anvender indholdet. Netop denne dokumentation adskiller en simpel slettehandling fra en pålidelig driftsprocedure.

Hvorfor sletning i et RAG-system er i flere trin

Retrieval-Augmented Generation forbinder en sprogmodel med ekstern viden. Mellem den originale kilde og svaret ligger der flere tekniske tilstande: Crawler eller upload, normaliseret fil, tekstgenkendelse, chunks, metadata, embeddings, vektor- og fuldtekstindeks, forespørgsels-cache, udvalgte søgeresultater og det genererede svar herudfra. Nogle systemer gemmer desuden sessionshistorik, kvalitetssamples eller traces. Hvis kun den første tilstand fjernes, kan efterfølgende kopier fortsat være findbare.

Dertil kommer et tidsproblem. En sletning kan behandles asynkront, mens der parallelt indløber nye forespørgsler. En natlig genindeksering er så ikke nok: Indtil kørsels-tidspunktet vil chatbotten kunne fortsætte med at levere den tilbagetrukne information. Omvendt må en senere import ikke utilsigtet genoprette kilden. Derfor kræver enhver sletning både en hurtig blokering i forespørgselsstien og en fuldstændig oprydning i baggrunden.

Definer sletningsomfanget entydigt på forhånd

Det hele starter med en stabil kildeidentitet. Filnavn eller URL alene er ofte for svage, fordi de kan ændre sig eller forekomme flere gange. Det er hensigtsmæssigt med et internt kilde-ID, version, tenant, sprog, adgangsområde og et hash af det importerede indhold. Hver chunk og hver indeksindgang skal kunne føres tilbage til denne identitet. Først da kan det pålideligt fastslås, hvilke afledninger der hører til en kilde.

Derefter fastlægges det, hvad "slettet" betyder i det konkrete tilfælde. For en forældet produktinformation kan det være nok at deaktivere den fra den aktive videnbase og erstatte den med en ny version. Ved en tilbagekaldelse, en anmodning om databeskyttelse eller et licensudløb kan strengere frister og yderligere lagringssteder være berørt. Backups, sikkerhedslogge og lovpligtig dokumentation har ofte egne regler. Beslutningen bør derfor inddrage dataansvarlige, drift og – ved personhenførbart eller reguleret indhold – også databeskyttelses- henholdsvis juramedarbejdere.

En sikker sletningsproces i syv trin

1. Registrer og verificer anmodningen: Noter kilde-ID, version, årsag, anmodet frist, berørte tenants og den person eller rolle, der har godkendt. Ved følsomme sletninger skal rettighederne kontrolleres, før data ændres.
2. Placer en tombstone: Marker straks kilden som spærret. Retrieval-filtre skal tage højde for denne status, så tilhørende chunks ikke længere havner i nye svar, selvom den fysiske oprydning stadig kører.
3. Løs afhængigheder: Identificer råkopier, parser-resultater, chunks, embeddings, fuldtekstdokumenter, caches, forudgenererede svarbyggeklodser og eventuelle testdatasæt. Kilde-ID fungerer som fælles nøgle.
4. Ryd op i aktive indeks: Slet eller deaktiver alle berørte dataposter i vektor- og nøgleordsindekset. Kontroller tilbagemeldingerne fra den enkelte tjeneste; en accepteret opgave er endnu ikke et bevis på fuldført sletning.
5. Invalider caches: Tøm målrettet retrieval-, query- og svar-caches. Hvor selektiv invalidering ikke er mulig, hjælper versionsnøgler eller et nyt namespace, så gamle indtastninger ikke længere kan nås.
6. Udfør kontrol og dokumentation: Spørg ind til kendte formuleringer, dokumenttitler, sjældne begreber og semantisk lignende varianter. Et direkte opslag via kilde-ID og en stikprøve i chatbotten bør begge forblive uden fund.
7. Afslut sagen: Gem en kort sletningsprotokol med tidspunkt, omfang, systemsvar, testresultat og åbne opbevaringsfrister. Protokollen skal dokumentere forløbet uden at kopiere det slettede indhold unødigt.

Hvorfor tombstonen kommer før den fysiske sletning

Rækkefølgen forhindrer to typiske fejl. For det første kan en crawler ikke altid knytte en slettet kildefil korrekt til en eksisterende indeksindgang. Nogle indeksere forventer et soft-delete-signal, så længe kilden stadig kan genkendes. For det andet kan igangværende jobs skrive data igen mellem kildesletning og indeksoprydning. En central tombstone blokerer for denne genoptagelse. Den bør bevares, selvom de faktiske brugsdata allerede er fjernet – dog kun med de minimalt nødvendige metadata og en klar opbevaringsfrist.

Versioning gør cache-sletning håndterbar

Caches er særligt fejlbehæftede, hvis nøglerne kun består af brugerens spørgsmål. Det er bedre med en nøgle, der desuden indeholder videnbase-version, tenant, sprog og rettighedskontekst. Efter en sletning forøges versionen. Selvom en enkelt cache-indgang teknisk set fortsat eksisterer indtil sit udløb, kan den aktive applikation ikke længere ramme den. Det erstatter ikke den målrettede invalidering i alle tilfælde, men reducerer risikoen for, at gamle svar dukker op igen.

HTTP-caches følger til gengæld egne regler. Standarden RFC 9111 beskriver, hvornår gemte svar er friske, forældede eller skal invalideres. For RAG-applikationer følger heraf: CDN-, API- og applikationscache skal betragtes adskilt. En ny databaseversion alene tømmer ikke en svar-cache, der leveres ude i kanten (edge).

Konkret eksempel: En tilbagetrukket monteringsvejledning

Antag, at en producent trækker version 3 af en monteringsvejledning tilbage, fordi et arbejdstrin er blevet ændret. Version 4 er allerede godkendt. Systemet sætter straks en tombstone for kilde V3 og udgiver V4 under et nyt versions-ID. Retrieveren filtrerer udelukkende godkendte kilder og foretrækker den aktuelle version. Parallelt fjerner en worker samtlige V3-chunks fra vektor- og fuldtekstindeks og invaliderer caches, hvis afhængighedsliste indeholder dette kilde-ID.

Kvalitetssikringen stiller nu ikke kun spørgsmålet "Hvordan monterer jeg komponenten?". Den anvender også en markant formulering fra V3, et omformuleret spørgsmål samt et spørgsmål, der tidligere kun kunne besvares med V3. Forventningen er enten det dokumenterede svar fra V4 eller en klar besked om, at der ikke foreligger godkendt information. En kildeangivelse til V3, et ordret fragment eller et svar uden aktuel kildehenvisning betragtes som en fejl. Hvordan kilder gøres synlige i svar, forklares i artiklen Dokumenter chatbot-svar med kilder.

Test om sletningen rent faktisk virker

En grøn API-status er ikke nok. Kontrollen bør ske på flere niveauer. På lagerniveau søges der efter kilde-ID, chunk-ID'er og kendte hashes. På retrieval-niveau udføres testspørgsmål, og de returnerede kildehenvisninger kontrolleres. På svarniveau kontrolleres det, om det gamle udsagn stadig optræder ordret eller i overført betydning. Endelig er der brug for en genstarts-test: Efter en crawler-kørsel, genopbygning af indekset eller genoprettelse fra backup må kilden ikke vende tilbage.

Gem et lille Golden Set af positive og negative cases for hver kritisk videnklasse. Positive cases beviser, at erstatningskilden findes korrekt; negative cases viser, at spærrede oplysninger ikke længere dukker op. Proceduren supplerer den løbende QA til at holde en AI-chatbot-videnbase opdateret. Ved større indeksændringer hjælper desuden en parallel genopbygning med kontrolleret omstilling, som beskrevet i guiden til skift af en RAG-embedding-model.

Tjekliste til den daglige drift

• Hver kilde har et stabil ID, version, oprindelse, sprog og en ansvarlig ejer.
• Chunks, embeddings, indeksdokumenter og caches kan føres tilbage til dette kilde-ID.
• En tombstone spærrer kilden straks i retrieval og forhindrer en ny import.
• Sletteopgaven kører idempotent: En gentagelse skaber hverken fejl eller nye dataposter.
• Workers rapporterer ikke kun "accepteret", men en fuldført status med fejldetaljer.
• Retrieval- og svar-caches kan invalideres selektivt eller frikobles via versioner.
• Direkte søgning, semantisk søgning, svartest og genstarts-test er dokumenteret.
• Backups og logge har definerede opbevaringsfrister og en proces for senere genoprettelse.
• Sletningsprotokollen indeholder kun nødvendige metadata og ingen unødig kopi af det fjernede indhold.
• Ansvar, eskalering og maksimal behandlingstid er fastlagt og afprøves regelmæssigt.

Bland ikke governance og databeskyttelse sammen

Et teknisk sletningskoncept besvarer, hvordan en kilde sikkert forsvinder fra den aktive RAG-strøm. Om og hvornår den skal slettes, er et andet spørgsmål. Databeskyttelsesforordningen (GDPR) indeholder i artikel 17 en ret til sletning under visse betingelser og ligeledes undtagelser. En generel udtalelse som "enhver anmodning sletter straks enhver backup" ville derfor være lige så risikabel som en ubegrænset lagring uden formål. Det afgørende retsgrundlag og frist skal fastlægges for det enkelte anvendelsestilfælde; den officielle forordningstekst kan findes via EUR-Lex.

Organisatorisk hører processen til i Content Governance: Hvem må trække indhold tilbage? Hvem bekræfter oprydningen? Hvad sker der, hvis en ekstern vektortjeneste ikke er tilgængelig? Artiklen AI-Chatbot Content Governance viser, hvordan ejere, godkendelser og change control arbejder sammen. Ved høje risici anbefales et fire-øjne-princip; ved normale opdateringer kan et automatiseret, fuldt protokolleret workflow være tilstrækkeligt.

Officielle kilder og tekniske referencer

• Microsoft Learn: Registrering af ændrede og slettede blobs i Azure AI Search
• Microsoft Learn: Documents API til Azure AI Search
• Google Cloud: Administrer filer og korpora i Vertex AI RAG Engine
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Databeskyttelsesforordningen

Konklusion: Sletbarhed er en kvalitetsfunktion

En RAG-videnbase er kun pålidelig, hvis indhold ikke kun kan tilføjes, men også trækkes kontrolleret tilbage. Stabile kilde-ID'er, tombstones, afhængighedslister, versionerede caches og genoptagelige tests gør en usikker enkelt handling til en håndterbar proces. Den, der her forbinder faglig godkendelse, teknisk oprydning og dokumenterbar QA, reducerer forældede svar og skaber fundamentet for en chatbot, hvis viden styres bevidst.