Die KI-Hilfe in BCS: Schritt für Schritt zur präzisen Antwortqualität

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 BCS-Hilfe entsprach dem normalen RAG-Schema (Retrieval-Augmented Generation). Den Prozessablauf zeigt das folgende Bild: 

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. 

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 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:

Das ist der Stand, mit dem wir die erste produktive Version der Hilfe ausliefern. Jetzt warten wir auf den „Reality Check“: Erfahrungen mit den ersten echten Kunden. 

Man erkennt an unserem Erfahrungsbericht recht gut, dass die meiste Optimierungsarbeit das Retrieval und besonders den Text-Splitter betraf. Wenn man erst einmal den richtigen Kontext ermittelt hat, erstellt das Sprachmodell auch eine passende Antwort.