Traduction automatique : le problème des langues peu dotées

Il existe environ 7 000 langues parlées sur Terre. Google Traduction en prend en charge une centaine. La plupart des systèmes commerciaux de TA gèrent correctement moins de 30 langues. Si vous parlez yoruba, quechua ou khmer, votre expérience de la traduction automatique va de « à peine utilisable » à « franchement hilarante, et fausse ». La vérité embarrassante, c'est que l'essentiel des progrès du TAL ces dix dernières années s'est fait d'abord pour l'anglais, et que l'écart entre langues riches en ressources et langues pauvres se creuse au lieu de se réduire.

L'effort récent de Meta vers la traduction automatique omnilingue, couvrant plus de 1 600 langues, est l'une des tentatives les plus ambitieuses pour changer cela. Mais les défis techniques révèlent des hypothèses fondamentales ancrées dans la façon dont nous construisons les modèles de langage, et expliquent pourquoi il ne suffit pas d'augmenter la taille des modèles pour résoudre le problème.

Ce qui fait d'une langue une langue « peu dotée »

En recherche sur la TA, une paire de langues « riche en ressources » signifie que vous disposez de millions de phrases parallèles, c'est-à-dire de textes traduits professionnellement d'une langue à l'autre. Anglais–français, anglais–chinois, anglais–espagnol : ces paires disposent de corpus parallèles énormes, issus du Parlement européen, de l'ONU, des agences de presse et de décennies de traduction professionnelle. Les modèles entraînés sur ces paires fonctionnent remarquablement bien.

Une langue « peu dotée » peut ne disposer que de quelques milliers de phrases parallèles, voire d'aucune. Le fon (parlé par environ 2 millions de personnes au Bénin) ne dispose pratiquement d'aucune donnée parallèle avec l'anglais. Le bambara (parlé par environ 14 millions de personnes au Mali) en possède un peu plus, mais toujours des ordres de grandeur de moins que ce dont les systèmes de TA classiques ont besoin. Pour beaucoup de langues, le plus grand corpus textuel disponible est une traduction de la Bible, et peut-être quelques articles Wikipédia.

L'écart de ressources ne tient pas seulement au volume de données, mais aussi à leur diversité. Même lorsqu'un texte parallèle existe pour une langue peu dotée, il tend à se concentrer sur des textes religieux ou des documents administratifs. Le modèle apprend à traduire une prose formelle et répétitive, mais s'effondre dès qu'il s'agit de conversation courante, de terminologie technique ou de tout ce qui sort du domaine étroit sur lequel il a été entraîné.

Pourquoi on ne peut pas simplement passer à l'échelle

L'instinct dans le ML moderne se résume ainsi : plus de données, un modèle plus grand, de meilleurs résultats. Cela a fonctionné à merveille pour les tâches centrées sur l'anglais. Les modèles de type GPT, entraînés sur des milliers de milliards de tokens anglais, produisent un texte remarquablement fluide. Mais cette approche présente trois modes d'échec critiques pour la TA en langues peu dotées.

• Les données tout simplement n'existent pas. Vous ne pouvez pas extraire du texte parallèle fon–anglais d'internet si personne n'en a jamais publié de quantité significative. Le web scraping, qui alimente la plupart des corpus d'entraînement de TA à grande échelle, est intrinsèquement biaisé en faveur des langues ayant une forte présence en ligne.
• La tokenisation s'effondre. La plupart des modèles de langage utilisent des tokenizers entraînés principalement sur l'anglais (ou sur une poignée de langues riches en ressources). Quand vous faites passer du texte amharique ou birman dans un tokenizer BPE entraîné sur l'anglais, il fragmente les caractères en séquences de tokens absurdement longues. Un seul mot amharique peut consommer 8 à 12 tokens. Le modèle utilise donc l'essentiel de sa fenêtre de contexte pour encoder l'entrée, ne laissant que peu de place pour la comprendre réellement.
• Le transfert d'apprentissage a ses limites. Les modèles multilingues comme mBERT ou XLM-R montrent qu'entraîner sur de nombreuses langues peut aider les langues peu dotées : le modèle capte des similarités structurelles. Mais ce transfert est surtout efficace entre langues apparentées. Un modèle qui maîtrise bien le français peut transférer une partie de ce savoir au créole haïtien. Il ne transfère presque rien au mandarin ou au navajo.

Le problème du pivot linguistique

La plupart des systèmes de TA qui prétendent gérer des centaines de langues passent en réalité tout par l'anglais. Vous voulez traduire du swahili vers le thaï ? Le système traduit swahili → anglais → thaï. Cette approche « pivot » est pratique, car il suffit de construire des modèles de traduction vers et depuis l'anglais, mais elle introduit des erreurs qui s'accumulent et une forme subtile d'aplatissement culturel.

Quand on passe par l'anglais, on perd les concepts qui ne se transposent pas proprement dans cette langue. Le japonais encode plusieurs niveaux de politesse dans les formes verbales. Le yoruba possède des distinctions tonales qui modifient le sens. Le tamoul distingue le « nous » inclusif et le « nous » exclusif, selon que l'interlocuteur est inclus ou non. Quand ces informations passent par le goulot d'étranglement de l'anglais, elles disparaissent : l'anglais ne les encode pas, et le modèle n'a aucun moyen de les préserver.

La traduction directe entre paires de langues non anglaises, du swahili directement vers le thaï sans le détour par l'anglais, préserve davantage d'informations. Mais construire des modèles directs pour chaque paire possible est combinatoirement impossible. Avec 1 600 langues, il faudrait 2,56 millions de paires de traduction orientées. Même si l'on ne traite directement que les 100 langues les plus parlées, cela représente encore 9 900 paires.

Comment les approches modernes diffèrent

La génération actuelle de modèles de TA massivement multilingues adopte une approche fondamentalement différente de la stratégie du pivot. Plutôt que de construire un modèle distinct pour chaque paire de langues, ils entraînent un seul modèle qui apprend une représentation partagée de toutes les langues simultanément. Les innovations clés se répartissent en quelques catégories.

Tokenisation indépendante de la langue

Le problème du tokenizer est traité en entraînant les tokenizers sur des corpus multilingues équilibrés plutôt que sur des corpus dominés par l'anglais. L'approche de Meta utilise un repli au niveau caractère qui garantit qu'aucune langue ne produit de séquences de tokens anormalement longues. Les modèles SentencePiece entraînés avec un équilibrage explicite des langues produisent une tokenisation bien plus équitable : une phrase en yoruba et une phrase en anglais de sens similaire consomment à peu près le même nombre de tokens.

C'est plus important qu'il n'y paraît. Si votre tokenizer est 4 fois moins efficace pour la langue X, votre modèle dispose en pratique de 4 fois moins de capacité pour traiter cette langue. Corriger la tokenisation est, à lui seul, l'amélioration au meilleur rendement pour les performances en langues peu dotées.

Extraire des données parallèles du web

L'une des contributions techniques les plus astucieuses est l'extraction automatique de données parallèles. L'idée : entraîner un encodeur de phrases multilingue qui projette les phrases de n'importe quelle langue dans un espace d'embeddings commun. Puis on explore le web à la recherche de phrases dans différentes langues dont les vecteurs sont proches : il s'agit probablement de traductions l'une de l'autre.

Cette technique, initiée par des outils comme LASER puis étendue par des travaux plus récents, a permis d'extraire des centaines de millions de phrases parallèles à partir de corpus web comme CCNet et OSCAR. Elle est bruitée (peut-être 20 à 30 % des paires extraites sont réellement parallèles), mais des heuristiques de filtrage améliorent la précision, et le volume compense le bruit. Pour certaines langues, cette extraction automatique a produit davantage de données parallèles que l'ensemble des jeux de données précédemment annotés par des humains réunis.

Rétrotraduction et auto-apprentissage

La rétrotraduction (back-translation) consiste à utiliser votre modèle de TA existant, imparfait, pour traduire du texte monolingue vers la langue cible, puis à utiliser ces paires parallèles synthétiques pour entraîner un meilleur modèle. C'est de l'amorçage, et ça marche étonnamment bien.

Le cycle se déroule ainsi : entraîner un modèle initial sur les données parallèles disponibles, l'utiliser pour traduire des données monolingues, filtrer les mauvaises traductions, réentraîner sur l'ensemble des données réelles et synthétiques, puis recommencer. Chaque itération améliore le modèle, qui produit de meilleures données synthétiques, lesquelles améliorent encore la suivante. Pour les langues dont on part de quelques milliers de phrases parallèles seulement, la rétrotraduction peut multiplier effectivement les données d'entraînement par 10 à 50.

# 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

L'évaluation est plus difficile qu'il n'y paraît

Les scores BLEU, la métrique standard de qualité en TA, posent de sérieux problèmes pour les langues peu dotées. BLEU mesure le recouvrement de n-grammes entre la sortie du modèle et une traduction de référence. Cela fonctionne raisonnablement bien pour l'anglais, qui a un ordre des mots assez fixe et une morphologie limitée. Mais pour les langues agglutinantes comme le turc ou le finnois, où un seul mot peut exprimer ce que l'anglais rend par toute une phrase, BLEU pénalise des traductions valides qui utilisent d'autres formes morphologiques.

Il y a aussi le problème des références : qui rédige les traductions de référence auxquelles on compare ? Pour les langues riches en ressources, on dispose de traducteurs professionnels. Pour beaucoup de langues peu dotées, les traductions « étalons » ont été produites par des missionnaires, des traducteurs administratifs travaillant dans un registre formel, ou des étudiants en master. Ces références peuvent être techniquement correctes mais stylistiquement peu naturelles, et un modèle qui produit des traductions plus naturelles obtient en fait un score plus bas.

Des métriques plus récentes comme COMET et BLEURT utilisent des modèles neuronaux pour estimer la qualité des traductions et corrèlent mieux avec le jugement humain. Mais elles ont aussi été entraînées principalement sur des données de langues riches en ressources, et risquent donc de mal se généraliser aux langues aux structures très différentes. Certaines équipes ont commencé à faire évaluer par des locuteurs natifs leurs paires de langues les plus critiques, mais cette approche ne passe pas à l'échelle de 1 600 langues.

Les dimensions culturelles et éthiques

Construire de la TA pour 1 600 langues n'est pas seulement un défi d'ingénierie. Cela soulève des questions : qui en profite, qui décide de la manière dont les langues sont représentées, et que se passe-t-il quand les modèles encodent des traductions erronées ou biaisées.

Pour beaucoup de langues en danger, les locuteurs principaux sont des membres âgés de communautés rurales. Ce ne sont pas eux qui utilisent les API de traduction automatique. Les premiers bénéficiaires sont plutôt les chercheurs, les ONG et les gouvernements, ce qui peut être positif (meilleur accès à l'information) ou problématique (surveillance, assimilation forcée), selon le contexte. La TA pour les langues autochtones, développée sans la participation des communautés, a un passé douloureux.

Se pose aussi la question de la standardisation linguistique. Beaucoup de langues peu dotées présentent une variation dialectale importante et n'ont pas de forme « standard » unique. Quand un modèle de TA retient un dialecte comme référence (généralement celui le mieux représenté dans les données d'entraînement), il marginalise implicitement les locuteurs des autres dialectes. Ce n'est pas hypothétique : cela se produit déjà avec des langues mieux dotées. Les modèles de TA pour l'arabe gèrent généralement bien l'arabe standard moderne, mais peinent avec les dialectes égyptien, levantin ou du Golfe, que des centaines de millions de personnes parlent réellement.

Ce que cela signifie pour les développeurs

Si vous développez un logiciel destiné à un public mondial, l'état de la TA a des implications pratiques pour vos choix d'architecture et de produit.

• Ne partez pas du principe que la qualité de la TA est uniforme. Votre application utilise peut-être Google Traduction ou une API similaire pour la localisation. La qualité pour le français est excellente. Pour l'amharique, elle peut être à la limite de l'inutilisable. Testez avec des locuteurs natifs pour chaque langue que vous prétendez supporter, pas seulement les dix premières.
• Prévoyez une dégradation en douceur en cas d'échec de la TA. Affichez le texte original à côté des traductions. Permettez aux utilisateurs de signaler les mauvaises traductions. Ne cachez pas qu'un contenu est traduit automatiquement : les utilisateurs le découvriront de toute façon, et ils vous feront d'autant moins confiance si vous avez prétendu à une qualité humaine.
• Tenez compte de la « taxe de tokenisation ». Si vous utilisez des modèles de langage (pas seulement de la TA) dans un contexte multilingue, sachez que les langues autres que l'anglais consomment davantage de tokens. Votre fenêtre de contexte de 4K contient nettement moins de texte thaï ou arabe que de texte anglais. Dimensionnez-la en conséquence.
• Investissez dans des données de test multilingues. La partie la plus difficile du support des langues peu dotées n'est pas le modèle : c'est de savoir si votre résultat est correct. Nouez des relations avec des locuteurs natifs capables de valider la qualité. Les métriques automatiques vous induiront en erreur.

La suite

La progression vers une TA omnilingue est vraiment enthousiasmante, malgré toutes les réserves. Il y a cinq ans, construire un modèle de traduction pour une langue disposant de 10 000 phrases parallèles relevait encore de la curiosité de recherche. Aujourd'hui, des techniques comme la rétrotraduction, le transfert multilingue et l'extraction automatique de données parallèles le rendent faisable : pas parfait, mais utilisable.

Les défis restants sont autant sociaux que techniques. Obtenir des données d'entraînement pour les langues en danger suppose des partenariats avec les communautés, et non pas seulement du web scraping. Évaluer la qualité à grande échelle exige de nouvelles métriques et la participation de locuteurs natifs. Faire en sorte que les outils de TA servent réellement les communautés qui parlent ces langues, plutôt que de cocher une case de couverture, demande un engagement continu.

Mais la direction est la bonne. La langue ne devrait pas être un obstacle à l'accès à l'information, et le fait même que nous tentions de construire des systèmes de traduction pour 1 600 langues, plutôt que d'optimiser sans cesse les mêmes 30, marque un changement de priorités significatif. L'ingénierie est difficile. Le seul problème de la tokenisation a mis des années à être correctement identifié et traité. Mais pour les milliards de personnes dont les langues ont été ignorées par l'industrie technologique, ce travail compte plus qu'une nouvelle amélioration de quelques fractions de point sur les scores BLEU anglais–français.