RAG verstehen Teil II: Wie klassisches RAG funktioniert
Im ersten Beitrag dieser Reihe stellten wir Retrieval Augmented Generation (RAG) vor und erklärten, dass es notwendig wurde, die Fähigkeiten herkömmlicher großer Sprachmodelle (LLMs) zu erweitern. Wir skizzieren auch kurz die Schlüsselidee, die RAG zugrunde liegt: das Abrufen kontextrelevanter Informationen aus externen Wissensdatenbanken, um sicherzustellen, dass LLMs genaue und aktuelle Informationen produzieren, ohne unter Halluzinationen zu leiden und ohne dass das Modell ständig neu trainiert werden muss.
Der zweite Artikel dieser aufschlussreichen Reihe entmystifiziert die Mechanismen, nach denen ein herkömmliches RAG-System funktioniert. Während heutzutage im Zuge der rasanten KI-Fortschritte fast täglich viele verbesserte und ausgefeiltere Versionen von RAG auf den Markt kommen, besteht der erste Schritt zum Verständnis der neuesten, hochmodernen RAG-Ansätze darin, zunächst den klassischen RAG-Workflow zu verstehen.
Der klassische RAG-Workflow
Ein typisches RAG-System (im Diagramm unten dargestellt) verarbeitet drei wichtige datenbezogene Komponenten:
- Ein LLM, das Wissen aus den Daten erworben hat, mit denen es trainiert wurde, typischerweise Millionen bis Milliarden von Textdokumenten.
- Eine Vektordatenbank, auch Wissensdatenbank genannt, die Textdokumente speichert. Aber warum der Name Vektor-Datenbank? In RAG- und Natural Language Processing (NLP)-Systemen insgesamt werden Textinformationen in numerische Darstellungen, sogenannte Vektoren, umgewandelt, die die semantische Bedeutung des Textes erfassen. Vektoren stellen Wörter, Sätze oder ganze Dokumente dar und behalten wichtige Eigenschaften des Originaltextes bei, sodass zwei ähnliche Vektoren Wörtern, Sätzen oder Textteilen mit ähnlicher Semantik zugeordnet werden. Das Speichern von Text als numerische Vektoren erhöht die Effizienz des Systems, sodass relevante Dokumente schnell gefunden und abgerufen werden können.
- Vom Benutzer in natürlicher Sprache formulierte Anfragen oder Aufforderungen.
Kurz gesagt: Wenn der Benutzer einem LLM-basierten Assistenten, der mit einer RAG-Engine ausgestattet ist, eine Frage in natürlicher Sprache stellt, finden zwischen dem Senden der Frage und dem Empfangen der Antwort drei Phasen statt:
- Abruf: Eine Komponente namens Retriever greift auf die Vektordatenbank zu, um relevante Dokumente für die Benutzerabfrage zu finden und abzurufen.
- Erweiterung: Die ursprüngliche Benutzerabfrage wird durch die Einbeziehung von Kontextwissen aus den abgerufenen Dokumenten erweitert.
- Generierung: Der LLM – aus RAG-Sicht auch allgemein als Generator bezeichnet – empfängt die Benutzeranfrage ergänzt um relevante Kontextinformationen und generiert eine präzisere und wahrheitsgetreuere Textantwort.
Im Retriever
Der Retriever ist die Komponente in einem RAG-System, die relevante Informationen findet, um die später vom LLM generierte Endausgabe zu verbessern. Sie können es sich wie eine erweiterte Suchmaschine vorstellen, die nicht nur Schlüsselwörter in der Benutzeranfrage mit gespeicherten Dokumenten abgleicht, sondern auch die Bedeutung hinter der Anfrage versteht.
Der Retriever durchsucht eine große Menge an Domänenwissen im Zusammenhang mit der Abfrage, das im vektorisierten Format (numerische Darstellungen von Text) gespeichert ist, und ruft die relevantesten Textteile heraus, um einen Kontext um sie herum aufzubauen, der an die ursprüngliche Benutzeranfrage angehängt wird. Eine gängige Technik zur Identifizierung relevanten Wissens ist die Ähnlichkeitssuche, bei der die Benutzeranfrage in eine Vektordarstellung kodiert und dieser Vektor mit gespeicherten Vektordaten verglichen wird. Auf diese Weise läuft das Erkennen der für die Benutzerabfrage relevantesten Wissensteile auf die iterative Durchführung einiger mathematischer Berechnungen hinaus, um die Vektoren zu identifizieren, die der Vektordarstellung dieser Abfrage am nächsten (ähnlichsten) sind. Und so gelingt es dem Retriever, genaue, kontextbezogene Informationen nicht nur effizient, sondern auch genau abzurufen.
Im Generator
Der Generator in RAG ist typischerweise ein hochentwickeltes Sprachmodell, oft ein LLM, das auf einer Transformer-Architektur basiert, das die erweiterten Eingaben vom Retriever entgegennimmt und eine genaue, kontextbewusste und normalerweise wahrheitsgetreue Antwort erzeugt. Dieses Ergebnis übertrifft in der Regel die Qualität eines eigenständigen LLM durch die Einbeziehung relevanter externer Informationen.
Innerhalb des Modells umfasst der Generierungsprozess sowohl das Verstehen als auch das Generieren von Text, verwaltet von Komponenten, die die erweiterte Eingabe kodieren und Wort für Wort Ausgabetext generieren. Jedes Wort wird auf der Grundlage der vorhergehenden Wörter vorhergesagt: Diese Aufgabe, die als letzte Stufe innerhalb des LLM ausgeführt wird, ist als Nächstes-Wort-Vorhersage-Problem bekannt: Vorhersage des wahrscheinlichsten nächsten Wortes, um Kohärenz und Relevanz aufrechtzuerhalten in der generierten Nachricht.
In diesem Beitrag wird der vom Generator gesteuerte Sprachgenerierungsprozess weiter erläutert.
Blick nach vorn
Im nächsten Beitrag dieser Artikelreihe zum Verständnis von RAG werden wir Fusionsmethoden für RAG aufdecken, die sich durch die Verwendung spezieller Ansätze zum Kombinieren von Informationen aus mehreren abgerufenen Dokumenten auszeichnen und so den Kontext für die Generierung einer Antwort verbessern.
Ein häufiges Beispiel für Fusionsmethoden in RAG ist das Reranking, bei dem mehrere abgerufene Dokumente anhand ihrer Benutzerrelevanz bewertet und priorisiert werden, bevor die relevantesten Dokumente an den Generator übergeben werden. Dies trägt dazu bei, die Qualität des erweiterten Kontexts und der eventuellen vom Sprachmodell erzeugten Antworten weiter zu verbessern.