Optimierung eines RAG-Chat-Bot-Systems
Ausgangslage
Unsere Aufgabe war es, in kürzester Zeit einen «Proof-of-Concept» für einen deutschsprachigen Chat-Bot umzusetzen, der – basierend auf einer vorhandenen «Knowledge-Base» - Fragen interner User beantworten kann.
Die Knowledge-Base bestand zum einen aus öffentlich verfügbaren und sehr gut strukturierten schweizerischen Gesetzestexten auf kantonaler und Bundesebene im PDF-Format; zum anderen beinhaltete sie interne Kundendokumente (Weisungen), ebenfalls im PDF-Format. Diese waren weniger gut strukturiert als die Gesetzestexte und beinhalteten mehr Grafiken. Hinzu kamen im weiteren noch interne Glossare in tabellarischer Form.
Im Rahmen des Projektes stellten sich uns insbesondere die folgenden Fragen:
Wie können wir ein Basis-RAG-System ausgehend von den gesetzten Default-Einstellungen und -Parametern mit begrenztem Mitteleinsatz optimieren?
An welchen «Stellschrauben» können wir überhaupt drehen und was sind deren Auswirkungen?
Wann ist das System "gut genug" für die Anwender?
Den Chat-Bot haben wir als «RAG-System» konzipiert.
Architektur
Parameter
Die Tabelle rechts zeigt die identifizierten Stellschrauben.
Stellschrauben
Evaluation
Experimente
Markdown-Format
In der Basisversion wurden die PDF-Dokumente mit dem «FormRecognizerService» von Microsoft vor der Weiterverarbeitung in das HTML-Format extrahiert. Wir vermuteten jedoch, dass eine Extraktion in das Markdown-Format zu einer besseren Leistung des RAG-Systems führen würde.
Für das Experiment verwendeten wir den «DocumentIntelligenceClient» von Microsoft in der neusten Version, wobei wir Markdown als Output-Format wählten. Im Ergebnis erbrachte die Verwendung von Markdown allein jedoch keine messbare Verbesserung gegenüber der Basisversion.
Berücksichtigung der Text-Struktur
In der Basisversion wurden die aus den Dokumenten extrahierten Texte anhand gängiger Satzzeichen wie z.B. «.», «!», «?», «;», «:» usw. in Schnipsel mit der vorgegebenen Grösse von 1024 Tokens zerteilt. Dies hat zur Folge, dass der Text unabhängig von der Struktur des jeweiligen Dokumentes gesplitted wird: Der zusammengehörende Inhalt eines Text-Abschnitts, der aus mehreren Sätzen besteht, wird so unter Umständen auf verschiedene Schnipsel aufgeteilt, was suboptimal erscheint.
Wir wählten deshalb ein Vorgehen, bei dem der Text zunächst nach den Überschriften der Abschnitte und erst in einem zweiten Schritt bei den dann noch zu grossen Chunks nach den gängigen Satzzeichen gesplittet wird. Zu kleine Schnipsel setzten wir hierbei wieder bis zur Zielgrösse zusammen.
Dieses Experiment erwies sich als erfolgreich und erzielte einen um sechs Prozentpunkte höheren RAGAS-Score als die Basisversion.
Übersetzung nach Englisch
Im Weiteren vermuteten wir, dass das für die Antwort-Generierung verwendete GPT4-Modell mit englischsprachigen Anfragen und Dokumenten besser umgehen könnte, als mit unseren deutschsprachigen. Insofern erwogen wir eine Übersetzung der Anfragen und Dokumente ins Englische, sowie eine Rückübersetzung der Antworten ins Deutsche. Da dies aufwändige Anpassungen erfordern und die Übersetzungen auch einen Qualitätsverlust bewirken könnten, entschieden wir uns schliesslich gegen die Übersetzung.
Dafür fanden wir heraus, dass Deutsch mittlerweile von der Lucene-Suche im Azure AI Search Index unterstützt wird, wenn man die Felder entsprechend konfiguriert. Folglich wählten wir diesen Weg und kombinierten ihn mit einer Anpassung in der Suchmethodik wie im Folgenden beschrieben.
Semantische Suche
Standardmässig werden bei RAG-Systemen sowohl die Anfrage als auch die in der Datenbank gespeicherten Dokumentschnipsel in numerische Vektoren (sog. Embeddings) umgewandelt. Das RAG-System sucht dann die für die Anfrage relevanten Schnipsel, indem es diejenigen Schnipsel-Vektoren mit der geringsten «Distanz» zum Anfrage-Vektor identifiziert (vgl. die Links unten zur Vertiefung dieser Themen).
Wir haben uns gefragt, ob eine semantische Lucene-Suche in deutscher Sprache besser abschneiden würde als die Standard-Vektorsuche, da das standardisierte Embedding-Modell von OpenAI möglicherweise für unsere Dokumente und Kontext nicht optimal sein könnte.
Diese Vermutung erwies sich als zutreffend und unser Experiment erzielte einen um sechs Prozentpunkte höheren RAGAS-Score als die Basisversion.
Fazit
Unsere Experimente haben gezeigt, dass es sich lohnen kann, in Abhängigkeit von der genauen Aufgabe und dem Kontext, Anpassungen an der Default-Konfiguration der vorhandenen Basis-RAG-Systeme durchzuführen. Mit der Kombination unserer Experimente konnten wir einen Uplift im RAGAS-Score von gut zehn Prozentpunkten erzielen.
Wir bieten umfangreiche Unterstützung im Bereich Artificial Intelligence & Machine Learning.
_2-01.png)