# 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.

Track: [LLMOps](https://physar.tech/learn/llmops)  
Kanonische Fassung: https://physar.tech/learn/llmops/rag-data-lifecycle  
Stand: 2026-07-25  
Interaktiver Teil: 4 Checks (nur im Browser)

## Der Index ist ein abgeleitetes Datenprodukt

### 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.

> **Merksatz:** Behandle jeden Indexeintrag wie eine veröffentlichte Ableitung mit Eigentümer, Quelle, Berechtigung und Version.

### Aufnahme braucht einen nachvollziehbaren Vertrag

Quelle identifizieren und abrufen → Inhalt extrahieren und Qualität prüfen → Dokument, Version und ACL-Metadaten speichern → Chunks und Embeddings erzeugen → 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.

> **Trade-off:** ACL-Filter erhöhen Komplexität und können Recall senken. Sie sind dennoch keine Qualitätsoptimierung, die man bei Druck abschaltet, sondern eine Sicherheitsgrenze.

### Änderung, Löschung und Nachweis

|  |  |
| --- | --- |
| Ereignis | Erforderliche Reaktion |
| Neue Dokumentversion | Alte und neue Version unterscheidbar machen, Reindexierung nachverfolgen |
| Berechtigung entzogen | Treffer sofort ausschließen; Index-Metadaten aktualisieren |
| Löschanforderung | Primärquelle und abgeleitete Chunks, Embeddings, Caches und Backups nach definierter Policy behandeln |
| Parser- oder Importfehler | Quarantä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

> **Abgrenzung:** Dieses Modul lehrt den Datenlebenszyklus. Retrieval-Algorithmus und Ranking bleiben in `rag-architecture` und `rag-quality`; Datenschutz-Risikobewertung bleibt im Security-Modul.

## Quellen

- NIST SP 800-162: Guide to Attribute Based Access Control — https://doi.org/10.6028/NIST.SP.800-162
- Google SRE Workbook: Data Processing Pipelines — https://sre.google/workbook/data-processing/