Was ist RAG?
Retrieval-Augmented Generation (RAG) ist eine Anwendungsarchitektur, bei der die Anwendung zu einer Aufgabe passende Inhalte sucht und ausgewählte Teile davon in den Modellkontext legt, bevor das Modell antwortet. Das Modell selbst wird nicht verändert, nur seine Eingabe.
RAG ist ein Muster, kein Modellbaustein und keine Sicherheitsgrenze. Produkte unterscheiden sich stark darin, wie sie Inhalte aufnehmen, indexieren, abrufen und zusammensetzen. Dieser Artikel beschreibt verbreitete Rollen in der Architektur, keine universelle Implementierung.
Er baut auf Vertrauensgrenzen und Modellkontext und AI Agents und Tool Calling auf: Modellsichtbare Inhalte können die Ausgabe beeinflussen, aber Vertrauen, Autorität und sicherheitsrelevante Fakten werden durch anwendungsseitigen Zustand und Nachweise festgestellt.
Warum Anwendungen Retrieval nutzen
Anwendungen rufen Inhalte ab, um auf Basis aktueller oder organisationsspezifischer Informationen zu antworten, um belegen zu können, woher eine Antwort stammt, und um nicht ganze Datenbestände in jede Anfrage zu legen. Retrieval verbessert Relevanz und Nachvollziehbarkeit.
Retrieval bedeutet, Inhalte für eine Aufgabe auszuwählen. Es authentifiziert diese Inhalte nicht, bestätigt nicht ihre Richtigkeit und verleiht ihnen keine Autorität über Anwendung oder Modell.
Die RAG-Pipeline
| Stufe | Was sie tut | Vertrauenscharakter |
|---|---|---|
| Quelle | Dokument, Seite, Datensatz oder Nachricht, die später abgerufen werden kann | Variabler Inhalt plus von der Anwendung erfasste Quellidentität und Provenienz |
| Aufnahme (Ingestion) | Ein Connector holt und registriert die Quelle | Vertrauenswürdige Verarbeitungskomponente; bestätigt den Inhalt nicht |
| Parsen, Normalisieren, Chunking | Extrahiert Text, teilt ihn auf und hängt Metadaten an | Transformation; die Herkunftskette muss erhalten bleiben |
| Embedding und Index | Erzeugt Retrieval-Repräsentationen und speichert sie | Retrieval-Repräsentation; weder Vertrauen noch Berechtigung |
| Nutzeranfrage | Nutzeranfrage ist variable Eingabe; Principal, Mandant und Aufgabenrahmen sind anwendungseigene Metadaten | Gemischt: Anfragetext ist variable Eingabe; Scope-Metadaten sind anwendungseigen |
| Query Rewriting (optional) | Formuliert die Anfrage um oder erweitert sie | Variabler oder generierter Text bei unverändertem Autorisierungsrahmen |
| Kandidatenabruf | Findet ähnliche oder passende Einträge | Auswahl nach Relevanz |
| Security Trimming | Entfernt Einträge, die der aktuelle Principal nicht lesen darf | Deterministische Zulässigkeit nach aktuellem Principal, Mandant und ACL |
| Ranking und Reranking | Ordnet die verbleibenden Kandidaten | Ordnet nur bereits zulässige Kandidaten |
| Kontextaufbau | Legt ausgewählte Inhalte in den Modellkontext | Variable ausgewählte Inhalte werden modellsichtbar; anwendungsseitige Provenienz bleibt verknüpft |
| Modellantwort oder Vorschlag | Text, Zitate oder ein vorgeschlagener nächster Schritt | Variable Ausgabe |
| Anwendungsrichtlinie | Entscheidet, was zurückgegeben, verwendet, offengelegt oder ausgeführt werden darf | Entscheidung der Anwendung |
Die Reihenfolge variiert. Manche Systeme filtern Berechtigungen schon in der Indexabfrage, andere trimmen nach dem Kandidatenabruf. Entscheidend ist, dass die Zulässigkeit feststeht, bevor Inhalte modellsichtbar werden.
Was tatsächlich modellsichtbar wird
In verbreiteten Designs erhält das Modell ausgewählten Text oder eine andere gerenderte oder rekonstruierte Darstellung, zusammen mit den Metadaten, die die Anwendung anzeigen möchte. Alles, was dort landet, kann die Ausgabe beeinflussen, auch Sätze, die wie Anweisungen aussehen.
Anwendungseigene Fakten wie Identität des Aufrufers, Mandant, ACL-Entscheidungen und Versionsstand sollten außerhalb des Modells gehalten und durchgesetzt werden. Ein Label im Kontext kann dem Modell beim Formulieren helfen; durchsetzbar wird es dadurch nicht.
Relevanz ist kein Vertrauen
Ein vertrauenswürdiger Retriever, Connector, Parser, eine Vektordatenbank oder ein Index kann nicht vertrauenswürdige oder von Angreifern beeinflusste Inhalte originalgetreu transportieren. Vertrauenswürdige Infrastruktur überträgt kein Vertrauen auf die Inhalte, die sie befördert, so wie ein vertrauenswürdiger Browser eine nicht vertrauenswürdige Seite anzeigen kann.
Provenienz und zweckgebundene Autorität
| Frage | Entschieden durch |
|---|---|
| Quellvertrauen und Provenienz: Woher stammt das, wurde es verändert? | Erfasste Quellidentität, Version und Herkunftskette |
| Quellautorität: Ist diese Quelle für diesen Zweck vorgesehen? | Eine Source-of-Truth-Regel oder ein Register für das Thema |
| Nutzer- und Mandantenautorisierung: Darf dieser Aufrufer es lesen? | ACL oder Richtlinie für den aktuellen Principal |
| Anweisungsautorität: Darf dieser Inhalt die Anwendung steuern? | Anwendungsdesign; abgerufene Inhalte haben normalerweise keine |
| Antwort- und Aktionsautorisierung: Darf das zurückgegeben oder ausgeführt werden? | Nachgelagerte Anwendungsrichtlinie |
Eine authentische Quelle kann für die aktuelle Frage trotzdem die falsche Autorität sein. Eine echte Teamnotiz ist authentisch, muss aber nicht die maßgebliche Richtlinie für eine Kundenantwort sein. Autorität ist oft zweckgebunden.
Maßgebliche Metadaten gehören nicht in Dokumenttext, den Angreifer bearbeiten können. Ein Satz wie "freigegeben", "öffentlich", "aktuell" oder "gehört zu Mandant X" ist Inhalt, keine Richtlinie. Siehe Datenprovenienz.
Retrieval-Autorisierung und Security Trimming
Security Trimming bedeutet, Inhalte, die der aktuelle Principal nicht lesen darf, zu entfernen, bevor sie in den modellsichtbaren Kontext gelangen. Erst nach der Generierung zu filtern ist zu spät: Das Modell hat die geschützten Inhalte dann bereits gesehen und womöglich in Formulierungen, Zusammenfassungen oder Vorschläge einfließen lassen.
Ranking sollte nur Kandidaten ordnen, die nach aktueller Autorisierung zulässig sind. Ein hoher Rang darf einen Autorisierungsfehler nie reparieren oder übersteuern.
Nutzer-, Mandanten- und Anfragerahmen
Initiierender Principal, Mandant, Sitzung und Aufgabenrahmen sind anwendungseigener Zustand, festgestellt durch Authentifizierung und Sitzungsverwaltung. Der Anfragetext ist variable Eingabe. Autorisierung wird nie aus dem abgeleitet, was die Anfrage sagt oder was das Modell ausgibt.
Eine Anfrage, die einen anderen Mandanten, eine eingeschränkte Sammlung oder eine Rolle nennt, ändert den Rahmen des Aufrufers nicht. Der Rahmen begleitet die Anfrage als Metadaten, die das Modell nicht bearbeiten kann.
Query Rewriting und Folgeabrufe
Viele Systeme formulieren Anfragen um oder erweitern sie, teils mit einem Modell, um mehr passende Treffer zu finden. Die umformulierte Anfrage ist variabler oder generierter Text. Sie darf die Formulierung erweitern, aber nie den Mandanten-, Ressourcen-, Sammlungs-, Feld- oder Berechtigungsrahmen des Aufrufers.
Folgeabrufe, die im Gesprächsverlauf oder von einem Agenten vorgeschlagen werden, sind ebenfalls Vorschläge. Jeder Abruf läuft im selben Autorisierungsrahmen wie die ursprüngliche Anfrage.
Embeddings, Ranking und Reranking
Ein Embedding ist eine numerische Darstellung, mit der Bedeutungen verglichen werden. In üblichen RAG-Designs dienen Embeddings und andere Vektordarstellungen der Kandidatenauswahl und dem Ranking; das Modell erhält typischerweise ausgewählten Text oder eine andere gerenderte Darstellung, nicht "das Embedding selbst". Implementierungen unterscheiden sich, besonders bei multimodalen Systemen.
Reranking ordnet Kandidaten mit einem weiteren Bewertungsschritt neu. Scores drücken geschätzte Relevanz zur Anfrage aus. Über Wahrheit, Aktualität, Berechtigung oder Autorität sagen sie nichts.
Chunking, Parsing, Zusammenfassungen und abgeleitete Artefakte
Parsing, OCR, Chunking, Zusammenfassung und Query Rewriting verändern Inhalte. Sie können Kontext verlieren, eine Einschränkung von der Aussage trennen, die sie begrenzt, Text wiederholen oder neue abgeleitete Artefakte erzeugen. Anweisungsartige Bedeutung bereinigen sie nicht.
Herkunftsangaben, die Transformationen überdauern sollten
- Quell-, Dokument- und Versionskennungen
- Beitragende Person oder Eigentümer
- Mandant und ACL oder Sicherheitslabel
- Chunk-Herkunft bis zum Quellabschnitt
- Transformations- und Indexversion, wo sinnvoll
Diese Felder sind Architekturempfehlungen, keine Feldliste aus einem Standard.
Zitate und Nachvollziehbarkeit
Ein Zitat verknüpft eine Antwort mit dem abgerufenen Eintrag, auf den sie sich stützt. Das ist für Prüfungen wertvoll. Es zeigt aber nicht, dass der Eintrag richtig oder aktuell ist oder dass die lesende Person ihn sehen durfte; das sind getrennte Prüfungen.
Eine fundierte oder zitierte Antwort bleibt Modellausgabe und variable Daten. Sie wird nicht dadurch maßgeblich für die Anwendung, dass sie auf eine Quelle verweist.
Knowledge Poisoning, RAG Prompt Injection und Vektorschwächen
| Begriff | Kernproblem |
|---|---|
| Knowledge oder Corpus Poisoning | Verfälschte Fakten im Datenbestand schädigen die Wissensintegrität; anweisungsartiger Inhalt ist nicht nötig |
| RAG Prompt Injection | Abgerufene anweisungsartige Inhalte beeinflussen das Modellverhalten |
| Vektor- und Embedding-Schwächen | Breitere Fehler bei Erzeugung, Speicherung, Metadaten, Zugriff oder Abruf von Vektoren, einschließlich unberechtigtem Zugriff oder manipuliertem Retrieval |
Ein Artefakt kann mehrere davon betreffen, aber die Begriffe sind keine Synonyme und brauchen getrennte Befunde. OWASP führt Prompt Injection (LLM01:2026) und Vector and Embedding Weaknesses (LLM09:2026) als getrennte Risiken. Die Angriffsmechanik behandelt RAG Prompt Injection.
Widerruf, veraltete Indizes, Caches und abgeleiteter Zustand
Wird eine Quelle entfernt oder korrigiert, verschwinden ihre abgeleiteten Chunks, älteren Indexgenerationen, Caches, Zusammenfassungen oder Memory-Einträge nicht zwingend mit. Inhalte können abrufbar bleiben, obwohl die Quelle weg ist.
Herkunftsbewusste Invalidierung bedeutet, anhand der erfassten Herkunftskette jedes aus einer Quelle oder Version abgeleitete Artefakt zu finden und zu widerrufen und zu bestätigen, dass der Abruf es nicht mehr liefert. Das ist eine Architekturempfehlung.
Agentisches RAG und nachgelagerte Aktionen
Bei agentischem RAG können abgerufene Inhalte spätere Abrufe oder Tool-Vorschläge beeinflussen. Diese bleiben Vorschläge. Die Autorisierung von Tools und Aktionen bleibt unabhängig und deterministisch, wie in AI Agents und Tool Calling beschrieben.
Ausgabevalidierung ist eine nachgelagerte Prüfung von Form und Vertrag. Sie ist getrennt von Quellvertrauen, Retrieval-Autorisierung und senkenspezifischer Kodierung, Escaping oder Parametrisierung. Siehe Ausgabevalidierung.
Synthetische Beispiele
Rang 1 passt sehr gut zur Frage nach der fiktiven Rückgabefrist, aber die Anwendung hat keine erfasste Quellidentität oder Freigabe dafür.
Die Anwendung stellt den Eintrag nicht als offizielle Tatsache dar.
Eine Teamnotiz steht auf Rang 1; das Register kennzeichnet policy-doc-A v4 (Rang 3) als aktuelle maßgebliche Quelle für das Thema, und die Nutzerin darf sie lesen.
Die Antwort stützt sich trotz geringerer Ähnlichkeit auf policy-doc-A v4.
Die Antwort zitiert guide-B v2 exakt; das Versionsregister kennzeichnet v2 als durch v3 ersetzt.
Das Zitat bleibt nachvollziehbar, aber die Anwendung stellt den Inhalt nicht als aktuell dar.
Ein eingeschränktes Dokument in collection-R würde die Frage perfekt beantworten; die aktuelle Person hat keinen Lesezugriff.
Security Trimming schließt es vor dem Kontextaufbau aus; es wird nie modellsichtbar.
Eine generierte Umformulierung erweitert den Wortlaut der Frage; die Anfrage bleibt an tenant-1 und die für die Person lesbaren Sammlungen gebunden.
Nicht berechtigte Sammlungen bleiben unabhängig von der Umformulierung unzulässig.
Ein Eintrag im Datenbestand nennt ein falsches fiktives Eröffnungsdatum. Er enthält keinen anweisungsartigen Text.
Ein Problem der Wissensintegrität, keine Prompt Injection; Provenienz und Source-of-Truth-Regeln adressieren es.
Logging, Telemetrie und Audit-Nachweise
Nützliche Nachweise pro Anfrage
- Principal, Mandant und Sitzungsrahmen des Abrufs
- Ursprüngliche und umformulierte Anfrage, getrennt gehalten
- Kandidaten-IDs mit Quelle, Version und Herkunftskette
- Trimming-Entscheidungen und angewendete Richtlinienversion
- In den Kontext gelegte Einträge in ihrer Reihenfolge
- Zurückgegebene Zitate und nachgelagerte Entscheidungen
Diese Nachweise gehören außerhalb des Modells und sind so zu schützen wie die Daten, die sie beschreiben. Das ist eine Architekturempfehlung.
Häufige Missverständnisse
Aussagen, die nicht zutreffen
- "RAG macht Antworten vertrauenswürdig."
- "Das bestplatzierte Ergebnis ist das maßgebliche."
- "Unser Retriever ist vertrauenswürdig, also sind abgerufene Inhalte es auch."
- "Eingeschränkte Inhalte können wir nach der Modellantwort herausfiltern."
- "Ein Zitat beweist, dass die Antwort stimmt."
- "Wer die Quelle löscht, löscht alles daraus Abgeleitete."
- "Chunking oder Embedding entfernt Anweisungen aus Text."
Quellen und Praxis
Wie dieser Artikel Quellen nutzt
- OWASP
- LLM01:2026 Prompt Injection, LLM09:2026 Vector and Embedding Weaknesses
- NIST
- AI 100-2e2025 und Glossar - Begriff indirekte Prompt Injection
- Microsoft
- Input, Context, and Retrieval Hygiene, Defend against indirect prompt injection attacks
- Forschung
- PoisonedRAG - USENIX Security 2025, Forschung zu Knowledge Corruption, Overcoming the Retrieval Barrier - USENIX Security 2026, Vorhandensein im Datenbestand, Abrufbarkeit und spätere Beeinflussung
PoisonedRAG wird als Forschung zu Knowledge Corruption zitiert, nicht automatisch als Prompt Injection. Source-of-Truth-Register, Herkunftsfelder, Invalidierung und Audit-Nachweise sind Architekturempfehlungen, keine aus einem Standard zitierten Anforderungen.
Die Konzepte lassen sich in den Labs Retrieval-Relevanz und Vertrauen, RAG Prompt Injection und Manipulierte Wissensbasis üben.
Häufige Fragen
Ist RAG eine Sicherheitskontrolle?
Bedeutet ein hoher Ähnlichkeitswert, dass eine Quelle verlässlich ist?
Wo sollten Berechtigungsprüfungen stattfinden?
Kann Query Rewriting den Zugriff erweitern?
Sieht das Modell Embeddings?
Ist Knowledge Poisoning dasselbe wie RAG Prompt Injection?
Was passiert, wenn eine Quelle entfernt wird?
Quellen
- LLM01:2026 Prompt InjectionOWASP GenAI Security Project · GuidanceGeprüft 2026-09-26
- LLM09:2026 Vector and Embedding WeaknessesOWASP GenAI Security Project · GuidanceGeprüft 2026-09-26
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Geprüft 2026-09-26
- indirect prompt injectionNIST Glossary · Technical documentationGeprüft 2026-09-26
- Input, Context, and Retrieval HygieneMicrosoft Learn · GuidanceGeprüft 2026-09-26
- Defend against indirect prompt injection attacksMicrosoft Learn · GuidanceGeprüft 2026-09-26
- PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language ModelsUSENIX Association · Research publication · USENIX Security 2025Geprüft 2026-09-26
- Overcoming the Retrieval Barrier: Indirect Prompt Injection in the Wild for LLM SystemsHongyan Chang et al. · Research publication · USENIX Security 2026Geprüft 2026-09-26