RAG aktuell halten: Gelöschte Dokumente sicher entfernen

Du ersetzt eine Richtlinien-PDF. Im neuen Dokument stehen sieben Tage. Der Agent antwortet weiterhin mit dreißig und nennt sogar den richtigen Dokumenttitel als Quelle.

Das kann passieren, wenn der Titel gleich bleibt, aber ein alter Textabschnitt, eine gespeicherte Antwort oder das Gespräch noch die vorige Regel enthält. Eine ordentlich aussehende Quellenangabe sagt noch nichts über die verwendete Version aus.

Diesen Fall würde ich vor dem Einsatz eines RAG-Agenten für interne IT- oder Unternehmensrichtlinien ausdrücklich testen. Das Beispiel verfolgt eine Quelle durch Azure AI Search, Antwort-Cache und Agent-Memory. Der lokale Prüfcode ist getestet; die Azure-Schritte beschreiben den dokumentierten Integrationsweg, keinen durchgeführten Löschtest im Tenant. Quellenstand ist der 20. Oktober 2026.

Die Quelle über die PDF hinaus verfolgen

Retrieval-Augmented Generation, kurz RAG, bringt gefundene Informationen in den Modellkontext. Die ursprüngliche Datei zu aktualisieren, ist nur ein Teil ihres Lebenszyklus.

Für einen Richtlinien-Assistenten würde ich diese Stellen verfolgen:

Stelle	Was kann veraltet bleiben?	Prüfung
Quellenablage	Abgelöste oder gelöschte Fassung	Aktuelle Revision und Freigabestatus
Suchindex	Alte Chunks oder fehlende Rechteänderungen	Tatsächliche Dokument- und Chunk-Schlüssel abfragen
Antwort-Cache	Früher gültige Antwort	Version und aktuellen Zugriff vor Wiederverwendung prüfen
Gespräch oder Memory	Bereits übergebene Aussagen	Nicht als aktuellen Richtliniennachweis behandeln
Gespeicherter Bericht	Alte Entscheidung nach alter Regel	Historischen Stand sichtbar halten

Die Reddit-Diskussion über wachsendes Agent-Memory fragt nach Qualität bei immer mehr Historie. Für Unternehmenswissen würde ich ergänzen: Kann das System aufhören, eine inzwischen ungültige Aussage zu verwenden?

Verwende stabile Quellenkennungen und explizite Revisionen. Bei einem aufgeteilten Dokument gehört die Kennung der Ursprungsquelle an jeden Chunk. Ohne diese Zuordnung wird die Entfernung eines Dokuments schnell zur Suche nach verstreuten Textteilen.

Änderung und Löschung getrennt testen

Azure-Storage-Indexer erkennen Änderungen anhand von Zeitstempeln der Quelle. Für Löschungen brauchst du eine eigene unterstützte Strategie. Eine entfernte Blob-Datei beweist nicht, dass das Suchdokument ebenfalls verschwunden ist. Richte die Strategie ein und teste sie, bevor du dich darauf verlässt. Änderungs- und Löschverfolgung

Erstelle für einen kontrollierten Test eine synthetische Richtlinie mit einem eindeutigen Wert. Indexiere sie, frage sie ab und speichere die zurückgegebenen Schlüssel. Ersetze anschließend die Regel, durchlaufe die Indexierung erneut und wiederhole die Abfrage. Die alte Regel darf nicht mehr als aktuelle Quelle erscheinen.

Danach folgt die Löschung. Wenn deine Anwendung Chunks selbst in den Index schreibt, lösche die bekannten alten Chunk-Schlüssel gezielt. Der Push-Aufruf verwendet den Schlüssel jedes Suchdokuments, nicht automatisch die Kennung seines übergeordneten Dokuments:

POST https://<search-service>.search.windows.net/indexes/<index>/docs/index?api-version=2026-04-01
Content-Type: application/json
Authorization: Bearer <token-for-the-search-service>

{
  "value": [
    { "@search.action": "delete", "id": "policy-travel-v1-chunk-001" },
    { "@search.action": "delete", "id": "policy-travel-v1-chunk-002" }
  ]
}

Ersetze den Feldnamen, wenn dein Index einen anderen Schlüssel als id verwendet. Die aufrufende Identität muss Indexdaten ändern dürfen. Prüfe die Ergebnisse pro Dokument. Eine HTTP-Antwort allein ist noch keine Abnahme; frage anschließend erneut nach der entfernten Regel. Push-Indexierung und Dokumentaktionen

Bei One-to-many-Indexierung ist besondere Vorsicht nötig. Eine Löschstrategie auf Quellenebene deckt nicht automatisch alle erzeugten Chunks ab. Microsoft nennt dafür Einschränkungen in der Löschdokumentation. Halte die Chunk-Schlüssel in einem Manifest fest oder verwende einen überprüfbaren Bereinigungsprozess.

Wiederverwendung an den aktuellen Stand binden

Ein Eintrag im Antwort-Cache sollte für meine Anwendung Quellenkennung, Revision und eine Wissensgeneration enthalten. Diese Generation wird bei relevanten Änderungen erhöht. Sie ist eine eigene Eigenschaft der Anwendung, kein Feld einer Azure-AI-Search-API.

Das Verzeichnis aktueller Quellen muss aus dem vertrauenswürdigen Backend stammen. Weder das Sprachmodell noch ein frei gesetztes Request-Feld darf bestimmen, welche Version aktuell ist. Prüfe dieses Verzeichnis vor dem Wiederverwenden einer Antwort.

Das folgende lokale Beispiel macht die Regel prüfbar. Speichere es als freshness_check.py und führe python3 freshness_check.py aus:

from dataclasses import dataclass, replace

@dataclass(frozen=True)
class Source:
    version: str
    active: bool
    groups: frozenset[str]

@dataclass(frozen=True)
class Evidence:
    source_id: str
    version: str
    epoch: int
    observed_at: int

def reusable(ref, registry, caller_groups, epoch, now, max_age=60):
    source = registry.get(ref.source_id)
    return bool(source and source.active
        and source.version == ref.version
        and ref.epoch == epoch
        and source.groups.intersection(caller_groups)
        and 0 <= now - ref.observed_at <= max_age)

registry = {"policy": Source("v2", True, frozenset({"staff"}))}
current = Evidence("policy", "v2", 7, 1000)
assert reusable(current, registry, {"staff"}, 7, 1010)
assert not reusable(replace(current, version="v1"), registry, {"staff"}, 7, 1010)
assert not reusable(current, {}, {"staff"}, 7, 1010)
assert not reusable(current, registry, {"guest"}, 7, 1010)
assert not reusable(current, registry, {"staff"}, 8, 1010)
assert not reusable(current, registry, {"staff"}, 7, 1100)
print("current evidence accepted; stale evidence rejected")

Die sechzig Sekunden sind ein Lehrbeispiel, keine empfohlene Produktionsvorgabe. Eine kurze TTL allein erkennt keinen sofortigen Rechteentzug. Deshalb prüft das Beispiel auch aktuelles Verzeichnis, Revision und erlaubte Gruppen. Verwendet eine Antwort mehrere Quellen, müssen alle maßgeblichen Verweise die passenden Prüfungen bestehen.

Zugriff erneut prüfen statt Berechtigungen dauerhaft zu cachen

Eine Antwort kann fachlich aktuell sein und für einen bestimmten Benutzer trotzdem unzulässig. Das passiert etwa, wenn jemand nach der ersten gespeicherten Antwort aus einer Gruppe entfernt wird.

Azure AI Search unterstützt anwendungsseitige Sicherheitsfilter und bestimmte native Berechtigungsansätze. Ihre Voraussetzungen unterscheiden sich; native ACL- und Sensitivity-Label-Funktionen können Preview sein. Wähle den unterstützten Weg für deine Quelle. Nicht jeder Index übernimmt automatisch SharePoint-Berechtigungen. Dokumentbezogene Zugriffskontrolle

Bei anwendungsseitigen Filtern ist die Anwendung für die richtige vertrauenswürdige Benutzer- und Gruppenzuordnung zuständig. Ein Benutzer darf nicht per Prompt den Filter einer anderen Gruppe auswählen. Security-Filter-Muster

Invalidiere betroffene Antworten bei Rechteänderungen und prüfe die Autorisierung erneut bei der Ausgabe. Für sensible Aktionen gehört eine aktuelle Berechtigungsprüfung außerdem an das Backend, das die Aktion ausführt.

Bestehende Gespräche mitprüfen

Starte ein Gespräch vor dem Austausch der Richtlinie und ein zweites danach. Stelle nach der Änderung in beiden dieselbe Frage.

Im älteren Gespräch steht die alte Information bereits. Behandle sie als historischen Kontext, hole die aktuelle Richtlinie erneut und nenne ihren Gültigkeitsstand. Kann die Anwendung die aktuelle Fassung nicht feststellen, sollte sie genau das sagen, statt beide Regeln zu vermischen.

Bei strikten Löschanforderungen muss auch der Umgang mit gespeichertem Gesprächszustand und Memory-Verweisen festgelegt sein. Ein gelöschter Suchindex entfernt keine bereits angezeigten Nachrichten, exportierten Berichte oder Screenshots. Überprüfbar ist, ob die Anwendung erneut auf abgelöste Quellen zugreift oder daraus neue Antworten erzeugt.

Der englischsprachige Beitrag zu Copilot-Memory-Kontrollen behandelt konkrete Produktfunktionen. Diesen Quellen-Lebenszyklus würde ich unabhängig von der verwendeten Memory-Bibliothek testen.

Diese Reihenfolge vor dem nächsten Release durchspielen

1. Synthetische Version eins veröffentlichen und ihre Chunk-Schlüssel festhalten.
2. Durch Version zwei ersetzen, Indexierung prüfen und alte sowie neue Gespräche testen.
3. Einem Testbenutzer den Zugriff entziehen; Retrieval und gespeicherte Antworten erneut abfragen.
4. Die Quelle über den unterstützten Weg löschen und prüfen, dass ihre Chunks nicht mehr gefunden werden.
5. Eine freigegebene Version wiederherstellen und ihre erneute Indexierung und Abfrage prüfen.

Halte Quellenstand, Indexstatus, Benutzer, Frage, Antwort und Quellenangaben pro Schritt fest. Der richtige Titel reicht nicht: Die Antwort muss die richtige Version verwenden und innerhalb des aktuellen Benutzerzugriffs bleiben.