RAG, Retrieval-Augmented Generation, ist ein Muster, bei dem relevante Dokumente aus einem externen Speicher abgerufen und einem Sprachmodell vor der Antwortgenerierung als Kontext übergeben werden. Das Modell antwortet auf Basis der abgerufenen Inhalte, nicht nur auf Basis des Trainingswissens.
Warum es existiert
Sprachmodelle haben einen festen Wissensstand und kennen keine privaten Daten. Ein Modell, das auf öffentlichen Texten trainiert wurde, kann keine Fragen zu Ihrer internen Dokumentation, aktuellen Ereignissen oder proprietären Daten beantworten, sofern diese Informationen nicht zum Zeitpunkt der Inferenz bereitgestellt werden. RAG ist der Standardweg, um dies zu ermöglichen.
Die Alternative, Fine-Tuning, verankert Wissen in den Modellgewichten. Das ist kostspielig, langsam zu aktualisieren und schlecht geeignet für Informationen, die sich häufig ändern. RAG trennt den Wissensspeicher und das Modell voneinander, sodass Dokumente aktualisiert werden können, ohne das Modell anzupassen.
So funktioniert es
Auf hoher Ebene umfasst eine RAG-Pipeline drei Phasen:
- Indexierung. Quelldokumente werden in Abschnitte aufgeteilt, in Vektoreinbettungen umgewandelt und in einer Vektordatenbank gespeichert. Metadaten werden häufig zusammen mit den Vektoren gespeichert, um die Filterung zu unterstützen.
- Abruf. Wenn eine Anfrage eingeht, wird diese ebenfalls eingebettet. Das System durchsucht den Vektorspeicher nach Abschnitten, deren Einbettungen der Anfrageeinbettung nahekommen, typischerweise mittels Kosinusähnlichkeit oder Skalarprodukt. Einige Pipelines ergänzen einen Reranking-Schritt zur Verbesserung der Präzision.
- Generierung. Die abgerufenen Chunks werden als Kontext in den Prompt eingefügt. Das Sprachmodell liest sowohl die Anfrage als auch den abgerufenen Text und generiert eine Antwort, die auf diesem Material basiert.
Dies wird manchmal als Kontextfenster als Arbeitsfläche bezeichnet: Sie befüllen das Kontextfenster des Modells mit abgerufenen Fakten, anstatt sich auf das parametrische Gedächtnis zu verlassen.
Mögliche Fehlerquellen
RAG ist keine automatische Garantie für Genauigkeit. Mehrere Fehlerquellen treten häufig auf.
Fehlschlagende Abfragen. Wenn der relevante Chunk nicht abgerufen wird, halluziniert das Modell oder gibt an, dass es die Information nicht kennt. Chunk-Größe, Wahl des Embedding-Modells und die Formulierung der Anfrage wirken sich alle auf den Abruf aus.
Kontext-Vergiftung. Abgerufener Text, der veraltet, widersprüchlich oder themenfern ist, kann das Modell in die Irre führen, selbst wenn der Abrufschritt technisch erfolgreich war.
Prompt Injection. Schädliche Inhalte, die in einem abgerufenen Dokument eingebettet sind, können versuchen, das Verhalten des Modells umzuleiten. Dies ist ein reales Risiko, wenn das Dokumentenkorpus nicht vollständig kontrolliert wird. Weitere Details finden Sie unter Was ist Prompt Injection.
Attributionsfehler. Modelle vermischen abgerufene Inhalte manchmal mit Trainingswissen auf eine Weise, die schwer nachzuvollziehen ist. Aussagen auf Quell-Chunks zurückzuführen ist eine gute Praxis, erfordert jedoch ein bewusstes Pipeline-Design.
Einordnung von RAG in ein übergeordnetes System
RAG ist häufig eine Komponente innerhalb einer größeren Architektur. Ein MCP-Server kann den Abruf als Tool bereitstellen, das ein Agent dynamisch aufruft, anstatt bei jeder Anfrage abzurufen. Agentic-Coding-Umgebungen nutzen RAG manchmal, um Codebasis-Kontext einzubinden, der nicht in einen einzelnen Prompt passt.
Evaluierung spielt hier eine wichtige Rolle. Eine RAG-Pipeline muss in drei getrennten Bereichen getestet werden: Abrufqualität, Antworttreue und Antwortrelevanz. Eine einzige aggregierte Kennzahl verschleiert, welche Komponente versagt. Informationen zur Evaluierungsgestaltung finden Sie unter Was ist ein Eval.
Was wir prüfen
Entwickler, die mit RAG-Pipelines arbeiten, müssen klar einschätzen können, wo ein Fehler entsteht: im Retrieval-Schritt, im an das Modell übergebenen Kontext oder in der Verwendung dieser Informationen durch das Modell. Unsere Eignungsprüfung bewertet dies direkt. In der AI-native Session werden Kandidaten nach den Kriterien Verifikation von KI-Ausgaben und KI-beschleunigtes Debugging bewertet – beides zeigt, ob jemand die gesamte Pipeline versteht oder sie als Black Box behandelt. Der vollständige Ansatz ist unter „Wie wir prüfen“ beschrieben.
Kurze Antworten
Was ist der Unterschied zwischen RAG und Fine-Tuning?
Fine-Tuning bettet Wissen in die Modellgewichte ein und erfordert ein erneutes Training für Aktualisierungen. RAG ruft Wissen zur Inferenzzeit aus einem externen Speicher ab, was es einfacher macht, aktuelle Informationen bereitzustellen, und es besser für private oder häufig wechselnde Informationen geeignet macht.
Beseitigt RAG Halluzinationen?
Nein. RAG reduziert Halluzinationen, indem Antworten auf abgerufenen Texten basieren, aber das Modell kann diesen Text dennoch falsch lesen, vermischen oder ignorieren. Fehlschlagende Abrufe lassen das Modell ohne den benötigten Kontext, was zu selbstsicheren, aber falschen Antworten führen kann.
Welche Art von Datenbank verwendet RAG?
Die meisten RAG-Pipelines verwenden eine Vektordatenbank, um Dokument-Embeddings zu speichern und per Ähnlichkeitssuche zu durchsuchen. Einige Implementierungen ergänzen dies um relationale Metadatenspeicher oder Schlüsselwortsuche neben der Vektorsuche, um die Abrufgenauigkeit zu verbessern.
