RAG (Retrieval-Augmented Generation)

Was macht RAG anders als ein reines Sprachmodell?

Ein Large Language Model erzeugt Text auf Basis statistischer Muster, die es während des Trainings gelernt hat, sowie auf Basis des aktuellen Eingabekontexts. Für unternehmensspezifische Fragen reicht das häufig nicht aus: interne Richtlinien, Produktdokumentationen, Verträge, Prozessbeschreibungen oder aktuelle Wissensstände waren entweder nie Bestandteil des Trainings oder haben sich seitdem verändert.

RAG ergänzt deshalb einen Retrieval-Schritt. Bevor die Antwort erzeugt wird, sucht das System in einer angebundenen Wissensbasis nach passenden Inhalten. Erst danach erhält das Sprachmodell die Frage zusammen mit den gefundenen Textstellen. Das ursprüngliche RAG-Paper von Lewis et al. beschreibt diese Verbindung als Kombination aus parametrischem Wissen im Modell und nicht-parametrischem Wissen in einer externen Sammlung.

Fachliche Grundlage: Woher stammt RAG?

Lewis et al. stellten 2020 auf der NeurIPS den Ansatz „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks“ vor. In der dort untersuchten Architektur wird ein generatives Modell mit einem dichten Vektorindex von Wikipedia und einem neuronalen Retriever kombiniert. Die Autoren zeigten für mehrere wissensintensive Aufgaben Vorteile gegenüber rein parametrischen Baselines.

Wichtig ist die Einordnung: Das Paper definiert nicht jede heutige Unternehmensarchitektur, die als „RAG“ bezeichnet wird. In der Praxis existieren zahlreiche Varianten mit unterschiedlichen Embedding-Modellen, Suchverfahren, Re-Ranking, Metadatenfiltern, Datenbanken und Prompt-Strategien. Der Kern bleibt jedoch: relevantes externes Wissen wird zur Laufzeit abgerufen und in die Generierung einbezogen.

Wie läuft ein RAG-System typischerweise ab?

1. Dokumente aufbereiten: Quellen werden extrahiert, bereinigt und häufig in kleinere Einheiten – sogenannte Chunks – zerlegt.
2. Repräsentation erzeugen: Textabschnitte können beispielsweise als Embeddings dargestellt und in einem geeigneten Index gespeichert werden.
3. Frage verarbeiten: Die Nutzeranfrage wird analysiert und als Suchanfrage verwendet.
4. Retrieval: Das System sucht nach fachlich passenden Textstellen. Das kann dense, sparse oder hybrid erfolgen.
5. Optionales Re-Ranking: Kandidaten werden nochmals genauer sortiert, bevor sie in den Kontext gelangen.
6. Generierung: Das LLM erhält Frage, Instruktionen und ausgewählte Quellen und formuliert daraus eine Antwort.
7. Nachweis: Gute Anwendungen zeigen dem Nutzer, auf welchen Dokumenten oder Textstellen die Antwort beruht.

Warum Chunking und Retrieval-Qualität entscheidend sind

RAG ist nicht automatisch gut, nur weil eine Vektordatenbank angebunden wurde. Die Qualität hängt stark davon ab, welche Informationen das System überhaupt findet. Chen et al. zeigten 2024, dass die Granularität der Retrieval-Einheiten die Retrieval- und Downstream-Leistung deutlich beeinflussen kann. Zu große Chunks können viel irrelevanten Kontext enthalten; zu kleine Einheiten verlieren möglicherweise den fachlichen Zusammenhang.

Auch ein sehr großes Kontextfenster löst das Problem nicht automatisch. Liu et al. untersuchten, wie Sprachmodelle Informationen in langen Kontexten nutzen, und fanden Positionsabhängigkeiten: Relevante Informationen werden nicht in jeder Position gleich zuverlässig verwendet. Das spricht dafür, Retrieval nicht lediglich als „Dokumente irgendwo in den Prompt legen“ zu verstehen.

Wann ist RAG für Unternehmen sinnvoll?

RAG ist besonders interessant, wenn Antworten auf einer klar abgegrenzten, pflegbaren Wissensbasis beruhen sollen. Typische Einsatzfelder sind:

• interne Wissensassistenten für Richtlinien, Prozesse oder Dokumentationen,
• Support-Systeme mit Produkt- und Servicewissen,
• Recherche in technischen Dokumenten, Handbüchern oder Projektdaten,
• Frage-Antwort-Funktionen in Kunden- oder Mitarbeiterportalen,
• KI-Funktionen innerhalb individueller Geschäftsanwendungen.

Der Vorteil ist nicht, dass das Modell „alles weiß“, sondern dass die Wissensbasis kontrollierter aktualisiert werden kann als ein Modelltraining. Neue oder geänderte Dokumente können in die Retrieval-Pipeline aufgenommen werden, ohne das Basismodell neu zu trainieren.

Was RAG nicht garantiert

RAG beseitigt Halluzinationen nicht grundsätzlich. Ein System kann falsche Quellen abrufen, relevante Dokumente übersehen, Inhalte missinterpretieren oder trotz guter Quellen eine fehlerhafte Antwort formulieren. Außerdem können widersprüchliche, veraltete oder schlecht gepflegte Ausgangsdaten die Antwortqualität unmittelbar verschlechtern.

Für geschäftskritische Anwendungen gehören deshalb neben Retrieval-Metriken auch fachliche Evaluation, Rechte- und Rollenkonzepte, Quellenanzeige, Logging sowie klare Regeln für Unsicherheit und Eskalation zum Systemdesign.

RAG, Fine-Tuning und lange Kontextfenster sind unterschiedliche Werkzeuge

RAG wird häufig mit Fine-Tuning verwechselt. Fine-Tuning verändert Modellparameter, etwa um Verhalten, Stil oder aufgabenspezifische Muster anzupassen. RAG ergänzt dagegen zur Laufzeit externes Wissen. Beide Ansätze können kombiniert werden. Auch lange Kontextfenster sind kein direkter Ersatz: Sie ermöglichen mehr Eingabetext, beantworten aber nicht automatisch die Frage, welche Informationen für eine konkrete Anfrage relevant sind.

Praxisbeispiel

Ein Maschinenbauunternehmen besitzt mehrere hundert Serviceanleitungen. Mitarbeitende suchen bislang manuell nach Fehlercodes. Ein RAG-System könnte die Dokumente aufbereiten, bei einer Anfrage passende Abschnitte abrufen und eine Antwort mit Quellenverweisen erzeugen. Entscheidend wäre dabei nicht nur das LLM, sondern ebenso Dokumentqualität, Chunking, Metadaten, Retrieval und eine Evaluation mit realen Servicefragen.

Fazit

RAG ist eine Architekturidee für KI-Anwendungen, die generative Modelle mit gezielt abrufbarem Wissen verbindet. Der Nutzen entsteht nicht durch das Schlagwort selbst, sondern durch eine belastbare Wissensbasis und eine Retrieval-Pipeline, die nachweisbar die richtigen Informationen findet. Für Unternehmen ist RAG besonders dann interessant, wenn internes oder aktuelles Wissen kontrolliert in KI-Funktionen einfließen soll.