RAG vs. CAG

Die Kernfrage

Du willst ein LLM mit eigenem Wissen versorgen. RAG ist der etablierte Weg – aber mit immer größeren Kontextfenstern und Prompt Caching ist eine Alternative entstanden: CAG (Cache-Augmented Generation).

• RAG: Zur Laufzeit werden die relevantesten Chunks per Retrieval aus einer Wissensbasis geholt und dem Modell als Kontext mitgegeben
• CAG: Die gesamte Wissensbasis wird vorab in den Kontext geladen und per KV-/Prompt-Caching wiederverwendet – ganz ohne Retrieval

Die Entscheidung hängt vor allem an einer Frage: Wie groß ist deine Wissensbasis – und wie oft ändert sie sich?

Wie RAG funktioniert

Bei RAG wird die Wissensbasis vorverarbeitet: Dokumente werden per Chunking in Abschnitte zerlegt, als Embeddings in eine Vektordatenbank geschrieben und zur Laufzeit über semantische Suche abgerufen. Nur die Top-Treffer landen im Prompt.

Stärken:

• Skaliert auf beliebig große Korpora – Millionen Dokumente sind kein Problem
• Updates sind billig: geändertes Dokument neu embedden, fertig
• Zugriffskontrolle möglich: Retrieval kann pro Nutzer filtern
• Schlanke Prompts: nur relevante Chunks kosten Tokens

Schwächen:

• Eine ganze Pipeline will gepflegt werden: Chunking-Strategie, Embedding-Modell, Re-Ranking
• Retrieval kann danebenliegen – dann fehlt dem Modell die entscheidende Information
• Der Retrieval-Schritt kostet Latenz bei jeder Anfrage

Wie CAG funktioniert

CAG dreht den Spieß um: Statt zur Laufzeit zu suchen, wird die komplette Wissensbasis einmal in den Kontext geladen. Moderne Modelle mit großen Kontextfenstern machen das möglich, und KV-/Prompt-Caching macht es bezahlbar – der statische Wissensblock wird nur einmal verarbeitet und danach aus dem Cache bedient.

Stärken:

• Keine Retrieval-Infrastruktur: keine Vektordatenbank, keine Embedding-Pipeline, kein Chunking-Tuning
• Keine Retrieval-Fehler: das Modell sieht garantiert alle Informationen
• Niedrige Latenz pro Anfrage, weil der Suchschritt entfällt
• In Minuten aufgesetzt statt in Tagen

Schwächen:

• Funktioniert nur bei begrenztem Korpus – das Kontextfenster ist die harte Grenze
• Bei jeder Datenänderung muss der Cache neu aufgebaut werden
• Sehr lange Kontexte können die Antwortqualität drücken (Lost in the Middle)
• Keine feingranulare Zugriffskontrolle: alle Nutzer sehen denselben Kontext

Wann was?

CAG wählen, wenn:

• Die Wissensbasis klein und stabil ist (Handbuch, FAQ, Richtlinien-Sammlung, Produktdoku eines einzelnen Produkts)
• Du schnell und ohne Infrastruktur starten willst
• Alle Nutzer auf dasselbe Wissen zugreifen dürfen
• Latenz wichtiger ist als Korpusgröße

RAG wählen, wenn:

• Der Korpus groß ist oder wächst (Wikis, Ticketsysteme, Dokumentenarchive)
• Sich Inhalte häufig ändern
• Berechtigungen pro Nutzer oder Mandant nötig sind
• Du Quellenangaben pro Antwort gezielt nachverfolgen willst

Typische Praxis-Szenarien

CAG in Aktion: Ein Support-Assistent für ein einzelnes SaaS-Produkt. Die gesamte Produktdokumentation, die FAQ und die Onboarding-Guides ergeben zusammen einen überschaubaren Textbestand, der bequem ins Kontextfenster passt. Das Team lädt alles einmal in den Kontext, aktiviert Prompt Caching und ist nach einem Nachmittag produktiv – ohne eine einzige Zeile Retrieval-Code.

RAG in Aktion: Ein interner Wissensassistent für ein Unternehmen mit Confluence-Wiki, Ticketsystem und Vertragsarchiv. Hunderttausende Dokumente, tägliche Änderungen, dazu Berechtigungen: Die Rechtsabteilung darf Verträge sehen, das Marketing nicht. Hier führt kein Weg an einer Retrieval-Pipeline mit Vektordatenbank, sauberem Chunking und Rechte-Filterung vorbei.

Der Graubereich dazwischen ist die eigentlich interessante Zone: Eine Wissensbasis, die gerade noch in den Kontext passt. Hier lohnt der Blick auf die Änderungsrate – bei täglichen Updates frisst der ständige Cache-Neuaufbau die Ersparnis schnell auf, und RAG wird trotz kleinerem Korpus zur wirtschaftlicheren Lösung.

Entscheidungsbaum

Passt die gesamte Wissensbasis komfortabel ins Kontextfenster?
├── Nein → RAG
└── Ja
    └── Ändern sich die Daten häufig oder brauchst du Rechte-Filter?
        ├── Ja → RAG (oder Hybrid)
        └── Nein → CAG

Die Kombination

RAG und CAG schließen sich nicht aus. Ein bewährtes Hybrid-Muster:

1. Kern-Wissen (stabil, für alle gleich) liegt dauerhaft gecacht im Kontext
2. Long-Tail-Wissen (groß, dynamisch, rechtegebunden) kommt per Retrieval aus der Vektordatenbank dazu

So kombinierst du die Zuverlässigkeit von CAG für das Wichtigste mit der Skalierbarkeit von RAG für den Rest – und sparst gleichzeitig Tokens, weil der gecachte Teil nicht bei jeder Anfrage neu berechnet wird.

Faustregel: Starte mit dem einfachsten Ansatz, der funktioniert. Für viele kleine Wissensbasen ist das heute CAG – RAG wird erst nötig, wenn Umfang, Änderungsrate oder Zugriffsrechte es erzwingen. Und weil beide Ansätze dieselben aufbereiteten Dokumente nutzen, ist der spätere Wechsel von CAG zu RAG kein Neuanfang, sondern ein Ausbau.