Retrieval Augmented Generation (RAG) löst ein konkretes Problem: LLMs kennen keine internen Prozessdokumente, keine aktuellen Produktspezifikationen und keine firmeneigenen Wissensbasen. RAG verbindet das Sprachverständnis moderner Sprachmodelle mit strukturiertem Zugriff auf eigene Daten. Das geht ohne aufwändiges Fine-Tuning und ohne Datenweitergabe an externe Dienste.
Das Ergebnis: Mitarbeitende können in natürlicher Sprache Fragen zu internen Dokumenten stellen und bekommen präzise, quellenbasierte Antworten.
Was RAG von Fine-Tuning unterscheidet
Fine-Tuning bringt einem Modell neues Wissen durch Nachtraining bei. Das klingt intuitiv richtig, hat aber gravierende Nachteile: Es ist teuer, zeitaufwändig und muss bei jedem Dokumentenupdate wiederholt werden. Außerdem “vergisst” das Modell beim Fine-Tuning häufig älteres Wissen. Dieses Phänomen wird als Catastrophic Forgetting bezeichnet.
RAG arbeitet anders: Das LLM bleibt unverändert. Stattdessen wird zur Laufzeit relevanter Kontext aus einer Wissensdatenbank abgerufen und dem Prompt hinzugefügt. Das Modell sieht dann nicht nur die Frage, sondern auch die passenden Dokumentenausschnitte.
| Kriterium | Fine-Tuning | RAG |
|---|---|---|
| Update-Aufwand | Hoch (Neutraining) | Niedrig (Dokument einspielen) |
| Kosten | Hoch | Gering |
| Aktualität | Beim Training eingefroren | Laufend aktualisierbar |
| Transparenz | ”Black Box” | Quellenangabe möglich |
| Datenschutz | Daten im Training | Daten bleiben lokal |
Für die meisten Unternehmensanwendungen (interne Q&A-Systeme, Support-Bots, Dokumentenanalyse) ist RAG die pragmatischere Wahl.
Architektur: Die drei Kernkomponenten
Ein RAG-System besteht aus drei Phasen: Indexierung, Retrieval und Generation.
Indexierung
Dokumente werden in Chunks aufgeteilt, durch ein Embedding-Modell in Vektoren umgewandelt und in einem Vector Store gespeichert. Dieser Schritt läuft einmalig (oder inkrementell bei neuen Dokumenten).
Retrieval
Bei einer Anfrage wird die Frage ebenfalls in einen Vektor umgewandelt. Der Vector Store findet die semantisch ähnlichsten Chunks per Approximate Nearest Neighbor Search. Diese Chunks werden als Kontext an das LLM übergeben.
Generation
Das LLM beantwortet die Frage auf Basis des abgerufenen Kontexts. Gute RAG-Implementierungen geben dabei die Quell-Chunks als Zitate mit aus, um Nachvollziehbarkeit und Vertrauen zu schaffen.
from anthropic import Anthropic
import chromadb
client = Anthropic()
vector_db = chromadb.Client()
collection = vector_db.get_collection("company_docs")
def rag_query(question: str, n_results: int = 5) -> dict:
# 1. Retrieval: Relevante Chunks holen
results = collection.query(
query_texts=[question],
n_results=n_results,
)
context_chunks = results["documents"][0]
sources = results["metadatas"][0]
# 2. Kontext in Prompt einbauen
context = "\n\n---\n\n".join(context_chunks)
prompt = f"""Beantworte die folgende Frage ausschließlich auf Basis des bereitgestellten Kontexts.
Wenn die Antwort im Kontext nicht enthalten ist, sage das explizit.
Kontext:
{context}
Frage: {question}"""
# 3. Generation
response = client.messages.create(
model="claude-opus-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": prompt}],
)
return {
"answer": response.content[0].text,
"sources": sources,
}Chunking-Strategien: Das unterschätzte Detail
Die Qualität eines RAG-Systems steht und fällt mit der Chunking-Strategie. Zu große Chunks bringen zu viel irrelevanten Kontext, zu kleine Chunks reißen Sinnzusammenhänge auseinander.
Feste Fenstergröße mit Overlap
Der einfachste Ansatz: Text in Blöcke von z.B. 512 Tokens aufteilen, mit 50-100 Token Überlapp zwischen benachbarten Chunks. Der Overlap verhindert, dass wichtige Satzübergänge verloren gehen.
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=64,
separators=["\n\n", "\n", ".", " "],
)
chunks = splitter.split_text(document_text)Semantisches Chunking
Für strukturierte Dokumente (Handbücher, Prozessdokumentation) empfiehlt sich semantisches Chunking. Dokumente werden an natürlichen Grenzen geteilt: Überschriften, Absätze, Aufzählungen. So bleibt der Sinnzusammenhang innerhalb eines Chunks erhalten.
Hierarchisches Chunking (Parent-Child)
Ein fortgeschrittener Ansatz: Kleine Chunks für das Retrieval, aber bei einem Treffer wird der umgebende größere Kontext an das LLM übergeben. Das verbessert sowohl die Retrieval-Präzision als auch die Antwortqualität.
In der Praxis hat sich bei uns gezeigt: Für Fließtext (Policies, FAQs) funktioniert 512 Tokens mit Overlap gut. Für strukturierte Dokumente ist semantisches Chunking klar überlegen.
Embedding-Modell und Vector Store wählen
Embedding-Modelle
Für deutschsprachige Dokumente empfehlen sich multilinguale Modelle:
- multilingual-e5-large (Microsoft): Gute DE-Performance, lokal ausführbar
- text-embedding-3-large (OpenAI): Sehr hohe Qualität, API-abhängig
- nomic-embed-text (Nomic AI): Open Source, lokal, gute Balance
Für sensible Unternehmensdaten: Lokal laufende Modelle bevorzugen, keine Daten an externe APIs senden.
Vector Stores
| Tool | Einsatzgebiet |
|---|---|
| ChromaDB | Prototypen, lokale Entwicklung |
| Qdrant | Produktionssysteme, Self-Hosted, DSGVO-konform |
| pgvector | PostgreSQL bereits im Stack vorhanden |
| Pinecone | Managed Cloud, schnelles Setup |
Für Enterprise-Deployments im DACH-Raum ist Qdrant Self-Hosted eine bewährte Wahl: DSGVO-konform, skalierbar, mit gutem Python-SDK.
Typische Fallstricke in der Praxis
Retrieval-Qualität messen
Viele Teams optimieren intensiv die Generation (Prompt-Engineering), vernachlässigen aber das Retrieval. Wenn die falschen Chunks abgerufen werden, hilft auch das beste LLM nicht. Retrieval-Metriken wie MRR (Mean Reciprocal Rank) und Recall@K sollten Teil des Evaluierungsprozesses sein.
Halluzinationen trotz Kontext
LLMs können auch mit bereitgestelltem Kontext falsche Schlüsse ziehen. Gegenmaßnahmen:
- System-Prompt explizit anweisen, nur aus dem Kontext zu antworten
- Antworten mit Quellenangaben verbinden (Chunk-ID, Dokumentenname)
- Niedrigen Temperature-Wert setzen (0.0–0.3) für faktische Abfragen
Chunk-Metadaten nicht vergessen
Jeder Chunk sollte Metadaten tragen: Quelldokument, Erstellungsdatum, Abteilung, Freigabestatus. Das ermöglicht gezielte Filterung (“nur Dokumente aus Q1 2026”) und nachvollziehbare Quellenangaben.
Fazit
RAG ist kein Hype-Thema mehr. Es ist ein produktionsreifes Muster für Unternehmensanwendungen, die KI mit internem Wissen verbinden. Die Einstiegshürde ist niedrig: Mit ChromaDB, einem lokalen Embedding-Modell und einem LLM-API-Zugang lässt sich ein funktionierender Prototyp in einem Tag aufsetzen.
Der Aufwand steckt im Detail: sauberes Chunking, robustes Retrieval-Evaluation und eine durchdachte Update-Strategie für neue Dokumente. Das sind genau die Fragen, die wir in Kundenprojekten gemeinsam durcharbeiten.
Wer tiefer einsteigen möchte, findet im Artikel zu KI-Agenten im Enterprise-Einsatz Informationen, wie RAG-Systeme in größere Agenten-Architekturen eingebettet werden. Wenn die Infrastruktur für das Deployment steht, lohnt sich auch ein Blick auf Cloud-Migration im Mittelstand, da viele der Prinzipien auch für KI-Workloads gelten.
Sprich mit uns über dein RAG-Projekt →
Häufige Fragen
Warum ist RAG besser als Fine-Tuning für Unternehmenswissen?
RAG lässt Modelle unverändert und bindet Wissen zur Laufzeit. Fine-Tuning trainiert Modelle um, ist teuer, zeitaufwändig und muss bei jedem Update wiederholt werden. RAG ist aktueller (Dokumente können live aktualisiert werden), günstiger, transparenter (mit Quellenangaben) und schützt Datenschutz (Daten bleiben lokal).
Wie wählt man die richtige Chunking-Strategie?
Für Fließtext funktioniert 512 Tokens mit 64 Token Overlap gut. Für strukturierte Dokumente ist semantisches Chunking überlegen, das Inhalte an natürlichen Grenzen teilt. Ein fortgeschrittener Ansatz: hierarchisches Parent-Child-Chunking mit kleinen Chunks beim Retrieval und größerem Kontext beim LLM.
Welcher Vector Store ist für Enterprise am besten?
Für DSGVO-konforme Self-Hosted-Deployments: Qdrant ist skalierbar und gut dokumentiert. Wenn PostgreSQL bereits im Stack läuft: pgvector ist praktisch. Für prototypische Entwicklung: ChromaDB ist niedrigschwellig. Für Managed Cloud: Pinecone ermöglicht schnelles Setup ohne Ops-Overhead.
Wie verhindert man Halluzinationen in RAG-Systemen trotz Kontext?
Explizit im System-Prompt anweisen, nur aus dem Kontext zu antworten. Antworten mit Quellenangaben verbinden (Chunk-ID, Dokumentenname). Temperature niedrig halten (0.0-0.3) für faktische Abfragen. Retrieval-Metriken wie MRR und Recall@K monitoren, weil wenn falsche Chunks abgerufen werden, hilft auch das beste LLM nicht.
