RAG-Architektur: Ingestion, Retrieval, Generation, Reranking

Die RAG-Architektur beschreibt den technischen Aufbau eines Retrieval-Augmented-Generation-Systems 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, 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 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 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-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 RAG fordert Mandantentrennung und ein Rechte- und Rollenkonzept.

5. Reranking. 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-Template eingesetzt. Wichtige Passagen gehören nach vorne, um das Lost-in-the-middle-Problem 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

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 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-tauglich. Blck Alpaca konzipiert und betreibt solche Pipelines end-to-end, inklusive RAGAS-Evaluation und Lösch-Pipeline gemäß DSK-Orientierungshilfe. Sprechen Sie uns an, wenn aus einem KI-Piloten ein produktives, nachprüfbares Wissenssystem werden soll.