RAG (Retrieval Augmented Generation)
RAG (Retrieval Augmented Generation) ergänzt ein Sprachmodell um passende Textstellen aus einer Wissensbasis. Vor der Antwort werden Inhalte gesucht und als Kontext mitgegeben. Das kann Antworten aktueller und nachvollziehbarer machen; falsche Treffer, veraltete Quellen und unbelegte Ergänzungen des Modells bleiben mögliche Fehler.
Der Ablauf in fünf Schritten
Zwei davon passieren einmalig beim Aufbau, drei bei jeder einzelnen Frage.
- Zerlegen. Dokumente werden in Abschnitte geteilt, die einzeln auffindbar sein sollen.
- Einbetten und speichern. Jeder Abschnitt wird in eine Zahlenreihe übersetzt und mit seinen Metadaten abgelegt – Quelle, Überschriftenpfad, Datum.
- Abrufen. Die Frage wird mit demselben Verfahren übersetzt, die ähnlichsten Abschnitte werden gesucht.
- Zusammenstellen. Die besten Treffer werden zusammen mit der Frage und einer Anweisung in den Kontext gelegt.
- Formulieren. Das Modell schreibt die Antwort – ausdrücklich aus dem Mitgelieferten, nicht aus dem Gedächtnis.
Warum der Abruf die Schwachstelle ist
Der Abruf prägt die Antwortqualität stark: Fehlt die passende Stelle, kann das Modell sie nicht aus dem bereitgestellten Kontext belegen. Auch Quellenqualität, Anweisungen und die Verarbeitung durch das Modell entscheiden mit. Ein guter Abruf allein garantiert noch keine richtige Antwort.
Ein schlechter Abruf muss keinen technischen Fehler auslösen. Das Modell kann einen thematisch benachbarten, aber unpassenden Abschnitt überzeugend zusammenfassen. Deshalb sollten Prüfungen die gefundenen Stellen und die Antwort gemeinsam bewerten.
Daraus folgt eine Prüfregel: Wer ein RAG-System bewertet, muss die abgerufenen Abschnitte sehen, nicht nur die Antwort.
Die drei Stellschrauben mit dem größten Effekt
Chunking. Überschriften und Absätze sind sinnvolle Grenzen für Textabschnitte. Die passende Größe hängt vom Inhalt ab. Überlappungen und mitgeführte Überschriften können helfen, Zusammenhänge zu erhalten. Ob die Aufteilung besser ist, zeigt ein Testset mit bekannten Antwortstellen.
Hybride Suche. Bei Produktnummern, Fehlercodes und Eigennamen kann reine Vektorsuche ungenau sein. Eine Kombination mit Volltextsuche ist eine mögliche Verbesserung. Aufwand und Nutzen sollten am eigenen Bestand gemessen werden.
Re-Ranking. Ein zusätzlicher Schritt bewertet abgerufene Treffer erneut gegen die Frage. Beispielsweise können zunächst 30 Treffer gesucht und anschließend fünf ausgewählt werden. Das kann die Relevanz verbessern, kostet aber zusätzliche Laufzeit und gegebenenfalls Geld. Die Zahlen sind ein Versuchsaufbau, keine allgemeine Vorgabe.
Was RAG nicht kann
Ein einfacher RAG-Abruf liefert eine Auswahl von Stellen. Vollständigkeit über den gesamten Bestand verlangt zusätzliche Verfahren.
Zählen und vollständig aufzählen. „Wie viele Artikel gibt es zu Thema X“ ist mit RAG nicht zuverlässig zu beantworten, weil immer nur eine Auswahl abgerufen wird. Solche Fragen brauchen eine Datenbankabfrage, kein Ähnlichkeitsmaß.
Vergleichen über den gesamten Bestand. „Was hat sich zwischen den beiden Fassungen geändert“ setzt voraus, dass beide vollständig vorliegen. Ein Abruf liefert Ausschnitte.
Zusammenhänge über viele Dokumente hinweg. Wenn eine Antwort viele Quellen benötigt, können Auswahl und Kontextbudget zum Engpass werden. Zehn Quellen sind keine feste technische Grenze. Mehrstufiger Abruf, Zusammenfassungen oder gezielte Werkzeuge können hier helfen.
Wer diese drei Fälle kennt, baut sie als eigene Werkzeuge daneben, statt am Abruf herumzuschrauben, bis er sie irgendwie auch erledigt.
„Weiß ich nicht“ als Funktion
Der eigentliche Gewinn von RAG ist nicht Aktualität, sondern die Möglichkeit, die Grenze des eigenen Wissens zu benennen. Wenn feststeht, dass nur aus den mitgelieferten Abschnitten geantwortet werden darf, dann ist eine leere Trefferliste eine gültige Antwort.
Ohne passende Anweisung und Prüfung kann das Modell Lücken aus seinem Trainingswissen füllen. Eine leere Trefferliste sollte deshalb eine begrenzte Antwort auslösen: Für diese Frage ist in der geprüften Wissensbasis kein ausreichender Beleg vorhanden. Auch diese Regel muss getestet werden.
Aufwand im laufenden Betrieb
Ein RAG-System ist nicht fertig, wenn es antwortet. Drei Dinge kommen dauerhaft dazu.
Geänderte Inhalte müssen neu zerlegt und eingebettet werden, gelöschte müssen verschwinden. Ein Abschnitt, der im Index bleibt, nachdem die Seite überarbeitet wurde, produziert veraltete Antworten mit dem vollen Selbstbewusstsein einer belegten Aussage.
Ein Wechsel des Embedding-Modells bedeutet Neuberechnung des gesamten Bestands, weil Embeddings verschiedener Modelle nicht vergleichbar sind. Bei gleicher Vektorlänge kann eine solche Mischung unbemerkt schlechte Treffer liefern; bei abweichenden Dimensionen kann die Datenbank die Anfrage ablehnen.
Und es braucht ein kleines Testset: zwanzig bis dreißig Fragen, deren Antwortstelle bekannt ist. Damit lässt sich nach jeder Änderung prüfen, ob der richtige Abschnitt noch gefunden wird. Ohne dieses Set optimiert man nach Gefühl.
Aus dem eigenen Betrieb
Evitas aktueller Abruf wählt bis zu fünf geeignete Textabschnitte aus; darunter höchstens zwei nicht abgelaufene News-Briefings. Das sind Codegrenzen des heutigen Systems, keine allgemeinen RAG-Regeln.
Ein konkretes Problem der Anzeige: Fünf Textabschnitte können aus nur drei unterschiedlichen Seiten stammen. Deshalb zeigt der Aktivitätsbereich inzwischen die Anzahl verlinkter Wissensseiten, das gesuchte Thema und die verfügbaren Seitentitel getrennt an. Die Zahl der Abschnitte allein war als Quellenzahl missverständlich.
Die Abrufauswahl ist noch kein Beweis dafür, dass jede Stelle in der endgültigen Antwort verwendet wurde. Dafür muss man zusätzlich die Antwort und ihre Belege prüfen. Evita und die Wissensaktivität ansehen.