Die Sprache eines Modells ist nicht die Sprache einer Gesellschaft.
Sechzehn Sprachen sind ein Anfang, kein Urteil
Am 22. Juli 2026 veröffentlichte die Generaldirektion Übersetzung der Europäischen Kommission EU MMLU, eine Benchmark, die große Sprachmodelle in europäischen sprachlichen und kulturellen Kontexten testen soll. Die Veröffentlichung war ungewöhnlich ehrlich über die Lücke, die sie schließen wollte. Viele Evaluierungsdatensätze wurden auf Englisch erstellt. Ein Modell kann dort gut abschneiden und trotzdem bei Französisch, Ungarisch oder Maltesisch versagen. Der neue Datensatz beginnt mit sechzehn Amtssprachen der EU, sieben Themenbereichen und mehr als tausend Fragen, die von fast 250 Studierenden aus 21 europäischen Universitäten übersetzt und überarbeitet wurden.
Der wichtigste Teil dieser Ankündigung ist nicht die Liste der Sprachen. Es ist der Satz darunter: Das Verhalten eines Modells lässt sich nicht aus der Sprache ableiten, in der es am flüssigsten wirkt. Das sollte selbstverständlich sein. Es ist auch die Annahme hinter einer bemerkenswerten Menge an Beschaffung, Forschung und öffentlicher Diskussion. Wir sprechen immer noch von einem Sprachmodell, als hätte es einen einzigen Geist, und bitten es dann, verschiedene Sprachen wie Mäntel zu tragen. Der Mantel wechselt. Der Geist, die Belege, die blinden Flecken und das soziale Umfeld werden als stabil behandelt.
Das sind sie nicht. Sprache ist der Ort, an dem ein Mensch auf eine Institution trifft. Sie trägt die Bedingungen einer Leistung, den Ton eines Einspruchs, den Unterschied zwischen Rat und Anweisung, die Form eines Witzes, den Namen eines Ortes und die Annahmen in einem Formular. Wenn ein System eine Sprache besser beherrscht als eine andere, erzeugt es nicht nur einen weniger eleganten Satz. Es kann verändern, wer verstanden wird, wem geglaubt wird, wer ein Ergebnis anfechten kann und wer aufgibt, bevor er die richtige Tür findet.
Die praktische Schlussfolgerung ist klar. Mehrsprachige KI ist keine Übersetzungsfunktion, die nachträglich zum Modell hinzugefügt wird. Es ist eine Frage des Zugangs, der Belege und der Autorität. Die Arbeit Europas an Sprachtechnologien, Sprachdaten und mehrsprachiger Evaluierung ist wertvoll, weil sie das Problem als Infrastruktur behandelt. Die Arbeit ist noch nicht abgeschlossen. Eine Benchmark ist keine Garantie, und sechzehn Sprachen sind nicht ganz Europa. Aber die Richtung stimmt: Hören Sie auf zu fragen, ob ein Modell eine Sprache spricht, und fragen Sie, was es in dieser Sprache sicher tun kann, für wen, unter welchen Bedingungen und mit welchen Belegen.
Sprache ist eine Zugangsgrenze
Europa hat Sprache zu einer institutionellen Tatsache gemacht, nicht zu einer privaten Vorliebe. Artikel 22 der Charta der Grundrechte besagt, dass die Union die kulturelle, religiöse und sprachliche Vielfalt achtet. Die eigene Sprachtechnologiepolitik der Kommission stellt dieser Verpflichtung eine praktische Warnung zur Seite: Sprachtechnologien benötigen eine unvoreingenommene Nutzung, wenn Rechte und Grundsätze den Kontakt mit Software überstehen sollen. Dies sind keine dekorativen Bekenntnisse. Sie beschreiben die Grenze, auf die ein öffentliches System stößt, wenn eine Einwohnerin oder ein Einwohner einen Bescheid nicht lesen kann, nicht versteht, warum eine Entscheidung getroffen wurde, oder einen relevanten Sachverhalt nicht in der Sprache ausdrücken kann, in der der Sachverhalt besteht.
Diese Grenze übersieht man leicht, wenn ein Team nur misst, ob eine Übersetzung erstellt wurde. Ein Satz kann in der gewünschten Sprache ankommen und dennoch der Person nicht helfen, die ihn braucht. Die Übersetzung könnte eine rechtliche Unterscheidung einebnen, die Höflichkeitsstufe verändern, die anzeigt, ob eine Behörde fragt oder anordnet, oder einen Begriff verwenden, der eine Alltagsbedeutung, aber in einem bestimmten Dienst eine Fachbedeutung hat. Ein Spracherkenner könnte eine regionale Aussprache in ein anderes Wort verwandeln. Ein Zusammenfasser könnte die Einschränkung entfernen, die die Haftung trägt. Flüssigkeit sagt uns nicht, ob der Vorgang intakt geblieben ist.
Stellen Sie sich einen öffentlichen Informationsdienst vor, der dieselbe Erklärung der Anspruchsvoraussetzungen auf Niederländisch, Französisch und einer Regionalsprache anbietet. Die ersten beiden Wege wurden mit Verwaltungsmaterial, Widerspruchsschreiben und Gesprächen mit Fachexperten trainiert und getestet. Der dritte Weg hat ausgezeichnete allgemeine Prosa, aber keine aussagekräftige Bewertung anhand der eigenen Terminologie des Dienstes. Ein Dashboard kann drei grüne Sprachkennzeichnungen melden. Die Einwohnerinnen und Einwohner erhalten nicht drei gleichwertige Dienste. Eine Gruppe erhält eine Erklärung; eine andere erhält eine Annäherung; die dritte erhält eine polierte Ungewissheit, die offiziell wirkt, weil sie das richtige Logo trägt.
Das Beispiel ist bewusst hypothetisch. Es ist keine Behauptung über eine bestimmte Gemeinde oder einen bestimmten Anbieter. Sein Zweck ist es, einen Konstruktionsfehler aufzuzeigen. Sprachunterstützung wird oft an der Schnittstelle gezählt, während die eigentliche Verpflichtung weiter unten in der Kette liegt. Das System muss wissen, welche Daten die Sprache stützen, welche Aufgaben bewertet wurden, wer Fehler überprüft hat, wie Nutzerinnen und Nutzer sie korrigieren können und wann der Weg eine Antwort verweigern muss. Wenn diese Einzelheiten fehlen, ist die Sprachauswahl ein Versprechen ohne Vertrag.
Die Karte eines Modells ist nicht die Karte der Gesellschaft
Ein Modell lernt aus einer Karte der Sprache, die seine Daten und sein Trainingsprozess verfügbar machen. Eine Gesellschaft lebt in einer viel größeren Karte. Die Karte des Modells enthält die Texte, Aufnahmen, Kennzeichnungen, Übersetzungen und Bewertungen, die zugelassen wurden. Die Karte der Gesellschaft enthält Menschen, die zu Hause und bei der Arbeit unterschiedlich sprechen, ohne Ankündigung die Sprachregister wechseln, Wörter über eine Grenze hinweg übernehmen, eine Minderheitensprache in einer lokalen Einrichtung verwenden oder in einer Schrift schreiben, die ein Benchmark nicht enthielt. Die eine Karte ist ein technisches Artefakt. Die andere ist eine Anordnung von Leben, Rechten und Pflichten.
Der Unterschied ist selbst bei Sprachen mit großen öffentlichen Textkorpora von Bedeutung. Eine Nationalsprache ist kein einheitlicher Strom. Behördliche Formulare, Gerichtsentscheidungen, Unterrichtssprache, Gesundheitshinweise, Textnachrichten und ein Gespräch zwischen Nachbarn verwenden unterschiedliche Wortschätze und unterschiedliche Toleranzen für Mehrdeutigkeit. Ein Modell kann bei Nachrichtenprosa kompetent und bei einem Sozialleistungswiderspruch schwach sein. Es kann die Standardrechtschreibung bewältigen und sich mit einem Dialekt schwer tun. Es kann einen wörtlichen Satz übersetzen und die pragmatische Bedeutung verfehlen, die eine höfliche Formel trägt. Die gesamte Sprache als unterstützt zu bezeichnen, verschleiert die Grenze der Aufgabe.
Sprachtechnologie braucht daher eine präzisere Terminologie. Wir sollten unterscheiden, ob eine Sprache in Trainingsdaten vorkommt oder ob eine Aufgabe in dieser Sprache bewertet wird. Wir sollten eine Benchmark-Übersetzung von einem unabhängig verfassten Testelement unterscheiden. Wir sollten unterscheiden, ob ein System eine Schrift lesen kann oder ob es die Register einer Gemeinschaft versteht. Wir sollten die Fähigkeit eines Systems, Text zu erzeugen, von seiner Befugnis unterscheiden, zu beraten, zu klassifizieren oder zu entscheiden. Jede dieser Unterscheidungen ist ein kleines Stück Dokumentationsarbeit. Zusammen verhindern sie, dass aus schmalen Belegen eine weitreichende Behauptung zusammengesetzt wird.
Es gibt einen institutionellen Grund für diese Strenge. Öffentliche Dienste können sich nicht einfach die bequemste Sprache aussuchen und das Ergebnis als effizient bezeichnen. Eine Bank, ein Krankenhaus, ein Arbeitgeber oder ein Softwareanbieter mag unterschiedliche rechtliche Pflichten haben, aber jede dieser Einrichtungen entscheidet, wie viel Reibung eine Person auf sich nehmen muss, um verstanden zu werden. Ein mehrsprachiger Weg, der stillschweigend scheitert, verlagert die Kosten auf die Nutzerin oder den Nutzer. Die Person muss eine Übersetzerin oder einen Übersetzer finden, eine Geschichte wiederholen, ein schlechteres Ergebnis akzeptieren oder den Vorgang abbrechen. Das System meldet Erfolg, weil es eine Zeichenkette zurückgegeben hat. Die Person erlebt Ausgrenzung mit ausgezeichneter Grammatik.
Was ressourcenarm tatsächlich bedeutet
Ressourcenarm wird oft als Eigenschaft einer Sprache behandelt, als ob manche Sprachen mit weniger Ressourcen an der Tür des Modells ankämen und sich für die Unannehmlichkeit entschuldigen sollten. Sinnvoller ist es, dies als Eigenschaft einer Aufgabe, eines Datensatzes und einer Governance-Entscheidung zu betrachten. Eine Sprache kann über umfangreiches literarisches Material verfügen, aber nur wenig annotierte Daten für einen medizinischen Klassifikator. Sie kann Paralleltexte haben, aber fast keine Sprachaufnahmen. Sie kann in einem Korpus vertreten sein, ohne dass die Rechte oder Metadaten für einen bestimmten Einsatz vorliegen. Sie kann Daten in einer Standardform haben, während die betroffenen Menschen eine regionale Varietät verwenden.
Die sprachtechnologiepolitische Strategie der Europäischen Kommission benennt dies unmissverständlich. Sprachdaten sind die Grundlage von Sprachwerkzeugen, und menschliche Expertise ist ein notwendiger Bestandteil erfolgreicher Entwicklung. Ein Modell benötigt Text oder Sprache, Algorithmen, Rechenleistung und Menschen, die die Sprache und die Domäne verstehen. Das Entfernen eines dieser Elemente verändert das System. Mehr Rechenleistung kann ein fehlendes Gespräch nicht erschaffen. Mehr Beispiele können ein Label nicht reparieren, das zwei rechtliche Kategorien verwechselt. Ein größeres Modell kann nicht entscheiden, welche Quelle eine Gemeinschaft als maßgeblich betrachtet.
Ressourcenarme Arbeit ist daher keine Einladung, den Standard zu senken. Sie ist ein Grund, den Standard sichtbar zu machen. Wenn eine Aufgabe nur wenig Evaluierungsmaterial hat, sagen Sie das. Wenn eine Metrik für ein Sprachpaar instabil ist, berichten Sie die Instabilität. Wenn die menschliche Prüfung klein war, benennen Sie den Umfang der Prüfung, statt sie als allgemeine Garantie darzustellen. Wenn ein Weg für Entwürfe nützlich ist, aber nicht für Entscheidungen, setzen Sie diese Grenze dorthin, wo Käufer und Nutzer sie sehen können. Ehrliche Knappheit ist sicherer als ein Schweigen, das wie Überfluss wirkt.
Die Sprachenlandschaft Europas macht diese Disziplin unvermeidlich. Die Kommission beschreibt eine komplexe Menge offizieller, regionaler und Minderheitensprachen und hat Initiativen wie die European Language Grid, die Agenda European Language Equality und den Common European Language Data Space unterstützt. Diese Projekte sind keine einzelne Lösung und sollten nicht als eine solche beschrieben werden. Sie sind Teile eines Ökosystems, in dem Daten, Werkzeuge, Rechte, Expertise und öffentliche Einrichtungen zusammenkommen können. Die institutionelle Form ist ebenso wichtig wie das Modell darin.
Die Rechtsebene kommt vor der Benchmark
Es liegt nahe, über Sprachmodelle zu sprechen, als wäre Sprache ein neutraler Eingabekanal. Das ist sie nicht. Die Eingabe kann personenbezogene Daten, ein geschütztes Merkmal, einen lokalen Ortsnamen, eine medizinische Angabe oder die Aufzeichnung einer Person enthalten, die um Hilfe bittet. Die Quelle kann urheberrechtlich geschützt oder mit einem Vorbehalt belegt sein. Eine übersetzte Ausgabe kann in einer Entscheidung verwendet werden, auch wenn der Übersetzungsweg für diesen Kontext nie evaluiert wurde. Das Sprachproblem des Modells ist bereits ein Rechtsproblem, bevor jemand einen Wert auswählt.
Der sprachtechnologische Leitfaden der Kommission verknüpft Sprachdaten sowohl mit Urheberrecht als auch mit Datenschutz. Dieser Zusammenhang sollte verändern, wie Teams Pipelines entwerfen. Ein Korpus ist nicht bloß ein Haufen von Sätzen. Er hat eine Quellenidentität, Erhebungsbedingungen, einen Lizenz- oder Rechtsstatus, Metadaten zu Sprache und Schrift, Qualitätssignale, einen Zweck und Aufbewahrungsregeln. Wenn ein Eintrag korrigiert oder zurückgezogen wird, muss die Organisation wissen, welche abgeleiteten Artefakte betroffen waren. Andernfalls kann ein späteres Modell einen alten Fehler mit der Sicherheit eines frisch gedruckten Formulars wiederholen.
Hier zeigt der Begriff Provenienz seinen Wert. Provenienz ist keine Fußnote, die besagt, dass Daten irgendwoher stammen. Sie ist die Menge der Beziehungen, die es einer prüfenden Person ermöglicht, von einem Ergebnis zu den relevanten Belegen und wieder zurück zu gelangen. In der mehrsprachigen Arbeit müssen diese Beziehungen Übersetzung, Transkription, Normalisierung, Segmentierung und Evaluierung überstehen. Ein für einen Benchmark übersetzter Satz ist nicht mit dem Quellsatz austauschbar. Ein von einer prüfenden Person erstelltes Label ist nicht mit einem aus einer anderen Sprache übernommenen Label austauschbar. Die Transformation ist Teil der Belege.
Es gibt keine Anforderung, dass jede Nutzerin und jeder Nutzer ein Forschungstagebuch sieht. Es gibt die Anforderung, dass eine Organisation eine ernsthafte Frage beantworten kann, wenn sie eintrifft. Welche Version der Sprachressource wurde verwendet? Welche Aufgabe hat sie unterstützt? Welche Sprachexpertinnen und Sprachexperten haben sie geprüft? Was hat das System getan, wenn die Konfidenz niedrig war? Wurde eine Beschwerde als Korrektur einer einzelnen Antwort behandelt oder als mögliche Fehlerklasse? Der Sprachweg wird vertrauenswürdig, wenn diese Fragen Verantwortliche und Aufzeichnungen haben.
Europa baut Sprachinfrastruktur auf, nicht nur Übersetzungsbuttons
Die Beschreibung des Gemeinsamen Europäischen Sprachdatenraums durch die Europäische Kommission ist nützlich, weil sie das Projekt nicht auf eine Modellveröffentlichung reduziert. Das Ziel ist eine Plattform und ein Marktplatz zum Sammeln, Teilen und Wiederverwenden mehrsprachiger und multimodaler Sprachdaten, während die Organisationen und Einzelpersonen, die die Daten erzeugen, die Kontrolle behalten. Diese Formulierung weist auf eine andere Vorstellung von Fortschritt hin. Die Arbeit besteht nicht nur darin, einen besseren Satz zu erzeugen. Es geht darum, Sprachressourcen auffindbar, rechtsbewusst, wiederverwendbar und rechenschaftspflichtig zu machen, in der öffentlichen Verwaltung, in der Forschung und in der Industrie.
Der European Language Grid hat einen ähnlichen Schritt gemacht, indem er spezialisierte Sprachtechnologiewerkzeuge und -ressourcen in einen gemeinsamen Katalog gebracht hat. Ein Katalog beweist nicht, dass jeder Dienst für jede Aufgabe funktioniert. Er macht eine versteckte Abhängigkeit leichter überprüfbar. Ein Team kann fragen, was das Werkzeug tut, welche Sprache es unterstützt, woher seine Daten stammen und ob die Lizenz zur beabsichtigten Nutzung passt. Das ist unauffällige Infrastruktur. Es ist auch der Weg, auf dem ein Kontinent mit vielen Institutionen vermeidet, dieselbe Sprachfähigkeit in getrennten Räumen neu aufzubauen.
Infrastruktur ist wichtig, weil der lange Schwanz der Spracharbeit nicht von einem einzigen Flaggschiffmodell gelöst wird. Eine öffentliche Stelle benötigt möglicherweise Spracherkennung für einen regionalen Akzent, Terminologieextraktion für ein spezialisiertes Fachgebiet, Übersetzungsspeicher für Gesetzgebung, Erkennung benannter Entitäten für Ortsnamen oder eine Möglichkeit, zwei Versionen eines Dokuments zu vergleichen, ohne Diakritika zu verlieren. Ein Unternehmen benötigt möglicherweise eine lokale Bereitstellung, weil das Material seine Rechtsordnung nicht verlassen darf. Eine Forschungsgruppe benötigt möglicherweise einen Datensatz mit klarer Provenienz statt einer weiteren anonymen Bewertung.
In diesem Ansatz steckt eine stille politische Entscheidung. Daten und Werkzeuge werden als Fähigkeiten behandelt, die Europa prüfen und mitgestalten können sollte, nicht als ein Dienst, der aus einem unsichtbaren Anderswo ankommt. Das bedeutet nicht, dass europäische Systeme automatisch gut sind oder dass kommerzielle Anbieter anderswo nicht nützlich sein können. Es bedeutet, dass eine Sprache zu wichtig ist, um ohne ein öffentliches Vokabular für ihre Daten, ihre Lücken und ihre Bewertung zu bleiben. Souveränität beginnt damit zu wissen, was das System nicht sehen kann.
Übersetzung ist keine neutrale Verrohrung
Übersetzung wird in Architekturdiagrammen oft zwischen zwei Komponenten platziert, als wäre sie ein Rohr, das Bedeutung von einer Seite zur anderen transportiert. Echte Übersetzung ist eine Abfolge von Entscheidungen. Welcher Quelltext ist maßgeblich? Welche Wörter müssen exakt bleiben? Welche Mehrdeutigkeit sollte bewahrt werden? Welcher kulturelle Verweis braucht eine Erklärung? Welche Register ist für eine öffentliche Bekanntmachung angemessen? Welche Entität darf nicht übersetzt werden? Welches Datum, welche Zahl oder welche Einheit sollte in der Konvention der Lesenden wiedergegeben werden? Ein Modell kann diese Entscheidungen schnell treffen. Geschwindigkeit macht sie nicht unsichtbar.
Man betrachte den Unterschied zwischen der Übersetzung eines Wettersatzes und der Übersetzung einer Bekanntmachung über eine Frist. Im ersten Fall mag ein kleiner stilistischer Fehler ärgerlich sein. Im zweiten Fall kann eine Zahl oder ein Modalverb verändern, was eine Person zu tun glaubt. Das zugrunde liegende Sprachmodell mag dasselbe Tokenbudget und dieselbe Konfidenzanzeige haben. Die gesellschaftlichen Folgen sind nicht dieselben. Die Bewertung muss daher der Aufgabe folgen und nicht bei einem allgemeinen Sprachwert stehen bleiben.
Die Seite der Kommission zu ihrer eigenen Sprachverwendung macht den Punkt ohne Dramatik. Maschinelle Übersetzung kann eine grundlegende Idee vermitteln, aber Qualität und Genauigkeit variieren erheblich von einem Text zum anderen und zwischen Sprachpaaren. Das ist ein nützlicher öffentlicher Satz, weil er sich weigert, einen Dienst in ein Orakel zu verwandeln. Er gibt den Lesenden die Erlaubnis, eine Übersetzung als Orientierung zu nutzen, während er einen Grund bewahrt, eine menschliche oder maßgebliche Version zu suchen, wenn die Konsequenz es rechtfertigt.
Für Produktteams ist die Implikation eine Reihe expliziter Wege. Eine Übersetzung mit geringen Konsequenzen kann direkt mit einem klaren Status zurückgegeben werden. Ein rechtlicher oder medizinischer Weg kann eine menschliche Prüfung, einen Quelllink oder eine Ablehnung erfordern. Ein interner Entwurf kann den Quelltext neben der Übersetzung bewahren. Eine Sprachschnittstelle kann einen kritischen Namen wiederholen und um Bestätigung bitten. Die Wahl besteht nicht zwischen vollständiger Automatisierung und keiner Automatisierung. Sie besteht zwischen einer Pipeline, die ihre Übergaben erklärt, und einer, die sie hinter einem flüssigen Absatz verbirgt.
Der Satz überlebt, die Situation nicht
Modelle arbeiten mit Repräsentationen. Gesellschaften arbeiten mit Situationen. Wenn eine Übersetzung von einem zum anderen wechselt, können kleine Details die gesamte Bedeutung ausmachen. Eine Phrase, die in einer Sprache höflich ist, kann in einer anderen ausweichend klingen. Ein Begriff, der ein gesetzliches Recht von einem Ermessensdienst unterscheidet, kann zu einem allgemeinen Wort für Hilfe zusammengezogen werden. Eine Redewendung kann wörtlich übersetzt werden und Unsinn ergeben, oder frei übersetzt werden und den Verweis verlieren, der eine Gemeinschaft identifiziert. Keiner dieser Fehler braucht eine absurde Ausgabe. Die gefährliche Antwort ist die, die gewöhnlich aussieht.
Die EU-MMLU-Veröffentlichung benennt genau dieses Gebiet. Ihre Qualitätskriterien verlangen von mehrsprachigen Benchmarks, nicht nur Bedeutung und Schwierigkeit zu testen, sondern auch Redewendungen, Humor, kulturelle Verweise, Datums- und Zahlenformate sowie Unterschiede in erwartetem Ton oder Höflichkeit. Das ist eine wichtige Erweiterung des Bewertungsziels. Einem Sprachmodell wird nicht nur die Frage gestellt, ob es einen grammatikalischen Satz erzeugen kann. Es wird gefragt, ob der Satz in die Situation gehört, in der eine Person darauf handeln wird.
The mention of humour is not an invitation to make the benchmark entertaining. It recognises that humour is a stress test for context. A literal translation can preserve words and destroy the joke. A culturally adapted translation can preserve the effect while changing the reference. In a public information service, the same mechanism appears without laughter. A proverb, a local place-name or a formal greeting can signal who is speaking and what relationship the message creates.
When teams say that a model understands a language, they should ask which layer they mean. Does it recognise the script? Segment words correctly? Identify entities? Translate the proposition? Preserve the legal force? Follow a local convention? Keep the speaker’s level of certainty? Handle a non-standard spelling? Reply in the right register? These are separate capabilities. A single label called multilingual conceals the work required to establish each one.
Why evaluation must travel with language
Evaluation is often added at the end because teams want a number to attach to a model. Multilingual systems make that order impossible. The test data determines what counts as an error. The language determines how a sentence can fail. The domain determines which failure matters. The user determines whether the system’s answer is an aid or an obstacle. Evaluation has to travel with all four.
The European research paper Towards Multilingual LLM Evaluation for European Languages demonstrates the scale of the problem. The authors assess 40 language models across 21 European languages, examine translated versions of five widely used benchmarks and publish a framework that includes EU20-MMLU, EU20-HellaSwag, EU20-ARC, EU20-TruthfulQA and EU20-GSM8K. The paper does not claim that translating an existing benchmark automatically makes it fair. It treats translation services, benchmark construction and cross-language comparability as things to investigate.
That is the right posture. A translated test item can inherit a difficulty change, a cultural assumption or a clue that did not exist in the original. A model may score higher because the translated wording makes the answer easier, not because the model became more capable. It may score lower because a grammatical construction is unnatural in the target language, even though the underlying reasoning is sound. Both outcomes are evidence about the test as well as the model.
Human review remains necessary, but human review also needs a contract. Who reviewed the item? Were reviewers native speakers, domain specialists, or both? Did they review isolated sentences or the task in context? Were disagreements recorded? Did the benchmark preserve alternate acceptable answers? A language expert can tell us that a phrase is wrong. A domain expert can tell us why the wrongness changes a decision. A credible evaluation often needs both and must say which one it had.
The point is not to make every system pass an endless examination before anyone can use it. It is to prevent a narrow test from being mistaken for a wide claim. If a model has been evaluated on short factual questions in standard written language, report that. Do not let the result silently become a claim about spoken interaction, legal drafting, local government, children, older people or every register in the language.
Die Lektion aus Maltesisch und Baskisch
Ein auf der LREC-COLING-Konferenz 2024 vorgestelltes Papier untersuchte die Bewertung von maschineller Übersetzung für Englisch nach Maltesisch und Spanisch nach Baskisch. Die Autoren prüften die Bewertungsmetrik COMET, sammelten direkte menschliche Bewertungen und testeten, wie gut sich die Metrik verhält, wenn sie an die beiden Sprachpaare angepasst wird. Ihr Fazit ist bescheiden, aber folgenreich: Die Leistung der Metrik kann durch Feintuning verbessert werden, und sie kann stark von der Verteilung der Scores in ihren Trainingsdaten abhängen, besonders in Umgebungen mit wenigen Ressourcen.
Hier geht es nicht um eine Metrik, die versagt. Es geht darum, wovon ein Score abhängt. Eine Metrik, die auf einer Verteilung trainiert wurde, kann sich anders verhalten, wenn sie eine andere beurteilen soll. Ein Sprachpaar mit weniger Bewertungsmaterial kann den Score entschiedener wirken lassen, als er ist. Ein System, das sich bequem vergleichen lässt, kann dennoch ein schwacher Stellvertreter für das sein, was Sprecher als gute Übersetzung betrachten. Menschliche Urteile machen die Bewertung nicht perfekt, aber sie zeigen die Stellen auf, an denen ein automatisches Maß Annahmen trifft.
Eine weitere Studie aus dem Jahr 2024, Benchmarking Low-Resource Machine Translation Systems, vergleicht öffentlich verfügbare Systeme über vier Datensätze und 26 Sprachen und veröffentlicht die Ergebnisse über BENG, eine FAIR-Benchmarking-Plattform für natürliche Sprachgenerierung. Auch hier ist der Beitrag keine universelle Rangliste. Es ist ein besser überprüfbarer Vergleich. Effizienz und Effektivität werden gemeinsam betrachtet, und die Sprachliste ist sichtbar. Eine Leserin kann fragen, ob der Benchmark die relevante Route enthält, statt eine einzelne Schlagzeilenzahl zu übernehmen.
Diese Studien bieten eine europäische Lektion in Zurückhaltung. Das Schwierige ist nicht, einen weiteren Score zu erfinden. Es ist der Aufbau einer Bewertung, die der Leserin zeigt, wessen Sprache, wessen Aufgabe und wessen Qualitätsdefinition den Score hervorgebracht haben. Fehlt dieser Kontext, wird eine Zahl zu einem Grenzübertritt ohne Pass. Sie mag die Präsentation überstehen, aber niemand kann feststellen, woher sie stammt.
Sprachabdeckung kann eine Sicherheitseigenschaft sein
Sicherheitsdiskussionen konzentrieren sich oft auf Inhalte, die ein System ablehnen sollte, auf Angriffe, denen es widerstehen sollte, oder auf Fehler, die es erkennen sollte. Sprache fügt eine weitere Frage hinzu: Kann das System erkennen, wenn es außerhalb seiner Kompetenz liegt? Eine Route, die in einer Sprache funktioniert, kann in einer anderen häufiger versagen, während sie denselben selbstbewussten Ton beibehält. Wenn die Oberfläche diesen Unterschied nicht sichtbar macht, können Nutzer ihr Vertrauen nicht kalibrieren.
Dies ist besonders wichtig, wenn Sprache Teil einer sicherheitskritischen Interaktion ist. Eine Patientin oder ein Patient kann ein Symptom in einer regionalen Varietät beschreiben. Eine Arbeitskraft kann eine Gefahr mit einem lokalen Begriff melden. Eine Bewohnerin oder ein Bewohner kann einen Einspruch mit einer Schreibkonvention einreichen, die ein Normalisierer als Rauschen behandelt. Ein Modell kann in seiner Benchmark technisch korrekt und für diese Route betrieblich unsicher sein. Die relevante Frage ist nicht, ob das System eine plausible Antwort erzeugen kann. Es ist die Frage, ob die Sicherheitskontrollen anhand der Sprache und Situation, die vor ihm liegt, bewertet wurden.
Sicherheit erfordert nicht, jede Sprachroute als besonderen Notfall zu behandeln. Sie erfordert, die Kontrolle an die Konsequenz anzupassen. Ein risikoarmes Suchergebnis kann seine Quellen offenlegen und zu einer Korrektur einladen. Eine medizinische Triage-Oberfläche kann unsichere Spracheingaben an eine geschulte Fachkraft weiterleiten. Ein Arbeitsablauf für Rechtsdokumente kann Quelle und Übersetzung nebeneinander halten und vor der Veröffentlichung eine Freigabe verlangen. Ein Sprachsystem kann die Nutzerin oder den Nutzer bitten, einen Namen zu wiederholen, anstatt stillschweigend die nächstgelegene vertraute Entität auszuwählen. Dies sind gewöhnliche technische Entscheidungen, wenn Sprache als Teil der Systemgrenze behandelt wird.
Die Verweigerung selbst braucht Sprachgestaltung. Einer Nutzerin oder einem Nutzer zu sagen, dass ein System nicht antworten kann, reicht nicht aus, wenn die Verweigerung undurchsichtig, bevormundend oder in der Sprache der Nutzerin oder des Nutzers nicht verfügbar ist. Das System sollte sagen, was es nicht feststellen konnte, welche Informationen helfen würden und welche menschliche oder maßgebliche Route verfügbar ist. Andernfalls wird eine Sicherheitskontrolle zu einer weiteren Zugangsbarriere. Das Sprachprinzip Europas wird am deutlichsten getestet, wenn ein System die angeforderte Antwort nicht liefern kann.
Die operative Gestaltung eines mehrsprachigen Dienstes
Ein vertrauenswürdiger mehrsprachiger Dienst hat eine operative Form, die leicht zu beschreiben und überraschend schwer aufrechtzuerhalten ist. Erstens benennt er die Aufgabe. Übersetzung, Transkription, Klassifikation, Abruf, Zusammenfassung und Generierung sind nicht austauschbar. Zweitens benennt er die Sprachroute, einschließlich Schrift und aller relevanten regionalen oder fachlichen Grenzen. Drittens hält er das Quellmaterial und die darauf angewendeten Transformationen fest. Viertens definiert er den Prüf- und Eskalationspfad. Fünftens teilt er der Nutzerin oder dem Nutzer mit, was das System behaupten kann und was nicht.
Diese Schritte sind keine Forderung nach einer riesigen Bürokratie. Sie sind das Minimum, das nötig ist, um ein Sprachversprechen testbar zu machen. Wenn ein Anbieter sagt, dass ein Modell Finnisch unterstützt, sollte eine Käuferin oder ein Käufer fragen können, ob das Textgenerierung, Spracherkennung, Übersetzung aus welchen Sprachen oder alles zusammen bedeutet. Wenn ein Produktteam sagt, dass es eine Regionalsprache unterstützt, sollte es sagen, ob die Unterstützung auf nativen Daten, übersetzten Daten, einem kleinen Auswertungssatz oder einer Expertenprüfung beruht. Wenn die Antwort unbekannt ist, ist unbekannt ein gültiger Status.
Der Dienst braucht auch eine Änderungspolitik. Neues Trainingsmaterial, ein neuer Tokenizer, ein neues Übersetzungsmodell, eine neue Terminologieliste oder eine neue Nutzergruppe können das Sprachverhalten verändern. Eine Veröffentlichung, die eine Route verbessert, kann eine andere verschlechtern. Ein Benchmark-Ergebnis aus dem letzten Jahr beschreibt nicht automatisch das heutige System. Versionsaufzeichnungen, Vergleichstests und eine Route zur Meldung sprachspezifischer Fehler machen den Dienst wartbar statt zeremoniell.
Wartung hat eine menschliche Seite. Sprachexpertinnen und Sprachexperten brauchen eine Möglichkeit, die Fehler zu sehen, die ihre Gemeinschaften betreffen. Fachteams brauchen eine Möglichkeit, einen Übersetzungsfehler von einer politischen Mehrdeutigkeit zu unterscheiden. Betreiber brauchen eine Möglichkeit, eine Route zu pausieren, ohne darauf zu warten, dass ein Modellanbieter eine Beschwerde interpretiert. Nutzerinnen und Nutzer brauchen eine Möglichkeit zu sagen, dass das System ein Wort, einen Kontext oder den Namen einer Person missverstanden hat. Ein mehrsprachiger Dienst ist nicht vollständig, wenn das Modell bereitgestellt ist. Er ist vollständig genug, um rechenschaftspflichtig zu sein, wenn das nächste Sprachproblem auftritt.
Herkunft durch eine Sprach-Pipeline
Provenienz wird konkret, wenn wir einer einzelnen Bedeutung durch ein System folgen. Beginnen wir mit einem Quellabsatz. Erfassen Sie seine Sprache, Schrift, Autor oder Institution, sofern bekannt, Rechte und Zweck. Wenn er segmentiert ist, bewahren Sie die Beziehung zum Original. Wenn er übersetzt ist, behalten Sie die Quelle und den Übersetzer oder den Übersetzungsprozess bei. Wenn eine prüfende Person den Wortlaut ändert, erfassen Sie das als neuen Zustand, nicht als stilles Ersetzen. Wenn der Absatz zu einem Benchmark-Element wird, führen Sie die Aufgabe, den Lösungsschlüssel, die Sprache und den Prüfvermerk mit.
Zur Laufzeit gilt dieselbe Disziplin in umgekehrter Richtung. Speichern Sie, welche Sprachroute die Anfrage bearbeitet hat, welche Modell- oder Toolversion ausgeführt wurde, welche Quellenbelege abgerufen wurden, welcher Unsicherheits- oder Verweigerungszustand erreicht wurde und welche menschliche Aktion folgte. Der Datensatz muss privaten Inhalt nicht jedem Bediener offenlegen. Er muss aber die wesentlichen Fakten einer autorisierten prüfenden Person zugänglich machen. Ohne sie wird ein Sprachvorfall zu einer Debatte über Eindrücke.
Hier unterscheidet sich mehrsprachige Provenienz von einem generischen Prüfprotokoll. Ein Zeitstempel und ein Modellname sagen uns, dass etwas passiert ist. Sie sagen uns nicht, ob die Quelle übersetzt wurde, ob die Antwort ein Zahlenformat geändert hat, ob eine benannte Entität normalisiert wurde oder ob die prüfende Person in der Zielsprache gearbeitet hat. Der Transformationspfad ist der Beleg. Eine kurze Antwort kann eine lange Kette von Entscheidungen verbergen.
Es steckt eine kleine niederländische Tugend in diesem Ansatz: Halten Sie das Protokoll langweilig genug, dass jemand es an einem Dienstagnachmittag nutzen kann. Ein Provenienzdatensatz sollte kein Museumsschild sein, das für eine Prüfung geschrieben wurde, die vielleicht nie kommt. Er sollte einem Bediener helfen, die nächste Frage zu beantworten, die richtige Route zu stoppen und das Ergebnis einer Person zu erklären, die kein Interesse an Ihrem Architekturdiagramm hat. Gute Sprachgovernance ist leicht langweilig. So wissen Sie, dass sie den Kontakt mit der Arbeit überleben könnte.
Die verborgenen Entscheidungen in einer Übersetzung
Jedes Übersetzungssystem trägt Entscheidungen in sich, die Namen verdienen. Die Tokenisierung entscheidet, wie die Eingabe aufgeteilt wird. Die Normalisierung entscheidet, welche Unterscheidungen bewahrt oder verworfen werden. Die Ausrichtung entscheidet, welche Teile zweier Texte als gleichwertig behandelt werden. Die Terminologie entscheidet, welche Wörter stabil sind. Das Decoding entscheidet, wie die Ausgabe ausgewählt wird. Die Nachbearbeitung entscheidet, was die Leserin oder der Leser sieht. Keiner dieser Schritte ist von Natur aus falsch. Jeder kann einen sprachspezifischen Fehler erzeugen, der in einer allgemeinen Demo unsichtbar ist.
Nehmen wir einen Eigennamen. Ein System kann ihn übersetzen, transliterieren, bewahren oder durch eine vertraute Schreibweise ersetzen. Bei einem Gedicht können mehrere Entscheidungen vertretbar sein. Bei einem Identitätsdokument kann nur eine akzeptabel sein, und diese kann von der ausstellenden Behörde abhängen. Nehmen wir eine Einheit oder ein Datum. Die Werte können mathematisch gleichwertig bleiben, während die Form für eine Leserin oder einen Leser mehrdeutig wird. Nehmen wir ein geschlechtsspezifisches Nomen oder Pronomen. Eine Übersetzung kann Informationen einführen, die die Quelle zurückgehalten hat, oder eine Unterscheidung auslöschen, die die Quelle bewusst getroffen hat.
Die gestalterische Antwort ist nicht, Sprache einzufrieren. Es geht darum, die Richtlinie zu benennen und die Ausnahme sichtbar zu machen. Eine Terminologieliste kann Rechtsbegriffe schützen. Eine Regel für benannte Entitäten kann verhindern, dass eine Stadt zu einer Person wird. Eine quellenerhaltende Ansicht kann einer prüfenden Person den Vergleich von Original und Ausgabe ermöglichen. Eine Eskalation an Menschen kann durch einen Namen mit geringer Konfidenz, eine Uneinigkeit zwischen Routen oder eine als folgenreich eingestufte Aufgabe ausgelöst werden. Das Modell bleibt nützlich, weil seine Grenzen Teil des Arbeitsablaufs sind.
Große Sprachmodelle machen die Entscheidungen schwerer erkennbar, weil die Ausgabe so glatt ist. Eine glatte Ausgabe ist eine wunderbare Benutzeroberfläche und eine unzuverlässige Erklärung. Das System kann einen Satz erzeugen, der sich muttersprachlich anhört, während es die falsche Wortbedeutung auswählt. Es kann das allgemeine Thema beibehalten und dabei eine Verneinung weglassen. Es kann einen lokalen Ausdruck in eine standardisierte Formulierung übersetzen, die die Position des Sprechers verändert. Deshalb kann Sprachqualität nicht allein durch Grammatik dargestellt werden. Bedeutung hat eine soziale Form.
Schriften, Dialekte, Register und Institutionen
Sprachunterstützung wird oft auf der Ebene eines Sprachnamens angekündigt, aber die Leser begegnen Schriften, Varietäten und Registern. Ein System, das mit moderner Standardorthografie umgeht, kann bei historischen Dokumenten scheitern. Ein Spracherkenner kann Studioaudio verarbeiten und in einem überfüllten Bahnhof versagen. Ein öffentlicher Chatbot kann in einem formellen Register antworten, während der Nutzer eine einfache Sprache benötigt. Eine Institution kann aus rechtlich bedeutsamen Gründen einen Begriff verwenden, der sich von der Alltagssprache unterscheidet.
Das sind keine Randfälle im abwertenden Sinne. Es sind die Orte, an denen Sprache auf die Welt trifft. Ein regionaler Name kann den Unterschied zwischen einer korrekten Adresse und einer fehlgeschlagenen Zustellung ausmachen. Ein Dialektwort kann das einzige Wort sein, das eine Person für ein Symptom kennt. Eine formelle Formulierung kann signalisieren, dass eine Nachricht rechtliche Wirkung hat. Eine Schriftsvariante kann darüber entscheiden, ob ein Dokument durchsuchbar ist. Wenn ein Benchmark diese Wege ausschließt, kann er dennoch nützlich sein, aber er kann nicht für die gesamte Sprache stehen.
Alle Varietäten zu testen ist nicht immer möglich. Die ehrliche Antwort ist, die unterstützte Teilmenge zu beschreiben und zu Belegen für den Rest einzuladen. Ein System kann veröffentlichen, dass es für die Zusammenfassung öffentlicher Informationen im standardisierten geschriebenen Niederländisch evaluiert wurde, ohne einen Anspruch auf regionale Spracherkennung zu erheben. Es kann einen Test für Friesisch oder Baskisch hinzufügen, ohne so zu tun, als würde die Ergänzung alle Fragen zu regionalen und Minderheitensprachen klären. Spezifität ist keine Schwäche. Sie zeigt den Nutzern, wo die Untergrenze liegt.
Institutionen sollten auch der Vorstellung widerstehen, dass ein nationaler Sprachpfad automatisch neutral ist. Verwaltungssprache kann für Sprecher derselben Sprache unzugänglich sein. Barrierefreiheit und Mehrsprachigkeit überschneiden sich, weil beide danach fragen, ob die Leser verstehen und handeln können. Die Spracharbeit der Kommission umfasst aus genau diesem Grund Werkzeuge zur Vereinfachung und barrierefreie Texte. Ein Satz kann sprachlich korrekt und dennoch institutionell unbrauchbar sein.
Wenn die Benutzeroberfläche fließend, aber falsch ist
Die schwierigsten Sprachfehler sind nicht spektakulär. Es sind Antworten, die den Augenschein bestehen. Eine Zusammenfassung enthält die richtigen Namen, ändert aber, wer verantwortlich ist. Eine Übersetzung bewahrt die Substantive, verwandelt aber eine Empfehlung in eine Anweisung. Ein Klassifikator versteht das Thema, übersieht aber eine Verneinung. Ein Sprachsystem erkennt die Wörter, aber nicht das Zögern des Sprechers. Ein Nutzer liest die Ausgabe in seiner eigenen Sprache und nimmt an, dass Flüssigkeit ein Zeichen von Sorgfalt ist.
Wir sollten für diese Fehlerklasse entwerfen, statt darauf zu warten, dass ein bizarres Beispiel Schlagzeilen macht. Vergleichen Sie Quelle und Ausgabe bei Inhalten mit hohen Konsequenzen. Bewahren Sie Unsicherheitsmarker. Halten Sie Zitate oder Dokumentverweise an. Fragen Sie nach Bestätigung, wenn eine Zahl, ein Name oder eine Frist zentral ist. Machen Sie den Weg für die Bedienperson sichtbar. Bieten Sie einen Korrekturmechanismus an, der nicht erfordert, dass der Nutzer weiß, welche Komponente versagt hat. Diese Kontrollen sind klein, aber sie machen aus einer Übersetzung eine überprüfbare Transaktion.
Menschliche Prüfung sollte nicht als magische letzte Instanz beschrieben werden. Prüfende haben Zeitlimits, Wissenslücken und ihre eigenen sprachlichen Annahmen. Eine nützliche Prüfungsoberfläche gibt ihnen die Quelle, die Ausgabe, den Kontext und den Grund für die Eskalation. Sie hält Uneinigkeit fest, statt sie zu glätten. Wenn Prüfende wiederholt einen Begriff korrigieren, kann die Organisation die Terminologie verbessern oder die Aufgabenabgrenzung ändern. Wenn die Uneinigkeit zeigt, dass die Quelle selbst mehrdeutig ist, kann die richtige Maßnahme sein, die Autorin oder den Autor zu fragen, statt das Modell stärker zu trainieren.
Betreibende brauchen außerdem eine Möglichkeit, negative Belege zu sehen. Welche Sprachen wurden nicht ausgewertet? Welche Aufgaben haben keine menschliche Prüfung? Welche Anfragen wurden abgelehnt? Welche Nutzerinnen und Nutzer haben die Route nach einer Übersetzung verlassen? Eine Abwesenheit kann ein Signal sein. Eine grüne Abdeckungsgrafik, die die fehlgeschlagenen Pfade auslässt, ist eine Karte der Marketingoberfläche, nicht des Dienstes.
Menschliche Expertise ist kein Notfallknopf
Die europäische Sprachtechnologiepolitik nennt Sprachwissenschaftlerinnen und Sprachwissenschaftler, Datenwissenschaftlerinnen und Datenwissenschaftler, Computertechnikerinnen und Computertechniker sowie Fachleute aus den jeweiligen Domänen im selben Satz. Das ist eine Designanforderung, keine Liste von Berufen, die man zu einem Startgespräch einlädt. Jede Person sieht ein anderes Versagen. Die Sprachwissenschaftlerin oder der Sprachwissenschaftler sieht eine unnatürliche Konstruktion oder einen verlorenen Unterschied. Die Ingenieurin oder der Ingenieur sieht ein Segmentierungs- oder Routingproblem. Die Domänenfachperson sieht einen gefährlichen Kategorienfehler. Die Betreiberin oder der Betreiber sieht eine Warteschlange, für die niemand zuständig ist. Die Person, die den Dienst nutzt, erlebt eine Entscheidung, die keinen Sinn mehr ergibt.
Menschliche Expertise sollte einfließen, bevor der Benchmark eingefroren wird. Eine Sprachfachperson kann helfen, Testmaterial auszuwählen, das reale Register repräsentiert, statt nur saubere Sätze. Eine Domänenfachperson kann Begriffe identifizieren, die nicht abweichen dürfen. Eine Vertretung der Community kann einem Team sagen, welche Formulierung offiziell, vertraut oder beleidigend wirkt. Eine Datenverantwortliche oder ein Datenverantwortlicher kann erklären, welche Herkunft verfügbar ist und welche nicht. Diese Beiträge prägen den Vertrag des Systems. Sie sind keine Dekoration, nachdem die technischen Entscheidungen getroffen wurden.
Es gibt natürlich Kosten. Gute Prüfung braucht Zeit und bezahlt Menschen für Wissen, das oft als unsichtbar behandelt wird. Diese Kosten sind Teil der Sprachunterstützung. Die Alternative ist, sie auf die Nutzerinnen und Nutzer abzuwälzen, die mit Verwirrung und Beschwerden zahlen, oder auf das Personal, das die Route informell übersetzt und repariert. Ein System, das billig wirkt, weil es Sprachexpertise ignoriert, ist nicht effizient. Es hat nur die Rechnung verschoben.
Was ein fairer Benchmark offenlegen muss
Ein mehrsprachiger Benchmark sollte mit einer Behauptung beginnen, die klein genug ist, um getestet zu werden. Die Behauptung könnte sein, dass ein System Fragen zu öffentlichen Informationen in einer Reihe von Sprachen beantworten, Daten und Zahlen erhalten und ablehnen kann, wenn die Quellenbelege fehlen. Es könnte sein, dass eine Übersetzungsroute ein bestimmtes Sprachenpaar und eine bestimmte Domäne auf einem definierten Qualitätsniveau bearbeitet. Es könnte sein, dass ein Spracherkenner eine bestimmte Varietät unter bestimmten akustischen Bedingungen transkribieren kann. Der Benchmark ist ein Vertrag für diese Behauptung.
Der Vertrag braucht mehr als eine Sprachliste. Er sollte die Aufgabe, die Quelle, die Domäne, das Register, die Schrift, die Richtung, die Kontextlänge, die Eingabebedingungen, die Referenzantworten, die akzeptablen Varianten, die Metriken, die menschliche Prüfung und die Unsicherheit offenlegen. Er sollte angeben, ob die Einträge ursprünglich in jeder Sprache verfasst oder übersetzt wurden. Er sollte festhalten, wer sie überarbeitet hat und welche Uneinigkeiten bestehen blieben. Er sollte Gesamtergebnisse von Ergebnissen pro Sprache trennen. Er sollte genügend Beispiele zeigen, damit eine Leserin oder ein Leser versteht, was der Wert misst.
The EU MMLU criteria are useful because they widen the word fair. Balanced representation across the EU’s official languages is one part. Retaining meaning, difficulty and testing value across languages is another. Testing EU values and cultural contexts, including idioms, humour, references, date and number formats, tone and politeness, makes the benchmark a social instrument as well as a technical one. The criteria do not remove judgement. They make the judgement inspectable.
Benchmark designers should publish failure slices, not only averages. A model can have a good mean score while failing every item involving a particular register or type of number. A route can be efficient in one direction and slow or expensive in another. A metric can correlate with human judgement in one language and become unstable in another. Per-language and per-task views are not a luxury. They are how a buyer avoids purchasing the average while deploying the exception.
Finally, a benchmark should state what it cannot tell us. A written test does not establish speech performance. A translation score does not establish legal reliability. A set of official languages does not establish support for regional or minority languages. A high score does not establish that a person can challenge a decision. The limitation is not an embarrassment. It is the edge of the map, and users need to see it before they sail.
A score is a map legend, not the territory
Numbers are useful because they force a comparison. They are dangerous because they invite a conclusion larger than the measurement. A score can tell us how a system behaved on a defined sample under a defined method. It cannot tell us how a community will experience the system without a bridge of assumptions. The bridge may be sound. It must be named.
Suppose a system improves on a multilingual benchmark after fine-tuning. That is evidence of improved performance on that evaluation. It is not automatically evidence that the system is safer in a public service. The service may use different terminology, longer context, speech input, a different register or a downstream workflow that turns a suggestion into a decision. The benchmark can still be valuable. It becomes more valuable when the organisation says which part of the service it represents.
The same discipline applies to energy, speed and cost. A low-resource language route may require more human review or a larger retrieval context. That is not a defect to conceal in an average. It is a property of the service that should inform design. European institutions have spent decades building translation and language services because the practical cost of linguistic diversity is real. An AI system does not abolish that cost by emitting text quickly.
There is no shame in choosing a narrower route. A team can support fewer tasks well, publish the boundary and add languages as evidence grows. That is better than claiming every language and asking users to discover the gaps. The European instinct for a standard is strongest when it is paired with the Dutch instinct to check whether the thing works on an ordinary Wednesday.
Build for 24, test beyond 24
The European Union has 24 official and working languages, and the Commission’s translation service operates across them. That number creates a useful baseline for public infrastructure. It does not define Europe’s linguistic life. Regional, minority, non-territorial and migrant languages also shape communities and institutions. A system built for 24 can still exclude people who do not use one of those routes, or who use an official language in a form the system did not evaluate.
Für 24 zu bauen bedeutet daher, die Grundlage real zu machen, nicht die Erlaubnis, aufzuhören. Ein Sprachpfad sollte seine eigene Evidenz mit sich führen. Eine öffentliche Einrichtung sollte sagen können, welche Amtssprachen für welche Aufgaben abgedeckt sind, welche menschliche Prüfung es gibt und wo Nutzer eine maßgebliche Fassung erhalten können. Sie sollte auch einen Weg haben, aus Sprachen außerhalb des anfänglichen Sets zu lernen, ohne die Gemeinschaft in ein unbezahltes Testlabor zu verwandeln.
Über 24 hinaus zu testen bedeutet mehr, als eine neuartige Sprache zu einer Demo hinzuzufügen. Es bedeutet, mit Sprechenden, Institutionen und Forschenden zu arbeiten, um zu entscheiden, was die Aufgabe ist, wofür das Quellmaterial verwendet werden darf und was als schädlicher Fehler gilt. Der Prozess kann eine kleine, sorgfältig abgegrenzte Fähigkeit hervorbringen. Das ist immer noch Fortschritt. Ein bescheidener Pfad mit einem klaren Vertrag kann wertvoller sein als eine beeindruckende Behauptung, die kein Betreiber verteidigen kann.
Was wir explizit machen wollen
Bei Dweve nähern wir uns diesem Thema von der Infrastrukturseite. Loom wird in unserem öffentlichen Produktmaterial als ein aufgabenkompilierendes kognitives Modell beschrieben, dessen Sprachkomponenten einen gesteuerten Ergebnisgraphen rendern, während Constraint-Lernen, Graphkomposition, Solver und Verifikation die Entscheidungsautorität tragen. Das ist eine architektonische Position, keine Behauptung über mehrsprachige Leistungsfähigkeit. Sie macht einen Sprachpfad nicht korrekt. Sie macht eine Verpflichtung schwer zu verbergen: Die Sprachausgabe sollte nicht der einzige Ort sein, an dem die Argumentation und Evidenz des Systems existieren.
Unsere Ground-Truth-Arbeit macht denselben Punkt in einem menschlicheren Maßstab. Menschen brauchen genug gemeinsame Sprache, um ein Modell von einem Workflow, eine Vorhersage von Evidenz und eine flüssige Antwort von einem geprüften Ergebnis zu unterscheiden. In mehrsprachigen Systemen braucht dieses Vokabular ein weiteres Wort: Pfad. Eine niederländische Antwort, eine französische Antwort und eine baskische Antwort sind nicht bloß Wiedergaben eines internen Ereignisses, wenn sich Evidenz, Terminologie, Prüfung und Fehlerverhalten unterscheiden. Der Pfad ist Teil der Behauptung.
Diese Position ist bewusst weniger aufregend als zu sagen, dass ein Modell Europa versteht. Sie ist auch nützlicher. Wir wollen, dass ein System zeigt, was es erhalten hat, welche Quellen und Constraints es nutzen konnte, was es nicht feststellen konnte und wann ein Mensch übernehmen sollte. Sprache ist eine Oberfläche, durch die eine Person dieser Arbeit begegnet. Die Oberfläche sollte klar sein, aber sie darf nicht die Struktur darunter auslöschen.
Wir sind von den hier beschriebenen Standards nicht ausgenommen. Ein Herkunftsfeld repariert keine fehlenden Daten. Ein deterministischer Pfad beweist nicht, dass eine Übersetzung fair ist. Eine europäische Verarbeitungsgrenze verleiht keine sprachliche Kompetenz. Der einzige ehrliche Weg, eine mehrsprachige Behauptung aufzustellen, ist, weiter zu testen, die Grenzen zu veröffentlichen und Sprachexperten den Pfad herausfordern zu lassen. Der Produktname ist keine Evidenz. Der Datensatz ist es.
Ein praktischer Standard für Teams
Teams, die entscheiden, ob sie ein mehrsprachiges KI-Feature einführen, können mit einer kurzen Reihe von Fragen beginnen. Was genau muss das System in jeder Sprache tun? Welche Menschen sind betroffen, wenn es falsch liegt? Welches Quellmaterial ist maßgeblich? Wie wurden die Testelemente erstellt, und von wem? Welche Register, Schriften, Dialekte und Domänen sind Teil der Behauptung? Was tut das System, wenn es keine Bedeutung feststellen kann? Wer kann den Pfad anhalten? Wie kann ein Nutzer eine Antwort korrigieren, ohne der unbezahlte Linguist des Projekts zu werden?
Die Fragen werden konkret, wenn sie an Artefakte gebunden sind. Führen Sie eine Sprachpfad-Karte mit der Aufgabe, den unterstützten Sprachvarianten, Quellfamilien, Rechtestatus, Modell- und Toolversionen, Evaluationsergebnissen, bekannten Fehlermodi und Prüfverantwortlichen. Halten Sie Beispiele von Fehlern mit ihrem Kontext fest, nicht nur eine Punktzahl. Halten Sie die Quelle neben einer folgenreichen Übersetzung. Halten Sie einen Eskalationsgrund fest, den ein Betreiber verstehen kann. Führen Sie ein Änderungsprotokoll, wenn sich Tokenizer, Terminologieliste, Benchmark oder Modell ändern.
Beschaffungsteams können Lieferanten um Ergebnisse pro Sprache und pro Aufgabe bitten, statt um einen einzigen mehrsprachigen Durchschnitt. Sie können fragen, ob ein Benchmark übersetzt oder nativ erstellt wurde, ob menschliche Bewertungen vorliegen, wie mit ressourcenarmen Sprachen umgegangen wird und ob der Lieferant die für eine Überprüfung nötigen Belege exportieren kann. Sie können fragen, was passiert, wenn eine Sprache nicht unterstützt wird, denn eine Ablehnung und ein stiller Rückgriff auf eine andere Sprache haben sehr unterschiedliche Folgen.
Produktteams können die Oberfläche so gestalten, dass sie Route und Konfidenz anzeigt, ohne so zu tun, als sei eine Konfidenzzahl eine Wahrheitswahrscheinlichkeit. Sie können Quelllinks erhalten, in Ablehnungen eine klare Sprache verwenden und Überprüfungsaktionen sichtbar machen. Sie können den Ausdruck unterstützt alle Sprachen vermeiden, es sei denn, sie können das Verb definieren. Unterstützen kann bedeuten: Text anzeigen, Eingaben annehmen, übersetzen, zusammenfassen, antworten, klassifizieren, sprechen oder einen regulierten Arbeitsablauf abwickeln. Ein Sprachauswahlmenü ist keine Spezifikation.
Forschungsteams können Datensätze mit Herkunftsnachweis und Korrekturwegen veröffentlichen. Sie können negative Ergebnisse aufnehmen und berichten, wenn eine Kennzahl nicht übertragbar ist. Sie können Sprachgemeinschaften in die Evaluierung einbeziehen, bevor ein Modell als einsatzbereit erklärt wird, und für deren Fachwissen bezahlen. Sie können dem Druck widerstehen, ein enges Ergebnis in einen universellen Anspruch umzuwandeln. Der wertvollste Benchmark könnte der sein, der ein Team dazu bringt, einen Satz von seiner Produktseite zu entfernen.
Die Gesellschaft hinter dem Modell
Ein Sprachmodell kann sehr gut darin sein, Sprache zu erzeugen, ohne zu wissen, was Sprache in einer Gesellschaft bewirkt. Es kann einen Satz vorhersagen, einen Absatz übersetzen und eine Frage beantworten und dabei die institutionelle Beziehung übersehen, die in den Worten steckt. Diese Lücke ist kein Beleg dafür, dass das Modell nutzlos ist. Sie ist ein Beleg dafür, dass Sprache mehr ist als ein Datentyp.
Die Antwort Europas sollte kein Wettbewerb darum sein, Sprachen in einer Modellkarte zu zählen. Sie sollte eine dauerhafte Anstrengung sein, Sprachdaten, Rechte, Fachwissen, Evaluierung und öffentliche Kontrolle zu Teilen derselben Infrastruktur zu machen. Die Sprachtechnologiearbeit der Kommission, der Language Data Space, der European Language Grid und der EU-MMLU-Benchmark weisen alle in diese Richtung. Europäische Forschende testen, was passiert, wenn übersetzte Benchmarks als Forschungsfragen behandelt werden statt als unangefochtene Instrumente. Diese Arbeit verdient Aufmerksamkeit, weil sie eine alte politische Tatsache technisch sichtbar macht: Die Menschen erleben die Union nicht in einer einzigen Sprache.
Wenn ein Lieferant das nächste Mal sagt, ein Modell sei mehrsprachig, fragen Sie, was diese Behauptung enthält. Welche Sprachen? Welche Aufgaben? Welche Gemeinschaften? Welche Quellen? Welche Überprüfung? Welche Ablehnung? Welches Änderungsprotokoll? Die Frage ist nicht feindselig. Sie ist der gewöhnliche Anfang von Rechenschaftspflicht.
Eine Gesellschaft wird nicht dadurch gerecht, dass eine Maschine ihre Worte wiederholen kann. Sie wird gerechter, wenn Menschen in ihre Institutionen eintreten können, verstehen, was geschieht, ein Ergebnis anfechten und in der Sprache gehört werden, die ihr Leben trägt. Ein Modell kann diese Arbeit unterstützen. Es kann sie nicht definieren. Die Sprache eines Modells ist eine technische Fähigkeit. Die Sprache einer Gesellschaft ist eine gemeinsame Verantwortung.
Quellen
- Auf dem Weg zu fairer mehrsprachiger KI: EU MMLU, eine neue EU-Benchmark für LLMs, Generaldirektion Übersetzung der Europäischen Kommission, 22. Juli 2026.
- Sprachtechnologien, Europäische Kommission, zuletzt aktualisiert am 23. Juni 2026.
- Die Verwendung der Sprachen durch die Kommission, Europäische Kommission, abgerufen am 26. Juli 2026.
- Charta der Grundrechte der Europäischen Union, Artikel 22: Kulturelle, religiöse und sprachliche Vielfalt, EUR-Lex, 7. Juni 2016.
- Towards Multilingual LLM Evaluation for European Languages, Klaudia Thellmann und Kollegen, arXiv:2410.08928, Oktober 2024.
- COMET for Low-Resource Machine Translation Evaluation: A Case Study of English-Maltese and Spanish-Basque, Júlia Falcão, Claudia Borg, Nora Aranberri und Kurt Abela, LREC-COLING 2024.
- Benchmarking Low-Resource Machine Translation Systems, Ana Silva und Kollegen, LoResMT 2024.
- Dweve Loom, öffentliche Produktbeschreibung von Dweve, abgerufen am 26. Juli 2026.