RAG ohne Buzzwords: Wie Modelle in fremdem Wissen nachschlagen

Die Antwort klingt sicher. Die Richtlinie ist trotzdem falsch

Ein Beispiel: Eine Mitarbeiterin fragt einen internen Assistenten, welche Unterlagen für eine Freigabe nötig sind. Das System antwortet flüssig, nennt plausible Schritte und übersieht die Richtlinie, die erst kürzlich geändert wurde. Das Dokument liegt im Unternehmensspeicher. Im Sprachmodell selbst ist die neue Fassung jedoch nicht enthalten.

Hier setzt Retrieval-Augmented Generation, kurz RAG, an. Der sperrige Name beschreibt eine nüchterne Idee: Bevor das Modell formuliert, sucht ein vorgeschaltetes System nach passenden Informationen. Die gefundenen Textstellen werden zusammen mit der Frage in den Arbeitskontext des Modells gelegt. Erst dann entsteht die Antwort.

Das zusätzliche Wissen steckt also nicht dauerhaft in den Modellgewichten. Es kann aus Handbüchern, Produktdaten, redaktionellen Regeln, Verträgen oder anderen freigegebenen Beständen stammen. Für jede Anfrage wird daraus ein möglichst relevanter Ausschnitt ausgewählt.

RAG ist weniger ein neues Gedächtnis als eine organisierte Form des Nachschlagens. Damit verschiebt sich die entscheidende Frage. Nicht nur das Formulieren muss funktionieren. Das System muss zuerst die richtige Stelle finden.

Vor der ersten Frage wird das Wissen zerlegt

Eine RAG-Pipeline beginnt lange vor der ersten Antwort. Dokumente müssen ausgelesen, bereinigt und für die Suche vorbereitet werden. In der Praxis stammen sie häufig aus PDF-Dateien, Webseiten, Tabellen, Präsentationen oder exportierten Handbüchern. Scans benötigen zusätzlich eine Texterkennung.

Der extrahierte Inhalt wird in kleinere Abschnitte zerlegt, meist Chunks genannt. Ihre Größe beeinflusst die spätere Suche. Ein zu kurzer Ausschnitt kann eine Einschränkung vom zugehörigen Satz trennen. Ein zu langer Abschnitt enthält zwar die gesuchte Aussage, bringt aber möglicherweise mehrere irrelevante Themen mit. Überschriften, Kapitelgrenzen und Dokumenttypen sind deshalb oft bessere Trennlinien als eine rein mechanische Teilung nach Zeichenlänge.

Zu jedem Abschnitt gehören außerdem Metadaten: etwa Quelle, Titel, Sprache, Dokumenttyp, Version, Gültigkeitszeitraum oder Zugriffsbereich. Sie helfen dabei, Treffer einzugrenzen und eine veraltete Fassung nicht mit einer aktuellen Regel gleichzusetzen.

Für die semantische Suche kann jeder Abschnitt in ein Embedding umgewandelt werden. Dabei bildet ein Modell den Text als Zahlenvektor ab. Inhaltlich verwandte Passagen können im entstehenden Vektorraum nahe beieinanderliegen, obwohl sie unterschiedliche Wörter verwenden. Das ist eine mathematische Repräsentation sprachlicher Muster, kein menschliches Verständnis des Dokuments.

Ob der Bestand in einer Wissensdatenbank, einem Suchindex oder mehreren spezialisierten Systemen liegt, ist eine Architekturfrage. Entscheidend ist, dass Text, Metadaten und Herkunft zusammenbleiben. Ein Treffer ohne verlässlichen Quellenpfad ist später nur schwer zu prüfen.

Was bei einer einzelnen Anfrage geschieht

Bei jeder Frage läuft die Such- und Antwortstrecke erneut an. Ein typischer Ablauf sieht so aus:

1. Die Anfrage wird für die Suche aufbereitet.
2. Die Suchkomponente ermittelt passende Abschnitte, gegebenenfalls unter Berücksichtigung von Metadaten und Zugriffsrechten.
3. Ein weiteres Ranking kann die Kandidaten im Verhältnis zur konkreten Frage neu sortieren.
4. Die ausgewählten Passagen gelangen mit ihren Quellenangaben in den Modellkontext.
5. Das Sprachmodell formuliert daraus eine Antwort nach den vorgegebenen Regeln.

Bei der Vektorsuche wird auch die Anfrage als Vektor dargestellt. Das System sucht anschließend nach nahe gelegenen Dokumentvektoren. Diese Nähe ist ein Signal für mögliche Relevanz, aber kein Wahrheitsbeweis.

Embeddings sind zudem nicht für jede Frage die beste Suchmethode. Produktcodes, Eigennamen und exakte Formulierungen lassen sich mit klassischer Schlagwortsuche oft zuverlässiger finden. Viele Systeme kombinieren deshalb semantische und wortgetreue Suche. Diese hybride Suche ist kein technischer Kompromiss, sondern eine Reaktion auf unterschiedliche Arten von Fragen.

Der Vorgang verändert das Grundmodell nicht. Das gefundene Wissen wird für die konkrete Antwort bereitgestellt, aber nicht automatisch in die Modellgewichte geschrieben. Ob Anfragen und Treffer anschließend protokolliert oder gespeichert werden, hängt von der jeweiligen Anwendung ab.

Der schönste Satz rettet keinen falschen Treffer

Die sichtbare Antwort lenkt leicht vom wichtigsten Bauteil ab: dem Retrieval. Ein leistungsfähiges Sprachmodell kann einen schwachen Treffer elegant ausformulieren. Eine Passage, die nie in den Kontext gelangt ist, kann es jedoch weder auswerten noch korrekt belegen.

Ein Beispiel: Eine technische Dokumentation verwendet den Begriff Zwei-Faktor-Authentifizierung, während die Frage von einer Anmeldung mit Sicherheitscode spricht. Eine reine Wortsuche kann die Verbindung übersehen. Semantische Suche findet möglicherweise die inhaltliche Nähe. Geht es dagegen um eine exakte Artikelnummer, ist die wortgetreue Suche meist das stärkere Signal.

Auch die Dokumentaufbereitung wirkt bis in die Antwort hinein. Tabellen können beim Auslesen ihre Zuordnung verlieren. Kopfzeilen tauchen plötzlich in jedem Abschnitt auf. Bei einem Scan kann die Texterkennung einzelne Zeichen verwechseln. Was am Ende wie ein Modellfehler aussieht, ist dann bereits beim Import entstanden.

Eine Vektordatenbank allein macht deshalb noch kein gutes RAG. Je nach Anfrage können Metadatenfilter, Schlagwortindizes, strukturierte Datenbanken oder direkte Schnittstellen die verlässlichere Quelle sein. Die eigentliche Leistung besteht darin, eine Frage an den passenden Wissensweg zu führen.

Quellen im Kontext sind noch keine Wahrheit

RAG wird häufig als Gegenmittel gegen erfundene Antworten beschrieben. Das greift zu kurz. Gute Quellen können unbelegte Aussagen reduzieren und die Prüfung erleichtern. Eine Garantie liefern sie nicht.

• Fehlende Information: Enthält der Bestand keine tragfähige Antwort, kann das Modell trotzdem versuchen, die Lücke plausibel zu füllen.
• Widersprüchliche Fassungen: Nennen zwei Dokumente unterschiedliche Regeln, braucht das System eine erkennbare Versionierung oder muss den Konflikt offenlegen.
• Unpassende Zugriffsrechte: Berechtigungen müssen greifen, bevor eine Passage in den Modellkontext gelangt.
• Manipulierte Inhalte: Ein gefundenes Dokument kann eingebettete Anweisungen enthalten. Solche Inhalte sind als Daten zu behandeln, nicht als automatisch vertrauenswürdiger Arbeitsauftrag.

Ein weiterer Fehler ist weniger sichtbar: Das System findet die richtige Passage, zieht daraus aber eine falsche Schlussfolgerung. Auch Quellenangaben helfen nur, wenn sie auf die tatsächlich verwendete Stelle führen. Eine dekorative Literaturliste hinter einer frei formulierten Antwort erzeugt lediglich den Anschein von Belegbarkeit.

Ein belastbares System muss deshalb nicht nur antworten, sondern auch ablehnen können. Hinweise wie „keine ausreichende Quelle gefunden“ oder „die Dokumente widersprechen sich“ sind kein technisches Versagen. Sie zeigen, dass die Grenze des verfügbaren Wissens erkannt wurde.

Wo RAG passt – und wo eine Abfrage besser ist

RAG eignet sich besonders für Wissen, das sich verändert, klar begrenzen lässt und in überprüfbaren Quellen vorliegt. Dazu zählen beispielsweise interne Anleitungen, freigegebene Produktinformationen, redaktionelle Vorgaben oder technische Dokumentationen. Der Nutzen entsteht dort, wo eine Antwort nicht nur plausibel, sondern auf einen aktuellen Bestand zurückführbar sein soll.

Andere Aufgaben verlangen andere Werkzeuge. Soll ein Modell einen bestimmten Ton oder ein wiederkehrendes Ausgabeformat beherrschen, können klare Anweisungen oder eine Modellanpassung geeigneter sein. Geht es um einen exakten Lagerbestand oder einen aktuellen Transaktionsstatus, sollte das System die dafür verantwortliche Datenbank oder Schnittstelle abfragen. Freitext-Retrieval ist kein Ersatz für eine verbindliche strukturierte Abfrage.

RAG und Fine-Tuning schließen sich nicht aus, erfüllen aber unterschiedliche Aufgaben. Eine Modellanpassung beeinflusst eher Verhalten und Form. Retrieval liefert veränderliches Wissen für den jeweiligen Moment. Wer beides verwechselt, trainiert womöglich ein Modell neu, obwohl eigentlich nur der Dokumentenbestand aktualisiert werden müsste.

Eine Demo prüft die Antwort. Ein Test prüft die Kette

Eine Vorführung wirkt schnell überzeugend, wenn die Frage fast genauso formuliert ist wie der Ausgangstext. Die härtere Prüfung beginnt mit echten Sprachvarianten, unvollständigen Fragen, widersprüchlichen Dokumenten und Fällen, in denen keine Antwort vorhanden ist.

Dafür braucht es einen kuratierten Satz typischer Anfragen. Zu jeder Frage wird festgehalten, welche Quelle die Antwort tragen sollte und wann das System besser ablehnt. Retrieval und Formulierung werden getrennt betrachtet: Wurde die richtige Passage gefunden? Ist die Aussage durch diese Passage gedeckt? Hat das System einen Konflikt sichtbar gemacht?

Ebenso wichtig ist der Weg zurück. Für eine ausgegebene Antwort sollten sich Quelle, Dokumentversion und verwendeter Ausschnitt nachvollziehen lassen. Ändert sich der Bestand, werden die relevanten Testfragen erneut geprüft. So wird aus einer eindrucksvollen Antwort ein belastbarer Arbeitsablauf.

Künftig zählt der Weg zurück

Die Qualität eines RAG-Systems zeigt sich nicht zuerst an seiner Eloquenz. Sie zeigt sich an der Strecke davor: Welcher Bestand wurde durchsucht? Warum wurde diese Passage ausgewählt? Welche Version galt? Was geschieht, wenn die Quellen schweigen?

Wer diese Fragen stellen kann, bewertet Sprachmodelle anders. Eine flüssige Antwort ist dann nicht mehr der Endpunkt. Entscheidend ist, ob sich ihr Weg bis zum Dokument zurückverfolgen lässt.

Das ist der konkrete Unterschied im Arbeitsalltag: Man prüft nicht länger nur, wie ein Modell spricht. Man erkennt, ob es tatsächlich nachgeschlagen hat.