physar / LLMOps / RAG Data Lifecycle: Rechte, Qualität, Löschung

RAG Data Lifecycle: Rechte, Qualität, Löschung

Retrieval beginnt vor dem Index und endet nicht beim Re-Embedden: Dokumente aufnehmen, Berechtigungen erhalten, Qualität messen, Änderungen nachvollziehen und Daten zuverlässig entfernen.

Der Index ist ein abgeleitetes Datenprodukt

Einführung · 5 Abschnitte · ~10 Min Lesezeit · Stand

Die relevante Grenze

Ein RAG-Index ist keine Kopie eines Ordners, sondern eine abgeleitete, durchsuchbare Projektion. Daher ist nicht nur der Upload wichtig: Parser, Chunking, Metadaten und Embeddings entscheiden, was auffindbar ist. Eine Antwort darf nur auf Inhalte zugreifen, die der anfragende Nutzer im Ursprungssystem sehen dürfte.

Aufnahme braucht einen nachvollziehbaren Vertrag

  1. Quelle identifizieren und abrufen
  2. Inhalt extrahieren und Qualität prüfen
  3. Dokument, Version und ACL-Metadaten speichern
  4. Chunks und Embeddings erzeugen
  5. Indexierung und Suchbarkeit bestätigen

Scheitert ein Schritt, darf das System nicht stillschweigend einen unvollständigen oder unlesbaren Inhalt als vertrauenswürdiges Wissen ausgeben. Quarantäne und ein sichtbarer Fehlerzustand sind oft besser als ein verdeckter Teilindex.

Berechtigungen gehören in den Retrieval-Pfad

Autorisierung nur vor dem Chatfenster zu prüfen reicht nicht. Die Anfrage muss beim Retrieval gegen Dokument- oder Chunk-Metadaten gefiltert werden. Bei feingranularen Rechten können Attribute von Subjekt, Objekt, Aktion und Kontext die Entscheidung bestimmen.

Änderung, Löschung und Nachweis

EreignisErforderliche Reaktion
Neue DokumentversionAlte und neue Version unterscheidbar machen, Reindexierung nachverfolgen
Berechtigung entzogenTreffer sofort ausschließen; Index-Metadaten aktualisieren
LöschanforderungPrimärquelle und abgeleitete Chunks, Embeddings, Caches und Backups nach definierter Policy behandeln
Parser- oder ImportfehlerQuarantäne, Alarm und reproduzierbarer Reprocessing-Pfad

Löschung ist ein Workflow, kein einzelner Datenbankbefehl. Das Ziel ist belegbar zu wissen, welche abgeleiteten Kopien existieren und welcher Prozess sie innerhalb der zugesagten Frist entfernt oder unzugänglich macht.

Was die Checks prüfen

  • Ob ein Berechtigungsmodell bis in die Suche durchgereicht werden muss
  • Wann ein fehlerhafter Import quarantänisiert statt indexiert wird
  • Warum Löschung und Versionswechsel einen vollständigen Ableitungsweg brauchen

Gelesen ist nicht geprüft: Im Modul entscheidest du die Fälle selbst und siehst danach, wo dein Urteil trägt.

4 Checks starten →

Modul-Aufbau

EINFÜHRUNGDer Index ist ein abgeleitetes Datenprodukt~10 Min
ADR-001ACL-PROPAGATIONsenior
ADR-002INGEST-QUALITYsolide
ADR-003DELETION-LINEAGEsenior
SORT-004MISSION · ACL-PROPAGATIONsenior

Quellen

  1. 01NIST SP 800-162: Guide to Attribute Based Access Control
  2. 02Google SRE Workbook: Data Processing Pipelines

Verfasst von Julian Zentgraf