Was ist RAG
RAG (Retrieval-Augmented Generation) ist ein Ansatz, bei dem ein Sprachmodell relevante Fragmente aus Ihrer Wissensbasis sucht, bevor es antwortet, und dann Text generiert. Statt alle Dokumente in den Modellgewichten zu "speichern" oder vollständig in den Kontext zu laden, findet das System die passenden Stücke und fügt sie in den Prompt ein. Im Folgenden - was RAG ist, wie die Pipeline funktioniert und wann die Methode in Production sinnvoll ist.
Definition in einfachen Worten
Retrieval-Augmented Generation verbindet zwei Schritte:
- Retrieval (Abruf) - zur Nutzeranfrage findet das System die passendsten Textfragmente in einem Korpus: Wiki, PDF, Tickets, Code, Richtlinien.
- Generation (Generierung) - das LLM erhält die gefundenen Fragmente als Kontext und formuliert die Antwort darauf basierend.
Der Begriff etablierte sich nach Lewis et al. (2020) und wurde Standard für Unternehmens-Chatbots, Support-Systeme und interne Assistenten. RAG ersetzt das Modell nicht - es ergänzt es mit aktuellen Daten, die nicht im Training waren oder gestern geändert wurden.
Wie RAG funktioniert: typische Pipeline
┌──────────┐ ┌─────────────┐ ┌──────────────┐ ┌─────────┐
│Dokumente │───▶│ Chunking + │───▶│ Vector DB │ │ │
│ (PDF, MD)│ │ Embeddings │ │ (Index) │ │ LLM │
└──────────┘ └─────────────┘ └──────┬───────┘ │ │
│ │ │
Anfrage ──▶ Embedding ──▶ Top-K ──▶ Prompt + Kontext ──▶ Antwort
1. Datenvorbereitung (offline)
- Ingestion - Parsing von PDF, HTML, Markdown, Confluence, Notion, Repositories.
- Chunking - Aufteilung in 256-1024 Token-Fragmente mit Überlappung, damit der Sinn nicht am Absatzende abreißt.
- Embedding - jedes Chunk wird per Embedding-Modell zum Vektor (OpenAI text-embedding-3, Cohere, Open-Source BGE, E5).
- Indexierung - Vektoren in Vector Store: Pinecone, Weaviate, Qdrant, pgvector, Chroma, Milvus.
Diese Phase läuft beim Hinzufügen oder Aktualisieren von Dokumenten, nicht bei jeder Nutzeranfrage.
2. Anfrage (online)
- Die Nutzerfrage wird mit demselben Encoder eingebettet.
- Die Vector DB liefert Top-K nächste Chunks (meist K = 3-10).
- Optional - Reranking: ein zweites Modell sortiert Kandidaten relevanter als reine Kosinus-Ähnlichkeit.
- Gefundene Fragmente gehen in System/User-Prompt mit Anweisung "nur aus dem Kontext antworten".
- Das LLM generiert die Antwort; oft mit Quellenangaben zu Chunk-ID oder Seite.
RAG-Qualität hängt zu ~80% vom Retrieval ab: fehlt das richtige Fragment in Top-K, halluziniert das Modell oder sagt ehrlich "weiß nicht".
Zentrale Komponenten
| Komponente | Rolle | Beispiele |
|---|---|---|
| Embedding-Modell | Text → Vektor für semantische Suche | text-embedding-3-large, bge-m3, voyage-3 |
| Vektordatenbank | Speicherung und schnelle ANN-Suche | Qdrant, Pinecone, pgvector, Weaviate |
| Chunking-Strategie | Balance Detail vs Rauschen | Feste Größe, semantischer Split, nach Überschriften |
| LLM | Finale Antwort mit Reasoning | GPT-5.6, Claude Fable 5, Gemini 3.1, lokale Modelle |
| Orchestrator | Pipeline, Cache, Logging | LangChain, LlamaIndex, Haystack, eigener Code |
2026 implementieren viele Frameworks (LlamaIndex, LangGraph) und Produkte (Cursor @Codebase, Notion AI, Glean-ähnliche Systeme) RAG unter der Haube - das Grundverständnis der Pipeline bleibt für Debugging und Tuning nötig.
Praktische Anwendungsfälle
- Support und FAQ - Antworten aus Artikelbasis und alten Tickets ohne manuelle Suche.
- Internes Wiki - "Urlaub beantragen", "wo liegt das Incident-Runbook".
- Legal und Compliance - Suche in Verträgen und Richtlinien mit Klauselverweis.
- Code-Assistenten - semantische Repo-Suche (Index + Embeddings), Ergänzung zum vollen IDE-Kontext.
- Dokumentenanalyse - Fragen zu Reports, Studien, Meeting-Transkripten.
Typisches Muster: großer Korpus, häufige Updates, Quellenangaben nötig - RAG passt besser als einmaliges Datei-Upload im Chat.
RAG vs Fine-Tuning vs langer Kontext
| Ansatz | Wann sinnvoll | Grenze |
|---|---|---|
| RAG | Aktuelle Dokumente, transparente Quellen, Updates ohne Retraining | Abhängig von Suchqualität |
| Fine-Tuning | Stil, Format, Domänenterminologie, stabiles Wissen | Teuer bei Datenänderung |
| Langer Kontext | Ganzes Dokument oder Codebase in einer Session | Kosten, Latenz, "lost in the middle" |
Diese Ansätze schließen sich nicht aus. Typisches Setup 2026: RAG für Korpus-Suche + langer Kontext für wenige volle Dateien + leichtes Fine-Tuning oder System-Prompt für Unternehmens-Tonalität.
Grenzen und typische Probleme
RAG löst Wissenszugang, aber nicht:
- garantierte faktische Korrektheit (Modell kann Kontext ignorieren)
- komplexe mehrstufige Aktionen (Tools / MCP nötig)
- automatische Index-Aktualität (ETL bei Dokumentänderung)
Häufige Fehler:
- Schlechtes Chunking - Tabelle halbiert, Formel ohne Überschrift.
- Falsches K - zu wenig Chunks → Fakten fehlen; zu viele → Rauschen im Prompt.
- Veralteter Index - Dokument aktualisiert, Embedding nicht neu berechnet.
- Hybrid-Suche fehlt - reine semantische Suche verfehlt SKU, ID, Datum; Hybrid (BM25 + Vektoren) hilft.
Für Production: Retrieval-Hit-Rate monitoren, A/B für Chunk-Größe, Human Feedback, Guardrails "bei niedriger Confidence - nicht antworten".
RAG-System verbessern
- Metadaten - Abteilungs-Tags, Datum, Dokumentversion; Filter vor Vector Search.
- Hybrid-Suche - Keyword (BM25) + semantisch; besonders bei technischer Doku.
- Reranker - Cross-Encoder nach Top-20 → finales Top-5.
- Query-Transformation - Umformulierung, Multi-Query, HyDE (hypothetisches Dokument).
- Graph RAG - verknüpfte Entitäten (Personen, Projekte, Abhängigkeiten) über flache Chunks.
- Evaluation - Frage-Gold-Antwort-Dataset; Faithfulness, Context Recall (RAGAS, DeepEval).
Start mit einfacher Pipeline (Chunk → Embed → Top-5 → GPT), Baseline messen, Komplexität nur dort erhöhen, wo Metriken steigen.
RAG und Agent-Ökosystem
RAG wird oft mit MCP und Tool Calling kombiniert: RAG holt Wissen aus Dokumenten, Tools führen Aktionen aus (Ticket erstellen, Kontostand abfragen). In Cursor ist der semantische @Codebase-Index ein RAG-Fall über Projektdateien; im Enterprise skaliert man dasselbe Muster auf Confluence, Slack und CRM.
| Schicht | Aufgabe |
|---|---|
| RAG | "Was steht in den Dokumenten?" |
| MCP / Tools | "Was ist jetzt im System? Handle" |
| LLM | Antwort synthetisieren und Schritte planen |
Fazit
RAG ist der Standardweg, ein LLM an Ihre Daten anzubinden ohne Retraining: Dokumente werden indexiert, relevante Fragmente pro Anfrage abgerufen, das Modell antwortet darauf gestützt. Skaliert vom Chroma + OpenAI-Prototyp bis zum Cluster mit Hybrid-Suche, Reranking und Qualitätsmonitoring.
Für das erste Projekt: einen Korpus wählen (z. B. 50-seitiges FAQ), Chunking und Top-K einstellen, messen ob der richtige Absatz im Kontext landet - das ist der wichtigste Erfolgsindikator.
Häufig gestellte Fragen
Worin unterscheidet sich RAG von Fine-Tuning?
Fine-Tuning ändert Modellgewichte anhand Ihrer Beispiele - gut für Stil, Format und stabile Muster. RAG berührt keine Gewichte: jede Anfrage holt frische Fragmente aus dem Index. Wöchentlich wechselnde Dokumente lassen sich per RAG (Reindexierung) leichter aktualisieren als per Retraining. Fine-Tuning, wenn das Modell ein Verfahren auswendig kennen soll; RAG, wenn Aktualität und Quellenangabe zählen.
Brauche ich RAG bei Millionen-Token-Kontext?
Langer Kontext (1M+ Tokens bei Claude, Gemini, GPT-5.6) erlaubt viel Text in einer Session, ersetzt RAG aber nicht für große Korpora: 100 GB PDF passen nicht in den Prompt, Kosten und Latenz wachsen linear. RAG wählt relevante Stücke; langer Kontext eignet sich für wenige volle Dateien nach Retrieval oder Repo-Code in der IDE. In der Praxis kombiniert man beides.
Welche Vektordatenbank für RAG?
Abhängig von Skala und Infrastruktur. pgvector - wenn PostgreSQL schon da und bis Millionen Vektoren. Qdrant, Weaviate, Milvus - self-hosted oder managed beim Wachstum. Pinecone - managed ohne Cluster-Betrieb. Chroma - schneller Prototyp-Start. Entscheidend sind Embedding-Qualität, Chunking und Monitoring; viele Production-Systeme starteten mit Chroma und migrierten zu pgvector oder Qdrant ohne App-Logik-Wechsel.
Warum liefert RAG manchmal falsche Antworten?
Hauptursachen: (1) Retrieval verfehlt - richtiges Chunk nicht in Top-K; (2) Modell ignorierte Kontext und ergänzte aus "Gedächtnis"; (3) veralteter Index; (4) widersprüchliche Chunks. Hilft bessere Suche (Hybrid, Reranker), strikter Prompt ("wenn nicht im Kontext - sage ich weiß nicht"), Quellenangaben und Eval-Set für Regressionen.
Lässt sich RAG mit lokalen Modellen bauen?
Ja. Embedding-Modelle (bge-m3, nomic-embed) und LLMs (Llama, Qwen, Mistral via Ollama) laufen offline; Vector Store kann lokal sein. Grenzen - Qualität auf schwacher Hardware; Modellgröße an GPU/RAM anpassen. Für vertrauliche Daten (Medizin, Finanzen, Behörden) ist lokales RAG üblich: Dokumente verlassen das Perimeter, Pipeline-Architektur wie in der Cloud.