Das Low-Resource-Problem bei maschineller Übersetzung

Auf der Erde werden schätzungsweise 7.000 Sprachen gesprochen. Google Translate unterstützt davon etwa 130. Die meisten kommerziellen MT-Systeme beherrschen weniger als 30 wirklich gut. Wenn du Yoruba, Quechua oder Khmer sprichst, bewegt sich deine Erfahrung mit maschineller Übersetzung zwischen „kaum brauchbar“ und „zum Totlachen falsch“. Die unbequeme Wahrheit ist: Der Fortschritt in der NLP hat im letzten Jahrzehnt größtenteils auf Englisch stattgefunden – und die Kluft zwischen ressourcenstarken und ressourcenschwachen Sprachen wird eher größer als kleiner.

Metas aktueller Vorstoß in Richtung omnilingualer maschineller Übersetzung mit Abdeckung von über 1.600 Sprachen gehört zu den ehrgeizigsten Versuchen, daran etwas zu ändern. Die technischen Herausforderungen zeigen aber grundlegende Annahmen, die tief in unserem Umgang mit Sprachmodellen verankert sind, und erklären, warum einfaches Hochskalieren das Problem nicht löst.

Was eine Sprache „ressourcenschwach“ macht

In der MT-Forschung bedeutet ein „ressourcenstarkes“ Sprachpaar, dass man Millionen paralleler Sätze hat – Texte, die professionell zwischen den beiden Sprachen übersetzt wurden. Englisch–Französisch, Englisch–Chinesisch, Englisch–Spanisch: Für diese Paare gibt es enorme Parallelkorpora, etwa aus dem EU-Parlament, den Vereinten Nationen, Nachrichtenredaktionen und jahrzehntelanger professioneller Übersetzungsarbeit. Modelle, die auf diesen Paaren trainiert werden, funktionieren bemerkenswert gut.

Eine „ressourcenschwache“ Sprache hat womöglich ein paar Tausend parallele Sätze oder gar keine. Fon (gesprochen von rund 2 Millionen Menschen in Benin) hat praktisch keine parallelen Daten mit Englisch. Bambara (rund 14 Millionen Sprecher in Mali) hat etwas mehr, aber immer noch um Größenordnungen weniger, als herkömmliche MT-Systeme brauchen. Für viele Sprachen besteht das größte verfügbare Textkorpus aus einer Bibelübersetzung und vielleicht ein paar Wikipedia-Artikeln.

Die Ressourcenlücke betrifft nicht nur die Datenmenge, sondern vor allem die Datenvielfalt. Selbst wenn es parallele Texte für eine ressourcenschwache Sprache gibt, konzentrieren sie sich meist auf religiöse Texte oder Regierungsdokumente. Das Modell lernt, formelle, repetitive Prosa zu übersetzen, scheitert aber an Alltagsgesprächen, Fachterminologie oder allem, was von der engen Domäne abweicht, auf der es trainiert wurde.

Warum sich das Problem nicht einfach wegskalieren lässt

Der Instinkt im modernen ML lautet: mehr Daten, größeres Modell, bessere Ergebnisse. Für englischzentrierte Aufgaben hat das spektakulär funktioniert. GPT-artige Modelle, die auf Billionen englischer Tokens trainiert wurden, erzeugen bemerkenswert flüssigen Text. Für ressourcenschwache MT gibt es bei diesem Ansatz aber drei kritische Fehlerquellen.

• Die Daten existieren schlicht nicht. Parallele Fon-Englisch-Texte kann man nicht aus dem Internet abgreifen, wenn bisher kaum jemand nennenswerte Mengen davon veröffentlicht hat. Web-Scraping, das die meisten großen MT-Trainingssets speist, ist grundsätzlich auf Sprachen mit großer Online-Präsenz ausgerichtet.
• Die Tokenisierung versagt. Die meisten Sprachmodelle nutzen Tokenizer, die überwiegend auf Englisch (oder einer Handvoll ressourcenstarker Sprachen) trainiert wurden. Wenn du amharische Schrift oder birmanischen Text durch einen auf Englisch trainierten BPE-Tokenizer schickst, zerfällt er in absurd lange Tokenfolgen. Ein einzelnes amharisches Wort kann 8 bis 12 Tokens verbrauchen. Das Modell nutzt dann den Großteil seines Kontextfensters schon zum Kodieren der Eingabe und hat kaum Kapazität, sie tatsächlich zu verstehen.
• Transfer-Learning stößt an Grenzen. Multilinguale Modelle wie mBERT oder XLM-R zeigen, dass das Training auf vielen Sprachen auch ressourcenschwachen Sprachen helfen kann – das Modell erkennt strukturelle Ähnlichkeiten. Dieser Transfer ist aber am stärksten zwischen verwandten Sprachen. Ein Modell, das Französisch gut beherrscht, kann etwas von diesem Wissen auf Haitianisches Kreol übertragen. Auf Mandarin oder Navajo überträgt es fast nichts.

Das Pivot-Sprachen-Problem

Die meisten MT-Systeme, die hunderte Sprachen abdecken, leiten praktisch alles über Englisch. Du willst Swahili ins Thailändische übersetzen? Das System macht Swahili → Englisch → Thailändisch. Dieser Pivot-Ansatz ist praktisch, denn man braucht nur Übersetzungsmodelle von und nach Englisch. Er führt aber zu sich aufschaukelnden Fehlern und einer subtilen Form kultureller Verflachung.

Wenn man über Englisch pivotiert, gehen Konzepte verloren, die sich nicht sauber auf Englisch abbilden lassen. Japanisch kodiert mehrere Höflichkeitsstufen in den Verbformen. Yoruba hat tonale Unterschiede, die die Bedeutung verändern. Tamil unterscheidet ein inklusives und ein exklusives „wir“ (je nachdem, ob der Zuhörer eingeschlossen ist). Wenn diese Merkmale durch den englischen Flaschenhals laufen, gehen die Informationen verloren – Englisch kodiert diese Unterschiede nicht, und das Modell hat keine Möglichkeit, sie zu bewahren.

Direkte Übersetzung zwischen Nicht-Englisch-Sprachpaaren – Swahili direkt ins Thailändische, ohne den Umweg über Englisch – bewahrt mehr Information. Direkte Modelle für jedes mögliche Paar zu bauen, ist aber kombinatorisch unmöglich. Bei 1.600 Sprachen bräuchte man 2,56 Millionen gerichtete Übersetzungspaare. Selbst wenn man nur die 100 meistgesprochenen Sprachen direkt abdeckt, sind es immer noch 9.900 Paare.

Wie sich moderne Ansätze unterscheiden

Die aktuelle Generation massiv multilingualer MT-Modelle geht grundlegend anders vor als die Pivot-Strategie. Statt für jedes Sprachpaar ein eigenes Modell zu bauen, trainieren sie ein einziges Modell, das gleichzeitig über alle Sprachen hinweg eine gemeinsame Repräsentation lernt. Die zentralen Innovationen lassen sich in ein paar Kategorien einteilen.

Sprachunabhängige Tokenisierung

Das Tokenizer-Problem wird angegangen, indem man Tokenizer auf ausgewogenen multilingualen Korpora trainiert statt auf englischlastigen. Metas Ansatz verwendet einen zeichenbasierten Fallback, der verhindert, dass eine Sprache krankhaft lange Tokenfolgen bekommt. SentencePiece-Modelle, die mit expliziter Sprachbalance trainiert werden, tokenisieren deutlich gerechter – ein Yoruba-Satz und ein englischer Satz mit ähnlicher Bedeutung verbrauchen ungefähr gleich viele Tokens.

Das ist wichtiger, als es klingt. Wenn dein Tokenizer für Sprache X viermal ineffizienter ist, hat dein Modell für diese Sprache effektiv nur ein Viertel der Kapazität. Die Tokenisierung zu verbessern ist deshalb die wirkungsvollste einzelne Maßnahme für die Leistung bei ressourcenschwachen Sprachen.

Parallele Daten aus freier Wildbahn gewinnen

Einer der cleversten technischen Beiträge ist das automatische Mining paralleler Daten. Die Idee: Man trainiert einen multilingualen Satz-Encoder, der Sätze aus beliebigen Sprachen in einen gemeinsamen Einbettungsraum abbildet. Dann durchsucht man das Web nach Sätzen in verschiedenen Sprachen, die auf ähnliche Vektoren abgebildet werden – sie sind wahrscheinlich Übersetzungen voneinander.

Diese Technik, die mit Werkzeugen wie LASER Pionierarbeit leistete und in neueren Arbeiten erweitert wurde, hat aus Web-Crawls wie CCNet und OSCAR hunderte Millionen paralleler Sätze extrahiert. Sie ist verrauscht – vielleicht 20 bis 30 Prozent der extrahierten Paare sind tatsächlich parallel –, aber Filterheuristiken verbessern die Präzision, und die schiere Menge gleicht das Rauschen aus. Für manche Sprachen hat dieses automatisierte Mining mehr parallele Daten erzeugt als alle bisherigen von Menschen kuratierten Datensätze zusammen.

Back-Translation und Selbsttraining

Back-Translation bedeutet, dass man das bestehende (unvollkommene) MT-Modell nutzt, um einsprachige Texte in die Zielsprache zu übersetzen, und diese synthetischen Paare dann verwendet, um ein besseres Modell zu trainieren. Das ist Bootstrapping – und es funktioniert überraschend gut.

Der Zyklus sieht so aus: Ein erstes Modell wird auf den vorhandenen parallelen Daten trainiert → damit werden einsprachige Daten übersetzt → schlechte Übersetzungen werden herausgefiltert → das Modell wird auf der Kombination aus echten und synthetischen Daten neu trainiert → und das Ganze wird wiederholt. Jede Iteration verbessert das Modell, das daraufhin bessere synthetische Daten erzeugt, was die nächste Runde weiter verbessert. Bei Sprachen, bei denen man mit nur ein paar Tausend parallelen Sätzen startet, kann Back-Translation die Trainingsdaten effektiv um das 10- bis 50-Fache vervielfachen.

# Simplified back-translation loop
def back_translate_cycle(model, parallel_data, monolingual_target, rounds=3):
for round in range(rounds):
# Generate synthetic source from monolingual target text
synthetic_pairs = []
for target_sent in monolingual_target:
source_sent = model.translate(target_sent, direction='reverse')
score = model.score_pair(source_sent, target_sent)
if score > QUALITY_THRESHOLD:
synthetic_pairs.append((source_sent, target_sent))
# Combine real and synthetic data
combined = parallel_data + synthetic_pairs
# Retrain model on combined data
model = train_mt_model(combined)
print(f'Round {round+1}: {len(synthetic_pairs)} synthetic pairs added')
print(f'BLEU score: {evaluate(model, test_set)}')
return model

Evaluation ist schwieriger, als man denkt

BLEU-Scores – der Standardmaßstab für MT-Qualität – haben bei ressourcenschwachen Sprachen ernsthafte Probleme. BLEU misst die n-Gramm-Überlappung zwischen der Ausgabe des Modells und einer Referenzübersetzung. Für Englisch funktioniert das halbwegs gut, weil Englisch eine relativ feste Wortstellung und wenig Morphologie hat. Bei agglutinierenden Sprachen wie Türkisch oder Finnisch, wo ein einziges Wort ausdrückt, wofür das Englische eine ganze Phrase braucht, bestraft BLEU aber gültige Übersetzungen, die andere morphologische Formen verwenden.

Dazu kommt das Referenzproblem: Wer schreibt die Referenzübersetzungen, gegen die man evaluiert? Für ressourcenstarke Sprachen gibt es professionelle Übersetzer. Bei vielen ressourcenschwachen Sprachen wurden die „Goldstandard“-Referenzen von Missionaren, Regierungsübersetzern mit formalem Register oder Studierenden erstellt. Diese Referenzen mögen technisch korrekt sein, klingen aber stilistisch unnatürlich – und ein Modell, das natürlichere Übersetzungen liefert, erzielt damit tatsächlich niedrigere Werte.

Neuere Metriken wie COMET und BLEURT nutzen neuronale Modelle, um die Übersetzungsqualität zu schätzen, und korrelieren besser mit menschlichen Urteilen. Sie wurden aber ebenfalls vor allem auf Daten ressourcenstarker Sprachen trainiert und generalisieren möglicherweise schlecht auf Sprachen mit ganz anderen Strukturen. Einige Teams haben angefangen, für ihre wichtigsten Sprachpaare menschliche Evaluation mit Muttersprachlern durchzuführen – das skaliert aber nicht auf 1.600 Sprachen.

Die kulturellen und ethischen Dimensionen

MT für 1.600 Sprachen aufzubauen ist nicht nur eine technische Herausforderung. Es wirft Fragen auf: Wer profitiert, wer entscheidet, wie Sprachen repräsentiert werden, und was passiert, wenn Modelle falsche oder voreingenommene Übersetzungen kodieren.

Bei vielen bedrohten Sprachen sind die Hauptsprecher ältere Gemeindemitglieder in ländlichen Regionen. Sie sind nicht diejenigen, die MT-APIs nutzen. Die unmittelbaren Nutznießer sind eher Forschende, NGOs und Regierungen – was je nach Kontext gut (besserer Zugang zu Informationen) oder problematisch (Überwachung, erzwungene Assimilation) sein kann. MT für indigene Sprachen, die ohne Beteiligung der Gemeinschaft entwickelt wurde, hat eine belastete Geschichte.

Außerdem stellt sich die Frage der Sprachstandardisierung. Viele ressourcenschwache Sprachen haben erhebliche dialektale Variation und keine einzige „Standard“-Form. Wenn ein MT-Modell einen Dialekt als kanonisch wählt – meist den, der in den Trainingsdaten am stärksten vertreten ist –, drängt es die Sprecher anderer Dialekte implizit an den Rand. Das ist keine Hypothese, sondern passiert bereits bei besser ausgestatteten Sprachen. Arabische MT-Modelle beherrschen Modernes Standardarabisch meist gut, tun sich aber schwer mit ägyptischen, levantinischen oder golfarabischen Dialekten, die Hunderte Millionen Menschen tatsächlich sprechen.

Was das für Entwickler bedeutet

Wenn du Software für ein globales Publikum baust, hat der Stand der MT praktische Folgen für deine Architektur- und Produktentscheidungen.

• Geh nicht davon aus, dass die MT-Qualität einheitlich ist. Deine App nutzt für die Lokalisierung vielleicht Google Translate oder eine ähnliche API. Die Qualität für Französisch ist ausgezeichnet. Für Amharisch kann sie hart an der Grenze der Unbrauchbarkeit liegen. Teste mit Muttersprachlern für jede Sprache, die du unterstützt – nicht nur für die Top 10.
• Plane MT-Fehler von vornherein ein. Zeige Nutzern den Originaltext neben der Übersetzung. Lass sie schlechte Übersetzungen markieren. Verschleiere nicht, dass Inhalte maschinell übersetzt wurden – Nutzer merken es ohnehin, und sie vertrauen dir weniger, wenn du so tust, als wäre es menschliche Qualität gewesen.
• Berücksichtige die Tokenisierungs-Steuer. Wenn du Sprachmodelle (nicht nur MT) in einem mehrsprachigen Kontext einsetzt, bedenke, dass nicht-englische Sprachen mehr Tokens verbrauchen. Dein 4K-Kontextfenster fasst deutlich weniger Thai- oder Arabisch-Text als Englisch. Plane entsprechend.
• Investiere in mehrsprachige Testdaten. Der schwierigste Teil bei der Unterstützung ressourcenschwacher Sprachen ist nicht das Modell – sondern zu wissen, ob die Ausgabe korrekt ist. Baue Beziehungen zu Muttersprachlern auf, die die Qualität prüfen können. Automatische Metriken werden dich in die Irre führen.

Der Weg nach vorn

Der Vorstoß in Richtung omnilingualer MT ist wirklich spannend, trotz aller Vorbehalte. Vor fünf Jahren wäre ein Übersetzungsmodell für eine Sprache mit 10.000 parallelen Sätzen eine Forschungskuriosität gewesen. Heute machen Techniken wie Back-Translation, multilingualer Transfer und automatisches Parallel-Mining es machbar – nicht perfekt, aber brauchbar.

Die verbleibenden Herausforderungen sind mindestens so sehr sozial wie technisch. Trainingsdaten für bedrohte Sprachen erfordern Partnerschaften mit Gemeinschaften, nicht nur Web-Scraping. Qualität im großen Maßstab zu bewerten verlangt neue Metriken und die Einbindung von Muttersprachlern. Und sicherzustellen, dass MT-Werkzeuge tatsächlich den Gemeinschaften dienen, die diese Sprachen sprechen – statt nur ein Abdeckungs-Häkchen zu setzen –, verlangt kontinuierliches Engagement.

Aber die Richtung stimmt. Sprache sollte keine Barriere beim Zugang zu Informationen sein, und allein die Tatsache, dass wir versuchen, Übersetzungssysteme für 1.600 Sprachen zu bauen – statt immer wieder dieselben 30 zu optimieren –, markiert einen echten Wandel der Prioritäten. Die Technik ist schwierig. Allein das Tokenisierungsproblem hat Jahre gebraucht, um richtig erkannt und angegangen zu werden. Doch für die Milliarden Menschen, deren Sprachen von der Tech-Branche ignoriert wurden, ist diese Arbeit wichtiger als eine weitere Verbesserung um einen Bruchteil eines Prozentpunkts beim BLEU-Score für Englisch–Französisch.