RAG-Wissen löschen: So prüfen Sie Quelle, Index, Cache und Antworten
Ein Dokument ist in einem RAG-System erst dann funktional gelöscht, wenn es keinen zulässigen Antwortpfad mehr beeinflussen kann. Eine verschwundene Quelldatei oder eine erfolgreiche Delete-Anfrage reichen dafür nicht aus. Prüfen Sie sämtliche Kopien und Ableitungen, Suchpfade, Caches, Gesprächskontexte und Möglichkeiten zur erneuten Aufnahme.
Zwei Meilensteine müssen getrennt nachgewiesen werden: funktionaler Ausschluss aus aktiven Antwortpfaden und physische Entfernung aus den betroffenen Speichern.
Warum das Löschen der Quelldatei nicht genügt
Ein RAG-System erzeugt aus einem Dokument weitere Daten: temporäre und normalisierte Kopien, OCR- oder Parser-Ergebnisse, Chunks, Embeddings und Indexeinträge. Die Retrieval-Pipeline kann Trefferlisten zwischenspeichern, neu bewerten und gemeinsam mit früheren Antworten in einen Modellkontext übernehmen.
Ein Chunk ist ein aus dem Dokument extrahierter Textabschnitt. Ein Embedding ist dessen numerische Repräsentation für Ähnlichkeitssuche. Beide können nach dem Löschen der ursprünglichen Datei weiter vorhanden sein.
Das Löschinventar muss deshalb folgende Ebenen abdecken:
- Quelle, temporäre Dateien, normalisierte Dokumentkopien sowie OCR- und Parser-Ergebnisse;
- Chunk-Manifest, Dense-Vector-Index und getrennten Sparse-, Keyword- oder Volltextindex;
- Hybrid Search, Reranker sowie Retrieval- und Reranker-Caches;
- Anwendungs-Response-Cache, bestehende Chats, Zusammenfassungen und langfristiges Memory;
- Ingestion Queues, Retry-Jobs, Snapshots, Backups und externe Modellanbieter.
Das OWASP RAG Security Cheat Sheet beschreibt die erforderliche Weitergabe von Löschungen an abgeleitete Indizes und Antwort-Caches. Die allgemeine Anbindung und Synchronisierung von Dokumentquellen behandelt RAG-Datenquellen anbinden; hier geht es ausschließlich um die technische Löschabnahme.
Funktionaler Ausschluss und physische Löschung sind verschiedene Meilensteine
Meilenstein 1: Funktionaler Ausschluss. Ein gelöschtes Dokument darf in keinem zulässigen Retrieval-, Cache-, Memory- oder Antwortpfad mehr als Evidenz verfügbar sein. Bereits erzeugte Antworten dürfen nicht ungeprüft aus einem alten Anwendungscache erneut ausgeliefert werden. Eine bestehende Chat-Sitzung darf den früheren Dokumentauszug nicht als weiterhin gültige Quelle verwenden.
Meilenstein 2: Physische Entfernung. Kopien und Ableitungen müssen aus den betroffenen Speichern entfernt werden oder mit dokumentierten offenen Bereinigungs- und Aufbewahrungsfristen erfasst sein. Hierzu zählen auch Backups und Dienstleister-Speicher.
Herstellerverhalten ist nicht einheitlich: Azure AI Search dokumentiert eine verzögerte physische Speicherbereinigung; Weaviate beschreibt eine asynchrone HNSW-Bereinigung. Diese Beispiele sind keine Garantie für die vollständige Löschung einer gesamten RAG-Anwendung.
Empfehlung: Geben Sie den funktionalen Ausschluss nur nach bestandener Prüfung der aktiven Antwortpfade frei. Führen Sie den Nachweis physischer Entfernung separat.
Ohne Dokumentidentität und Lineage bleibt die Löschung unvollständig
Lineage bezeichnet die nachvollziehbare Verbindung von der Quelle zu sämtlichen abgeleiteten Artefakten. Ein belastbarer Löschauftrag braucht mindestens:
| Feld | Zweck |
|---|---|
tenant_id oder workspace_id | Mandanten- und Arbeitsbereichsgrenze |
source_id | Herkunftssystem beziehungsweise Quellobjekt |
document_id | Stabile Dokumentidentität |
version_id | Eindeutige Dokumentfassung |
chunk_ids | Alle abgeleiteten Textabschnitte |
index_generation | Betroffene Suchindex-Generation |
cache_dependencies | Betroffene Retrieval- und Antwort-Caches |
delete_job_id | Korrelierbarer Löschauftrag und Prüfbeleg |
Die Kombination muss mandantensicher und über Re-Indexierungen hinweg nachvollziehbar sein. Ein erneuter Indexaufbau kann andere Chunk-IDs erzeugen. Deshalb genügt es nicht, nur eine alte Chunk-Liste zu löschen: Die Dokumentidentität muss auch neue Ableitungen erfassen.
Wiedereintrittssperre: Wie verhindern Sie einen Re-Import?
Ein Retry-Job, ein Batch-Neuaufbau, eine Migration oder ein Restore kann bereits gelöschte Inhalte erneut aktivieren.
Eine zentrale Delete Registry oder ein Tombstone (dauerhafter Löschvermerk innerhalb seines definierten Schutzzeitraums) sperrt die betroffene Dokumentversion. Ingestion und Retrieval müssen diese Sperre prüfen. Der Schutz muss greifen, bevor ein parallel laufender Job alte Daten erneut veröffentlicht.
Ein empfehlenswerter Ablauf:
- Löschauftrag und betroffene Versionen registrieren; Wiedereintritt sofort sperren.
- Quelldaten und alle bekannten Ableitungen löschen oder wirksam ausschließen.
- Dense, Sparse und Hybrid Search sowie abhängige Caches und Kontexte bereinigen.
- Wartende Jobs gegen die aktuelle Löschregistrierung abgleichen.
- Bei Index-Neuaufbau, Migration oder Restore das neueste Löschjournal einspielen, bevor Suchendpunkte freigegeben werden.
Die Löschregistrierung muss unabhängig vom zurückspielbaren Snapshot fortbestehen oder aus einem neueren, verlässlichen Journal rekonstruierbar sein. Läuft ein Tombstone aus, während ältere Imports weiterhin möglich sind, besteht die Gefahr einer erneuten Aufnahme.
Prüftabelle der vollständigen Löschkette
| Ebene | Löschaktion | Technischer Nachweis | Erwartetes Ergebnis |
|---|---|---|---|
| Quelldokument | Entfernen oder aus RAG ausschließen | Quell-API-Lookup | Keine aktive RAG-Quelle |
| Temporäre Dateien, OCR, Parser | Kopien und Extrakte bereinigen | Datei-/Objektinventar | Keine aktiv nutzbare Kopie |
| Chunk-Manifest | Chunks entfernen oder sperren | ID- und Dokument-Lookup | Null aktive Chunks |
| Dense Vector Index | Vektoreinträge bereinigen | Punktabfrage und semantische Suche | Keine zulässigen Treffer |
| Sparse-/Keyword-Index | Lexikalische Einträge entfernen | Exakte Volltextsuche | Keine zulässigen Treffer |
| Hybrid Search und Reranker | Alle Kandidatenpfade kontrollieren | Einzel- und kombinierte Suchen | Keine ausgeschlossene Evidenz |
| Retrieval-/Response-Cache | Abhängige Einträge invalidieren | Alter Cache-Key und neuer Request | Keine alte Antwort |
| Chat und Memory | Frühere Quellkontexte sperren oder bereinigen | Bestehende Sitzung und Memory-Lookup | Keine neue Verwendung |
| Ingestion Queues | Stale Jobs blockieren | Kontrollierter Replay | Keine erneute Indexierung |
| Snapshots und Backups | Restore absichern, Fristen dokumentieren | Isolierter Restore-Test | Keine Reaktivierung |
| Externe Anbieter | Speicher- und Retention-Regeln prüfen | Konfiguration, Anbieter-Nachweis | Offene Fristen dokumentiert |
Nicht vorhandene Komponenten dürfen als nicht anwendbar gekennzeichnet werden. Fehlende Prüfnachweise dürfen nicht als bestandene Tests gelten.
Acht konkrete Abnahmetests
Test 1: Bekannte IDs nachschlagen
Fragen Sie document_id, version_id und alle chunk_ids direkt ab. Bestanden: Keine Referenz ist in einem produktiv zulässigen Antwortpfad mehr abrufbar; physisch noch vorhandene, gesperrte Einträge werden separat dokumentiert. Achtung: Azure AI Search beschreibt idempotente Löschoperationen, die auch für bereits fehlende Dokument-IDs erfolgreich sein können. Microsoft-Dokumentation.
Test 2: Exakten Marker suchen
Suchen Sie nach einem eindeutigen, vorab im Testdokument platzierten Marker. Bestanden: Null Treffer in produktiven Keyword-, Volltext- oder Metadatenzugängen.
Test 3: Semantische Frage stellen
Fragen Sie nach einer ausschließlich im Testdokument enthaltenen Aussage, ohne Marker oder Titel zu verwenden. Inspizieren Sie Treffer, Reranker, Modellkontext und Antwort. Bestanden: Die gelöschte Quelle wird nirgends als zulässige Evidenz verwendet. Eine unabhängig belegbare Antwort aus anderen gültigen Quellen bleibt möglich.
Test 4: Dense, Sparse und Hybrid Search trennen
Testen Sie Vektorsuche, lexikalische Suche und kombinierten Retrieval-Pfad jeweils separat. Bestanden: Jeder Pfad liefert null zulässige Treffer aus dem gelöschten Dokument; eine leere Hybrid-Suche allein genügt nicht.
Test 5: Alten Response-Cache-Key wiederverwenden
Erzeugen Sie vor der Löschung eine gecachte Antwort. Rufen Sie nach der Löschung denselben Key und die normale Anwendung erneut auf. Bestanden: Der alte Inhalt wird nicht mehr als gültige Antwort ausgeliefert.
Wichtig: Ein anwendungseigener Response-Cache ist nicht der Provider-Prompt-Cache. OpenAI Prompt Caching dokumentiert providerinterne Cache-Repräsentationen und Retention-Einstellungen. Die Invalidierung des Anwendungscaches ist kein Beleg für die physische Löschung des Provider-Caches.
Test 6: Bestehenden Gesprächsverlauf fortsetzen
Stellen Sie vor der Löschung eine Frage, die das Dokument nutzt, und danach eine Anschlussfrage im selben Chat. Bestanden: Vorhandene Antworten, Zusammenfassungen und Memory-Inhalte werden nicht als aktuelle Ersatzquelle verwendet. Ob historische Nachrichten selbst gelöscht werden müssen, ist ein gesonderter Vorgang.
Test 7: Wartenden Ingestion-Job wiederholen
Halten Sie einen Importjob mit dem Dokument zurück und starten Sie ihn nach der Löschung erneut. Bestanden: Die Wiedereintrittssperre blockiert das Dokument vor erneuter Indexierung. Ein zufälliger technischer Jobfehler reicht nicht als Beleg.
Test 8: Snapshot wiederherstellen
Spielen Sie in einer isolierten Umgebung einen Snapshot ein, der das Dokument noch enthält. Gleichen Sie vor Freigabe des Retrieval-Endpunkts das neuere Löschjournal ab. Wiederholen Sie ID-, Marker- und semantische Suche. Bestanden: Das Dokument wird nicht reaktiviert.
Fiktives Prüfbeispiel: policy-2026-017
Ausdrücklich fiktiv: Dieses Beispiel enthält erfundene Daten und erwartete Ergebnisse. Es ist kein Kundenfall und kein gemessener Benchmark.
| Eigenschaft | Testwert |
|---|---|
document_id | policy-2026-017 |
version_id | v3 |
tenant_id | tenant-demo-at |
| Eindeutiger Marker | RAG-DEL-7Q4M |
| Abgeleitete Einheiten | 8 Chunks, policy-2026-017-v3-c01 bis c08 |
| Indexe | Vector Index und Keyword Index |
| Fiktive Testaussage | „Die Kontrollfrist für RAG-DEL-7Q4M beträgt 17 Tage.“ |
| Löschauftrag | delete-policy-2026-017-001 |
Vorher: Testvoraussetzung. Die Dokument-ID ist abrufbar, acht Chunks sind vorhanden, die Markersuche liefert einen Treffer, die semantische Frage nach der Kontrollfrist findet das Dokument und eine Antwort wurde im Response-Cache hinterlegt.
Ablauf. Die Version wird in der Delete Registry gesperrt. Danach werden Quelldatei und Ableitungen, acht Chunks, Vector- und Keyword-Einträge sowie Cache-Abhängigkeiten bereinigt. Bestehende Chats dürfen die alte Aussage nicht weiter als gültige Evidenz benutzen.
Nachher: geforderter Sollzustand.
| Prüfung | Erwartetes Ergebnis |
|---|---|
| Dokument-ID | 0 aktive Datensätze |
| Chunk-IDs | 0 aktive Chunks |
| Exakter Marker | 0 Treffer |
| Dense / Keyword / Hybrid | Jeweils 0 Treffer aus dem Dokument |
| Alter Response-Cache-Key | Keine erneute Auslieferung |
| Bestehender Chat | Keine neue Antwort gestützt auf die gelöschte Richtlinie |
| Retry / Restore | Keine Reaktivierung |
Die Frage „Wie lang ist die Kontrollfrist?“ darf nicht erneut mit „17 Tage“ aus diesem Dokument beantwortet werden. Ohne andere gültige Quelle muss das System die fehlende Evidenz kenntlich machen. Die Tabelle beschreibt nur Sollwerte; bestanden ist die Löschung erst nach tatsächlicher Durchführung und protokollierten Ergebnissen.
Typische Fehlerbilder
HTTP 200 ohne Dokument: Der API-Status wird irrtümlich als Existenz- oder Löschbeweis verstanden. Prüfen Sie den resultierenden Zustand.
Asynchroner Delete-Job: Bei Qdrant kann eine Operation zunächst nur bestätigt sein; die Delete Points API unterstützt wait. Selbst eine abgeschlossene Datenbankoperation beweist noch keine Bereinigung aller Anwendungspfade.
Vector Index gelöscht, Keyword Index vergessen: Dense Search ist sauber, lexikalische Suche findet die Aussage weiter.
Alter Response Cache: Eine frühere Antwort wird ohne erneutes Retrieval ausgeliefert.
Chat als Ersatzquelle: Der alte Dokumentauszug überlebt in einer Unterhaltung oder Zusammenfassung.
Retry nach Löschung: Ein wartender Job importiert die gesperrte Dokumentversion erneut.
Altes Backup: Ein Restore reaktiviert veraltete Indexdaten vor dem Abgleich mit dem Löschjournal.
Physische Entfernung mit funktionalem Ausschluss verwechselt: Das Dokument ist nicht mehr abrufbar, kann aber weiterhin in Backup- oder Speicherstrukturen liegen.
Betriebskennzahlen für die Löschfunktion
| Kennzahl | Zweck |
|---|---|
| Offene Löschaufträge | Rückstand sichtbar machen |
| Fehlgeschlagene Löschaufträge | Fehlerhafte Komponenten erkennen |
| Zeit bis zum funktionalen Ausschluss | Ende-zu-Ende-Latenz der Löschabnahme |
| Verbliebene Treffer | Treffer aus gesperrten Quellen pro Suchpfad |
| Fehlgeschlagene Cache-Invalidierungen | Veraltete Antwortpfade erkennen |
| Blockierte Wiedereintritte | Wirksamkeit der Sperre dokumentieren |
| Fristüberschreitungen | Technische oder organisatorische Zeitgrenzen überwachen |
Messen Sie getrennt den Eingang der Löschanforderung, ihre Freigabe und den nachgewiesenen funktionalen Ausschluss. Protokolle sollten Job-ID, Mandant, Indexgeneration, Prüfergebnis und Zeitstempel enthalten, nicht unnötigerweise vertrauliche Dokumentvolltexte.
Wann ist die Löschung technisch bestanden?
Für den funktionalen Ausschluss gelten diese Abnahmekriterien:
- Dokumentversion und alle bekannten Ableitungen sind eindeutig inventarisiert.
- Die Wiedereintrittssperre ist wirksam.
- Alle acht Tests sind bestanden oder begründet nicht anwendbar.
- Gelöschte Inhalte erreichen weder zulässiges Retrieval noch Modellkontext, Cache-Antwort oder neue Zitation.
- Chat- und Memory-Pfade wurden überprüft.
- Retry, Rebuild, Migration und Restore reaktivieren nichts.
- Testzeitpunkt, Konfiguration, Indexgeneration und Ergebnisse liegen nachvollziehbar vor.
Für physische Entfernung sind Speicherorte, Restkopien, Backup- und Anbieterfristen sowie verfügbare Löschbelege getrennt festzuhalten.
Artikel 17 der DSGVO enthält Voraussetzungen und Ausnahmen für die rechtliche Löschung. Auch die DSK-Orientierungshilfe zu RAG (Oktober 2025) behandelt Betroffenenrechte. Eine technische Abnahme ersetzt keine rechtliche Einzelfallprüfung.
Ohne Nachweis darf nicht behauptet werden: „Das Dokument ist vollständig aus allen Systemen gelöscht.“
Belastbarer ist: „Das Dokument ist seit dem protokollierten Prüfzeitpunkt aus allen geprüften produktiven Antwortpfaden ausgeschlossen. Ausstehende Speicher- und Backup-Bereinigungen sind mit Fristen dokumentiert.“
Fazit: Löschung ist ein Abnahmeprozess
Eine erfolgreiche Delete-Anfrage ist nur ein Schritt. Erst stabile Identitäten, überprüfbare Lineage, konsequente Cache-Invalidierung, eine Wiedereintrittssperre und reproduzierbare Negativtests schaffen einen belastbaren Nachweis.
Die allgemeine Methodik für reproduzierbare Qualitätsprüfungen beschreibt RAG-Evaluation und Golden Dataset. Die Löschung benötigt darüber hinaus eigene Freigabekriterien.
Wenn ein bestehender RAG-Pilot Dokumente einliest, Delete Propagation, Cache-Invalidierung und Wiedereintritt aber noch nicht reproduzierbar testet, kann dieser Pfad als begrenzter Teil einer AI-Production-Readiness-Prüfung untersucht werden. Das Ergebnis ist ein Prüfprotokoll mit Fehlerursachen, offenen Speicherrisiken und klaren Freigabekriterien.