RAG

KAPITEL 16 · KI & ENGINEERING

RAG – Retrieval-Augmented Generation

Die wichtigste Technik für praxistaugliche KI im Unternehmen. Lernen Sie, wie Large Language Models mit eigenen Daten kombiniert werden, um hallucinationsfreie, aktuelle und domänenspezifische Antworten zu generieren.

Architektur Vektordatenbanken Chunking Enterprise Use Cases

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über RAG im Enterprise-Umfeld:

  • Definition: Was ist RAG und warum ist es wichtig?
  • Architektur: Die RAG-Pipeline Schritt für Schritt
  • Komponenten: Embeddings, Vektordatenbanken, Retriever, Generator
  • Vektordatenbanken: Pinecone, Weaviate, Chroma, pgvector im Vergleich
  • Chunking-Strategien: Fixed, Semantic, Recursive, Document-based
  • Use Cases: Support, Dokumentation, Research, Code, Compliance
  • Best Practices: Datenqualität, Evaluation, Sicherheit
  • FAQ: Häufige Fragen und Troubleshooting

1. Was ist RAG?

Definition

RAG (Retrieval-Augmented Generation) ist eine Architektur, die Large Language Models (LLMs) mit externen Wissensquellen verbindet. Statt nur auf trainiertes Wissen zu vertrauen, ruft RAG vor der Antwortgenerierung relevante Dokumente aus einer Datenbank ab und fügt sie als Kontext in den Prompt ein. Das Ergebnis: faktisch korrekte, aktuelle und domänenspezifische Antworten.

Im Enterprise-Umfeld löst RAG die drei größten Probleme reiner LLMs: Halluzinationen (falsche Fakten), veraltetes Wissen (Trainings-Cutoff) und fehlendes Domänenwissen (interne Dokumente, Prozesse, Regularien).

Typische Anwendungen: Kundensupport-Chatbots mit Produktwissen, interne Wissensdatenbanken, juristische Dokumentenanalyse, Code-Assistenten mit Unternehmenscodebase, Compliance-Prüfung.

Warum RAG statt Fine-Tuning?

  • Kosten: RAG ist deutlich günstiger als Fine-Tuning (keine GPU-Training nötig)
  • Aktualität: Daten können jederzeit aktualisiert werden, ohne Modell neu zu trainieren
  • Transparenz: Quellenangaben möglich – Nutzer sehen, woher die Information stammt
  • Datenschutz: Sensible Daten bleiben in Ihrer Infrastruktur, werden nicht ins Modell "eingebrannt"
  • Flexibilität: Unterschiedliche Wissensquellen für verschiedene Use Cases kombinierbar

2. Die RAG-Architektur

Die RAG-Pipeline besteht aus zwei Hauptphasen: Indexing (Vorbereitung) und Querying (Abfrage).

RAG-Pipeline im Überblick

1
Daten laden

PDFs, Docs, Webseiten, Datenbanken importieren

2
Chunking

Dokumente in sinnvolle Abschnitte teilen

3
Embedding

Text in Vektoren umwandeln

4
Speichern

Vektoren in Vektordatenbank indexieren

5
Retrieval

Ähnliche Chunks zur Query finden

6
Generation

LLM generiert Antwort mit Kontext

Indexing vs. Querying

Indexing (Offline): Einmalige Vorbereitung – Dokumente werden geladen, gechunkt, embedded und in der Vektordatenbank gespeichert. Kann Stunden bis Tage dauern.

Querying (Online): Echtzeit-Abfrage – User-Frage wird embedded, ähnliche Chunks werden gesucht, LLM generiert Antwort. Dauert Millisekunden bis Sekunden.

3. Die vier Kernkomponenten

Jede RAG-Pipeline besteht aus vier wesentlichen Komponenten, die zusammenarbeiten.

Embedding Models

Text → Vektor

Embedding-Modelle wandeln Text in numerische Vektoren um, die semantische Ähnlichkeit abbilden.

  • OpenAI text-embedding-3-large
  • Sentence-Transformers (open-source)
  • Cohere embed-v3
  • Dimension: 768–3072

Vektordatenbanken

Speicher & Suche

Spezialisierte Datenbanken für effiziente Ähnlichkeitssuche in hochdimensionalen Vektorräumen.

  • Pinecone (Managed)
  • Weaviate (Open Source)
  • Chroma (Lightweight)
  • pgvector (PostgreSQL)

Retriever

Relevante Chunks finden

Suchalgorithmen, die die relevantesten Dokumenten-Chunks für eine gegebene Query identifizieren.

  • Dense Retrieval (Cosine Similarity)
  • Sparse Retrieval (BM25)
  • Hybrid Search (Kombination)
  • Re-Ranking (Cross-Encoder)

Generator (LLM)

Antwort generieren

Das Large Language Model, das basierend auf dem abgerufenen Kontext die finale Antwort formuliert.

  • GPT-4o / GPT-4-turbo
  • Claude 3.5 Sonnet
  • Llama 3.1 (Open Source)
  • Mistral Large

4. Vektordatenbanken im Vergleich

Die Wahl der richtigen Vektordatenbank hängt von Skalierungsbedarf, Budget und Infrastruktur ab.

Datenbank Typ Skalierung Besonderheiten Einsatz
Pinecone Managed Cloud Sehr hoch Serverless, automatische Skalierung Enterprise, hohe Last
Weaviate Open Source / Cloud Hoch Multi-Modal, GraphQL API Flexible Architekturen
Chroma Open Source Mittel Lightweight, Python-nativ Prototyping, kleine Projekte
pgvector PostgreSQL Extension Mittel-Hoch In bestehender DB integrierbar Bereits PostgreSQL-Nutzer
Milvus Open Source / Cloud Sehr hoch Distributed, GPU-beschleunigt Big Data, Milliarden Vektoren
Qdrant Open Source / Cloud Hoch Rust-basiert, Payload-Filtering Performance-kritisch

Entscheidungshilfe

  • Schneller Start / Prototyping: Chroma (lokal, einfach)
  • Bereits PostgreSQL: pgvector (keine neue Infrastruktur)
  • Enterprise / Managed: Pinecone oder Zilliz Cloud
  • Open Source + Skalierung: Weaviate, Milvus oder Qdrant
  • Multi-Modal (Bilder + Text): Weaviate

5. Chunking-Strategien

Wie Dokumente in Chunks aufgeteilt werden, hat großen Einfluss auf die Retrieval-Qualität. Zu große Chunks verwässern die Relevanz, zu kleine verlieren den Kontext.

Fixed-Size Chunking

Einfachste Methode: Feste Zeichen- oder Token-Anzahl pro Chunk mit Overlap.

Chunk-Größe: 512 Tokens
Overlap: 64 Tokens
✅ Einfach, schnell
❌ Kann Sätze trennen

Semantic Chunking

Trennt an semantischen Grenzen (Absätze, Themenwechsel) basierend auf Embedding-Ähnlichkeit.

Erkennt Themenwechsel automatisch
✅ Kohärente Chunks
❌ Langsamer, rechenintensiv

Recursive Character Splitting

Versucht zuerst große Trennzeichen (\n\n, \n, .), dann kleinere. Standard in LangChain.

Separatoren: ["\n\n", "\n", ". ", " "]
✅ Behält Struktur
✅ Gute Balance

Document-Based Chunking

Nutzt Dokumentstruktur (Überschriften, Tabellen, Listen) für intelligente Aufteilung.

Markdown-Header als Grenzen
✅ Semantisch sinnvoll
❌ Benötigt strukturierte Docs

Chunking Best Practices

  • Größe: 256–1024 Tokens je nach Use Case (Support: kleiner, Research: größer)
  • Overlap: 10–20% der Chunk-Größe verhindert Informationsverlust an Grenzen
  • Metadaten: Titel, Abschnitt, Datum, Autor als Metadaten speichern für Filtering
  • Testen: Verschiedene Strategien evaluieren – es gibt keine Universallösung
  • Parent Document Retriever: Kleine Chunks für Suche, große Chunks für Kontext

6. Enterprise Use Cases

RAG wird in Unternehmen für vielfältige Anwendungen eingesetzt – hier die wichtigsten Bereiche.

Kundensupport

Chatbots mit Produktwissen, FAQ-Dokumenten und Ticket-Historie. Reduziert Ticket-Volumen um 30-50%.

Empfohlen: GPT-4o-mini + Pinecone

Interne Wissensdatenbank

Zugriff auf Confluence, SharePoint, Notion. Mitarbeiter finden Antworten in Sekunden statt Stunden.

Empfohlen: Claude 3.5 + Weaviate

Forschung & Analyse

Wissenschaftliche Papers, Patente, Marktberichte durchsuchen und zusammenfassen.

Empfohlen: GPT-4-turbo + Milvus

Code-Assistent

Unternehmenscodebase durchsuchen, Code erklären, Boilerplate generieren.

Empfohlen: StarCoder2 + Qdrant

Compliance & Recht

Verträge, Regularien, Richtlinien prüfen. DSGVO-Konformität sicherstellen.

Empfohlen: Claude 3.5 Opus + pgvector

Datenanalyse

Natürlichsprachliche Abfragen auf strukturierte Daten (Text-to-SQL).

Empfohlen: GPT-4o + DuckDB

7. Best Practices

Datenqualität

  • Dokumente vor Indexing bereinigen (Header/Footer entfernen)
  • Duplikate erkennen und deduplizieren
  • Metadaten konsistent pflegen
  • Regelmäßige Re-Indexing-Zyklen planen
  • Quellenangaben immer mitspeichern

Chunking optimieren

  • Chunk-Größe an Use Case anpassen
  • Overlap von 10-20% verwenden
  • Semantische Grenzen bevorzugen
  • Parent-Child-Strategie für langen Kontext
  • Chunking regelmäßig evaluieren

Evaluation & Testing

  • Gold-Standard-Datensatz erstellen
  • RAGAS-Metriken nutzen (Faithfulness, Relevancy)
  • A/B-Testing verschiedener Konfigurationen
  • User-Feedback systematisch sammeln
  • Continuous Monitoring etablieren

Sicherheit & Compliance

  • Zugriffskontrolle auf Dokumentebene
  • Sensible Daten vor Indexing filtern
  • Audit-Logs für alle Abfragen
  • DSGVO-konforme Löschung ermöglichen
  • Prompt Injection Schutz implementieren

8. FAQ – Häufige Fragen & Antworten

Häufige Fragen zu RAG

Was ist der Unterschied zwischen RAG und Fine-Tuning?

RAG ruft externes Wissen zur Laufzeit ab und fügt es als Kontext in den Prompt ein. Das Modell selbst wird nicht verändert.

Fine-Tuning trainiert das Modell mit domänenspezifischen Daten. Das Wissen wird in die Modellgewichte "eingebrannt".

  • RAG Vorteile: Günstiger, aktueller, transparenter, datenschutzfreundlicher
  • Fine-Tuning Vorteile: Bessere Stil-Anpassung, schnelleres Inference, kein Retrieval-Overhead
  • Kombination: Oft optimal – Fine-Tuning für Stil/Ton, RAG für Fakten
Wie groß sollten Chunks sein?

Es gibt keine Universallösung – die optimale Größe hängt vom Use Case ab:

  • Kundensupport / FAQ: 256–512 Tokens (präzise, kurze Antworten)
  • Dokumentenzusammenfassung: 1024–2048 Tokens (mehr Kontext nötig)
  • Code-Assistent: 512–1024 Tokens (Funktionen als Einheit)
  • Forschung: 1024–4096 Tokens (lange Passagen verstehen)

Faustregel: Lieber zu klein als zu groß. Zu große Chunks verwässern die Relevanz. Immer mit Overlap (10-20%) arbeiten.

Wie verhindere ich Halluzinationen in RAG?

RAG reduziert Halluzinationen deutlich, eliminiert sie aber nicht vollständig. Maßnahmen:

  • System-Prompt: "Antworte NUR basierend auf dem bereitgestellten Kontext. Wenn die Information nicht vorhanden ist, sage das."
  • Citation Enforcement: Modell muss Quellenangaben liefern
  • Faithfulness-Check: Automatische Prüfung, ob Antwort im Kontext belegt ist
  • Confidence Scoring: Niedrige Confidence → menschliche Überprüfung
  • Guardrails: Output-Filter für sensible Themen
Welches Embedding-Modell soll ich verwenden?

Die Wahl hängt von Sprache, Budget und Performance-Anforderungen ab:

  • Beste Qualität (Englisch): OpenAI text-embedding-3-large (3072 Dim)
  • Beste Qualität (Deutsch): sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2
  • Open Source Top: BAAI/bge-large-en-v1.5 oder jina-embeddings-v3
  • Budget / Lokal: all-MiniLM-L6-v2 (schnell, gut genug für viele Fälle)

Tipp: MTEB-Leaderboard konsultieren für aktuelle Benchmarks. Für deutsche Inhalte immer multilinguale Modelle testen.

Wie evaluiere ich meine RAG-Pipeline?

Systematische Evaluation ist entscheidend für Produktionsreife:

  • Gold-Standard-Datensatz: 100-500 manuell kuratierte Query-Answer-Paare
  • RAGAS-Metriken: Faithfulness, Answer Relevancy, Context Precision, Context Recall
  • Retrieval-Metriken: Hit Rate, MRR, NDCG
  • User-Feedback: Thumbs Up/Down, explizite Bewertungen
  • A/B-Testing: Verschiedene Chunk-Größen, Modelle, Retrieval-Strategien vergleichen

Tools: RAGAS, DeepEval, LangSmith, Arize Phoenix

Ist RAG DSGVO-konform?

RAG kann DSGVO-konform betrieben werden, erfordert aber sorgfältige Umsetzung:

  • Datenlokalisierung: Vektordatenbank in EU betreiben (z.B. Hetzner, AWS Frankfurt)
  • LLM-Auswahl: EU-hosted Modelle (Mistral, Aleph Alpha) oder On-Premise (Llama)
  • Zugriffskontrolle: Dokumentenberechtigung muss auf Retrieval-Ebene durchgesetzt werden
  • Löschkonzept: Vektoren müssen bei Löschrequest vollständig entfernt werden
  • Audit-Trail: Alle Abfragen und Antworten protokollieren
  • AV-Verträge: Mit allen Cloud-Anbietern (Pinecone, OpenAI, etc.)

Wichtig: Rechtsberatung einholen – dies ist keine Rechtsberatung.

Was kostet eine RAG-Implementierung?

Die Kosten variieren stark je nach Skalierung und Anforderungen:

  • Prototyping / MVP: 0–500 €/Monat (Open Source, lokale Modelle)
  • KMU / Abteilung: 500–3.000 €/Monat (Managed Services, API-Kosten)
  • Enterprise: 3.000–20.000+ €/Monat (hohe Volumina, SLAs, Support)

Kostentreiber: LLM-API-Calls (Token-Volumen), Vektordatenbank-Hosting, Embedding-Kosten, Entwicklungsaufwand

Spartipp: Kleinere Modelle für einfache Queries, Caching häufiger Fragen, Batch-Embedding

Wie aktualisiere ich die Wissensbasis ohne Downtime?

Strategien für kontinuierliche Aktualisierung:

  • Incremental Indexing: Nur neue/geänderte Dokumente re-indexieren
  • Versionierung: Neue Index-Version parallel aufbauen, dann umschalten
  • Metadata Filtering: Gültigkeitsdatum als Metadatum, abgelaufene Chunks filtern
  • CDC (Change Data Capture): Automatische Trigger bei Dokumentänderungen
  • Scheduled Re-Indexing: Nächtlicher Voll-Index für Konsistenz

Best Practice: Kombination aus Incremental Updates (Echtzeit) und periodischem Full-Rebuild (Konsistenz).

Zusammenfassung

Die wichtigsten Punkte

  • RAG = Retrieval + Generation: Externes Wissen abrufen, dann LLM antworten lassen
  • Löst LLM-Probleme: Halluzinationen, veraltetes Wissen, fehlendes Domänenwissen
  • 6-Schritte-Pipeline: Laden → Chunking → Embedding → Speichern → Retrieval → Generation
  • Vektordatenbanken: Pinecone, Weaviate, Chroma, pgvector – je nach Anforderung wählen
  • Chunking ist kritisch: 256–1024 Tokens, 10-20% Overlap, semantische Grenzen bevorzugen
  • Evaluation ist Pflicht: RAGAS-Metriken, Gold-Standard-Datensatz, User-Feedback
  • Sicherheit beachten: Zugriffskontrolle, DSGVO, Audit-Logs, Prompt Injection Schutz
  • Kosten variieren: Von kostenlos (Open Source) bis 20.000+ €/Monat (Enterprise)

Nächste Schritte

Bereit, Ihre erste RAG-Pipeline zu bauen? Starten Sie mit einem kleinen Prototyp:

  1. Framework wählen: LangChain, LlamaIndex oder Haystack
  2. Vektordatenbank starten: Chroma (lokal) oder Pinecone (Cloud)
  3. 10-20 Dokumente indexieren: PDFs, Docs, Confluence-Seiten
  4. Evaluieren: 20 Testfragen stellen, Qualität prüfen
  5. Iterieren: Chunk-Größe, Embedding-Modell, Prompt anpassen
Zu den KI-Tools

Weiterführende Themen

LLM-Grundlagen

Wie Large Language Models funktionieren – Transformer, Attention, Tokenization.

Zu LLM-Grundlagen
Prompt Engineering

Effektive Prompts schreiben – Chain-of-Thought, Few-Shot, System-Prompts.

Zu Prompt Engineering
KI-Agenten

Autonome KI-Agenten – Tool-Use, Planning, Multi-Agent-Systeme.

Zu KI-Agenten
KI-Sicherheit

Prompt Injection, Jailbreaks, Guardrails – sichere KI-Systeme bauen.

Zur KI-Sicherheit