Retrieval-Augmented Generation (RAG)

Begriff und Einordnung

Retrieval-Augmented Generation, kurz RAG, verbindet ein Sprachmodell mit einer externen Wissensbasis. Das System sucht zuerst passende Textstellen, Policies, Produktinformationen oder interne Dokumente und lässt das Sprachmodell danach auf dieser Basis antworten (Niessner 2026).

Die einfache Analogie lautet Open-Book-Prüfung. Das Modell soll nicht nur aus seinem gelernten Allgemeinwissen antworten, sondern vor der Antwort in bereitgestellten Unterlagen nachschauen. Für Unternehmen ist das wichtig, weil allgemeine Modelle interne Prozesse, Preise, Richtlinien und Produktdetails nicht kennen (Niessner 2026).

Abbildung: RAG verbindet eine Frage mit einer Wissensdatenbank und lässt das Sprachmodell danach eine Antwort mit bereitgestelltem Kontext formulieren. Für Unternehmen ist das der Grundmechanismus, um interne Dokumente in KI-Antworten einzubeziehen. Quelle: eigene Darstellung nach Niessner 2026.

Funktionsweise in Grundzügen

In der Vorbereitungsphase zerlegt das Unternehmen Dokumente in Chunks, also Textschnipsel, wandelt diese in Embeddings um und speichert sie in einer Vektordatenbank. In der Abfragephase wird auch die Nutzerfrage vektorisiert; die Datenbank liefert semantisch ähnliche Chunks zurück; diese Chunks landen als Kontext im Prompt des Sprachmodells (Niessner 2026).

Chunk-Größe, Überlappung und Anzahl der zurückgelieferten Treffer entscheiden über die Antwortqualität. Zu große Chunks bringen Rauschen, zu kleine Chunks verlieren Zusammenhang, zu wenige Treffer lassen wichtige Informationen aus, und zu viele Treffer sprengen das Kontextfenster oder verwässern die Antwort (Niessner 2026).

Eine robuste RAG-Pipeline endet deshalb nicht bei „Dokumente in eine Vektordatenbank laden“. Sie braucht vier sauber getrennte Qualitätsbereiche: Ingestion mit sinnvollen Datenquellen, semantischem Chunking und Metadaten; Indexing mit passenden Embeddings und Vektordatenbank; Retrieval mit Query Rewriting, hybrider Suche und Reranking; sowie Generation und Evaluation mit Kontextauswahl, grounded answer und Messung von Faktentreue, Latenz, Kosten und Zitaten (Gohel 2026).

Abbildung: Eine RAG-Pipeline braucht Qualitätskontrollen von der Dokumentenaufnahme über Index und Retrieval bis zur Antwort-Evaluation. Für Unternehmen ist entscheidend, ob Quellen, Kontextauswahl und Messgrößen vor dem Go-live nachvollziehbar sind. Quelle: eigene Darstellung nach Gohel 2026.

RAG verändert das Sprachmodell nicht. Das Unternehmen trainiert damit keine neuen Gewichte, sondern gibt dem Modell bei jeder Anfrage passende Informationen mit. Deshalb eignet sich RAG für Wissen, das sich ändert: Preislisten, Policies, Produktkataloge, Prozesshandbücher oder interne Wissensdatenbanken (Niessner 2026).

Abbildung: Die Pipeline trennt Indexierung und Abfrage. Dokumente werden vorab aufbereitet, vektorisiert und gespeichert; bei einer Anfrage ruft das System passende Inhalte ab und lässt daraus eine Antwort generieren. Quelle: eigene Darstellung nach Niessner 2026.

Bedeutung für Unternehmen

RAG ist kein Ersatz für Datenqualität, Governance oder fachliche Verantwortung. Schlechte PDFs, Scans ohne Texterkennung, zerrissene Tabellen, veraltete Dokumente und unklare Zuständigkeiten erzeugen schlechte Antworten. Das System wirkt dann überzeugend, obwohl die Grundlage falsch oder unvollständig ist (Niessner 2026).

RAG reduziert Halluzinationen, beseitigt sie aber nicht. Fehler können beim Retrieval entstehen, wenn die falschen Chunks zurückkommen. Fehler können auch beim Generieren entstehen, wenn das Sprachmodell bereitgestellte Quellen falsch zusammenfasst oder trotz Anweisung eigenes Wissen einmischt (Niessner 2026).

Für Entscheider:innen liegt der wichtigste Prüfpunkt oft vor dem Modellaufruf. Vier stille Fehlerquellen können ein RAG-System unzuverlässig machen: Chunks werden nach technischer Größe statt nach Bedeutung geschnitten, Metadaten wie Titel, Autor, Tags oder Beziehungen fehlen, das Retrieval liefert zu viele statt relevante Treffer, und nach der Antwort misst niemand Faktentreue, Kosten, Latenz oder Quellenqualität. In solchen Fällen wirkt das Sprachmodell wie das Problem, obwohl die Pipeline den Fehler bereits vorher erzeugt hat (Gohel 2026).

Unternehmen sollten RAG nicht mit APIs verwechseln. RAG liefert Kontext aus unstrukturierten Texten. APIs liefern aktuelle, strukturierte Daten oder lösen Aktionen aus: Kundendaten abrufen, Preise berechnen, einen CRM-Datensatz schreiben oder eine Bestellung anlegen (Niessner 2026).

Typische Einsatzfälle

RAG passt, wenn Mitarbeitende oder Kund:innen Fragen zu umfangreichem, textlastigem Unternehmenswissen stellen: Richtlinien, Handbücher, Produktinformationen, Serviceprozesse, Schulungsunterlagen oder rechtliche Orientierungstexte. Es passt besonders dann, wenn Wissen häufig aktualisiert wird und nicht in das Modell selbst trainiert werden soll (Niessner 2026).

RAG passt weniger gut, wenn eine Antwort exakte Live-Daten oder Transaktionen braucht. Wer Lieferstatus, aktuellen Lagerstand, individuelle Preise oder Kundendaten benötigt, braucht APIs oder direkte Systemintegration. In vielen Business-Lösungen kombiniert man beides: RAG für Kontext, APIs für Wahrheit und Aktionen (Niessner 2026).

Bei agentischen KI-Anwendungen steigt die Bedeutung dieser Abgrenzung. Ein Agent, der auf schlechtes Retrieval zugreift, entscheidet oder handelt mit falschem Kontext. Vor produktivem Einsatz sollten Teams deshalb nicht nur das Modell testen, sondern die gesamte RAG-Kette mit realen Fragen, Negativbeispielen, Quellenprüfungen und Kostenmessung abnehmen (Gohel 2026).

Weitere technische Grundlagen finden Sie unter Sprachmodelle und generative KI und Training, Inferenz und Kontextfenster. Die Kontextfenster-Seite zeigt außerdem die größere Kontextpipeline vor einer LLM-Antwort: Anfrage verstehen, Kontext beschaffen, Inhalte auswählen und erst dann an das Modell übergeben (Niessner 2026).