RAG ist keine Wahrheitsmaschine
Ein Sprachmodell wird nicht wahrheitsfähig, nur weil man ihm Dokumente vorlegt. Es erhält lediglich eine bessere Chance, seine Antwort auf überprüfbare Evidenz zu stützen.

Retrieval-Augmented Generation wirkt auf den ersten Blick wie die elegante Lösung für ein bekanntes Problem. Statt ausschließlich auf parametrisches Modellwissen zu vertrauen, sucht das System passende Informationen in einem externen Bestand und gibt sie dem Modell als Kontext. Quellen können aktualisiert, interne Dokumente einbezogen und Antworten mit Belegen versehen werden.
Das ist ein großer Fortschritt. Es ist aber kein Wahrheitsmechanismus. Ein RAG-System kann die falsche Quelle finden, die richtige Quelle falsch segmentieren, eine gültige Passage übersehen, veraltete Inhalte höher ranken, unzulässige Dokumente abrufen oder die gefundene Evidenz bei der Formulierung verdrehen. Qualität entsteht deshalb nicht an einem einzigen Modellaufruf, sondern entlang einer vollständigen Evidenzkette.
RAG verschiebt das Problem
Ohne Retrieval lautet die zentrale Frage: Was hat das Modell gelernt, und wie zuverlässig kann es dieses Wissen anwenden? Mit RAG kommen neue Fragen hinzu: Befindet sich die benötigte Information überhaupt im Korpus? Ist sie gültig, zugänglich und korrekt beschrieben? Wird die Anfrage richtig verstanden? Findet der Retriever die relevante Passage? Rangiert sie hoch genug? Passt sie in das Kontextfenster? Nutzt das Modell sie treu?
RAG reduziert damit bestimmte Risiken, fügt aber eine komplexe Systemoberfläche hinzu. Die ursprüngliche NeurIPS-Arbeit verband parametrisches Wissen mit einer nichtparametrischen, abrufbaren Wissensquelle und berichtete spezifischere und faktischere Ausgaben als bei einem parametrischen Vergleichssystem. Daraus folgt nicht, dass jede heutige RAG-Pipeline zuverlässig ist. Korpus, Retriever, Ranking, Prompt, Modell und Evaluation unterscheiden sich fundamental.
Ein hilfreiches Denkmodell zerlegt RAG in sechs Kontrollpunkte: Wissen aufnehmen, Kandidaten begrenzen, Evidenz abrufen, Evidenz ordnen, Kontext zusammenstellen und Antwort erzeugen. Jeder Punkt kann Qualität erhöhen oder zerstören.
Ähnlichkeit ist weder Wahrheit noch Autorität
Vektorsuche beantwortet vereinfacht die Frage, welche Repräsentationen einer Anfrage ähnlich sind. Sie beantwortet nicht automatisch, welche Quelle wahr, aktuell, freigegeben oder für diese Person zulässig ist. Ein ausführlicher alter Entwurf kann semantisch näher liegen als eine kurze neue Entscheidung. Eine häufig zitierte Behauptung kann leichter auffindbar sein als ihre spätere Korrektur.
Deshalb braucht Retrieval einen zulässigen Kandidatenraum. Mandant, Berechtigung, Schutzklasse, Gültigkeitszeitraum, Dokumentstatus, Sprache, Region und erlaubter Zweck werden vor oder verbindlich innerhalb der Suche gefiltert. Sicherheitsregeln gehören nicht nur in den Prompt. Das Modell darf Inhalte, für die keine Berechtigung besteht, gar nicht erst erhalten.
Anschließend kann hybride Suche lexikalische und semantische Signale verbinden. Exakte Kennungen, Namen, Paragraphen oder Produktcodes profitieren oft von Schlüsselwortsuche; paraphrasierte Fragen von dichten Repräsentationen. Ein Reranker kann Kandidaten feiner zur konkreten Anfrage bewerten. Diese Komponenten verbessern die Auswahl, ersetzen aber keine Quellenhierarchie und Gültigkeitslogik.
Chunking entscheidet, welche Aussage überhaupt sichtbar wird
Dokumente werden häufig in Abschnitte zerlegt, weil ganze Dateien nicht sinnvoll in Index und Kontext passen. Zu kleine Chunks verlieren Definition, Ausnahme oder zeitlichen Bezug. Zu große Chunks verdünnen das relevante Signal und verbrauchen Kontext. Starre Zeichenlängen können Überschrift vom Absatz, Tabellenkopf von Werten oder Regel von Ausnahme trennen.
Chunking sollte deshalb Struktur respektieren: Überschriften, Absätze, Listen, Tabellen, Seiten, Sprecherwechsel und fachliche Einheiten. Jeder Chunk erbt Dokument-ID, Position, Version, Status, Sprache, Berechtigung und Provenienz. Überlappung kann Kontext erhalten, erzeugt aber Dubletten und darf Trefferstatistiken nicht künstlich aufblasen.
Besonders kritisch sind Beziehungen über mehrere Stellen. Eine Definition steht am Anfang, die Ausnahme drei Seiten später und das Inkrafttreten im Anhang. Kein einzelner Chunk enthält die vollständige Antwort. Parent-Child-Retrieval, Nachbarschaftserweiterung oder mehrstufige Suche können helfen. Entscheidend ist, solche Fälle im Testset abzubilden.
Query Transformation kann helfen und verfälschen
Systeme formulieren Nutzerfragen um, erzeugen Teilfragen, erweitern Synonyme oder erstellen hypothetische Antworten als Suchanker. Das kann Recall erhöhen. Gleichzeitig kann die Transformation Bedeutung verschieben, Einschränkungen entfernen oder aus einer offenen Frage eine unbelegte Annahme machen.
Die Originalanfrage bleibt deshalb erhalten. Jede Umschreibung wird als abgeleitetes Objekt protokolliert und mit Tests verglichen. Bei sensiblen Filtern wie Zeitraum, Person, Produkt oder Rechtsraum dürfen kritische Bedingungen nicht verloren gehen. Für komplexe Fragen ist es oft besser, mehrere Suchanfragen zu erzeugen und ihre Evidenz später zusammenzuführen, statt eine einzige „optimierte" Frage als Wahrheit zu behandeln.
Auch Konversationsverlauf kann stören. Ein Pronomen wie „das" benötigt Kontext, aber alte Gesprächsannahmen dürfen die neue Suche nicht unbemerkt dominieren. Query-Rewriting ist ein kontrollierter Interpretationsschritt, kein unsichtbarer Komfortfilter.
Gefundene Evidenz ist noch keine treue Antwort
Selbst wenn die richtige Passage im Kontext liegt, kann das Modell sie ignorieren, falsch kombinieren oder um Wissen ergänzen, das nicht belegt ist. Eine flüssige Antwort kann stärker formuliert sein als die Quelle. Aus „kann" wird „muss", aus einem Beispiel eine allgemeine Regel, aus Korrelation Kausalität.
Ein Evidence Contract macht die Aufgabe enger. Zentrale Aussagen müssen auf konkrete Passagen verweisen. Widersprüche werden sichtbar benannt. Das Modell unterscheidet direkte Evidenz, zulässige Ableitung und ungesicherte Interpretation. Fehlt ausreichende Evidenz, reduziert es den Anspruch, stellt eine Rückfrage oder antwortet nicht.
Abstention ist damit ein Qualitätsmerkmal. Ein System, das immer antwortet, optimiert Oberfläche statt Verlässlichkeit. Die Schwelle hängt vom Risiko ab: Für Ideensammlung kann eine vorsichtige Hypothese sinnvoll sein; für eine folgenschwere Entscheidung braucht es stärkere Evidenz und häufig menschliche Prüfung.
Zitation ist ein eigener Prüfschritt
Eine Quellenangabe kann vorhanden und trotzdem falsch sein. Der verlinkte Abschnitt kann das Thema erwähnen, ohne die konkrete Aussage zu tragen. Eine Antwort kann eine belegte Passage korrekt zitieren und daneben unbelegte Behauptungen enthalten. Daher müssen mindestens drei Fragen getrennt werden:
1 · Zitationskorrektheit: Trägt die zitierte Passage tatsächlich die zugeordnete Aussage?
2 · Zitationsvollständigkeit: Sind alle wesentlichen überprüfbaren Aussagen belegt?
3 · Quellenqualität: Ist die Quelle für Zweck, Zeitpunkt und Geltungsbereich geeignet?
Zitate sollten auf die verwendete Version und möglichst auf eine stabile Passage zeigen. Ein Link auf die Startseite oder ein gesamtes PDF erschwert Prüfung. Gleichzeitig darf ein System nicht so tun, als sei eine Modellantwort ein wörtliches Zitat. Paraphrase, Zusammenführung und direkte Wiedergabe müssen unterscheidbar bleiben.
Provenienz verbindet Antwort, Lauf, abgerufene Chunks, Indexversion, Extraktion und Originalquelle. Erst dann kann ein Fehler lokalisiert und eine zurückgezogene Quelle in ihren Auswirkungen verfolgt werden.
Der Wissensbestand ist eine Angriffsfläche
Externe oder von Nutzern hochgeladene Dokumente können Anweisungen enthalten, die ein Modell als Befehle interpretiert. OWASP beschreibt dies als indirekte Prompt Injection: Inhalt aus Dateien oder Webseiten verändert das Verhalten des Systems. RAG und Fine-Tuning beseitigen dieses Risiko nicht vollständig.
Deshalb wird abgerufener Inhalt als Daten behandelt, nicht als privilegierte Instruktion. Systemregeln und Werkzeugberechtigungen bleiben getrennt. Unvertrauenswürdige Quellen werden gekennzeichnet, Eingaben und Ausgaben geprüft, Werkzeuge minimal berechtigt und folgenschwere Aktionen menschlich bestätigt. Ein Dokument darf niemals allein dadurch Autorität über Tools erhalten, dass es semantisch gut zur Anfrage passt.
Auch der Index selbst kann manipuliert werden. Viele ähnliche Dokumente können Rankings verdrängen; vergiftete Texte können falsche Beziehungen oder versteckte Instruktionen verbreiten. Aufnahmeprozesse benötigen deshalb Herkunft, Freigabe, Deduplizierung, Quoten, Anomalieerkennung und kontrollierte Aktualisierung.
Evaluation muss Retrieval und Generation trennen
Eine einzige Bewertung „Antwort war gut" verrät nicht, wo ein Fehler entstand. Die Evaluation beginnt beim Korpus: Deckt er die Fragen ab? Sind gültige Versionen vorhanden? Danach wird Retrieval geprüft: Taucht relevante Evidenz in den Top-k auf, an welcher Position, und werden unzulässige oder veraltete Quellen ausgeschlossen?
Die Generationsprüfung fragt anschließend: Ist die Antwort durch den bereitgestellten Kontext gestützt? Ist sie fachlich korrekt? Werden Unsicherheit und Widerspruch angemessen dargestellt? Stimmen Zitate? Lehnt das System unbeantwortbare Fragen ab?
Ein belastbares Testset enthält normale Fragen, seltene Begriffe, Mehrdeutigkeiten, Multi-Hop-Fälle, alte Fassungen, widersprüchliche Quellen, harte Negativbeispiele, fehlende Antworten und Angriffsversuche. Es misst nicht nur Durchschnittswerte, sondern kritische Fehlerklassen und relevante Nutzergruppen.
Retrievalmetriken helfen bei der Diagnose. Recall@k zeigt, ob relevante Evidenz in den ersten k Treffern erscheint. Precision betrachtet den Anteil relevanter Treffer. MRR gewichtet die Position des ersten relevanten Ergebnisses; nDCG berücksichtigt abgestufte Relevanz und Reihenfolge. Keine Kennzahl ersetzt fachliche Relevanzurteile. BEIR zeigt zudem, dass Architekturen über unterschiedliche Domänen stark variieren können und robuste Baselines wichtig bleiben.
Produktionsqualität braucht Beobachtbarkeit
Nach dem Start verändert sich der Bestand. Dokumente werden ergänzt, Embeddingmodelle getauscht, Chunking angepasst und Nutzerfragen ändern sich. Deshalb gehören Index-, Schema-, Retriever-, Reranker-, Prompt- und Modellversion in den Antwortlauf.
Monitoring beobachtet leere Treffer, niedrige Scores, ungewöhnliche Quellenkonzentration, häufige Abstention, Berechtigungsfehler, Latenz, Kosten und Nutzerkorrekturen. Änderungen laufen zunächst gegen Regressionstests. Ein besserer Durchschnitt darf keine Verschlechterung bei kritischen Fragen oder Zugriffsschutz verdecken.
Die wichtigste Kennzahl ist oft nicht, wie überzeugend das System klingt. Es ist, wie zuverlässig es die richtige Evidenz findet, Grenzen erkennt und eine Prüfung ermöglicht. RAG ist dann stark, wenn es Unsicherheit nicht versteckt, sondern die Brücke zwischen Frage, Quelle und Antwort sichtbar macht.
Übungsblatt: Zerlege eine RAG-Antwort
Wähle einen kleinen Bestand aus mindestens zehn Dokumenten und entwickle acht Testfragen.
1. Korpus qualifizieren. Markiere gültige, veraltete, gesperrte, widersprüchliche und unzureichende Quellen.
2. Chunking vergleichen. Erzeuge zwei Segmentierungsvarianten und prüfe Definitionen, Ausnahmen, Tabellen und Multi-Hop-Fragen.
3. Retrieval testen. Vergleiche lexikalische, semantische und hybride Suche sowie einen Reranker.
4. Berechtigung erzwingen. Prüfe, dass gesperrte Inhalte auch bei perfekter Ähnlichkeit nicht in den Modellkontext gelangen.
5. Evidence Contract anwenden. Ordne jede Kernaussage einer Passage zu und markiere Ableitung oder Unsicherheit.
6. Abstention prüfen. Ergänze zwei unbeantwortbare Fragen und definiere die erwartete Reaktion.
7. Angriff simulieren. Platziere eine indirekte Instruktion in einem Testdokument und kontrolliere Tool- und Antwortverhalten.
8. Fehler lokalisieren. Ordne jeden Fehler Korpus, Chunking, Query, Retrieval, Ranking, Kontext, Generation oder Zitation zu.
Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:
Einordnung: RAG ist eine Architekturfamilie, kein einzelnes Qualitätsversprechen. Retrieval kann Antworten aktueller, spezifischer und belegbarer machen, garantiert aber weder Wahrheit noch Vollständigkeit, Rechtmäßigkeit oder Sicherheit. Messwerte wie Recall@k, Precision, MRR oder nDCG müssen passend zu Datensatz, Relevanzurteilen und Anwendung interpretiert werden.
● Nur für Mitglieder
Lies den vollständigen Artikel und lade alle Dateien mit einer Mitgliedschaft herunter.
Vollständigen Artikel + Downloads freischalten → Abonnieren0 Kommentare
● Kommentare werden geladen…