RAG-Architekturen: Ein Überblick

Was ist RAG

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.

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.

Das Original-Paper (Lewis et al., NeurIPS 2020) beschrieb eine spezifische Modellarchitektur — die Kombination aus parametrischem Gedächtnis (Modellgewichte) und nicht-parametrischem Gedächtnis (externer Wissensindex). In der Praxis hat sich der Begriff davon gelöst: RAG meint heute lose “Retrieval vor Generation” — vom Vektorsearch über Graph-Traversierung bis hin zu file-basierten Ansätzen, die ganz ohne Vektoren arbeiten.

RAG ist eine Technik des Context-Engineering – dem Gesamtsystem, das dafür sorgt, dass eine Anfrage mit den richtigen Inhalten angereichert wird. Technisch betrachtet ist der Retrieval-Schritt eines RAG-Systems ein Tool Call; Conversational RAG nutzt die Gesprächshistorie; file-basierte Ansätze sind eine Form von Memory. RAG als Begriff ist also eng verbunden mit dem Begriff des Context-Engineering und teilweise werden die Begriffe zur Beschreibung von Systemen verwendet, wo diese austauschbar wären.

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

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.

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.

Das Schichtenmodell

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 — diese Begriffe beschreiben nicht alle dasselbe: manche betreffen die Indexierung, manche die Query-Strategie, manche den Kontrollfluss.

Als Denkwerkzeug hilft ein Schichtenmodell:

• Ingestion — Wie werden Dokumente aufbereitet, damit sie durchsuchbar sind?
• Query-Strategie — Wie werden Suchanfragen formuliert und transformiert?
• Retrieval-Ausführung — Welche Backends werden abgefragt?
• Post-Retrieval — Was passiert mit den Ergebnissen, bevor sie an das LLM gehen?
• Darüber liegt die Kontroll-Architektur: Wer orchestriert diese Schritte — einmal linear, als Workflow mit Schleifen, oder als Agent mit offener Entscheidungslogik?

Alle Schichten sind frei kombinierbar. Agentic RAG mit simplem Vector Search. Query-Expansion über Hybrid Search (also jede generierte Query als parallele BM25- plus Vektor-Suche). Erst wenn man das verstanden hat, kann man sinnvolle Architekturentscheidungen treffen.

Viele der benannten RAG-Varianten (Fusion, CRAG, HyDE) sind dabei weniger eigenständige Architekturen als Taktiken, die eine Kontroll-Architektur kontextabhängig einsetzen kann. In einem agentischen System tauchen sie als emergentes Verhalten wieder auf: Der Agent macht Fusion, wenn er parallel abfragt. Er macht CRAG, wenn er Ergebnisse verwirft und neu sucht. Das wird in den folgenden Abschnitten sichtbar.

Ingestion bzw. Indexierung: Die Vorverarbeitung

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.

Mechanische Verarbeitung

Je nach Datenbasis kann schon die Aufbereitung zu LLM-lesbaren Inhalten eine Herausforderung darstellen.

Das Parsing komplexer Formate — PDFs mit Tabellen, gescannte Dokumente, verschachtelte Layouts — ist ein noch nicht optimal gelöstes Problem, wobei es gerade im Bereich des PDF-Parsings Fortschritte gibt (z.B. opendataloader-pdf). Die Edge-Cases sind hier jedoch potentiell unendlich und so ist eine Kenntnis der Datenbasis vor dem Aufbau des RAG-Systems unabdingbar.

Daneben ist auch die Chunking-Strategie, also wie diese dann i.d.R. als Markdown-Texte aufbereiteten Inhalte weiter zerlegt werden, kein Randthema — die Strategie (fixed-size, semantic, recursive) und die Chunk-Größe beeinflussen die Retrieval-Qualität direkt.

Semantische Anreicherung

Hier wird der LLM zur Indexierungszeit eingesetzt — nicht nur beim Retrieval. Und hier divergiert die Qualität zwischen RAG-Systemen.

Contextual Retrieval: 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. Lohnt sich praktisch immer.

Weitere Anreicherungen: Wer schon einen LLM jeden Chunk analysieren lässt, kann im selben Durchlauf (unter Nutzung von Prompt-Caching) weitere Schritte einbauen: Metadaten-Extraktion (Autor, Datum, Dokumenttyp), Entity-Extraction (Entitäten und Relationen — die Grundlage für Graph-basiertes Retrieval), oder die Generierung hypothetischer Fragen pro Chunk (Reverse HyDE).

Query-Strategie

Query as-is

Die einfachste Variante — die Query wird direkt als Suchvektor verwendet. Das Embedding-Modell wandelt die Anfrage in einen Vektor um, dieser wird per Cosine Similarity gegen die gespeicherten Chunk-Embeddings verglichen, die ähnlichsten K Ergebnisse (Top-K) werden zurückgegeben. Baseline.

Query-Expansion / Multi-Query

Statt einer Suchanfrage werden mehrere erzeugt: Ein LLM reformuliert die Original-Query in drei bis fünf Varianten. Jede Variante läuft als eigene Suche, die Ergebnislisten werden per Reciprocal Rank Fusion (RRF) zusammengeführt — einer rang-basierten Formel, die das Problem umgeht, dass Scores aus verschiedenen Suchen nicht direkt vergleichbar sind. Dokumente, die in mehreren Listen auftauchen, steigen im Ranking.

Das ist das, was früher als RAG-Fusion firmierte. Der Begriff ist 2026 kaum noch gebräuchlich — nicht weil die Idee schlecht ist, sondern weil sie disaggregiert wurde: Query-Expansion ist ein Standardbaustein, RRF der Standard-Merge in Hybrid Search sowieso, Multi-Query direkt in LlamaIndex/LangChain eingebaut. Die Komponenten leben weiter, das Label nicht.

HyDE

HyDE dreht die Retrieval-Logik um: Das LLM generiert eine hypothetische Antwort, die als Suchvektor dient statt der originalen Query. Funktioniert, weil ein hypothetisches Antwort-Dokument Vokabular und Stil mit realen Dokumenten teilt — auch wenn es faktisch falsch ist. HyDE eignet sich vor allem dann, wenn es darum geht genau ein passendes Dokument zu einer Anfrage zu finden und wenn aus dem Original-Query zumindest eine “Ahnung” abgeleitet werden kann, was das für ein Dokument sein könnte.

Beispiel: Die Query “Wie regeln wir Überstunden bei Teilzeitkräften?” liefert per Vector Search Chunks über Überstunden allgemein und Chunks über Teilzeit — aber nicht das eine Dokument, das beides zusammen regelt. HyDE generiert eine hypothetische Betriebsvereinbarung, die Formulierungen wie “anteilige Mehrarbeitszuschläge” und “individuelle Wochenarbeitszeit” enthält — Fachsprache, die dem realen Dokument näher ist als die ursprüngliche Frage.

Verwandt mit HyDE ist das o.g. Reverse HyDE, wo im Ingestion-Schritt hypothetische Fragen zu einem Dokument erzeugt werden.

Routing

Nicht immer soll dieselbe Suchstrategie laufen. Ein Classifier oder LLM-Call entscheidet vorab: Welche Quelle? Welche Strategie? Braucht es überhaupt Retrieval? Konzeptionell orthogonal zu Multi-Query: Multi-Query vervielfacht die Query, Routing wählt den Kanal.

Klassisch vs. Agentisch:

Klassisch:
  Query → [LLM: Varianten] → N parallele Suchen → RRF Merge

Agentisch:
  Query → [Agent: Brauche ich Varianten? Welche Quelle? HyDE sinnvoll?]
        → Suche(n) → Ergebnis

Retrieval-Ausführung

Vector Search (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

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.

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.

Graph-basiertes Retrieval

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 Beziehungen per LLM → Knowledge Graph → Community Detection → Zusammenfassungen. Zwei Query-Modi: Local und Global Search. Problem: Indexierungskosten ~10.000x höher als Vector RAG.

LightRAG (HKUDS, EMNLP 2025) löst das pragmatischer: Entitäten und Relationen als kompakte Profile, durchsuchbar per Vektor-Retrieval. Der Graph wird nicht traversiert, sondern als strukturierter Index genutzt. Indexierungskosten nahe Vector RAG, inkrementelle Updates möglich. Stand 2026 die praktisch relevantere Wahl.

RAPTOR (hierarchisches Retrieval)

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

RAPTOR baut vor der Indexierung einen hierarchischen Baum: Chunks werden geclustert — auch dokumentübergreifend — jeder Cluster per LLM zusammengefasst, die Zusammenfassungen wiederum geclustert und zusammengefasst — bis eine Wurzel entsteht. Alle Ebenen fließen in den Index ein.

Zwei Query-Modi: Tree Traversal (schichtweise Navigation, aufwändig) und Collapsed Tree (der Baum wird flachgelegt, alle Nodes per Vektorsuche durchsucht — einfacher, schneller, oft ausreichend).

Nische 2026: Sinnvoll für große, stabile Dokumentkorpora, bei denen Überblicksfragen wichtig sind. Nicht für häufig wechselnde Inhalte — der Baum muss bei Änderungen neu aufgebaut werden. Mit wachsenden Context Windows und agentischen Ansätzen schrumpft die Nische, verschwindet aber nicht.

Trend: Vectorless / File-basiertes Retrieval

Ein Gegenentwurf zum Embedding-Paradigma, getrieben vom Agentic-Drift: Wenn das LLM sowieso reasoned — warum nicht über die Dokumente selbst statt über deren Schattenkopie im Embedding-Raum?

PageIndex (VectifyAI) baut einen hierarchischen Baum-Index (wie ein intelligentes Inhaltsverzeichnis) und lässt das LLM per Reasoning navigieren — kein Chunking, kein Vektorstore. Konzeptionell verwandt mit RAPTOR, aber ohne den Umweg über Embeddings. 98.7% Accuracy auf FinanceBench.

Karpathys “LLM Wiki” geht weiter: Das LLM verarbeitet Quellen einmalig in ein persistentes Wiki — Markdown-Dateien mit Querverweisen. Es gibt kein Retrieval mehr; das Wissen ist bereits kompiliert. Funktioniert nur für überschaubare Wissensbasen.

In der Praxis zeigt sich der Vectorless-Ansatz am deutlichsten in agentischen Systemen, die klassische und file-basierte Strategien kombinieren: Ein Agent, der erst per Hybrid Search Kandidaten-Dokumente identifiziert und dann per Dateisystem-Traversierung und Grep den genauen Abschnitt findet — oder umgekehrt über eine Ordnerstruktur navigiert und nur bei Bedarf semantisch sucht. Das ist kein theoretisches Konstrukt: Claude Code, Cursor und ähnliche Coding-Agents arbeiten genau so — Codebase-Suche über Glob, Grep und gezieltes File-Reading, ergänzt durch semantische Suche wenn nötig.

Das ist noch kein Ersatz für vektorbasiertes RAG bei großen Korpora — aber ein Signal, wohin sich das Feld bewegt. Die Grenze zwischen Indexierung und Retrieval verschwimmt, wenn das LLM beides übernimmt.

Klassisch vs. Agentisch:

Klassisch:
  Query → [fest konfiguriert: Hybrid Search] → Ergebnisse

Agentisch:
  Query → [Agent: Was für eine Frage ist das?
            → Fakten-Lookup: Hybrid Search
            → Beziehungsfrage: LightRAG
            → Überblicksfrage: RAPTOR / Long-Context
            → Dokument finden: HyDE + Vector Search
            → Strukturierte Daten: SQL / API]
        → Ergebnisse

Post-Retrieval

Nach dem Retrieval stellt sich die Frage: Wie gut passen die abgerufenen Chunks zur Anfrage? Und was lässt sich noch verbessern, bevor sie dem LLM übergeben werden?

Re-Ranking

Der initiale Retrieval-Schritt — ob Vector, Hybrid oder Graph — arbeitet mit Bi-Encodern: Query und Dokument werden unabhängig vektorisiert, der Score ist ein einfacher Cosine-Vergleich. Das ist schnell genug für Millionen von Dokumenten, aber semantisch flach.

Ein Cross-Encoder bewertet Query und Dokument gemeinsam — beide Texte fließen in ein Transformer-Modell, das eine gemeinsame Attention-Berechnung durchführt. Das ist um Größenordnungen präziser, aber zu langsam für den ersten Retrieval-Schritt. Die Lösung ist Two-Stage Retrieval: Der Bi-Encoder retrievet die Top-100, der Cross-Encoder re-ranked auf Top-10.

Two-Stage ist kein optionaler Optimierungsschritt — es ist eine Baseline-Komponente. Wer auf Re-Ranking verzichtet, verschenkt Retrieval-Qualität, die mit minimalem Aufwand erreichbar wäre.

Bewertung und Fallback

Re-Ranking sortiert, bewertet aber nicht inhaltlich. Das sogenannte CRAG-Muster (Corrective RAG, Yan et al. 2024) geht einen Schritt weiter: Ein LLM bewertet jeden Chunk explizit als relevant, irrelevant oder unklar. Fällt die Bewertung zu schlecht aus, wird die Suche korrigiert — andere Query, andere Quelle, Fallback auf Web-Suche.

Als eigenständige Architektur ist der Begriff CRAG 2026 kaum noch gebräuchlich — das Muster ist in Workflow- und agentische Pipelines aufgegangen. Aber das zugrunde liegende Prinzip — evaluate, decide, fallback — lebt als Standardbaustein. In einem agentischen System passiert genau das: Der Agent bewertet Ergebnisse, verwirft bei Bedarf und sucht erneut. Nur nicht als vordefinierter Schritt, sondern als emergentes Verhalten im Reasoning-Loop. Die Grenze zwischen einem Workflow, der nach schlechtem Retrieval die Query ändert und nochmal sucht, und einem Agenten ist fließend — dazu mehr im nächsten Kapitel.

Klassisch vs. Agentisch:

Klassisch:
  Retrieval → Top-K → [Cross-Encoder Rerank] → Top-N → LLM

Agentisch:
  Retrieval → Top-K → [Agent: Ergebnisse gut genug?
                        → Nein: Fallback / neue Query / andere Quelle
                        → Ja: weiter] → LLM

Kontroll-Architektur

Die bisherigen Schichten beschreiben, wie gesucht und aufbereitet wird. Die Kontroll-Architektur bestimmt, wer entscheidet, wann und wie oft diese Schritte laufen.

Single-Shot (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.

Workflow (deterministische Schleifen)

Ein vordefinierter Ablauf mit Entscheidungspunkten: Retrieval → Evaluate → bei schlechtem Ergebnis Query anpassen, nochmal suchen. Die Schleife ist finit, das Verhalten determiniert.

Das ist im Grunde das, was CRAG als Forschungsbeitrag beschrieb — und was die meisten produktiven RAG-Systeme heute nutzen: feste Pipelines mit eingebauten Qualitätsprüfungen und Retry-Logik. Der Übergang zum Agenten ist fließend: Ein Workflow, der sein Verhalten kontextabhängig anpasst, ist de facto ein Agent — nur mit Leitplanken.

Adaptive RAG (Routing)

Warum immer suchen, wenn einfache Fragen direkt beantwortbar sind? Ein Classifier oder LLM-Call analysiert die eingehende Query vorab und routet: Einfache Fragen direkt ans Modell, mittlere Komplexität über Standard-RAG, komplexe Fragen über Multi-Step-Retrieval.

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. Routing und Multi-Query sind dabei konzeptionell orthogonal: Multi-Query vervielfacht die Suche, Routing wählt den Kanal.

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.

Self-RAG (Sonderfall)

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 (Asai et al., ICLR 2024). 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.

Synthese

Single-Shot:   Query → Retrieve → Generate → Done

Workflow:      Query → Retrieve → Evaluate
                                    ├── gut → Generate → Done
                                    └── schlecht → Query anpassen → Retrieve (max N×)

Agentic:       Query → [Agent-Loop:
                          Brauche ich Retrieval? → Welche Quelle?
                          → Retrieve → Gut genug?
                          → Nein: andere Query / andere Quelle / parallel
                          → Ja: Generate]
                       → Done (wenn Agent entscheidet)

Die klassischen RAG-Begriffe — Fusion, CRAG, HyDE, Adaptive — beschreiben nicht konkurrierende Architekturen, sondern Taktiken, die eine Kontroll-Architektur kontextabhängig einsetzt. In einem agentischen System tauchen sie als emergentes Verhalten wieder auf: Der Agent macht Fusion, wenn er parallel abfragt. Er macht CRAG, wenn er Ergebnisse verwirft und neu sucht. Er macht HyDE, wenn er zuerst eine hypothetische Antwort formuliert.

Zusammenspiel und Empfehlungen

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

Contextual Retrieval verbessert die Indexierung unabhängig vom Retrieval-Ansatz. Und wenn man schon einen LLM jedes Dokument analysieren lässt, warum nicht im selben Durchlauf — sich Prompt-Caching zunutze machend — weitere Anreicherungen einbauen: Metadaten-Extraktion, Entity Extraction, hypothetische Fragen pro Chunk?

Fusion RAG läuft am besten über Hybrid Search — jede generierte Query als parallele BM25- plus Vektor-Suche. Re-Ranking ist dabei nicht optional, sondern Baseline.

Bei der Kontroll-Architektur verschwimmen die Grenzen am stärksten. Adaptive RAG routet nach Anfragetyp auf verschiedene Retrieval-Strategien. Und diese Strategien können wieder eigene Agenten sein — dann ist man bei Agentic RAG.

Wo anfangen?

Wer eine schnelle, solide Grundlage will, startet mit Contextual Retrieval + Hybrid Search + Cross-Encoder Reranking + Conversational RAG. Das ist kein Kompromiss — es ist die Kombination, die in den meisten realen Szenarien den besten Return on Investment bietet. Die einzelnen Bausteine sind gut verstanden, breit unterstützt und in wenigen Tagen aufgesetzt.

Wenn diese Baseline an ihre Grenzen stößt — etwa weil Beziehungsfragen über mehrere Dokumente hinweg auftauchen oder weil Nutzerinnen sehr unterschiedliche Anfragetypen stellen — lohnt sich der nächste Schritt: LightRAG für Fragen, die Verbindungen zwischen Entitäten erfordern. Query-Expansion für Anfragen, die zu kurz oder zu vage formuliert sind. Adaptive Routing, das eingehende Fragen nach Typ klassifiziert und jeweils die passende Retrieval-Strategie wählt.

Für wirklich komplexe Wissensarbeit — wo im Voraus nicht klar ist, wie viele Quellen relevant sind oder welche Strategie die richtige wäre — führt der Weg zu Agentic RAG: Ein Agent, der selbst entscheidet, welche Tools er nutzt, wie oft er sucht und wann er genug weiß. Das ist mächtig, aber auch teuer und schwerer zu kontrollieren. Workflow-Loops mit eingebauten Qualitätsprüfungen sind oft ein guter Zwischenschritt — sie bieten Schleifen und Fallbacks, ohne die volle Offenheit eines Agenten.

Unabhängig von der Ausbaustufe gilt: Der Dokumentkorpus entscheidet. Wer technische Handbücher, E-Mail-Verläufe und strukturierte Produktdaten in denselben Index wirft, wird mit keiner Strategie glücklich. Ein extrem heterogener Korpus kann eigene Indizes pro Dokumentart erfordern — mit jeweils eigenen Chunking-Strategien, Embedding-Modellen und Retrieval-Ansätzen.

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. Was 2024 eine benannte Technik war, ist 2026 ein Standardbaustein oder absorbiert. Die Begriffe zu kennen hilft beim Sortieren — aber die Architekturentscheidung liegt in der Kombination, nicht in der Wahl eines Labels.