RAG erklärt: wie deine Dokumente zu einem KI-Assistenten werden, der nicht danebenliegt.

Retrieval-Augmented Generation, kurz RAG, wird als die Antwort auf „wir wollen eine KI, die unsere Unternehmensdokumente kennt“ verkauft. Das stimmt ungefähr — aber der Unterschied zwischen einem wirklich nützlichen RAG-System und einem Chatbot, der gelegentlich deine eigene Richtlinie halluziniert, liegt vollständig in der Umsetzung.

Was RAG tatsächlich ist, ohne Fachjargon

Ein Sprachmodell für sich allein kennt nur, was es beim Training gesehen hat — es hat nie dein internes Wiki, deine Produktspezifikationen oder die Preisänderung vom letzten Monat gesehen. RAG überbrückt das in zwei Schritten: Zuerst durchsucht es deine tatsächlichen Dokumente nach den für die Frage relevanten Passagen, dann übergibt es diese Passagen zusammen mit der Frage an das Modell, sodass die Antwort aus deinem echten Content generiert wird — nicht aus den allgemeinen Trainingsdaten des Modells.

Das ist der zentrale Unterschied zum bloßen Einfügen von Dokumenten in ein Chat-Fenster: RAG sucht und ruft die passende Passage genau im Moment der Antwort ab, aus einer Quelle, die unabhängig vom Modell selbst aktualisiert werden kann.

Wie es auf praktischer Ebene funktioniert

Dokumente werden in Abschnitte zerlegt und in Embeddings umgewandelt — numerische Darstellungen, die es einem System erlauben, Passagen nach Bedeutung zu finden, nicht nur nach Stichwort-Treffer. Eine Frage kommt herein, das System ruft die relevantesten Abschnitte aus diesem Index ab, und das Modell generiert eine Antwort, die genau in diesen Abschnitten verankert ist, meist mit einer Quellenangabe zum Ursprungsdokument.

Die Qualität des gesamten Systems hängt am Retrieval-Schritt. Ein Modell, das aus irrelevantem oder schlecht zerlegtem Kontext antworten soll, produziert selbstbewusst eine falsche Antwort — genau hier scheitern die meisten schwachen RAG-Implementierungen tatsächlich, nicht am Sprachmodell selbst.

Es gibt einen zweiten, weniger offensichtlichen Fehler, der viele enttäuschende Ergebnisse erklärt: die Position. Die Studie „Lost in the Middle“ fand, dass Modelle am zuverlässigsten antworten, wenn die relevante Passage nahe am Anfang oder am Ende des übergebenen Kontexts steht, und messbar schlechter, wenn sie in der Mitte vergraben ist — selbst bei Modellen, die ausdrücklich für lange Kontexte gebaut sind. Das richtige Dokument abzurufen reicht nicht, wenn du es anschließend in vierzig Seiten „sicherheitshalber“-Kontext vergräbst. Weniger abzurufen und richtig zu sortieren schlägt regelmäßig das Abrufen in Menge.

Wo es für ein Unternehmen wirklich nützlich ist

Interne Wissensdatenbanken sind der klarste Fall: Support-Mitarbeitende, die Richtliniendokumente abfragen, Ingenieure, die technische Dokumentation durchsuchen, Vertriebsteams, die während eines Anrufs korrekte Produktspezifikationen abrufen. Kundensupport, der aus deiner tatsächlichen Dokumentation antworten muss — nicht aus generischem Wissen — ist ein weiterer starker Anwendungsfall, sofern die Antworten verankert bleiben und ihre Quelle zitieren.

Es eignet sich schlecht für alles, was über das Geschriebene hinausgehende Schlussfolgerungen oder Berechnungen erfordert, und schlecht für Daten, die sich schneller ändern, als der Index realistisch aktualisiert werden kann.

Was ein gutes RAG-System von einem schlechten unterscheidet

Dokumentenzerlegung, die die tatsächliche Struktur respektiert (nicht willkürliche Zeichenanzahlen), ein Retrieval-Schritt, der evaluiert und optimiert statt einfach als funktionierend angenommen wird, sichtbare Quellenangaben, damit ein Mensch die Antwort prüfen kann, und ein Prozess, um den Index aktuell zu halten, während sich Dokumente ändern. Auch Zugriffskontrolle zählt — ein RAG-System, das vertrauliche Dokumente dem falschen Publikum zeigt, ist ein reales Risiko, kein hypothetisches.

Die bislang wirksamste veröffentlichte Technik ist Contextual Retrieval: jedem Abschnitt vor dem Embedding eine kurze Beschreibung voranzustellen, wo er im übergeordneten Dokument steht. Anthropic hat dafür 49 % weniger fehlgeschlagene Retrievals gemessen, mit zusätzlichem Reranking 67 %. Es kostet einen einmaligen Vorverarbeitungslauf über deinen Bestand. Genau solche unglamourösen Details trennen ein System, dem Leute vertrauen, von einem, das sie still nicht mehr benutzen — und genau das bauen wir in ein Individuelles Text-KI-Modell ein, statt es den Standardeinstellungen zu überlassen.

Quellen

Der Mechanismus und die gemessenen Zahlen oben stammen aus diesen Primärquellen, geprüft im Juli 2026.

• Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv:2005.11401) ↗

  Die Arbeit von 2020, die RAG benannt hat. Kombiniert einen vortrainierten Generator mit einem dichten Vektorindex als nicht-parametrischem Gedächtnis und stellt fest, dass RAG-Modelle spezifischere, vielfältigere und faktentreuere Sprache erzeugen als eine rein parametrische Vergleichsbasis.

• Liu et al. — Lost in the Middle: How Language Models Use Long Contexts (arXiv:2307.03172) ↗

  Stellt fest, dass die Genauigkeit am höchsten ist, wenn die relevante Information am Anfang oder Ende des Kontexts steht, und in der Mitte deutlich abfällt — auch bei Modellen, die für lange Kontexte gebaut sind. Deshalb zählt die Rangfolge beim Retrieval mehr als die Kontextlänge.

• Anthropic — Introducing Contextual Retrieval ↗

  Gemessene Ergebnisse dafür, Chunks vor dem Embedding mit ihrem Dokumentkontext zu versehen: 49 % weniger fehlgeschlagene Retrievals, mit zusätzlichem Reranking 67 % weniger.