Retrieval-Augmented Generation, meist zu RAG abgekürzt, verbindet eine Suche mit einem Sprachmodell: Bevor das Modell antwortet, holt ein Suchschritt passende Textstellen aus einer eigenen Wissensbasis und legt sie als Kontext vor. Die Antwort entsteht dann aus diesen Fundstellen und nicht allein aus dem, was beim Training hängen geblieben ist. Der Begriff stammt aus einer Forschungsarbeit von 2020 und beschreibt heute die übliche Bauform für alles, was ein Large Language Model mit firmeneigenen Inhalten verbinden soll.
Der praktische Reiz liegt darin, dass sich das Wissen ändern lässt, ohne das Modell anzufassen. Neues Dokument rein, Index aktualisiert, fertig.
Warum ein Modell allein nicht reicht
Ein Sprachmodell kennt nur, was in seinen Trainingsdaten stand. Daraus folgen drei Lücken:
- Stichtag: Alles nach dem Trainingsende fehlt. Preise, Personalstand, der letzte Woche geänderte Prozess.
- Interne Inhalte: Handbücher, Verträge, Tickets, Wiki-Seiten. Nichts davon war je öffentlich.
- Belegbarkeit: Ein Modell kann nicht sagen, woher eine Aussage stammt. Es hat keine Quellen, es hat Gewichte.
Fehlt der Bezug, füllt das Modell die Lücke mit einer plausibel klingenden Formulierung. Genau das ist eine KI-Halluzination, und sie ist der Hauptgrund, warum reine Chatmodelle in der Sachbearbeitung so wenig taugen.
Wie eine RAG-Anwendung aufgebaut ist
Es sind zwei Abläufe, die zeitlich getrennt voneinander laufen.
Das Wissen vorbereiten
Dokumente einsammeln, in Textstücke zerlegen (Chunking), zu jedem Stück einen Vektor berechnen (Embedding) und beides in eine Datenbank schreiben. Dazu gehören Metadaten: Quelle, Datum, Version, wer das lesen darf. Dieser Schritt läuft im Hintergrund und wird bei jeder Änderung an den Quelldokumenten wiederholt.
Die Anfrage beantworten
- Frage entgegennehmen und bei Bedarf umformulieren, etwa Pronomen aus dem Gesprächsverlauf auflösen.
- Kandidaten suchen: über Vektorähnlichkeit, über klassische Stichwortsuche oder über beides zusammen.
- Die Treffer neu sortieren (Reranking) und nur die besten behalten.
- Frage und Fundstellen als Prompt an das Modell geben, mit der Anweisung, ausschließlich daraus zu antworten und die Quelle zu nennen.
- Antwort mit Belegen ausliefern.
| Baustein | Aufgabe | Typische Umsetzung |
|---|---|---|
| Chunking | Dokumente in abfragbare Stücke schneiden | entlang von Überschriften und Absätzen, mit Überlappung |
| Embedding-Modell | Text in Vektoren übersetzen | API-Modell oder Open-Source-LLM, passend zur Sprache gewählt |
| Vektorspeicher | Ähnlichkeitssuche über Millionen Stücke | pgvector, Qdrant, Weaviate, Elasticsearch |
| Retriever | Kandidaten finden | hybrid aus Vektor- und Stichwortsuche |
| Reranker | Kandidaten nach echter Relevanz ordnen | Cross-Encoder-Modell |
| Generator | Antwort formulieren | das Sprachmodell mit striktem System-Prompt |
Der letzte Punkt ist der, über den am meisten geredet und am wenigsten entschieden wird. Die Qualität einer RAG-Anwendung hängt fast immer am Abruf, nicht am Modell.
RAG, Fine-Tuning oder einfach ein großes Kontextfenster
Die drei Ansätze lösen unterschiedliche Probleme und schließen sich nicht aus.
| Ansatz | Wofür er taugt | Wofür nicht |
|---|---|---|
| RAG | aktuelles Wissen, Quellenangaben, Zugriffsrechte pro Nutzer | Tonfall, Ausgabeformat, Aufgabenverständnis |
| Fine-Tuning | Stil, Format, wiederkehrende Aufgabenmuster | frische Fakten, denn jede Änderung bedeutet neu trainieren |
| Großes Kontextfenster | einmalige Fragen an eine Handvoll bekannter Dokumente | Bestände jenseits des Fensters, und die Kosten je Anfrage |
Der dritte Punkt wird gern unterschätzt. Alles, was im Kontext landet, wird bei jeder einzelnen Anfrage bezahlt und verarbeitet, siehe KI-Token. Ein gezielter Abruf von fünf Textstellen ist billiger und meistens auch genauer als das Hineinkippen des kompletten Handbuchs.
Wo RAG in der Praxis scheitert
Ein Prototyp steht an einem Nachmittag. Der Abstand zwischen diesem Prototyp und etwas, das die Fachabteilung wirklich benutzt, ist der eigentliche Teil des Projekts.
Falsch geschnittene Dokumente
Wird stur nach Zeichenzahl geschnitten, zerfällt eine Tabelle in Bruchstücke und eine Bedingung wird von ihrer Ausnahme getrennt. Das Modell antwortet dann korrekt auf Basis eines halben Satzes. Struktur schlägt Zeichenzahl: an Überschriften schneiden, den Abschnittstitel in jedes Stück mitschreiben.
Fragen, die kein Dokument beantwortet
Wenn die Wissensbasis die Antwort nicht enthält, liefert der Abruf trotzdem die fünf ähnlichsten Stücke. Ohne ausdrückliche Erlaubnis, nichts zu wissen, baut das Modell daraus eine Antwort. Ein sauberer Schwellenwert und ein erlaubtes “steht hier nicht” sind wichtiger als jede Prompt-Feinschliffrunde.
Berechtigungen
Der Index kennt keine Rollen, wenn man sie ihm nicht beibringt. Wer Personalakten und Wiki in denselben Speicher legt, hat eine Suchmaschine gebaut, die jede Rechtevergabe im Quellsystem aushebelt. Rechte gehören als Filter in die Abfrage, nicht in den Prompt.
Veralteter Index
Ein Dokument wird geändert, der Index nicht. Ab da antwortet das System selbstbewusst mit dem Stand von vorgestern. Der Abgleich braucht einen festen Takt und eine sichtbare Anzeige, wie alt der Bestand ist.
Was eine RAG-Anwendung produktionsreif macht
- Belege in jeder Antwort. Ohne Link auf die Quelle kann niemand prüfen, ob die Antwort stimmt.
- Ein Testsatz mit echten Fragen. Fünfzig Fragen aus dem Support-Postfach mit bekannter richtiger Antwort sagen mehr über die Qualität aus als jedes Gefühl beim Ausprobieren.
- Getrennte Messung von Abruf und Antwort. Kam die richtige Stelle überhaupt in den Kontext? Wenn nein, hilft ein besseres Modell nicht.
- Schutz vor manipulierten Quellen. Wer Dokumente aus dem Netz oder von Nutzern indexiert, muss mit Prompt Injection rechnen, denn abgerufener Text landet im selben Prompt wie die Anweisung.
- Protokolle. Welche Frage, welche Fundstellen, welche Antwort. Ohne das ist ein Fehlverhalten nicht rekonstruierbar.
Häufige Fragen zu Retrieval-Augmented Generation
Brauche ich dafür eine Vektordatenbank? Nicht zwingend. Bei überschaubaren Beständen reicht eine vorhandene Datenbank mit Vektorerweiterung, etwa PostgreSQL mit pgvector, und oft schlägt eine gute Stichwortsuche die reine Vektorsuche sogar. Interessant wird spezialisierte Software erst bei sehr großen Beständen oder hoher Abfragelast.
Bleiben unsere Daten dabei im Haus? Das hängt allein davon ab, wo Embedding-Modell und Sprachmodell laufen. Bei einem API-Anbieter verlassen die abgerufenen Textstellen das Haus, und zwar bei jeder Anfrage. Wer das nicht will, betreibt beides selbst, was möglich, aber teurer und langsamer ist. Diese Frage gehört an den Anfang des Projekts.
Verhindert RAG Halluzinationen? Es senkt sie deutlich, weil das Modell aus vorgelegtem Text arbeitet statt aus Erinnerung. Es beseitigt sie nicht: Bei widersprüchlichen Fundstellen, bei Fragen ohne Beleg im Bestand und beim Zusammenfassen mehrerer Stellen entstehen weiterhin falsche Aussagen. Deshalb die Quellenangabe.
Wie aufwendig ist der Einstieg? Ein Durchstich mit einer Handvoll Dokumente ist schnell gebaut. Der Aufwand steckt in den Formaten (gescannte PDFs, Tabellen, Präsentationen), in den Rechten und im Betrieb des Index. Als Faustregel: Die Datenaufbereitung ist das Projekt, das Modell ist eine Zeile Konfiguration.
Fazit
RAG ist die unspektakulärste und zugleich tragfähigste Art, ein Sprachmodell an eigenes Wissen zu binden. Der Gewinn kommt nicht aus dem Modell, sondern aus sauber aufbereiteten Dokumenten, einem guten Abruf und der Disziplin, jede Antwort belegbar zu machen. Wer das ernst nimmt, bekommt ein System, dessen Fehler man sieht statt sie zu suchen. Wie wir Software rund um solche Anforderungen bauen, steht auf unserer Seite zur Custom-Software-Entwicklung, und was aus unserer Projektpraxis mit KI wirklich funktioniert, haben wir im Artikel KI in der Softwareentwicklung aufgeschrieben. Ein fertiges Produkt auf dieser Grundlage, vom Dokumentenbestand bis zur Quellenangabe unter der Antwort, beschreibt unsere Seite zur KI-Chatbot-Entwicklung. Für alles Weitere gibt es das unverbindliche Beratungsgespräch.