RAG - Eine Einführung

RAG - Eine Einführung

von Christian Betz 4 Min. Lesezeit Also available in English

Retrieval-Augmented Generation (RAG)

Architektur, Nutzen, Grenzen und praktische Umsetzung

Einordnung und Motivation

Large Language Models (LLMs) wie GPT, Claude oder Llama sind beeindruckend gut darin, Sprache zu verstehen und zu erzeugen. Sie haben aber ein strukturelles Problem:
Ihr Wissen ist statisch, begrenzt durch den Trainingszeitpunkt und nicht unternehmensspezifisch.

Genau hier setzt Retrieval-Augmented Generation (RAG) an. RAG kombiniert zwei Welten:

  • Retrieval: gezieltes Abrufen relevanter Informationen aus externen Datenquellen
  • Generation: sprachliche Verarbeitung und Antwortgenerierung durch ein LLM

Das Modell „weiß“ also nicht alles, sondern schlägt nach, bevor es antwortet. Eine erstaunlich menschliche Idee, die erstaunlich lange gebraucht hat, bis sie ernsthaft umgesetzt wurde.

Grundprinzip von RAG

Das Kernprinzip ist simpel, aber wirkungsvoll:

  1. Eine Nutzeranfrage wird gestellt
  2. Die Anfrage wird in einen Vektorraum übersetzt (Embedding)
  3. Relevante Dokumente werden aus einer Wissensbasis abgerufen
  4. Diese Dokumente werden dem LLM als Kontext übergeben
  5. Das LLM generiert eine Antwort auf Basis dieses Kontexts

Wichtig:
Das LLM halluziniert idealerweise nicht, sondern argumentiert entlang realer Inhalte.

Klassische Architektur einer RAG-Pipeline

1. Datenquellen

Typische Quellen sind:

  • PDFs, Word-Dokumente, Präsentationen
  • Confluence, SharePoint, Wikis
  • Datenbanken
  • Ticketsysteme, Logs, E-Mails
  • Verträge, Richtlinien, Handbücher

Qualität rein, Qualität raus. RAG ist gnadenlos ehrlich, was schlechte Dokumentation angeht.

2. Dokumentenaufbereitung (Ingestion)

Vor der eigentlichen Nutzung müssen Daten vorbereitet werden:

  • Parsing (PDF, DOCX, HTML)
  • Bereinigung (Header, Footer, Boilerplate entfernen)
  • Chunking (Aufteilung in sinnvolle Textsegmente)
  • Metadaten-Anreicherung (Quelle, Datum, Kategorie, Berechtigungen)

Chunk-Größe ist kein Glaubenskrieg, sondern ein Optimierungsproblem:

  • Zu klein → Kontext fehlt
  • Zu groß → Retrieval wird ungenau

3. Embeddings

Jeder Text-Chunk wird in einen Vektor umgewandelt.

  • Semantische Repräsentation
  • Nähe im Vektorraum = inhaltliche Ähnlichkeit
  • Grundlage für semantische Suche

Typische Embedding-Modelle:

  • OpenAI text-embedding-3
  • bge, E5, Instructor
  • lokale Modelle für Datenschutzanforderungen

4. Vektordatenbank

Hier werden die Embeddings gespeichert und durchsucht.

Beispiele:

  • FAISS
  • Milvus
  • Qdrant
  • Pinecone
  • Weaviate

Anforderungen:

  • Schnelle Similarity Search
  • Filterung nach Metadaten
  • Skalierbarkeit
  • Reproduzierbarkeit

5. Retrieval

Bei einer Anfrage passiert:

  • Query → Embedding
  • Ähnlichkeitssuche im Vektorraum
  • Top-k relevante Chunks werden ausgewählt

Optional:

  • Re-Ranking (z. B. mit Cross-Encodern)
  • Hybrid Search (Vektor + Keyword)
  • Filter nach Berechtigungen oder Aktualität

Retrieval ist der eigentliche Engpass. Ein schlechtes Retrieval macht jedes LLM dumm.

6. Prompt Construction

Die gefundenen Texte werden in einen strukturierten Prompt eingebaut:

  • System-Instruktionen
  • Kontext (Dokumentauszüge)
  • Nutzerfrage

Beispielhaft:

  • klare Trennung von Kontext und Frage
  • Hinweise, nur den Kontext zu verwenden
  • Zitieranforderungen

Prompt-Engineering ist hier weniger Magie, mehr Handwerk.

7. Generation

Das LLM generiert die Antwort:

  • basierend auf bereitgestelltem Kontext
  • idealerweise nachvollziehbar
  • optional mit Quellenangaben

Das Modell denkt nicht. Es formuliert. Der Kontext entscheidet, was formuliert wird.

Typische Anwendungsfälle

Wissensmanagement

  • Unternehmensinterne Suche
  • FAQ-Chatbots
  • Onboarding-Unterstützung
  • Expertenwissen zugänglich machen

Compliance & Regulierung

  • Analyse von Richtlinien
  • Abgleich von Dokumenten mit Normen (z. B. DORA, ISO 27001)
  • Audit-Vorbereitung
  • Nachvollziehbare Antworten mit Quellen

Kunden- und Supportsysteme

  • Ticket-Zusammenfassungen
  • Antwortvorschläge
  • Self-Service-Portale
  • Reduktion von First-Level-Support

Vertrags- und Dokumentenanalyse

  • Klauselerklärungen
  • Risikoindikationen
  • Vergleich von Vertragsversionen
  • Semantische Suche über Verträge

Vorteile von RAG

  • Aktuelle Informationen ohne Modell-Neutraining
  • Nutzung proprietärer Daten
  • Nachvollziehbarkeit durch Quellen
  • Geringere Halluzinationsrate
  • Datenschutzfreundlich bei lokaler Ausführung

Kurz gesagt:
RAG macht LLMs nützlich statt nur eloquent.

Grenzen und typische Probleme

Halluzinationen verschwinden nicht vollständig

  • Schlechter Kontext → schlechte Antwort
  • LLMs bleiben probabilistische Systeme

Retrieval-Qualität ist kritisch

  • Falsche Chunks → falsche Antworten
  • Semantik schlägt Keywords, aber nicht immer

Kontextfenster sind begrenzt

  • Zu viele Dokumente passen nicht rein
  • Priorisierung wird notwendig

Wartung ist realer Aufwand

  • Re-Ingestion bei Änderungen
  • Versionsmanagement
  • Monitoring von Antwortqualität

RAG ist kein Plug-and-Play. Es ist ein System.

RAG vs. Fine-Tuning

Aspekt RAG Fine-Tuning
Aktualisierbarkeit Hoch Niedrig
Kosten Mittel Hoch
Erklärbarkeit Hoch Niedrig
Unternehmensdaten Ideal Problematisch
Trainingsaufwand Gering Hoch

In der Praxis:

  • RAG zuerst
  • Fine-Tuning nur ergänzend
  • Beides kombinieren ist möglich, aber selten nötig

Erweiterungen und fortgeschrittene Konzepte

  • Hybrid Search (BM25 + Vektor)
  • Graph-RAG (Wissensgraphen statt reiner Texte)
  • Multi-Hop Retrieval
  • Tool-Augmented RAG
  • Agentenbasierte RAG-Systeme

Der Trend geht klar Richtung strukturierterem Kontext, nicht größerem Modell.

Fazit

Retrieval-Augmented Generation ist keine Spielerei, sondern eine Architekturentscheidung.
Sie verschiebt den Fokus von „größeres Modell“ zu „bessere Informationen“.

Ein gutes RAG-System:

  • kennt seine Daten
  • kennt seine Grenzen
  • und behauptet nicht mehr zu wissen, als es wirklich weiß

Das ist für eine KI schon fast philosophisch.