Dynamische Inhalte in LLM-ChatBots - Der 1-Day viadee Blog Assistent

Der Nutzen vom “Nachschlagen bei Bedarf” in typischen LLM-Anwendung ist deutlich und schnell sichtbar: Aktualität der Information und wenig Aufwand. Multi-LLM-Technik und Chat-Bot-Agenten mit Funktionsaufrufen standen heute im Vordergrund unseres Tech-X-Days im Team. Wir berichten von unseren Erfahrungen mit dem kürzlich an einem Tag entstandenen Proof-of-Concept eines Assistenten für Blog-Autor:innen.

Anwendungsfall: Der viadee Blog-Assistant

Seit 2015 gibt es den viadee-Blog. Wir nutzen ihn ebenso als Austauschmedium und Notizzettel wie auch als Aushängeschild für die Kompetenzen der viadee-Themenbereiche.
Das Schreiben braucht neben einer Idee und den offensichtlichen Fertigkeiten auch Orientierung: Viele Berater:innen tragen etwas bei und es wird für Autor:innen schnell unübersichtlich: Was gab es schon und was noch nicht? Worauf kann ein neuer Blogpost aufbauen, verweisen oder einen Beitrag zur SEO-Positionierung leisten?
Hier ist sehr aktuelles Wissen und Recherche notwendig.

Während Hinweise zum Stil (“viadee immer klein schreiben”) längere Zeit stabil bleiben und sich gut in einem Prompt abspeichern und von Autoren und Autorinnen mehrfach nutzen lassen, geht das mit den aktuellen Bezügen nicht.
Ein guter Blog-Assistent müsste die anderen Blogposts ad hoc nachschlagen können! Das ist unser Anwendungsfall für heute - wir helfen auch gern ihren Anwendungsfall aufzuzeigen.

Lösungsansatz: Mehrere LLM und Funktionsaufrufe

Der Ansatz, um Chatbots mit diesen veränderlichen Informationen zu versorgen ist offensichtlich: Man definiert vor dem Chat-Verlauf Funktionen (oft in Python, alternativ auch in Java), die einem LLM zur Verfügung stehen (sog. Tools) und beschreibt sie so, dass ein LLM entscheiden kann, wann sie einzusetzen sind und mit welchen Parametern. Das kann im Extremfall ein Stück Code sein, das erst generiert und ausgeführt wird. Wer es weniger riskant mag, bietet vorab geprüfte Funktionen für Rechenoperationen an oder für das Nachschlagen von Dingen in Datenbanken. Hier haben wir kürzlich im Rahmen einer TechX-Aktion eine Reihe von Experimenten gemacht.

Es gibt wenige Heuristiken im Umgang mit LLMs und KI, die fast immer sinnvoll anwendbar sind. Eine davon ist “Divide and Conquer”. Wir teilen den Anwendungsfall “Blog-Assistenz“ in kleine Teile auf:

Prinzipiell wären Assistenzfunktionen wie diese auch sehr strukturiert anzubieten: Titel zuerst, Links ergänzen als letztes. Wir möchten hier aber sicherstellen, dass die Nutzerin die volle Kontrolle über die Interaktion hat und natürlich schadet es nicht später neue Funktionen anbieten zu können, ohne dass sich erlernte Abläufe ändern müssen. Ziel ist daher eine GPT-Ansprechperson zu simulieren, die bei mehreren Problemstellungen helfen kann.

LLM-ChatBots: Architekturen und Werkzeuge

Während einfache Frage-Antwort-Systeme für eigene Daten schon als SaaS-Angebote etabliert sind ist im Bereich dynamischer Interaktion mit Chatbots noch sehr viel mehr Dynamik und der Markt ist unübersichtlicher. Die großen Player versuchen sich hier Marktanteile zu sichern und auch Low-Code / No-Code-Zielgruppen zu erschließen (bspw. mit Microsoft Autogen Studio, den Open Ai Assistants oder Open Source-Projekten wie Langchain oder Langchain4J), was offensichtliche Lock-In-Effekte mit sich bringt und in einem Raum voller Software-Engineers nicht mehrheitsfähig war: Die Technologien in unseren Kundenprojekten sind heterogen und oft nicht ad hoc zu ändern. Wir wollten hier die volle Kontrolle über das Geschehen und haben uns daher entschieden, die Anwendung nur auf Basis der bekannten LLM-Modelle und deren APIs zu bauen.

Prompt Engineering

Angenehm daran war, dass wir insb. am Minute 1 volle Kontrolle über Interaktion und Prompts hatten. Ein Sub-Team “Prompt Engineering” konnte also schon mit Copy & Paste im Chat-Playground aktiv werden und sich Feedback für Ergebnisse holen, während ein “Agent”-Team noch Infrastruktur aufgebaut hat.

Nach ein wenig Feinarbeit haben wir aus der Wissensbasis schon bestehender Blogartikel gute (und begründete) Vorschläge bekommen, auf die ein fiktiver Beitrag zu MLOps-Grundlagen gut verweisen könnte.

Arbeitsteilung auf zwei LLM-Ebenen

Nach einigen Experimenten haben wir uns auf eine einfache Struktur des Antwort-Prozesses geeinigt. Grundidee ist, dass wir im Backend eine 2-stufige Architektur verwenden. Der Ablauf ist wie folgt:

Die obere Ebene realisiert das, was funktional klassischerweise ein User-Interface leisten wird - nur eben durch ein LLM. Kernaufgaben hier sind:

1. Den Dialog steuern. (“Hallo, wie kann ich helfen?”)

2. Bemerken, ob eine Funktion mit “Außenkommunikation” benötigt wird und wenn ja, mit welchen Parametern. (“Du möchtest wissen welche anderen Blogposts zum Thema MLOps schon im viadee-Blog veröffentlicht sind? Das kann ich nachschauen!“)

Nach dieser Feststellung kommt eine von mehreren Funktion zum Zuge, die genau diese Aufgabe gut lösen kann. Im konkreten Fall wird sie durch eine SQL-Datenbankabfrage und ein zweites LLM realisiert, welches die Relevanz von möglichen Treffern bewertet. Das ist nicht einfach, denn vielleicht taucht das Stichwort selbst nicht auf. Relevanz ist hier nicht mit Ähnlichkeit zu verwechseln. Vielleicht ist ein anderer Blogpost auch Grundlage für den aktuellen und bauen darauf auf, ohne dass die Posts sich sehr ähnlich sind. Als Architektur-Muster geschieht hier oft das Gleiche:

1. Wir führen ein Stück Python-Code aus. (“Datenbankabfrage“)

2. Ein (spezialisiertes) LLM formuliert eine Antwort dazu.

3. Wir übernehmen die Antwort (und nur die Antwort) in den Dialog des Level 1-LLMs.

Von dieser Trennung haben wir hier deutlich profitiert: Das zweite LLM bekommt in unserem Fall eher viele potenzielle Blogposts als Kandidaten angeboten. Es braucht einen großen Kontext für die potenziell relevanten Dokumente - auch wenn es sich um eine RAG-Abfrage handelt. Wir können hier also gezielt ein Modell mit großem Kontext wählen. Das koordinierende LLM bekommt nur die Antwort im Dialog zu sehen, so als ob es sie selbst gegeben hätte. Damit sparen wir eine große Anzahl Token im weiteren Verlauf des Dialogs, denn der Dialog hat nur den zusammengefassten Dialog im Zugriff.

Lessons Learned

Die Umsetzung dieses Multi-Agent-Workflows war bestechend einfach und liefert gute Ergebnisse. Die reine Technik stand heute im Vordergrund, aber der Nutzen der Integration von Funktionen in typische LLM-Anwendung ist deutlich sichtbar. Mein Kollege Lennart hat jetzt einen Titel für seinen Blogpost und das Feedback zu den Titeln vergangener Postings war plausibel. Dabei haben wir auch inhaltlich etwas dazugelernt:

• Wir haben uns einmal die Zeit genommen auszuformulieren, was gut Blog-Titel für uns ausmacht und haben das Prompt jetzt auch selbst als Referenz behalten.

• Wir haben einen Trend bemerkt bei der Recherchen nach Beispielen in der Historie: Unsere ersten Blogposts vor einigen Jahren waren nach den Maßstäben von heute noch weniger gut betitelt als aktuelle Blogposts. Eine menschliche Lernkurve ist zu sehen und das ist auch beruhigend.

Bei der Erstellung und Nutzung dieser Prompts braucht es keine großen Prompt-Engineering-Künste, aber eine gewisse Medienkompetenz im Umgang mit LLMs: Auch, um zu verstehen welche Anfragen gute Ergebnisse bringen werden und welche nicht.

Technisch betrachtet zeigt sich vor allem ein Aspekt: Wir hatten vorab überlegt, mehrere Teams mit mehreren Basistechnologien wie LangChain, LangChain4j, Azure Bot Service und anderen gleichzeitig arbeiten zu lassen, um dann die Entwicklungsgeschwindigkeit vergleichen zu können. Letztlich haben wir uns entschieden keine dieser “Abstraktionsebenen” zu verwenden, um mehr Kontrolle über den Ablauf zu haben und in kleinen, sichtbaren Schritten voranzukommen.

Es stellte sich am Ende des Tages heraus, dass wir auf diesem Weg nicht nur schnell am Ziel waren. Zusätzlich haben wir auch architektonisch einige sinnvolle Trade-Off-Entscheidungen getroffen. Wir nutzen nur die OpenAI-API, die analog für Azure Open AI oder auch lokal betrieben LLM via ollama nutzbar ist und sind folglich unabhängig von konkreten Modellen und Anbietern. Darüber hinaus ist LangChain auch eine große, schnell veränderliche Abhängigkeit, die man im Produktiveinsatz vermeiden wollen würde - nicht schlecht für einen Nachmittag.

Interesse an KI?

Hier geht's zu unserem Seminarangebot im Bereich Künstliche Intelligenz: