--- title: "RAG-Architektur: Ingestion, Retrieval, Generation, Reranking" description: "Die RAG-Architektur ist der zweiphasige Aufbau eines Retrieval-Augmented-Generation-Systems: Im Ingestion-Pfad werden Dokumente geladen, gechunkt, in Vektoren eingebettet und indexiert; im Query-Pfad werden zur Anfrage passende Passagen abgerufen, neu sortiert (Reranking) und als Kontext an ein LLM zur Antwortgenerierung übergeben." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/rag-architektur-komponenten" category: "KI Agenten" topic: "RAG-Systeme erklärt" updated: "2026-07-29T08:22:43.500Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # RAG-Architektur: Ingestion, Retrieval, Generation, Reranking Die RAG-Architektur ist der zweiphasige Aufbau eines Retrieval-Augmented-Generation-Systems: Im Ingestion-Pfad werden Dokumente geladen, gechunkt, in Vektoren eingebettet und indexiert; im Query-Pfad werden zur Anfrage passende Passagen abgerufen, neu sortiert (Reranking) und als Kontext an ein LLM zur Antwortgenerierung übergeben. ## Kernaussagen - Eine RAG-Pipeline besteht aus zwei getrennten Pfaden: dem offline laufenden Ingestion-/Indexing-Pfad (Loading, Chunking, Embedding, Upsert in Vektor-DB) und dem online laufenden Query-Pfad (Query-Embedding, Retrieval, Filtering, Reranking, Context-Assembly, Generation). - Reranking mit einem Cross-Encoder ist kein optionales Extra: Anthropics Contextual Retrieval senkt die Retrieval-Fehlerrate um 49 Prozent, in Kombination mit Reranking um 67 Prozent (Stand September 2024). - Hybrid Search kombiniert Dense-Vektor-Suche (HNSW-Index) mit Sparse-BM25 und fängt exakte Codes, IDs und Eigennamen ab, die reine Embeddings verfehlen. - Metadaten-Filter (tenant_id, ACL) gehören in jeden Chunk: Sie sind technische Voraussetzung für Multi-Tenancy und für die von der DSK geforderte Mandantentrennung und Löschbarkeit. - Die häufigsten Architektur-Fehler sind naives Fixed-Size-Chunking, fehlendes Reranking, fehlende Evaluation und fehlende Quellen-Zitate. - DACH-souveräne Bausteine für EU-Hosting sind Qdrant (Berlin), Weaviate (Amsterdam) und Haystack/deepset (Berlin) sowie Embeddings von Jina, Mistral oder Aleph Alpha. Die [RAG](/de/glossar/rag)-Architektur beschreibt den technischen Aufbau eines [Retrieval-Augmented-Generation-Systems](/de/glossar/rag) in zwei klar getrennten Phasen. Die erste Phase, Ingestion (auch Indexing), läuft offline und überführt Quelldokumente in einen durchsuchbaren Index. Die zweite Phase, Query-Time, läuft online pro Anfrage und ruft die passenden Inhalte ab, ordnet sie neu und übergibt sie einem Sprachmodell zur Generierung. Wer RAG produktiv betreiben will, muss beide Pfade getrennt verstehen und betreiben. - **Zwei Pfade, nicht einer:** Ingestion (Loading, Chunking, [Embedding](/de/glossar/embedding), Upsert) läuft im Batch; der Query-Pfad (Embedding, Retrieval, Filtering, Reranking, Generation) läuft pro Anfrage. - **Reranking ist Pflicht, nicht Kür:** Ein Cross-Encoder nach der Grobsuche senkt die Retrieval-Fehlerrate messbar (bis 67 Prozent in Kombination mit Contextual Retrieval, Stand September 2024). - **Metadaten entscheiden über Compliance:** tenant\_id, ACL und Quell-Referenz pro Chunk sind die technische Basis für Multi-Tenancy, Mandantentrennung und Löschbarkeit. ## Phase 1: Ingestion / Indexing (offline) Der Ingestion-Pfad ist die Vorarbeit, die Qualität und Latenz des späteren Betriebs vorentscheidet. Er besteht aus vier bis fünf Schritten: **1. Loading / Connectors.** Quellen wie SharePoint, S3, Confluence oder eine Datenbank werden über Connectoren angebunden. Pro Dokument werden bereits hier stabile IDs und Metadaten erfasst (Quelle, Zeitstempel, Mandant, Zugriffsrechte). **2. Parsing.** Roh-Dokumente, vor allem PDFs und Verträge, werden in strukturierten Text überführt. Layout-aware Parser erhalten Tabellen-, Listen- und Header-Struktur, was später Halluzinationen vermeidet. Werkzeuge dafür sind unter anderem Docling (IBM, Open Source), Unstructured.io, LlamaParse oder Azure Document Intelligence. **3. Chunking.** Der Text wird in abrufbare Einheiten zerlegt. Naives Fixed-Size-Chunking (z. B. 512 Tokens, Overlap 50) ist einfach, zerschneidet aber Sätze und Tabellen. Besser sind Recursive/Semantic Chunking (Schnitt bei Cosine-Drift zwischen Sätzen) oder hierarchisches Parent-Child-Chunking (kleine Chunks zum Retrieval, große Parent-Chunks als Kontext). Faustregel: 200 bis 800 Tokens, 10 bis 20 Prozent Overlap. **4. Embedding.** Jeder Chunk wird von einem [Embedding-Modell](/de/glossar/embedding) in einen Vektor umgewandelt. Für deutschsprachige Korpora dominieren multilinguale Modelle wie Cohere Embed v4, Voyage-3, Gemini Embedding 002 oder BGE-M3; souveräne Optionen sind jina-embeddings-v3 (Berlin), Mistral Embed (EU) und Aleph Alpha Pharia-1-Embed (on-prem). Wichtig: Deutsch ist je nach Tokenizer rund 1,3- bis 1,7-mal tokenintensiver als Englisch. **5. Indexierung / Upsert.** Die Vektoren werden samt Metadaten in eine [Vektor-Datenbank](/de/glossar/vektordatenbank) geschrieben. Der Standard-Index-Algorithmus ist nahezu überall HNSW (Malkov & Yashunin 2016) mit den Parametern M, ef\_construction und ef\_search, die Recall gegen Geschwindigkeit abwägen. Optional wird parallel ein BM25-Index für Hybrid Search aufgebaut und pro Chunk ein [LLM](/de/glossar/llm)-generierter Kontext-Header vorangestellt (Contextual Retrieval). ## Phase 2: Query-Time (online) Der Query-Pfad verarbeitet jede einzelne Nutzeranfrage in Millisekunden bis wenigen hundert Millisekunden: **1. Query-Vorverarbeitung (optional).** Query-Rewriter, HyDE oder Decomposer formulieren komplexe Fragen um oder zerlegen sie. In Multi-Tenant-Systemen erfolgt hier zusätzlich AuthN/Z und Tenant-Resolution. **2. Query-Embedding.** Die Frage wird mit demselben Embedding-Modell wie die Chunks in einen Vektor umgewandelt. Parallel entsteht eine BM25-Query. **3. Retrieval / Vector Search.** Die Vektor-DB liefert die ähnlichsten Chunks (typisch top\_k = 50 bis 100). Bei Hybrid Search laufen Dense- und Sparse-Suche parallel und werden per Rank-Fusion (Reciprocal Rank Fusion) zusammengeführt. **4. Filtering.** Metadaten-Filter (tenant\_id, ACL, Datum) schränken die Kandidaten ein. Das ist nicht nur Performance, sondern Compliance: Die [DSK-Orientierungshilfe](https://dsgvo-gesetz.de/) RAG fordert Mandantentrennung und ein Rechte- und Rollenkonzept. **5. [Reranking](/de/wissen/ki-agenten/was-ist-ein-rag-system/reranking-modelle-rag).** Ein Cross-Encoder (Cohere Rerank v3, BGE-Reranker, Jina Reranker v2) bewertet Query und Dokument gemeinsam und reduziert die 50 bis 100 Kandidaten auf die relevantesten top\_k = 5 bis 10. Cross-Encoder sind genauer, aber langsamer als die Bi-Encoder der Grobsuche, deshalb laufen sie erst nach dem günstigen Recall. **6. Context-Assembly & Prompting.** Die finalen Chunks werden mit Quellen-Referenzen in ein [Prompt](/de/glossar/prompt)-Template eingesetzt. Wichtige Passagen gehören nach vorne, um das [Lost-in-the-middle-Problem](https://aiindex.stanford.edu/report/) zu vermeiden. **7. LLM-Generation.** Das Sprachmodell erzeugt die Antwort, idealerweise mit Citation-Forcing und einem nachgelagerten Faithfulness-Guardrail, der prüft, ob die Antwort durch die Quellen gedeckt ist. ## Tabelle: RAG-Pipeline nach Phase, Aufgabe und Tools | Phase | Aufgabe | Typische Tools (Stand 2026) | | --- | --- | --- | | Ingestion | Loading / Connectors | SharePoint-, S3-, Confluence-Connector | | Ingestion | Parsing | Docling, Unstructured.io, LlamaParse, Azure Document Intelligence | | Ingestion | Chunking | [LangChain](/de/glossar/langchain) Splitter, Semantic/Hierarchical Chunking, Contextual Chunking | | Ingestion | Embedding | Cohere Embed v4, Voyage-3, Gemini Embedding 002, jina-v3, BGE-M3, Aleph Alpha | | Ingestion | Indexierung / Upsert | Qdrant, Weaviate, Pinecone, Milvus, pgvector (HNSW + optional BM25) | | Query | Query-Embedding | gleiches Embedding-Modell wie Ingestion | | Query | Retrieval / Vector Search | HNSW-ANN-Suche, Hybrid (Dense + BM25), RRF-Fusion | | Query | Filtering | Metadata-Filter (tenant\_id, ACL) in Qdrant/Weaviate/pgvector | | Query | Reranking | Cohere Rerank v3, BGE-Reranker, Jina Reranker v2, LLM-as-Judge | | Query | Generation | LLM (Claude, [GPT](/de/glossar/gpt), Gemini, Mistral, Aleph Alpha Pharia) + Faithfulness-Guardrail | | Querschnitt | Evaluation / Observability | RAGAS, TruLens, DeepEval, Arize Phoenix, LangSmith | ## Datenfluss in Worten Ein Dokument wandert offline durch Loader, Parser und Chunker, wird vom Embedding-Modell vektorisiert und landet samt Metadaten als Record in der Vektor-DB. Trifft online eine Frage ein, wird sie mit demselben Modell eingebettet, über den HNSW-Index gegen alle Chunk-Vektoren verglichen und liefert eine Grobauswahl. Metadaten-Filter entfernen, was der Nutzer nicht sehen darf. Der Reranker verdichtet die Grobauswahl auf die besten Treffer. Diese werden mit Quellenangaben in den Prompt montiert, das LLM generiert daraus die Antwort, und ein Guardrail prüft die Treue zur Quelle. Entscheidend: Ingestion- und Query-Embedding müssen dasselbe Modell nutzen, sonst sind die Vektoren nicht vergleichbar. ## Konkretes Beispiel mit Zahlen Ein Support-Bot für ein SaaS-Produkt indexiert 50.000 Dokumente. Bei semantischem Chunking mit etwa 500 Tokens je Chunk entstehen rund 300.000 Vektoren. Die Indexierung mit [Contextual Retrieval](https://www.anthropic.com/research) kostet laut Anthropic etwa 1,02 US-Dollar pro 1 Million Document-Tokens mit Prompt-Caching (Stand September 2024). Im Betrieb ruft jede Query top\_k = 50 Kandidaten ab; der Cohere-Reranker reduziert auf top\_k = 5. Die Anthropic-Eval zeigt die Wirkung der Bausteine an der Top-20-Retrieval-Fehlerrate: Ohne Optimierung lag sie bei 5,7 Prozent. Mit Contextual Embeddings allein sank sie auf 3,7 Prozent (minus 35 Prozent), mit vollständigem Contextual Retrieval (Embeddings plus Contextual BM25) auf 2,9 Prozent (minus 49 Prozent) und mit zusätzlichem Reranking auf 1,9 Prozent (minus 67 Prozent). Eine Hybrid-Retrieval-Query inklusive Rerank liegt latenzseitig im Bereich von etwa 100 bis 800 Millisekunden. Pseudocode des Query-Pfads: \`\`\` q\_vec = embed(query) # gleiches Modell wie Ingestion dense = vdb.search(q\_vec, top\_k=50, filter={tenant\_id}) sparse = bm25.search(query, top\_k=50) cands = rrf\_fuse(dense, sparse) # Hybrid Search top5 = rerank(query, cands)[:5] # Cross-Encoder prompt = template(query, top5, cite=True) answer = llm.generate(prompt) assert faithfulness(answer, top5) > 0.8 # Guardrail \`\`\` ## Häufige Architektur-Fehler - **Naives Fixed-Size-Chunking** ignoriert Satz- und Tabellengrenzen und führt zu fehlenden Inhalten und Halluzinationen. - **Falsches Embedding-Modell für die Sprache** (EN-Embeddings für DE-Korpus) zerstört den Recall bei deutschen Queries. - **Kein Reranking:** Treffer sind semantisch ähnlich, aber nicht relevant. - **Lost-in-the-chunks:** Ohne Kontext-Header weiß ein Chunk wie "Er erhöhte sich um 12 Prozent" nicht, worum es geht. - **Reine Semantik ohne BM25:** Exakte Codes und IDs werden nicht gefunden. - **Keine Metadaten-Filter:** Kein Multi-Tenant-, kein ACL-Schutz, ein Chunk aus Mandant A kann für Mandant B abgerufen werden. - **Übergroße top\_k an das LLM:** Lost-in-the-middle und höhere Kosten. - **Keine Evaluation und keine Quellen-Zitate:** Stille Qualitätsregression und Compliance-Risiko. - **Embedding-Drift bei Modellwechsel:** Ohne Versionsstring und vollständige Re-Indexierung sind alte und neue Vektoren inkompatibel. ## Für Agenturen und B2B Eine saubere RAG-Architektur ist kein Wochenend-Prototyp, sondern eine Pipeline mit Ingestion, Hybrid Retrieval, Reranking, Evaluation und Lösch-Konzept. Für Agenturen heißt das: Der Wert liegt nicht im LLM, sondern in der Datenstrategie, im Chunking und in der Mandantentrennung. Für DACH-B2B-Entscheider zählt zusätzlich die Souveränität: Qdrant, Weaviate, Haystack und EU-Hosting machen RAG [DSGVO](/de/glossar/dsgvo)-tauglich. [Blck Alpaca](/de) konzipiert und betreibt solche Pipelines end-to-end, inklusive [RAGAS-Evaluation](/de/wissen/ki-agenten/was-ist-ein-rag-system/rag-evaluation-ragas-trulens) und Lösch-Pipeline gemäß DSK-Orientierungshilfe. Sprich uns an, wenn aus einem [KI](/de/glossar/ki)-Piloten ein produktives, nachprüfbares Wissenssystem werden soll. ## FAQ ### Was ist der Unterschied zwischen Ingestion und Query-Phase in einer RAG-Architektur? Die Ingestion-Phase läuft offline und im Batch: Quellen werden angebunden, geparst, in Chunks zerlegt, mit einem Embedding-Modell in Vektoren umgewandelt und in die Vektor-Datenbank geschrieben (Upsert). Die Query-Phase läuft online pro Anfrage: Die Nutzerfrage wird eingebettet, passende Chunks werden abgerufen, gefiltert, per Reranker neu sortiert, in den Prompt eingesetzt und vom LLM zu einer Antwort verarbeitet. ### Ist Reranking in einer RAG-Pipeline wirklich notwendig? In produktiven Systemen praktisch immer. Die Vektorsuche liefert semantisch ähnliche, aber nicht zwingend relevante Treffer. Ein Cross-Encoder-Reranker bewertet Query und Dokument gemeinsam und sortiert die Top-50 auf die besten Top-5 bis Top-10 um. Laut Anthropic reduziert das die Retrieval-Fehlerrate in Kombination mit Contextual Retrieval um bis zu 67 Prozent (Stand September 2024). Ohne Reranking landet zu viel Rauschen im Prompt. ### Welche Chunk-Größe ist die richtige für ein RAG-System? Es gibt keinen universellen Wert. Als Faustregel gelten 200 bis 800 Tokens mit 10 bis 20 Prozent Overlap. Wichtiger als die exakte Zahl ist layout-aware Parsing, das Tabellen, Listen und Überschriften erhält, sowie semantisches oder hierarchisches Chunking statt starrem Fixed-Size-Schnitt. Für deutschsprachige Korpora ist zu beachten, dass Deutsch je nach Modell etwa 1,3- bis 1,7-mal tokenintensiver ist als Englisch, was die effektive Chunk-Kapazität senkt. ### Was ist Hybrid Search und warum reicht reine Vektorsuche nicht? Hybrid Search kombiniert Dense-Retrieval (semantische Vektorsuche über einen HNSW-Index) mit Sparse-Retrieval (klassisches BM25-Keyword-Matching) und fusioniert beide Trefferlisten, typischerweise per Reciprocal Rank Fusion. Reine Vektorsuche verfehlt oft exakte Codes, Artikelnummern, Eigennamen oder IDs wie TS-999, weil diese semantisch kaum Signal tragen. BM25 fängt genau diese Fälle ab. ### Welche Tools brauche ich für eine EU-souveräne RAG-Architektur? Für die Vektor-Datenbank Qdrant (Berlin) oder Weaviate (Amsterdam/EU), als Framework Haystack von deepset (Berlin), als Embedding jina-embeddings-v3 (Berlin), Mistral Embed (EU) oder Aleph Alpha Pharia-1-Embed (Heidelberg, on-prem-fähig) und für das Hosting STACKIT, IONOS, OVHcloud oder Open Telekom Cloud. So bleiben Daten in der EU und Mandantentrennung sowie Löschbarkeit gemäß DSK-Orientierungshilfe lassen sich umsetzen. --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/was-ist-ein-rag-system/rag-architektur-komponenten). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.