Sprachmodelle wie GPT-4 sind beeindruckend – aber sie haben ein zentrales Problem:
Sie erfinden Dinge. Oder wie es in der Fachsprache heißt: „Sie halluzinieren.“
Was aber, wenn du möchtest, dass ein Modell nur mit deinem Wissen antwortet – z. B. aus internen PDFs, Datenbanken oder Richtlinien?
Dann kommt RAG ins Spiel: Retrieval-Augmented Generation.
In diesem Artikel erfährst du:
- Was RAG ist – und wie es funktioniert
- Warum es oft besser ist als Finetuning
- Welche Tools du brauchst
- Wie ein typischer RAG-Workflow aussieht
- Welche Risiken und Grenzen es gibt
Was ist RAG – und warum braucht man das?
LLMs haben zwei Probleme im Unternehmenskontext:
- Ihr Wissen ist veraltet (Trainingsstand meist >6 Monate alt)
- Sie kennen deine Daten nicht (z. B. dein Intranet, deine Produktlogik)
Lösung: Das Modell nutzt aktuelle & interne Daten bei jeder Antwort.
RAG bedeutet: Das Modell recherchiert vor der Antwort – es zieht sich passende Inhalte aus einer externen Wissensquelle, statt einfach alles zu raten.
Vorteile gegenüber klassischem Finetuning:
| Kriterium | RAG | Finetuning |
|---|---|---|
| Aktualisierbarkeit | jederzeit neue Inhalte laden | jedes Mal neu trainieren |
| Datenschutz | keine festen Daten im Modell | Daten dauerhaft integriert |
| Flexibilität | Inhalte austauschbar | feste „Verankerung“ |
| Infrastruktur | leichtgewichtig, API-basiert | GPU-Cluster + Expertise nötig |
RAG ist wie ein LLM mit eingebautem Wissensmanager – es denkt nicht „aus dem Bauch“, sondern sucht zuerst nach Kontext.
Wie funktioniert ein RAG-System?
RAG besteht aus drei Hauptkomponenten:
- Retriever
→ durchsucht externe Inhalte (z. B. PDFs, Datenbank-Einträge) - RAG-Pipeline
→ kombiniert User-Frage + Fundstellen zu einem optimierten Prompt - Generator (LLM)
→ formuliert eine Antwort – auf Basis des gefundenen Kontexts
Typischer Ablauf:
textKopierenUserfrage → Retriever sucht Kontext → Prompt wird gebaut → LLM antwortet mit Quellenbezug
Beispielkomponenten (modular):
| Funktion | Tool/Libs |
|---|---|
| Chunking | LangChain, LlamaIndex, Haystack |
| Vektorsuche | Qdrant, Weaviate, FAISS, Pinecone |
| Embeddings | HuggingFace, OpenAI, Azure, E5, BAAI |
| LLM | GPT-4, Mistral, LLaMA, Claude, Gemini |
| Prompt-Logik | Templates, Chain-of-Thought, ReAct |
Welche Daten eignen sich für RAG?
RAG kann (fast) jede Textquelle verarbeiten – du musst nur die Struktur in den Griff bekommen.
Geeignete Quellen:
- Interne PDF-Dokumente
- Webseiten & Intranets
- Datenbankeinträge (nach Export)
- CSVs, JSON, XML
- PowerPoint, Word, E-Mails (nach Umwandlung)
Wichtig: „Chunking“ entscheidet
Ein RAG-System teilt Inhalte in kleine, semantisch sinnvolle Stücke (Chunks) auf – z. B. Absätze, FAQs oder Kapitelüberschriften.
Zu kleine Chunks = Kontext verloren. Zu große Chunks = relevante Infos übersehen.
Faustregel: Lieber inhaltlich trennen (Thema, Satzstruktur) als technisch (nach Zeichenlänge).
Beispiel: FAQ-RAG für den Support
Frage: „Was passiert, wenn mein Passwort abläuft?“
→ RAG sucht im Intranet-Export nach Textstellen wie:
„Passwörter müssen alle 90 Tage geändert werden. Bei Ablauf erhalten Sie eine Erinnerungsmail…“
Dann baut das System folgenden Prompt:
„Ein Nutzer hat gefragt: ‘Was passiert, wenn mein Passwort abläuft?’
Hier ist ein Auszug aus dem internen Regelwerk:
[…]
Formuliere bitte eine hilfreiche Antwort auf Basis dieses Wissens.“
→ Das Modell antwortet korrekt und mit Kontext – obwohl es die Antwort vorher nie „gelernt“ hat.
Architekturvarianten: Light vs. Heavy RAG
Variante 1: Leichtgewichtige RAG-API (ideal für KMU)
- Lokale Dateien oder Nextcloud-Ordner
- Embeddings mit SentenceTransformers (E5, BAAI)
- Vektorsuche über Qdrant oder FAISS
- Antwortgenerierung mit GPT-4 oder Mixtral
→ Eingebettet in Chat-UI oder Support-Modul
Variante 2: Unternehmens-RAG mit Live-Index
- Daten-ETL in Echtzeit (PDF + SQL + SharePoint + API)
- Custom Chunking & Klassifikation
- Scoring & Ranking der Retrieval-Ergebnisse
- Reranking durch Mini-LLM oder BGE
- Antwortverlinkung & Quellenanzeige
Fallstricke & Grenzen
RAG ist kein Wundermittel. Typische Probleme:
| Problem | Lösung / Hinweis |
|---|---|
| Kontext passt nicht zur Frage | Reranking / Query Expansion nötig |
| Nutzerfrage ist zu unpräzise | Prompt-Optimierung |
| Datensätze veraltet | Versionierung / regelmäßiges Crawling |
| Falsche Antwort trotz gutem Kontext | Prompt war zu schwach |
| Halluzination bleibt möglich | Zwinge Antwort auf Kontext zu basieren („Answer only using…“) |
Best Practices für RAG
- Chunke semantisch, nicht technisch.
- Nutze hochwertige Embeddings. (z. B. E5, OpenAI ada-002, BGE-large)
- Baue Prompt-Templates mit Kontextpflicht.
- Zeige Quellen an, wenn möglich.
- Trenne UI/UX sauber vom Backend.
Fazit & Ausblick
RAG ist ein einfacher, aber mächtiger Weg, um eigene Daten mit Sprachmodellen zu kombinieren – ohne Trainingsaufwand.
Wer RAG sauber aufsetzt, erhält ein System, das:
- präziser antwortet
- weniger halluziniert
- einfacher pflegbar ist
- und auch mit Open-Source-Modellen funktioniert
In Teil 10 der Serie zeigen wir:
Wie du RAG mit Vektorsuche, Metadatenfilter und Feedback-Loop kombinierst, um produktionsreife KI-Assistenten zu bauen.
❓ FAQ – Häufige Fragen
Was ist der Unterschied zwischen RAG und Finetuning?
Finetuning verändert das Modell selbst. RAG belässt das Modell unverändert, liefert aber neue Daten in den Prompt ein.
Ist RAG DSGVO-konform?
Ja – wenn du keine personenbezogenen Daten direkt im Prompt überträgst und deine Quellen sauber verwaltest.
Kann ich RAG mit GPT-4 verwenden?
Ja, über eigene Infrastruktur oder z. B. Azure GPT-4 in Verbindung mit einem Retrieval-Modul wie LangChain + Qdrant.
Was ist besser: Pinecone oder Qdrant?
Für Selbsthosting: Qdrant. Für skalierbare SaaS-Integrationen: Pinecone oder Weaviate.
