Projektron und KI: Erfahrungen bei Entwicklung und Optimierung der Projektron BCS-Hilfe

Die funktionale Sicht auf das Framework zeigt die folgende Grafik. Eingetragen ist als erste Anwendung die Softwarehilfe. Schnittstellen bestehen zu Datenquellen, zu Sprachmodellen, zur Ergebnisanzeige in Projektron BCS sowie über ein User Interface (UI) zum Administrator des Frameworks. Über das UI definiert der Administrator die Applikationen. Kern ist das System-Prompt, das festlegt, was die Anwendung leisten soll. Zusätzlich legt er das Sprachmodell (intern/extern) fest und kann Parameter eingeben. Wenn es sich, wie bei der Hilfe, um einen RAG-Applikation handelt, lässt sich steuern, wie aus dem Datensatz der Vektorindex erzeugt wird, beispielweise die Art und Größe der Textsplitts, oder wie viele Treffer zurückgegeben werden, und wie hoch diese mindestens bewertet sein müssen.

Von Projektron BCS aus wird das Framework über eine Schnittstelle angesprochen. Wenn ein Nutzer eine Frage in das KI-Hilfe-Fenster eingibt, wird eine Anfrage an das Framework gestellt, in der die betreffende Applikation als Parameter enthalten ist. Je nachdem, welche Aufgabe erledigt werden soll (Hilfe, Ticket zusammenfassen) können über die Schnittstelle verschiedene Applikationen angefragt werden.

Das Framework kann eine größere Zahl Applikationen enthalten, wie die folgende Grafik zeigt. Applikationen können verkettet werden. So kann beispielsweise aus den geschlossenen Tickets mit einem lokalen Modell ein Datensatz erzeugt werden, der aus anonymisierten Zusammenfassungen besteht. Dieser Datensatz steht dann zur Beantwortung von neu hereinkommenden Tickets zur Verfügung. 

In einer späteren Version kann der Kunde eigene individuelle Applikationen definieren, die nichts mit BCS zu tun haben müssen. Im Bild ist das beispielhaft ganz rechts dargestellt, „Verträge“. Diese stellt eine Unterstützung für Mitarbeiter dar, die häufig Verträgen verhandeln oder erklären müssen, wie es in einer Softwarefirma der Fall ist, wo mit jedem neuen Kunden ein Lizenzvertrag abgeschlossen wird. Die meisten dieser Fragen wurden bereits früher einmal beantwortet. Auf diese Erfahrungen kann mit einer KI-Applikation zurückgegriffen werden, um die Bearbeitung neuer Fälle zu beschleunigen. Der Datensatz besteht aus Dokumenten, die jeweils einen Vertragsparagrafen enthalten, die früher gestellte Kundenfrage dazu, und die getroffene Entscheidung. Das kann einfach über eine Sammlung von .txt-Dateien geschehen. Diese werden wie die Hilfedokumente verarbeitet, es wird ein Vektorindex erzeugt, der dann befragt werden kann.

Auf die gleiche Weise kann ein Kunde firmenindividuelle Prozessanweisungen, Sicherheitsrichtlinien und ähnliche Datensammlungen durch KI befragbar machen.

Die technischen Komponenten zeigt die folgende Grafik. Grundsätzlich sind diese alle austauschbar, um auf die schwer vorhersehbaren, raschen Entwicklungen auf dem Feld reagieren zu können. Die serverartigen Komponenten wie Ollama und LangServe sind tiefer verankert, sie haben einen standard-nahen Status und werden auch weithin in der Industrie verwendet (Stand Dezember 2024). Komponenten wie das Text-Embedding haben wir durch Test ausgewählt, dazu später mehr. Die Sprachmodelle lassen durch einen einfachen Konfigurationseintrag auswechseln.

Um ein lokales Embedding-Modell auszuwählen, haben wir einen Vergleichstest mit verschiedenen Produkten gemacht. Als Benchmark haben wir OpenAIs text-embedding-ada verwendet, das aber nicht lokal betrieben werden kann. Basis des Tests war ein Datensatz von ca. 100 Texten und 10 Fragen, die jeweils spezifisch zu einem Text gestellt wurden, sodass klar war, welcher Text der Top-Treffer zur Frage sein sollte. Die Texte wurden in die RAG-Lösung von OpenAI eingespielt, die Fragen gestellt, und die jeweils 4 Treffer (also TopK=4) mitgeschrieben. OpenAI konnte die Fragen gut beantworten, die erwarteten Dokumente kamen an erster Stelle. Verglichen haben wir mit 6 lokalen Embedding-Modellen sowie dem auch einzeln, aber nur online verfügbaren text-embedding-ada-002. Die 10 Fragen wurden gestellt, und die jeweils 4 Treffer mit dem Benchmark verglichen. Für eine Abweichung an Pos 1 gab es 7 Punkte, dann 4, 2 und 1 Punkt. Das lokale Modell mit der geringsten Punktzahl haben wir ausgewählt. Das war BAAI/bge-m3 von der Beijing Academy of Artificial Intelligence. 

Die Ergebnisse im Einzelnen zeigt die folgende Tabelle: oberer Teil die Punkte zu jeder Frage, unterer Teil, welche Texte jeweils abweichend herausgesucht wurden. Wir planen, den Test in Abständen zu wiederholen; bei wesentlichen Verbesserungen könnten wir das Embedding-Modell wechseln. Allerdings müssten man dann den gesamten Dokumentenbestand neu indizieren, was einen gewissen Aufwand bedeutet.

Der folgende Teil beschreibt die Einstellungen, Ergänzungen und Konfigurationen, die wir bei der Umsetzung unserer ersten produktiven Anwendung, dem Projektron BCS KI-Hilfe-Assistenten, gemacht haben. Wir haben die Anwendung in mehreren Test- und Implementierungsschleifen verbessert. Dargestellt ist jeweils der Prozessablauf, mit dem wir in die nächste Testschleife gegangen sind.

Links in den Bildern ist die Indexierungsphase abgebildet, der Weg von den Dokumenten bis zur Vektordatenbank. Rechts davon die Inferenzphase, der Weg von der Nutzerfrage bis zur Antwort. Nochmal zur Erinnerung: Der Frage wird durch das Text-Embedding ein semantischer Vektor zugeordnet, dann wird die Datenbank nach ähnlichen Vektoren – deren zugehörige Texte also vom gleichen Thema wie die Frage handeln – durchsucht. Die Treffer werden als Kontext an das Sprachmodell übergeben, zusammen mit der Frage und der Anweisung: „Beantworte die Frage anhand der gefundenen Texte“.

Unser erster Aufschlag für die Projektron BCS-Hilfe entsprach dem normalen RAG-Schema. Den Prozessablauf zeigt das folgende Bild. 

Wie findet man heraus, ob dieses Setup gute Ergebnisse liefert? Dazu benötigt man zunächst gute Testdaten. Das sollten validierte Frage-Antwort-Paar sein, sodass man schauen kann, ob die KI zur Frage die vorgegebene Antwort reproduzieren kann. Diese Daten waren bei Projektron in guter Qualität vorhanden, da über den Supportserver von Projektron häufig auch Hilfe-Anfragen gestellt werden. Unsere Testdaten sind also gelöste und vom Kunden abgenommene Hilfe-Tickets aus dem Support. 

Wir haben damit gerechnet, dass dieses Fragen im Schnitt eine Nummer zu schwer für die KI sind, also vielleicht zu etwa ein Viertel gut beantwortet werden kann, weil nur die geschulten Projektleiter und Administratoren einen Supportzugang haben. Diese Personen sind mit dem System und der Hilfe vertraut und sollten nur solche Fragen kostenpflichtig bearbeiten lassen, die sie mithilfe der Dokumentation nicht selber lösen können. Dieser Schwierigkeitsgrad des Testdatensatzes erschien uns vorteilhaft, da genügend Raum für Optimierungen ist. Ein Vorteil des Datensatzes ist ferner, dass der Test realistisch wird, da wir echte Kundenprobleme (noch einmal) lösen können. 

Die Dokumentationsabteilung, als die Experten für die Hilfe, testete die KI-Funktionen. Die Rückmeldungen erfolgten zusammengefasst, in der Regel über Microsoft-Word-Protokolle mit Screenshots und den Beobachtungen. Dann wurden die gefundenen mangelhaften Antworten untersucht, die Gründe ermittelt und überlegt, wie man den Prozess verbessern kann. Die notwendigen Änderungen wurden implementiert und getestet, dann folgte eine neue Evaluationsrunde mit der Dokumentationsabteilung mit dem jetzigen Ergebnis. 

Das folgende beispielhafte Testergebnis aus der ersten Runde führte zu einer Prozessänderung. Die Frage „Was bedeutet BT-115?“ konnte nicht beantwortet werden, obwohl das in der Dokumentation beschrieben ist. Die BT-Nummern bedeuten „Business Terms“, sie bezeichnen die Felder der elektronischen Rechnung. Die Frage ist schwierig, weil sie keinen Kontext enthält. Wenn man die Frage leicht erweitert, „Was bedeutet BT-115 bei elektronischen Rechnungen“, kommt die richtige Antwort. 

Es ist aber auch möglich, die kontextlose Frage richtig zu beantworten. Eine Analyse der Treffer aus der Vektordatenbank ergab, dass ein Textsplitt aus dem richtigen Hilfedokument zur elektronischen Rechnung gefunden wurde, aber nicht derjenige Split, in dem BT 115 vorkam. Mit diesen Informationen kann das Sprachmodell die Frage nicht richtig beantworten. 

Wir haben dann eine Funktion implementiert, die nach Aktivierung jeden Split durch das komplette Dokument ersetzt, das dann an das Sprachmodell übergeben wird („Parent Dokument Retrieval“). Mit dieser Funktion wird auch die kontextlose Frage nach BT-115 richtig beantwortet. 

Bei der Bestimmung der optimalen Größe der Textsplits besteht ein Zielkonflikt. Einerseits müssen die Splits groß genug sein, um ausreichend Kontext für die Beantwortung der Frage zu liefern, andererseits klein genug, um möglichst nur ein Thema zu enthalten, damit der Vektor die Bedeutung genau wiedergeben kann. Mit „Parent Document Retrieval“ kann man diesen Zielkonflikt zum Teil auflösen. 

Die zweite Version des Prozessablaufs, mit Parent Document Retrieval, sah wie folgt aus. 

Damit gingen wir in eine neue Testrunde. Die folgenden Screenshots zeigen einen Ausschnitt aus der Testdokumentation mit neuen Beobachtungen. 

Die Analyse ergab, dass das Problem auch hier wieder von der Retrieval-Stufe herrührt. Wenn „BCS“ oder „Projektron“ in der Frage enthalten sind, liefert die Vektorsuche oft sehr kurze Textstücke zurück, in denen vor allem „BCS“ oder „Projektron“ steht. Oft hat keiner der fünf Treffer etwas mit dem Rest der Frage zu tun. Auch wenn man den Split durch das ganze Dokument ersetzt, kommt das Sprachmodell mit dieser Kontextinformation nicht zu einer korrekten Antwort. 

Wenn man in einem allgemeinen Textkorpus suchen würde, ist es eine gute Strategie, sehr spezifische Begriffe wir „BCS“ oder „Projektron“ hoch zu gewichten, um die vermutlich wenigen Dokumente zu finden, die von diesen Themen handeln. Bei unserer speziellen Anwendung handelt aber jeder Text im Korpus von Projektron BCS, daher führt eine hohe Aufmerksamkeit für diese Begriffe in die Irre. Wir schreiben deshalb die Frage um, wenn sie bestimmte Begriffe (hier ist der Filter: „BCS“ oder „Projektron“) enthält. Sofern die Begriffe nicht enthalten sind, wird die Frage unverändert verwendet, andernfalls werden die Begriffe von einer KI-Applikation entfernt. Dabei soll die Frage ansonsten möglichst wenig verändert werden. Das ist ein erstes Beispiel für die Verkettung von KI-Applikationen. Der Prozess mit Query Rewriting (QRW) sieht jetzt so aus: 

Damit gehen wir in eine neue Testrunde. Das nächste Fundstück hat wieder mit der Retrieval-Stufe zu tun. Wir haben getestet, ob kürzere Splits, weil sie präziser semantisch vektorisiert werden können, zusammen mit Parent Dokument Retrieval bessere Ergebnisse liefern. Das war überraschend nicht unbedingt der Fall, wie das Beispiel zeigt. Bei größeren Splitlängen (250 oder 1.000 Zeichen) wurde die Testfrage im Beispiel richtig beantwortet, bei einer Länge von 100 Zeichen nicht. Anscheinend gibt es dann zufällig keinen Split, der alle drei bedeutungstragenden Begriffe in der Frage: „Ticket“, „Artikel“, „zuordnen“ enthält. Die Treffer drehen sich meist um die Zuordnung von Mails zu Tickets. Mit diesem Kontextmaterial lässt sich die Frage nicht beantworten. 

Als Lösung haben wir implementiert, dass der Datensatz um KI-generierte Zusatzdokumente ergänzt werden kann. In diesem Fall sind das kurze Zusammenfassungen, die alle Schlüsselwörter der betreffenden Hilfeseite enthalten. Die Zusammenfassungen werden nicht weiter gesplittet. Wenn der Indexer eine dieser Zusammenfassungen findet, wird diese wie bei den Textsplits durch die komplette Hilfeseite ersetzt, die dann als Kontext übergeben wird. Damit sieht der Prozess so aus:

Auch der letzte Verbesserungsschritt, den wir vorstellen möchten, hat mit dem Splitting- und Indizierungsprozess zu tun. Wir haben beobachtet, dass die vom Indexer gefundenen Splits oft sehr kurz sind. In der Standardeinstellung des „Recursive Text Splitter“ wird zuerst an doppelten Zeilenumbrüchen, dann an einfachen, dann an Leerzeichen, und zuletzt im Wort, gesplittet. Da die Hilfedokumente stark strukturiert sind, mit vielen doppelten Zeilenumbrüchen, entstehen viele Splits kürzer als die „Chunk Size“.

Die Standardeinstellung passt gut für Standardtexte, in unserem Spezialfall liefert sie weniger brauchbare Resultate. Das liegt im Effekt daran, dass die semantische Suche diese kurzen Splits sehr bevorzugt. Es ergibt sich oft ein Fundbild wie in der folgenden Abbildung. Obwohl als Splitlänge 1.000 eingestellt ist, sind die gefundenen Splits nur zwischen 16 und 26 Zeichen lang. 

Wir haben den Verdacht, dass (ähnlich wie bei den Begriffen BCS und Projektron) deshalb oft Splits ermittelt werden, die einen hoch bewerteten Begriff enthalten. Das müssen nicht unbedingt die Splits sein, die nach dem Parent Document Replacement auf das optimale Originaldokument führen. Wir haben daher die Splitparameter über das Framework konfigurierbar gemacht, sodass man einfach die fixe Länge einstellen kann, ohne Rücksicht auf Strukturen durch Zeilenumbrüche oder die Semantik. Ein groß gewählter Überlapp sorgt dafür, dass Sinnzusammenhänge möglichst erhalten bleiben. Es scheint nach den Tests, das diese Methode in unserem Spezialfall etwas bessere Ergebnisse liefert als das Standardsplitting. Damit sieht der Gesamtprozess jetzt so aus: