RAG: Eine Einführung

Ein Beispiel:

Fragt man ein Modell „Wie viele interne Projekte haben wir beim Kunden XY?“ oder „Wie baue ich den Schrank des Modells ABC auf?“, fehlt meist das Wissen, denn solche Informationen liegen in internen Tools wie Confluence, PDF-Handbüchern oder MS Teams.

Retrieval-Augmented Generation (RAG) bietet hier eine intelligente Lösung. Es kombiniert generative Sprachmodelle mit externem, abrufbarem Wissen. Statt sich auf gespeichertes Modellwissen zu verlassen, wird gezielt nach relevanten Informationen in Dokumenten, Datenbanken oder Wissenssystemen gesucht. Diese Informationen fließen direkt in die Antwortgenerierung ein.²

RAG fungiert somit als Vermittler zwischen vortrainiertem Sprachwissen und gezielt eingebundenem, externem Kontext. Diese Kombination macht es besonders geeignet für Anwendungen mit hohen Anforderungen an Präzision und Nachvollziehbarkeit. Die Kombination aus Retrieval und Generation bewährt sich zunehmend in Chatbots und internen Wissenssystemen, insbesondere zur Erstellung verlässlicher Inhalte.

Doch was genau steckt hinter RAG? Wie funktioniert es, und worauf sollte man achten? Diesen Fragen gehen wir in diesem Artikel nach.

Was ist Retrieval-Augmented Generation (RAG)?

Formal beschrieben ist RAG ein Architekturstil, bei dem Large Language Models (LLMs) mit einem vorgeschalteten Retrieval-Modul kombiniert werden, um bei jeder Anfrage gezielt externes Wissen einzubinden.³

Ein vollständiges RAG-System besteht dabei in der Regel aus den folgenden technischen Komponenten:

• einem Large Language Model (LLM) für die generative Antwortformulierung,
• einem Embedding-Modell zur Umwandlung von Texten in semantische Vektoren,
• einer Vektor-Datenbank (z. B. FAISS, Weaviate) zur effizienten Ähnlichkeitssuche,
• sowie einer Retriever-Logik, die bei jeder Anfrage relevante Inhalte aus der Datenbank abruft.

Diese Kombination ist besonders im sogenannten Naive RAG Paradigm weit verbreitet.⁴ Dabei handelt es sich um einen klassischen dreistufigen „Retrieve-Read“-Ansatz, der aus drei funktionalen Hauptkomponenten besteht:

Indexing: Vorverarbeitung und Vektorisierung

Der erste Schritt besteht darin, verschiedenste Datenquellen wie PDFs, HTML-Seiten oder interne Word-Dokumente zu extrahieren und bereinigen. Diese Inhalte werden anschließend in ein einheitliches Textformat überführt und in kleinere Chunks segmentiert, da Sprachmodelle nur begrenzt viele Tokens verarbeiten können.
Jeder dieser Textabschnitte wird dann mittels eines Embedding-Modells (z. B. Sentence Transformers oder OpenAI Embeddings) in einen Vektor überführt und in einer Vektordatenbank (z. B. FAISS, Weaviate oder Chroma) gespeichert. Dies stellt die Wissensgrundlage für das System dar, aus welcher Informationen entnommen werden.

Retrieval: Abruf passender Inhalte

Stellt ein Nutzer eine Anfrage (Query), wird auch diese in einen Vektor umgewandelt. Die Retrieval-Komponente vergleicht diesen Vektor mit den Vektoren in der Datenbank, welcher basierend auf Ähnlichkeitsmaßen (meistens Cosine Similarity) und wählt die Top-k relevantesten Chunks aus. Das bedeutet, dass wir die ähnlichsten Informationen aus der Datenbank erhalten.
Diese Phase ist entscheidend für die Qualität der Antwort, denn werden irrelevante Passagen gewählt oder wichtige Informationen übersehen, sinkt die Präzision der späteren Antwort deutlich. Dies führt wiederum zu falschen oder nicht aussagekräftigen Ergebnissen.

Generation: Antwortformulierung durch das LLM

Die ausgewählten Chunks werden zusammen mit der ursprünglichen Nutzeranfrage zu einem Prompt kombiniert und an ein (meist "frozen") Large Language Model übergeben, das daraus eine natürliche Antwort generiert. Je nach Anwendung kann das Modell entweder frei formulieren oder explizit an den gelieferten Kontext gebunden sein.

Ein typisches Beispiel für den Prompt-Aufbau lautet:

„Bitte beantworte folgende Frage basierend auf den untenstehenden Informationen: [Query] Kontext: Chunk 1, Chunk 2, Chunk 3“.

Praktische Anwendung eines RAG‘s

Nach dem grundlegenden Verständnis der Architektur stellt sich die Frage: Wie sieht die Anwendung eines RAG-Systems in der Praxis konkret aus?
Die folgende Abbildung illustriert eine typische RAG-Pipeline in einem Frage-Antwort-Szenario. Sie lässt sich in sechs funktionale Stationen gliedern, die gemeinsam einen geschlossenen Informationsfluss vom Nutzerinput bis zur generierten Antwort abbilden:⁵

Schritt 1: Nutzeranfrage (Query Initiation)

Der RAG-Prozess startet mit einer Nutzereingabe in natürlicher Sprache, typischerweise in Form einer konkreten Frage. Sie bildet die semantische Grundlage für alle folgenden Verarbeitungsschritte.

Schritt 2: Indexierung (Indexing)

Um relevante Informationen auffindbar zu machen, werden externe Wissensquellen, etwa interne Dokumente, PDFs oder Webseiten, in kleinere, semantisch sinnvolle Textabschnitte („Chunks“) unterteilt. Diese werden anschließend mithilfe eines Embedding-Modells in Vektoren überführt und in einer Vektor-Datenbank gespeichert. So entsteht ein durchsuchbarer Index für das spätere Retrieval.

Schritt 3: Semantische Suche (Retrieval)

Sobald eine Anfrage gestellt wird, wird auch diese in einen Vektor umgewandelt. Über ein Ähnlichkeitsmaß (meist Cosine Similarity) wird dieser mit den vektorisierten Chunks im Index verglichen. Die Top-k Chunks mit der höchsten semantischen Übereinstimmung werden selektiert und zur Weiterverarbeitung bereitgestellt.

Schritt 4: Prompt-Zusammenführung (Contextual Prompt Construction)

Die gefundenen Textfragmente werden nun gemeinsam mit der Originalanfrage zu einem sogenannten augmented prompt zusammengeführt. Dieser erweitert die Eingabe um relevantes Kontextwissen und bildet die Grundlage für die nachfolgende Modellantwort, ohne dass das LLM selbst neues Wissen speichern muss.

Schritt 5: Antwortgenerierung (Controlled Natural Language Generation)

Ein LLM verarbeitet den erweiterten Prompt und erzeugt eine Antwort. Dabei kann es entweder ausschließlich auf den gelieferten Kontext zurückgreifen (kontextabhängig) oder diesen mit internem Modellwissen kombinieren (parametrisch erweitert). Die Ausgabe erfolgt sequenziell und zielt auf inhaltliche Konsistenz mit den eingebundenen Informationen.

Schritt 6: Ausgabe und Rückführung (Answer Delivery & Feedback Loop)

Die Antwort wird an den Nutzer zurückgegeben.

In fortgeschritteneren Architekturen kann zusätzlich eine Feedback-Schleife implementiert sein, über die Antworten evaluiert und zur Optimierung der Indexierungs- oder Retrievalstrategie genutzt werden (z. B. durch User-Rating, Confidence-Scoring oder Ranking-Refinements).

Vorteile und Limitationen von RAG

Der entscheidende Vorteil eines RAG-Systems liegt darin, dass das zugrunde liegende Sprachmodell nicht starr auf fest eintrainiertes Wissen beschränkt ist, sondern laufend mit externen Informationen ergänzt und aktualisiert werden kann. Neue Inhalte, etwa aus internen Dokumenten oder Datenbanken, lassen sich direkt einpflegen, ohne dass das Modell selbst neu trainiert werden muss. So können Antworten flexibel an veränderte Wissensstände oder spezifische Unternehmensanforderungen angepasst werden, ideal z. B. in der Kundenberatung, technischen Dokumentation oder Wissensmanagement.

Ein weiterer zentraler Vorteil von RAG liegt in der Nachvollziehbarkeit und Transparenz der generierten Inhalte. Besonders in stark regulierten Branchen wie dem Finanz- und Versicherungswesen, in denen Entscheidungen dokumentiert, begründet und im Rahmen von Prüfungen offengelegt werden müssen, ist diese Eigenschaft essenziell.

RAG-Systeme ermöglichen eine explizite Verknüpfung der Antwort mit den zugrunde liegenden Quellen, beispielsweise durch die Angabe der verwendeten Dokumenten-Chunks oder durch Verlinkungen zur Originalstelle. So entsteht eine prüfbare Entscheidungsbasis, die nicht nur für Nutzer nachvollziehbar ist, sondern sich auch systemseitig auditieren und versionieren lässt.
Damit können auch regulatorische Anforderungen wie MaRisk, VAIT oder der EU AI Act  erfüllt werden. Gleichzeitig stärkt RAG das Vertrauen in die Anwendung und schafft eine verlässliche Grundlage für Compliance, interne Kontrolle und revisionssichere Dokumentation.

Trotz der Vorteile bringt RAG auch einige Herausforderungen mit sich. Zentral ist die Qualität des Retrievals, denn wenn irrelevante oder unvollständige Chunks abgerufen werden, leidet die Antwortqualität deutlich. Auch das Prompt Design ist entscheidend, da der Kontext sinnvoll eingebunden sein muss, damit das Modell die Anfrage korrekt interpretieren kann.⁶

Weitere Risiken ergeben sich durch Redundanzen oder Widersprüche im abgerufenen Kontext, die die Konsistenz der Ausgabe beeinträchtigen können. Zudem erfordert RAG zusätzliche Ressourcen, da die Erstellung von sogenannten Embeddings und die semantische Suche in der Vektordatenbank spürbare Speicher- und Rechenlast verursachen, besonders in Echtzeitszenarien.⁷

Erweiterte RAG-Ansätze (Advanced RAG)

Um diese Grenzen zu überwinden, wurden in den letzten Jahren mehrere erweiterte RAG-Ansätze entwickelt. Dazu gehört etwa Multi-hop RAG, bei dem komplexe Fragen durch mehrstufiges, voneinander abhängiges Retrieval beantwortet werden.

Reranking-Methoden bewerten die gefundenen Chunks zusätzlich nach Relevanz, Kohärenz und Redundanz, bevor sie in den Prompt einfließen.⁸

Auch ReAct und Toolformer erweitern die klassische RAG-Pipeline, indem sie reasoning-Fähigkeiten und externe Tools wie Websuche oder Rechenfunktionen integrieren. Conversational RAG bezieht zusätzlich den Dialogverlauf mit ein und sorgt so für konsistente Antworten in längeren Interaktionen.

Besonders hervorzuheben ist auch GraphRAG, ein Ansatz, der nicht nur lineare Dokumentenstrukturen berücksichtigt, sondern explizit auf Wissensgraphen basiert. Dabei werden Informationen als Knoten und Kanten in einem semantischen Netzwerk modelliert, was eine strukturierte, kontextbewusstere Exploration und Verknüpfung von Inhalten ermöglicht, insbesondere bei komplexen Relationen zwischen Entitäten oder Konzepten.

Darüber hinaus lassen sich RAG-Systeme durch folgende Komponenten weiter verbessern und anwendungsspezifisch anpassen:

• Query-Rewriter, die unspezifische oder mehrdeutige Nutzeranfragen vor dem Retrieval automatisch präzisieren.
• Prompt-Optimierer, die retrieved Chunks strukturieren oder komprimieren, um sie effizienter im Prompt zu verwenden.
• Answer-Validator, der nach der Generierung prüft, ob die Antwort durch den Kontext gedeckt ist (z. B. mit einem zweiten LLM).
• Dialog-Memory-Module, die den Gesprächsverlauf speichern und eine konsistente Konversation über mehrere Runden ermöglichen.
• Agentic RAG, bei dem spezialisierten Agenten (z. B. Retriever, Reasoner, Kritiker) kollaborativ an der optimalen Antwort arbeiten.

Viele dieser Erweiterungen befinden sich noch in der Forschung oder in spezialisierten Anwendungen. Sie verfolgen jedoch dasselbe Ziel, nämlich die Grenzen des Naive RAG zu überwinden und präzisere sowie kontextbezogene Antworten zu ermöglichen.⁹

Fazit

Retrieval-Augmented Generation kombiniert die Ausdrucksstärke großer Sprachmodelle mit der Präzision und Aktualität externer Wissensquellen. In domänenspezifischen Anwendungen liefert RAG nachvollziehbare und aktualisierbare Antworten, ohne dass das Modell neu trainiert werden muss.
Ein einfaches Retrieve-and-Generate-Verfahren genügt dafür oft nicht mehr. Erweiterte Ansätze wie Multi-hop RAG, Graph RAG oder Multi-Agent-Architekturen verbessern die Qualität des Retrievals, erhöhen die Konsistenz und vertiefen den Kontextbezug.

RAG entwickelt sich damit zu einem zentralen Bestandteil moderner KI-Systeme, vor allem dort, wo Verlässlichkeit, Erklärbarkeit und unternehmensspezifisches Wissen im Fokus stehen.

Quellenverzeichnis

¹https://arxiv.org/abs/2402.19473

²https://arxiv.org/abs/2005.11401

³https://arxiv.org/abs/2312.10997

⁴https://arxiv.org/pdf/2312.10997

⁵https://arxiv.org/abs/2312.10997

⁶https://arxiv.org/html/2409.14924v1

⁷https://arxiv.org/abs/2402.19473

⁸https://arxiv.org/abs/2410.12837

⁹https://arxiv.org/abs/2410.12837