Large Language Models

Spätestens seit ChatGPT sind Large Language Models (LLMs) in aller Munde und sowohl im Privatleben als auch in diversen Branchen angekommen. Von automatisch erstellten Blogbeiträgen und Zeitungsartikeln bis hin zur massiven Unterstützung durch Tools wie GitHub Copilot bei der Softwareentwicklung lassen sich LLMs mal mehr, mal weniger erfolgreich einsetzen. Insbesondere die Fähigkeiten der neuesten Modellgeneration GPT-4 - der Basis von ChatGPT, Bing Chat und zukünftig auch Copilot X -, sich auf die Fragen des menschlichen Gesprächspartners einzulassen und sich an dessen Anforderungen zu halten, sind äußerst verblüffend.

Bei der Nutzung begegnen Anwendern jedoch immer wieder auch seltsame, unwahre Antworten, welche bei sogenanntem Halluzinieren entstehen. Da GPT-4 auf Grundlage eines riesigen Datensatzes wissenswerter Texte trainiert wurde, kann es viele Fragen und Aufgaben richtig beantworten. Dieser Datensatz enthält allerdings nur Daten bis zum Jahr 2021, womit aktuellere Aussagen nicht möglich sind. Anstatt jedoch Unwissenheit wie diese zuzugeben, erfindet das Modell in der Regel eine plausible Antwort, denn das ist es, was aktuelle LLMs tun: Sie vervollständigen Fragen mit einer sprachlich plausiblen Antwort, die aber nicht faktisch geprüft wird. Denn das sogenannte Reasoning, also Schlussfolgern, beherrschen diese aktuellen Modelle noch nicht.

Auch bei anderen Modellen wie Metas Llama 2 gibt es Beschränkungen, die das zugrundeliegende Wissen betreffen. Da diese deutlich kleiner sind, lassen sie sich zwar auf der eigenen Hardware ausführen - was Microsoft und OpenAI mit GPT-4 nicht ermöglichen - haben aber einen deutlich begrenzteren Wissensschatz zum faktisch richtigen Beantworten von Fragen.

Vor dem Hintergrund dieser Einschränkungen ergibt sich bei der Verwendung von LLMs eine Frage: Wie können wir per LLM unsere eigenen Daten abfragen und analysieren, wenn diese Modelle nur mit öffentlichen Daten vortrainiert wurden und sich dabei beispielsweise durch Halluzinieren auch noch faktische Fehler einschleichen?

Die Lösung liegt darin, weitere Informationen bei der Abfrage mitzugeben. So können Nutzende einfach ein vorhandenes Dokument mit dem Prompt eingeben, um dessen Informationen abzufragen und sich vom LLM ihrer Wahl dabei unterstützen zu lassen. Sobald jedoch größere Mengen an Text hinzugegeben werden, wird schnell das Context Limit erreicht. Das Context Limit ist die Länge des Inputs, den das jeweilige Modell verarbeiten kann, und es lässt sich nur durch eine Änderung der Modellarchitektur mit teurem und aufwändigem Retraining erweitern. Dieses Problem können Nutzende allerdings lösen, indem sie relevante Texte vorab auswählen und nur diese mit dem Prompt eingeben.

Die Auswahl relevanter Inhalte ist zum Beispiel durch eine semantische Suche mit Embeddings möglich. Dafür werden zuerst alle Texte - je nach Länge auch nur einzelne Abschnitte daraus - beispielsweise mittels Sentence Transformer in Embeddings umgewandelt. Im einfachsten Fall kommt ein vortrainiertes Modell zum Einsatz, das bei allgemeinen Texten eine gute Performance aufweist. Vortrainierte und kommerziell nutzbare Modelle finden sich online inzwischen zur Genüge.

Anschließend wird die Abfrage mit dem gleichen Modell in ein Embedding umgewandelt und beispielsweise per Kosinus-Ähnlichkeit die ähnlichsten Embeddings gesucht. Die Texte, aus denen diese Embeddings berechnet wurden, werden anschließend zusammen mit der ursprünglichen Abfrage an das LLM weitergegeben. Im Nachgang können Nutzende so auch die gefunden Informationen auf die entsprechenden Textstellen beziehen, da sie wissen, welche Texte in die Antwort mit eingeflossen sind.

Auch bei Accso haben wir das oben beschriebene Vorgehen zur Unterstützung und Effizienzsteigerung unserer täglichen Arbeit verprobt. Innerhalb eines einzigen Tages entstanden die ersten Prototypen für eine erweiterte Confluence-Suche und zur Abfrage von Mitarbeiterprofilen und Skills. Wie in der pseudonymisierten Abbildung 3 zu sehen ist, nutzte der allererste Ansatz für die Skill-Suche ChatGPT und übergab dabei nur wenige pseudonymisierte Profile. So lassen sich deutlich schneller und einfacher relevante Informationen finden.

Diese Prototypen bauen wir nun zu robusten und wartbaren Anwendungen aus, um auch langfristig von dem Effizienz- und Komfortgewinn zu profitieren. Dafür nutzen wir den zuvor beschriebenen Ansatz: Wir berechnen Embeddings zu Text-Absätzen mittels Sentence Transformer, speichern diese Embeddings in einer Vektor-Datenbank ab und können so mittels Kosinus-Ähnlichkeit relevante Texte für jede Anfrage heraussuchen, die wir in der Query an die OpenAI-API oder ein lokal betriebenes Modell mitgeben. Mit diesem Vorgehen skalieren wir die Suche auch für eine größere Zahl von Mitarbeiterprofilen oder sogar eine ganze Confluence-Instanz. Dabei bleibt das Verfahren immer gleich, nur die Aufbereitung der Texte muss je nach Datengrundlage angepasst werden.