Retrieval Augmented Generation (RAG)

Bei Retrieval Augmented Generation (RAG) wird ein KI-System mit einem externen Wissensspeicher verbunden. Dadurch beruhen die Antworten der KI nicht nur auf Trainingsdaten, sondern werden um relevante Quellen erweitert.

RAG ist die gängigste Form von Grounding. Grounding ist das übergeordnete Prinzip, Modellantworten an überprüfbare externe Quellen zu koppeln statt allein an Trainingsmuster.

So können aktuelle Informationen oder unternehmensspezifisches Wissen eingebunden werden, ohne dass das Modell neu trainiert werden muss.

Eingesetzt wird Retrieval Augmented Generation vor allem in der Enterprise-KI: Wissensmanagement, Assistenz für Service und Vertrieb, technische Dokumentation, Support-Chatbots.

Eine RAG-Pipeline holt zu jeder Nutzeranfrage passende Textstellen aus einer Dokumentensammlung, einer Datenbank oder einem Wissensgraphen. Sie fügt sie der Anfrage (Prompt) hinzu und lässt das Sprachmodell daraus eine Antwort mit Quellenbezug erzeugen.

Den Begriff prägten 2020 Patrick Lewis et al. in „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks“ (arXiv 2005.11401, NeurIPS 2020).

Kerngedanke: ein parametrischer Speicher (das vortrainierte Sprachmodell) wird mit einem nicht-parametrischen Speicher (ein dichter Vektorindex über Wikipedia) verbunden. Ein neuronaler Retriever greift zur Inferenzzeit darauf zu.

Wie RAG funktioniert: die vier Schritte einer Pipeline

Eine RAG-Pipeline hat vier Phasen: Indexierung der Wissensbasis, Retrieval zur Anfragezeit, Augmentation des Prompts und Generierung der Antwort. Drei davon laufen bei jeder einzelnen Anfrage. Nur die Indexierung passiert vorab oder im Hintergrund.

Indexierung der Wissensbasis

In der Indexierungsphase werden die Quelldokumente — Handbücher, Tickets, Produktdaten, PDFs, Wiki-Seiten — in kleinere Abschnitte (Chunks) zerlegt. Ein Embedding-Modell überführt sie in Vektoren, die in einem Vektorspeicher abgelegt werden. Üblich sind Chunkgrößen zwischen 128 und 512 Tokens. Faktenbasierte Inhalte mit Keyword-Matching profitieren von kleineren Chunks (128–256 Tokens), konzeptuelle Inhalte und Zusammenfassungen von größeren (256–512 Tokens).

Als Speicher kommen dedizierte Vektordatenbanken (Qdrant, FAISS) oder Erweiterungen bestehender Systeme (pgvector für PostgreSQL, Elasticsearch/OpenSearch) infrage. Welche Wahl passt, hängt mehr von Skalierung und vorhandener Infrastruktur ab als vom RAG-Konzept selbst.

Retrieval zur Anfragezeit

Trifft eine Nutzerfrage ein, wird sie ebenfalls eingebettet und gegen den Vektorindex abgeglichen. Der Retriever liefert die k ähnlichsten Chunks. In der Praxis genügt reines Dense Retrieval selten: exakte Tokens wie Produktcodes, Funktionsnamen oder seltene Eigennamen trifft BM25 zuverlässiger. Dense-Vektoren erfassen dafür Paraphrasen und Intent. Deshalb dominiert in produktiven Systemen Hybrid Search: beide Verfahren laufen parallel, danach werden die Ergebnislisten zusammengeführt.

Augmentation und Generierung

Die ausgewählten Chunks werden zusammen mit der Originalfrage und einer Systemanweisung zu einem Prompt zusammengesetzt — das ist der Augmentation-Schritt. Das LLM erzeugt daraus eine Antwort und sollte die verwendeten Quellen zitieren. Erst dieser Quellenbezug unterscheidet eine RAG-Antwort von einer freien LLM-Antwort: er macht die Aussage prüfbar und verschiebt die Verantwortung von „das Modell behauptet“ zu „das Modell zitiert“.

RAG, Fine-Tuning oder Long-Context? Was man wann nimmt

Die drei Ansätze werden oft als Konkurrenten dargestellt, sind aber Antworten auf unterschiedliche Fragen. RAG ändert das Modell nicht, sondern erweitert es um eine Wissensquelle. Fine-Tuning verändert die Gewichte. Long-Context vergrößert nur das Eingabefenster.

RAG vs. Fine-Tuning

RAG passt, wenn sich das relevante Wissen häufig ändert, wenn jede Antwort eine Quelle nachweisen muss oder wenn die Wissensbasis aus rechtlichen oder organisatorischen Gründen vom Modell getrennt bleiben soll. Inhalte lassen sich aktualisieren, indem die Vektordatenbank neu indexiert wird — ohne Modelltraining.

Fine-Tuning passt, wenn nicht Wissen, sondern Verhalten angepasst werden soll: Tonalität, Antwortstruktur, ein bestimmter Klassifikationsstil. Es ist teurer, weil spezialisiertes Labeling und Trainingsrechenzeit anfallen. Nach Abschluss bleibt das Modell auf dem damaligen Wissensstand stehen. In der Praxis schließen sich die Ansätze nicht aus — ein domänen-fine-getuntes Modell als Generator in einer RAG-Pipeline ist eine gängige Kombination.

RAG vs. Long-Context-Prompting

Mit Kontextfenstern von mehreren hunderttausend Tokens kam die These auf, RAG werde überflüssig. Sie hat sich nicht bestätigt. Wer ein ganzes Handbuch in den Prompt schiebt, zahlt für jede Anfrage den vollen Tokenpreis. Er riskiert Qualitätsverluste durch verdünnten Kontext (der dokumentierte Lost-in-the-Middle-Effekt) und gibt die Möglichkeit auf, gezielt nur die relevanten Stellen auszuwählen. Long-Context und RAG ergänzen sich: das Retrieval entscheidet, was hineingehört, das große Fenster gibt dem Modell den Platz für umfangreichere Kontextpakete.

RAG vs. klassische Volltext- und Semantic Search

Klassische Suche liefert eine Trefferliste. RAG liefert eine formulierte Antwort mit Quellenbezug. Semantic Search ist als Retriever-Komponente Teil vieler RAG-Systeme, aber nicht das Gesamtsystem. Wer eine Liste zur weiteren manuellen Sichtung braucht, kommt mit Enterprise Search aus; wer eine direkt verwertbare Antwort braucht, nicht.

Was über Qualität entscheidet — Chunking, Embeddings, Hybrid Search, Reranking

Die Qualität einer RAG-Pipeline begrenzt selten das Sprachmodell allein — sie steht und fällt mit dem, was der Retriever liefert. Vier Stellschrauben tragen den Hauptanteil.

Chunk-Größe und Overlap

Der übliche Arbeitsbereich liegt bei 128–512 Tokens pro Chunk. Als Default für allgemeine Anwendungsfälle hat sich rekursives Splitting auf 512 Tokens mit 10–20 % Overlap etabliert. NVIDIA testete auf FinanceBench Overlap-Werte von 10 %, 15 % und 20 % und fand 15 % als optimal. Der Test lief auf 1.024-Token-Chunks; weil der Overlap als prozentualer Anteil der Chunkgröße angegeben wird, ist der Richtwert weitgehend chunkgrößen-unabhängig und damit auf eine 512-Token-Basis übertragbar — dort entsprechen 15 % rund 75 Tokens. Unterhalb von 10 % Overlap geht Grenzkontext an den Chunk-Übergängen verloren. Oberhalb von 25 % entsteht Rauschen durch nahezu identische Treffer. Faktenfragen profitieren von kleineren Chunks, Konzeptzusammenfassungen von größeren.

Embedding-Modell wählen

Drei Auswahlkriterien dominieren: Retrieval-Qualität, Latenz, Hosting-Anforderung. Als Orientierung dient der MTEB-Benchmark — im Cloud-Segment etwa Modelle von Cohere, OpenAI oder Google (Gemini Embedding), für den Self-Hosted-Betrieb offene Modelle wie die BGE- oder Qwen-Embedding-Familie, dazu kleinere Modelle der E5-Reihe für latenzkritische Anwendungen. Die MTEB-Spitze rotiert allerdings schnell, und MTEB v2 (ab 2026) ist nicht direkt mit v1 vergleichbar; konkrete Ranglistenplätze und Punktwerte veralten innerhalb von Monaten. Maßgeblicher als der Tabellenplatz ist ohnehin: MTEB-Werte sagen die Performance auf den eigenen Domänendaten nicht zuverlässig vorher. Vor der Festlegung lohnt ein Benchmark auf einer kleinen, repräsentativen Anfragemenge aus der eigenen Wissensbasis.

Hybrid Search und Reranking

Hybrid Search (Dense plus BM25) und eine nachgelagerte Reranking-Schicht heben die Trefferqualität messbar über das, was ein einzelnes Verfahren liefert. Die Größenordnung lässt sich an publizierten Benchmarks ablesen: Eine akademische Untersuchung auf Finanzdokumenten zeigt für eine zweistufige Pipeline aus Hybrid Retrieval und neuralem Reranking Recall@5 von 0,816 und MRR@3 von 0,605; dieselbe Untersuchung findet, dass BM25 auf Finanzdokumenten selbst State-of-the-Art Dense Retrieval schlägt. Einzelne Praxis-Benchmarks (z. B. ein veröffentlichter Test eines FastAPI-RAG-Systems, Medium 2026) berichten dieselbe Richtung in deutlicher Form — von rund 60 % Recall bei reinem Dense oder BM25 auf über 90 % in der Vollkaskade mit Reranker; solche Einzelwerte sind illustrativ, nicht repräsentativ. Praktisch heißt das: in fast jedem ernsthaften System gehören BM25 (über Elasticsearch oder OpenSearch), ein Dense Retriever und ein Reranker auf den letzten 20–50 Treffern zusammen — nicht eines davon als Alleinlösung.

Wo RAG in der Praxis scheitert

Es kommt durchaus vor, dass RAG-Pipelines scheitern. Die Ursachen liegen fast nie im LLM, sondern im Retrieval-Pfad.

Stille Degradation: Wenn das System antwortet, aber falsch liegt

Ein gescheitertes Produktions-RAG erkennt man daran, dass nichts abstürzt. Die Pipeline liefert weiter Antworten, das Dashboard zeigt gesunde Latenz, die Evaluationsergebnisse vom Launch stehen noch im Wiki.

Darunter degradiert das System auf jeder relevanten Achse: neue Dokumentenversionen sind nicht indexiert, der Embedding-Raum passt nicht mehr zur veränderten Wissensbasis, irrelevante Treffer kommen häufiger durch.

Drei Anker helfen bei der Diagnose: ein fest definierter Goldstandard-Fragensatz, der periodisch gegen Produktion läuft; Stichproben menschlicher Bewertung statt nur automatisierter Metriken; Tracking von Faithfulness und Context Precision über die Zeit, nicht nur zum Launch.

Typische Fehlerklassen entlang der Pipeline

In der Indexierungsphase: ungünstige Chunkgrenzen, die Tabellen, Listen oder Code zerreißen; nicht aktualisierte Dokumente; Embeddings, die für die Domäne ungeeignet sind. Im Retrieval: Document-Level Retrieval Mismatch, wenn das System aus einem großen Dokument zwar einen Chunk holt, aber nicht den relevanten; fehlende BM25-Komponente bei sehr token-genauen Anfragen wie Produktcodes. In der Augmentation: zu viele Chunks im Prompt, sodass das Modell den Bezug verliert; fehlende Quellen-Metadaten, die Zitate unmöglich machen. In der Generierung: das Modell antwortet trotz Kontext aus dem eigenen Wissen — eine RAG-Halluzination, die nur durch Faithfulness-Messung sichtbar wird.

Wie man misst, ob ein RAG-System funktioniert

Ein verbreitetes Bewertungsframework ist RAGAS. Die vier am häufigsten verwendeten Kerndimensionen beantworten jeweils eine andere Frage.

Faithfulness prüft, ob die generierte Antwort in den abgerufenen Dokumenten verankert ist und nicht halluziniert wurde. Das ist die zentrale Metrik, um RAG-spezifische Halluzinationen sichtbar zu machen.

Answer Relevancy prüft, ob die Antwort die gestellte Frage beantwortet — eine faithful Antwort kann am Thema vorbeigehen.

Context Precision prüft, ob die abgerufenen Chunks relevant für die Frage sind. Niedrige Werte deuten auf Retrieval-Probleme.

Context Recall prüft, ob alle für eine vollständige Antwort nötigen Informationen abgerufen wurden. Niedrige Werte deuten auf Lücken im Index oder zu enges Retrieval.

Faithfulness und Context Precision zielen auf den Retriever und die Bindung der Antwort an die Quellen. Answer Relevancy und Context Recall zielen auf die Vollständigkeit. RAGAS hat sein Metrik-Set inzwischen erweitert (etwa um Noise Sensitivity und Response Groundedness); die vier Kerngrößen bleiben aber der pragmatische Einstieg. Ergänzend kommen Werkzeuge wie TruLens für Traceability, DeepEval für unit-test-artige Prüfungen und Arize Phoenix für Observability zum Einsatz. Eine formale ISO-Norm für RAG-Evaluation existiert nicht; etabliert sind aufgabenspezifische Benchmarks wie KILT, MS MARCO, FinanceBench und Legalbench-RAG.

RAG im B2B- und Industriekontext — DSGVO, On-Prem und konkrete Anwendungsfelder

Im DACH-Industrieumfeld kommt RAG vor allem deshalb zum Einsatz, weil es das Wissen vom Modell trennt — eine architektonische Eigenschaft mit unmittelbaren Folgen für Datenschutz und Betrieb.

Typische Anwendungsfelder in Industrie und B2B

Das Mittelstand-Digital Zentrum Fokus Mensch beschreibt Anwendungen in Branchen wie Maschinenbau, Elektrotechnik und Logistik.

Dort verknüpft RAG Sprachmodelle mit internen und externen Datenquellen für Echtzeit-Informationen. Lufthansa Industry Solutions nennt als typische Felder internes Wissensmanagement zu Prozessdokumentation, Mitarbeiterhandbücher und Wartungsanleitungen sowie B2B- und B2C-Chatbots.

Dokumentierte Beispiele aus produktiven Systemen:

• Grainger (B2B-MRO-Distribution): RAG-basiertes Suchsystem auf Databricks Mosaic AI für 2,5 Mio. Produkte mit rund 400.000 täglichen Produktupdates. Hintergrund: unterschiedliche Buyer-Personas (etwa Elektriker vs. Maschinenbauer) erwarten bei einer Anfrage wie „Klemmen“ branchenspezifisch unterschiedliche Treffer.
• Ramp nutzt RAG zur Industrieklassifizierung nach NAICS-Codes: Kundeninformationen werden vektorisiert, gegen eine Datenbank von Codes verglichen, ein LLM erzeugt die finale Klassifikation.
• Thomson Reuters setzt RAG ein, um Support-Mitarbeitern relevante Inhalte aus internen Wissensbasen über eine Chat-Oberfläche bereitzustellen.
• Der BVDW hat das Muster mit einem eigenen Whitepaper für den DACH-Markt aufgegriffen („Retrieval-Augmented Generation: Wissen gezielt nutzen, Antworten präzise generieren“).

DSGVO, Datenresidenz und On-Prem-Betrieb

Bei RAG bleibt vertrauliches Material außerhalb der Modellgewichte: Wissen wird aus kontrollierten Repositories abgerufen, nicht ins Modell eingebettet. Das senkt das Leak-Risiko gegenüber Fine-Tuning, bei dem Trainingsinhalte über die Gewichte rekonstruierbar werden können. Für die DACH-Industrie folgen daraus drei Architekturentscheidungen, die früh fallen müssen: Wo liegt die Vektordatenbank (eigene Infrastruktur, EU-Cloud, US-Cloud)? Welcher Generator wird genutzt (Cloud-API, EU-gehostetes Modell, lokales Open-Weight-Modell)? Welche Quellen-Metadaten werden mitgespeichert, damit Audit und Löschanfragen umsetzbar sind? Die Trennung von Wissen und Modell macht RAG zur architektonisch einfacheren Lösung für Datenresidenz-Anforderungen — sie ersetzt aber keine saubere Datenklassifizierung im Vorfeld.

FAQ