Warum dieser Artikel?
Einleitung
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 Bedeutung multilingualer LLMs basierend auf meinen alltäglichen Erfahrungen als Data Scientist im Umgang mit aktuellen Open Source Text-To-Text Models in deutscher Sprache geben.
Inhalt und Aufbau des Artikels
In diesem Artikel möchte ich auf folgende Punkte eingehen:
1. Open Source LLMs als (bessere) Alternative zu ChatGPT?
2. Warum Open Source LLMs deutsch (oder die jeweilige Sprache) können müssen
3. Die Bedeutung deutschsprachiger LLMs für RAG-Systeme
4. Wieso können nicht alle LLMs deutsch?
5. Welche deutschen Open Source LLMs gibt es aktuell?
6. Fazit
Open Source LLMs als (bessere) Alternative zu ChatGPT?
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:
- Kein Vendor Lock: Bei der Nutzung von Open Source LLMs ist man nicht von der Preispolitik oder Änderungen eines Anbieters abhängig. Bei Bedarf können Modelle und Anbieter beliebig ausgetauscht, angepasst oder entfernt werden.
- Open Source hat je nach Anwendungsfall einen Preisvorteil: Die Nutzung von Closed Source Modellen ist mit nutzungsabhängigen Gebühren verbunden. Für Anpassungen und Training fallen gesonderte Kosten an. Insbesondere bei der Nutzung von angepassten Modellen im Rahmen eines Fine-Tunings werden deutlich höhere Kosten berechnet. Natürlich verursacht das Hosting von Open Source Modellen ebenfalls konstante Kosten, welche maßgeblich von der Größe der Modelle und der Anzahl Gewichte bestimmt wird. Diese Kosten müssen natürlich gegengerechnet werden. Um so mehr Bedeutung kommt deshalb der aktuellen Entwicklung hin zu kleineren Open Source Modellen zu, welche mit deutlich niedrigeren Kosten betrieben werden können (und für viele Use Cases auch vollkommen reichen, siehe nächster Punkt).
- Es braucht in den wenigsten Fällen generalistische KI-Systeme oder LLMs: Modelle wie GPT-3 oder GPT-4 sind sehr starke Generalisten, welche sehr viele unterschiedliche Anwendungsfälle und Aufgaben abdecken können. In der Praxis, insbesondere im unternehmerischen Umfeld, braucht es jedoch häufig keine derart generalistischen Modelle! LLMs müssen nur einzelne Aufgaben können. Open Source Modelle bieten hier deutliche Vorteile, da diese leicht anzupassen, klein und gleichzeitig leistungsfähig sind.
- Verlässlichkeit: Bei der Nutzung von eigenen Open Source LLMs hat man 100%ige Kontrolle über die Änderungen am LLM und wie diese funktionieren. Closed Source Modelle wie GPT-3 / 4 werden konstant angepasst, was dazu führen kann, dass sich das Verhalten der Modelle im Laufe der Zeit verändert. Dies hat Auswirkungen auf die Performance und sorgt dafür, dass Pipelines, Prompts und Prozesse kontinuierlich angepasst werden müssen oder ggf. von einem Tag zum nächsten nicht mehr wie gewünscht funktionieren.
- Kontrolle über Daten und Datenschutz: Beim Datenschutz fällt einem sofort die DSGVO und der Schutz von personenbezogenen Daten ein. Closed Source Modelle haben ihre Rechenzentren häufig im nicht europäischen Ausland und durch den Black-Box-Charakter, kann auch nicht immer sicher aufgezeigt werden, wie personenbezogene Daten genau verarbeitet werden und letztendlich muss man sich auf das Versprechen der Hersteller / Anbieter verlassen. Doch auch wenn keine personenbezogenen Daten im Spiel sind, spielen LLMs und darauf basierende KI-Systeme ihre Stärken erst im Umgang mit firmeninternen oder vertraulichen Daten aus, welche dafür an die Server und Systeme der Hersteller übertragen oder gespeichert werden müssen (z. B. im Kontext von RAG-Anwendungen oder Fine-Tuning). Es stellen sich damit die gleichen Frage- und Problemstellungen wie bei allen Public-Cloud Anwendungen. Open Source Modelle bieten die Möglichkeit, auf eigener Infrastruktur (On-Prem) oder einem Rechenzentrum des Vertrauens (Private Cloud) betrieben zu werden. Open Source ermöglicht damit mehr Kontrolle und Datensouveränität.
- Regulierung und Copy-Right: Insbesondere mit Blick auf den AI-Act und etwaige Copy-Right-Klagen ist es wichtig, dass LLMs, der Trainingsprozess und die verwendeten Daten nachvollziehbar und überprüfbar sind. Dies ist bei vielen Open Source Modellen deutlich einfacher, da sowohl die Trainingsmethoden, als auch die verwendeten Datensätze überprüf- und einsehbar sind.
- Open Source Modelle ermöglichen eine wirklich EIGENE KI: Closed Source KI-Modelle von z. B. OpenAI werden auf Basis der Nutzung “gemietet” und abgerechnet. Sie sind PaaS/SaaS (Platform/Software as a Service). Einem Unternehmen, welches eine Anwendung auf Basis eines Closed Source Modells wie GPT-4 entwickelt, besitzt keine Rechte an dem KI-Modell. Mit einem Open Source Modell schafft sich ein Unternehmen ein eigenes Asset, welches dem Unternehmen (im Rahmen der jeweiligen Open Source Lizenzen) auch tatsächlich gehört.
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.
Warum Open Source LLMs deutsch (oder die jeweilige Sprache) können müssen
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:
- Das automatisierte Erzeugen von SEO-gerechten Produktbeschreibungen — Problem(e): Beschreibungen, welche nicht richtig oder grammatikalisch falsch formuliert sind, machen keinen seriösen Eindruck und können das SEO Rating negativ beeinflussen, wenn diese unnatürliche Wort- oder Satzfolgen aufweisen, welche nicht häufig gesucht werden.
- Das automatische Ausfüllen von Profilen und Generieren von Infotexten auf Basis von Websites — Problem(e): Der erste Eindruck zählt. Profile oder Texte, welche nicht natürlich klingen, erzeugen kein Vertrauen. Zusätzlich können wichtige Informationen nicht erkannt oder in einem falschen Kontext wiedergegeben werden. Das Profil könnte damit inhaltlich falsche Informationen oder Texte enthalten.
- Übersetzung — Problem(e): Der Klassiker. Falsch übersetzte Texte führen zu Missverständnissen oder falschen Aussagen und machen das KI-System damit unzuverlässig.
- Segmentierung und Auswertung Kundenbewertungen oder Anfragen — Problem(e): Wenn Kunden Fragen haben, muss ein KI-System in der Lage sein, sowohl die Frage- als auch Problemstellung korrekt zu verstehen und zu beantworten. Wenn das System die Fragen nicht versteht, weil es Wörter oder deren Kontext in Sätzen nicht kennt, ist die Wahrscheinlichkeit für Fehler hoch.
- Sicherheit: Um sicherzustellen, dass LLMs keine unerwünschten oder gefährlichen Ausgaben und Antworten generieren, werden vielfach sogenannte System-Prompts oder Moderationssysteme verwendet. In und mit diesen wird beschrieben, was und wie ein LLM auf eine Nutzeranfrage antworten darf oder eben auch nicht. Eine Anfrage eines Nutzers wird damit immer zuerst im Kontext des System- bzw. Moderations-Prompt geprüft, bevor eine Antwort generiert wird. Damit dies aber vernünftig funktioniert, muss das LLM die Sprache der Anfrage ausreichend beherrschen, um den Kontext und damit einen möglichen Verstoß gegen eine Richtlinie erkennen zu können.
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.
Die Bedeutung deutschsprachiger LLMs für RAG-Systeme
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.
Wieso können nicht alle LLMs deutsch?
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.
Welche deutschen Open Source LLMs gibt es aktuell?
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:
[UPDATE 07/24] mistralai/Mistral-Nemo-Instruct-2407: mit 12B Parametern mein neuer persönlicher Favorit — wer es noch kleiner braucht, sollte einen Blick auf folgende quantisierte Version mit 2.8B werfen: shuyuej/Mistral-Nemo-Instruct-2407-GPTQ.
- DiscoResearch/DiscoLM_German_7b_v1 (der Nachfolger der EM Serie)
- mistralai/Mixtral-8x7B-Instruct-v0.1
- VAGOsolutions/SauerkrautLM-Mixtral-8x7B-Instruct
- LeoLM/leo-mistral-hessianai-7b
Encoder-Modelle (Embeddings):
- intfloat/multilingual-e5-large-instruct
- BAAI/bge-m3
- jinaai/jina-embeddings-v2-base-de
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. Persönlich habe ich 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.
[UPDATE 07/24] Im Juli 2024 hat Mistral seine neuen Nemo Modelle herausgebracht, welche es in Zusammenarbeit mit NVIDIA trainiert hat. Diese sind direkt multilingual angelegt und das Nemo-Instruct-2407 ist in seinen sprachlichen als auch allgemeinen Fähigkeiten in Relation zu seiner Größe absolut bemerkenswert. Für den Betrieb auf kleiner Hardware (≤ 24GB VRAM) kann ich die GPTQ-Version empfehlen, welche mit knapp 2.8B Parametern sehr gut funktioniert.
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:
- MTEB Leaderboard: https://huggingface.co/spaces/mteb/leaderboard
- Open LLM Leaderboard: https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard
Fazit
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.
Ich freue mich über Feedback oder jeden Austausch zu anderen Erfahrungen!
0 Kommentare