RAG-Architekturen: Ein Überblick

RAG ist das Kernthema, wenn es darum geht, KI-Systeme sinnvoll in einem wirtschaftlichen oder organisatorischen Kontext zu nutzen – denn ohne Zugriff auf eigene Daten bleibt ein LLM auf sein Trainingswissen beschränkt.

Zunächst mal zum Begriff: RAG steht für Retrieval Augmented Generation – wörtlich: abrufgestützte Generierung. Gemeint ist: Die Antwort eines LLM wird verbessert, indem automatisch abgerufene Informationen in den Kontext der Anfrage einfließen.

RAG ist eine der zentralen Techniken des sogenannten Context-Engineering – einem Begriff, der das Gesamtsystem beschreibt, welches dafür sorgt, dass eine Anfrage mit genau den Inhalten angereichert wird, die zu ihrer Beantwortung nötig sind.

Einordnung in Context-Engineering

Um RAG einordnen zu können hier ein paar weitere Begriffe, die die Maßnahmen beschreiben, den Kontext für eine optimale LLM-Antwort herzustellen.

System Prompt

Dieser enthält statische Basisinformationen, die bei jeder Anfrage mitgeschickt werden. Unveränderlich, nicht auf die konkrete Frage zugeschnitten. Beispiel: “Du bist ein hilfreicher Support-Assistent für die Firma XY. Antworte immer auf Deutsch.”

Conversation History

Der bisherige Gesprächsverlauf wird bei jeder neuen Anfrage mitgeschickt. Das Modell “erinnert” sich dadurch an frühere Aussagen – nicht weil es ein Gedächtnis hat, sondern weil der Kontext es enthält. Beispiel: Eine Folgefrage wie “Erkläre das nochmal einfacher” funktioniert nur, weil das Modell die vorherige Antwort noch “sieht”, also den Gesprächsverlauf im Kontext mitgegeben bekommt.

Tool Results

Ein Modell ruft ein externes Werkzeug auf – API, Datenbank, Suche – und das Ergebnis fließt in den Kontext. Beispiel: “Wie ist das Wetter in Bremen?” → Wetter-API → Ergebnis im Kontext.

Memory

Gespeicherte Informationen aus früheren Sitzungen, die bei einer neuen Anfrage automatisch abgerufen und in den Kontext eingespeist werden. Beispiel: “Der Nutzer arbeitet in der Steuerberatung und bevorzugt kurze Antworten.” – Das Modell “weiß” das nicht von selbst, es wurde ihm in den Kontext gelegt.

Was ist also RAG

Fasst man RAG wortwörtlich auf – Anreicherung der Generierung durch automatischen Abruf – dann beschreibt es eigentlich den Kern von Context-Engineering insgesamt. System Prompt ausgenommen ist nahezu jede Technik ein Abruf irgendeiner Art: vergangene Gespräche, Tool-Ergebnisse, Erinnerungen, Dokumente.

Der Begriff RAG hat sich in der Praxis auf einen bestimmten Anwendungsfall verengt – semantische Suche über eine Wissensbasis – aber das ist eine Konvention, keine Definition.

Die effektivsten RAG-Systeme kombinieren oft semantische Suche und anderen Maßnahmen (z.B. BM25, traditionelles SQL bis hin zur Verfügungstellung von CLI-Tools, die in einem Dateisystem suchen).

Verengt man den Begriff RAG, so wie es viele tun, auf die Suche in Vektor-Datenbanken, schließt man viele wertvolle Optionen aus dem Denkraum aus. Trotzdem bleibt die Vektordatenbank ein zentrales Werkzeug. Es lohnt sich also, die verschiedenen Ansätze zu kennen – und zu verstehen, wo ihre Grenzen liegen.

Die Grenzen der Technik und des Anwendungsfalls verstehen

Ein RAG-System kann beliebig komplex werden – und dennoch gibt es keines, das für jeden Anwendungsfall perfekt funktioniert. Wie gut ein System funktioniert, hängt an zwei Fragen: Welche Daten stehen zur Verfügung? Und welche Art von Anfragen soll es beantworten können?

“There are no solutions. There are only trade-offs.”

Thomas Sowell

Der Datenstamm – die “Ground Truth”

Es ist ein erheblicher Unterschied, ob man technische Handbücher, Produktdaten, Vertragsdokumente, eine Code-Basis oder E-Mail-Verläufe durchsuchbar machen möchte – oder alles zusammen. Strukturierte Produktdaten verhalten sich fundamental anders als Fließtext in E-Mails oder Kommentare in einer Codebase.

Unterschiedliche Dokumentarten erfordern teilweise völlig unterschiedliche Retrieval-Strategien. Welche das sind, dazu später mehr.

Die gewünschte Antwort: Retrieval vs. Synthese

Ein weiterer entscheidender Faktor ist die Art der erwarteten Antwort. Am einen Ende des Spektrums steht einfaches Retrieval: Eine Anfrage zielt auf ein bestimmtes Dokument oder eine klar umrissene Information. Beispiel: “Wie stelle ich einen Antrag auf Teilzeit?” – sofern das in einem Dokument beschrieben ist, muss das System es finden und wiedergeben. Kaum mehr.

In der Mitte liegt die gezielte Synthese: Die Antwort erfordert Informationen aus mehreren Quellen, die zusammengeführt werden müssen. Beispiel: “Welche Kündigungsfristen gelten für Mitarbeiter mit Sonderverträgen?” – das System muss mehrere Verträge finden, vergleichen und eine konsolidierte Antwort formulieren.

Am anderen Ende steht die offene Aggregation: Aus einer unbekannten Menge an Dokumenten sollen neue Erkenntnisse entstehen. Beispiel: “Welches waren die häufigsten Probleme in unseren Projekten zwischen 2019 und 2025?” – hier ist weder klar, wie viele Quellen relevant sind, noch welche Form die Antwort haben sollte.

Je weiter man sich auf diesem Spektrum nach rechts bewegt, desto anspruchsvoller wird das Retrieval – und desto wichtiger wird die Wahl der richtigen Architektur.

Deep-Dive: Die klassischen RAG-Architekturen

Warum die meisten RAG-Übersichten irreführend sind

Wer sich mit RAG beschäftigt, stößt schnell auf eine Flut von Begriffen: Fusion RAG, Agentic RAG, RAPTOR, GraphRAG, Self-RAG, CRAG. Die meisten Übersichten listen diese Techniken nebeneinander auf, als wären sie Alternativen auf derselben Ebene. Das greift zu kurz – es gibt Bedarf zur weiteren Differenzierung, auch wenn die Grenzen in der Praxis fließend sind.

Als Denkwerkzeug hilft ein Schichtenmodell mit fünf Ebenen:

Schicht 1 – Indexierung: Wie werden Dokumente aufbereitet, damit sie durchsuchbar sind? Contextual Retrieval, Chunking-Strategien, Entity-Extraction.

Schicht 2 – Query-Strategie: Wie werden Suchanfragen formuliert und parametrisiert? Fusion RAG erzeugt Query-Varianten, HyDE generiert hypothetische Antworten als Suchvektor.

Schicht 3 – Retrieval-Ausführung: Welche Backends werden mit diesen Queries abgefragt? Vector Search, Hybrid Search (BM25 + Vektor), GraphRAG, RAPTOR, SQL, Dateisystem-Suche.

Schicht 4 – Post-Retrieval: Was passiert mit den Ergebnissen, bevor sie dem LLM gegeben werden? Re-Ranking und Bewertung (inkl. CRAG-Muster), Kompression, Filterung.

Schicht 5 – Kontroll-Architektur: Wer orchestriert die Pipeline – wann, wie oft, mit welchen Parametern? Naive RAG durchläuft sie genau einmal. Agentic RAG entscheidet im Loop, ob und mit welchen Parametern erneut gesucht wird.

Schicht 1 liegt vor der Pipeline, Schichten 2–4 laufen sequenziell pro Anfrage, Schicht 5 steuert das Ganze. Alle Schichten sind frei kombinierbar: Agentic RAG mit simplem Vector Search. Fusion RAG über Hybrid Search – jede generierte Query als parallele BM25- plus Vektor-Suche. Self-RAG über einem GraphRAG-Backend. Erst wenn man das verstanden hat, kann man sinnvolle Architekturentscheidungen treffen.

Schicht 1: Indexierung

Wie gut sind die Daten aufbereitet, die durchsucht werden sollen? Diese Frage wird oft unterschätzt – dabei entscheidet sie maßgeblich über die Qualität aller nachgelagerten Schritte.

Contextual Retrieval – den Chunk-Kontext retten

Standard Chunking verliert den Dokumentkontext. Ein Chunk wie “Der Vertrag wurde am 15. März unterzeichnet” ist isoliert bedeutungslos. Von welchem Vertrag? Welches Jahr?

Contextual Retrieval löst das, indem vor dem Embedding jedem Chunk ein LLM-generiertes Kontext-Präfix hinzugefügt wird, das seinen Platz im Gesamtdokument erklärt.

Dieses Präfix fließt sowohl in die Indexierung (Embedding und BM25) als auch in den Kontext ein, den das LLM bei der Antwortgenerierung erhält – der Chunk wird dadurch selbsterklärend.

Anthropic berichtet bis zu 67% weniger Retrieval-Fehler. Die Kosten fallen nur einmalig beim Indexaufbau an. Contextual Retrieval verbessert jeden nachgelagerten Retrieval-Ansatz, ob Hybrid Search, Vector Search oder rein lexikalische Suche. Lohnt sich praktisch immer, wenn Dokumente Kohärenz über Chunks hinweg haben – also fast immer.

Schicht 2: Query-Strategie

Die Frage dieser Schicht: Wie werden Suchanfragen formuliert, transformiert und parametrisiert?

Fusion RAG – wenn eine Query nicht reicht

Statt einer Suchanfrage werden mehrere erzeugt: Ein LLM reformuliert die Original-Query in drei bis fünf Varianten, die verschiedene Aspekte oder Formulierungen abdecken. Jede Variante läuft als eigene Suche, die Ergebnislisten werden per RRF zusammengeführt.

Dokumente, die in mehreren Listen auftauchen, steigen im Ranking.

Der Gedanke dahinter: Queries sind oft unvollständig oder sprachlich weit von der Quelle entfernt. Mehrere Formulierungen desselben Informationsbedürfnisses erhöhen die Trefferquote erheblich. Direkt mit Hybrid Search kombinierbar – jede der generierten Queries kann als Hybrid Search laufen.

Kosten: N zusätzliche LLM-Calls für die Query-Generierung plus N Retrieval-Läufe. Bei paralleler Ausführung kaum Latenz-Overhead, aber die Kosten skalieren.

HyDE – die umgekehrte Suche

HyDE dreht die Retrieval-Logik um.

Das Problem: Fragen und Antworten liegen im Embedding-Raum weit auseinander.

Die Lösung: Das LLM generiert zuerst eine hypothetische Antwort – rein aus Parameterwissen, ohne Retrieval.

Diese hypothetische Antwort wird vektorisiert (nicht die originale Query) und als Suchvektor verwendet.

Warum das funktioniert: Ein hypothetisches Antwort-Dokument teilt Vokabular, Konzepte und Stil mit realen Antwort-Dokumenten – auch wenn es faktisch falsch ist.

Die Embedding-Nähe zwischen Dokumenten gleicher Art ist höher als zwischen Query und Dokument.

Der Haken: Wenn das LLM in eine komplett falsche Richtung halluziniert, landet man im falschen Teil des Embedding-Raums. Bei präzisen Fact-Lookups (“Was ist die Telefonnummer von X?”) ist HyDE kontraproduktiv. Am stärksten in Fachdomänen mit spezifischem Vokabular, wo Queries kurz und Dokumente lang sind.

Schicht 3: Retrieval-Ausführung

Die Frage dieser Schicht: Welche Backends werden abgefragt – und wie?

Standard Vector Search – die Baseline

Der Einstieg in jedes RAG-System: Dokumente werden in Chunks zerlegt, jeder Chunk per Embedding-Modell vektorisiert und in einer Vektordatenbank gespeichert. Bei einer Anfrage wird die Query ebenfalls vektorisiert und per Cosine Similarity die ähnlichsten Chunks abgerufen.

Das funktioniert – bis es nicht mehr funktioniert. Der Embedding-Raum kodiert semantische Ähnlichkeit, aber Fragen und Antworten liegen in diesem Raum oft weit auseinander. Kurze Fragen matchen schlecht zu langen, inhaltlich dichten Dokumenten. Und exaktes Matching – ein Eigenname, eine Versionsnummer, eine Vertragsnummer – ist schlicht nicht das, wofür Vektoren gebaut sind.

Als Prototyp oder Proof-of-Concept brauchbar. Für Produktionssysteme mit heterogenen Inhalten: nicht ausreichend.

Hybrid Search – der wichtigste einzelne Schritt

Hybrid Search kombiniert zwei parallele Suchen: BM25 (klassisches Keyword-Matching, exzellent für exakte Begriffe und IDs) und Dense Vector Search (semantische Ähnlichkeit, exzellent für Paraphrasen und Konzepte). Die Ergebnisse werden per Reciprocal Rank Fusion (RRF) zusammengeführt – einer Rang-basierten Formel, die das Problem umgeht, dass BM25-Scores und Vektor-Scores nicht direkt vergleichbar sind.

Hybrid Search schlägt reine Vector Search in fast allen realen Benchmarks. Es ist der einzelne Schritt mit dem höchsten Return on Investment in der RAG-Optimierung – geringer Aufwand (die meisten Vektordatenbanken unterstützen BM25 nativ), messbarer Gewinn. Sollte Standard sein, nicht Ausnahme.

RAPTOR – hierarchisches Verstehen

Standard RAG kann einzelne Fakten finden, scheitert aber an Fragen, die Aggregation oder Überblick erfordern: “Was sind die Hauptthemen dieses Dokuments?”

Kein einzelner Chunk kann das beantworten.

RAPTOR baut vor der Indexierung einen hierarchischen Baum: Chunks werden geclustert, jeder Cluster per LLM zusammengefasst, die Zusammenfassungen wiederum geclustert und zusammengefasst – bis eine Wurzel entsteht.

Alle Ebenen fließen in den Index ein. Bei der Suche kann das System sowohl aus den Detail-Chunks als auch aus den Zusammenfassungen abrufen.

Die Indexierungskosten sind hoch (viele LLM-Calls), und bei Änderungen an Quelldokumenten muss der Baum neu aufgebaut werden.

Geeignet für große, stabile Dokumentkorpora – technische Dokumentation, Rechtsdokumente, wissenschaftliche Literatur. Nicht für häufig wechselnde Inhalte.

GraphRAG – wenn Beziehungen zählen

Vector Search ist ein Best-First-Algorithmus: Er findet, was der Query am ähnlichsten ist. Manche Fragen sind aber inhärent global: «Welche Verbindungen existieren zwischen X und Y über alle Dokumente?» Für solche Fragen gibt es keine einzelnen ähnlichen Chunks – die Antwort entsteht erst aus dem Zusammenspiel vieler Quellen.

GraphRAG (Microsoft) extrahiert Entitäten und ihre Beziehungen per LLM und baut daraus einen Knowledge Graph. Ein Community-Detection-Schritt identifiziert thematische Cluster und erzeugt für jeden Cluster eine LLM-generierte Zusammenfassung. Daraus ergeben sich zwei Query-Modi: Local Search für spezifische Fragen via Graph-Traversierung und Global Search für übergreifende Fragen, die auf den Community Reports basieren.

Das Problem: Die Indexierungskosten sind prohibitiv – etwa 10.000x höher als Vector RAG. LightRAG (HKUDS, EMNLP 2025) löst das pragmatischer: Statt Community Detection und hierarchischer Summarisierung extrahiert es Entitäten und Relationen per LLM, speichert sie als kompakte Profile und durchsucht sie per Vektor-Retrieval. Der Graph wird nicht traversiert, sondern als strukturierter Index genutzt. Indexierungskosten nahe Vector RAG, inkrementelle Updates möglich, Multi-Hop-Fragen trotzdem abgedeckt. LightRAG ist Stand 2026 die praktisch relevantere Wahl für die meisten Teams, die Graph-basiertes Retrieval evaluieren.

Schicht 4: Post-Retrieval

Oft übersehen, aber kritisch: Auch gutes Retrieval liefert Rauschen. Was dem LLM gegeben wird, beeinflusst Qualität, Latenz und Kosten direkt.

Re-Ranking und Bewertung

Nach dem initialen Retrieval stellt sich immer dieselbe Frage: Wie gut passen die abgerufenen Chunks zur Anfrage? Das Werkzeug variiert, die Aufgabe bleibt gleich.

Im einfachsten Fall sortiert ein spezialisierter Cross-Encoder die Ergebnisse neu – Query und Dokument werden gemeinsam betrachtet, deutlich präziser als der initiale Bi-Encoder, aber zu langsam für den ersten Retrieval-Schritt. Typisch: Bi-Encoder retrievet Top-100, Cross-Encoder re-ranked auf Top-10. Latenz-Overhead: 200–500ms.

Das sogenannte CRAG-Muster (Corrective RAG) geht einen Schritt weiter: Statt nur zu sortieren, bewertet ein LLM jeden Chunk explizit als relevant, irrelevant oder unklar. Fällt die Bewertung zu schlecht aus, wird auf alternative Quellen ausgewichen – etwa Web-Suche. Teurer und langsamer, aber mit Fallback-Logik für Domänen mit hohen Genauigkeitsanforderungen (Medizin, Recht, Compliance).

Ob spezialisierter Cross-Encoder oder General-Purpose LLM, ob stille Akzeptanz der Top-K oder Reject mit Fallback – das ist eine Konfigurationsentscheidung innerhalb derselben Stufe, kein Architekturwechsel.

Context Compression

Context Compression reduziert die Token-Last: Techniken wie LLMLingua entfernen irrelevante Tokens, gemessen per Perplexity. Kompressionsraten von 2–10x bei unter 1% Qualitätsverlust. Besonders relevant bei Agentic RAG mit vielen Retrieval-Runden oder Budget-Constraints.

Schicht 5: Kontroll-Architektur

Wer orchestriert die Pipeline – wann, wie oft, mit welchen Parametern?

Naive RAG

Query → Retrieval → Generation. Einmalig, deterministisch, keine Entscheidungslogik. Reicht für einfache Q&A-Systeme und Prototypen.

Conversational RAG

Erweitert Naive RAG um Konversationsgedächtnis. Das Problem: In einem Multi-Turn-Gespräch sind Folgefragen kontextabhängig. “Wie hoch ist der Umsatz?” nach “Erzähl mir über Tesla” ist als Standalone-Query sinnlos. Vor dem Retrieval reformuliert ein LLM-Call die aktuelle Query zusammen mit der Gesprächshistorie zu einer eigenständigen Suchanfrage.

Adaptive RAG

Warum immer suchen, wenn einfache Fragen direkt beantwortbar sind? Ein Classifier analysiert die Komplexität der Query und routet: einfache Fragen direkt ans Modell, mittlere Komplexität über Standard-RAG, komplexe Fragen über Multi-Step-Retrieval. Effizienzgewinn, weil einfache Fragen oft 90% aller Anfragen ausmachen.

Self-RAG

Retrieval-Verhalten wird direkt ins Modell eintrainiert: Spezielle Reflexions-Tokens entscheiden während der Generierung, ob gesucht werden soll und ob die eigene Aussage gestützt ist. Stark in Benchmarks, aber durch das erforderliche Fine-Tuning an einen Modell-Checkpoint gebunden. In einer Welt, in der alle paar Monate neue Foundation Models erscheinen, ist das ein hoher Preis – und für die meisten Teams kein praktikabler Weg.

Agentic RAG

Retrieval als Agenten-Problem: Ein LLM-Agent erhält Retrieval-Tools und entscheidet selbst im Reasoning-Loop, wann, wie oft und mit welchen Parametern gesucht wird. Der Loop endet nicht nach einem festen Schritt, sondern wenn der Agent entscheidet, genug Information zu haben. Von Single-Agent mit Tools bis hin zu Multi-Agent-Systemen mit spezialisierten Sub-Agenten skalierbar. In Kombination mit modernen Reasoning-Modellen ist das 2026 der praktische State of the Art für komplexe Wissensarbeit. Die Kosten sind hoch – mehrere LLM-Calls, potenziell unbegrenzte Schleifen – und erfordern Guardrails.

Und doch: Alles Schall und Rauch

Das Schichtenmodell hilft beim Sortieren der Begriffe – aber es ist kein Implementierungsplan. In der Praxis kombiniert man frei über Schichten und Ebenen hinweg.

Contextual Retrieval verbessert die Indexierung unabhängig vom Retrieval-Ansatz. Und wenn man schon einen LLM jedes Dokument analysieren lässt, warum nicht hier noch 1–2 weitere Calls machen (sich Prompt-Caching zu Nutze machen), um z.B. Meta-Daten generieren zu lassen über Entity-Extraction?

Fusion RAG (Schicht 2) läuft am besten über Hybrid Search (Schicht 3) – jede generierte Query als parallele BM25- plus Vektor-Suche.

Bei der Kontroll-Architektur verschwimmen die Grenzen am stärksten. Adaptive RAG klassifiziert eingehende Anfragen und routet auf die passende Strategie. Das kann, der reinen Lehre nach, nach Komplexität sein – aber interessanter wird es, wenn nach Anfragetyp geroutet wird: Sucht der Nutzer ein bestimmtes Dokument? Braucht er eine Synthese über mehrere Quellen? Oder eine Aggregation über strukturierte Daten? Jeder Typ hat eine optimale Retrieval-Strategie – und die muss nicht dieselbe sein.

Und diese Strategien können wieder eigene Agenten sein – dann ist man bei Agentic RAG.

Die Frage ist also immer: Welche Kombination passt zu meinen Daten, meinen Anfragen und meinem Budget? Wer eine schnelle, solide Baseline will, startet mit Contextual Retrieval + Hybrid Search + Re-Ranking + Conversational RAG.

Die nächste Ausbaustufe wären eine Form von graphbasiertem und/oder agentischem RAG. Gerade hier kommt es aber auf die Feinheiten an – die Möglichkeiten sind groß, wenn klar ist welche Use-Cases durch die “Knowledge-Base” erfüllt werden müssen und welche (erstmal) nur “nice-to-have” wären.

Insgesamt ein spannendes Feld, gerade weil die Silver Bullet nicht existiert und LLM, richtig eingesetzt – in der Indexierungsphase oder als Agents im Retrieval – viele kreative Möglichkeiten eröffnen, Informationen effizient zu erschließen.