Retrieval-Augmented Generation: Der umfassende Leitfaden

Retrieval-Augmented Generation (RAG) ist ein Architekturmuster in der künstlichen Intelligenz, das ein grosses Sprachmodell (LLM) mit einer externen Datenquelle verbindet. Anstatt sich ausschliesslich auf das im Training erworbene (und oft veraltete) Wissen des Modells zu verlassen, ruft das System bei einer Benutzerfrage zunächst relevante Dokumente ab und übergibt diese als verlässliche Informationsbasis an das LLM.

Warum RAG wichtig ist (Die Vorteile)

Klassische Sprachmodelle stossen in produktiven Unternehmensanwendungen an klare Grenzen. RAG löst diese Probleme elegant:

• Vermeidung von Halluzinationen: Durch die strikte Anweisung im Systemprompt, Antworten nur auf Basis der mitgelieferten Quellen zu generieren, sinkt die Fehlerquote drastisch.
• Aktualität der Daten: Es ist kein zeit- und kostenintensives Vortraining nötig. Neue Dokumente sind sofort nach dem Einlesen (Ingestion) für das System auffindbar.
• Mandantentrennung & Zugriffsrechte: Filter können sicherstellen, dass Benutzer nur Antworten aus Dokumenten erhalten, für die sie eine Leseberechtigung besitzen.
• Nachvollziehbarkeit: Da das Modell Zugriff auf konkrete Dokumentabschnitte hat, kann es seine Antworten mit exakten Quellenbelegen (Zitaten) versehen.

---

Die RAG-Architektur im Detail

Eine typische RAG-Pipeline unterteilt sich in zwei Hauptphasen: Ingestion (Datenaufnahme) und Retrieval & Generation (Abfrage & Generierung).

graph TD
    subgraph Ingestion Phase
        Doc[Dokumente / Webseiten] --> Clean[Textbereinigung]
        Clean --> Chunk[Chunking: Text aufteilen]
        Chunk --> Embed[Embedding: Text in Vektor umwandeln]
        Embed --> DB[(Vektordatenbank: pgvector)]
    end
    
    subgraph Query Phase
        Query[Benutzerfrage] --> QueryEmbed[Embedding der Frage]
        QueryEmbed --> Search[Ähnlichkeitssuche]
        DB --> Search
        Search --> Context[Kontext-Zusammenstellung]
        Context --> Prompt[Systemprompt + Kontext]
        Prompt --> LLM[Large Language Model]
        LLM --> Stream[Streaming-Antwort + Zitate]
    end

1. Ingestion Phase

• Textbereinigung: Entfernung von HTML-Boilerplate (Navigation, Footer), Skripten und irrelevanten Zeichen.
• Chunking (Textsegmentierung): Da LLMs ein begrenztes Kontextfenster besitzen, wird der Text in handliche Segmente unterteilt (z. B. 200 Wörter mit 30 Wörtern Überlappung).
• Embeddings: Jeder Text-Chunk wird durch ein Embedding-Modell in einen mathematischen Vektor (Zahlenreihe, z. B. 768 Dimensionen) konvertiert, der die semantische Bedeutung repräsentiert.
• Vektorspeicher: Die Chunks und ihre Vektoren werden in einer spezialisierten Datenbank (wie PostgreSQL mit der Erweiterung pgvector) indiziert gespeichert.

2. Retrieval & Generation Phase

• Suche: Die Benutzerfrage wird ebenfalls eingebettet. Eine Ähnlichkeitssuche (z. B. Cosine Similarity) findet in der Datenbank die Chunks, die der Frage semantisch am nächsten liegen.
• Prompt-Konstruktion: Die gefundenen Textpassagen werden zusammen mit der Originalfrage in einen Systemprompt eingefügt.
• Generierung: Das LLM liest den Kontext und formuliert eine präzise, quellenbasierte Antwort, die an den Benutzer zurückgegeben (bzw. gestreamt) wird.

---

Typische Fehler in RAG-Projekten

• Schlechtes Chunking: Zu grosse Chunks verwässern die Relevanz; zu kleine Chunks verlieren den Kontext des Absatzes.
• Fehlender SSRF-Schutz: Beim dynamischen Crawlen von URLs als Ingestion-Quelle können Angreifer versuchen, interne IP-Adressen (z. B. 169.254.169.254 für Cloud-Metadaten) abzufragen.
• Prompt Injection: Ohne strikte Trennung von Systemanweisungen und Benutzerdokumenten im Prompt können bösartige Inhalte in importierten Dateien das LLM manipulieren.
• Fehlendes No-Answer-Gate: Wenn keine relevanten Dokumente gefunden werden, neigen Modelle ohne Absicherung dazu, zu fantasieren. Ein hartes Schwellenwert-Gate muss das Modell in diesem Fall blockieren.

---

RAG vs. andere Ansätze: Wann lohnt sich was?

RAG ist nicht in jedem Fall die richtige Wahl. Die folgende Tabelle hilft bei der Einordnung gegenüber zwei verbreiteten Alternativen:

Ansatz	Stärke	Schwäche	Typischer Einsatz
Reines LLM	schnell, kein Aufbau nötig	kein aktuelles/internes Wissen, halluziniert	Brainstorming, Textstil
Fine-Tuning	prägt Verhalten & Ton dauerhaft	teuer, statisch, kein Faktenupdate	feste Aufgaben, Tonalität
RAG	aktuelles Wissen, belegbar, Mandantentrennung	Aufwand für Pipeline & Indexierung	Wissensdatenbanken, Support

In der Praxis schliessen sich die Verfahren nicht aus: Ein leichtgewichtiges Fine-Tuning kann den Antwortstil festlegen, während RAG das Faktenwissen liefert. Eine ausführliche Gegenüberstellung mit Kostenrechnung finden Sie im Leitfaden Fine-Tuning vs. RAG.

---

Die zwei Suchstrategien im RAG

Das Herzstück jedes RAG-Systems ist das Retrieval. Hier konkurrieren und ergänzen sich zwei Verfahren: Die Vektorsuche erfasst die Bedeutung einer Anfrage und findet auch dann passende Stellen, wenn andere Worte verwendet werden. Die schlüsselwortbasierte BM25-Suche glänzt dagegen bei exakten Begriffen, Produktnummern oder Eigennamen. Welche überlegen ist, hängt vom Anfragetyp ab – eine fundierte Entscheidungshilfe bietet der Vergleich Hybrid vs. Vector Search.

Die robusteste Lösung kombiniert beide über Hybrid Search und gewichtet die Trefferlisten mit Reciprocal Rank Fusion. Ein nachgelagertes Reranking sortiert die Kandidaten anschliessend nach tatsächlicher Relevanz, bevor sie ins Kontextfenster gelangen – so landen nur die besten Passagen beim Modell.

---

Best Practices für die Umsetzung

1. Hybrid Search nutzen: Kombinieren Sie Vektorsuche (semantische Konzepte) mit klassischer Schlüsselwortsuche (PostgreSQL-FTS), um sowohl Abstraktionen als auch exakte IDs oder Fachbegriffe perfekt zu finden.
2. SSRF-Guards implementieren: Sperren Sie beim Import von URLs alle privaten IP-Bereiche (RFC 1918) und überprüfen Sie jeden Redirect-Hop.
3. Evaluierung automatisieren: Messen Sie Kennzahlen wie Faithfulness (basiert die Antwort wirklich nur auf den Quellen?) und Answer Relevance systematisch mit Testsets.
4. pgvector für relationale Stärke: Wenn Sie bereits PostgreSQL nutzen, verwenden Sie pgvector. Das vereinfert Backups, Joins mit Benutzerrechten und die Administration erheblich.

---

Alle RAG-Leitfäden im Überblick

Hier finden Sie unsere vertiefenden Fachartikel zu den einzelnen Komponenten eines modernen RAG-Systems:

• RAG-Architektur & Ablauf: RAG-Architektur | Vector Search | BM25 (Keyword-Suche) | Hybrid Search | Reranking | Hybrid vs. Vector Search
• Datenverarbeitung (Ingestion): Chunking-Strategien | Embeddings im RAG
• Implementierung & Integration: RAG mit Spring AI | RAG mit PostgreSQL & pgvector
• Sicherheit & Härtung: RAG-Sicherheit | Prompt Injection im RAG | No-Answer-Gate | Citations (Quellenangaben)
• Optimierung & QA: RAG Best Practices | Typische RAG-Fehler vermeiden | RAG-Evaluation

[!IMPORTANT] Allerate realisiert hochperformante RAG-Systeme auf Basis von Java, Spring Boot 4, Spring AI und PostgreSQL/pgvector. Besuchen Sie allerate.dev für eine interaktive Schritt-für-Schritt-RAG-Demo.