Die Möglichkeiten, die ein Large Language Model (LLM) eröffnet, haben bei vielen Unternehmen und Organisationen grosse Aufmerksamkeit erregt. Besonders im Informationsmanagement besitzen diese grossen Sprachmodelle nahezu ungeahntes Potenzial, den Fluss, die Verwertung und die Bereitstellung von Daten sowohl intern als auch im Austausch mit Kunden erheblich zu beschleunigen.
Jedoch geht diese Technologie mit nicht zu ignorierenden Hürden einher: Zum einen gibt es nach wie vor Bedenken bezüglich des Schutzes der Daten, die einem LLM anvertraut werden. Zum anderen liegt der Fokus aller bekannten LLMs auf dem Englischen, zum Nachteil anderer Sprachen. Und nicht zuletzt gibt es inzwischen eine ganze Bandbreite an Anbietern verschiedener Modelle, die sich in der allgemeinen Leistungsfähigkeit und ihren individuellen Stärken erheblich unterscheiden.
Unter diesen Gesichtspunkten ist es eine mögliche Strategie, zuerst einen Chatbot für den internen Gebrauch unter Mitarbeitenden zu entwickeln, mit dem diese Technologie erforscht, verschiedene Modelle erprobt und Erfahrungswerte gesammelt werden. Das Ziel ist es, einen Chatbot zu kreieren, der auf Suchanfragen der Nutzenden hin in unzähligen Dokumenten und Texten im unternehmenseigenen Intranet nach relevanten Informationen sucht, um sie dann wahrheitsgetreu, in konziser Form und in natürlicher Sprache zu präsentieren. Der technologische Ansatz, auf dem der Chatbot basieren soll, ist die Retrieval-Augmented Generation (RAG).
RAG ist ein Prozess, der die Fähigkeiten von LLMs mit einem System zur Informationsabfrage erweitert. Bei seiner Antwort stützt sich das LLM auf diese Wissensbasis («information retrieval system») ausserhalb des LLMs. Damit ist die Kontrolle, woher das LLM seine Informationen bei einer Antwort bezieht, stets gewährleistet.
Am Beispiel unseres Chatbots können wir die zwei Phasen des RAG-Prozesses aufzeigen:
LLMs oder grosse Sprachmodelle sind KI-Modelle, die auf Anwendungen im Zusammenhang mit der menschlichen Sprache spezialisiert sind. Mit riesigen Textmengen werden diese trainiert und sind danach in der Lage, natürliche Sprache zu verstehen und zu generieren.
Nun stehen wir also vor der Aufgabe herauszufinden, welches LLM sich am besten für unsere RAG Use Case eignet. Zur Auswahl stehen die Modelle der führenden Anbieter OpenAI, Anthropic, Mistral, Google und Meta:
Um das beste Modell für unsere Zwecke ausfindig zu machen, müssen wir eine präzise Bewertungsmethodik entwickeln. Ein wichtiger Aspekt hierbei sind die nicht-funktionalen und funktionalen Kriterien.
Auf grundsätzlicher Ebene können wir unterscheiden, ob das Modell «Open Source» oder kommerziell ist. Von den oben aufgeführten Modellen ist nur Llama 3 70B Instruct (Meta-Lizenz) Open Source, die restlichen sind kommerzielle Angebote. Dies wirkt sich auf die nicht-funktionalen Kriterien aus, insbesondere die Bereitstellung und den Betrieb eines LLM. Hierbei gibt es zwei Optionen:
Alle Modelle bieten eine Bereitstellung des LLM per API an, aber nur bei Open-Source-Modellen ist ein Own Deployment möglich. Dies bedeutet, dass wir bei der Verwendung eines kommerziellen Modells gewisse Kompromisse eingehen müssen. Beispielsweise können wir bei einem LLM, das wir selbst bereitstellen und kontrollieren, im Hinblick auf die Sicherheit unserer Daten etwas beruhigter sein, als es bei einem fremdbetriebenen LLM der Fall ist. Hier ist es besonders wichtig, dass wir die Vereinbarungen zur Datenverarbeitung des jeweiligen Anbieters genau studieren, um keine unangenehmen Überraschungen zu erleben.
Darüber hinaus haben kommerzielle Modelle alle eine begrenzte Lebensdauer. Bei OpenAI lassen sich diese Modellwechsel besonders gut beobachten. Sobald ein solcher Lebenszyklus vollendet ist, haben wir als Anwendende keine andere Wahl, als auf das Nachfolgermodell zu wechseln, was nicht ohne Konsequenzen bleibt. In diesem Zusammenhang ist es wichtig zu verstehen, dass sich ein LLM auf konzeptioneller Ebene von anderen Teilen eines Softwaresystems unterscheidet. Der Austausch einer Datenbank oder eines Applikationsservers kann derart nahtlos vonstattengehen, dass die Anwendenden nichts davon mitkriegen. Wird jedoch ein LLM ausgetauscht, und sei es auch nur mit einer neueren Version, wird das von den Nutzenden in der Regel bemerkt: Das System liefert auf die gleiche Frage u.U. eine andere Antwort, die zwar die gleiche Kernaussage haben mag, aber nicht identisch formuliert ist.
Diese nicht-funktionalen Kriterien, d.h. Kontrolle, Datenschutz und Stabilität sowie die wichtige Kostenfrage, werden wir im weiteren Verlauf nochmal anschneiden. Aber zunächst wenden wir uns den entscheidenden Kriterien zu, wenn es darum geht, das für uns optimale LLM zu ermitteln.
Unsere Wunschvorstellung von einem LLM ist relativ einfach erklärt: Wir wollen das LLM, das bei der Beantwortung unserer Fragen am besten abschneidet. Um das herauszufinden, ist jedoch ein erstaunlich grosser Aufwand nötig, da wir es hier mit einer Reihe von Unbekannten zu tun haben: Wir kennen die Fragen der Benutzenden nicht, und damit auch nicht die Resultate der Retrieval-Phase. Ebenso wenig haben wir die richtigen Antworten auf diese Fragen definiert.
Wir brauchen also ein allgemeineres Kriterium, das wir wie folgt formulieren: Welches LLM kann mehrere Fragen zu einem bestimmten Kontext, z.B. einem Wikipedia-Artikel, am besten beantworten? Sowohl die Fragen als auch der Kontext müssen hierbei auf Deutsch sein (was sich noch als zusätzliche Herausforderung erweisen wird).
Um also das beste Modell zu ermitteln, benötigen wir sogenannte Benchmarks.
Im weitesten Sinne ist ein Benchmark ein Massstab, um die Leistung oder Performance von Produkten, Prozessen oder organisatorischen Strukturen im Hinblick auf einen Bezugswert zu messen. In der Computer- und Informationstechnologie werden z.B. Hardwarekomponenten wie Prozessoren und Grafikkarten sowie auch Softwareanwendungen mit Benchmarks auf den Prüfstand gestellt.
Seit den frühesten Tagen des Machine Learning (ML) haben Benchmarks ebenfalls eine Schlüsselrolle gespielt. Erst sie machen es möglich, die Qualität verschiedener ML-Modelle miteinander zu vergleichen und deren Fortschritt zu messen.
Um einen Benchmark zu erstellen, sind a) ein Datensatz, b) eine Metrik und c) die Modelle erforderlich, die der Benchmark prüfen soll.
Schauen wir uns aus den Anfängen des ML den MNIST-Datensatz an. Er besteht aus Bildern handgeschriebener Zahlen (a) und den entsprechenden Zahlenwerten (auch als «Ground Truth» bezeichnet). Hier ein paar Beispiele aus dem MNIST-Testdatensatz (Foto von Josef Steppan, CC BY-SA 4.0):
Nun sollen zwei Bilderkennungsmodelle (c) im MNIST-Benchmark die handgeschriebenen Zahlen aus den Bildern feststellen. Die angewandte Metrik (b) ist simpel: Stimmt die vom Modell genannte Zahl mit der Ground Truth überein, ist die Identifizierung geglückt. Je höher die Trefferzahl, desto besser das Modell.
Für LLMs bestehen ebenfalls – inzwischen zahlreiche – Benchmarks, die sich jeweils auf die verschiedenen Anwendungsmöglichkeiten von LLMs fokussieren, z.B. die Übersetzung eines Texts vom Englischen ins Deutsche, die Zusammenfassung eines längeren Dokuments oder die Lösung eines mathematischen Problems.
Um das für uns beste grosse Sprachmodell zu finden, konzentrieren wir uns auf jene Benchmarks, bei denen der Datensatz unserem RAG Use Case entspricht. Das heisst, er besteht aus Kontext, Frage und Antwort (Ground Truth). Das LLM soll beim Benchmark und in unserem RAG-System dieselbe Aufgabe lösen: auf Basis des gelieferten Kontexts eine Frage beantworten.
Diese Art von Aufgabe wird als Open-Book-Question-Answering bezeichnet, da dem Modell die Information zur Beantwortung der Frage mitgeliefert wird. Im Gegensatz dazu muss das Modell bei Closed-Book-Question-Answering die Frage ohne zusätzliche Informationen beantworten.
Einige Beispiele bekannter Benchmarks für das Open-Book-Question-Answering:
Informationen zu einem neuen LLM werden meist im Rahmen eines technischen Berichts veröffentlicht. Dieser enthält die Ergebnisse des Modells für verschiedene Benchmarks sowie teilweise Vergleiche mit den Werten anderer Modelle.
Selbst bei einem englischsprachigen RAG-System stehen wir bei diesen Berichten vor dem Problem, dass sie keine Ergebnisse der LLMs für einen gemeinsamen Question-Answering-Benchmark enthalten. Während in den Berichten von Anthropics Modell Claude 3 und von GPT-4o von OpenAI ein F1-Score für den DROP-Benchmark zu finden ist, fehlt dieser für das Large-Modell von Mistral.
Spätestens jetzt wird klar, dass wir für unser Vorhaben einen eigenen Benchmark erstellen müssen. Doch mit welchen Daten?
Eine Recherche auf Plattformen, die entsprechende Datensätze zur Verfügung stellen (z.B. Hugging Face, Kaggle, and Papers With Code), sorgt für Ernüchterung. Hier sind nur sehr wenige deutschsprachige Datensätze für unser Open-Book-Question-Answering im Angebot. Und selbst der aussichtsreichste Kandidat lässt einiges zu wünschen übrig. Die einzelnen Antworten, also die Ground Truths, unterscheiden sich untereinander sehr in ihrer Beschaffenheit: mal sind sie komplette Sätze, mal Satzfragmente, manchmal sogar nur Stichworte. Mit einer solchen Varianz und Unbeständigkeit in den Antworten ist es äusserst schwierig, eine sinnvolle Metrik zu definieren, mit der sich die Ergebnisse der einzelnen LLMs vergleichen lassen.
Also müssen wir uns anderweitig nach einem geeigneten Datensatz umschauen. Eine Möglichkeit ist, einen solchen Datensatz selbst herzustellen – was jedoch beträchtlichen manuellen Aufwand erfordert und dementsprechend kostspielig ist. Eine praktischere Alternative besteht darin, einen bestehenden englischsprachigen Datensatz maschinell ins Deutsche zu übersetzen. Der DROP-Datensatz sticht hier als besonders geeignete Option hervor. Seine Aufgabenstellung entspricht in etwa einem RAG-System, und der Datensatz ist etabliert, d.h. er wird für viele Modelle verwendet.
Der Datensatz DROP (Discrete Reasoning over the Content of Paragraphs) wird manuell (d.h. per Crowdsourcing) erstellt und umfasst etwa 96'000 Fragen. Die Beantwortung der Fragen erfordert das Verstehen mehrerer Textpassagen eines Wikipedia-Artikels. Zu jedem Wikipedia-Artikel, der als Eingabekontext für die LLMs fungiert, gibt es in dem Datensatz mehrere Fragen.
Ein maschinell übersetztes Beispiel:
Kontext: Auf das gesamte County bezogen setzte sich die Bevölkerung zusammen aus 24,90% Einwohnern unter 18 Jahren, 7,20% zwischen 18 und 24 Jahren, 28,10% zwischen 25 und 44 Jahren, 23,60% zwischen 45 und 64 Jahren und 16,30% waren 65 Jahre alt oder darüber. Das Durchschnittsalter betrug 39 Jahre. Auf jeweils 100 Frauen entfielen 97,10 Männer. Bei den über 18-Jährigen entfielen auf 100 Frauen 93,6 Männer.
Frage: Wie viele Prozent der Bezirksbevölkerung waren nicht zwischen 18 und 24 Jahre alt
Antwort: 92,8%.
Für unseren deutschen DROP-Benchmark wählen wir 1000 Kontext-Fragen-Antworten-Einheiten aus und übersetzen sie ins Deutsche. Die Auswahlkriterien hierbei sind a) keine Fragen zu sportlichen Themen und b) keine mehrfachen Antwortmöglichkeiten. Die Übersetzung des Kontexts sowie der Frage-Antwort-Paare übernimmt der Translation Service von AWS.
Neben dem Datensatz brauchen wir noch eine Metrik, also ein standardisiertes Verfahren, mit dem wir die Antworten der LLMs mit der Ground Truth vergleichen. Dafür verwenden wir die beim DROP-Benchmark übliche Metrik, den F1-Score. Dabei handelt es sich um den Mittelwert zweier Grössen, der sogenannten Präzision zum einen und dem Recall zum anderen. Die Präzision gibt an, wie viele Wörter in der Antwort des LLM in der Ground Truth vorkommen, der Recall, wie viele Wörter der Ground Truth in der Antwort des LLM enthalten sind. Für den DROP-Datensatz ist der F1-Score eine geeignete Metrik, da die richtige Antwort der Ground Truth nur aus Zahlen, Namen oder sehr einfachen Sätzen besteht.
Um unser Benchmarking-Konzept einem ersten Test zu unterziehen, erstellen wir einen Benchmark mit den 1000 ausgewählten Datenpunkten im englischsprachigen Original. Bei jedem Modell kommt ein eigenes sogenanntes Prompt-Template zum Einsatz, das sich an der Dokumentation des jeweiligen Modells orientiert. Die Resultate:
Die Diskrepanz in den F1-Scores erklärt sich dadurch, dass bei den Prompt-Templates drei Beispiele von Kontext-Frage-Antwort-Einheiten angegeben wurden (3-Shot). Bei unserem Prompt-Template ist das aber nicht der Fall. Der F1-Score im technischen Bericht des Gemini-Modells von Google eignet sich nicht für einen Vergleich, da nicht ganz klar ist, wie dieser zustande kommt.
| F1-Score | GPT-4o | Claude 3 Opus | Mistral Large | Gemini 1.5 Pro | Llama 3 70B Instruct |
| Technischer Bericht | 83.4 | 83.1 | – | 78.9 | 79.7 |
| Unser Benchmark | 74.4 | 71.2 | 59.3 | 61.3 | 59.3 |
Die besten Modelle sind, in absteigender Reihenfolge, GPT-4o, Claude 3 Opus und Gemini 1.5 Pro.
Wenden wir uns nun unserem eigentlichen Vorhaben zu, dem Benchmarking mit deutschsprachigen Daten. Das Setup zur Bestimmung des F1-Scores bleibt identisch, lediglich werden alle englischsprachigen Daten und Prompt-Templates automatisiert ins Deutsche übersetzt. Das Ergebnis:
GPT-4o und Claude 3 Opus verbuchen wieder den ersten bzw. zweiten Platz für sich. Den dritten teilen sich nun Gemini 1.5 Pro und das Open-Source-Modell Llama 3 70B Instruct. Wie zu erwarten war, erzielen alle Modelle im deutschen Benchmark schlechtere Werte als im englischen Benchmark zuvor, was an den vorwiegend englischen Trainingsdaten liegt:
Den geringsten Unterschied zwischen englischen und deutschen Testwerten verzeichnet das Lllama-3-Modell für sich, das nicht nur in dieser Hinsicht eine Besonderheit darstellt.
Llama 3 70B Instruct ist das aktuellste unter den hier getesteten LLMs. In den ersten Durchläufen unseres Benchmarkings ging noch das Vorgängermodell Llama 2 70B Chat an den Start, was uns einen Vergleich mit dem Nachfolger ermöglicht:
Der Leistungsanstieg ist erstaunlich und hat die Situation grundlegend verändert: Davor waren in der Spitzengruppe unseres LLM-Rankings nur kommerzielle Modelle vertreten. Nun steht mit Llama 3 70B Instruct ein konkurrenzfähiges Open-Source-LLM zur Verfügung.
Aus Sicht der Anwendenden ist der hochdynamische Wettbewerb zwischen den verschiedenen Anbietern sehr positiv – vorausgesetzt, man verfügt über eine unabhängige Vergleichsmöglichkeit, wie unser Benchmark sie bietet.
Nachdem wir die Leistungsfähigkeit der Modelle in unserem Anwendungsbeispiel ermittelt haben, gilt es nun, die eingangs erwähnten nicht-funktionalen Kriterien zu berücksichtigen, die bei der Entscheidung für ein LLM eine ebenfalls wichtige Rolle spielen. Hier die grundlegenden Rahmenbedingungen der verschiedenen Anbieter und Modelle in einer kleinen Übersicht:
| Anbieter | Modell | Deployment- Optionen | Auftragsdaten-verarbeitungs-vertrag | Kosten | Modell- Kontrolle |
| OpenAI |
GPT-4o | Azure (Switzerland North) OpenAI |
Enterprise-ready | 0.007 | Gering |
| Mistral | Mistral Large |
AWS EU (Paris) |
Enterprise-ready | 0.0146 | Gering |
| Meta | Llama 3 70B Instruct | AWS US-East Own deploy-ment |
Enterprise-ready | 0.0021 | Hoch |
| Anthropic | Claude 3 Opus | AWS US-West Claude.ai platform Google Cloud (announced) |
Enterprise-ready | 0.027 | Gering |
| Gemini 1.5 Pro | Google Cloud | Enterprise-ready | 0.0049 | Gering |
Bei den Deployment-Optionen haben wir anfangs zwischen API Only und Own Deployment unterschieden. In der Spalte Deployment-Optionen sind mit Azure oder AWS die Anbieter für die Option API Only gemeint. Der gewählte Anbieter bestimmt die weiteren Kriterien. Die Einträge in den Spalten Auftragsdatenverarbeitungsvertrag, Kosten und Modellkontrolle beziehen sich jeweils auf den erstgenannten Anbieter.
Die Kosten werden bei allen Modellen pro Anzahl der Tokens berechnet. Ein Token kann man sich in etwa als ein Teilwort vorstellen. Sowohl die Tokens des Prompts (d.h. der Eingabe) als auch die Tokens der generierten Antwort (Output) sind kostenpflichtig und unterscheiden sich im Preis. Um einen Kostenvergleich zu ermöglichen, berechnen wir den durchschnittlichen Preis pro Token mit der Annahme, dass der Prompt im Vergleich zur Antwort ein Vierfaches an Tokens enthält. In der Tabelle oben sind die Preise in US-Dollar pro 1000 Tokens angegeben.
Die Auftragsdatenverarbeitungsverträge sind bei den Anbietern Google Vertex AI, Amazon Bedrock und Azure im Wesentlichen vergleichbar. Die Datenschutzanforderungen für die Verwendung eines LLMs werden bei diesen Anbietern erfüllt.
Ziehen wir neben der im Benchmark erzielten Ergebnisse (F1-Score) die Kosten als weiteres quantitatives Kriterium hinzu, so ergibt sich folgendes Bild:
Um nun endlich ein LLM auszuwählen, müssen wir die funktionalen und nicht-funktionalen Kriterien gegeneinander abwägen. Wie dieser Prozess ablaufen kann, wollen wir an zwei Szenarien für unseren Anwendungsfall, einen RAG-basierten Chatbot, veranschaulichen:
Szenario A: Die Mitarbeitenden verwenden den Chatbot, um Anfragen von Kunden zu beantworten. Vor der Einführung wurden die generierten Antworten ausführlich getestet. In einer nachfolgenden Ausbauphase ist die vollautomatische Beantwortung von Kundenanfragen geplant.
Szenario B: Der Chatbot dient den Mitarbeitenden als weitere Informationsmöglichkeit neben der Intranet-Suche.
In Szenario A ist die fehlende Kontrolle über das Modell ein Ausschlusskriterium. Ein vom Anbieter oder Betreiber forcierter Wechsel des LLMs ist aus Business-Sicht inakzeptabel, da das Ende eines Lebenszyklus oft kurzfristig angekündigt wird und erhebliche interne Aufwände verursachen kann. Hier kommt also nur ein Open-Source-Modell infrage, d.h. Llama 3 70B Instruct, das wir ohne Weiteres bei einem Hyperscaler betreiben können. Wichtig ist allerdings, dass das Deployment des Modells aus einem eigenen Download erfolgt.
In Szenario B stehen mehrere Möglichkeiten offen. Die Modellkontrolle fällt nicht allzu schwer ins Gewicht, und die Auftragsdatenverarbeitungsverträge der Anbieter sind vertretbar. Hier würde es naheliegen, das im Kosten-Performance-Vergleich beste Modell zu wählen. Gemäss der Evaluation oben bieten sich GPT-4o, Gemini 1.5 Pro und Llama 3 70B Instruct an.
Die Frage der Modellwahl können wir aber auch von einer anderen Perspektive aus angehen. Wie bereits erwähnt, besteht momentan ein intensiver Wettbewerb zwischen den Anbietern, und jeden Monat hat ein anderer die Nase vorn. Daher ist es mit der einmaligen Frage nach dem gegenwärtig leistungsstärksten Modell nicht getan. Wie das LLM von Meta zeigt, ist von einem Modell zum nächsten ein ausserordentlicher Leistungszuwachs möglich, während in anderen Fällen die Qualitätssprünge vernachlässigbar sind. Mit einem kontinuierlichen Benchmarking können wir diese Marktentwicklungen mitverfolgen und objektiv entscheiden, ob ein Wechsel des LLMs gerechtfertigt ist. Aus diesem Blickwinkel ist der Wechsel des LLMs Teil des Konzepts.
Damit stellt sich die Frage nach dem optimalen Hosting-Anbieter. Idealerweise sollte er die meisten Modelle bereitstellen können und einen Wechsel des LLMs möglichst einfach und kostengünstig machen. AWS hat, wie die Tabelle oben zeigt, nicht nur die meisten Modelle im Angebot. Mit der Plattform AWS Bedrock ist zudem ein Wechsel des LLMs mit geringem Aufwand möglich. Darüber hinaus kann AWS eine gewisse Neutralität zwischen den verschiedenen Modellen für sich beanspruchen, da das Amazon-LLM (zumindest vorläufig) nicht konkurrenzfähig ist.
Bei der Wahl des richtigen LLMs fliessen unzählige Faktoren in den Entscheidungsprozess ein. Besonders die nicht-funktionalen Aspekte verlangen eine sorgfältige Abwägung und ein hohes Mass an Fingerspitzengefühl, um alle relevanten Gesichtspunkte und Bedingungen angemessen zu berücksichtigen. Was ist der Anwendungsfall? Wie gut ist die IT-Infrastruktur aufgestellt? Ist der Datenschutz gewährleistet? Wie viele Kapazitäten stehen beim IT-Personal zur Verfügung, und wie gross ist das Budget? Das sind nur einige der Überlegungen, die Unternehmen und Organisationen vor der Einführung eines LLMs anstellen müssen.
Glücklicherweise ist die Bewertung der funktionalen Kriterien mit dem von uns entwickelten LLM-Benchmarking wesentlich unkomplizierter. Unsere kontinuierliche Evaluierung von bestehenden und neuen LLMs gibt Ihnen ein wertvolles Instrument in die Hand, mit dem Sie das optimale Angebot für Ihre Zwecke bestimmen und erkennen, wann sich der Umstieg auf ein neues (Konkurrenz-)Modell finanziell und operativ lohnt.
Die hier präsentierten Resultate sind nur ein kleiner Ausschnitt aus unserem Benchmarking. Und wie sich die Technologie der LLMs rasant weiterentwickelt, optimieren und expandieren wir stetig unsere Testverfahren. So ziehen wir kontinuierlich neue Modelle in unsere Bewertung ein und planen, weitere Sprachen in unser Benchmarking zu integrieren, allen voran Französisch und Italienisch.
Wenn Sie von den Vorteilen eines LLMs profitieren möchten, stehen wir Ihnen gerne zur Seite. Mit unserer genauen Beobachtung der technologischen Entwicklung, der Erprobung neuer Angebote und der eigenen Anwendung grosser Sprachmodelle verfügen wir über die Erfahrung und Expertise, die selbst in einer turbulenten Marktlage eine nachhaltig erfolgreiche LLM-Strategie ermöglichen.