LLMs und deutsche Sprache: Was bei deutschsprachigen Eingaben zu beachten ist

Fast jedes Projekt mit LLMs und deutscher Sprache beginnt mit derselben stillen Annahme: Was mit englischen Texten funktioniert, funktioniert mit deutschen genauso. Die Dokumentation der Anbieter ist englisch, die Beispiele sind englisch, die Benchmarks sind englisch. Die eigenen Daten aber sind es nicht. Verträge, Support-Tickets, interne Notizen, Behördenschreiben: In einem österreichischen Unternehmen ist der Alltag deutschsprachig, oft mit regionaler Färbung.

Die großen Modelle beherrschen Deutsch inzwischen gut, das ist nicht der Punkt. Der Punkt ist, dass Deutsch nicht gratis ist. Es kostet mehr Tokens, es verhält sich in Grenzfällen anders, und es bringt eigene Fallstricke mit, von Komposita über Fachsprache bis zur Frage, in welcher Sprache der System-Prompt geschrieben gehört. Wer diese Effekte kennt, plant realistischer und misst an den richtigen Stellen.

Tokenizer und Komposita: warum Deutsch mehr kostet

Sprachmodelle verarbeiten Text nicht als Wörter, sondern als Tokens: Bruchstücke, die der Tokenizer aus seinen Trainingsdaten gelernt hat. Diese Trainingsdaten sind überwiegend englisch. Häufige englische Wörter sind deshalb oft ein einziges Token, während deutsche Wörter in mehrere Bruchstücke zerfallen. Besonders betroffen sind Komposita, also genau die Wortbildung, die das Deutsche so gerne nutzt. Ein Begriff wie Grundstücksverkehrskommission wird nicht als ein Token gespeichert, sondern in eine Kette von Teilstücken zerlegt.

Das hat drei praktische Folgen. Erstens die Kosten: Abgerechnet wird pro Token, und derselbe Inhalt braucht auf Deutsch spürbar mehr Tokens als auf Englisch. Zweitens der Kontext: Das Kontextfenster ist in Tokens bemessen, deutsche Dokumente füllen es schneller. Ein Retrieval-System, das mit englischen Texten bequem zwanzig Passagen unterbringt, schafft mit deutschen entsprechend weniger. Drittens die Latenz: Mehr Ausgabe-Tokens bedeuten längere Antwortzeiten.

Die richtige Reaktion ist nüchtern: den Tokenizer des eingesetzten Modells auf einer Stichprobe der eigenen Dokumente laufen lassen und den Faktor gegenüber der Kalkulation messen. Wer seine Kostenschätzung auf englischen Beispieltexten aufgebaut hat, sollte sie mit echten deutschen Daten nachrechnen, bevor Budgets festgeschrieben werden.

Qualitätsunterschiede messen statt vermuten

Ob ein Modell auf Deutsch schlechter arbeitet als auf Englisch, lässt sich nicht pauschal beantworten, und genau deshalb sollte man es auch nicht pauschal annehmen. Die ehrliche Antwort lautet: Es hängt von der Aufgabe ab, und man muss es messen. Ein Eval-Set mit deutschsprachigen Prüffällen aus dem eigenen Anwendungsfall ist dafür das Werkzeug der Wahl. Wer bereits Evals betreibt, ergänzt sie um deutsche Fälle. Wer keine hat, beginnt am besten hier.

Erfahrungswerte aus der Praxis geben zumindest eine Richtung, wo man zuerst hinschauen sollte. Grammatik und Idiomatik sind bei den großen Modellen selten das Problem, bei kleineren offenen Modellen dagegen häufiger. Auffälliger sind weiche Verschiebungen: Formatvorgaben werden auf Deutsch manchmal weniger zuverlässig eingehalten, die Anrede wechselt ungefragt zwischen Du und Sie, und bei strukturierter Extraktion leiden Feldnamen, wenn Schema und Text sprachlich gemischt sind. All das sind messbare Eigenschaften, keine Geschmacksfragen. Ein Prüffall-Katalog mit einigen Dutzend realen deutschen Eingaben deckt solche Muster schnell auf.

Fachsprache, Amtsdeutsch und österreichische Besonderheiten

Deutsch ist nicht gleich Deutsch. Die Trainingsdaten der Modelle enthalten deutlich mehr bundesdeutsche als österreichische Texte. Für Alltagssprache ist das egal, für Fachsprache nicht. Österreichische Rechts- und Verwaltungsbegriffe unterscheiden sich teils erheblich von den deutschen Entsprechungen, und ein Modell neigt dazu, den statistisch häufigeren Begriff zu wählen. Im harmlosen Fall wirkt ein Text dann nur fremd. Im weniger harmlosen Fall ersetzt das Modell einen österreichischen Fachbegriff durch einen deutschen, der fachlich etwas anderes bedeutet.

Dazu kommt das Amtsdeutsch: verschachtelte Sätze, Verweisketten, Abkürzungen, die nur im jeweiligen Verwaltungskontext eindeutig sind. Modelle fassen solche Texte oft flüssig zusammen, glätten dabei aber genau die Präzision weg, auf die es ankommt.

Bewährt haben sich drei Gegenmaßnahmen:

• Glossar im Kontext: die relevanten Fachbegriffe samt kurzer Definition mitgeben und anweisen, exakt diese Terminologie zu verwenden.
• Terminologie-Prüfung in den Evals: prüfen, ob geschützte Begriffe unverändert übernommen und nicht durch Synonyme ersetzt wurden.
• Formate festnageln: Datums-, Zahlen- und Währungsformate explizit vorgeben, statt sich auf die Locale-Intuition des Modells zu verlassen.

System-Prompt: Deutsch oder Englisch

Die Frage kommt in jedem Projekt: Sollen die Anweisungen an das Modell auf Deutsch oder auf Englisch formuliert werden. Beide Lager haben Argumente. Für Englisch spricht, dass Modelle auf englische Instruktionen trainiert und getestet werden und komplexe Anweisungen dort oft robuster befolgen. Für Deutsch spricht, dass ein durchgehend deutscher Kontext weniger Anlass für Sprachmischungen gibt.

In der Praxis hat sich eine Trennung bewährt. Die technische Steuerung, also Rollenbeschreibung, Regeln, Schemadefinitionen, funktioniert auf Englisch zuverlässig, sofern die Zielsprache der Ausgabe unmissverständlich festgelegt ist. Alles, was den Ton der Ausgabe prägt, gehört dagegen in die Zielsprache: Beispielantworten, Formulierungsvorgaben, Few-Shot-Beispiele. Ein englisches Beispiel in einem deutschen Anwendungsfall ist eine Einladung an das Modell, englische Satzmuster oder gleich englische Halbsätze in die Antwort zu tragen.

Wichtiger als die Grundsatzentscheidung ist die Überprüfbarkeit: beide Varianten gegen dasselbe deutsche Eval-Set laufen lassen und die Ergebnisse vergleichen. Der Unterschied ist je nach Modell und Aufgabe verschieden groß, und er ändert sich mit jedem Modellwechsel. Was heute stimmt, kann nach dem nächsten Update anders aussehen.

Fazit

Deutschsprachige Eingaben sind für aktuelle Modelle kein Problem, aber sie sind ein Kostenfaktor und eine Fehlerquelle mit eigenem Profil. Komposita treiben den Token-Verbrauch und damit Kosten, Kontextbedarf und Latenz. Qualitätsunterschiede zwischen Deutsch und Englisch existieren, sind aber aufgaben- und modellabhängig und gehören gemessen statt vermutet. Österreichische Fachsprache braucht Glossare und Terminologie-Prüfungen, weil die Trainingsdaten bundesdeutsch dominiert sind. Und die Sprache des System-Prompts ist keine Glaubensfrage, sondern ein Testfall: Steuerung auf Englisch, Tonvorgaben in der Zielsprache, Entscheidung per Eval. Wer diese vier Punkte im Griff hat, holt aus deutschsprachigen Projekten dieselbe Verlässlichkeit heraus wie aus englischen.