# RAG-System-Architektur

> Retrieval-Verfahren, Chunking, Embeddings und Kontextgröße — die Grundsatzentscheidungen, bevor die erste Zeile RAG-Code steht.

Track: [LLMOps](https://physar.tech/learn/llmops)  
Kanonische Fassung: https://physar.tech/learn/llmops/rag-architecture  
Stand: 2026-07-22  
Interaktiver Teil: 12 Checks (nur im Browser)

## RAG-System-Architektur: von der Pipeline zur richtigen Entscheidung

### Was RAG ist — und die Pipeline dahinter

**RAG** = Retrieval-Augmented Generation. Statt dem LLM blind zu vertrauen, holst du relevante Dokumente aus deinem Wissensbestand und gibst sie ihm als Kontext mit — das Modell antwortet auf Basis **deiner** Daten, aktuell und nachvollziehbar, ohne Fine-Tuning.

Wichtig für alles Weitere: RAG ist keine einzelne Komponente, sondern eine **Pipeline aus zwei Phasen** — einmal **offline indexieren**, dann pro Frage **online abrufen und generieren**. Jede Stufe hat Alternativen mit Trade-offs.

_[Abbildung: Zwei Phasen: einmal den Bestand indexieren (offline), dann pro Frage abrufen, optional neu ordnen und generieren (online). Der Vektor-Store verbindet beide.]_

> **Merksatz:** Die Kunst ist nicht, **eine** Pipeline zu bauen — sondern für deinen Use-Case die **richtigen** Stufen zu wählen.

### Retrieval-Grundlagen: sparse vs. dense

**Sparse (BM25 / Keyword):** matcht exakte Begriffe und Tokens — Fehlercodes wie `ORA-12154`, Hostnamen, CLI-Flags. Präzise auf Stichwörter, aber blind für Paraphrasen.

**Dense (Embeddings):** matcht Bedeutung — findet „Backup schlägt fehl“ auch bei „nightly job bricht ab“. Dafür verwischt es exakte Tokens: einen präzisen Fehlercode findet es unzuverlässig.

|  |  |
| --- | --- |
| Exakte Codes / IDs | BM25 (sparse) |
| Natürliche Sprache | Dense (Embeddings) |
| Gemischte Last | Hybrid + RRF |

### Hybrid: zwei Signale, per RRF vereint

Reale Query-Verteilungen sind gemischt — mal exakte Codes, mal ganze Sätze. **Hybrid** kombiniert beide Retrieval-Signale und ist damit der robuste Praxis-Default.

_[Abbildung: Reciprocal Rank Fusion (RRF) vereint die beiden Ranglisten allein über die Rangpositionen — ohne die Scores der Verfahren kalibrieren zu müssen.]_

> **Warum RRF:** BM25- und Embedding-Scores sind nicht vergleichbar. RRF umgeht das, indem es nur die **Rangplätze** fusioniert — simpel und überraschend stark.

### Chunking & Kontext

Dokumente werden vor dem Indexieren in **Chunks** zerlegt. Die Größe ist ein Trade-off: **klein** = präzises Retrieval, wenig Kontext; **groß** = mehr Kontext, aber verrauschte Treffer und „lost in the middle“ (Modelle übersehen Inhalte in der Mitte langer Kontexte).

_[Abbildung: small-to-big: über kleine Chunks präzise retrieven, dann den größeren Eltern-Abschnitt ans LLM geben — Präzision UND Kontext.]_

> **Merksatz:** Mehr Kontext ist nicht besser — **relevanter** Kontext ist besser.

### Die vier Architektur-Muster

Die meisten RAG-Systeme fallen in eines von vier Mustern — von simpel bis schwer:

|  |  |
| --- | --- |
| Naive RAG | embed → top-k → generieren. Baseline. Für kleine, stabile Bestände völlig ausreichend. |
| Advanced RAG | + Query-Rewriting, Hybrid, Reranking. Der pragmatische Produktions-Default. |
| Agentic RAG | ein Agent entscheidet mehrstufig, was er retrievt. Für komplexe Fragen — teurer, langsamer, schwerer abzusichern. |
| GraphRAG | Knowledge-Graph + Traversierung. Für relationale „verbinde über Dokumente“-Fragen (Multi-Hop). |

### Welcher Aufbau wofür?

Die entscheidende Frage ist nicht „welches Muster ist am besten“, sondern „welches passt zu **dieser** Frageklasse und diesem Bestand“. Der Entwurfsraum als Entscheidungsbaum:

_[Abbildung: Frageklasse und Bestand bestimmen das Muster — nicht der Trend. Im Zweifel unten anfangen und nur bei echtem Bedarf komplexer werden.]_

> **Kernfehler:** Over-Engineering ist der häufigste Anfängerfehler. Passe die Architektur an die Aufgabe an — nicht umgekehrt.

### Retrieval-Qualität: Reranking

Symptom: Das Retrieval liefert viele Kandidaten, aber die Antworten zitieren oft irrelevanten Kontext. Der höchste Präzisions-Hebel ist **Reranking** — nicht ein größeres LLM und nicht ein höheres `top-k` (das bringt nur mehr Rauschen).

_[Abbildung: Ein Cross-Encoder bewertet Query–Chunk-Paare direkt und filtert die vielen Kandidaten auf die wirklich relevanten, sortiert nach oben.]_

> **Trennschärfe:** Trenne **Retrieval**-Probleme von **Generierungs**-Problemen. „Irrelevanter Kontext“ ist ein Retrieval-Problem — dort ansetzen.

### Die Ops-Sicht: Security & Messung

**Security:** Alles, was du retrievst, ist **nicht vertrauenswürdige Eingabe**. Versteckte Anweisungen in einem Dokument sind indirekte Prompt Injection — Antwort: Guardrails + Least-Privilege, nicht auf das „Wohlverhalten“ des Modells hoffen.

**Messung:** „Am besten für meinen Use-Case“ beweist man mit einem **Eval-Set** (Faithfulness, Context Precision/Recall), nicht mit Bauchgefühl. Jede Architektur-Änderung vorher/nachher messen, idealerweise als Regressionsgate in der CI.

> **Ops-Denkweise:** Ein RAG-System ist Betrieb, nicht nur ein Prompt: Trust-Grenzen, Messbarkeit und Wartbarkeit gehören von Anfang an dazu.

### Zusammenfassung — gleich im Check

Du kennst jetzt die Achsen des Entwurfsraums: **Retrieval-Verfahren**, **Right-Sizing** der Architektur, **Datenmodell** für die Frageklasse, **Chunking**, **Retrieval-Qualität** sowie **Security & Messung**.

> **Gleich im Check:** In den nächsten Entscheidungen wählst du für konkrete Ops-Szenarien selbst den Aufbau — und siehst pro Option, **warum** sie trägt oder nicht.

## Quellen

- Okapi BM25 (Robertson/Zaragoza) — The Probabilistic Relevance Framework: BM25 and Beyond
- Reciprocal Rank Fusion — Cormack, Clarke, Buettcher, 2009
- Lost in the Middle: How Language Models Use Long Contexts — Liu et al., 2023
- Passage Re-ranking with BERT (Cross-Encoder) — Nogueira & Cho, 2019
- OWASP Top 10 for LLM Applications — LLM01: Prompt Injection
- RAGAS: Automated Evaluation of Retrieval Augmented Generation — Es et al., 2023
- Retrieval-Augmented Generation for Large Language Models: A Survey — Gao et al., 2023
- MTEB: Massive Text Embedding Benchmark — Muennighoff et al., 2022
- Metadata filtering in vector search (Pre- vs. Post-Filtering) — Weaviate / Qdrant Dokumentation
- Retrieval-Augmented Generation — Lewis et al., 2020
- Incremental indexing / Change-Data-Capture — gängiges Daten-Pipeline-Muster
- Index-Update-Strategien — LlamaIndex / LangChain Dokumentation
- Passage Re-ranking with BERT — Nogueira & Cho, 2019
- Chunking strategies (fixed-size with overlap) — LlamaIndex / LangChain Dokumentation
- pgvector — PostgreSQL-Extension, Projekt-Dokumentation
- Efficient and robust approximate nearest neighbor search using HNSW — Malkov & Yashunin, 2016
- OWASP Top 10 for LLM Applications — LLM06: Sensitive Information Disclosure
- Multi-tenant vector search: namespaces & partitioning — Pinecone / Qdrant Dokumentation