Webinar: Agent-RAG

In meinem letzten Webinar habe ich gemeinsam mit meinem Kollegen Martin König und unserem Moderator Stefan Heberling darüber gesprochen, wie Retrieval Augmented Generation (RAG) in der Praxis funktioniert. Wir wollten zeigen, welche technischen Details sich hinter diesem Ansatz verbergen und warum er für viele Anwendungen so wertvoll ist. Dabei ging es vor allem um das Zusammenspiel zwischen verschiedenen Pipelines, die dafür sorgen, dass ein KI-Modell firmeneigene oder öffentlich verfügbare Daten heranziehen und intelligent nutzen kann.

Martin hat das Webinar damit eröffnet, dass wir diesmal mehr Fachbegriffe als sonst verwenden würden und uns deshalb eingangs um grundlegende Erklärungen kümmern. Das betraf vor allem das Large Language Model (LLM), das im Zentrum eines jeden KI-Agenten steht, und den Begriff des System Prompts, der festlegt, wie die Antworten des Modells formuliert werden. Außerdem machten wir klar, dass der Query – also die Frage des Nutzers – und der zusätzliche Kontext aus einer Wissensdatenbank zusammenspielen müssen, um eine umfassende Antwort zu liefern.

“Ein Large Language Model ist das Herzstück eines KI-Agenten: Es erzeugt fortlaufenden Text, indem es das bereits Gesagte sinnvoll ergänzt und damit die Grundlage für jede generative Anwendung bildet.”

Überblick über die Pipelines

Der Kern von RAG lässt sich grob in drei Abschnitte aufteilen. Diese sogenannten Pipelines bestimmen, wie Informationen aufgenommen, vorbereitet und schließlich genutzt werden. In der ersten Pipeline, der Ingestion Pipeline, geht es darum, Dokumente aus unterschiedlichen Quellen auszuwählen, zu bereinigen und zu strukturieren. Anschließend werden diese Daten in einer Wissensdatenbank abgelegt, die sie später schnell wieder verfügbar machen kann.

Die zweite Pipeline, die Query Pipeline, kümmert sich um alles, was beim Stellen einer Benutzerfrage passiert. Dabei wird untersucht, was der Nutzer überhaupt will und wie man seine Anfrage im Zweifel umformulieren kann, um relevantere Treffer zu erzielen. In der dritten Pipeline, der Retrieval Pipeline, werden schließlich die passenden Antworten aus einer Vektordatenbank gesucht und zusammen mit der ursprünglichen Frage zu einem flüssigen, verständlichen Text verarbeitet.

Die Ingestion Pipeline

Der erste Schritt in einem RAG-System umfasst das Einlesen und Verarbeiten von Daten, bevor sie in eine Wissensdatenbank wandern. Bei diesem Vorgang wird entschieden, welche Dokumente man überhaupt einbeziehen möchte und ob möglicherweise Zugriffsrechte zu beachten sind. Falls interne Richtlinien verbieten, dass bestimmte Dateien mit einem KI-System geteilt werden, kann man diesen Content frühzeitig aussortieren.

Sobald die richtigen Daten ausgewählt sind, geht es an ihre Aufteilung in kleine Abschnitte. Dieser Vorgang wird meist als Chunking bezeichnet und hat den Zweck, das Wissen so zu zerteilen, dass das Modell später genau die richtigen Ausschnitte abrufen kann. Ein einfaches Verfahren ist das Aufteilen in feste Länge, etwa alle paar tausend Wörter. Oft ist es jedoch sinnvoll, die Struktur eines Textes beizubehalten und an Überschriften oder thematischen Abschnitten zu schneiden. Dadurch wird sichergestellt, dass ein Abschnitt in sich schlüssig bleibt und sich nicht mit ganz anderen Themen vermischt.

“Ein perfekt gemachter Textsplitter teilt das Dokument so, wie wir es als Menschen ebenfalls tun würden: nach Überschriften, nach zusammenhängenden Absätzen oder nach klar abgegrenzten Textboxen.”

Im Webinar haben wir auch auf das Problem hingewiesen, dass Standardwerkzeuge oft nicht wissen, welche Elemente eines Dokuments überflüssig sind. Sie übernehmen manchmal Navigationsmenüs, Links und Bildunterschriften an unpassenden Stellen. Dadurch entstehen Fragmente, die nur bedingt nützlich sind. Eine maßgeschneiderte Lösung, die genau die zu verwendenden Inhalte erkennt und sinnvoll in Chunks aufteilt, kann hier Abhilfe schaffen.

Sobald die Abschnitte erstellt und bereinigt sind, lässt sich jeder Einzelne mithilfe eines Sprachmodells in einen numerischen Vektor verwandeln. Diese Vektoren liegen später in der Wissensdatenbank und ermöglichen das semantische Suchen. Metadaten wie Kategorien, Zugriffsrechte oder Zeitstempel können den Inhalt ergänzen. Das erleichtert den späteren Umgang mit verschiedenen Dokumentversionen und verhindert, dass vertrauliche Informationen an unbefugte Benutzer gelangen.

Die Query Pipeline

Sobald ein Nutzer eine Frage stellt, tritt die Query Pipeline in Aktion. Ein wichtiges Thema ist dabei die Intent Recognition. Wir wollen verstehen, was hinter der Frage steckt. Wurde ein Dokument hochgeladen und soll einfach nur zusammengefasst werden? Oder möchte jemand nach Quellen suchen, die im Firmennetz liegen? Eine einfache Möglichkeit besteht darin, ein Sprachmodell mit Beispielsätzen zu füttern und es entscheiden zu lassen, in welche Kategorie die Anfrage fällt. Komplexere Szenarien können mithilfe eines eigenen Klassifizierungsmodells abgedeckt werden.

In manchen Fällen ist es zudem sinnvoll, den Query – also die eigentliche Benutzerfrage – umzuschreiben. Dieses sogenannte Query Rewriting kann helfen, statt einer sehr engen Frage eine umfassendere Version zu erstellen. Im Webinar haben wir zum Beispiel über das Verfahren namens Hypothetical Document Embedding gesprochen. Dabei wird aus der Frage eine hypothetische Antwort erzeugt, die wiederum vektorisiert wird, um besser mit den vorhandenen Dokumenten abgeglichen zu werden. Bei der finalen Ausgabe bekommt der Nutzer natürlich die Antwort auf seine Originalfrage, nur im Hintergrund nutzen wir eine umgeschriebene Fassung für die Datenbank-Suche.

Die Retrieval Pipeline

Der letzte Schritt entscheidet, wie die eigentliche Antwort generiert wird. Die Retrieval Pipeline sucht in der Wissensdatenbank nach den passenden Textstellen, indem sie den Vektor der Nutzerfrage mit den Vektoren der Chunks vergleicht. Die ähnlichsten Chunks werden zunächst ausgewählt, da sie inhaltlich am besten passen. Wenn zu viele mögliche Treffer vorhanden sind, kann man die Liste mit sogenannten Re-Ranking-Methoden noch weiter verfeinern. Ein Sprachmodell bewertet dann zum Beispiel, welche Chunks wirklich am relevantesten sind, und sortiert sie neu.

“Retrieval bedeutet, dass mithilfe einer Anfrage im Vektorraum die passenden Textabschnitte gefunden werden, indem wir den semantischen Abstand bestimmen und so herausfiltern, welche inhaltlich am nächsten liegen.”

Nach dem Retrieval kann das System den Umfang der einfließenden Textstücke beschränken, um das generierende Sprachmodell nicht mit zu viel Kontext zu überfrachten. Zu wenige Chunks sind aber ebenso problematisch, weil dann womöglich relevante Informationen fehlen. Am Ende werden alle ausgewählten Chunks zusammen mit der Originalfrage und einem System Prompt an das große Sprachmodell geschickt. Diese drei Elemente – System Prompt, Kontext und Query – münden schließlich in einen zusammenhängenden Text als Antwort.

Halluzination und Fehlerquellen

Im Webinar wurde oft gefragt, ob ein RAG-System halluzinieren kann. Streng genommen kann jeder Sprachgenerator Fakten erfinden oder Details vermischen, wenn er nicht den richtigen Kontext hat. RAG verringert jedoch die Wahrscheinlichkeit solcher Fehler. Die KI stützt sich bei ihren Antworten auf externe und meist geprüfte Inhalte aus der Wissensdatenbank. Gleichzeitig kann sie aber immer noch ihr allgemeines Sprachwissen nutzen, was in seltenen Fällen zu falschen Ergänzungen führen kann. Der wesentliche Vorteil liegt darin, dass das Modell mit abfragbaren Quellen arbeitet, statt alles aus seinem eigenen “Gedächtnis” zusammenzuspinnen.

Wenn ein Dokument sehr umfangreich ist, kann ein anderes Problem auftreten: Das Modell erhält nur Auszüge. Wer eine globale Zusammenfassung des gesamten Inhalts erwartet, stößt an die kontextuelle Begrenzung. Es gehört daher zur Planung eines RAG-Systems, sich zu überlegen, ob ein Nutzer das komplette Dokument benötigt oder nur einzelne Details. Moderne Sprachmodelle bieten längere Kontextfenster an, lösen dieses Problem teilweise und erlauben bei Bedarf umfangreichere Analysen.

Fazit und Ausblick

Meine Zusammenfassung des Webinars hat gezeigt, wie Retrieval Augmented Generation in der Praxis funktioniert. Es ist nicht nur eine clevere Methode, um riesige Datenmengen handhabbar zu machen, sondern auch eine Chance, die interne Recherche in Unternehmen nachhaltig zu verbessern. Wer einmal erlebt hat, wie schnell ein KI-System eine präzise Antwort liefert, wird selten wieder auf starre Dateistrukturen, langwierige Volltextsuchen oder manuelles Durchscrollen zurückgreifen.

Das Einrichten eines RAG-Systems braucht dennoch Expertise. Die richtige Konfiguration der Ingestion Pipeline, die Integration von Zugriffsrechten und Metadaten sowie die Feinjustierung bei Query und Retrieval stellen oft spezielle Anforderungen. Im nächsten Webinar legen wir den Fokus stärker auf den businessorientierten Teil von generativen KI-Lösungen. Wir wollen dort Fragen klären wie: “Was unterscheidet Microsoft Copilot von ChatGPT?” und “Wann braucht man zusätzlich eine AI-Lösung wie den AI Hub?” Damit möchten wir denen eine Orientierung geben, die Entscheidungen rund um die Einführung von KI-Systemen treffen müssen, ohne jedes technische Detail kennen zu müssen.

“Wer einmal erfahren hat, wie effizient ein RAG-System präzise Antworten liefert, möchte nicht mehr zu den klassischen Recherchemöglichkeiten zurückkehren.”

Damit war das Webinar beendet und die wichtigsten Fragen zu RAG geklärt. Ich bedanke mich bei allen, die mit dabei waren, und freue mich auf das nächste Mal, wenn wir die geschäftlichen Perspektiven und strategischen Überlegungen vertiefen.