Was ist Retrieval-Augmented Generation?

Mit Retrieval-Augmented Generation (RAG) können Sie bessere Antworten von einer auf generativer KI basierenden Anwendung erhalten, indem Sie ein Large Language Model (LLM) mit einer externen Ressource verbinden. 

KI von Red Hat erkunden

RAG bietet die Möglichkeit, die in einem LLM vorhandenen Daten durch externe Wissensquellen Ihrer Wahl zu ergänzen, wie etwa Daten-Repositories, Textsammlungen und bestehende Dokumentation. Diese Ressourcen werden dann segmentiert, in einer Vektordatenbank indiziert und als Referenzmaterial genutzt, um genauere Antworten zu liefern.

RAG ist deshalb so hilfreich, weil es das LLM anweist, spezifische Echtzeitinformationen aus den Sources of Truth Ihrer Wahl abzurufen. Unternehmen können außerdem mit RAG Geld sparen, da es ein Kundenerlebnis bereitstellt, ohne dass Ausgaben für das Training und Fine Tuning eines Modells anfallen. Auch Ressourcen lassen sich so sparen, da damit bei der Abfrage eines LLMs statt umfassender Dokumente nur die relevantesten Informationen gesendet werden.

Mehr über generative KI erfahren 

LLMs nutzen Machine Learning und NLP-Techniken (Natural Language Processing), um menschliche Sprache zu verstehen und zu generieren. LLMs können zwar im Bereich Kommunikation und Datenverarbeitung von unglaublichem Nutzen sein, bringen aber auch Nachteile mit sich:

• LLMs werden mit allgemein verfügbaren Daten trainiert, die aber möglicherweise nicht die konkreten Informationen enthalten, auf die sie sich beziehen sollen, etwa interne Daten Ihres Unternehmens.
• LLMs haben einen Wissensstichtag, das heißt, dass die Informationen, mit denen sie trainiert wurden, nicht kontinuierlich aktualisiert werden. Dadurch kann es passieren, dass diese Quellen irgendwann veraltet und nicht mehr relevant sind.
• LLMs wollen gefallen. Statt keine Antwort auszugeben, präsentieren sie daher manchmal falsche oder veraltete Informationen, auch bekannt als „Halluzinationen“.

Wenn Sie eine RAG-Architektur in ein LLM-basiertes Frage-Antwort-System implementieren, ermöglichen Sie die Kommunikation zwischen dem LLM und den von Ihnen gewählten Wissensquellen. Das LLM ist in der Lage, Querverweise zu ziehen und sein internes Wissen zu ergänzen. So bietet es Nutzenden eine zuverlässigere und genauere Ausgabe zu ihrer Abfrage.

Mehr über Large Language Models erfahren 

Mit den Abfragemechanismen einer RAG-Architektur lassen sich zusätzliche Datenquellen nutzen, die über das allgemeine Training eines LLMs hinausgehen. Wenn Sie Ihr LLM über RAG auf eine Basis aus externen, überprüfbaren Fakten aufsetzen, bietet das verschiedene Vorteile:

Genauigkeit
RAG stellt einem LLM Quellen zur Verfügung, die es zitieren kann, damit Nutzende diese Behauptungen überprüfen können. Sie können eine RAG-Architektur auch so gestalten, dass sie mit „Ich weiß es nicht“ auf eine Frage antwortet, die von ihrem Wissen nicht abgedeckt ist. Da RAG insgesamt die Wahrscheinlichkeit reduziert, dass ein LLM falsche oder irreführende Information ausgibt, kann es das Vertrauen bei Nutzenden erhöhen.

Kosteneffizienz
Das Retraining und Fine Tuning von LLMs ist kostspielig und zeitaufwendig. Das Gleiche gilt, wenn Sie ein Basismodell von Grund auf entwickeln und mit domainspezifischen Information trainieren, etwa um einen Chatbot zu entwerfen. Mit RAG können Nutzende nicht nur neue Daten in ein LLM eingeben, sondern auch Informationsquellen austauschen oder aktualisieren, indem sie einfach nur ein Dokument oder eine Datei hochladen.

RAG kann auch Inferenzkosten reduzieren. LLM-Abfragen sind teuer. Bei einem lokalen Modell beanspruchen sie Ihre eigene Hardware, und wenn Sie einen externen Service über eine API (Application Programming Interface) nutzen, summiert sich der gemessene Verbrauch in Ihrer Rechnung. Anstatt ein ganzes Referenzdokument auf einmal an ein LLM zu senden, lassen sich mit RAG lediglich die relevanten Blöcke des Referenzmaterials senden, was die Größe von Abfragen reduziert und so die Effizienz verbessert.

Kontrolle für Entwicklungsteams
Verglichen mit traditionellen Fine Tuning-Methoden bietet RAG eine verständlichere und unkompliziertere Möglichkeit, Feedback zu erhalten, Troubleshooting durchzuführen und Probleme bei Anwendungen zu beheben. Der Hauptvorteil von RAG-Architekturen für Entwicklungsteams besteht darin, dass sie damit von domainspezifischen und aktualisierten Informationen profitieren.

Datenhoheit und Datenschutz
Vertrauliche Informationen für das Fine Tuning eines LLM-Tools zu nutzen, war bisher immer ein riskantes Unterfangen, da LLMs Informationen aus ihren Trainingsdaten preisgeben können. RAG bietet eine Lösung für diese datenschutzrechtlichen Bedenken, da damit vertrauliche Informationen vor Ort verbleiben können, selbst wenn sie für ein lokales LLM oder ein vertrauenswürdiges externes LLM genutzt werden. Eine RAG-Architektur kann auch so eingerichtet werden, dass der Abruf vertraulicher Informationen auf verschiedene Autorisierungsstufen beschränkt wird. Abhängig von ihrer Stufe bei der Sicherheitsüberprüfung können bestimmte Nutzende dann nur auf bestimmte Informationen zugreifen. 

RAG-Architekturen rufen Daten von externen Quellen ab, verarbeiten sie im Kontext eines LLMs und generieren dann basierend auf dem Mix an Quellen eine Antwort. Dieser Prozess umfasst 3 Hauptphasen: Datenvorbereitung, Abruf und Generierung.

Schritt 1: Vorbereitung der Daten (für den Abruf)

• Beschaffen und Laden von Dokumentation: Ermitteln und beschaffen Sie die Quelldokumente, die Sie mit dem LLM teilen wollen. Dabei sollten Sie sicherstellen, dass diese in einem für das LLM verständlichen Format gespeichert sind. Das sind oft Textdateien, Datenbanktabellen oder PDFs. Abgesehen vom Quellformat müssen die Dokumente außerdem in eine Textdatei konvertiert werden, bevor sie in die Vektordatenbank eingebettet werden können. Dieser Prozess ist auch bekannt als ETL (Extract, Transform, Load). ETL stellt sicher, dass die Rohdaten bereinigt und für die Anforderungen von Storage, Analyse und Machine Learning strukturiert sind.
   

• Transformieren: Durch „Text Splitting“ oder „Chunking“, also das Aufteilen des Texts in Blöcke, werden die Dokumente für den Datenabruf vorbereitet. Dabei werden die aktualisierten Dokumente geparst und basierend auf bestimmten Merkmalen in zusammengehörigen „Chunks“ oder Blöcken katalogisiert. So ist es etwa für das Modell möglicherweise einfacher, Dokumente zu durchsuchen und abzurufen, die nach Absätzen formatiert sind, als Dokumente mit Tabellen und Abbildungen.

  Chunking kann nach Aspekten wie Semantik, Sätze, Tokens, Formatierung, HTML-Zeichen oder Codetyp erfolgen. Viele Open Source-Frameworks können Unternehmen bei der Aufnahme von Dokumenten unterstützen, darunter LlamaIndex und LangChain.
   

• Einbetten: Einbettungen nutzen ein spezialisiertes ML-Modell (ein Vektoreinbettungsmodell), das Daten in numerische Vektoren umwandelt. Dadurch können Sie mathematische Operationen anwenden, um Gemeinsamkeiten und Unterschiede zwischen Daten zu bestimmen. Mithilfe von Einbettung können Sie Text (oder Bilder) in einen Vektor umwandeln, der die wesentliche Bedeutung des Inhalts erfasst und unwichtige Details aussondert. Beim Einbettungsprozess könnte einem Datenblock etwa ein numerischer Wert wie [1.2, -0.9, 0.3] zugeordnet werden, mit dem er dann in einem größeren System indiziert wird, der sogenannten Vektordatenbank.

  Die RAG-Architektur kann dank dieser numerischen Werte in der Vektordatenbank Assoziationen zwischen den Blöcken von Inhalten einfacher kennzeichnen und die Daten besser organisieren, um so das Abrufen zu optimieren. Ziel der Indexierung ist, die Vektoren so zu strukturieren, dass ähnliche Konzepte in benachbarten Koordinaten gespeichert werden. So würden etwa „Kaffee“ und „Tee“ eng beieinander positioniert werden. Auch „Heißgetränk“ wäre in der Nähe. Konzepte wie „Handy“ und „Fernseher“, die in keinem Zusammenhang dazu stehen, würden weiter weg positioniert werden. Die Distanz oder Nähe zwischen 2 Vektorpunkten hilft dem Modell bei der Entscheidung, welche Informationen es abrufen und in der Ausgabe für die Nutzeranfrage mit einbeziehen soll.
   

• Speichern: Die gebündelten Daten aus mehreren Quellen – die von Ihnen gewählten externen Dokumente und das LLM – werden in einem zentralen Repository gespeichert.
   

Schritt 2: Abruf

• Wenn die Daten in der Vektordatenbank katalogisiert sind, suchen Algorithmen darin nach Informationsschnipseln, die für die Nutzerabfrage relevant sind, und rufen diese dann ab. Frameworks wie LangChain unterstützen viele verschiedene Abrufalgorithmen, darunter solche, die auf Gemeinsamkeiten bei Daten basieren, wie etwa Semantik, Metadaten oder übergeordnete Dokumente.

  Wenn Endbenutzende in offenen Domains Informationen abfragen, stammen diese von indizierten Dokumenten im Internet. Der Zugriff darauf erfolgt dabei über die API der Informationsquelle. In geschlossenen Domains von Unternehmen hingegen, wo Informationen vertraulich behandelt und vor externen Quellen geschützt werden müssen, kann der Abruf über eine RAG-Architektur lokal erfolgen und so für mehr Sicherheit sorgen.
  
  Zum Schluss werden die abgerufenen Daten in den Prompt eingefügt und zur Verarbeitung an das LLM gesendet.
   

Schritt 3: Generierung

• Ausgabe: Den Nutzenden wird eine Antwort präsentiert. Wenn die RAG-Methode wie beabsichtigt funktioniert, erhalten die Nutzenden eine genaue Antwort auf Grundlage des als Quelle bereitgestellten Wissens.

Einstieg in KI-Frameworks mit Red Hat Consulting 

Bei der Entwicklung eines ML-Modells ist es wichtig, dass die Quelldokumente eine hohe Qualität aufweisen, da die Ausgabe nur so gut sein kann wie die Daten Ihrer Eingabe. Systeme, die verzerrte oder einseitige Informationen erzeugen, sind ein ernst zu nehmendes Problem für Unternehmen, die KI nutzen. Um solche Verzerrungseffekte in Ihrer Ausgabe zu vermeiden, sollten Sie unbedingt darauf achten, dass Ihre Quelldokumente keine voreingenommenen Informationen enthalten – also einseitige Darstellungen, die privilegierten Gruppen einen systematischen Vorteil und unprivilegierten Gruppen einen systematischen Nachteil verschaffen.

Stellen Sie beim Beschaffen von Daten für eine RAG-Architektur auch sicher, dass die Daten in Ihren Quelldokumenten ordnungsgemäß zitiert wurden und aktuell sind. Zusätzlich sollten menschliche Fachkräfte die Ausgabe bewerten, bevor Sie ein Modell für ein größeres Publikum bereitstellen. Und selbst nach dem Deployment des Modells in der Produktion sollte die Qualität der Ergebnisse weiterhin von solchen Fachkräften bewertet werden.

Sich die Unterschiede zwischen Datentrainingsmethoden und RAG-Architekturen deutlich zu machen, kann Ihnen dabei helfen, strategische Entscheidungen zum Einsatz der passenden KI-Ressource für Ihre Anforderungen zu treffen. Dabei ist es gut möglich, dass Sie gleichzeitig mehrere Methoden einsetzen. Im Folgenden sehen wir uns daher einige gängige Methoden und Prozesse für die Arbeit mit Daten an und vergleichen sie mit RAG.

RAG im Vergleich zu Prompt Engineering
Prompt Engineering ist die einfachste und am wenigsten technische Weise, mit einem LLM zu interagieren. Prompt Engineering beinhaltet das Schreiben von Anweisungen, das ein Modell in einer bestimmten Reihenfolge ausführen soll, damit bei einer Nutzeranfrage eine gewünschte Ausgabe generiert wird. Verglichen mit RAG erfordert Prompt Engineering weniger Daten, da es nur diejenigen nutzt, mit denen das Modell vorab trainiert wurde, und ist kostengünstiger, da es nur bestehende Tools und Modelle nutzt. Es ist jedoch nicht in der Lage, Ausgaben anhand von aktuellen oder sich ändernden Informationen zu generieren. Die Qualität der Ausgabe hängt außerdem von der Formulierung des Prompts ab, sodass es zu inkonsistenten Antworten kommen kann.

Wenn Sie nach einer nutzungsfreundlichen und kosteneffizienten Möglichkeit suchen, Informationen zu allgemeinen Themen ohne viele Einzelheiten zu extrahieren, kann Prompt Engineering für Sie die bessere Wahl sein.

RAG im Vergleich zu semantischer Suche
Semantik bezieht sich auf die wissenschaftliche Beschäftigung mit der Bedeutung von Wörtern. Die semantische Suche ist eine Methode zum Parsen von Daten, die den Zweck und Kontext einer Suchanfrage berücksichtigt.

Dabei werden NLP und Machine Learning genutzt, um die Anfrage zu entschlüsseln und Daten zu finden, die eine sinnvollere und genauere Antwort zu liefern als die, die ein simpler Keyword-Abgleich bereitstellen würde. Anders gesagt: Mit der semantischen Suche kann die Lücke geschlossen werden, die zwischen der Nutzeranfrage und den zur Generation einer Antwort verwendeten Daten besteht.

Wenn Sie beispielsweise eine Anfrage zu einem „Traumurlaub“ tippen, würde das Modell dank der semantischen Suche verstehen, dass Sie vermutlich Informationen zu einem „idealen“ Urlaub wollen. Statt eine Antwort zu Träumen zu liefern, würde das Modell Ihnen eine Antwort geben, die für Ihre Absicht mehr Relevanz hat – etwa ein All-inclusive-Paket für einen Strandurlaub.

Die semantische Suche ist ein Teil von RAG, und RAG nutzt sie während der Abfrage der Vektordatenbank, um Ergebnisse zu erzeugen, die sowohl für den Kontext richtig und genau als auch aktuell sind.

RAG im Vergleich zu Pretraining
Beim Pretraining handelt es sich um die Anfangsphase des LLM-Trainings, bei der das LLM von einem sehr großen Datensatz lernt und so ein grobes Verständnis der Sprache erlangt. Ähnlich dem menschlichen Gehirn, das Nervenbahnen aufbaut, wenn wir neue Dinge lernen, wird beim Pretraining ein neuronales Netzwerk in einem LLM erstellt, wenn dieses mit Daten trainiert wird.

Verglichen mit RAG ist das Pretraining eines LLMs teurer, kann länger dauern und mehr Rechenressourcen erfordern – etwa Tausende von GPUs. Wenn Sie Zugriff auf einen wirklich umfassenden Datensatz haben, der das trainierte Modell bedeutend beeinflussen kann, und Ihrem LLM ein integriertes, grundlegendes Verständnis bestimmter Themen oder Konzepte geben wollen, kann Pretraining die bessere Wahl für Sie sein.

RAG im Vergleich zu Fine Tuning
RAG-Architektur definiert, was ein LLM wissen muss. Fine Tuning hingegen definiert, wie das Modell reagieren soll. Fine Tuning beschreibt den Prozess, ein vortrainiertes LLM mit einem kleineren, gezielteren Datensatz weiterzutrainieren. Dadurch kann das Modell allgemeine Muster erlernen, die sich nicht mit der Zeit verändern.

Oberflächlich betrachtet scheinen sich RAG und Fine Tuning zu ähneln, es gibt aber Unterschiede. So sind beim Fine Tuning für die Modellerstellung beispielsweise sehr viele Daten und erhebliche Rechenressourcen erforderlich. RAG hingegen kann Informationen aus einem einzigen Dokument abrufen und bedarf sehr viel weniger Rechenressourcen. Darüber hinaus ist es viel zeitaufwendiger und schwieriger, Halluzinationen durch Fine Tuning eines LLMs zu reduzieren, während sich RAG in dieser Hinsicht als sehr effektiv erwiesen hat.

Oft ist es für ein Modell von Vorteil, sowohl Fine Tuning als auch RAG-Architektur zu nutzen. Wenn Sie jedoch bereits Zugriff auf eine enorm große Menge an Daten und Ressourcen haben und diese Daten sich relativ selten oder wenig ändern, oder wenn Sie an einer spezialisierten Aufgabe arbeiten, die eine individuellere Analyse als die des Frage-Antwort-Formats von RAG erfordert, kann Fine Tuning für Sie die bessere Wahl sein. 

Es gibt viele potenzielle Use Cases für eine RAG-Architektur. Im Folgenden beleuchten wir einige der gängigsten.

• Kundenservice: Durch das Programmieren eines Chatbots, der Kundenanfragen anhand von wichtigen Informationen aus einem bestimmten Dokument beantwortet, lassen sich Servicetickets schneller abwickeln, was auch zu einem effektiveren Kundensupportsystem führt.

• Generieren von Erkenntnissen: Mit RAG können Sie aus bereits vorhandenen Dokumenten lernen. Nutzen Sie eine RAG-Architektur, um ein LLM mit Jahresberichten, Marketingdokumenten, Social Media-Beiträgen, Kundenbewertungen, Umfrageergebnissen, Forschungsdokumenten oder anderen Materialien zu verknüpfen. Sie finden dann Antworten, die Ihnen dabei helfen, Ihre Ressourcen besser zu verstehen. Sie können RAG auch direkt mit Live-Datenquellen verbinden, etwa Social Media-Feeds, Websites oder andere häufig aktualisierte Quellen. Dadurch können Sie hilfreiche Antworten in Echtzeit generieren.

• Informationssysteme im Gesundheitswesen: RAG-Architekturen können Systeme verbessern, die medizinische Informationen oder Empfehlungen bereitstellen. RAG bietet die Möglichkeit, Aspekte wie die persönliche medizinische Vorgeschichte, Terminplanungsservices und neueste medizinische Forschung und Richtlinien zu prüfen, und kann so das Gesundheitswesen dabei unterstützen, Patientinnen und Patienten mit den erforderlichen Services und Supportstellen zu vernetzen.

Red Hat® OpenShift® AI ist eine flexible, skalierbare MLOps-Plattform (Machine Learning Operations) mit Tools zum Entwickeln, Bereitstellen und Verwalten von KI-gestützten Anwendungen. Auf Basis von Open Source-Technologien bietet es bewährte und konsistente Operations-Features, mit denen Teams experimentieren, Modelle bereitstellen und innovative Anwendungen präsentieren können.

OpenShift AI gibt Unternehmen die Möglichkeit, RAG-Architektur in ihre LLMOps (Large Language Model Operations) zu implementieren, da es die zugrunde liegende Workload-Infrastruktur bietet. Dazu gehören etwa der Zugriff auf eine Vektordatenbank, das LLM zum Erstellen von Einbettungen und die Abfragemechanismen, die zum Erzeugen von Ausgaben erforderlich sind.

Red Hat Consulting hat mit Red Hat OpenShift AI Pilot eine Lösung entwickelt, die Kunden den Einstieg in Red Hat OpenShift AI erleichtert und sich in ihre bestehenden Unternehmensservices integrieren lässt. Eine zentrale Plattform bietet Nutzenden Zugriff auf standardisierte Libraries und Tools, erhöhte Verfügbarkeit von Rechenleistung und ein besseres Onboarding von Data Scientists und anderen Nutzenden. Im Rahmen eines solchen Projekts setzen sich Expertinnen und Experten von Red Hat mit Ihren Teams zusammen, um die aktuellen Umgebungen und Ansätze zu bewerten und zukünftige Anforderungen zu ermitteln. Sie unterstützen die Teams dabei, Red Hat OpenShift AI bereitzustellen, zu verwalten und in andere Data Science-Tools des Unternehmens zu integrieren, um die Technologie optimal zu nutzen. Dabei ist es nicht erforderlich, dass Sie über funktionsfähige ML-Modelle für dieses Projekt verfügen. Red Hat unterstützt Sie unabhängig davon, an welchem Punkt Ihr Team bei der Einführung von Data Science gerade steht.

Für Organisationen, die über Modellexperimente hinaus Strategien für die Bereitstellung von Modellen in der Produktion entwickeln möchten, bietet Red Hat Consulting Services an, die Ihnen die nächsten Schritte erleichtern. Mit der MLOps Foundation-Initiative können Organisationen ihre Funktionen und Arbeitsmethoden im Bereich Data Science verbessern, um so ihre ML-Strategien voranzutreiben, wiederverwendbare Muster für einen produktionsfähigen Inferenzservice zu entwickeln und den gesamten ML-Modell-Lifecycle mit cloudnativen Tools und Architekturen zu automatisieren.

Mehr über MLOps Foundation erfahren