RAG-System
Wenn ein Sprachmodell eine Frage beantworten soll, greift es normalerweise nur auf das zurück, was es während des Trainings gelernt hat. Ein RAG-System ändert das: Es sucht zuerst passende Dokumente aus einer Wissensdatenbank und übergibt sie dem Modell als Grundlage für die Antwort. So entsteht eine Antwort, die auf nachprüfbaren Quellen basiert.
Antworten aus echten Dokumenten statt aus dem Gedächtnis
Sprachmodelle speichern Während des Trainings statistische Zusammenhänge zwischen Wörtern. Dieses gespeicherte Wissen hat zwei Schwächen: Es kann veraltet sein, und es lässt sich nicht auf eine konkrete Quelle zurückführen. Ein RAG-System umgeht beide Probleme, indem es vor jeder Antwort gezielt Dokumente abruft und dem Modell als Kontext übergibt.
RAG steht für Retrieval-Augmented Generation. Der Begriff beschreibt eine Architektur, die zwei Teilsysteme verbindet: eine Suchkomponente (Retrieval) und eine Generierungskomponente. Die Suchkomponente findet relevante Textabschnitte. Die Generierungskomponente formuliert daraus eine Antwort.
Beispiel: Ein Versicherungsunternehmen setzt ein RAG-System auf seiner internen Wissensbasis ein. Ein Sachbearbeiter fragt: "Welche Fristen gelten für die Kündigung einer Berufsunfähigkeitsversicherung?" Das System durchsucht die internen Vertragsbedingungen, findet den relevanten Paragraphen und generiert eine Antwort mit Verweis auf die Quelle.
Beispiel: Eine Anwaltskanzlei nutzt ein RAG-System über ihre Mandantenakten. Auf die Frage "Welche Vereinbarungen gelten im Fall Müller vs. Schmidt?" findet das System die relevanten Schriftsätze und fasst die Kernpunkte zusammen.
Der Weg einer Frage durch das System
Jede Anfrage an ein RAG-System durchläuft eine feste Abfolge von Schritten. Diese Pipeline bestimmt, welche Dokumente das Modell sieht und wie es sie verarbeitet.
Im ersten Schritt wird die Nutzerfrage durch ein Embedding-Modell in einen Vektor umgewandelt. Dieser Vektor repräsentiert die Bedeutung der Frage als Zahlenfolge. Im zweiten Schritt vergleicht eine Vektordatenbank diesen Frage-Vektor mit den Vektoren aller gespeicherten Dokumente und gibt die ähnlichsten zurück. Im dritten Schritt werden die gefundenen Dokumente zusammen mit der ursprünglichen Frage zu einem Prompt zusammengesetzt. Im letzten Schritt generiert das Sprachmodell eine Antwort auf Basis dieses erweiterten Kontexts.
Beispiel: Ein IT-Helpdesk setzt ein RAG-System über seine Wissensdatenbank mit 15.000 gelösten Tickets ein. Die Frage "Outlook stürzt beim Start ab" wird als Vektor kodiert, die Vektorsuche findet drei ähnliche Tickets mit Lösungen, und das Sprachmodell formuliert daraus eine Schritt-für-Schritt-Anleitung.
Dokumente in suchbare Einheiten zerlegen
Bevor Dokumente durchsucht werden können, müssen sie in kleinere Abschnitte zerlegt werden. Dieser Vorgang heißt Chunking. Die Größe und der Zuschnitt dieser Abschnitte beeinflussen die Qualität der späteren Suche erheblich.
Zu große Chunks verwischen die Bedeutung: Wenn ein Abschnitt mehrere Themen enthält, ist sein Vektor ein Durchschnitt, der keines der Themen präzise repräsentiert. Zu kleine Chunks verlieren den Zusammenhang: Ein einzelner Satz ohne Kontext kann mehrdeutig sein.
Beispiel: Ein Produktkatalog mit 500 Artikeln. Chunk-Strategie A teilt jeden Artikel in Titel, Beschreibung und technische Daten. Chunk-Strategie B nimmt den gesamten Artikel als einen Chunk. Bei der Frage "Welcher Drucker hat eine Auflösung über 1200 dpi?" findet Strategie A den relevanten Datenabschnitt präziser, weil der Vektor des Technik-Chunks die Spezifikation direkt abbildet.
Beispiel: Ein juristisches Dokumentenarchiv. Ein Chunk, der nur den Satz "Die Frist beträgt sechs Monate" enthält, ist ohne den umgebenden Paragraphen nicht interpretierbar. Hier liefert ein größerer Chunk mit dem gesamten Paragraphen bessere Ergebnisse, weil das Sprachmodell den Geltungsbereich der Frist erkennen kann.
In der Praxis haben sich Chunk-Größen zwischen 200 und 800 Tokens bewährt. Viele Systeme verwenden überlappende Chunks, bei denen der Anfang eines neuen Abschnitts die letzten Sätze des vorherigen wiederholt. Diese Überlappung verringert das Risiko, dass relevante Zusammenhänge an Chunk-Grenzen verloren gehen.
Fachliche Einordnung: Die Wahl der Chunk-Strategie ist domänenabhängig. Strukturierte Dokumente wie Verträge oder technische Handbücher profitieren von semantischem Chunking entlang logischer Abschnitte. Unstrukturierte Texte wie E-Mails oder Chat-Protokolle erfordern häufig ein Sliding-Window-Verfahren. Es gibt keine universell optimale Chunk-Größe.Warum die Suche wichtiger ist als das Sprachmodell
Die Qualität eines RAG-Systems hängt maßgeblich von der Retrieval-Qualität ab. Wenn die Suchkomponente irrelevante Dokumente liefert, kann auch das beste Sprachmodell keine korrekte Antwort daraus ableiten. Das Modell arbeitet ausschließlich mit dem, was es im Prompt sieht.
Zwei Metriken beschreiben die Suchqualität. Precision misst den Anteil relevanter Treffer unter allen zurückgegebenen Dokumenten. Recall misst den Anteil gefundener relevanter Dokumente unter allen relevanten Dokumenten in der Datenbank. Ein System mit hoher Precision, aber niedrigem Recall übersieht wichtige Informationen. Ein System mit hohem Recall, aber niedriger Precision überflutet den Kontext mit irrelevantem Material.
Beispiel: Ein medizinisches Nachschlagesystem erhält die Frage "Wechselwirkungen von Metformin mit ACE-Hemmern". Die Suchkomponente gibt zehn Dokumente zurück. Sieben davon behandeln Metformin-Wechselwirkungen, aber drei beschreiben allgemeine Diabetes-Therapie ohne Bezug zur Frage. Die Precision liegt bei 70 Prozent. Von insgesamt zwanzig relevanten Dokumenten in der Datenbank wurden sieben gefunden, der Recall liegt bei 35 Prozent.
Hybride Suchverfahren kombinieren vektorbasierte Suche mit klassischer Stichwortsuche. Die Vektorsuche findet semantisch ähnliche Dokumente, auch wenn sie andere Begriffe verwenden. Die Stichwortsuche findet exakte Treffer für Fachbegriffe, Produktnummern oder Eigennamen, die in der Vektorrepräsentation untergehen können.
Beispiel: Eine Anfrage nach "Fehlermeldung 0x80070057" in einer IT-Wissensdatenbank. Die Vektorsuche findet allgemeine Artikel zu Windows-Fehlern, weil der Fehlercode als Zahlenfolge keinen eindeutigen semantischen Vektor erzeugt. Die Stichwortsuche findet den exakten Treffer sofort.
Wie der Kontext zusammengesetzt wird
Nachdem die Suchkomponente relevante Dokumente gefunden hat, müssen diese für das Sprachmodell aufbereitet werden. Dieser Schritt entscheidet darüber, wie gut das Modell die Informationen nutzen kann.
Sprachmodelle haben ein begrenztes Kontextfenster. Alle Informationen, die das Modell gleichzeitig verarbeitet, müssen in dieses Fenster passen. Dazu gehören die Systemanweisung, die Nutzerfrage, die abgerufenen Dokumente und der Platz für die generierte Antwort. Je mehr Dokumente eingefügt werden, desto weniger Platz bleibt für die Antwort.
Beispiel: Ein RAG-System mit einem Kontextfenster von 8.000 Tokens. Die Systemanweisung belegt 500 Tokens, die Nutzerfrage 100 Tokens. Für Dokumente und Antwort bleiben 7.400 Tokens. Bei durchschnittlich 400 Tokens pro Chunk passen etwa 15 Chunks in den Kontext, wobei mindestens 1.000 Tokens für die Antwort reserviert werden sollten.
Die Reihenfolge der Dokumente im Prompt beeinflusst die Antwortqualität. Studien zeigen, dass Sprachmodelle Informationen am Anfang und am Ende des Kontexts besser verarbeiten als Informationen in der Mitte. Dieses Phänomen heißt "Lost in the Middle". Relevante Dokumente sollten deshalb nicht ausschließlich in der Mitte des Prompts platziert werden.
Beispiel: Ein Kundendienst-System erhält zehn Dokumente aus der Suche. Der relevanteste Artikel steht an Position sechs. In Tests antwortet das System in 40 Prozent der Fälle unvollständig. Nachdem der relevanteste Artikel an Position eins verschoben wird, sinkt die Fehlerquote auf 15 Prozent.
Architekturvarianten und Erweiterungen
Die beschriebene Grundarchitektur lässt sich auf mehrere Arten erweitern. Jede Variante adressiert eine spezifische Schwäche des Basissystems.
Mehrfache Suchschritte
In manchen Fällen genügt ein einzelner Suchschritt nicht. Multi-Hop-RAG führt mehrere aufeinander aufbauende Suchen durch. Das System nutzt die Ergebnisse der ersten Suche, um die Frage zu präzisieren und erneut zu suchen.
Beispiel: Die Frage "Wie hoch war der Umsatz des größten Kunden im letzten Quartal?" erfordert zwei Suchschritte. Zuerst muss das System den größten Kunden identifizieren. Dann sucht es nach den Umsatzdaten dieses spezifischen Kunden.
Selbstbewertung der Suchergebnisse
Self-RAG-Architekturen lassen das Sprachmodell die Relevanz der gefundenen Dokumente bewerten, bevor die Antwort generiert wird. Das Modell entscheidet, ob die Dokumente die Frage beantworten können, und fordert gegebenenfalls eine neue Suche an.
Beispiel: Ein Rechtsauskunftssystem erhält die Frage "Gilt die DSGVO für Vereine?" Die erste Suche liefert Dokumente über Datenschutz in Unternehmen. Das Modell erkennt, dass keines der Dokumente explizit Vereine behandelt, und löst eine zweite Suche mit dem präzisierten Term "Datenschutz Verein" aus.
Korrektur durch Rückkopplung
Corrective RAG (CRAG) integriert einen zusätzlichen Prüfschritt. Nachdem Dokumente abgerufen wurden, bewertet ein separates Modell deren Relevanz und kann bei niedrigem Vertrauen auf externe Quellen ausweichen.
Beispiel: Ein Unternehmens-Wiki enthält keine Informationen über eine neue gesetzliche Regelung. Das CRAG-System erkennt, dass die gefundenen Dokumente die Frage nicht beantworten, und leitet die Anfrage an eine externe Rechtsdatenbank weiter.
Typische Fehlerquellen und Gegenmaßnahmen
RAG-Systeme bringen spezifische Fehlerquellen mit, die über die Probleme reiner Sprachmodelle hinausgehen.
Veraltete oder widersprüchliche Dokumente
Wenn die Wissensbasis veraltete und aktuelle Versionen desselben Dokuments enthält, kann das System widersprüchliche Informationen im Kontext haben. Das Sprachmodell hat dann keine verlässliche Grundlage für die Antwort.
Beispiel: Ein Personalhandbuch wurde 2024 aktualisiert. Die alte Version mit abweichenden Urlaubsregelungen ist noch in der Wissensbasis. Auf die Frage "Wie viele Urlaubstage stehen mir zu?" findet das System beide Versionen und generiert eine Antwort, die Elemente aus beiden kombiniert.
Fehlende Quellenangaben
Ohne explizite Anweisung generiert das Sprachmodell eine flüssige Antwort, ohne die genutzten Dokumente zu referenzieren. Die Nachprüfbarkeit der Antwort geht dadurch verloren. Lösungsansätze umfassen Prompt-Anweisungen zur Quellenangabe und nachträgliche Zuordnung von Antwortteilen zu Quell-Chunks.
Übermäßiges Vertrauen in den Kontext
Sprachmodelle neigen dazu, Informationen aus dem Kontext als wahr zu behandeln, auch wenn diese fehlerhaft sind. Wenn ein falsches Dokument in den Kontext gelangt, reproduziert das Modell den Fehler mit hoher Wahrscheinlichkeit. Dieses Verhalten verstärkt sich, wenn der Prompt das Modell anweist, ausschließlich auf Basis der bereitgestellten Dokumente zu antworten.
Beispiel: Ein Produktdatenblatt enthält einen Tippfehler in der Gewichtsangabe: 15 kg statt 1,5 kg. Das RAG-System gibt auf die Frage "Wie schwer ist Produkt X?" die fehlerhafte Angabe 15 kg zurück. Der Nutzer vertraut der Antwort, weil sie auf einem offiziellen Dokument basiert.
Fachliche Einordnung: RAG-Systeme verlagern das Problem der Modellgenauigkeit teilweise auf die Datenqualität. Das ist kein Nachteil, sondern ermöglicht eine gezielte Qualitätskontrolle: Fehlende oder fehlerhafte Dokumente lassen sich identifizieren und korrigieren. Die Korrektur von Trainingsdaten eines Sprachmodells ist dagegen ungleich aufwendiger. Allerdings verlangt dieser Ansatz ein systematisches Dokumentenmanagement, das in vielen Organisationen erst aufgebaut werden muss.Grenzen und Einordnung
RAG-Systeme sind kein Ersatz für domänenspezifisches Fine-Tuning. Sie ergänzen ein Sprachmodell um externes Wissen, verändern aber nicht, wie das Modell Sprache versteht oder Schlussfolgerungen zieht. Wenn ein Modell systematisch Schwierigkeiten mit einem bestimmten Aufgabentyp hat, behebt RAG dieses Problem nicht.
Die Latenz eines RAG-Systems ist höher als die eines reinen Sprachmodells. Jede Anfrage erfordert zusätzlich die Vektorsuche, das Laden der Dokumente und den Aufbau des erweiterten Prompts. Bei Echtzeitanwendungen kann diese Verzögerung relevant sein.
Beispiel: Ein Chatbot für Echtzeitberatung in einem Online-Shop. Die reine Sprachmodell-Antwort dauert 800 Millisekunden. Mit RAG kommen 200 bis 600 Millisekunden für die Suche hinzu. Bei Spitzenlasten kann sich die Gesamtantwortzeit auf über zwei Sekunden erhöhen.
Die Skalierung der Wissensbasis bringt eigene Herausforderungen. Mit wachsender Dokumentenmenge steigt die Wahrscheinlichkeit von Fehltreffern. Die Pflege der Indizes, die Aktualisierung von Embeddings bei Modellwechseln und die Versionierung der Dokumente erfordern operative Prozesse, die über den Betrieb des Sprachmodells hinausgehen.
RAG eignet sich am besten für Anwendungsfälle, in denen die Antwort auf nachprüfbare Fakten aus einer definierten Dokumentenmenge basieren soll. Für kreative Aufgaben, Zusammenfassungen über sehr große Dokumentmengen oder Aufgaben, die tiefes Sprachverständnis erfordern, ist RAG allein nicht ausreichend.
Fachliche Einordnung: Die Grenze zwischen RAG und Fine-Tuning verschwimmt in der Praxis. Einige Architekturen kombinieren beide Ansätze: ein feinabgestimmtes Modell für die domänenspezifische Sprachverarbeitung, ergänzt durch RAG für den Zugriff auf aktuelle Fakten. Die Forschung zu "Retrieval-Augmented Fine-Tuning" (RAFT) untersucht diese Kombination systematisch. Stand 2026 gibt es keinen Konsens darüber, welche Aufgabentypen von welcher Kombination am meisten profitieren.