Was ist RAG? Retrieval-Augmented Generation für Unternehmen erklärt

Retrieval-Augmented Generation, allgemein zu RAG verkürzt, ist das am weitesten verbreitete Muster der künstlichen Intelligenz im Unternehmen. Nahezu jedes System, das Fragen zu den eigenen Dokumenten, Richtlinien, Produkten oder Vorgängen eines Hauses beantwortet, nutzt eine Spielart davon.

Die Idee ist unkompliziert, und sie gut zu verstehen entscheidet darüber, ob Menschen einem System vertrauen oder es stillschweigend aufgeben.

Das Problem, das RAG löst:

Ein Sprachmodell kennt nur, was in seinen Trainingsdaten stand, die zu einem festen Zeitpunkt endeten und Ihre internen Dokumente nie enthielten. Fragen Sie es nach Ihrer Rückgaberichtlinie, und es erzeugt etwas, das wie eine Rückgaberichtlinie klingt, aus Mustern erfunden statt aus Ihrer tatsächlichen Richtlinie geholt.

Sie könnten das Modell auf Ihren Dokumenten nachtrainieren, doch das ist teuer, langsam, muss bei jeder Änderung wiederholt werden und gibt immer noch keine Gewähr, dass das Modell den Text getreu wiedergibt.

RAG geht einen anderen Weg. Statt dem Modell Ihre Informationen beizubringen, suchen Sie im Moment der Frage die einschlägigen Passagen heraus und stellen sie direkt in seinen Kontext. Das Modell antwortet dann anhand von Text, den es wirklich sieht, statt anhand halb erinnerter Muster. Damit wird aus einem Erinnerungsproblem ein Leseverständnisproblem, und darin sind diese Modelle wirklich gut.

Wie das Retrieval arbeitet:

Das System hat zwei Phasen: die Vorbereitung, einmal erledigt und bei Änderungen aktualisiert, und das Abrufen, das bei jeder Frage geschieht.

In der Vorbereitung werden Dokumente in Abschnitte von einigen hundert Wörtern geteilt. Jeder Abschnitt läuft durch ein Embedding-Modell, das Text in eine Zahlenreihe verwandelt, einen Vektor, so gelegen, dass bedeutungsähnliche Passagen nahe beieinanderliegen. Diese Vektoren liegen in einer Datenbank, die auf das schnelle Finden nächster Nachbarn ausgelegt ist.

Zum Zeitpunkt der Frage wird diese auf dieselbe Weise eingebettet. Das System findet die ihr nächsten Abschnitte, nimmt die besten wenigen und baut eine Anweisung: Hier ist die Frage, hier sind die einschlägigen Passagen, antworte nur anhand dieses Materials und sage es, wenn die Antwort darin nicht steht.

Weil Bedeutung verglichen wird und nicht Stichwörter, kann eine Frage nach „freien Tagen" eine Richtlinie finden, die durchweg nur von „Jahresurlaub" spricht.

Warum hybride Suche meist gewinnt:

Rein semantische Suche hat eine vorhersehbare Schwäche: exakte Kennungen. Produktcodes, Fehlernummern, Rechnungsreferenzen und Nachnamen sind genau dort, wo bedeutungsbasierter Abgleich schwächelt, denn der Vektor für „SKU-88421" trägt kaum semantisches Signal.

Produktionssysteme fahren deshalb sowohl semantische als auch klassische Stichwortsuche und führen die Ergebnisse zusammen. Die Stichwortsuche trifft exakte Begriffe, die semantische fängt Umschreibungen. Die Kombination schlägt beständig jede der beiden allein, und die Fehlerfälle, die sie abdecken, ergänzen einander weitgehend.

Eine zweite Stufe, das Reranking, verbessert die Ergebnisse weiter. Eine billige Suche liefert etwa fünfzig Kandidatenabschnitte, dann bewertet ein langsameres, genaueres Modell diese fünfzig auf echte Einschlägigkeit und behält die besten fünf. Dieses zweistufige Vorgehen ist weit genauer, als gleich fünf abzurufen, und kostet wenig, weil das teure Modell stets nur eine Vorauswahl sieht.

Die Abschnittsbildung entscheidet mehr, als man denkt:

Wie Dokumente geteilt werden, wirkt überproportional auf die Qualität, und hier gehen die meisten enttäuschenden Systeme falsch.

Zu kleine Abschnitte verlieren den Zusammenhang: Eine Passage mit „dies gilt nicht für Auftragnehmer" ist gefährlich, wenn sie von dem getrennt ist, worauf „dies" verweist. Zu große Abschnitte verwässern die Bedeutung, sodass das Embedding einen vagen Durchschnitt mehrerer Themen abbildet und nichts genau trifft.

Nach Struktur zu teilen, nach Abschnitt und Überschrift statt nach fester Zeichenzahl, funktioniert weit besser als mechanisches Zerlegen. Leicht überlappende Abschnitte verhindern, dass Antworten zwischen die Grenzen fallen. Metadaten anzuhängen, Dokumenttitel, Abschnittsüberschrift, Datum und Quelle, erlaubt es, nach Aktualität oder Abteilung zu filtern und, entscheidend, zu belegen, woher eine Antwort stammt.

Belege sind nicht optional:

Die wichtigste Entwurfsentscheidung in einem RAG-System ist die Vorgabe, dass das Modell angeben muss, welche gefundene Passage jede Behauptung stützt, mit einem Link zum Ausgangsdokument.

Belege leisten dreierlei auf einmal. Sie erlauben Nutzerinnen und Nutzern, Antworten zu prüfen, statt ihnen zu vertrauen, was das System für alles Folgenreiche überhaupt erst brauchbar macht. Sie machen Halluzination sichtbar, denn eine unbelegte Behauptung hat keine Fundstelle. Und sie verwandeln das Werkzeug von einem Orakel in eine Rechercheassistenz, eine weit besser vertretbare Position.

Systeme, die selbstsicher ohne nachvollziehbare Quelle antworten, sind jene, die nach dem ersten ernsten Fehler das Vertrauen verlieren.

Woran RAG-Systeme scheitern:

Der häufigste Fehlschlag liegt gar nicht am Modell. Er liegt am Retrieval. Wurde die richtige Passage nie geholt, kann kein Modell eine richtige Antwort erzeugen. Enttäuscht ein RAG-System, sehen Sie sich die gefundenen Abschnitte an, bevor Sie das Modell beschuldigen; dort liegt meist der Fehler.

Der zweite sind veraltete Inhalte. Widersprechen sich die zugrunde liegenden Dokumente, weil überholte Fassungen nie entfernt wurden, wird das System überzeugt eine überholte Richtlinie hervorholen. RAG erbt die Qualität des Ausgangsmaterials genau.

Der dritte betrifft Fragen, die eine Zusammenschau vieler Dokumente verlangen. Retrieval findet Passagen, die einer Frage ähneln, was für „wie lautet unsere Richtlinie zu X" gut funktioniert und für „fasse alle Beschwerden dieses Quartals zusammen und finde Muster" schlecht. Das ist ein Auswertungsproblem im Gewand einer Chat-Oberfläche.

RAG, Feintuning oder längerer Kontext:

Sie werden oft als Konkurrenten dargestellt. Sie lösen verschiedene Probleme.

RAG liefert Wissen: Fakten, Dokumente, aktuelle Informationen. Feintuning formt Verhalten: Ton, Format, Fachvokabular, gleichbleibenden Aufbau. Lautet die Klage, das Modell wisse etwas nicht, ist das RAG. Weiß es etwas, antwortet aber im falschen Stil, ist das Feintuning.

Sehr lange Kontextfenster haben manche zu dem Vorschlag geführt, einfach alles hineinzukopieren. Für eine überschaubare Menge Dokumente ist das inzwischen wirklich gangbar und viel einfacher. Doch es kostet mehr je Anfrage, wird langsamer, je mehr Inhalt hinzukommt, und Modelle beachten Material in der Mitte sehr langer Eingaben weiterhin ungleichmäßig. Im großen Maßstab bleibt Retrieval die praktische Wahl, und beides ergänzt sich gut: breit abrufen und dann ein großes Fenster mehr von dem halten lassen, was man gefunden hat.

Eines bauen, das funktioniert:

Fangen Sie eng an. Ein System für einen gepflegten Dokumentenbestand und eine klar umrissene Nutzergruppe wird gelingen, wo der Versuch, alles auf einmal zu erschließen, scheitert.

Messen Sie Retrieval getrennt von der Erzeugung, anhand eines festen Satzes echter Fragen mit bekannten richtigen Quellen. Der meiste Fortschritt kommt aus besserer Abschnittsbildung, hybrider Suche und Reranking, nicht aus einem Modellwechsel.

Vor allem: Halten Sie die Quelle der Wahrheit sauber. RAG repariert keine unordentliche Dokumentenablage. Es legt sie offen.