Was ist Retrieval Augmented Generation (RAG)?

Seit einigen Jahren sind große Sprachmodelle oder auch Large Language Models, kurz LLMs in aller Munde und werden von vielen Unternehmen als Chatbots oder für Texterstellung genutzt. Es gibt verschiedene Methoden, die Effizienz dieser Modelle zu steigern,

1. Prompt Engineering,
2. Retrieval Augmented Generation (RAG)
3. und Feinabstimmung.

In diesem Beitrag geht es um Methode 2: Retrieval Augmented Generation, kurz RAG.

Lassen Sie uns starten!

Was ist die Definition von Retrieval Augmented Generation (RAG)?

RAG ist ein Architekturansatz, der die Effizienz großer Sprachmodelle (Large Language Models, LLMs) verbessert, indem er Kontext-spezifische Daten nutzt. Dieser Prozess erfolgt durch das Abrufen relevanter Daten oder Dokumente, die in Bezug auf eine gestellte Frage oder Aufgabe relevant sind, und stellt diese als Kontext für das LLM bereit.

Ein Anwendungsbeispiel ist die Drogeriekette dm: Hier wurde ein RAG-Framework verwendet, um Mitarbeitern Zugriff auf interne Produktinformationen zu ermöglichen, damit Betriebsprozesse effizienter laufen. Dafür integrierten Verantwortliche Echtzeitdaten zu Produkten in das LLM-Training.

Schauen wir uns das genauer an. Wenn wir mit einem LLM „kommunizieren“, gehen wir davon aus, dass das System uns korrekt auf unsere Frage antworten wird. Hier ist die Herausforderung: In dem LLM-Trainingsprozess fließt all das Wissen, Konzepte und Theorien der Welt komprimiert in das Modell. Diese Wissenskomprimierung hat 2 Folgen:

1. Das Wissen stagniert und wird nicht regelmäßig ergänzt/ upgedated
2. LLMs verfügen über viel Allgemeinwissen, haben jedoch wenig spezifisches Expertenwissen

RAG setzt an diesen beiden Herausforderungen an und versucht die Grenzen von Large Language Models durch spezifischen Kontext zu erweitern. Zum Beispiel ergänzen (Augmenting) wir LLMs um Domänenspezifisches Wissen, welches regelmäßig aktualisiert wird.

Wie das funktioniert?

Ein User tätigt eine Eingabe, welche von dem Retriever abgefangen wird. Dieser Retriever analysiert die Eingabe und extrahiert dann mit Hilfe von Text Embeddings die passenden Informationen aus der Wissensdatenbank. Daraus entsteht dann der Prompt, welcher wiederum durch das LLM als Ausgabe an den User übermittelt wird.

In unserem YouTube Video erklären wir in 9 Minuten was RAG ist.

Grundsätzlich stellt der RAG-Ansatz eine kostengünstige Variante für die Anpassung großer Sprachmodelle (LLMs) an unternehmensspezifische Daten dar.

Was sind Herausforderungen von Large Language Models?

RAG adressiert zwei zentrale Herausforderungen, die sich bei der Nutzung von LLMs ergeben.

1. Die erste Herausforderung besteht darin, dass LLMs aufgrund ihres Trainings auf großen, aber statischen Datensätzen oft nicht in der Lage sind, aktuelle oder spezifische Daten zu kennen. Dies führt dazu, dass sie veraltete Antworten geben oder sogar Fehlinformationen erzeugen können. In der Praxis führt es dann dazu, dass das LLM internes Wissen des Unternehmens wie gängige Abkürzungen oder Produktdaten nicht kennt und im schlimmsten Fall halluziniert.
2. Die zweite Herausforderung betrifft die Notwendigkeit für KI-Anwendungen, domänenspezifische Daten effektiv zu nutzen, um relevante und präzise Antworten zu liefern, insbesondere in Anwendungen wie Kundensupport-Bots oder internen Q&A-Systemen​​.

Die Lösung für diese Herausforderungen bietet die RAG-Architektur. RAG ermöglicht das Einbeziehen von unternehmensinternen Datenquellen (z.B. PDF, Handbücher, Produktstammdaten) für die Beantwortung einer Anfrage. Die Antwort ist somit auf dem neuesten Stand und spezifisch für den jeweiligen Anwendungsfall.

Diese Methode, bekannt als RAG, hat sich als branchenübergreifender Standard etabliert. Sie ermöglicht es Organisationen LLMs auf Basis von geringen Kosten und Aufwand zu verwenden.

Sehen wir uns nun an, in welchen Branchen und Use-Cases Sie den RAG-Architekturansatz einsetzen können.

Was sind die Vorteile von RAG?

Einer der Hauptvorteile von RAG ist die Fähigkeit, unternehmensspezifische, personalisierte und qualitativ hochwertige Antworten zu liefern. Indem es sich auf aktuelle, externe Datenquellen stützt, überwindet RAG die Beschränkungen, die sich aus der alleinigen Verwendung von statischen, veralteten Trainingsdaten ergeben. Durch die Verwendung von RAG kann das LLM-Modell kontextbezogene Antworten liefern, die speziell auf die proprietären oder domänenspezifischen Daten einer Organisation zugeschnitten sind.

Ein weiterer wesentlicher Vorteil ist die Effizienz und Kosteneffektivität dieser Methode. Im Vergleich zu anderen Ansätzen, die eine Anpassung von LLMs an domänenspezifische Daten erfordern, ist RAG einfach und kostengünstig in der Implementierung. Organisationen können RAG einsetzen, ohne das Modell anpassen zu müssen. Dies ist besonders vorteilhaft, wenn Modelle regelmäßig mit neuen Daten aktualisiert werden müssen. Zusammenfassend ermöglicht RAG Organisationen, ihre LLM-Anwendungen ohne erheblichen finanziellen oder zeitlichen Aufwand zu optimieren und dabei genaue und relevante Ergebnisse zu erzielen.

1. Aktuelles, benutzerdefiniertes Wissen: Die Antworten der RAG Lösung basieren auf aktuellen, benutzerspezifischen Dokumenten und Daten (können strukturiert aber auch unstrukturiert sein). Beispiele hierfür sind PDF-Dokumente, Handbücher aber auch Kaufdaten von Kunden. Die Antworten basieren somit auf aktuellen, benutzerdefinierten Dokumenten und Daten, nicht nur auf Trainingsdaten.
2. Reduziert das Risiko von Halluzinationen: Wenn ein Large Language Model (wie GPT4 oder Claude) die Antwort auf eine Frage nicht in seinem Trainingsdatensatz finden kann, neigt es zu Halluzinationen. Im Gegensatz dazu verankert RAG die Modelleingaben in externem Wissen und kann Quellen zitieren, wodurch das Risiko falscher Antworten reduziert wird.
3. Domänenspezifische Kontextualisierung: Kann spezialisierte, domänenspezifische Anfragen bearbeiten, indem es eigene oder domänenspezifische Daten (z.B. ihren Produktkatalog aus dem PIM oder Produkthandbücher für technische Fragen) verwendet.
4. Effizienz und Kosteneffektivität: Ermöglicht die Anpassung mit Daten ohne die Notwendigkeit der Feinabstimmung, was Entwicklungszeit und -kosten reduziert.

RAG ist nach dem Prompt Engineering die am wenigsten komplexe Möglichkeit LLMs an spezifische Bedürfnisse anzupassen und hat sich in der Praxis bewährt. Lassen Sie uns im nächsten Abschnitt auf die häufigsten Anwendungsfälle von RAG eingehen.

Was sind typische Anwendungsfälle von RAG?

RAG findet in einer Reihe von Bereichen Anwendung, wobei die häufigsten Einsatzgebiete Frage-Antwort-Chatbots oder Empfehlungsdienste sind. Bei Chatbots ermöglicht RAG eine automatische Ableitung präziserer Antworten aus Unternehmensdokumenten und internen Wissensdatenbanken. Das ermöglicht zum Beispiel die Entlastung des Support-Teams oder steigert die Produktivität ihres Vertriebs- oder Marketingteams. Als Empfehlungsdienst kann das RAG-angereicherte LLM potenziellen Käufern individuelle Empfehlungen vorschlagen, was zu einer Steigerung der Verkaufsrate führt. Aber auch als Suchmaschine entlastet die RAG-Architektur Mitarbeiter, indem sie in Sekunden wichtige Antworten zu Verträgen, Produktinformationen oder HR-Wissen bereitstellt.

In der folgenden Tabelle haben wir Ihnen wichtige Branchen und die jeweiligen Einsatzmöglichkeiten von RAG zusammengetragen.

Diese Vielfalt an Einsatzmöglichkeiten zeigt, wie RAG die Grenzen herkömmlicher LLM-Anwendungen erweitert, indem es sie mit dynamischen, kontextbezogenen und aktuellen Daten versorgt. Dadurch wird nicht nur die Genauigkeit der Antworten verbessert, sondern auch das Risiko von inkorrekten oder erfundenen Informationen (Halluzinationen) reduziert. RAG ermöglicht es Unternehmen, ihre LLM-Systeme effizient und kostengünstig an ihre spezifischen Bedürfnisse anzupassen.

Um Ihnen zu zeigen, wie Sie RAG zur Optimierung Ihres LLM verwenden können, stellen wir Ihnen im folgenden Absatz einen Use Case vor, den wir für unseren Kunden umsetzen durften.

Unsere Case Study für ein Wein-Empfehlungssystem mit RAG-Architektur

Für unseren Kunden – einen internationalen Weinhändler – durften wir das bestehende LLM mit einer RAG-Architektur personalisieren. Das Ziel war es, den Kunden des Weinhändlers einen Empfehlungsdienst auf der Website zu ermöglichen in Form eines Chatbots. Dafür pflegten wir die unternehmensinternen Daten über Produktinformationen zu einzelnen Weinen in das Modell ein. Der Kunde hat die Möglichkeit, dem Chatbot Fragen zu stellen, wie Beispielsweise „Welcher Wein passt am besten zu Lamm?“ Als Antwort folgt eine Empfehlung basierend auf den Vorlieben des Kundenprofils Die User Query wird innerhalb weniger Sekunden mit den Informationen zu verfügbaren Produkten abgeglichen. Der Chatbot schlägt dem Kunden schließlich den Wein/ die Weinsorten vor, die am besten zu seiner Anfrage passen. Durch den im Vorab von uns erstellten Prompt werden unseriöse Anfragen mit entsprechenden Hinweisen zu einem verantwortungsvollen Umgang mit Alkohol beantwortet.

Schritt-für-Schritt-Anleitung für RAG-Anwendungen

Die Implementierung eines RAG-Systems kann je nach spezifischen Anforderungen und Datencharakteristika variieren. Ein häufig angewandter Workflow umfasst mehrere Schlüsselschritte:

1. Datenvorbereitung: Zuerst werden Dokumentendaten zusammen mit Metadaten gesammelt und einer ersten Verarbeitung unterzogen, wie beispielsweise der Handhabung von personenbezogenen Informationen.
2. Indexierung relevanter Daten: Anschließend erfolgt die Erstellung von Dokumenten-Embeddings, die in einen Vector Search Index eingespeist werden.
3. Abrufen relevanter Daten: Dabei werden Teile der Daten abgerufen, die für eine Nutzeranfrage relevant sind, und dann als Teil der Eingabeaufforderung für das LLM verwendet.
4. Aufbau von LLM-Anwendungen: Die Komponenten der Eingabeerweiterung und das Abfragen des LLMs werden in einem Endpunkt zusammengeführt, der dann für Anwendungen wie Q&A-Chatbots über eine einfache REST-API zugänglich gemacht werden kann.

Zu den Schlüsselelementen einer RAG-Architektur gehören unter anderem Vector-Datenbanken für schnelle Ähnlichkeitssuchen und die MLflow AI Gateway für die Standardisierung von Schnittstellen. Diese Elemente tragen dazu bei, dass das eingesetzte Sprachmodell Zugang zu aktuellen Informationen hat und effizient genutzt werden kann​​.

Unabhängig von der gewählten Methode ist es wichtig, eine Lösung strukturiert und modular aufzubauen, um Flexibilität für Anpassungen und Weiterentwicklungen zu gewährleisten​​. Es gibt noch weitere Möglichkeiten, LLMs zu optimieren. Diese stellen wir Ihnen im nächsten Abschnitt vor.

Typische Herausforderungen für RAG-Applikationen

Auch wenn die RAG-Architektur einfach zu implementieren ist, stellen sich typischerweise eine Reihe von Herausforderungen, um eine hohe Qualität zu erreichen. Diese beziehen sich zumeist explizit auf den Retrieval-Prozess, also an dem Schritt, wo Dokumente für den Kontext gesammelt werden oder aber auf den Generation-Prozess, also den Teil der RAG-Architektur, wo die Antwort aus dem Kontext generiert wird.

Retrieval-Probleme

Als die drei gängigsten Herausforderungen beim Retrieval können folgende Aspekte herausgestellt werden:

1. Vollständigkeit: Es kann sein, dass das Dokument, welches zum Beantworten der Frage benötigt wird, nicht im Kontext ist. Hier gilt es den Retrieval-Prozess zu optimieren. Eine mögliche wichtige Methode hier ist Query Optimization. Hier wird die Anfrage des Users mit Hilfe von anderen LLM-Prompts vorverarbeitet, um besser für das Retrieval formatiert zu sein, zum Beispiel durch Zusammenfassen der Anfrage oder durch Extraktion der Keywords in dieser.
2. Granularität: Es besteht eine gewisse Freiheit, wie groß oder klein die sogenannten Chunks im Vectorindex sind. Ein Dokument wird meist nicht komplett embedded sondern zuerst in kleinere Texteinheiten (den Chunks) zerlegt. Sind die Chunks zu groß, kann es sein, dass die Texte nicht in das Kontextfenster des LLMs passen. Sind sie zu klein, kann es sein, dass Zusammenhänge der Texte nicht mehr ersichtlich sind. Hier muss vorsichtig mit der optimalen Chunksize experimentiert werden.
3. Metadaten: Manchmal möchte man nur eine gewisse Sorte oder Art von Dokumenten retrieven, beispielsweise bei unserem Weinempfehler nur die Rotweine oder nur Weißweine. Hier macht es Sinn zusätzlich Metadaten einzufügen, womit die Dokumente im Vectorindex versehen werden. Ein weiteres LLM kann dann aus der Useranfrage einen Filter erstellen, der dafür sorgt, dass nur bestimmte Dokumente (zum Beispiel Weißweine) überhaupt retrievt werden können. Somit schließt man von vornerein raus, dass falsche Dokumente überhaupt retrievt werden können.

Generation-Probleme

Auf Seite der Generation tauchen hingegen andere Probleme auf. Hauptsächlich kann man die folgenden Herausforderungen festmachen:

1. Kontextkuration: Es kann sein, dass das wichtige Dokument zur Beantwortung einer Frage zwar im Kontext enthalten ist, aber in der Menge der anderen Dokumente untergeht und deswegen nicht für die Antwort genutzt wird. Insbesondere trifft dies zu, wenn das Dokument in der Mitte des Kontexts liegt („Lost in the middle“ Problem). Hier bietet sich als Lösung das Reranking an, wo mit Hilfe von verschiedenen Metriken der Kontext nochmal umsortiert wird, sodass das wichtigste Dokument auch wirklich an erster Stelle steht.
2. Fachwissen: Ein RAG-System verfügt zwar für jede Frage über Kontext, lernt aber nicht wirklich domänenspezifisches Vokabular. Dies kann verbessert werden, indem man entweder einige feste Regeln in den System Prompt einpflegt oder aber das RAG-System „on top“ noch mit einem Fine-Tuning verseht, um speziellen „Sprech“ zu integrieren.
3. Qualitätskontrolle: um sicherzustellen, dass ein die Antwort des RAG-Systems einen gewissen Standard oder Format entspricht, kann man einen sogenannten LLM-Judge installieren. Dieser Judge ist ein weiteres LLM, welcher in seinem Prompt angewiesen wurde, den Output des RAG-Systems nach gewissen Regeln zu bewerten. Sollte die Qualität mangelhaft sein, kann das RAG-System so designed werden, dass eine Re-Generation der Antwort erfolgen soll.

Die hier beschriebenen Probleme sind zwar die häufigsten, aber nicht die einzigen. Eine naive RAG-Implementierung ist in den seltensten Fällen möglich und es ist immer sinnvoll, die hier beschriebenen Techniken in das bestehende RAG-System mit einzupflegen.

Evaluation von RAG-Systemen

In konventionellen Machine-Learning-Systemen wird die Modellqualität durch vordefinierte Metriken wie Accuracy, Precision, Recall oder den F1-Score bewertet, um zu bestimmen, ob die Performance zufriedenstellend ist. In RAG-Systemen gestaltet sich die Evaluation jedoch deutlich komplexer, da es oft kein direktes quantitatives Maß gibt, um die Qualität der generierten Antworten präzise zu messen.

Genau wie bei den Herausforderungen macht es Sinn die Evaluationen auf beide Schritte anzuwenden: Retrieval und Generation. Jede dieser Phasen muss separat evaluiert werden, da Fehler sowohl im Abrufprozess als auch bei der anschließenden Textgenerierung auftreten können.

Ein zentrales Problem ist das Fehlen eines „Single Ground Truth“ – also einer einzigen korrekten Antwort. Oft gibt es mehrere valide Möglichkeiten, eine Frage zu beantworten, was eine rein objektive Bewertung erschwert. Deshalb ist es nicht trivial, eine einzige Metrik festzulegen, die die Leistung des Systems angemessen widerspiegelt.

LLM as a Judge

Wie schon zuvor angemerkt ist bei RAG-Systemen der Einsatz von Large Language Models (LLMs) als „Judge“  sinnvoll, also das Nutzen eines LLMs, um die generierten Antworten auf deren Qualität hin zu bewerten. Der Judge dient dabei als eine Art „intelligente Instanz“, die sowohl die Richtigkeit als auch die Vollständigkeit der generierten Texte beurteilen kann.

Ein Vorteil dieser Methode ist, dass das LLM in der Lage ist, mehrere korrekte Antwortmöglichkeiten zu erkennen und nicht nur an einer festen Ground Truth festhält. Diese flexiblere Bewertung kann besonders in Anwendungsfällen nützlich sein, bei denen es mehrere richtige Antworten oder Interpretationen gibt, wie z.B. in offenen Fragestellungen oder kreativen Textgenerierungen.

Metriken zur Evaluation von RAG-Systemen

Trotz der Herausforderungen gibt es verschiedene Metriken, die zur Bewertung von RAG-Systemen herangezogen werden können. Diese decken unterschiedliche Aspekte der Retrieval- und Generationsprozesse ab:

1. Retrieval Performance:
   • Recall@K: Diese Metrik misst, wie oft das relevante Dokument unter den ersten K abgerufenen Dokumenten zu finden ist. Je höher der Wert, desto besser ist das Retrieval-Modul des RAG-Systems.
   • Mean Reciprocal Rank (MRR): Diese Metrik bewertet den Rang, an dem das erste relevante Dokument gefunden wird. Je niedriger der Rang, desto besser die Abrufqualität.
2. Generative Performance:
   • ROUGE (Recall-Oriented Understudy for Gisting Evaluation): Häufig verwendet, um zu messen, wie gut der generierte Text mit einem Referenztext übereinstimmt. ROUGE-L fokussiert sich dabei auf die Länge der längsten gemeinsamen Sequenzen.
   • BLEU (Bilingual Evaluation Understudy Score): Misst die Ähnlichkeit zwischen dem generierten und dem referenzierten Text auf Basis von n-Grammen. Vor allem bei maschinellen Übersetzungen populär, aber auch für generative Tasks nützlich.
   • METEOR: Eine Metrik, die Synonyme und Wortstämme berücksichtigt und damit flexibler auf verschiedene Ausdrucksweisen eingeht als ROUGE oder BLEU.
3. Human Evaluation:
   • Human-Rated Quality: Um die generierten Antworten ganzheitlich zu bewerten, werden oft menschliche Experten herangezogen. Diese bewerten die Relevanz, Richtigkeit, Kohärenz und Lesbarkeit der Antworten.
4. LLM Evaluation:
   • LLM-based Scores: Hier wird das LLM selbst zur Bewertung eingesetzt, indem es den generierten Output auf inhaltliche Korrektheit, Kohärenz und Vollständigkeit hin überprüft. Dies erfolgt entweder über skalierte Bewertungen oder durch Klassifizierungsansätze, bei denen das LLM den Output als korrekt oder falsch einordnet.

Die Bedeutung eines Single Ground Truth

Trotz der Flexibilität von LLMs als Bewertungshilfen bleibt das Konzept eines Single Ground Truth in vielen Fällen wichtig. Besonders bei spezifischen, faktischen Informationen (z.B. technische Dokumentationen, juristische Texte oder wissenschaftliche Antworten) muss eine genaue Übereinstimmung zwischen der generierten Antwort und der festgelegten korrekten Lösung bestehen. In solchen Szenarien sollten RAG-Systeme präzise und faktisch korrekt arbeiten.

Das Problem der Mehrdeutigkeit stellt sich oft stärker bei kreativen oder offenen Fragen. In diesen Fällen sind Metriken wie ROUGE oder BLEU möglicherweise weniger geeignet, da sie nur Wortübereinstimmungen bewerten und keine inhaltliche Tiefe. Hier kommt die Human Evaluation oder LLM as a Judge ins Spiel, um die Vielfalt der richtigen Antworten besser abzubilden.

Die Evaluation von RAG-Systemen ist also weitaus komplexer als bei klassischen Machine-Learning-Modellen. Es gibt keine einfache Metrik, die alle Aspekte der Systemleistung angemessen abbilden kann. Vielmehr ist ein kombinierter Ansatz aus Retrieval-Metriken, generativen Metriken sowie menschlicher und LLM-basierter Bewertung notwendig, um eine umfassende und präzise Evaluation zu gewährleisten. Besonders in Anwendungsbereichen, in denen es nicht nur eine richtige Antwort gibt, müssen flexible Bewertungssysteme eingesetzt werden, um die tatsächliche Qualität des Systems abzubilden.

FAQ – Die wichtigsten Fragen schnell beantwortet

Vinzent Wuttke

Geschäftsführer

Ihr Ansprechpartner

Ob und wie künstliche Intelligenz Ihnen weiterhelfen kann, können Sie in einem ersten, unverbindlichen Gespräch mit uns herausfinden.

In diesem Gespräch erfahren Sie:

• Wie Ihr Use-Case technisch am besten umgesetzt werden kann
• Wie wir maximal sicher mit Ihren Kundendaten umgehen
• Wie lange wir für die Umsetzung benötigen und wie ein konkreter Projektplan aussehen könnte

Jetzt Erstgespräch vereinbaren