Retrieval-Augmented Generative AI: Teil 1 - Funktionsweise
Die Bausteine von RAG-Chatbots
Retrieval-Augmented Generative AI (RAG) ermöglicht seit einiger Zeit den Bau einer neuen Generation von Chatbots, welche in natürlicher Sprache Auskunft über eigene, also firmeninterne Dokumente geben können. Auf diese Weise lässt sich das generische Wissen von Large Language Models (wie etwa die berühmten GPT-Modelle von OpenAI) kombinieren mit der spezifischen, firmeneigenen Wissensbasis. Die Technologie ist vielversprechend, und dementsprechend spielen viele Unternehmen derzeit mit dem Gedanken, eigene RAG-Chatbots zu entwickeln. Im Teil 2 dieses Blog-Beitrags wird es um die Frage gehen, wie mögliche Anwendungsfelder im Unternehmen identifiziert werden können. Dazu ist es jedoch erstmal hilfreich zu verstehen, wie ein RAG-Chatbot überhaupt funktioniert.
Etwas vereinfacht bestehen RAG-Chatbots aus einer Kombination von drei grundlegenden Technologien:
Um einen RAG-Chatbot zu bauen, gilt es in einem ersten Schritt erst einmal, alle Textdaten an einem zentralen Ort zu sammeln, auf welcher der RAG-Chatbot Zugriff haben soll, und dort die Daten so aufzubereiten, dass sie indexiert werden können. Oft sind die relevanten Daten an verschiedenen Orten verstreut abgelegt, beispielsweise in Wikis, Dokumenten- oder CMS-Systemen, was erstmal eine Investition in Datenintegration notwendig macht.
Bereits beim Bereitstellen der Daten gilt es einige Anfängerfehler zu vermeiden, beispielsweise sollten für produktive Anwendungen idealerweise die Extraktion, das Laden und die Aufbereitung der Daten wiederholbar gestaltet sein, so dass zukünftige Updates in der Datenbasis auch unkompliziert in den RAG-Chatbot einfliessen können.
Indexierung der Daten in einer semantischen Suchmaschine
Wenn die Daten zentral abgelegt und aufbereitet sind, können sie indexiert werden. Dazu werden sie mit Hilfe eines speziellen LLM-basierten Vektormodells in hochdimensionale mathematische Vektoren übersetzt. Die Vektorrepräsentation enthält in kondensierter Form die inhaltliche Bedeutung des Textes. Dieser Vorgang ist verhältnismässig rechenaufwendig und kann eine gewisse Zeit in Anspruch nehmen. Anschliessend werden die Vektoren in einer speziellen Vektordatenbank abgelegt. Vektordatenbanken erlauben die effiziente Suche auf einer potentiell sehr grossen Anzahl an Vektoren. Häufig macht es jedoch wenig Sinn, riesige Mengen Text zu indexieren. Die Erfahrung zeigt, dass RAG-Chatbots besonders dann gut funktionieren, wenn das in den indexierten Dokumenten vorhandene Wissen in natürlicher Sprache dargestellt und inhaltlich bzw. thematisch deutlich voneinander abgrenzbar ist, wie das etwa bei Wikipedia-Einträgen der Fall ist.
Zu beachten ist, dass während der Indexierung das zugrundeliegende LLM nicht in der Lage ist, firmeneigene Abkürzungen oder Bezeichnungen korrekt zu interpretieren, die ausserhalb der Organisation nicht vorkommen. Eine Normalisierung von Begriffen oder Anreicherung mit zusätzlichen Informationen der indexierten Dokumente kann hier Abhilfe schaffen, erhöht jedoch den Aufwand. Ebenfalls nicht besonders gut funktioniert RAG bei standardisierten Dokumententypen wie Formularen, in welchen sich die Dokumente bloss durch wenige Felder voneinander unterscheiden, ein grösserer Teil des Dokumenteninhalts jedoch immer identisch bleibt. In solchen Situationen empfehlen sich andere Ansätze. Auch für Text in Tabellen ist RAG eher weniger geeignet, da der RAG-Chatbot fundamental kein Verständnis einer tabellarischen Darstellung von Daten hat. Und nicht zuletzt ist RAG aus verschiedenen Gründen ohne weitergehende Modifikationen eher weniger geeignet zur Durchforstung von sehr grossen Mengen an Dokumenten.
Suchabfragen mittels der semantischen Suchmaschine durchführen
Wenn die Dokumente indexiert wurden, können nun Abfragen in natürlicher Sprache an die Vektordatenbank geschickt werden. Jede Anfrage wird grundsätzlich gleich behandelt wie zuvor die indexierten Dokumente. Zuerst wird die Anfrage mit dem gleichen Algorithmus wie während der Indexierungsphase in einen mathematischen Vektor verwandelt. Die Vektordatenbank vergleicht den Abfrage-Vektor gegen die bereits vorhandenen Dokumenten-Vektoren und sucht nach den zum Abfrage-Vektor "ähnlichsten" Dokumenten-Vektoren. Da die Vektoren den Inhalt der indexierten Dokumente in kondensierter Form repräsentieren, impliziert eine Ähnlichkeit zwischen Vektoren thematisch ähnliche Inhalte. Thematisch weit auseinanderliegende Vektoren deuten auf thematisch wenig verwandte Inhalte zwischen Abfrage und Dokument hin. Formal gesprochen handelt es sich um die geometrische Winkelbeziehung zwischen dem Abfrage-Vektor und einem Dokumenten-Vektor im hochdimensionalen Raum. Ein enger Winkel weist auf eine hohe Ähnlichkeit hin, ein weiter Winkel auf eine geringe Ähnlichkeit.
Die Vektordatenbank gibt nun jene Dokumente zurück, die zum Abfragevektor am ähnlichsten erscheinen. In einer traditionellen Textsuchmaschine ist das Vorhandensein eines Suchbegriffs eindeutig definiert: mal abgesehen von verschiedenen Schreibweisen, Konjugation von Verben oder Deklination von Nomen ist ein Suchbegriff entweder in einem Dokument vorhanden oder eben nicht. Es werden in einer herkömmlichen Suchmaschine folglich nur exakt jene Dokumente zurückgegeben, die den Kriterien der Suchabfrage genügen. Ganz anders in einer Vektordatenbank! Hier ist Ähnlichkeit nur noch relativ definiert. Übersetzt in Begriffe der sprachlichen Semantik heisst das: Ähnlich sind immer alle Dokumente zur Abfrage, manche mehr, manche weniger. Bei einer Suchanfrage zum Begriff "Hund" wäre wohl intuitiv zu erwarten, dass ein Dokument, in dem es um Katzenhaltung geht, zwar nicht perfekt passend aber doch einigermassen relevant ist. Was aber, wenn ein Dokument die Begriffe "Debatte" oder "Vernehmlassung" enthält? Soll dieses Dokument nun für die (zugegebenermassen wenig aussagekräftige) Suchabfrage "Hund" zurückgegeben werden? Das Beispiel zeigt die Grenzen von semantischer Suche. Semantische Suchmaschinen bzw. Vektordatenbanken finden immer irgendwelche Dokumente zu einer Abfrage, auch wenn sie aus Sicht eines menschlichen Nutzers wenig auf die Abfrage passen. Es ist also nötig, bei Suchabfragen eine künstliche Grenze zu ziehen: nach n gefundenen Suchresultaten sollen nicht noch weitere zurückgegeben werden. In die Antwort, die der RAG-Chatbot dem Nutzer später zurückgibt, fliesst ausschliesslich Wissen aus diesen n gefundenen Suchresultaten mit ein, alle weiteren Suchresultate werden notwendigerweise ignoriert.
Der RAG-Chatbot erhält nun von der Vektordatenbank die gefundenen – hoffentlich auf die Suchabfrage passenden – n Dokumente zurück. Theoretisch könnte der RAG-Chatbot jetzt einfach diese Liste mit Suchresultaten zurückgeben, und das Suchen nach der richtigen Antwort dem Benutzer überlassen. Dieser Ansatz entspräche einer semantischen Suchmaschine. Manchmal ist das genug. Auf diese Weise können auch die berüchtigten Halluzinationen verhindert werden: die semantische Suchmaschine findet zwar vielleicht nicht immer alle theoretisch relevanten Dokumente, sie dichtet jedoch auch nichts zu den Resultaten hinzu.
Wie ein RAG-Chatbot über semantische Suche hinausgeht
Oft ist jedoch vom Nutzer mehr Komfort gewünscht. Das für die Suchabfrage relevante Wissen ist nicht selten über die ersten, wenigen Dokumente verstreut. Falls die Dokumente etwas länger sind, zwingt eine blosse Liste von Suchresultaten den Nutzer immer noch, sich erst durch all die zurückgegebenen Dokumente durchzulesen. RAG-Chatbots gehen deshalb einen Schritt weiter. Die zurückgegebenen Dokumente werden in einem Zusatzschritt alle noch einmal an ein LLM geschickt mit der Bitte eine Zusammenfassung zu erzeugen, die die Suchabfrage beantwortet. Im gesamten Suchprozess ist dieser Schritt der zeitaufwändigste, weil er nur bedingt bzw. gar nicht parallelisiert werden kann – was besonders ins Gewicht fällt, wenn das LLM viel Text sichten muss. Weiter können hier Probleme auftreten, wenn die technisch zulässige Menge an zu prozessierenden Daten überschritten wird. Heutige kommerzielle Angebote ermöglichen zwischen ca. 8k und 200k Input- plus Output-Tokens pro Abfrage (ein «Token» entspricht grob gesagt einer Silbe; Gerüchten zufolge experimentieren Technologieanbieter wie Google bereits mit Abfragen bis zu 1000k Tokens). Wird diese Grenze überschritten, so ist das Verhalten des LLM-Services nicht eindeutig definiert, und es können ohne Warnung zu verarbeitende Daten abgeschnitten werden, oder eine laufende Anfrage abgebrochen werden. Diese Situationen sind oft schwer im voraus zu erkennen, da es ohne weiteren Zusatzaufwand schwer abzuschätzen ist, wie viele Input- und Output-Tokens eine einzelne Abfrage am Ende konsumiert.
Im Erfolgsfall schickt jedoch am Ende das LLM eine Antwort hoher Qualität zurück zum Nutzer, welcher die relevanten Punkte aus den gefundenen Dokumenten in einem kurzen Text zusammenfasst. Meistens ist es auch gewünscht, dass die Antworten mit Referenzen auf die originalen (indexierten) Dokumente hinterlegt sind, so dass ein Benutzer auf Wunsch die Quelle selbst studieren kann.
Damit ist aber noch keine echte Konversation möglich, sondern nur einzelne Abfragen. Nachfragen sind nicht möglich. Anders ausgedrückt vergisst ein solcher RAG-Chatbot stets sofort wieder, was er gerade eben gesagt hat. Je nach Situation kann es gewünscht sein, den Chatbot um eine Memory-Funktion zu erweitern. Das Chatbot-Memory garantiert, dass der RAG-Chatbot sich erinnert, was er zuvor in der Konversation gesagt hat, damit sowohl der Benutzer als auch der RAG-Chatbot darauf Bezug nehmen können. Normalerweise wird ein Chatbot-Memory nicht von Grund auf selbst implementiert, sondern es werden bestehende Libraries wie etwa Langchain oder Haystack zu Hilfe genommen. Dazu werden die Abfragen des Benutzers angereichert mit einer Historie oder den wichtigsten Punkten der letzten ausgetauschten Nachrichten. Damit diese Historie nicht immer länger wird, muss sie regelmässig gekürzt werden, wofür es verschiedene Implementierungs-Strategien gibt. Was aus der Historie verschwunden ist, wird vom Chatbot nicht mehr erinnert. Da meist die Dialoge mit dem RAG-Chatbot nur eine kurze Historie haben, ist dies im praktischen Gebrauch eher selten ein Problem. Allerdings gibt auch hier das LLM gewisse Grenzen vor: eine längere Historie verlängert die Verarbeitungszeiten auf Seiten des LLMs und verkürzt die Anzahl Tokens, die aus den gefundenen Dokumenten weiterverarbeitet werden kann.
Erweiterungsmöglichkeiten
Es gibt verschiedene Möglichkeiten, RAG-Chatbots zu erweitern. Beispielsweise könnte mittels text-to-sql der Versuch unternommen werden, auch relationale Datenbanken mit einzubinden. Benutzer stellen dann natürlichsprachige Abfragen, die vom LLM in SQL übersetzt werden, welches auf einer Datenbank ausgeführt wird. Offensichtlich gibt es dabei einige Fragen zu klären, beispielsweise was passieren soll, wenn das erzeugte SQL ungültig ist, oder Fragen um die Sicherheit der Datenbank.
Noch weiter gehen LLM-Agenten, welche versuchen, teil- oder vollautonom alleine oder im Verbund gewisse Arbeitsschritte selbständig auszuführen. Die Adoption von solchen Agenten steht jedoch noch eher am Anfang.
Nachdem nun die Grundfunktionsweise von RAG verstanden ist, wird es im zweiten Beitrag darum gehen, wie Anwendungsmöglichkeiten von RAG (-Chatbots) im eigenen Unternehmen identifiziert werden können.
Im Loop bleiben: www.acrea.com/newsletter