Was ist Retrieval-Augmented Generation (RAG)?

Lesedauer: ca. 12 Minuten

Retrieval-Augmented Generation, kurz RAG, ist eine Architektur, die ein Large Language Model (LLM) zur Laufzeit mit externen Wissensquellen verbindet. Statt sich nur auf das im Training gespeicherte Wissen zu verlassen, ruft das System bei jeder Anfrage relevante Dokumente aus einer angebundenen Datenbank ab und speist sie als Kontext in das LLM ein. Das LLM formuliert auf dieser Grundlage eine Antwort, die faktentreu, aktuell und auf die konkrete Wissensbasis des Unternehmens zugeschnitten ist.

Warum ist das relevant? Generative KI Modelle werden auf großen, statischen Datensätzen trainiert. Diese Trainingsdaten sind zum Zeitpunkt der Nutzung oft Monate oder Jahre alt und enthalten in der Regel keine unternehmensinternen Informationen. RAG überbrückt diese Lücke, ohne das zugrunde liegende Modell zu verändern. Das macht RAG zu einer vergleichsweise schnellen und kostengünstigen Methode, ein allgemeines Sprachmodell an domänenspezifische Anforderungen anzupassen.

In diesem Artikel erfahren Sie:

• Was RAG ist und woher der Begriff kommt
• Wie RAG technisch funktioniert
• Welche typischen Anwendungsfälle RAG abdeckt
• Welche Vorteile und Herausforderungen die Architektur mit sich bringt
• Wie sich RAG von der Feinabstimmung (Fine Tuning) und anderen Ansätzen unterscheidet
• Wohin sich RAG entwickelt

Woher kommt RAG?

Die Idee, ein generatives Modell zur Laufzeit mit zusätzlichem Wissen zu versorgen, ist nicht neu. Schon vor dem Durchbruch der großen Sprachmodelle gab es Systeme, die Dokumente aus einer Datenbank abriefen, um anschließend daraus eine Antwort zu formulieren.

Der Begriff Retrieval-Augmented Generation wurde 2020 in dem Paper „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” von Patrick Lewis und einem Team von Facebook AI Research geprägt. Das Paper zeigte, dass sich die Genauigkeit generativer Modelle deutlich verbessern lässt, wenn man ihnen erlaubt, vor der Generierung gezielt auf eine externe Wissensquelle zuzugreifen. Seither hat sich RAG zu einem Standardverfahren entwickelt, das in zahlreichen Enterprise Produkten und Frameworks zum Einsatz kommt.

Die Grundannahme ist einfach. Ein LLM verfügt über ein breites, aber generalisiertes Weltwissen. RAG ergänzt dieses Wissen gezielt um domänenspezifische Inhalte, die das Modell allein nicht hätte. Dadurch entstehen Antworten, die sowohl sprachlich flüssig als auch inhaltlich korrekt sind.

Was genau ist Retrieval-Augmented Generation?

RAG ist eine KI Architektur, die zwei Techniken kombiniert. Zunächst ruft ein Retrieval Modul relevante Informationen aus einer externen Wissensquelle ab. Anschließend nutzt ein generatives Modell diese Informationen als zusätzlichen Kontext, um eine Antwort zu formulieren.

Die externe Wissensquelle kann dabei sehr unterschiedlich aussehen. Typisch sind Vektordatenbanken, die unstrukturierte Dokumente wie PDFs, Wikis, Confluence Seiten, SharePoint Inhalte, CRM Einträge oder Vertragsdatenbanken enthalten. Möglich sind aber auch strukturierte Quellen, etwa über Datenbankabfragen oder API Anbindungen.

Der wesentliche Unterschied zu einem klassischen Chatbot ist die Verbindung zwischen LLM und aktuellem Unternehmenswissen. Wo ein gewöhnliches LLM auf sein Trainingswissen beschränkt ist, bezieht RAG zur Antwortzeit aktuelle, spezifische Informationen aus der angebundenen Wissensbasis.

Zentrale Eigenschaften von RAG:

• Aktualität. Inhalte in der Wissensbasis können kontinuierlich aktualisiert werden, ohne dass das LLM neu trainiert werden muss.
• Domänenspezifische Relevanz. Das System antwortet auf Basis der eigenen Unternehmensdokumente und nicht auf Basis allgemeiner Trainingsdaten.
• Nachvollziehbarkeit. Jede Antwort lässt sich auf eine konkrete Quelle zurückführen.
• Datenschutz. Die sensiblen Unternehmensdaten verbleiben in der kontrollierten Umgebung und werden nicht zum Training öffentlicher Modelle verwendet.
• Skalierbarkeit. RAG funktioniert sowohl mit kleinen Wissensbasen als auch mit Millionen von Dokumenten.

Wie funktioniert RAG?

Ein RAG System folgt einem mehrstufigen Prozess. Die folgende Darstellung orientiert sich an dem verbreiteten Fünf Schritte Modell, das auch IBM in seiner technischen Dokumentation verwendet.

Schritt 1: Wissensbasis aufbauen

Der erste Schritt besteht darin, die relevanten Unternehmensdokumente in eine Form zu bringen, die das System durchsuchen kann. Dafür werden die Dokumente in kleinere Einheiten, sogenannte Chunks, zerlegt. Ein Chunk kann ein Absatz, ein Abschnitt oder eine semantisch zusammenhängende Textpassage sein.

Die Chunk Größe ist ein wichtiger Stellhebel. Zu kleine Chunks verlieren den semantischen Zusammenhang, zu große Chunks verwässern die Treffergenauigkeit. In der Praxis haben sich Werte zwischen 500 und 1.500 Token bewährt.

Schritt 2: Embeddings erzeugen

Jeder Chunk wird durch ein Embedding Modell in einen numerischen Vektor umgewandelt. Ein Embedding ist eine dichte Zahlenreihe, die die semantische Bedeutung des Textes in einem mehrdimensionalen Raum abbildet. Texte mit ähnlicher Bedeutung liegen in diesem Vektorraum nahe beieinander.

Gängige Embedding Modelle sind OpenAI text-embedding-3, Cohere Embed v3, BGE M3 von BAAI oder spezialisierte mehrsprachige Modelle. Die Wahl hängt von der Sprache, der gewünschten Domäne und den Anforderungen an Datenschutz ab.

Schritt 3: Vektordatenbank befüllen

Die erzeugten Vektoren werden in einer Vektordatenbank gespeichert. Häufig eingesetzte Lösungen sind Pinecone, Weaviate, Milvus, Qdrant oder pgvector als Erweiterung von PostgreSQL. Die Vektordatenbank indiziert die Vektoren so, dass ähnliche Vektoren schnell gefunden werden können.

Schritt 4: Anfrage verarbeiten

Wenn ein Nutzer eine Frage stellt, wird diese ebenfalls in einen Vektor umgewandelt. Das System durchsucht die Vektordatenbank nach den Vektoren, die der Anfrage am ähnlichsten sind. Das Ergebnis ist eine Liste der relevantesten Chunks.

Optional kann die Trefferliste durch einen Re Ranker (zum Beispiel Cohere Rerank) nachsortiert werden, um die Qualität weiter zu verbessern. Auch eine klassische Stichwortsuche (BM25) lässt sich parallel zur Vektorsuche einsetzen. Diese Kombination wird als Hybrid Search bezeichnet.

Schritt 5: Antwort generieren

Die gefundenen Chunks werden zusammen mit der ursprünglichen Frage als Prompt an das LLM übergeben. Das LLM formuliert auf dieser Grundlage eine Antwort und verweist idealerweise auf die zugrunde liegenden Quellen.

Ablauf eines RAG Systems in fünf Schritten

Schritt	Was passiert	Beteiligte Komponente
1	Dokumente in Chunks zerlegen	Dokumentenverarbeitung
2	Chunks in Vektoren umwandeln	Embedding Modell
3	Vektoren speichern und indizieren	Vektordatenbank
4	Frage in Vektor umwandeln, ähnliche Chunks finden	Retriever
5	Antwort mit Quellenangabe formulieren	Generator (LLM)

Typische Anwendungsfälle für RAG

RAG eignet sich besonders für Anwendungen, bei denen ein LLM auf aktuelle, spezifische oder unternehmenseigene Informationen zugreifen muss. Die folgende Aufstellung orientiert sich an verbreiteten Einsatzmustern.

Internes Wissensmanagement

Anwendungsfall: Mitarbeiter suchen Antworten auf Fragen zu internen Prozessen, Richtlinien oder Projekten.
Beispiel: Ein Unternehmen betreibt ein RAG System, das mit Confluence Seiten, SharePoint Dokumenten und dem Intranet verbunden ist. Mitarbeiter stellen Fragen in natürlicher Sprache und erhalten Antworten mit direktem Verweis auf die Originaldokumente.

Kundenservice und Support

Anwendungsfall: Kundenanfragen werden automatisiert beantwortet, ohne dass ein Mensch jedes Ticket bearbeiten muss.
Beispiel: Ein Softwarehersteller bindet sein Handbuch, die FAQ Datenbank und bekannte Fehlerbeschreibungen in ein RAG System ein. Der Support Chatbot beantwortet Standardfragen sofort und erkennt komplexe Anliegen, die an einen Mitarbeiter weitergeleitet werden.

Recherche und Wissensaufbereitung

Anwendungsfall: Fachkräfte müssen große Mengen an Dokumenten sichten und die relevantesten Informationen extrahieren.
Beispiel: Eine Rechtsabteilung verwendet RAG, um Vertragsdokumente zu durchsuchen und Klauseln zu identifizieren, die einem bestimmten Muster entsprechen. Das System extrahiert die relevanten Passagen und verweist auf die Originalstellen.

Vertriebs und Marketingunterstützung

Anwendungsfall: Vertriebsmitarbeiter benötigen schnellen Zugriff auf Produktinformationen, Wettbewerbsanalysen und Angebotsvorlagen.
Beispiel: Ein RAG System im CRM greift auf das Produktkatalog, die Marketingmaterialien und vergangene Angebote zu. Ein Vertriebsmitarbeiter fragt nach den wichtigsten Alleinstellungsmerkmalen eines Produkts und erhält eine konsolidierte Antwort mit Quellen.

Forschung und Entwicklung

Anwendungsfall: Wissenschaftler und Ingenieure suchen nach relevanten Veröffentlichungen, internen Forschungsberichten oder Patentrecherchen.
Beispiel: Ein F&E Team nutzt RAG, um interne Versuchsberichte, Patentschriften und Fachpublikationen zu durchsuchen. Das System identifiziert relevante Querverbindungen und liefert Zusammenfassungen.

Personalwesen und Onboarding

Anwendungsfall: Neue Mitarbeiter stellen wiederkehrende Fragen zu Urlaubsregelungen, Benefits oder internen Tools.
Beispiel: Ein HR Chatbot beantwortet Fragen zu Betriebsvereinbarungen, Versicherungsleistungen oder internen Prozessen rund um die Uhr und entlastet die Personalabteilung.

Vorteile von RAG

Die folgenden Vorteile ergeben sich aus der Architektur und werden in der Fachliteratur, unter anderem in den Dokumentationen von IBM, Microsoft und Oracle, übereinstimmend beschrieben.

• Aktualität: Inhalte in der Wissensbasis können ohne erneutes Training des Modells aktualisiert werden. Dadurch bleiben die Antworten konsistent mit dem aktuellen Wissensstand des Unternehmens.
• Kosteneffizienz: Die Feinabstimmung oder das erneute Training eines großen Sprachmodells ist rechenintensiv und teuer. RAG nutzt das bestehende Modell und ergänzt es lediglich um eine externe Wissensquelle.
• Quellentransparenz: Jede Antwort kann mit einem Verweis auf die zugrunde liegenden Dokumente versehen werden. Das erleichtert die Prüfung und das Vertrauen.
• Domänenspezifische Relevanz: Das System antwortet auf Basis der eigenen Unternehmensdaten und nicht auf Basis generischer Trainingsinhalte.
• Datenschutz: Die sensiblen Daten verbleiben in der eigenen Infrastruktur oder in einer kontrollierten Cloud Umgebung. Sie werden nicht zum Training öffentlicher Modelle verwendet.
• Skalierbarkeit: RAG funktioniert mit kleinen Dokumentensammlungen ebenso wie mit Millionen von Dokumenten, sofern die Vektordatenbank entsprechend dimensioniert ist.
• Entwicklerkontrolle: Entwickler können die Wissensbasis und die Retrieval Logik jederzeit anpassen, ohne das LLM zu verändern.

Herausforderungen von RAG

Trotz der genannten Vorteile bringt RAG auch Herausforderungen mit sich, die in der Praxis adressiert werden müssen.

• Datenqualität: Das System ist nur so gut wie die Dokumente, auf die es zugreift. Veraltete, widersprüchliche oder schlecht strukturierte Inhalte führen zu minderwertigen Antworten.
• Chunking Strategie: Die Wahl der richtigen Chunk Größe und der Schnittlogik hat großen Einfluss auf die Trefferqualität. Es gibt keine universelle Einstellung, die für alle Anwendungsfälle funktioniert.
• Berechtigungen und Zugriffskontrolle: RAG macht Wissen auffindbar, aber nicht automatisch berechtigt. Wenn das System Zugriff auf vertrauliche Dokumente hat, müssen Filtermechanismen sicherstellen, dass nur berechtigte Nutzer diese Inhalte abrufen können.
• Halluzinationen: RAG reduziert das Risiko von Halluzinationen, eliminiert es aber nicht. Wenn das LLM die abgerufenen Informationen falsch interpretiert oder extrapoliert, können weiterhin ungenaue Antworten entstehen.
• Latenz: Die zusätzliche Retrieval Komponente erhöht die Antwortzeit im Vergleich zu einer reinen LLM Abfrage. In zeitkritischen Anwendungen muss die Architektur auf geringe Latenz optimiert werden.
• Evaluierung: Die Qualität eines RAG Systems zu messen ist komplex. Es braucht Metriken für die Retrieval Qualität, die Antworttreue und die inhaltliche Korrektheit.
• Wartung der Wissensbasis: Die Vektordatenbank muss kontinuierlich aktualisiert werden, wenn sich Inhalte ändern. Ein veralteter Index führt zu veralteten Antworten.

RAG im Vergleich zu anderen Ansätzen

RAG ist nicht der einzige Weg, ein LLM an einen bestimmten Anwendungsfall anzupassen. Die wichtigsten Alternativen sind das Fine Tuning und der Einsatz von Long Context Modellen.

RAG und Fine Tuning

Fine Tuning bedeutet, ein vortrainiertes Modell mit zusätzlichen, domänenspezifischen Daten weiter zu trainieren. Dadurch verändert das Modell seine Parameter und passt sein Verhalten an die neue Domäne an. RAG hingegen verändert die Modellparameter nicht. Es versorgt das Modell zur Laufzeit mit zusätzlichem Kontext aus einer externen Wissensquelle.

Beide Ansätze verfolgen ähnliche Ziele, unterscheiden sich jedoch in Aufwand, Kosten und Flexibilität. Fine Tuning ist rechenintensiv und erfordert spezialisiertes Know how. Die Anpassung an neue Inhalte erfordert ein erneutes Training. RAG ist flexibler, weil neue Inhalte einfach in die Wissensbasis aufgenommen werden, ohne das Modell zu verändern.

In der Praxis werden beide Ansätze häufig kombiniert. Fine Tuning kann das Modell für einen bestimmten Sprachstil oder eine bestimmte Terminologie optimieren, während RAG die aktuelle Faktenbasis liefert.

Vergleich von RAG und Fine Tuning

Kriterium	RAG	Fine Tuning
Wissensbasis	Externe Datenbank	Im Modell gespeichert
Aktualisierung	Neue Dokumente einlesen	Erneutes Training
Kosten	Gering bis mittel	Hoch
Datenschutz	Hoch, Daten bleiben extern	Mittel, Training sensible Daten
Anpassung an Stil	Begrenzt	Möglich
Eignung	Faktentreue Antworten	Spezifischer Sprachstil

RAG und semantische Suche

RAG nutzt semantische Suche als eine zentrale Komponente, ist aber nicht darauf beschränkt. Eine semantische Suche liefert dem Nutzer eine Liste relevanter Dokumente, die er selbst sichten muss. RAG geht einen Schritt weiter und formuliert auf Basis der gefundenen Dokumente eine direkt nutzbare Antwort.

RAG und Long Context Modelle

Neuere Modelle unterstützen Kontextfenster von einer Million Token und mehr. Dadurch lässt sich eine große Menge an Dokumenten direkt in den Prompt einbinden, ohne eine Vektordatenbank zu nutzen. Allerdings hat dieser Ansatz Grenzen. Die Verarbeitung großer Kontextfenster ist rechenintensiv und teuer, und die Qualität der Antworten kann abnehmen, wenn das Modell zu viele Informationen gleichzeitig verarbeiten muss. RAG bleibt für die meisten Unternehmensanwendungen der effizientere und kostengünstigere Weg.

Wie entwickelt sich RAG weiter?

Die RAG Architektur befindet sich in einer Phase intensiver Weiterentwicklung. Einige Trends sind heute bereits sichtbar.

Agentic RAG

Statt eine einzelne Suchanfrage abzusetzen, kann das LLM mehrere Retrieval Schritte selbst orchestrieren. Es kann Quellen wechseln, Rückfragen formulieren und externe Tools einbinden. Diese Form der agentischen RAG ermöglicht komplexere Arbeitsabläufe, erfordert aber auch eine sorgfältige Steuerung, um Fehlerketten zu vermeiden.

Graph RAG

Bei komplexen Fragestellungen, die Beziehungen zwischen Entitäten betreffen, stößt die klassische Vektorsuche an Grenzen. Graph RAG bildet Entitäten und ihre Beziehungen in einem Wissensgraphen ab und ermöglicht Abfragen, die mehrere Knoten und Kanten berücksichtigen. Dies ist besonders in Bereichen wie Vertragsanalyse, Betrugserkennung oder Forschung relevant.

Multimodal RAG

Die nächste Generation von RAG Systemen bezieht nicht nur Text, sondern auch Bilder, Audio, Video und strukturierte Daten in die Wissensbasis ein. Ein Servicetechniker könnte etwa ein Foto von einem defekten Bauteil machen und das System liefert die passende Reparaturanleitung samt historischer Fehlerbilder.

Verbesserte Evaluierung

Mit der Verbreitung von RAG entstehen neue Werkzeuge und Frameworks, um die Qualität von RAG Systemen systematisch zu messen. Open Source Tools wie RAGAS, DeepChecks oder kommerzielle Evaluierungsfunktionen der Hyperscaler erlauben es, Retrieval Qualität, Antworttreue und Nutzerzufriedenheit kontinuierlich zu überwachen.

Stärkere Integration in Plattformen

RAG Funktionen wandern zunehmend in Standardprodukte. Microsoft 365 Copilot, Google Workspace mit Gemini, Salesforce Agentforce und zahlreiche Branchenlösungen integrieren RAG nativ in ihre Oberflächen. Für viele Anwender wird RAG damit zu einer Funktion, die sie nutzen, ohne sie selbst implementieren zu müssen.

Was wir bei LYN Intelligence ergänzend beobachten

In unseren Projekten zeigen sich drei Faktoren, die in den technischen Dokumentationen oft nur am Rand erwähnt werden, in der Praxis aber entscheidend sind.

Die Qualität der Wissensbasis entscheidet

Die genannten Vorteile von RAG setzen voraus, dass die zugrunde liegenden Dokumente gepflegt und konsistent sind. In der Realität finden wir häufig veraltete SharePoint Inhalte, doppelte Versionen desselben Dokuments und widersprüchliche Prozessbeschreibungen. Wir empfehlen eine Datenbereinigung als festen Bestandteil der RAG Implementierung.

Chunking ist mehr als Technik

Die Wahl der Chunk Größe, der Schnittlogik und der Metadaten hat direkten Einfluss darauf, ob das System die richtigen Informationen findet. Wir testen in jedem Projekt mehrere Chunking Strategien und messen die Auswirkungen auf die Antwortqualität, bevor wir die endgültige Konfiguration festlegen.

Berechtigungskonzepte sind nicht optional

Viele RAG Piloten starten mit offenen Zugriffsrechten auf die Wissensbasis. Sobald das System jedoch produktiv geht, tauchen Fragen auf. Welche Inhalte dürfen alle Mitarbeiter sehen. Welche sind nur für bestimmte Rollen freigegeben. Wir bauen diese Filter direkt in das Retrieval ein, damit das System standardmäßig nur die Inhalte liefert, die der jeweilige Nutzer sehen darf.

Diese drei Punkte werden in der öffentlichen Diskussion über RAG häufig unterschätzt, entscheiden aber in vielen Projekten über Erfolg oder Misserfolg.

Häufig gestellte Fragen zu RAG

Weiterführende Ressourcen

• IBM: Was ist Retrieval-Augmented Generation auf ibm.com
• Microsoft Azure: RAG Architektur und Anwendungsfälle auf azure.microsoft.com
• Oracle: Retrieval-Augmented Generation erklärt auf oracle.com
• Cloudflare: RAG in KI und AutoRAG auf cloudflare.com
• SnapLogic: Glossar Eintrag zu RAG auf snaplogic.com

Dieser Artikel wurde von LYN Intelligence verfasst. Wenn Sie RAG in Ihrem Unternehmen einführen möchten oder eine unabhängige Einschätzung zu einer bestehenden Architektur benötigen, sprechen Sie uns an.