Was ist RAG (Retrieval-Augmented Generation) und wann braucht man es?
RAG gibt einem Sprachmodell Ihre Dokumente zur Fragezeit an die Hand, anstatt sie in die Gewichte einzubacken. Hier erfahren Sie, wie die Pipeline funktioniert, warum die meisten RAG-Fehler auf Abruffehler zurückzuführen sind und wann ein einfacherer Ansatz die Nase vorn hat.
Kurze Antwort
Was ist Retrieval-Augmented Generation (RAG)?
Retrieval-augmented Generation ist ein Muster, bei dem das System Ihre eigenen Dokumente nach relevanten Passagen zu einer Frage durchsucht, diese Passagen in den Prompt des Modells einfügt und das Modell bittet, diese zu verwenden, um zu antworten. Die Gewichte des Modells ändern sich nie; das Wissen kommt zur Laufzeit als Kontext.
Das Wichtigste
- RAG ist Suche plus Prompting. Wenn der Suchschritt die falschen Passagen zurückgibt, kann kein Modell die Antwort retten.
- Vektorsimilarität allein ist schwach bei Namen, Codes und exakten Phrasen – hybride Keyword-plus-Vektor-Suche ist der praktische Standard.
- Es aktualisiert sich sofort: Ändern Sie das Dokument, und die nächste Antwort ändert sich. Fine-Tuning kann das nicht.
- Zitate sind der Punkt. Begründete Antworten, die auf die Quellpassage verweisen, sind auf eine Weise überprüfbar, wie es reine Generierung nicht ist.
Ein Sprachmodell weiß nur, was in seinen Trainingsdaten enthalten war, und nichts anderes. Es kennt nicht Ihre Vertragsbedingungen, die Zahlen des letzten Quartals oder den gestern eingereichten Vorfallbericht. Retrieval-Augmented Generation ist der Standardweg, um diese Lücke zu schließen, ohne etwas neu zu trainieren.
Die Pipeline, Ende zu Ende
RAG hat zwei Phasen. Die erste findet im Voraus statt.
Indizierung (offline)
- Sammeln Sie die Dokumente.
- Teilen Sie sie in Passagen auf – typischerweise einige hundert bis einige tausend Tokens pro Stück.
- Berechnen Sie für jeden Abschnitt ein Embedding: einen Vektor von Zahlen, der diesen Text in einem Raum positioniert, in dem ähnliche Bedeutungen nahe beieinander liegen.
- Speichern Sie die Vektoren, den Originaltext und Metadaten (Quelle, Abschnitt, Datum, Berechtigungen) in einem Index.
Beantwortung (pro Anfrage)
- Nehmen Sie die Frage des Benutzers und betten Sie sie auf die gleiche Weise ein.
- Rufen Sie die nächstgelegenen Abschnitte ab – oft kombiniert mit einer Stichwortsuche.
- Sortieren Sie die Kandidaten optional mit einem kleineren Modell neu, das die Relevanz genauer bewertet als die reine Vektor-Distanz.
- Stellen Sie einen Prompt zusammen: Anweisungen, die abgerufenen Passagen, die Frage.
- Generieren Sie die Antwort mit Anweisungen, welche Passage für jede Behauptung zitiert werden soll.
Das ist die gesamte Idee. Der Clou liegt im Retrieval-Schritt, nicht im Generierungs-Schritt.
Die meisten RAG-Fehler sind Retrieval-Fehler
Wenn ein RAG-System eine falsche Antwort gibt, ist der Instinkt, das Modell zu beschuldigen. Es ist fast immer die Suche.
Bevor Sie etwas anderes ändern, führen Sie diese Prüfung durch: Nehmen Sie die fehlerhafte Frage, schauen Sie sich die tatsächlich abgerufenen Passagen an und fragen Sie sich, ob ein sorgfältiger Mensch sie hätte korrekt beantworten können. Wenn nicht, hatte das Modell nie eine Chance.
Häufige Ursachen, ungefähr in absteigender Reihenfolge der Häufigkeit:
- Vokabular-Diskrepanz. Der Benutzer fragt nach "Kündigung"; der Vertrag sagt "Stornierung". Reine Vektorsuche bewältigt dies einigermaßen gut; reine Stichwortsuche nicht.
- Exakte Identifikatoren. Der Benutzer fragt nach Rechnung
INV-2024-8871. Vektorsuche ist schlecht darin – das Embedding eines Identifikators trägt fast keine Bedeutung. Stichwortsuche findet es sofort. Dies ist das stärkste Argument für hybrides Retrieval: Führen Sie beides aus, verschmelzen Sie die Ranglisten. - Schlechte Chunk-Grenzen. Die Definition ist in einem Chunk, die Ausnahme im nächsten, und nur einer wurde abgerufen.
- Fehlende Metadatenfilter. Die Antwort kam aus einem Dokument, das der Benutzer nicht sehen darf, oder aus einer veralteten Version. Filtern Sie nach Berechtigung und Gültigkeit vor der Ähnlichkeit, nicht danach.
- Zu wenige Ergebnisse. Das Abrufen von drei Chunks ist effizient und zerbrechlich. Rufen Sie zwanzig ab, sortieren Sie neu, behalten Sie die besten fünf.
Wann RAG das falsche Werkzeug ist
RAG ist nicht kostenlos. Es fügt einen zu wartenden Index, ein Problem mit der Retrieval-Qualität, das überwacht werden muss, und Latenz zu jeder Anfrage hinzu. Überspringen Sie es, wenn:
- Der Korpus ist klein. Wenn Ihre gesamte Wissensbasis 20 Seiten umfasst, legen Sie sie in den System-Prompt und cachen Sie sie.
- Die Frage bezieht sich nicht auf Dokumente. Aggregationen – "wie viele Bestellungen wurden letzten Monat verspätet geliefert?" – gehören in SQL. Geben Sie dem Modell ein Abfragewerkzeug anstelle eines Vektorindex.
- Die Aufgabe betrifft den Stil, nicht die Fakten. Das Modell dazu zu bringen, in Ihrer Unternehmenssprache zu schreiben, ist ein Prompting- oder Fine-Tuning-Problem.
Es gibt auch einen Mittelweg, der erwähnenswert ist: agentisches Retrieval, bei dem dem Modell ein Suchwerkzeug zur Verfügung gestellt wird und es seine eigenen Abfragen ausgibt, die es nach Erhalt der Ergebnisse verfeinert. Es kostet mehr Anfragen, bewältigt aber Multi-Hop-Fragen ("vergleichen Sie die Richtlinien von 2024 und 2025"), die ein einzelner Retrieval-Durchlauf verpasst.
Was gute Antworten ausmacht
Drei Praktiken erledigen die meiste Arbeit:
Zitate verlangen. Bitten Sie das Modell, jedem Anspruch eine Quellenkennung anzuhängen, und rendern Sie diese als Links. Benutzer können dann überprüfen, und Sie können messen, wie oft die zitierte Passage den Satz tatsächlich stützt.
Verweigerung erlauben. Weisen Sie explizit an: Wenn die abgerufenen Passagen die Frage nicht beantworten, sagen Sie, dass Sie es nicht wissen. Ohne dies füllt ein hilfreiches Modell die Lücke mit seinem allgemeinen Wissen – das richtig, falsch oder über ein ganz anderes Unternehmen sein kann.
Retrieval separat bewerten. Erstellen Sie einen Satz von Frage-und-korrekt-Passagen-Paaren und verfolgen Sie den Recall bei k. Diese Zahl sagt Ihnen, ob sich das Retrieval verbessert, unabhängig davon, wie die Antworten klingen. Teams, die nur die endgültigen Antworten überfliegen, optimieren blind.
Was gut aussieht
Ein ausgereiftes RAG-System ist auf eine bestimmte Weise langweilig: Es beantwortet aus Ihren Dokumenten, verlinkt sie, gibt zu, wenn es etwas nicht finden kann, und zeigt morgen das gleiche Verhalten wie heute. Dorthin zu gelangen, ist hauptsächlich Such-Engineering – Chunking, hybrides Retrieval, Re-Ranking, Filter – wobei das Sprachmodell den letzten, kleinsten Schritt ausführt.
Wenn Sie entscheiden, wo Sie eine Arbeitswoche verbringen, verbringen Sie sie mit Retrieval.
Häufige Fragen
- Ist RAG besser als Fine-Tuning?
- Sie lösen unterschiedliche Probleme. RAG liefert Fakten, die das Modell nicht hat; Fine-Tuning lehrt Format, Ton oder eine spezifische Fähigkeit. Wenn Ihr Problem lautet „es kennt unsere Daten nicht“, verwenden Sie RAG. Wenn es lautet „es antwortet nicht so, wie wir es wollen“, erwägen Sie Fine-Tuning.
- Macht ein sehr großes Kontextfenster RAG überflüssig?
- Es reduziert den Druck, beseitigt aber nicht die Notwendigkeit. Das Senden eines gesamten Korpus bei jeder Anfrage ist teuer und langsam, und die Genauigkeit leidet immer noch bei sehr langen Eingaben. Retrieval hält jede Anfrage klein und relevant.
- Warum halluziniert mein RAG-System immer noch?
- Normalerweise, weil die Abfrage nichts Nützliches zurückgegeben hat und das Modell trotzdem geantwortet hat. Die Lösung ist eine explizite Anweisung und Überprüfung: Wenn die abgerufenen Passagen die Antwort nicht enthalten, sagen Sie das.
- Was ist Chunking und warum ist es wichtig?
- Chunking ist die Art und Weise, wie Dokumente vor der Indizierung aufgeteilt werden. Zu kleine Chunks verlieren den umgebenden Kontext; zu große Chunks verwässern den Treffer. Das Aufteilen anhand der Dokumentenstruktur – Abschnitte und Überschriften – ist in der Regel besser als das Aufteilen nach einer festen Zeichenanzahl.