RAG — Retrieval-Augmented Generation — ist 2026 fast schon Commodity. Vektor-Datenbank, Embeddings, semantische Suche, Kontextinjektion. Funktioniert in PoCs glänzend, in der Produktion aber nur halb. Der Grund ist meist nicht das RAG selbst — es ist, dass nur RAG verwendet wird, ohne die operative Schicht darüber zu denken.
Wo reines RAG an Grenzen stößt
Latenz: Jede Anfrage triggert einen Embedding-Aufruf plus Vektor-Suche. Bei hochfrequenten, wiederkehrenden Fragen ist das Verschwendung.
Stale Embeddings: Wenn sich die Quelldokumente ändern, müssen Embeddings neu berechnet werden. Ohne Pipeline driftet die Wissensbasis weg.
Schlechte Relevanz bei strukturierten Queries: Semantische Ähnlichkeit ist nicht immer das, was man will — manchmal will man einen exakten Code, eine Vertragsklausel, ein Produkt-SKU.
CAG: Cache-Augmented Generation
CAG ergänzt RAG um eine Cache-Schicht. Häufige Anfragen werden mit ihren Antworten oder ihren Retrieval-Resultaten zwischengespeichert — granular, mit definierter Invalidierung. Das ist nicht nur eine Performance-Optimierung, sondern Voraussetzung dafür, dass Wissen operativ wird und nicht nur „”.
Drei Cache-Ebenen, die sich in der Praxis bewähren:
- Query-Cache: Vollständige (Frage → Antwort)-Tupel mit kurzer TTL.
- Retrieval-Cache: (Frage → Treffer-IDs) mit längerer TTL — die Generation darüber kann variieren.
- Embedding-Cache: (Text → Vektor) deduplizieren, spart drastisch Embedding-Kosten.
Hybride Suche statt Vektor-Only
Reine Vektor-Suche ist gut für „”. Für „” ist BM25 oder ein keyword-basierter Ansatz besser. Produktive Systeme kombinieren beides:
- Vektor-Suche für semantische Ähnlichkeit (z. B. via pgvector, Qdrant, Pinecone).
- BM25 oder Elasticsearch für exakte Treffer.
- Re-Ranker (z. B. Cohere Rerank), um die kombinierten Top-K zu ordnen.
Welche Konkretion zum Einsatz kommt, hängt vom Datenbestand ab. Bei 100 k strukturierten Tickets ist Elasticsearch + Rerank meist überlegen. Bei freiem Fließtext gewinnt der Vektor-Ansatz.
Wissen als Operating Knowledge
RAG/CAG wird erst dann wirksam, wenn das Wissen Teil des operativen Schritts ist — nicht eine separate Recherche-Funktion. Konkret heißt das:
- Ein Klassifikations-Agent zieht die zuletzt geänderten Policies, bevor er ein Ticket einordnet.
- Ein Tool-Use-Agent prüft den Customer-Status aus der CRM-Vektorbasis, bevor er einen Rabatt anwendet.
- Ein Eskalations-Agent zieht die letzten drei ähnlichen Fälle, bevor er an einen Menschen übergibt.
Diese Verzahnung ist es, was unter dem Begriff Operating Knowledge zusammengefasst wird — Wissen ist nicht „”, sondern ein integrierter Bestandteil jedes Agent-Schritts.
Praxis: was wir typischerweise einsetzen
- pgvector als embedded Vektor-Layer in der PostgreSQL — keine zusätzliche DB.
- Qdrant für höhere Volumina oder Multi-Tenant-Setups.
- Redis als L1-Cache für Query- und Retrieval-Cache.
- Re-Ranking über Cohere Rerank oder bge-reranker-base, je nach Datenschutz-Anforderung.
- OpenAI text-embedding-3-large oder Voyage AI für Embeddings — beide DSGVO-konform nutzbar.
Fazit
RAG ist die Basis, CAG die produktive Erweiterung, hybride Suche der Qualitätshebel. Wer Wissen operativ verfügbar macht, statt es nur als Recherche-Werkzeug zu bauen, verändert die Wirksamkeit des Agent-Systems — messbar in Antwortqualität, Latenz und Tokenkosten.