RAG-Systeme erklärt

Was ist RAG? Eine klare Definition

Retrieval-Augmented Generation (RAG) bezeichnet ein Verfahren, bei dem ein Large Language Model (LLM) vor der Generierung einer Antwort gezielt externe Wissensinhalte abruft (Retrieval) und in den Prompt einbettet (Augmentation), um die Generierung auf nachprüfbare Quellen zu stützen. Die Originaldefinition stammt von Lewis et al. (Facebook AI Research, NeurIPS 2020) und beschreibt RAG als Kombination aus parametrischem Gedächtnis (dem trainierten Sprachmodell) und nicht-parametrischem Gedächtnis (einem externen, durchsuchbaren Index).

Über die verschiedenen kanonischen Definitionen hinweg lässt sich ein Konsens-Minimum festhalten: Ein RAG-System besteht aus drei Pflichtelementen — (i) einem externen Wissensspeicher mit Index, (ii) einem Retriever, der relevante Passagen findet, und (iii) einem Generator-LLM, dessen Prompt um die gefundenen Inhalte ergänzt wird. Der zentrale Nutzen: RAG liefert quellengestützte, nachvollziehbare Antworten, reduziert Halluzinationen messbar und hält Wissen aktuell, ohne dass das Modell neu trainiert werden muss.

Warum RAG? Das Problem, das es löst

LLMs haben drei strukturelle Schwächen: Sie halluzinieren, ihr Wissen ist auf den Trainingsstand eingefroren, und ihre Antworten sind nicht nachvollziehbar. RAG adressiert alle drei. Statt das Modell mit teurem Fine-Tuning auf neuen Daten zu trainieren, wird das relevante Wissen pro Anfrage zur Laufzeit nachgeladen. Aktualisierungen sind damit so einfach wie eine Re-Indexierung; Quellenangaben (Citations) sind nativ über Chunk-IDs möglich; und die Antwort bleibt an nachprüfbares Material gebunden.

Genau diese Eigenschaften machen RAG zum De-facto-Standard-Pattern für Enterprise-KI im DACH-Raum, wo Nachvollziehbarkeit, Aktualität und Datenkontrolle nicht optional, sondern regulatorisch und vertrauensseitig gefordert sind.

Die RAG-Pipeline: Indexing- und Query-Pfad

Ein produktives RAG-System hat zwei Pfade. Der Indexing-Pfad (offline/Batch) verarbeitet die Wissensquellen: Connectoren laden Dokumente aus SharePoint, S3, Confluence oder Datenbanken; ein Parser (z. B. Docling) extrahiert layout-treu Text, Tabellen und Strukturen; ein Chunker zerlegt die Inhalte; ein Embedding-Modell erzeugt Vektoren; und ein Upsert schreibt diese mit Metadaten (Tenant-ID, ACL, Quelle, Zeitstempel) in die Vektordatenbank — optional begleitet von einem parallelen BM25-Index.

Der Query-Pfad (online) beginnt mit der Nutzeranfrage, optional umgeschrieben (Query Rewriting, HyDE). Dann läuft ein Hybrid-Retrieval (typisch top_k = 50–100), gefolgt von einem Re-Ranker, der auf die relevantesten 5–10 Passagen verdichtet. Diese werden in ein Prompt-Template mit Quellen-Zitierung eingesetzt und an das LLM übergeben; ein Faithfulness-Check kann die Antwort gegen die Quellen prüfen.

Embeddings und Vektordatenbanken

Embeddings sind numerische Vektor-Repräsentationen von Text, in denen semantische Nähe als geometrische Nähe abgebildet wird (Cosine Similarity als Default für normalisierte Vektoren). Für deutschsprachige Korpora gilt eine wichtige Regel: Der englische MTEB-Rang ist nicht der deutsche Rang. Modelle, die im Englischen führen, verlieren auf deutschen Komposita, Fachsprache und langen Wörtern oft 5–15 nDCG@10-Punkte. Maßgeblich sind deutsche bzw. multilinguale Benchmarks (MMTEB, MIRACL-de, MTEB-DE). Deutsche Komposita führen zudem zu mehr Tokens — Faustregel: DE ist je nach Modell rund 1,3–1,7× tokenintensiver als EN.

Vektordatenbanken speichern Embeddings und beantworten Ähnlichkeitsanfragen über Approximate-Nearest-Neighbour-Indizes. Der Standard-Algorithmus ist HNSW (Hierarchical Navigable Small World, Malkov & Yashunin 2016), der in nahezu allen produktiven Systemen läuft — von Qdrant über Weaviate, Milvus und pgvector bis SAP HANA. Praktischer Richtwert: HNSW liefert 95–99 % Recall und ist bis ~100 Mio. Vektoren komfortabel; darüber helfen Quantisierung (halfvec, SQ8) oder disk-basierte Verfahren wie DiskANN.

Für den DACH-Mittelstand unter ~10–50 Mio. Vektoren ist pgvector auf einer managed Postgres (IONOS, STACKIT, OTC, Hetzner) der pragmatische souveräne Default: eine Datenbank, eine Backup-Story, eine AVV-Kette. Konzerne fahren typischerweise zwei oder drei Stores parallel — SAP HANA Vector für SAP-residente Daten plus eine dedizierte Vektor-DB (Qdrant, Weaviate) für unstrukturierte Dokumente.

Chunking: Wie Wissen zerlegt wird

Chunking entscheidet maßgeblich über die Retrieval-Qualität. Naives Fixed-Size-Chunking (z. B. 512 Tokens, 50 Token Overlap) ist robust, zerschneidet aber Sätze, Tabellen und Listen — ein häufiges Anti-Pattern. Bessere Strategien:

• Recursive/Semantic Chunking respektiert Dokumentstruktur bzw. schneidet an inhaltlichen Sprungstellen.
• Hierarchical (Parent-Child) nutzt kleine Chunks zum Retrieval und große Parent-Chunks als Generator-Kontext.
• Contextual Retrieval (Anthropic, 09/2024) stellt jedem Chunk vor dem Embedding einen kurzen, LLM-generierten Kontext-Header voran. Ergebnis: −49 % Retrieval-Fehler, −67 % mit zusätzlichem Reranker. Der Preis ist ein LLM-Call pro Chunk zur Ingest-Zeit.
• Late Chunking (Jina, 2024) kehrt die Reihenfolge um: Zuerst wird das ganze Dokument mit einem Long-Context-Embedder eingebettet, dann werden die Token-Embeddings über die Chunk-Grenzen gemittelt — die Chunk-Vektoren behalten so den Dokumentkontext. Late Chunking ist zur Ingest-Zeit praktisch kostenlos (kein zusätzlicher LLM-Call) und in der Jina-Studie ~24 % besser als naives Chunking. Für kostendisziplinierte DACH-Projekte ist Late Chunking mit Jina v3/v4 oder BGE-M3 oft der ertragreichere Default.

Bei layout-lastigen PDFs (Verträge, Behörden-Korrespondenz, IFRS-Berichte) gewinnen layout-aware Parser (Docling, Marker) — und perspektivisch multimodale Ansätze wie ColPali/ColQwen oder Jina v4, die jede Seite als Bild rendern und so OCR- und Layout-Fehler umgehen.

Hybrid Search und Reranking

Hybrid Search kombiniert Dense-Retrieval (Embeddings, semantische Nähe) mit Sparse-Retrieval (BM25 oder gelernte sparse Modelle wie SPLADE/ELSER) und fusioniert die Ergebnisse, üblicherweise via Reciprocal Rank Fusion (RRF). Der Grund: Reine Embeddings verfehlen exakte Codes, IDs, Aktenzeichen, SAP-Materialnummern oder IBANs — genau die Tokens, die in der DACH-B2B-Praxis zählen. BM25 fängt diese ab. Bei Deutsch mit Komposita und Fachsprache liefert Hybrid gegenüber Dense-only konsistent 5–15 nDCG@10-Punkte mehr.

Reranking ist die zweite, präzisere Sortierstufe: Ein Cross-Encoder rechnet Query und Dokument gemeinsam und bewertet die Top-Kandidaten neu. Das ist die ROI-stärkste Einzelverbesserung der gesamten Pipeline — typisch +5–15 Prozentpunkte recall@5. Die Anthropic-Studie quantifizierte den kombinierten Effekt: Embeddings + BM25 ergeben −49 % Retrieval-Fehler gegenüber Embeddings-only; mit Contextual Retrieval und Reranker zusammen −67 %.

Latenz-Budget für eine DACH-Standard-Pipeline (10 Mio. Vektoren): BM25- und Dense-Erststufe je 10–50 ms, RRF unter 1 ms, Cross-Encoder-Reranker (z. B. BGE Reranker M3 auf einer GPU) 100–300 ms — gesamt 150–500 ms vor der LLM-Generierung. Bei harten Sub-100-ms-SLAs ist der Reranker der erste Kandidat zum Weglassen, gegen einen Recall-Verlust von 5–15 Punkten.

RAG vs. Alternativen: Wann was?

RAG ist nicht die einzige Strategie. Die Wahl gegenüber Fine-Tuning, Long-Context und Prompt Engineering hängt vom Ziel ab:

Eine offene, aber zunehmend geklärte Debatte ist Long-Context vs. RAG. Moderne Modelle bieten riesige Kontextfenster (Gemini 2.5: 1 Mio. Tokens, Claude: 200 k). Im klassischen Single-Needle-Test erreicht Gemini 1.5 Pro bis 99,7 % Recall bei 1 Mio. Tokens — bei realistischem Multi-Needle-Retrieval fällt der Wert jedoch auf rund 60 % (arXiv:2407.01370). Hinzu kommen ~30–60× höhere Latenz und ~1250× höhere Kosten pro Anfrage gegenüber einer RAG-Pipeline (qualitativer Vergleich, Tian Pan 2026). Der Konsens 2026: Long-Context ergänzt RAG für engumrissene Workloads, ersetzt es aber für Multi-Needle-, Multi-Tenant- und kostensensitive Szenarien selten.

DSGVO und souveräner Betrieb im DACH-Raum

Hinweis: Die folgenden Aussagen sind informativ und stellen keine Rechtsberatung dar.

Eine der materiell wichtigsten DSGVO-Fragen 2025/2026 lautet: Sind Embeddings personenbezogene Daten? Die ehrliche Antwort lautet „höchstwahrscheinlich ja, sofern aus personenbezogenen Daten abgeleitet". Inversions-Angriffe rekonstruieren bis zu 92 % von 32-Token-Eingaben exakt (Morris et al., EMNLP 2023) — ein Embedding ist also keine sichere Pseudonymisierung. Die EDPB-Opinion 28/2024 fordert eine fallweise Re-Identifikations-Risikobewertung; das CJEU-Urteil C-413/23 P (September 2025) präzisiert, dass pseudonymisierte Daten nicht automatisch für jeden Empfänger personenbezogen sind, engt die Pflichten aber nur ein, statt sie aufzuheben.

Praktische Konsequenzen für RAG-Architekturen, orientiert an der DSK-Orientierungshilfe RAG und EDPB-Vorgaben:

• Recht auf Löschung (Art. 17): Auch Embeddings und Chunks müssen löschbar sein. HNSW-Graphen unterstützen Punkt-Löschung unterschiedlich gut — Löschsemantik ist ein hartes Beschaffungskriterium (pgvector und Qdrant löschen effizient).
• Mandantentrennung: Tenant-ID und ACL in den Metadaten, Filter bei jeder Query, Defense-in-Depth (Auth + Filter + Re-Check + Audit-Log). Ein geteilter Index ohne Tenant-Filter ist ein DSGVO-Unfall mit Ansage.
• Datenresidenz: EU-Region-Hosting bevorzugen; bei US-Cloud-Anbietern CLOUD-Act-/FISA-702-Restrisiko bewerten (SCC + TIA). Eine Embedding-Übertragung in eine US-gehostete Vektor-DB ist ein Drittland-Transfer.
• Minimierung vor dem Embedding: Namen, E-Mails, IDs nach Möglichkeit vor dem Embedding entfernen oder durch stabile Pseudonyme ersetzen; Vektoren mit kundenverwalteten Schlüsseln (CMK/BYOK) verschlüsseln.

Für regulierte Workloads (BFSI unter MaRisk/DORA, Health unter MDR/IVDR, KRITIS unter NIS2, Public Sector unter OZG) gilt: jede Schicht souverän deployable. Die souveräne DACH-/EU-Landschaft ist 2026 belastbar — Qdrant (Berlin), Weaviate (Amsterdam), Haystack/deepset (Berlin), SAP HANA Cloud Vector Engine, pgvector auf STACKIT/IONOS/OTC/Hetzner sowie Aleph Alpha (Heidelberg) und Jina (Berlin) als DACH-native Modellanbieter. Hinweis zum EU AI Act (Stand 05/2026): Die politische Einigung des Digital Omnibus vom 7. Mai 2026 schlägt vor, die Hochrisiko-Regeln auf den 2. Dezember 2027 zu verschieben — formal noch nicht verabschiedet (provisorisch); die Art. 50 Transparenzpflichten bleiben unverändert beim 2. August 2026.

Qualitätssicherung mit RAGAS

Ein RAG-System ohne Evaluation regrediert still. Der De-facto-Standard ist RAGAS mit den Kernmetriken Faithfulness (Treue zur Quelle), Answer Relevancy, Context Precision und Context Recall — ergänzt durch TruLens („RAG Triad") oder DeepEval. Sinnvoll ist ein Goldset plus LLM-as-Judge plus A/B-Tests in der Produktion, fest verankert in der CI-Pipeline. Citation-Forcing, Faithfulness-Guardrails und Antwortverweigerung bei niedrigem Score sind die Standardmittel gegen Halluzinationen trotz RAG.

Ausblick und Praxis-Hinweis

Vektordatenbanken und Embedding-Modelle haben sich auf API-Ebene weitgehend commoditisiert — HNSW ist überall, Hybrid Search ist Standard, und Multimodalität (ColPali, Jina v4) ist die neue Grenze. Parallel entwickelt sich RAG entlang der Stufen Naive → Advanced → Modular → Agentic RAG weiter, wobei Retrieval zunehmend als dynamisches Tool eines Agenten begriffen wird (Singh et al. 2025).

Der pragmatische Einstieg für ein DACH-Projekt: Beginnen Sie mit BM25 + Dense (BGE-M3 oder Jina v4) + Cross-Encoder-Reranker (BGE Reranker M3) auf einer souveränen Postgres-/pgvector-Basis, klassifizieren Sie personenbezogene Daten vor dem Embedding und messen Sie Qualität von Tag eins mit RAGAS. Was 2026 architektonisch dominiert, ist nicht mehr die rohe Performance, sondern die Frage, wo die Embeddings liegen, wer sie erreichen kann und ob der Stack im Zweifel On-Prem geholt werden kann — ein souverän, deutschsprachig und Open-Source-orientiert geplanter RAG-Stack ist die belastbare Antwort.