--- title: "RAG-Systeme erklärt" description: "Wie RAG-Systeme LLMs mit externem Wissen versorgen; Retrieval, Embeddings, Vektordatenbanken und genaue Antworten." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system" category: "KI Agenten" updated: "2026-07-29T08:53:27.479Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # RAG-Systeme erklärt Wie RAG-Systeme LLMs mit externem Wissen versorgen; Retrieval, Embeddings, Vektordatenbanken und genaue Antworten. ## Was ist RAG? Eine klare Definition Retrieval-Augmented Generation (RAG) bezeichnet ein Verfahren, bei dem ein [Large Language Model](/de/glossar/large-language-model) (LLM) vor der Generierung einer Antwort gezielt externe Wissensinhalte abruft (Retrieval) und in den [Prompt](/de/glossar/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](/de/glossar/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](/de/glossar/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](/de/glossar/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](/de/services/ki-agent-integration), 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](/de/wissen/ki-agenten/was-ist-ein-rag-system/embedding-modelle-vergleich)und ein Upsert schreibt diese mit Metadaten (Tenant-ID, ACL, Quelle, Zeitstempel) in die [Vektordatenbank](/de/glossar/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](/de/wissen/ki-agenten/was-ist-ein-rag-system/vector-databases-vergleich) 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. | Vektor-DB | Herkunft | Lizenz | Hybrid Search | DACH-/EU-Hosting | | --- | --- | --- | --- | --- | | **Qdrant** | Berlin (DE) | Apache 2.0 | ja (BM25/SPLADE) | ja (On-Prem, STACKIT, air-gapped) | | **Weaviate** | Amsterdam (NL/EU) | BSD-3 | ja | ja (EU-Region) | | **pgvector** | OSS (Postgres) | PostgreSQL-Lizenz | via tsvector/ParadeDB | überall wo Postgres läuft | | **SAP HANA Vector** | DE (SAP) | kommerziell | mit Full-Text | ja (BTP, Sovereign Cloud, Delos) | | **Pinecone** | New York (US) | proprietär SaaS | ja | EU-Region, aber kein On-Prem | 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](/de/wissen/ki-agenten/was-ist-ein-rag-system/pinecone-vs-weaviate-vs-qdrant) (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](/de/glossar/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](/de/glossar/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](/de/glossar/roi)-stärkste Einzelverbesserung der gesamten Pipeline; typisch +5–15 Prozentpunkte recall@5. Die [Anthropic-Studie](https://www.anthropic.com/research) 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](/de/glossar/prompt-engineering) hängt vom Ziel ab: | Dimension | RAG | Fine-Tuning | Long-Context | | --- | --- | --- | --- | | **Wissens-Update** | sehr einfach (Re-Index) | aufwendig (Re-Train) | pro Query teuer | | **Quellenangabe** | nativ (Chunk-IDs) | nicht möglich | möglich, aber unsicher | | **Halluzinationsrisiko** | niedrig (mit Rerank + Faithfulness) | mittel (eingefrorenes Wissen) | mittel-hoch (lost-in-the-middle) | | [**DSGVO](/de/glossar/dsgvo)-Steuerbarkeit** | gut (ACL, Lösch-Pipeline) | problematisch (Wissen im Modell) | bei Closed-[API](/de/glossar/api) problematisch | 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](https://dsgvo-gesetz.de/)-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)](/de/wissen/ki-agenten/dsgvo-konform-ai-agents-einsetzen/mistral-aleph-alpha-eu-anbieter) und Jina (Berlin) als DACH-native Modellanbieter. Hinweis zum [EU AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) (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: Beginne mit **BM25 + Dense (BGE-M3 oder Jina v4) + 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. ## Artikel - [Agentic RAG vs. klassisches RAG: Was ist der Unterschied?](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/agentic-rag-vs-klassisches-rag) — Agentic RAG ist eine RAG-Variante, bei der ein KI-Agent dynamisch entscheidet, ob, was und wie oft Wissen abgerufen wird. Retrieval wird zum - [Corrective RAG und Self-RAG: Selbstkorrigierende Retrieval-Pattern für weniger Halluzinationen](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/corrective-rag-self-rag) — Corrective RAG (CRAG) und Self-RAG sind selbstkorrigierende Retrieval-Pattern. CRAG bewertet die Relevanz abgerufener Treffer und schaltet b - [Multimodales RAG: Bilder, PDFs und Tabellen retrievern](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/multimodales-rag) — Multimodales RAG erweitert klassische Retrieval-Augmented-Generation um nicht-textuelle Inhalte: Bilder, gescannte PDFs, Tabellen, Charts un - [RAG-Evaluation: RAGAS, TruLens und DeepEval im Vergleich](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/rag-evaluation-ragas-trulens) — RAG-Evaluation ist die systematische, messbare Qualitätsprüfung eines Retrieval-Augmented-Generation-Systems. Sie bewertet getrennt, ob das - [RAG-Systeme DSGVO-konform aufbauen: Praxis-Leitfaden](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/rag-dsgvo-konform-aufbauen) — Ein DSGVO-konformes RAG-System verarbeitet personenbezogene Daten in Quelldokumenten, Vektor-Index und Embeddings nur auf gesicherter Rechts - [RAG on-premise vs. EU-Cloud: Entscheidungsmatrix für Hosting-Optionen](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/rag-on-premise-vs-cloud-eu) — RAG on-premise vs. Cloud bezeichnet die Hosting-Entscheidung für ein Retrieval-Augmented-Generation-System: On-premise (self-hosted) läuft a - [RAG-Architektur: Ingestion, Retrieval, Generation, Reranking](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/rag-architektur-komponenten) — Die RAG-Architektur ist der zweiphasige Aufbau eines Retrieval-Augmented-Generation-Systems: Im Ingestion-Pfad werden Dokumente geladen, gec - [Embedding-Modelle 2026 im Vergleich: text-embedding-3, Cohere, BGE-M3, Voyage & Jina](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/embedding-modelle-vergleich) — Ein Embedding-Modell-Vergleich bewertet Modelle wie OpenAI text-embedding-3, Cohere Embed v4, BGE-M3, Voyage und Jina anhand von Dimensionen - [Vector Database Vergleich: Pinecone, Weaviate, Qdrant, Milvus, pgvector & Co. im Enterprise-Check](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/vector-databases-vergleich) — Ein Vector Database Vergleich bewertet Vektordatenbanken anhand von Hosting, Skalierung, Metadaten-Filtering, Hybrid-Search, Konsistenz, Kos - [Pinecone vs. Weaviate vs. Qdrant: Vektor-DB-Vergleich aus DACH/EU-Hosting-Perspektive](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/pinecone-vs-weaviate-vs-qdrant) — Pinecone, Weaviate und Qdrant sind die drei meistgenutzten Vektor-Datenbanken für RAG-Systeme. Aus DACH-Sicht entscheidet weniger die Perfor - [Chunking-Strategien für RAG: Fixed, Semantic, Hierarchical und Late Chunking im Vergleich](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/chunking-strategien-fuer-rag) — Chunking-Strategien für RAG legen fest, wie ein Dokument vor dem Embedding in durchsuchbare Textabschnitte (Chunks) zerlegt wird. Die Wahl d - [Hybrid Search im RAG: BM25 und Vector Similarity richtig kombinieren](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/hybrid-search-bm25-und-vector) — Hybrid Search im RAG kombiniert lexikalische Suche (BM25/Keyword-Matching) mit dense Vector-Similarity. Beide Retriever laufen parallel, ihr - [Reranking in RAG: Cross-Encoder vs. Bi-Encoder](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/reranking-modelle-rag) — Reranking ist die zweite Retrieval-Stufe in einer RAG-Pipeline: Ein Cross-Encoder bewertet die vom schnellen Bi-Encoder gefundenen Top-Kandi - [Graph RAG: Wenn Beziehungen wichtiger sind als Ähnlichkeit](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/graph-rag-erklaert) — Graph RAG ist ein Retrieval-Augmented-Generation-Ansatz, der Wissen nicht (nur) als Vektoren, sondern als Knowledge Graph aus Entitäten und --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.