RAG ist kein Chatbot mit angehängten PDFs

Ein Dokumenten-Chat wirkt auf den ersten Blick wie Retrieval-Augmented Generation: PDFs werden hinzugefügt, eine Frage wird gestellt und eine flüssige Antwort erscheint. Technisch kann dahinter aber lediglich ein temporärer Dateikontext stehen. Es fehlen womöglich ein gepflegter Wissensbestand, eine explizite Suchstrategie, stabile Quellenreferenzen, getrennte Qualitätsmessungen und ein Aktualisierungsprozess. Das System kann nützlich sein – es ist dadurch noch keine belastbare RAG-Architektur.

RAG verbindet parametrisches Modellwissen mit einer externen, austauschbaren Wissensquelle. Die ursprüngliche Forschung beschreibt das Prinzip als Kombination eines Generators mit nichtparametrischer Erinnerung. Praktisch entsteht daraus keine einzelne Funktion, sondern eine Pipeline. Ihre Qualität hängt nicht nur vom Sprachmodell ab, sondern ebenso von Dokumentaufbereitung, Index, Retrieval, Kontextauswahl, Antwortlogik und Nachweis.

Vier Stufen statt eines Datei-Anhangs

Eine verständliche RAG-Pipeline besitzt vier Kernstufen. Retrieval sucht zu einer Anfrage passende Kandidaten. Context Assembly ordnet, filtert und begrenzt die gefundenen Passagen. Synthesis erzeugt eine Antwort unter Verwendung dieses Kontexts. Source Binding verbindet Aussagen mit überprüfbaren Fundstellen.

Jede Stufe kann unabhängig scheitern. Der Retriever kann die richtige Passage übersehen. Die Kontextzusammenstellung kann eine Einschränkung abschneiden. Der Generator kann eine plausible Ergänzung erfinden. Die Zitationslogik kann eine Quelle anzeigen, die zwar thematisch passt, die konkrete Aussage aber nicht trägt. Eine gute Oberfläche verdeckt diese Unterschiede; professionelles Engineering macht sie sichtbar.

Der Wissensbestand entsteht vor der ersten Frage

Vor dem Chat liegt die Ingestion Pipeline. Dokumente werden erfasst, auf Lesbarkeit geprüft, geparst, strukturiert, segmentiert, mit Metadaten versehen und indexiert. Version, Gültigkeit, Owner, Sprache, Berechtigung und Herkunft müssen erhalten bleiben. Ein Scan ohne Texterkennung, eine Tabelle ohne Spaltenbezug oder ein Handbuch ohne Versionsstatus wird durch Embeddings nicht automatisch zuverlässig.

Zur Anfragezeit wird nicht das gesamte Archiv in das Kontextfenster kopiert. Der Retriever erzeugt eine begrenzte Kandidatenmenge. Das kann lexikalisch, semantisch, hybrid oder durch mehrere Suchschritte geschehen. Anschließend werden Treffer neu bewertet, nach Berechtigungen gefiltert und innerhalb eines Kontextbudgets angeordnet. Erst danach beginnt die Antwortgenerierung.

Ein Vektorindex ist eine Suchkomponente, keine Wissensgarantie

Embeddings übersetzen Inhalte in numerische Repräsentationen; Ähnlichkeitssuche findet nahe Vektoren. Das ist leistungsfähig, aber Nähe bedeutet nicht automatisch fachliche Relevanz, Aktualität oder Autorität. Dense Passage Retrieval zeigt, wie dichte Repräsentationen für Passage Retrieval eingesetzt werden können. FAISS zeigt effiziente Ähnlichkeitssuche in großen Vektormengen. Beide lösen nicht die Frage, welche Quelle im eigenen Prozess verbindlich ist.

Deshalb bleiben Metadaten und Regeln notwendig. Ein Treffer kann semantisch sehr ähnlich und trotzdem abgelaufen, unfreigegeben oder für die anfragende Rolle gesperrt sein. Retrieval muss diese Bedingungen berücksichtigen, statt sie nachträglich einem Sprachmodell zu überlassen.

RAG verändert Wissen, ohne ein Modell neu zu trainieren

Ein wichtiger Vorteil ist die Austauschbarkeit des externen Wissensbestands. Dokumente können ergänzt, gesperrt oder neu indexiert werden, ohne das Grundmodell vollständig neu zu trainieren. Das macht Aktualisierung und Provenienz prinzipiell leichter. Es garantiert aber nicht, dass eine Änderung sofort überall wirkt. Caches, Replikate, alte Indizes und verzögerte Pipelines müssen ebenfalls kontrolliert werden.

RAG ist daher besonders sinnvoll, wenn Antworten auf einen definierten, veränderlichen Bestand gestützt werden sollen. Für Aufgaben ohne Wissensbezug oder bei sehr kleinen, stabilen Regeln kann eine einfachere Lösung genügen. Architektur beginnt mit dem Problem, nicht mit dem Wunsch nach einer Vektordatenbank.

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.

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.

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.

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

Reflexion: Welcher Fehler wirkte zunächst wie Halluzination, entstand aber bereits im Retrieval? Bei welcher Frage war Nichtantworten die qualitativ beste Entscheidung?

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. Dieser Artikel beschreibt ein technisches Qualitätsmodell, keine Garantie für einen bestimmten Anbieter oder Einsatzbereich.