Du lieferst einen Chatbot für dein deutsches Team. Die Benutzeroberfläche ist deutsch. Die Quelldokumente sind teilweise deutsch, teilweise englisch. Die Tools hinter dem Assistenten erwarten englische Enum-Werte, englische Funktionsbeschreibungen, englische Produktnamen, alles auf Englisch.
Dann stellt jemand eine ganz normale Frage auf Deutsch, das Modell wählt das richtige Tool aus, übergibt ein Argument auf Deutsch statt auf Englisch, und die ganze Sache fällt still und leise auseinander.
Ich habe das schon so oft erlebt, dass ich es nicht mehr als Übersetzungsproblem betrachte. **Es ist ein Ausführungsproblem.
Meine derzeitige Vorgabe ist einfach: Lass die Benutzer/innen in der Sprache sprechen, die sie wollen, aber lass den LLM die Suche, die Schlussfolgerungen und die Werkzeuge auf Englisch ausführen, wenn es um Zuverlässigkeit geht. Dann lokalisiere die Antwort außerhalb dieser Schleife.
Das klingt im ersten Moment etwas ketzerisch. Meiner Meinung nach ist es aber das Praktischste, was du im Moment tun kannst.
Die Forschung beginnt, dies laut zu sagen
Die Zahlen sind nicht mehr unauffällig.
Im [MASSIVE-Agents-Benchmark] (https://aclanthology.org/2025.findings-emnlp.1099/) haben Forscher den mehrsprachigen Funktionsaufruf in 52 Sprachen, 47.020 Stichproben und 21 Modellen bewertet. Die beste durchschnittliche Punktzahl über alle Sprachen hinweg lag bei nur 34,05 %. Englisch erreichte 57,37%. Amharisch fiel auf 6,81%.
Das ist keine kleine Qualitätsschwankung. Das ist eine Klippe in Sachen Zuverlässigkeit.
Dann gibt es noch [Lost in Execution] (https://arxiv.org/abs/2601.05366), das noch näher an das reale Systemproblem heranreicht. Die Arbeit zeigt, dass viele mehrsprachige Werkzeugaufrufe scheitern, ** nachdem das Modell die Absicht bereits verstanden und das richtige Werkzeug ausgewählt hat**. Das Hauptproblem war die mangelnde Übereinstimmung der Parameterwerte mit der Sprache. Im Klartext: Das Modell wusste, was zu tun war, drückte die ausführbaren Bits aber in der Sprache des Benutzers statt in der Sprache der Schnittstelle aus, sodass der Aufruf trotzdem fehlschlug.
Und das ist nicht auf Tool-Aufrufe beschränkt. In [Do Multilingual Language Models Think Better in English?] (https://aclanthology.org/2024.naacl-short.46/) haben Etxaniz und Kollegen herausgefunden, dass die Selbstübersetzung ins Englische bei fünf Aufgaben durchweg besser ist als die direkte Schlussfolgerung aus dem Nicht-Englischen. Ihre Formulierung ist erfrischend unverblümt: Modelle sind "nicht in der Lage, ihr volles mehrsprachiges Potenzial auszuschöpfen, wenn sie in nicht-englischen Sprachen aufgefordert werden".
Also ja, mehrsprachige Modelle sind beeindruckend. Aber wenn deine Messlatte nicht "klingt ziemlich gut" ist, sondern "muss sich in der Produktion korrekt verhalten", sieht Englisch immer noch erstaunlich oft wie die sicherere Betriebssprache aus.
Warum RAG immer an derselben Stelle bricht
Wenn man dieses Argument hört, denkt man normalerweise zuerst an Agenten. Funktionsaufrufe, strukturierte Ausgaben, API-Ausführung und dergleichen mehr.
RAG hat die gleiche Schwäche, nur eine Ebene früher.
Wenn deine Suchschicht die lokalen Formulierungen eines Nutzers mit Inhalten abgleichen muss, die in verschiedenen Sprachen verfasst wurden, mit inkonsistenter Terminologie, übersetzten Produktnamen und halb lokalisierten Taxonomiebezeichnungen, erhöht sich die Wahrscheinlichkeit, dass das System abdriftet, bevor die Generierung überhaupt beginnt. Ehrlich gesagt, kommen viele Beschwerden über "das Modell ist unzuverlässig" daher. Das Modell mag in Ordnung sein. Die Inhaltsschnittstelle ist es nicht.
Ich würde lieber früh normalisieren.
Übersetze die Frage ins Englische. Vergleiche sie mit einem kanonischen englischen Korpus. Lass das Modell über eine stabile Terminologieebene nachdenken. Erstelle bei Bedarf einen Antwortentwurf auf Englisch. Übersetze oder lokalisiere dann die endgültige Antwort für den Nutzer.
So hast du einen Ort, an dem die Benennung stabil bleibt:
- ein kanonischer Dokumententitel
- ein kanonisches Produktvokabular
- ein kanonisches Werkzeugschema
- ein kanonisches Set von Retrieval Labels
Du kannst immer noch jede Benutzersprache auf der Außenseite unterstützen. Du verlangst nur nicht mehr, dass der Kernausführungspfad bei jedem Schritt perfekt mehrsprachig ist.
Das ist nicht gegen die Lokalisierung.
Ganz im Gegenteil.
Eine schlechte mehrsprachige KI-Architektur schadet in der Regel zuerst den lokalen Nutzern. Sie bekommen eine schöne lokalisierte Oberfläche, aber das versteckte englischsprachige System darunter verhält sich inkonsequent und lässt sie den Preis dafür zahlen.
Richtige Lokalisierung bedeutet, dass man ehrlich darüber ist, wo sich die Sprache biegen sollte und wo nicht.
Für mich sieht die Aufteilung folgendermaßen aus:
- Lokalisiere die Benutzeroberfläche, die Eingabeaufforderungen, den Hilfetext, das Onboarding und die endgültigen Antworten.
- Lokalisiere den Quellinhalt, den die Leute direkt lesen, wenn dieser Inhalt auf dem Markt benötigt wird.
- Behalte interne Tooldefinitionen, kanonische Bezeichner, Abrufbezeichnungen und Argumentationspunkte auf Englisch, wenn dies die stabilste Ebene ist.
- Füge explizite Nachbearbeitung oder menschliche Überprüfung hinzu, wenn eine lokalisierte Ausgabe rechtlich, regulatorisch oder vertraglich von Bedeutung ist.
Dieser letzte Punkt ist wichtiger, als die Teams zugeben wollen. Wenn das Modell mit einem Menschen spricht, ist die Lokalisierung eine Entscheidung für die Benutzererfahrung. Wenn das Modell mit einem anderen System kommuniziert, ist die Sprache ein Schnittstellenvertrag.
Das ist nicht dasselbe.
Die Architektur, der ich im Moment am meisten vertraue
Dies ist die Version, auf die ich heute für mehrsprachige KI-Produkte setzen würde:
- Der Benutzer fragt in seiner Sprache.
- Das System übersetzt oder normalisiert die Anfrage ins Englische.
- Abfrage, Schlussfolgerung, Ranking und Tool-Aufrufe erfolgen anhand kanonischer englischer Daten.
- Die endgültige Antwort wird wieder in die Sprache des Nutzers übersetzt.
- Ausgaben mit hohem Risiko werden einem zusätzlichen Validierungsschritt unterzogen, bevor sie das System verlassen.
Es ist nicht philosophisch rein. Es ist operativ vernünftig.
Das Schöne daran ist, dass neuere Forschungsergebnisse in die gleiche Richtung weisen. Die Studie [Lost in Execution] (https://arxiv.org/abs/2601.05366) hat herausgefunden, dass die Vorübersetzung von Benutzeranfragen die Fehler bei der Sprachübereinstimmung in der Regel besser reduziert als Nachbesserungen, auch wenn dadurch die Leistung auf englischem Niveau nicht vollständig wiederhergestellt werden kann. Das entspricht dem, was viele Entwickler/innen in der Praxis bereits vermuten. Wenn du bis zum Ende wartest, um mehrsprachige Inkonsistenzen zu bereinigen, ist es meist zu spät.
Und ja, es gibt Ausnahmen. Wenn du für Sprachen mit geringen Ressourcen, für eine domänenspezifische Sprache oder für kulturell abhängige Formulierungen baust, kann es zu einem Drift kommen, wenn du alles ins Englische übersetzt. Davor wird in dem oben genannten Papier ausdrücklich gewarnt. Mach das also nicht zu einem Dogma.
Aber als Standard für Copiloten in Unternehmen, interne Assistenten, mehrsprachige RAG und Agenten, die Tools verwenden, halte ich die Regel für erstaunlich gut geeignet.
Was das für Rasepi bedeutet
Das ist genau der Grund, warum ich so viel Wert auf die kanonische Inhaltsstruktur lege.
Wenn deine Wissensbasis eine saubere Quellenschicht, eine stabile Terminologie und eine kontrollierte Lokalisierung aufweist, ist es einfacher, der KI zu vertrauen. Wenn jede Sprachversion unabhängig voneinander in den Ausführungspfad abdriftet, bittest du das Modell zu improvisieren, wo dein System präzise sein sollte.
Der gesamte Ansatz von Rasepi ist darauf ausgerichtet, diese Bereiche sauber voneinander zu trennen. Behalte einen kanonischen Kern. Lokalisiere absichtlich. Verfolge, wo Varianten existieren. Gib nicht vor, dass jede Schicht des Stacks gleichermaßen mehrsprachig sein sollte, nur weil die Benutzeroberfläche es ist.
Früher dachte ich, dass die beste mehrsprachige KI-Erfahrung bedeutet, alles in der Sprache des Nutzers zu machen. Das glaube ich nicht mehr. Nicht für Systeme, die den richtigen Absatz abrufen, das richtige Werkzeug wählen und etwas zurückgeben müssen, dem man vertrauen kann.
Die praktische Regel ist einfach: Die Benutzer sollten lokal bleiben, aber der Ausführungspfad des LLM sollte stabil bleiben. Im Moment bedeutet das normalerweise Englisch in der Mitte und Lokalisierung an den Rändern.
Das wird sich mit der Zeit ändern. Ich hoffe, es ändert sich schnell. Aber wenn du heute auslieferst und Zuverlässigkeit wichtiger ist als Ästhetik, würde ich das Modell auf Englisch denken lassen und dein Produkt die Sprache des Nutzers sprechen lassen.