RAG vs Context Engineering: Ein Entscheidungs-Framework

RAG — Retrieval Augmented Generation — war die richtige Antwort, als Context Windows bei 4.096 Tokens lagen. Die Daten passten nicht in den Prompt, also baute man ein Retrieval-System: Dokumente in Chunks aufteilen, in Vektoren umwandeln, in einer Vektordatenbank speichern, bei jeder Anfrage die ähnlichsten Chunks abrufen und in den Prompt injizieren. Cleveres Engineering für eine reale Einschränkung.

Aber diese Einschränkung verschwindet. Claude verarbeitet 200K Tokens. Gemini über 1M. Die Grenze, die RAG notwendig gemacht hat, ist weg — die Komplexität nicht.

Das ist kein weiterer "Ist RAG tot?"-Artikel. Davon gibt es genug. Das hier ist ein Entscheidungs-Framework: Wann RAG seine Komplexität verdient, wann nicht, und wie Context Engineering als Alternative aussieht.

Was ist RAG und wie funktioniert Retrieval Augmented Generation?

Retrieval Augmented Generation folgt einer klaren Pipeline. Nimm deine Dokumente — PDFs, Wikis, Datenbankeinträge — und teile sie in Chunks. Jeder Chunk wird mit einem Embedding-Modell in einen numerischen Vektor umgewandelt. Diese Vektoren landen in einer Vektordatenbank wie Pinecone, Weaviate oder pgvector.

Wenn ein Nutzer eine Frage stellt, wird diese Frage ebenfalls in einen Vektor umgewandelt. Dann läuft eine semantische Suche — die Chunks, deren Vektoren am nächsten an der Frage liegen, werden gefunden. Die Top-Ergebnisse werden als Kontext in den LLM-Prompt injiziert.

Das Versprechen: Deine KI beantwortet Fragen anhand deiner echten Daten, statt zu halluzinieren. Das LLM an der Realität verankern. Halluzinationen reduzieren. Wissen aktuell halten, ohne das Modell neu zu trainieren.

Bei 4K-8K Token Context Windows war das brilliant. Mehr als ein paar Seiten passten nicht in den Prompt. RAG war der einzige Weg, einem LLM Zugang zu großen Datensätzen zu geben. Anerkennung wo sie hingehört — RAG hat ein echtes Problem gelöst.

Aber die Situation hat sich grundlegend verändert.

Der RAG-Stack: Was du wirklich baust

Ein produktionsreifes RAG-System braucht mehr Infrastruktur als die meisten Teams erwarten.

Dokumenten-Ingestion. Loader für jedes Format — PDF, HTML, Markdown, Datenbank-Exports. PDF-Parsing allein ist ein Kaninchenbau voller Edge Cases.

Chunking-Strategie. Dokumente in Stücke teilen, die klein genug zum Embedden sind, aber groß genug, um Bedeutung zu erhalten. Überlappende Fenster? Semantische Grenzen? Hier einen Fehler machen und du zerstörst Kontext an Chunk-Grenzen. Ein Fakt in Absatz 3, der von Absatz 1 abhängt? In verschiedene Chunks aufgeteilt, verschwindet diese Verbindung.

Embedding-Modelle. Text in Vektoren umwandeln. OpenAI-Embeddings? Ein domänenspezifisches Modell? Jedes hat andere Dimensionen, Genauigkeitsprofile und Kosten. Modell wechseln heißt: alles neu embedden.

Vektordatenbank. Pinecone, Weaviate, Chroma, Qdrant, pgvector — eine komplette Infrastruktur-Schicht zum Deployen, Skalieren, Monitoren und Bezahlen. Jede mit eigener Query-Sprache, Indexierungsstrategie und Fehlermodellen.

Retrieval und Re-Ranking. Rein semantische Suche? Hybrid mit Keyword-Suche (BM25)? Re-Ranking-Modelle für bessere Präzision? Jede Schicht fügt der RAG-Pipeline Latenz und Komplexität hinzu.

Prompt-Assembly. Abgerufene Chunks formatieren und in den Prompt injizieren. Edge Cases behandeln: zu viele Ergebnisse, widersprüchliche Informationen, irrelevante Chunks die den Similarity-Threshold passiert haben.

Jede einzelne Schicht ist ein potentieller Fehlerquelle. Studien zeigen: etwa 50% der naiven RAG-Fehler stammen aus Retrieval-Limitierungen — das System findet schlicht nicht die richtigen Dokumente. Kein Generierungsproblem. Ein Suchproblem.

Die versteckten Kosten summieren sich: Vektordatenbank-Hosting ($50-500/Monat), 200-500ms zusätzliche Latenz pro Query allein fürs Retrieval, Embedding-Modell-Updates die volles Re-Indexing erfordern, und konstantes Monitoring für Qualitätsverschlechterung.

Semantische Suche hat eine fundamentale Einschränkung, die die meisten RAG-Tutorials überspringen: Ähnlichkeit ist nicht Relevanz. Der Vektor, der deiner Frage am nächsten ist, ist nicht unbedingt der nützlichste für die Antwort.

Von naivem RAG zu Agentic RAG: Was sich wirklich entwickelt

Ist RAG tot? Nein. Aber naives RAG — die Single-Pass Retrieve-then-Generate-Pipeline — reicht für echte Workloads zunehmend nicht mehr aus.

Was sich entwickelt, ist Agentic RAG. Statt einer festen Pipeline steuert ein KI-Agent die Retrieval-Schleife: abrufen → analysieren was fehlt → mit verfeinerter Query erneut abrufen → verifizieren → iterieren. Der Agent passt die Retrieval-Strategie dynamisch an die Query-Komplexität an.

Agentic RAG bewältigt Multi-Hop-Fragen, die Informationen über Dokumente hinweg verbinden. Es erholt sich von schlechten initialen Retrievals durch Query-Reformulierung. Gartner prognostiziert, dass 33% der Enterprise-Software bis 2028 Agentic AI enthalten wird — Agentic RAG ist ein wesentlicher Treiber.

Aber: Agentic RAG trägt immer noch den vollen Infrastruktur-Stack. Vektordatenbanken. Embedding-Pipelines. Chunking-Strategien. Das Retrieval ist smarter, aber die Architektur nicht einfacher.

Das "Lost in the Middle"-Problem

Stanfords "Lost in the Middle"-Forschung unterminiert die RAG-These direkt. LLMs verlieren 10-20+ Prozentpunkte an Genauigkeit, wenn relevante Informationen in der Mitte langer Kontexte liegen. Modelle gewichten Informationen am Anfang und Ende stärker — Primacy und Recency Bias.

RAG-Chunks landen im Prompt typischerweise in der Mitte des Kontexts. Das Retrieval hat perfekt funktioniert — der richtige Chunk wurde gefunden — aber das Modell hat ihn wegen seiner Position untergewichtet.

Und die Ironie: RAG sollte Halluzinationen verhindern. Aber schlechtes Retrieval erzeugt neue Halluzinationsvektoren. Den richtigen Chunk verpassen und der Agent argumentiert auf unvollständigen Daten. Einen teilweise relevanten Chunk injizieren und das Modell generiert selbstbewusst Antworten, die im falschen Kontext verankert sind. Diese Halluzination kam nicht aus den Trainingsdaten — sie kam aus der Retrieval-Pipeline.

RAG vs Fine-Tuning ist eine andere Achse. Fine-Tuning ändert was das Modell permanent weiß. RAG ändert was das Modell pro Query sieht. Beides valide Werkzeuge. Aber keins beantwortet die Architektur-Frage: Brauchst du die Retrieval-Infrastruktur überhaupt?

CAG und direkte Kontext-Injektion: Die einfachere Architektur

Mit 200K+ Token Context Windows gibt es einen Ansatz, den die meisten Teams übersehen: Die Daten direkt in den Prompt packen.

Cache-Augmented Generation (CAG) formalisiert das. Lade dein relevantes Wissen in einen gecachten Prompt-Prefix. Kein Retrieval-Schritt. Keine Vektordatenbank. Kein Chunking. Kein Embedding-Modell. Das LLM sieht alles — voller Kontext, volle Sichtbarkeit, null Retrieval-Latenz.

Die Benchmarks belegen das. Im HotPotQA-Benchmark reduzierte CAG die Generierungszeit von 94,35 Sekunden mit RAG auf 2,33 Sekunden — eine 40-fache Beschleunigung bei gleicher Genauigkeit. Das Paper "Don't Do RAG" (Chan et al., 2024) zeigte: Wenn die Daten ins Context Window passen, erreicht CAG die gleiche oder bessere Performance als RAG — mit dramatisch weniger Komplexität.

Prompt Caching macht das wirtschaftlich. Anthropic und OpenAI bieten Prompt Caching, das Token-Kosten um Faktor 4-10 für gecachte Prefixe senkt. Kontext einmal laden, cachen, und jede folgende Query nutzt die gecachten Tokens zu einem Bruchteil der Kosten. CAG plus Prompt Caching: schnell UND günstig — ohne eine einzige Vektordatenbank.

Direkte Kontext-Injektion überträgt das gleiche Prinzip in Agent-Architekturen: Zur Laufzeit genau die Daten injizieren, die der Agent braucht. Datenbank-Schema. Business-Regeln. Live-API-Daten. Nutzerspezifische Constraints. Der Agent sieht das vollständige Bild — nicht Fragmente, die per Kosinus-Ähnlichkeit ausgewählt wurden.

Die Kostenrechnung, die die meisten Teams falsch machen: Eine RAG-Query kostet ~$0,00008 an Compute. Günstig pro Query. Aber dazu kommen Vektordatenbank ($50-500/Monat), Embedding-Pipeline-Wartung und Engineering-Zeit. Direkte Injektion bei 200K Tokens kostet $0,03-0,10 pro Query ohne jegliche Infrastruktur. Für begrenzte Datensätze und Agent-Systeme ist die Total Cost of Ownership oft niedriger.

Weniger Infrastruktur, weniger Abstraktion, bessere Ergebnisse. Wenn du die Vektordatenbank, die Embedding-Pipeline, die Chunking-Strategie und das Re-Ranking-Modell überspringen kannst — und gleiche oder bessere Ergebnisse bekommst — das ist kein Shortcut. Das ist Architektur.

Was ist Context Engineering und warum macht es RAG optional?

Es gibt einen Begriff, der gerade Traktion gewinnt und genau das beschreibt, was ich seit einem Jahr baue: Context Engineering.

Context Engineering optimiert alles, was das Modell zur Generierungszeit weiß und wahrnimmt. Nicht nur Retrieval — das ist ein kleiner Teil. Context Engineering umfasst Schema-Injektion, Tool-Zugang via MCP, Business-Regeln, Persönlichkeits-Constraints, Live-Daten-Feeds und Verifikationsanforderungen. Die komplette Laufzeitumgebung, die den Output des Modells formt.

RAG wird ein Werkzeug in der Context-Engineering-Toolbox. Nicht der Standard. Nicht obsolet. Nur ein Mechanismus unter mehreren, um Wissen in den Kontext zu bringen — neben direkter Injektion, gecachtem Kontext und MCP-vermitteltem Datenzugang.

Der Context-Engineering-Stack für Agent-Systeme hat drei Schichten:

MCP (Model Context Protocol) — die Verrohrung. Gibt Agents strukturierten Zugang zu APIs, Datenbanken, Business-Logik und externen Tools. MCP vs RAG ist kein Wettbewerb. Sie operieren auf verschiedenen Ebenen. MCP liefert Tool-Zugang. RAG oder CAG liefert Wissens-Zugang.

Kontext-Injektion — das Gedächtnis. Laufzeit-Assembly von Schemas, Regeln, Constraints und relevanten Daten. Hier passt RAG, CAG oder direkte Injektion rein — als ein Mechanismus innerhalb der breiteren Kontext-Assembly.

Agent-Loop — die Entscheidungsschicht. Planen → Ausführen → Verifizieren → Iterieren. Der Agent nutzt seinen assemblierten Kontext und seine Tools, um mehrstufige Aufgaben mit Verifikation bei jedem Schritt zu erledigen.

Was die Industrie jetzt als "Context Engineering" entdeckt, deckt sich direkt mit dem, was ich als Environment Design bezeichne. Das Modell braucht kein besseres Training. Es braucht einen besseren Arbeitsplatz. Gib ihm das Schema, die Business-Regeln, die Live-Daten, die Tools — zur Laufzeit. Die Umgebung wird zum Prompt.

Für Agent-Systeme ist das entscheidend, weil Agents sequentielle Entscheidungen treffen. Jede hängt von korrektem Kontext ab. Ein RAG-Retrieval-Miss bei Schritt 3 eines 10-Schritt-Workflows kaskadiert durch jeden nachfolgenden Schritt. Direkte Injektion eliminiert dieses Risiko, indem der Agent von Anfang an volle Sichtbarkeit hat.

Das Entscheidungs-Framework: Wann nutzt du was?

Keine Ideologie. Kein Tribalismus. Architekturentscheidungen basierend auf echten Constraints.

RAG nutzen wenn:

• Dein Datensatz jedes Context Window übersteigt — Millionen Dokumente, Terabytes an Daten
• Wissen ständig aktualisiert wird und Near-Real-Time-Freshness braucht
• Multi-Tenant-Zugang verschiedene Daten-Slices pro Nutzer erfordert
• Compliance Citation-Tracking und Retrieval-Audit-Trails verlangt
• Unstrukturierte Datensuche im Enterprise-Maßstab

CAG oder direkte Injektion nutzen wenn:

• Dein Datensatz ins Context Window passt (unter 200K Tokens bei Claude, unter 1M bei Gemini)
• Wissen statisch oder semi-statisch ist — Dokumentation, Schemas, Business-Regeln
• Agent-Systeme, wo Latenz sich über mehrstufige Workflows aufsummiert
• Begrenzte Domain mit vorhersagbarem Datenbedarf
• Einfachheit und Wartbarkeit wichtiger sind als theoretische Skalierung

Agentic RAG nutzen wenn:

• Komplexe Multi-Hop-Queries große Dokumentensammlungen durchsuchen
• Query-Komplexität stark variiert und dynamische Retrieval-Strategien erfordert
• Enterprise-Maßstab mit diversen Query-Typen und heterogenen Datenquellen

Das Muster, das ich ständig sehe: Teams greifen standardmäßig zu RAG, weil es die erwartete Architektur ist — nicht weil ihre Constraints es erfordern. Sie bauen Vektordatenbanken für Datensätze, die in ein einziges 200K Context Window passen. Sie warten Embedding-Pipelines für Wissensbasen, die monatlich aktualisiert werden.

Wenn deine Daten in den Kontext passen, überspring RAG. Wenn nicht, nutz RAG. Alles andere ist Optimierung, nicht Architektur.

Komplexität ist keine Architektur

RAG hat ein echtes Problem gelöst. Für viele Use Cases existiert dieses Problem — begrenzte Context Windows — nicht mehr.

Die einfachste Architektur, die funktioniert, ist die beste Architektur. Für Agents in begrenzten Domains heißt das Context Engineering: Laufzeit-Dateninjektion, Tool-Zugang via MCP, Verifikation durch strukturierte Outputs. Keine Vektordatenbank. Keine Embedding-Pipeline. Keine Chunking-Strategie. Volle Sichtbarkeit. Volle Kontrolle.

Was die Industrie als Context Engineering entdeckt — Environment Design, Laufzeit-Injektion, Verifikations-Loops — das ist die Architektur, die tatsächlich zählt. RAG ist ein möglicher Input. Nicht die Architektur selbst.

RAG war die Antwort auf eine 4K-Token-Welt. Ich lebe nicht mehr dort. Bau die Umgebung, nicht die Retrieval-Pipeline.