RAG-System-Architektur: von der Pipeline zur richtigen Entscheidung
Einführung · 9 Abschnitte · ~8 Min Lesezeit · Stand
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.
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.
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).
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:
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).
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.
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.