Was ist Retrieval Augmented Generation (RAG)?

Retrieval Augmented Generation liefert kontextbezogene, aktuelle Daten, um LLMs nützlich zu machen.

Die Retrieval Augmented Generation ist eine Technik, die die Einschränkungen von LLMs ausgleicht, indem sie ihnen Zugang zu kontextbezogenen, aktuellen Daten bietet. RAG-Implementierungen, die manchmal auch als RAG-Modelle oder -Muster bezeichnet werden, funktionieren durch die Kombination eines vortrainierten LLM mit einem Abfragesystem für leicht zugängliche Informationen. Das Abfragesystem ist dafür verantwortlich, relevante Informationen aus einer Wissensbibliothek, z. B. einer Datenbank, zu finden. Die RAG-Modelle ermöglichen es dem LLM bzw. dem Foundation Model, eine genauere Antwort mit aktuellem und relevantem Kontext für die jeweilige Aufgabe zu generieren.

RAG-Modelle haben sich für eine Vielzahl von wissensintensiven Aufgaben als effektiv erwiesen, darunter:

• Aufgaben der Spracherzeugung wie die umfassende und informative Beantwortung von Fragen oder die Generierung verschiedener kreativer Textformate von Textinhalten, wie Gedichte, Skripte, Musikstücke, E-Mails, Briefe usw.
• NLP-Aufgaben wie die Erstellung von Zusammenfassungen von Gesprächen, Audioaufnahmen und Videoanrufen.
• Aufgaben, die eine Klassifizierung erfordern, wie z.B. Cybersicherheit und Compliance oder Schlussfolgerungen für Dinge wie Geschäftsplanung

RAG kann auch verwendet werden, um einer generativen KI-gestützten Anwendung zu ermöglichen, einen gewissen Hintergrundzustand zu beobachten und ihre Generationen entsprechend anzupassen. Ein Beispiel wäre die Möglichkeit, Code auf der Grundlage des Codes zu schreiben, den ein Benutzer gerade schreibt. Weitere Beispiele sind:

• Anwendungskontext. Nehmen wir an, Sie bauen einen KI-gestützten Excel-Assistenten – es wäre hilfreich, wenn er die Namen Ihrer Blätter, den Dateinamen, die ausgewählten Zellbereiche usw. kennt. RAG wird diese „Hintergrundinformationen“ in die Eingabeaufforderung einspeisen, sodass der LLM seine Hilfe auf Ihr Blatt zuschneiden kann.
• Persönliche Daten (z. B. Agent Assist Chatbot). Nehmen wir an, Sie erstellen einen Kundensupport-Bot. Der Bot kann frühere Konversationen und die CRM-Historie dieses Kunden heranziehen, um die Konversation anzupassen (nicht nur die Begrüßung, sondern auch die Anpassung der Optionen usw.). Ohne diese Historie wird das LLM nicht in der Lage sein, die Personalisierung effektiv durchzuführen oder bei bestehenden Problemen zu helfen.
• Rohdaten, Metriken, tabellarische Daten (z. B.. CSV, Parquet, JSON usw.). RAG arbeitet nicht nur mit textlichem Kontext, sondern auch mit quantitativen Informationen. Ein Chatbot für Business Intelligence (BI) würde sicherlich RAG mit tabellarischen Rohdaten durchführen.
• Andere multimodale Datentypen wie Bilder, Video und Audio. Viele Modelle, wie z. B. DALL-E 2, können Text verwenden, um Bilder zu erstellen oder zu ergänzen. Umgekehrt können sie Bilder oder Videos in natürliche Sprache umwandeln. Durch den Kontext zu bestimmten Bildern oder Designfaktoren kann RAG GenAI-Apps leistungsfähiger machen, wenn es darum geht, Marketing-Assets zu erstellen oder Zusammenfassungen und Übersetzungen von Videos zu generieren, die sehr spezifische, kontextlastige Informationen enthalten.

Die Retrieval Augmented Generation ist auch für Daten nützlich, die nicht als Trainingsdaten verwendet werden können

• Hochvolatile/zeitkritische Daten: Daten wie Börsennachrichten verlieren schnell ihren Wert. Daher ist es sinnvoller, die LLM nur mit den neuesten Informationen zu erweitern, idealerweise bei jeder Anfrage während der Inferenzzeit – im Gegensatz zu dem Versuch, die LLMs mit diesem Datenkorpus neu zu trainieren.* Sensible Daten: Viele der leistungsstärksten LLMs (wie GPT von OpenAI oder Claude von Anthropic) sind nutzungsabhängig und gehören diesen Unternehmen. Die Verwendung persönlicher, sensibler Informationen in den Trainingsdaten zur Feinabstimmung dieser LLMS kann zu privaten Datenlecks führen und ist potenziell gefährlich. Daher ist die RAG manchmal die einzige sichere Option.

Primäre Anwendungsfälle von RAG.

Ausgehend von den obigen Ausführungen sind die am besten geeigneten Anwendungsfälle für RAG folgende:

• Beantwortung von Fragen über jegliches extrinsische Domänenwissen, wie z. B. unternehmensspezifische Dokumentationen und Wissensdatenbanken, operative Systeme, Back-Office-Systeme usw.: Per Definition erfordert die Verwendung von LLMs mit Daten außerhalb der LLM-Wissensabgrenzung eine RAG. Hinzu kommt, dass Fragen und Antworten über hochgradig zeitkritische und sich schnell ändernde Kontexte – Daten, die schnell veralten – unmöglich durch Feinabstimmung in LLMs integriert werden können.
• Zur Verringerung von Halluzinationen und Erhöhung der Faktengenauigkeit: Im Allgemeinen kann RAG die Faktengenauigkeit sogar bei der Beantwortung von Fragen zu Informationen aus dem LLM-Trainingskorpus verbessern. Das liegt daran, dass RAG die Aufgabe zum Beantworten von Fragen in eine „Open-Book-Quiz“-Aufgabe umwandelt, die einfacher ist als eine ungebundene Frage-Antwort-Aufgabe.* Personalisierung ist ein klassischer Anwendungsfall für RAG. In diesem Fall wird die Eingabeaufforderung mit Benutzerdaten ergänzt. Optional können alle PII-Daten vor der Eingabe in die Eingabeaufforderung gesäubert werden.
• Kontextbezogene Antworten (innerhalb von Co-Pilots). Wie der Github Co-Pilot zeigt, können LLM-Generationen relevanter sein, wenn sie auf dem Zustand der Anwendung basieren (das aktuelle Dokument, die Metadaten des Gesamtprojekts, die URL oder Seite, die gerade besucht wird, usw.)
• Jede GenAI-App, die mit sehr domänenspezifischen Kontexten arbeitet. Beispiele sind das Gesundheitswesen, Finanzdienstleistungen, juristische Ermittlungen sowie Wissenschaft und Technik. In solchen Bereichen sind die Trainingsdaten oft spärlich und daher ist RAG für die Entwicklung nützlicher GenAI-Apps unerlässlich.

Warum eine Retrieval Augmented Generation? Was sind die Alternativen zu RAG bei der Entwicklung von generativen KI-Anwendungen?

Beim Erstellen generativer KI-Anwendungen gibt es eine Reihe von Alternativen zu RAG. Einige der beliebtesten Alternativen sind:

• Trainieren Sie Ihr eigenes LLM: Es könnte zwar gerechtfertigt sein, Ihr eigenes LLM zu trainieren, aber es wird wahrscheinlich viel zu teuer und zeitaufwendig sein, um etwas zu erstellen, das mit den vielen verfügbaren kommerziellen (OpenAI GPTs) und Open-Source-Modellen (Meta's LLaMa) konkurrenzfähig ist.
• Feinabstimmung eines bestehenden LLM: eine Technik, bei der ein vortrainiertes LLM auf einem kleineren Datensatz mit aufgabenspezifischen Daten neu trainiert wird. Die Feinabstimmung kann effektiv sein, um die Leistung eines LLM bei einer bestimmten Aufgabe zu verbessern, aber sie kann auch zeitaufwändig und teuer sein. Die Feinabstimmung endet nie – wenn neue Daten verfügbar werden, muss das Modell erneut feinabgestimmt werden. Wenn Ihre GenAI-App Zugriff auf Live-Betriebsdaten benötigt, ist eine Feinabstimmung nicht sinnvoll.

Warum eine Retrieval Augmented Generation statt einer Feinabstimmung eines LLM?

• Die Feinabstimmung ist eine weitere Möglichkeit, LLMs mit „benutzerdefinierten Daten“ zu verwenden, aber im Gegensatz zur RAG, bei der man einem LLM ein Quiz mit offenen Büchern gibt, ist die Feinabstimmung so, als würde man ihm völlig neue Erinnerungen oder eine Lobotomie verpassen. Bei der Feinabstimmung wird das Modell so angepasst, dass Sie seine Leistung, sein Verhalten, sein Kostenprofil usw. ändern können. Das ist zeit- und ressourcenintensiv und eignet sich im Allgemeinen nicht, um LLMs auf einen bestimmten Kontext zu gründen. Besonders ungeeignet ist es für operative Live-Daten aus Ihrem Unternehmen.

Die Kernbausteine einer grundlegenden RAG-Architektur.

Eine grundlegende Retrieval Augmented Generation Architektur besteht aus drei Hauptkomponenten:

• Ein vortrainiertes LLM: Das LLM ist für die Generierung von Text, Bildern, Audio und Video verantwortlich.
• Vektorsuche (oder semantische Suche): Das Retrievalsystem ist dafür verantwortlich, relevante Informationen aus einer Wissensdatenbank zu finden, die sich außerhalb des LLM befindet. Es gibt eine Vielzahl von Allzweckdatenbanken oder Einzweck-Vektordatenbanken, in denen Vektoreinbettungen gespeichert werden können und die eine ungefähre Suche nach dem nächsten Nachbarn ermöglichen. Die Vektorsuche ist das A und O, wenn es darum geht, proprietäres Wissen, das einem Allzweck-LLM zur Verfügung gestellt wird, präzise zu erweitern.
• Vektoreinbettungen: Manchmal einfach als „Vektoren“ oder „Einbettungen“ bezeichnet, sind Vektoreinbettungen im Wesentlichen numerische Darstellungen, die die semantische oder zugrundeliegende Bedeutung eines Teils der Daten erfassen. Im Allgemeinen handelt es sich dabei um ein Array von Fließkommazahlen, wobei jede Fließkommazahl eine einzelne Dimension der numerischen Darstellungen repräsentiert.
• Orchestrierung: Der Fusionsmechanismus ist dafür verantwortlich, die Ausgabe des LLM mit den Informationen aus dem Abfragesystem zu kombinieren, um die endgültige Ausgabe zu generieren.

Das folgende Diagramm zeigt eine grundlegende RAG-Architektur mit demselben Einzelhandelsbeispiel wie zuvor:

Um dieses Fehlen des domänenspezifischen Kontexts zu umgehen, wird die Retrieval Augmented Generation wie folgt durchgeführt:

• Wir holen die relevantesten Produktbeschreibungen aus einer Datenbank (oft eine Datenbank mit Vektorsuche), die den aktuellsten Produktkatalog enthält
• Dann fügen wir diese Beschreibungen in die LLM-Eingabeaufforderung ein (augmentieren)
• Abschließend weisen wir das LLM an, bei der Beantwortung der Frage auf diese aktuellen Produktinformationen zu „verweisen“

Drei Dinge, die Sie beachten sollten:

• Die Retrieval Augmented Generation ist eine reine Inferenzzeit-Technik (kein erneutes Training erforderlich). Die obigen Schritte 1 bis 3 erfolgen alle in der Inferenzzeit. Es sind keine Änderungen am Modell erforderlich (z. B. Ändern der Modellgewichte).
• Die Retrieval Augmented Generation ist gut geeignet für Echtzeit-Anpassungen von LLM-Generationen. Da kein erneutes Training erforderlich ist und alles über kontextinternes Lernen erfolgt, ist die RAG-basierte Inferenz schnell (Latenzzeit unter 100 ms) und eignet sich gut für den Einsatz in operativen Echtzeit-Anwendungen.
• Die Retrieval Augmented Generation macht LLM-Generationen genauer und nützlicher. Jedes Mal, wenn sich der Kontext ändert, wird der LLM eine andere Antwort erzeugen. Auf diese Weise macht RAG LLM-Generationen von dem Kontext abhängig, der abgerufen wurde.

RAG ist einfach gehalten, mit minimaler Komplexität, aber dennoch hochentwickelt, um in großem Umfang zuverlässig zu funktionieren.

Um eine leistungsstarke und dennoch minimal komplexe RAG-Architektur zu erreichen, müssen Sie zunächst die richtigen Systeme auswählen. Bei der Auswahl der Systeme oder Technologien für eine RAG-Implementierung ist es wichtig, Systeme oder Systeme zu wählen, die Folgendes erreichen können:

• Unterstützen Sie neue Anforderungen an Vektordaten, ohne Ihren IT-Betrieb mit enormer Ausdehnung, Kosten und Komplexität zu belasten.
• Stellen Sie sicher, dass die erstellten generativen KI-Erlebnisse Zugang zu Live-Daten mit minimaler Latenzzeit haben.
• Sie sind flexibel genug, um neue Daten- und Anwendungsanforderungen zu erfüllen und ermöglichen es den Entwicklungsteams, dabei agil zu bleiben.
• Rüsten Sie Entwicklerteams am besten so aus, dass sie das gesamte KI-Ökosystem auf ihre Daten anwenden können, nicht umgekehrt.

Die Optionen reichen von Einzweck-Vektordatenbanken über Dokument- und relationale Datenbanken mit nativen Vektorfunktionen bis hin zu Data Warehouses und Lakehouses. Einzweck-Vektordatenbanken führen jedoch sofort zu einer größeren Ausbreitung und Komplexität. Data Warehouses und Lakehouses sind von Natur aus für langwierige analytische Abfragen historischer Daten ausgelegt, im Gegensatz zu den Anforderungen der GenAI-Apps, die RAG mit hohen Datenmengen, geringer Latenz und frischen Daten versorgt. Außerdem bringen relationale Datenbanken starre Schemata mit, die die Flexibilität beim Hinzufügen neuer Daten und Anwendungsanforderungen einschränken. Damit bleiben nur noch Dokumentendatenbanken mit nativen oder integrierten Vektorfunktionen übrig. Insbesondere basiert MongoDB auf dem flexiblen Dokumentenmodell und verfügt über eine native Vektorsuche. Damit ist MongoDB nicht nur eine Vektordatenbank für RAG, sondern auch die branchenführende Datenbank für jede moderne Anwendung.

Bringen Sie die Leistungsfähigkeit von LLMs auf die nächste Stufe mit zusätzlichen Funktionen in Ihrer RAG-Implementierung.

Zusätzlich zu den Kernkomponenten gibt es eine Reihe von zusätzlichen Funktionen, die einer RAG-Implementierung hinzugefügt werden können, um die Leistungsfähigkeit von LLMs auf das nächste Level zu heben. Zu diesen zusätzlichen Funktionen gehören:

• Multimodalität: Multimodale RAG-Modelle können Texte generieren, die sowohl auf Text- als auch auf Nicht-Text-Daten basieren, wie z. B. Bilder, Videos und Audio. Da diese multimodalen Daten Seite an Seite mit den operativen Daten gespeichert werden, lässt sich die RAG-Implementierung einfacher gestalten und managen.
• Definition zusätzlicher Filter in der Vektorsuchabfrage: Die Möglichkeit, Schlüsselwortsuche, räumliche Suche sowie Punkt- und Bereichsfilter zur gleichen Vektorabfrage hinzuzufügen, kann die Genauigkeit und Geschwindigkeit des dem LLM bereitgestellten Kontexts erhöhen.
• Domänenspezifität: Domänenspezifische RAG-Modelle können auf Daten aus einer bestimmten Domäne trainiert werden, z. B. dem Gesundheitswesen oder dem Finanzwesen. Dadurch kann das RAG-Modell genauere und relevantere Texte für diese Domäne generieren.

Sicherstellung, dass Ihre generative KI-gestützte Anwendung sicher, leistungsfähig, zuverlässig und skalierbar ist, wenn sie global eingesetzt wird.

Es gibt eine Reihe von Maßnahmen, mit denen sichergestellt werden kann, dass eine GenAI-gestützte Anwendung, die mit einem RAG erstellt wurde, sicher, leistungsfähig, zuverlässig und skalierbar ist, wenn sie global eingesetzt wird. Einige dieser Dinge sind:

• Verwenden Sie eine Plattform, die sicher ist und über die richtigen Data Governance-Funktionen verfügt: Data Governance ist ein weit gefasster Begriff, der alles umfasst, was Sie tun, um sicherzustellen, dass die Daten sicher, privat, genau, verfügbar und nutzbar sind. Dazu gehören die Prozesse, Richtlinien, Maßnahmen, Technologien, Tools und Kontrollen rund um den Lebenszyklus der Daten. Daher sollte die Plattform standardmäßig sicher sein, über eine Ende-zu-Ende-Verschlüsselung verfügen und Compliance auf höchstem Niveau erreicht haben.
• Verwenden Sie eine cloudbasierte Plattform: Zusätzlich zu den Sicherheits- und Skalierbarkeitsfunktionen, die Cloud-basierte Plattformen bieten, gehören die führenden Cloud-Anbieter zu den führenden Innovatoren für KI-Infrastrukturen. Wenn Sie sich für eine cloudunabhängige Plattform entscheiden, können Ihre Teams die Vorteile der KI-Innovationen nutzen, wo auch immer sie entstehen.
• Verwenden Sie eine Plattform, die die Infrastruktur für Vektor-Workloads von der anderen Datenbankinfrastruktur isolieren kann: Es ist wichtig, dass reguläre OLTP-Workloads und Vektor-Workloads die Infrastruktur nicht gemeinsam nutzen, damit die beiden Workloads auf der jeweils für sie optimierten Hardware ausgeführt werden können und nicht um Ressourcen konkurrieren, während sie dennoch die gleichen Daten nutzen können.
• Verwenden Sie eine Plattform, die sich in großem Maßstab bewährt hat: Es ist eine Sache, wenn ein Anbieter sagt, dass er skalieren kann, aber hat er auch eine Geschichte und eine Erfolgsbilanz mit globalen Unternehmenskunden? Verfügt es über unternehmenskritische Fehlertoleranz und die Fähigkeit zur horizontalen Skalierung, und kann es dies anhand von Kundenbeispielen nachweisen?

Wenn Sie diese Tipps befolgen, können Sie mit RAG-Architekturen GenAI-gestützte Anwendungen erstellen, die sicher, performant, zuverlässig und skalierbar sind.

Mit der Einführung von Atlas Vector Search bietet MongoDB, die führende Plattform für Entwicklerdaten, Teams eine Vektordatenbank, die den Aufbau anspruchsvoller, leistungsfähiger und skalierbarer RAG-Architekturen ermöglicht. Und das alles unter Beibehaltung eines Höchstmaßes an Sicherheit und Cloud-Agnostizismus und – was am wichtigsten ist – ohne zusätzliche Komplexität und unnötige Kosten.