Retrieval Augmented Generation

Retrieval Augmented Generation (RAG) ist ein Architekturmuster für KI-Anwendungen, bei dem ein Large Language Model (LLM) vor der Antwortgenerierung gezielt mit passenden Informationen aus einer externen Wissensquelle versorgt wird. Statt sich allein auf das im Training eingefrorene Wissen des Modells zu verlassen, sucht das System zu jeder Anfrage die relevanten Dokumente heraus (Retrieval), reicht sie dem Modell als Kontext mit (Augmentation) und lässt es erst dann die Antwort formulieren (Generation). Das Ergebnis: Antworten, die auf aktuellen, überprüfbaren und unternehmenseigenen Daten beruhen, statt auf dem, was das Modell irgendwann einmal gelernt hat.

Der Begriff geht auf ein Forschungspapier von Patrick Lewis und Kollegen aus dem Jahr 2020 zurück („Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", Meta AI). Was damals eine akademische Idee war, ist heute das Standardmuster, mit dem Unternehmen ihre eigenen Daten sicher und aktuell in KI-Anwendungen einbinden — vom internen Wissensassistenten bis zum Kundenservice-Chatbot.

Welches Problem löst RAG?

Sprachmodelle haben drei strukturelle Schwächen, die im Unternehmenseinsatz schnell teuer werden. Erstens: Ihr Wissen endet am Trainingsstichtag — was danach passiert ist, kennt das Modell nicht. Zweitens: Sie kennen keine internen Daten. Preislisten, Verträge, Produktdokumentation oder Support-Historie eines Unternehmens waren nie Teil des Trainings. Drittens: Wenn ihnen Wissen fehlt, erfinden sie plausibel klingende Antworten — das bekannte Halluzinationsproblem.

RAG adressiert alle drei Punkte mit demselben Mechanismus: Das Modell muss die Antwort nicht wissen, es muss sie nur aus den mitgelieferten Quellen zusammensetzen. Die Wissensbasis lässt sich jederzeit aktualisieren, ohne das Modell neu zu trainieren. Interne Dokumente bleiben in der eigenen Infrastruktur und werden nur als Kontext an das Modell gereicht. Und weil die Antwort auf konkreten Textstellen basiert, kann das System seine Quellen zitieren — was Halluzinationen zwar nicht vollständig eliminiert, aber deutlich reduziert und vor allem überprüfbar macht.

Wie funktioniert RAG?

Eine RAG-Anwendung besteht aus zwei Phasen: der Vorbereitung der Wissensbasis (Indexierung) und der Beantwortung einer Anfrage (Abruf und Generierung).

Phase 1: Die Wissensbasis aufbauen

Zunächst werden die Quelldokumente — PDFs, Wiki-Seiten, Produktdaten, Support-Tickets — in handhabbare Abschnitte zerlegt, sogenannte Chunks. Jeder Chunk wird durch ein Embedding-Modell in einen Zahlenvektor übersetzt, der seine inhaltliche Bedeutung repräsentiert. Diese Vektoren landen in einer Vektordatenbank, die semantische Ähnlichkeitssuche in Millisekunden beherrscht. Inhaltlich verwandte Texte liegen in diesem Vektorraum nah beieinander — auch wenn sie kein einziges gemeinsames Wort enthalten.

Phase 2: Anfrage, Abruf, Antwort

Stellt ein Nutzer eine Frage, durchläuft sie denselben Weg: Die Frage wird in einen Vektor übersetzt, die Vektordatenbank liefert die inhaltlich ähnlichsten Chunks zurück, und diese Fundstellen werden zusammen mit der ursprünglichen Frage in den Prompt des Sprachmodells eingebettet — hier fließen die Disziplinen RAG und Prompt Engineering zusammen. Das Modell formuliert die Antwort ausschließlich auf Basis des mitgelieferten Kontexts, idealerweise mit Quellenangabe. Moderne Systeme ergänzen diesen Kern um weitere Stufen: hybride Suche (Vektor- plus Stichwortsuche), Re-Ranking der Treffer und Filterung nach Zugriffsrechten.

RAG, Fine-Tuning oder großes Kontextfenster?

RAG ist nicht der einzige Weg, einem Modell zusätzliches Wissen beizubringen. Die drei gängigen Ansätze lösen aber unterschiedliche Probleme:

In der Praxis schließen sich die Ansätze nicht aus: Ein feingetuntes Modell kann in einer RAG-Architektur laufen, und für kleine Wissensmengen ist das große Kontextfenster oft die einfachste Lösung. Als Faustregel gilt: Geht es um Faktenwissen, das sich ändert, ist RAG der richtige Hebel. Geht es um Verhalten des Modells, ist Fine-Tuning der richtige.

Realbeispiel: Support-Assistent im E-Commerce

Ein mittelständischer Onlinehändler mit rund 40.000 Artikeln möchte seinen Kundenservice entlasten. Ein klassischer Chatbot scheitert dort regelmäßig: Fragen wie „Passt das Ersatzteil X an Modell Y von 2019?" lassen sich nicht mit vorformulierten Antworten abdecken, und ein reines Sprachmodell würde mangels Produktwissen raten.

Die RAG-Lösung: Produktdatenblätter, Kompatibilitätslisten, Versand- und Retourenrichtlinien sowie die häufigsten gelösten Support-Tickets werden in Chunks zerlegt, eingebettet und indexiert. Fragt ein Kunde nach der Kompatibilität, findet das Retrieval die passende Kompatibilitätsliste und das zugehörige Datenblatt, und das Modell formuliert daraus eine konkrete, belegbare Antwort — inklusive Link auf die Quelle. Ändert sich eine Retourenfrist, wird nur das betreffende Dokument neu indexiert; fünf Minuten später antwortet der Assistent korrekt. Kein Nachtraining, keine Codeänderung. Genau diese Eigenschaft macht RAG für den Mittelstand attraktiv: Die Wissenspflege bleibt dort, wo sie heute schon stattfindet — in den Dokumenten.

Typische Stolperfallen in RAG-Projekten

So elegant das Muster ist, so viele Projekte bleiben hinter den Erwartungen zurück. Die häufigsten Ursachen liegen fast nie im Sprachmodell, sondern in der Datenaufbereitung und im Retrieval:

• Schlechte Chunking-Strategie: Werden Dokumente stumpf alle 500 Zeichen zerschnitten, reißen Tabellen, Aufzählungen und Sinnzusammenhänge auseinander. Das Retrieval findet dann Fragmente, mit denen das Modell nichts anfangen kann.
• Veraltete oder widersprüchliche Quellen: RAG macht die Wissensbasis zur einzigen Wahrheit. Liegen dort drei Versionen derselben Preisliste, zitiert das System irgendwann die falsche. Datenhygiene ist kein Vorprojekt, sondern Teil des Betriebs.
• Fehlende Rechteprüfung: Das Retrieval muss Zugriffsrechte respektieren. Ein Assistent, der Gehaltslisten an jeden ausliefert, der geschickt fragt, ist ein Datenschutzvorfall mit Ansage.
• Kein Umgang mit „nicht gefunden": Liefert das Retrieval nichts Brauchbares, muss das System das sagen — statt das Modell frei fantasieren zu lassen. Ein ehrliches „dazu liegt mir nichts vor" ist der halbe Wert einer RAG-Anwendung.
• Fehlende Evaluation: Ohne ein Testset aus realen Fragen mit erwarteten Antworten lässt sich nicht messen, ob eine Änderung an Chunking, Embedding-Modell oder Prompt die Qualität verbessert oder verschlechtert.

Datenschutz und DSGVO: warum RAG im Mittelstand punktet

Ein oft unterschätzter Vorteil von RAG liegt im Datenschutz. Beim Fine-Tuning wandern Unternehmensdaten dauerhaft in die Gewichte eines Modells — was einmal eintrainiert ist, lässt sich weder gezielt löschen noch auskunftsfähig machen. Bei RAG bleiben die Dokumente dagegen in einer normalen Datenbank unter eigener Kontrolle. Löschpflichten nach Art. 17 DSGVO lassen sich erfüllen, indem das betreffende Dokument aus dem Index entfernt wird; Auskunftsersuchen lassen sich beantworten, weil nachvollziehbar ist, welche Quellen gespeichert sind. An das Sprachmodell gehen Inhalte nur anfragebezogen als Kontext — bei einem EU-gehosteten Anbieter mit Auftragsverarbeitungsvertrag oder einem selbst gehosteten Modell ist damit ein sauberer, dokumentierbarer Datenfluss möglich. Für Unternehmen mit sensiblen Beständen ist genau diese Trennung von Wissen und Modell häufig das entscheidende Argument für RAG.

Varianten: von Naive RAG bis GraphRAG

Unter dem Oberbegriff haben sich mehrere Ausbaustufen etabliert. Naive RAG bezeichnet die Grundform: einbetten, suchen, antworten — schnell gebaut, aber anfällig für schwache Treffer. Advanced RAG ergänzt Optimierungen vor und nach dem Abruf: Anfragen werden umformuliert oder in Teilfragen zerlegt (Query Rewriting), Treffer durch ein Re-Ranking-Modell neu sortiert und Metadaten-Filter (Datum, Abteilung, Sprache) angewendet. GraphRAG verbindet die Vektorsuche mit einem Wissensgraphen, der Beziehungen zwischen Entitäten abbildet — nützlich, wenn Antworten Zusammenhänge über viele Dokumente hinweg erfordern, etwa „welche Kunden sind von der Änderung an Produkt X betroffen?". Für die meisten Mittelstandsprojekte ist Advanced RAG der realistische Zielzustand; GraphRAG lohnt erst bei komplex vernetzten Datenbeständen.

RAG und KI-Agenten

In modernen Architekturen ist RAG selten ein Einzelsystem, sondern ein Baustein: KI-Agenten nutzen Retrieval als eines von mehreren Werkzeugen. Statt dass jede Anfrage stur denselben Abruf-Pfad durchläuft, entscheidet der Agent selbst, ob und welche Wissensquelle er befragt — man spricht dann von Agentic RAG. Der Agent kann eine Suche mehrfach mit umformulierten Anfragen wiederholen, Ergebnisse aus verschiedenen Quellen kombinieren und bei Widersprüchen nachrecherchieren. Damit wandert die Retrieval-Logik vom starren Pipeline-Design in die Planungsschleife des Agenten — mit allen Chancen und Kontrollanforderungen, die Agentensysteme mit sich bringen.

Wie viel Aufbau-Aufwand realistisch ist, hängt fast vollständig vom Zustand der Quelldaten ab. Ein sauber gepflegtes Confluence-Wiki oder strukturierte Produktdaten lassen sich in wenigen Tagen indexieren. Ein historisch gewachsener Ablageordner mit gescannten PDFs, Duplikaten und veralteten Versionen braucht dagegen zuerst eine Bereinigungsrunde — und genau dort entscheidet sich, ob die spätere Anwendung vertrauenswürdige oder zufällige Antworten liefert. Eine ehrliche Ist-Aufnahme der Datenlage gehört deshalb an den Anfang jedes RAG-Projekts, nicht an dessen Ende.

Fazit

Retrieval Augmented Generation ist der pragmatischste Weg, Sprachmodelle mit aktuellem und unternehmenseigenem Wissen zu verbinden: aktualisierbar ohne Nachtraining, zitierfähig, datenschutzfreundlich, weil die Dokumente in der eigenen Infrastruktur bleiben. Der Erfolg entscheidet sich dabei weniger an der Modellwahl als an handwerklichen Fragen — Datenqualität, Chunking, Rechtekonzept und Evaluation. Wer diese Grundlagen sauber baut, bekommt mit RAG den Baustein, der aus einem generischen Sprachmodell einen Assistenten mit echtem Firmenwissen macht — eine Kernaufgabe jeder fundierten KI-Beratung.

Häufige Fragen zu Retrieval Augmented Generation

Verhindert RAG Halluzinationen vollständig?

Nein, aber es reduziert sie deutlich und macht sie überprüfbar. Das Modell kann mitgelieferte Quellen falsch zusammenfassen oder trotz Kontext eigenes „Wissen" einmischen. Quellenzitate, ein striktes „nur aus dem Kontext antworten" im Prompt und ein definiertes Verhalten bei fehlenden Treffern sind deshalb Pflicht.

Braucht jedes RAG-System eine Vektordatenbank?

Für semantische Suche ist eine Vektordatenbank der Standard, aber kein Dogma. Kleine Bestände funktionieren auch mit klassischer Volltextsuche oder einer Kombination aus beidem (hybride Suche). Entscheidend ist, dass das Retrieval die tatsächlich relevanten Passagen findet — mit welcher Technik, ist zweitrangig.

Was kostet der Betrieb einer RAG-Anwendung?

Die laufenden Kosten setzen sich aus Embedding- und LLM-API-Aufrufen (oder eigener Modell-Infrastruktur), dem Betrieb der Vektordatenbank und der Datenpflege zusammen. Für typische Mittelstands-Szenarien liegen die reinen Modellkosten pro Anfrage im Cent-Bereich; der größere Posten ist erfahrungsgemäß die initiale Datenaufbereitung. Eine erfahrene KI-Agentur hilft, genau diesen Aufwand realistisch einzuschätzen und die passende RAG-Architektur zu wählen.