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 (09/2024) misst den Effekt an der Fehlerrate beim Top-20-Retrieval: Contextual Embeddings allein senken sie um 35 %, Contextual Embeddings plus Contextual BM25 (zusammen Contextual Retrieval) um 49 %, mit zusätzlichem Reranker um 67 %. Der Reranker-Schritt drückt die Fehlerrate dabei von 2,9 % auf 1,9 %.

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. Aktuelle Modelle verarbeiten rund 1 Mio. Tokens Kontext, etwa Gemini 3.1 Pro (Preview) und die aktuellen Claude-Modelle. Im klassischen Single-Needle-Test erreichte schon Gemini 1.5 Pro über 99,7 % Recall bei 1 Mio. Tokens; sucht das Modell 100 Needles gleichzeitig, fällt der Wert auf gut 60 % (Gemini-1.5-Report, arXiv:2403.05530). Hinzu kommen ~30–60× höhere Latenz und um Größenordnungen höhere Kosten pro Anfrage gegenüber einer RAG-Pipeline (Schätzung von 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 Orientierungshilfe RAG der deutschen Datenschutzkonferenz (DSK) und an 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 gilt: jede Schicht souverän deployable. In der EU betrifft das etwa den Finanzsektor unter DORA (in Deutschland zusätzlich MaRisk), Medizinprodukte und Diagnostika unter MDR/IVDR, wesentliche und wichtige Einrichtungen unter der nationalen NIS2-Umsetzung (in Österreich dem NISG 2026) und in Deutschland den Public Sector unter dem OZG. In der Schweiz gilt das revidierte Datenschutzgesetz (revDSG), das auf Kompatibilität mit der DSGVO ausgelegt ist.

Die souveräne Infrastruktur im DACH-Raum und in der EU ist 2026 belastbar: Qdrant (Berlin), Weaviate (Amsterdam), Haystack/deepset (Berlin), SAP HANA Cloud Vector Engine und pgvector auf STACKIT/IONOS/OTC/Hetzner. Bei den Modellanbietern hat sich das Bild verschoben. Aleph Alpha (Heidelberg) hat sich von eigenen Frontier-Modellen abgewandt und bietet unter anderem die Plattform PhariaAI an. Im April 2026 hat Cohere den Zusammenschluss mit Aleph Alpha angekündigt, am 16. September 2026 haben beide den Fusionsvertrag unterzeichnet. Das gemeinsame Unternehmen soll als Cohere mit Sitz in Toronto und Berlin auftreten, der Heidelberger Standort soll sich auf Forschung konzentrieren. Der Abschluss steht noch unter dem Vorbehalt behördlicher Genehmigungen. Jina AI (Berlin), Anbieter von Embedding- und Reranker-Modellen, gehört seit Oktober 2025 zu Elastic.

Hinweis zum EU AI Act (Stand 10/2026): Der Digital Omnibus zur KI, Verordnung (EU) 2026/1744, ist seit 27. Juli 2026 in Kraft. Die Pflichten für Hochrisiko-Systeme nach Anhang III gelten damit ab 2. Dezember 2027, für Hochrisiko-KI in Produkten nach Anhang I ab 2. August 2028. Die Transparenzpflichten nach Art. 50 gelten seit dem 2. August 2026. Nur für die maschinenlesbare Kennzeichnung nach Art. 50 Abs. 2 haben Anbieter von Systemen, die schon vor diesem Datum auf dem Markt waren, bis 2. Dezember 2026 Zeit.

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: Beginne mit BM25 + Dense (BGE-M3) + Cross-Encoder-Reranker (BGE Reranker M3) auf einer souveränen Postgres-/pgvector-Basis, klassifiziere personenbezogene Daten vor dem Embedding und miss 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.