Would you like to know more about our products or do you have a question?
Open Source LLMs (Large Language Models) beherrschen zunehmend deutsch — ein Meilenstein, welcher den Einsatz von generativen KI-Systemen auf Basis von Open Source im deutschsprachigen Raum stark erleichtert und zu einer potenziellen Alternative zu Closed Source Modellen wie ChatGPT und Co. macht. Doch warum müssen große Sprachmodelle überhaupt deutsch (oder andere Sprachen) können?
In diesem Artikel möchte ich einen Überblick über die Problemstellung und meine alltäglichen Erfahrungen als Data Scientist im Umgang mit aktuellen Open Source Text-To-Text Models in deutscher Sprache geben.
Warum Open Source LLMs? Diese Frage wurde mir, insbesondere kurz nach der Veröffentlichung von ChatGPT, häufig und nicht selten mit großer Skepsis verbunden gestellt.
Doch was 2022 noch als unwahrscheinlich galt, ist spätestens mit der Veröffentlichung von Metas LLaMA-2 und der Modellfamilie von Mistral (einem französischen Startup) 2023 Realität geworden: Generative KI-Systeme (GenAI) auf Basis von Open Source LLMs sind gemessen anhand ihrer Fähigkeiten auf Augenhöhe mit sogenannten Closed Source Anbietern und Modellen wie jenen von OpenAI, Google, Anthrophic und Co. oder übertreffen diese je nach Anwendungsfall bereits.
Die Vorteile von Open Source Modellen gegenüber Closed Source sind darüber hinaus vielfältig:
So viel zu den Vorteilen und Argumenten für Open Source. Doch bei allen Vorteilen und überragenden Benchmarks (welche übrigens immer mit Vorsicht zu betrachten sind, da standardisierte Tests nicht unbedingt die tatsächliche Praxis abbilden) hatten Open Source LLMs lange Zeit einen entscheidenden Nachteil: Sie konnten kein oder nur sehr schlecht deutsch oder andere europäische Sprachen. Da die meisten Modelle überwiegend mit englischen Texten und Beispielen trainiert wurden, erreichen diese ihre Performance nur in englischer Sprache und haben auch dort ihre Stärken.
Was für einen Großteil der weltweiten (englischsprachigen) Nutzer kein Problem darstellen mag, hat in der Praxis für viele Anwendungsfälle gravierende Auswirkungen und hat die Nutzung von Open Source Modellen mit all ihren Vorteilen (insbesondere im unternehmerischen Umfeld) im deutschsprachigen Raum massiv eingeschränkt und war lange Zeit ein Argument für Closed Source Systeme wie ChatGPT und co.
Für viele Anwendungsfälle muss das KI-System in der Lage sein, deutsche Sprache zu verstehen und grammatikalisch korrekte und richtige Antworten zu generieren. Dazu ein paar Beispiele und Problemstellungen, welchen ich in unterschiedlichen Projekten begegnet bin:
Die Liste ließe sich theoretisch beliebig fortsetzen. Überall, wo automatisiert Texte verarbeitet, erstellt oder Informationen extrahiert werden sollen, ist es unerlässlich, dass LLMs die jeweilige Sprache beherrschen. Dies fällt umso mehr ins Gewicht, je fachspezifischer die Begriffe und der Kontext der Anwendungsfälle ist. So wird auch ein LLM mit wenig Deutschkenntnissen eher in der Lage sein, brauchbare Antworten zu allgemeinen Fragestellungen wie z. B. dem Wetter zu generieren oder diese zu verstehen als dem deutschen Steuerrecht, wo viele sehr fachspezifische Begriffe auf Beamtendeutsch treffen.
Unabhängig von den sprachlichen Fähigkeiten, ob Open oder Closed Source und wie universell und leistungsfähig aktuelle LLMs sind, gibt es eine übergreifende Einschränkung: LLMs haben nur Wissen und können nur auf das (korrekt) antworten, was ihnen im Rahmen ihres aufwendigen Trainingsprozesses beigebracht wurde. Im Rahmen von ChatGPT mit GPT 3.5 Turbo reicht das (trainierte) Wissen z.B. nach wie vor nur bis 2021. Für Fragen zu Ereignissen, Produkten oder Erkenntnissen danach, hätte das Modell keine Antwort oder würde halluzinieren. Für viele Anwendungsfälle (insbesondere in Unternehmen), ist jedoch der Zugriff auf interne Dokumente oder Daten essentiell.
Die Antwort (abseits von einem aufwendigen Finetuning) sind sogenannte RAG (Retrieval Augmended Generation) Systeme.
Dazu ein kleine Einführung in die Welt der RAG-Systeme: Obwohl der mediale Fokus auf LLMs liegt, sind RAG-Anwendungen die eigentlichen Shootingstars. Mit diesen ist es möglich, einem LLM beliebige Dokumente oder Informationen als zusätzliche Wissensquellen zur Verfügung zu stellen, in welchen dann nach Antworten zu Frage- oder Problemstellungen gesucht werden kann. Man spricht bei solchen Systemen auch von Information Retrieval (IR) Systemen. Ohne solche Systeme müsste zusätzliches Wissen (z.B. firmeninterne Dokumente) in einem aufwendigen Trainingsprozess einem LLM nachtrainiert werden und könnte auch gar nicht ohne weiteres wieder “verlernt” werden (Stand 01/24 nach wie vor eine große Problematik). Unter folgendem Link findet man eine, wie ich finde, sehr gute Zusammenfassung und Erklärung zur Funktionsweise eines RAG-Systems:
Ein RAG-System besteht aus mehreren Komponenten, wobei neben einem LLM sogenannte Text-Embedding-Modelle eine zentrale Rolle spielen. Bei diesen handelt es sich um eine spezielle Art von LLMs (überwiegend Encoder-Only Modelle), welche anders als die autoregressiven Modelle (Decoder-Only) wie jenen hinter ChatGPT keine “neuen” Texte generieren und ausgeben, sondern Eingabetexte in Zahlenvektoren, sogenannte Embeddings “übersetzen”. Das Besondere dabei ist, dass die Embedding-Modelle dabei den Kontext und die Bedeutung der jeweiligen Texte in dem Merkmalsvektor persistieren können. Mit diesen wird es Computern ermöglicht, inhaltlich ähnliche Texte auch in großen Textmengen, nur anhand dieser Embeddings zu suchen, zu vergleichen und auszugeben. Damit können aus einer riesigen Textmenge jeweils die Abschnitte oder Teile gesucht werden (Ausgabe), welche für eine Fragestellung (Eingabe) relevant sind. Für prominente Beispiele solcher Systeme muss man nicht lang suchen: Alphabet als Forschungstreiber und Pionier der Transformer Architektur nutzt z.B. solche angepassten Modelle (Bi- & Cross-Encoder) im Hintergrund seiner Google Suchmaschine, um für eine Suchanfrage die Ergebnisse mit der höchsten inhaltlichen Übereinstimmung anzuzeigen und zu ranken.
Im unternehmerischen Kontext könnte ein Beispiel z. B. wie folgt aussehen:
Ich habe eine Anwendungsdokumentation in PDF-Form. Diese ist 200 Seiten lang. Im ersten Schritt würde ich nun von einem Text-Embedding-Modell für jede Seite dieser Dokumentation die Embedding-Vektoren berechnen lassen und diese speichern.
Wenn ich nun eine Frage zu der Anwendungsdokumentation habe, z.B. wie ich einen neuen Benutzer anlegen kann, dann wird diese Frage ebenfalls von dem Text-Embedding-Modell in einen Embeddingvektor transformiert und im zweiten Schritt mit allen 200 Embedding-Vektoren aus Schritt 1 verglichen. Am Ende werden mir die Seiten der Dokumentation zurückgegeben, welche (anhand der Embedding-Vektoren) die höchste Ähnlichkeit und damit inhaltliche Übereinstimmung mit meiner Frage haben.
Damit dies jedoch gut funktioniert, muss das Embedding-Modell in der Lage sein, die Wörter und den Kontext in der gewünschten Sprache zu verstehen. Dies kann es nur, wenn es vorher auch auf deutsch (oder der gewünschten Sprache) trainiert wurde und über das notwendige Vokabular verfügt. Deshalb ist es auch bei Embedding-Modellen essentiell wichtig, dass diese die jeweilige Sprache beherrschen und in ihren Parametern abbilden. Tatsächlich waren und sind viele Open Source Embedding-Modelle lange rein monolingual gewesen und wurden überwiegend für englische Sprache und Texte optimiert. Dies machte deutschsprachige SOTA (State -of-the-Art) RAG-Systeme auf Basis von Open Source Modellen in deutscher oder anderer Sprache sehr schwierig und führte dazu, dass lange Zeit Closed Source Text-Embedding-Modelle wie OpenAIs multilinguale Ada-Familie der Standard waren.
Dies hat sich geändert. Sowohl für autoregressive LLMs wie jenen hinter ChatGPT (Decoder), als auch für Text-Embedding-Modelle (Bi- oder Cross-Encoder) haben sich hervorragende Open Source Alternativen entwickelt, mit welchen in deutscher, als auch vielen anderen Sprachen (oder Cross-Lingual) gearbeitet werden kann.
Der Grund warum dies lange Zeit nicht oder nur eingeschränkt möglich war, ist, dass viele der Modelle im Rahmen ihres Training-Prozesses (sowohl im Pre-Training, bei welchem grundlegendes Textverständnis vermittelt wird, als auch dem Instruction Finetuning, welches einem LLM Aufgabenstellungen beibringt) schlicht keine oder kaum Trainingsdaten in deutsch oder der gewünschten Sprache zur Verfügung hatten und darauf trainiert wurden. Dabei zeigt sich erfahrungsgemäß, dass größere Open Source Modelle (>70b Parameter), eher dazu neigen auch andere Sprachen zu beherrschen, als kleinere (<13b), da bei größeren die Wahrscheinlichkeit höher ist, dass in dem Trainingscorpus Texte der gewünschten Sprache vorhanden waren. Dies ist misslich, da insbesondere die kleinen Open Source LLMs für den unternehmerischen Einsatz interessant sind, weil diese leichter, günstiger und mit weniger Aufwand selbst betrieben werden können (siehe Vorteile Open Source).
Als Workarounds wurden deshalb häufig zwei Ansätze verfolgt:
Nachträgliches Finetuning: Es wird ein (englischsprachiges) SOTA LLM genommen und durch Finetuning auf verschiedenen Datensätzen in der gewünschten Sprache versucht, dem LLM diese nachträglich beizubringen. Da bei diesem Ansatz “nur” Wissen nachtrainiert werden muss, hält sich der Zeit- und Ressourcenaufwand im Vergleich zum Training eines neuen LLMs in Grenzen. Dennoch ist der Aufwand nicht zu unterschätzen und die Ergebnisse mitunter sehr durchwachsen und nicht vergleichbar mit Modellen, welche bereits in ihrem Pre-Training die jeweilige Sprache hatten. Je nach Finetuning-Art kann es durchaus auch vorkommen, dass sich ein Modell durch das Finetuning sogar deutlich verschlechtert, Downstream Tasks (Aufgaben, wie das Übersetzen von Text) nicht mehr ausführen kann oder Sicherheitsrichtlinien nicht mehr entspricht.
Nutzung eines Übersetzers: Die zweite Möglichkeit wäre, die Ein- und Ausgaben schlichtweg von einem Übersetzer (z. B. ein anderes LLM) aus oder in die gewünschte Sprache übersetzen zu lassen. So nimmt man sich ein beliebiges Modell und übersetzt z. B. eine deutsche Frage vorher ins englische bevor man die Anfrage an das LLM sendet. Umgekehrt übersetzt man sich anschließend die Ausgabe zurück ins deutsche.
Dies mag in der Theorie und für den einen oder anderen Use Case durchaus funktionieren, jedoch kommt dieser Ansatz in der Praxis mit einem sehr hohen Overhead daher. Denn jede Anfrage / Ausgabe muss nun zusätzlich von einem zusätzlichen Modell übersetzt werden. Für Use Cases, bei denen ein hoher Durchsatz und eine geringe Latenz wichtig sind, würde dieser Ansatz schnell zu Flaschenhälsen führen. Davon abgesehen bringen Übersetzungen weitere Möglichkeiten für Abweichungen oder Fehlerquellen.
Als beste und eleganteste Möglichkeit gelten deshalb LLMs, welche direkt auf und mit (hochwertigen!) Daten der jeweiligen Sprache trainiert wurden.
Mittlerweile gibt es eine ganze Liste verschiedener LLMs (Decoder-Only als auch Encoder-Only), welche multilingual sind und beinahe im Wochentakt werden neue und bessere veröffentlicht, weshalb die folgenden Modelle auf meinen persönlichen Erfahrungen und Recherchen mit Stand März 2024 basieren:
Causal-Decoder-Modelle:
Encoder-Modelle (Embeddings):
Die Modelle können alle bei Hugging Face gefunden werden. Persönlich habe ich häufig die Erfahrung gemacht, dass standardisierte Benchmarks wie der MT Bench oder MMLU nicht unbedingt aussagekräftig sind, wenn es um die Beurteilung der Sprachfertigkeiten von Modellen geht. Häufig haben selbst kleinste Änderungen im Prompting große Auswirkungen auf die Qualität der Antwort (was übrigens allgemein für die meisten LLMs gilt) und Grammatik/Schreibstil (welcher meines Wissens nach aktuell von keinem Benchmark berücksichtigt wird). Deshalb kann es sich häufig durchaus lohnen, auch kleine oder “schlechter” gerankte Modelle auszuprobieren oder zu testen. Ich persönlich habe sehr gute Erfahrungen mit dem 7B Modell von DiscoLM gemacht (Danke auch LeoLM für ihre tolle Arbeit und Unterstützung), welches durch seine geringe Größe (als GPTQ noch kleiner) auch auf kleiner Hardware betrieben werden kann und durch Fingerspitzengefühl beim Prompting hervorragende Ergebnisse liefert. Wie bereits besprochen, hat natürlich die Größe des jeweiligen Modells einen Einfluss auf die Qualität. Wer die GPU-Ressourcen hat, kann gleich zum Vanilla Mixtral-8x-7b oder der weiter feingetuned deutschen Version von SauerkrautLM greifen. Persönlich markieren diese für aktuell die Spitze des Eisbergs und sind sprachlich auf einer Ebene mit ChatGPT/ GPT4 und Co.
Bei den Embedding-Modellen waren lange Zeit die Modelle der multilingual-e5-large Reihe das Mittel der Wahl (und sind es immer noch). Mit den Anfang 2024 erschienenen Modellen von Jinaai und BGE-M3 sind jedoch auch weitere sehr interessante multilinguale Alternativen erschienen. Diese sind (wie z. B. das multilingual-e5-large-instruct Modell) im MTEB Benchmark, Stand März 2024, bereits gleichauf oder sogar besser als Closed Source Modelle wie OpenAIs Text-Embedding-V3 Modell. Deutschsprachige SOTA RAG-Anwendungen auf Basis von Open Source sind damit (theoretisch) ohne Probleme auf gleichem Level möglich.
Wer auf dem aktuellen Stand bleiben möchte, sollte ein Auge auf die Hugging Face Leaderboards werfen:
Mit der “unfreiwilligen” Veröffentlichung der Meta LLaMA-Modell-Familie 2023 und der darauf aufbauend rasend schnellen Entwicklung und Verbreitung von Feingetuned Instruction Modellen, wie Vicuna oder Dolly, hat Meta der Open Source Entwicklung im Bereich GenAI einen unglaublichen Kickstart gegeben. Wo vorher Encoder-Decoder Modelle wie Googles Flan-T5 Serie, oder Encoder-Modelle wie RoBERTA, insbesondere für kommerzielle Use Cases die erste Wahl waren, gibt es nun eine Vielzahl an leistungsfähigen (und von der Größe handelbaren) Decoder-Only Modellen. Durch die häufig noch fehlenden oder mangelhaften sprachlichen Fähigkeiten, konnten die wenigsten Modelle jedoch für deutschsprachige Problemstellungen eingesetzt werden.
Mit den Veröffentlichungen der letzten Monate und insbesondere der Modellreihe von Mistral und den darauf basierenden Varianten hat sich dies geändert. Generative Open Source LLMs sind nun auch im deutschsprachigen Raum für viele Anwendungsfälle eine realistische Alternative zu ChatGPT & Co. und ermöglichen es, wirklich eigene KI-Systeme ohne Abhängigkeiten von Dritten zu entwickeln und zu nutzen. Während Big-Tech mit ihren großen Closed Source KI-Systemen einer AGI (Artificial General Intelligence) immer näher kommt, so sind meiner Meinung nach für viele Anwendungsfälle kleinere, aber spezialisierte Open Source Modelle die ausreichende und womöglich deutlich bessere Alternative.
