KI-Assistent: Von Vektordatenbanken zu multimodalen Agenten

Die Funktion, eigene Dokumente in ogGPT hochzuladen, ist fast so alt wie ogGPT selbst. Und auch, wenn sich der Name der Funktion gewandelt hatte, so blieb die dahinter versteckte Implementierung größtenteils gleich: Bei einer Anfrage eines Nutzenden wurden mit Hilfe von Langchain und einem LLM die relevanten Teile der Anfrage zuerst umgeschrieben. Dann wurden sie mit Azure OpenAI ada-v2 embedded und schließlich mit den vorhandenen Text Chunks in der Vektordatenbank verglichen. Daraufhin wurden die relevantesten Dokumententeile zusammen mit der Anfrage des Users an ein Azure OpenAI LLM gesendet, wo anschließend eine Antwort generiert wurde.

Doch mit der Zeit fielen uns immer wieder einige Schwachstellen hierbei auf. Was passiert, wenn ein Nutzer zuerst Informationen aus seinen Dokumenten abfragen und dann mit allgemeinen Informationen vergleichen möchte? Dann würde bei der allgemeinen Anfrage trotzdem nach relevanten Dokumenten gesucht und diese an das Sprachmodell weitergegeben werden, auch wenn diese höchst unrelevant für diese Anfrage ist.

Oder, was soll passieren, wenn der Nutzer das Dokument zusammengefasst haben möchte? Ja, die Implementierung der Erstellung einer solchen Zusammenfassung ist nicht wirklich kompliziert, aber woher soll das Modell wissen, wann es zusammenfassen und wann stattdessen alle Dokumente durchsucht werden sollen?

Im Endeffekt lassen sich all diese Fragen auf ein Kernproblem fokussieren: Wir müssen aktuell für das Modell entscheiden, wann welche Funktionalität angewendet werden muss, während es eigentlich besser wäre, wenn es dies selbst tun würde. Anstatt dem Modell genau vorzuschreiben, was es wann tun muss, sollten wir es unterstützen. Wir sollten ihm die Werkzeuge zur Verfügung stellen, die es für seine Aufgaben benötigt.

Glücklicherweise gibt es bereits ein Konzept, was genau das umsetzen kann: “Agenten” und passend dazu “Tools”. Die Grundlage hierfür wurde durch eine Neuerung in den Modellen der großen LLM-Anbieter gelegt. „Function calling“ erlaubt es den Modellen mit ihrer Textausgabe bestimmte Code Schnipsel aufzurufen, was ihre Fähigkeiten deutlich erweitert. 

Während dies bereits vorher theoretisch möglich war, wurden bei OpenAI im August 2024 die Modelle so erweitert, dass sie verlässlicher funktionieren. Doch was steckt genau hinter diesen "Tools”? 

Das Konzept hierfür ist recht simpel: Wir als Entwickler*innen definieren eine Funktion, die zum Beispiel den Suchprozess relevanter Dokumente in der Datenbank regelt. Damit diese Funktion zu einem Tool wird, müssen wir nun noch passende Namen und Beschreibung hinzufügen, damit unser LLM weiß, was für Argumente der Funktion übergeben werden und in welchem Kontext sie ausgeführt werden sollte.

All das wird zusammen mit anderen möglichen Tools und dem Systemprompt an das Modell übergeben. Wenn der Nutzende nun eine Anfrage stellt, kann sich das Modell, bzw. der Agent entscheiden, ob er eins der zur Verfügung gestellten Tools ausführen möchte. Dies kann er tun, indem er den Funktionsnamen und die benötigten Argumente in einer vordefinierten Struktur generiert und zurückgibt. Diesen Output können wir dann auswerten und somit die gewünschte Funktion auf unserem Server ausführen. Die Ausgabe der Funktion wird dann wieder an den Agenten zurückgegeben, der daraufhin eine Antwort für den Nutzenden generiert.

DieseIteration kann auch mehrmals hintereinander ausgeführt werden, je nachdem wie relevant die vorhandenen Funktionen für die Anfrage sind und was der Output von vorherigen Funktionsaufrufen war. Somit kann der Agent auch eigene, vorherige Fehler ausbessern, indem die Funktion beispielsweise mit anderen Parametern aufgerufen wird.

Genau diese Selbständigkeit fehlte noch bei unseren customGPTs. Somit begannen wir damit die vorherige RAG (Retrieval Augmented Generation) Implementierung in ein Tool umzuwandeln und zusammen mit System Prompts unseren Nutzenden die agentenbasierte Modellierung vorzustellen. Während das grundsätzlich erstmal trivial klingt, erfolgten im Hintergrund viele Testiterationen, um das Verhalten des Modells an unsere Vorstellungen anzupassen.

Ein wenig später fügten wir dann auch ein Tool hinzu, was dem Agenten ermöglicht, eine Zusammenfassung eines Dokuments zu erstellen. Daraus ergaben sich dann ganz neue Abläufe, mit denen wir vorher nicht gerechnet hatten. So kombinierte der Agent seine Tools, indem er zum Beispiel erst eine Zusammenfassung erstellte und danach die spezifischere Vektorsuche verwendete.

Bei genauerer Betrachtung stellte sich heraus, dass in manchen Fällen die Zusammenfassung nicht spezifisch genug war. Also versuchte das Modell, diese Lücken zu ergänzen. Auch wenn die Anfrage des Nutzers nicht deutlich genug war, wurde erstmal die Zusammenfassung verwendet, um einen Überblick über das Dokument zu bekommen und dann, basierend auf dem Inhalt, Rückfragen stellen zu können. ogGPT war tatsächlich deutlich selbständiger geworden!

Eine weitere Schwachstelle von LLMs konnten wir nun auch lösen: Zahlen und Daten. Da die Modelle auf der semantischen Darstellung von Texten basieren, scheitern viele Modelle an komplexen Rechenaufgaben, wie sie auch in der Datenauswertung benötigt werden. Hier kommt der “Code Interpreter” ins Spiel: Dieser erlaubt es dem Modell, seinen eigenen Code zu schreiben und dann in einer Art Sandbox Umgebung auszuführen. Es erhält die Ausgaben des Codes zurück, welche es dann nutzen kann, um die Antwort zu generieren. Dadurch überfordern wir das Modell nicht mit numerischem Input, ermöglichen es ihm aber trotzdem mit den Daten auf eine flexible Art zu interagieren. 

Auch hier profitiert der Agent wieder von mehreren Iterationen: Die Daten sind anders strukturiert als erwartet und der Code produziert einen Fehler? Kein Problem, ogGPT erkennt den Fehler, passt den Code selbständig an und erzeugt trotzdem das gewünschte Ergebnis, ohne dass ich als Nutzer*in eine neue Anfrage stellen muss.