RAG-Architektur verständlich erklärt: Der dreistufige Prozess

Die RAG-Architektur (Retrieval-Augmented Generation) ist das führende Entwurfsmuster, um grosse Sprachmodelle (LLMs) mit externen, dynamischen Datenquellen zu verknüpfen. Statt ein Modell zeitaufwendig und teuer neu zu trainieren, stellt RAG dem Modell während der Anfrage verlässliche Dokumente zur Verfügung. Das Modell agiert als intelligenter Leser und Formulierer, der ausschliesslich auf Basis der ihm überreichten Fakten antwortet.

Damit ist RAG der wirksamste Weg, Halluzinationen zu reduzieren und ein Sprachmodell mit aktuellem Firmenwissen zu versorgen, ohne es neu zu trainieren. Einen Überblick über das gesamte Themenfeld bietet der RAG-Leitfaden.

Der dreistufige RAG-Prozess

Eine RAG-Pipeline lässt sich in drei aufeinanderfolgende Schritte unterteilen: Retrieve (Suchen), Augment (Anreichern) und Generate (Generieren).

graph LR
    A[1. RETRIEVE: Suchen & Abrufen] --> B[2. AUGMENT: Kontext in Prompt einbetten]
    B --> C[3. GENERATE: LLM formuliert faktische Antwort]

1. Schritt: Retrieve (Abrufen)

Gibt ein Benutzer eine Frage in das System ein (z. B. „Wie lauten die Kündigungsfristen in unserem Unternehmen?“), passiert im Hintergrund folgendes:

• Die Frage wird mithilfe eines Embedding-Modells in einen Zahlenvektor übersetzt.
• Dieser Vektor wird an eine Vektordatenbank geschickt.
• Die Datenbank berechnet die Ähnlichkeit zu allen dort gespeicherten Textabschnitten (Chunks) der Unternehmensdokumente.
• Die Datenbank gibt die $k$ ähnlichsten Textabschnitte (z. B. die Top 3 Abschnitte aus den HR-Handbüchern) im Klartext zurück.

2. Schritt: Augment (Anreichern)

Nun wird der ursprüngliche Benutzer-Prompt mit den gefundenen Textabschnitten verschmolzen. Dies geschieht über eine strukturierte Prompt-Vorlage im Backend (z. B. verwaltet durch Spring AI):

„Du bist ein hilfsbereiter HR-Assistent. Beantworte die Frage des Nutzers ausschliesslich auf Basis des folgenden Kontexts. Wenn die Antwort dort nicht steht, sage, dass du es nicht weiss.

Kontext: [Hier werden die gefundenen Textabschnitte der Vektordatenbank eingefügt]

Frage: Wie lauten die Kündigungsfristen in unserem Unternehmen?“

3. Schritt: Generate (Generieren)

Dieser angereicherte Prompt wird an das Sprachmodell (LLM) übermittelt. Das Modell liest die im Kontext enthaltenen Fristen ab, formuliert eine präzise Antwort und verweist idealerweise direkt auf die Quellendokumente – siehe dazu Citations (Quellenangaben).

---

Die Ingestion-Pipeline: Was vor dem Retrieval passiert

Damit der dreistufige Live-Prozess funktioniert, muss zuvor ein durchsuchbarer Index aufgebaut werden. Diese Ingestion läuft im Hintergrund und besteht aus vier Schritten:

Schritt	Aufgabe	Typische Stolperfalle
1. Laden & Bereinigen	Texte aus PDF, Wiki, DB extrahieren	Kopf-/Fusszeilen und Navigation verschmutzen den Text
2. Chunking	In sinnvolle Abschnitte zerlegen	Zu grosse Chunks verwässern den Vektor
3. Embeddings	Jeden Chunk in einen Vektor wandeln	Sprach-/Modell-Mismatch zwischen Index und Anfrage
4. Speichern	Vektoren in die Vektordatenbank schreiben	Fehlende Metadaten verhindern spätere Filterung

Die Qualität der Ingestion entscheidet über die Qualität aller späteren Antworten: Was nicht sauber indexiert ist, kann das Retrieval nicht finden.

---

Naive RAG vs. Advanced RAG

Die oben beschriebene Grundform wird oft als «Naive RAG» bezeichnet. In anspruchsvollen Szenarien reicht sie nicht aus und wird um zusätzliche Stufen erweitert:

Aspekt	Naive RAG	Advanced RAG
Suche	Nur Vektorsuche	Hybrid Search (Vektor + BM25)
Nachbearbeitung	Keine	Reranking der Treffer
Sicherheit	Keine	No-Answer-Gate, Quellenprüfung
Eignung	Prototyp, Demo	Produktivbetrieb

Wer von der Demo in den Produktivbetrieb wechselt, sollte den Schritt zu Advanced RAG einplanen – vor allem Hybrid Search und Reranking heben die Trefferqualität deutlich an.

---

RAG vs. Fine-Tuning: Wann nutzt man was?

Ein häufiges Missverständnis ist, dass man Sprachmodelle feintunen (Fine-Tuning) muss, um ihnen neues Wissen beizubringen. In der Praxis sieht die Verteilung wie folgt aus:

• RAG (Retrieval-Augmented Generation): Nutzen Sie RAG, wenn Sie Wissen bereitstellen möchten. RAG eignet sich perfekt für interne Wikis, Dokumenten-Suchen, dynamische Daten (wie Lagerbestände) und wenn Halluzinationen absolut ausgeschlossen werden müssen.
• Fine-Tuning: Nutzen Sie Fine-Tuning, wenn Sie das Verhalten oder den Stil des Modells ändern möchten. Beispiele sind das Beibringen einer sehr spezifischen Programmiersprache, die Anpassung der Tonalität an Markenrichtlinien oder das Trainieren auf extrem kurze Ausgaben. Fine-Tuning eignet sich nicht, um Faktenwissen verlässlich zu speichern, da das Modell weiterhin halluzinieren kann.

[!TIP] Die RAG-Architektur ist der Goldstandard für datenschutzkonforme Unternehmens-KIs. Überzeugen Sie sich von der Funktionsweise in der interaktiven RAG-Demo auf allerate.dev.