Was ist RAG — und warum reicht ein LLM allein nicht aus?
Large Language Models wie GPT-5 oder Claude sind beeindruckend leistungsfähig, aber sie kennen Ihre internen Daten nicht. Fine-Tuning ist teuer, schwer zu aktualisieren und löst das Kernproblem nicht: Das Modell muss auf aktuelle, unternehmensspezifische Informationen zugreifen können.
Retrieval Augmented Generation (RAG) löst dieses Problem, indem relevante Dokumente zur Laufzeit abgerufen und dem Modell als Kontext übergeben werden. Statt das Modell umzutrainieren, liefern Sie ihm die richtigen Informationen zum richtigen Zeitpunkt.
Das Ergebnis: Präzise Antworten, die auf Ihren tatsächlichen Unternehmensdaten basieren — nachprüfbar, aktuell und mit Quellenangabe.
Die RAG-Pipeline im Detail
Ein produktionsreifes RAG-System besteht aus vier aufeinander abgestimmten Stufen. Fehler in einer frühen Stufe propagieren durch die gesamte Pipeline — daher lohnt sich Sorgfalt bei jedem Schritt.
1. Ingestion: Dokumente aufbereiten
Die Qualität Ihrer Antworten beginnt bei der Dokumentenaufbereitung. Hier werden Rohdaten in strukturierte, durchsuchbare Einheiten verwandelt.
Typische Quellen sind PDF, Word, PowerPoint, Confluence, SharePoint, interne Wikis und Ticket-Systeme. Jedes Format bringt eigene Herausforderungen mit: PDFs können gescannte Bilder enthalten, PowerPoint-Folien haben oft keine logische Textstruktur, und Confluence-Seiten sind mit Makros und Formatierungen durchsetzt. Gutes Preprocessing — Tabellen extrahieren, Bilder mit OCR erfassen, Header und Footer entfernen — ist die Grundlage für alles Weitere.
Der kritischste Schritt ist das Chunking: Wie werden Dokumente in durchsuchbare Einheiten zerlegt? Fixed-size Chunking ist einfach, zerstört aber Kontext. Semantic Chunking respektiert inhaltliche Grenzen und liefert bessere Ergebnisse, ist aber aufwendiger. Recursive Chunking geht hierarchisch vor und bewahrt die Dokumentstruktur. In jedem Fall sollten Metadaten wie Autor, Erstellungsdatum, Abteilung und Dokumenttyp extrahiert werden — sie ermöglichen spätere Filterung und verbessern die Retrieval-Qualität erheblich.
2. Embedding: Text in Vektoren umwandeln
Embedding-Modelle wandeln Text-Chunks in hochdimensionale Vektoren um. Semantisch ähnliche Texte liegen im Vektorraum nahe beieinander — das ist die Grundlage für die spätere Suche.
Die Modellauswahl hat direkten Einfluss auf die Ergebnisqualität. OpenAI text-embedding-3-large liefert mit 3072 Dimensionen hohe Genauigkeit, Cohere embed-v3 ist besonders stark bei mehrsprachigen Inhalten, und BGE-M3 bietet als Open-Source-Alternative Flexibilität ohne Abhängigkeit von externen APIs. Der Trade-off zwischen Dimensionalität und Performance ist dabei zentral: Mehr Dimensionen bedeuten bessere Unterscheidungsfähigkeit, aber höheren Speicherbedarf und langsamere Suche.
Für deutsche Unternehmensdaten ist Mehrsprachigkeit ein oft unterschätzter Faktor. Nicht alle Embedding-Modelle bilden die deutsche Sprache gleichwertig ab — ein Modell, das auf englischen Texten hervorragend performt, kann bei deutschen Fachtexten deutlich schwächer sein. Testen Sie die Retrieval-Qualität explizit mit deutschen Beispielen aus Ihrem Fachbereich.
3. Retrieval: Die richtigen Informationen finden
Die Retrieval-Stufe entscheidet, welche Chunks dem LLM als Kontext übergeben werden. Dies ist häufig der kritischste Engpass im gesamten System — und gleichzeitig der Hebel mit dem größten Optimierungspotenzial.
Die Basis bildet Vector Similarity Search (Cosine Similarity oder Dot Product), die semantisch ähnliche Chunks findet. In der Praxis reicht das allein aber selten aus. Hybrid Search kombiniert Dense Retrieval (Vektoren) mit Sparse Retrieval (BM25/Keyword-Suche) und fängt Fälle ab, in denen rein semantische Suche versagt — etwa bei Fachbegriffen, Produktnummern oder exakten Bezeichnungen.
Zwei weitere Techniken heben die Qualität nochmals deutlich an: Reranking durch einen Cross-Encoder, der die Top-k Ergebnisse nach tatsächlicher Relevanz neu sortiert (Verbesserung der Precision je nach Datensatz um 10-25 Prozentpunkte, vgl. Cohere-Reranking-Benchmarks), und Query Transformation, bei der die Nutzeranfrage vor der Suche umformuliert wird (HyDE, Multi-Query), um die Trefferquote bei vagen oder mehrdeutigen Fragen zu steigern.
4. Generation: Antworten mit Kontext erzeugen
Das LLM generiert eine Antwort auf Basis der abgerufenen Chunks. Die Qualität hängt stark vom Prompt-Design ab.
Kontextuelles Prompt Engineering sorgt dafür, dass das Modell ausschließlich auf Basis der bereitgestellten Dokumente antwortet — und ehrlich signalisiert, wenn die Information nicht ausreicht (Confidence Scoring). Citation Extraction verknüpft jede Aussage mit der Quelldatei und dem relevanten Abschnitt, sodass Nutzer Antworten verifizieren können. Das schafft Vertrauen und unterscheidet ein produktionsreifes System von einem Prototyp.
Abgerundet wird die Generation durch Guardrails: Themenfilter und Output-Validierung verhindern, dass das System Fragen außerhalb des definierten Anwendungsbereichs beantwortet oder halluzinierte Informationen als Fakten präsentiert.
Architektur-Entscheidungen
Vector Database
Die Wahl der Vector Database beeinflusst Performance, Skalierbarkeit und Betriebsaufwand:
| Lösung | Stärke | Einsatz | Hybrid Search |
|---|---|---|---|
| Pinecone | Managed, skalierbar | Enterprise SaaS | Ja |
| Weaviate | Flexible Schema | On-Premise / Cloud | Ja (BM25 + Vector) |
| pgvector | PostgreSQL native | Bestehende PG-Infrastruktur | Nein (nur Vector) |
| Qdrant | Performance, Filtering | High-throughput | Ja (Sparse + Dense) |
| Milvus | Skalierung auf Milliarden Vektoren | Große Datenmengen | Ja |
Praktischer Hinweis: Wenn Sie bereits PostgreSQL betreiben, ist pgvector der schnellste Einstieg. Für produktionsreife Systeme mit Hybrid Search empfehlen sich dedizierte Lösungen wie Weaviate oder Qdrant.
Chunking-Strategie
Die richtige Chunk-Größe ist einer der einflussreichsten Parameter im gesamten System:
- Zu klein (unter 256 Tokens): Kontext geht verloren, Antworten sind fragmentiert, das LLM kann Zusammenhänge nicht erkennen
- Zu groß (über 2048 Tokens): Irrelevante Information verwässert die Antwort, das Context Window wird ineffizient genutzt
- Empfehlung: 512-1024 Tokens mit 15-20% Overlap als Ausgangspunkt, dann anhand von Evaluationsmetriken optimieren
Wann Hybrid Search unverzichtbar ist
Rein vektorbasierte Suche versagt bei:
- Exakten Bezeichnungen: Produktnummern, Artikelbezeichnungen, interne Kürzel
- Fachterminologie: Domänenspezifische Begriffe, die im Embedding-Modell unterrepräsentiert sind
- Mehrsprachigen Dokumenten: Wenn Anfrage und Dokument in unterschiedlichen Sprachen vorliegen
Hybrid Search kombiniert semantisches Verständnis mit exakter Keyword-Suche und liefert in der Praxis konsistent bessere Ergebnisse.
Häufige Fehler bei RAG-Implementierungen
Die meisten RAG-Projekte scheitern nicht an der Technologie, sondern an vermeidbaren Fehlern in der Umsetzung.
1. Chunking ohne Kontext
Problem: Dokumente werden mechanisch in gleich große Stücke zerlegt, ohne Rücksicht auf inhaltliche Grenzen. Eine Tabelle wird in der Mitte getrennt, ein Absatz verliert seinen Bezug zur Überschrift.
Lösung: Semantic Chunking verwenden, das natürliche Dokumentstruktur respektiert. Überschriften als Metadata an jeden Chunk anhängen. Bei Tabellen: die gesamte Tabelle als einen Chunk behandeln.
2. Keine Metadata-Strategie
Problem: Alle Chunks landen ohne Kontext in der Datenbank. Bei der Suche nach "aktuelle Reisekostenrichtlinie" werden veraltete Versionen gleichwertig zurückgegeben.
Lösung: Erstellungsdatum, Dokumentversion, Abteilung und Dokumenttyp als Metadata erfassen. Bei der Suche Metadata-Filter einsetzen, um Relevanz zu erhöhen.
3. Evaluation wird vernachlässigt
Problem: Das System wird einmal aufgebaut und "fühlt sich gut an". Niemand misst systematisch, ob die Antworten korrekt und vollständig sind. Qualitätsprobleme fallen erst auf, wenn Nutzer sich beschweren.
Lösung: Von Anfang an ein Evaluationsframework einrichten (siehe nächster Abschnitt).
4. Zu viel Kontext ins Prompt stopfen
Problem: Um sicher zu gehen, werden 20 Chunks ins Prompt gepackt. Das LLM verliert den Fokus, die Antwortqualität sinkt, und die Kosten steigen.
Lösung: Weniger, dafür relevantere Chunks. Reranking einsetzen und die Top-3 bis Top-5 Ergebnisse verwenden. Qualität schlägt Quantität.
5. Keine Zugriffskontrollen
Problem: Der Chatbot gibt Informationen aus vertraulichen HR-Dokumenten an beliebige Mitarbeitende weiter, weil die Zugriffsrechte der Quelldokumente nicht auf Chunk-Ebene durchgesetzt werden.
Lösung: Role-Based Access Control (RBAC) auf Chunk-Ebene implementieren. Zugriffsrechte aus dem Quellsystem übernehmen und bei jeder Abfrage filtern.
RAG-Qualität messen und optimieren
Ein RAG-System ohne Evaluation ist wie ein Produkt ohne Tests — es funktioniert, bis es das nicht mehr tut. Systematische Messung ist der Schlüssel zu kontinuierlicher Verbesserung.
Die wichtigsten Metriken
| Metrik | Was sie misst | Zielwert |
|---|---|---|
| Hit Rate | Anteil der Anfragen, bei denen das relevante Dokument in den Top-k Ergebnissen ist | > 90% |
| Mean Reciprocal Rank (MRR) | Wie weit oben das relevante Dokument in den Ergebnissen steht | > 0.8 |
| Context Precision | Anteil der abgerufenen Chunks, die tatsächlich relevant sind | > 70% |
| Context Recall | Anteil der relevanten Informationen, die abgerufen wurden | > 85% |
| Answer Faithfulness | Ist die Antwort durch die abgerufenen Dokumente belegbar? | > 90% |
| Answer Relevancy | Beantwortet die generierte Antwort tatsächlich die gestellte Frage? | > 85% |
Evaluationsframeworks
- RAGAS (Retrieval Augmented Generation Assessment): Open-Source-Framework, das Faithfulness, Answer Relevancy, Context Precision und Context Recall automatisiert bewertet — ohne manuell gelabelte Testdaten
- DeepEval: Bietet zusätzlich Halluzinations-Erkennung und G-Eval-Metriken
- Custom Testsets: Erstellen Sie 50-100 repräsentative Frage-Antwort-Paare aus Ihrem Fachbereich. Diese "Golden Answers" sind der zuverlässigste Qualitätsindikator
Evaluationsprozess in der Praxis
- Baseline messen: Vor jeder Änderung den aktuellen Stand aller Metriken erfassen
- Eine Variable ändern: Chunk-Größe, Embedding-Modell oder Retrieval-Strategie anpassen — nie alles gleichzeitig
- A/B-Vergleich: Neue Konfiguration gegen die Baseline testen
- Regression erkennen: Automatisierte Tests, die bei Qualitätseinbrüchen warnen
- Nutzer-Feedback einbeziehen: Daumen-hoch/runter-Bewertungen in der Benutzeroberfläche liefern wertvolle Signale
Von der Wissensdatenbank zum produktiven System
Die technische RAG-Pipeline ist nur ein Teil der Lösung. In der Praxis entscheiden drei weitere Faktoren über den Erfolg:
Datenaktualität sicherstellen
Unternehmenswissen veraltet. Richtlinien werden aktualisiert, Prozesse ändern sich, Produkte werden eingestellt. Ein produktionsreifes RAG-System braucht:
- Inkrementelle Ingestion: Neue und geänderte Dokumente automatisch erkennen und verarbeiten
- Versionierung: Veraltete Chunks als solche markieren oder entfernen
- Freshness-Signale: Bei zeitkritischen Anfragen aktuelle Dokumente bevorzugen
Zugriffskontrollen durchsetzen
In Unternehmen mit unterschiedlichen Vertraulichkeitsstufen muss das RAG-System dieselben Zugriffsrechte durchsetzen wie die Quellsysteme. Das bedeutet: RBAC auf Chunk-Ebene, synchronisiert mit Active Directory oder dem Identity Provider.
Betrieb und Monitoring
- Latenz überwachen: End-to-End-Antwortzeit unter 3 Sekunden halten
- Kostencontrolling: Token-Verbrauch pro Anfrage tracken, um LLM-Kosten im Griff zu behalten
- Nutzungsanalyse: Welche Themen werden häufig angefragt? Wo gibt es Wissenslücken?
Wie wir RAG-Systeme umsetzen
Viele RAG-Projekte starten vielversprechend, stagnieren aber, wenn die ersten Edge Cases auftreten: Das System findet die richtige Information nicht, gibt veraltete Daten zurück oder halluziniert bei komplexen Fragen. Genau diese Probleme adressieren wir systematisch.
Typische Herausforderungen, die wir lösen:
- "Die Antworten sind oft falsch oder unvollständig" — Wir analysieren die Retrieval-Pipeline, identifizieren Schwachstellen im Chunking und Embedding und optimieren mit messbaren Evaluationsmetriken
- "Vertrauliche Dokumente tauchen in Antworten auf, die nicht jeder sehen sollte" — Wir implementieren RBAC auf Chunk-Ebene, synchronisiert mit Ihrem Identity Provider
- "Das System wird immer langsamer, je mehr Dokumente wir laden" — Wir optimieren die Vector-Database-Architektur und Ingestion-Pipeline für skalierbare Performance
- "Wir wissen nicht, ob die Antworten stimmen" — Wir richten ein Evaluationsframework ein, das Qualität kontinuierlich und automatisiert misst
Fazit: RAG richtig umsetzen heißt Retrieval-Qualität messbar machen
RAG ist die pragmatischste Methode, um LLMs mit Unternehmenswissen zu verbinden. Aber die Differenz zwischen einem "funktioniert irgendwie"-Prototyp und einem produktionsreifen System ist erheblich. Der Schlüssel liegt nicht in der Wahl des LLM oder der Vector Database — sondern in der systematischen Optimierung der Retrieval-Pipeline, unterstützt durch kontinuierliche Evaluation.
Drei konkrete nächste Schritte:
- Baseline schaffen: Definieren Sie 50 repräsentative Testfragen und messen Sie Hit Rate, MRR und Faithfulness Ihres aktuellen Systems
- Chunking hinterfragen: Prüfen Sie, ob Ihre Chunking-Strategie Dokumentstruktur respektiert oder Kontext zerstört
- Zugriffskontrollen prüfen: Stellen Sie sicher, dass vertrauliche Informationen nur an berechtigte Nutzer ausgegeben werden
Wissen nutzbar machen, ohne Kontrolle zu verlieren. Mit unserer KI-Wissensdatenbank analysieren wir Ihre bestehenden Datenquellen — oder konzipieren gemeinsam mit Ihnen ein System, das Retrieval-Qualität, Zugriffskontrollen und Skalierbarkeit von Anfang an mitdenkt. Jetzt Erstgespräch vereinbaren.