DocumentationTarifsRechercheEnterpriseCarrières
Recrutement
Se connecterS’inscrireRéserver une démo
Tous les articles

La localisation augmentée par récupération réduit de 17 à 45 % les erreurs terminologiques des LLM

En production, la localisation porte sur des paragraphes et des chaînes isolés. Un pipeline CI/CD calcule les écarts avec la version précédente et retraduit uniquement ce qui a changé — une chaîne d’interface, une infobulle, un paragraphe modifié. Chaque requête arrive au LLM de manière isolée — sans la page qui l’entoure, sans le contexte complet du document, sans aucun signal indiquant s’il s’agit d’un texte juridique de l’UE ou d’un contenu marketing. Sans contexte métier injecté au moment de l’inférence, chaque requête isolée ouvre la porte à une nouvelle dérive terminologique.

La localisation augmentée par récupération (RAL) comble cet écart en enrichissant chaque requête de traduction avec des termes de glossaire, des règles de voix de marque et des instructions propres à chaque langue au moment de l’inférence — selon le même schéma retrieve-inject que Retrieval Augmented Generation (RAG). Dans une évaluation contrôlée menée sur cinq fournisseurs de LLM et cinq langues européennes, la RAL a réduit les erreurs terminologiques de 16,6 à 44,6 %.

Principaux enseignements :

  • La RAL a réduit les erreurs terminologiques de 16,6 à 44,6 % chez les cinq fournisseurs de LLM testés
  • Les scores de qualité holistiques (GEMBA-DA) n’ont pas permis de détecter ces écarts. Des deltas de 0,0007 à 0,0178, alors que MQM comptabilisait des milliers d’erreurs en moins
  • Les modèles avec les scores terminologiques initiaux les plus faibles ont le plus progressé : Mistral (-44,6 %) et Deepseek (-42,1 %), contre Anthropic (-24,4 %) et Google (-16,6 %)
  • Le portugais a enregistré la plus forte amélioration par langue ; le français la plus faible — plus la terminologie métier s’éloigne des données d’entraînement, plus la RAL est utile

Le problème de l’isolement#

En localisation de production, l’unité de travail est réduite : un paragraphe, une chaîne, un diff. Rarement plus de 200 mots. Souvent moins de 50. Un fichier JSON de langue contient des clés individuelles, chacune avec une expression ou une phrase. Une page CMS est composée de blocs, chacun traduit indépendamment.

Lorsque le modèle rencontre « provider » dans un paragraphe anglais isolé, il doit trancher : faut-il le traduire en portugais par « fornecedor » (le terme courant) ou par « prestador » (le terme juridique officiel de l’UE) ? Sans contexte métier, il choisit le terme courant. Répétez cela pour chaque terme spécifique à un domaine dans chaque langue, et la dérive terminologique devient la norme.

Nous avons donc voulu mesurer précisément l’ampleur de cet écart — et vérifier si l’injection du contexte de glossaire au moment de l’inférence permettait de le combler.

La première tentative n’a rien révélé#

Notre première expérience s’appuyait sur 37 termes de glossaire par paire de langues et évaluait les traductions au niveau de l’article — chaque article (200 à 700 mots) étant noté comme une unité unique. Résultat : GEMBA-DA — le prompt de qualité holistique lauréat de WMT23 — indiquait 0,952 pour le brut et 0,952 pour le configuré. L’annotation d’erreurs MQM produisait des scores de 0,985 à 0,999 pour chaque traduction. Aucun signal. Aucune différence. À en croire toutes les métriques, la sortie brute et la sortie augmentée par glossaire étaient identiques.

Nous avons failli publier un résultat nul. Puis nous avons cherché à comprendre pourquoi.

Deux problèmes. D’abord, 37 termes de glossaire, c’était trop peu — beaucoup de paragraphes de test ne contenaient aucune occurrence du glossaire, si bien que le moteur configuré n’avait aucun avantage. Ensuite, l’évaluation au niveau de l’article compresse mathématiquement les écarts de qualité jusqu’à les noyer dans le bruit. Les scores MQM sont calculés comme 1 - penalty / wordCount. Une seule erreur terminologique majeure dans un article de 500 mots : 1 - 5/500 = 0.99. La même erreur dans un paragraphe de 50 mots : 1 - 5/50 = 0.90. L’erreur est identique. Pas le score. Au niveau de l’article, toute différence réelle de qualité disparaît au-dessus de 0,98.

Ce n’est pas seulement un problème de mesure propre à notre étude. Cela concerne tous les benchmarks de traduction évalués au niveau de la page ou de l’article. Les erreurs sont bien là. La métrique, elle, ne les voit pas.

Nous avons changé de focale#

Pour la deuxième itération, nous avons apporté quatre changements.

Premièrement, nous avons élargi le glossaire de 37 à 72 termes par paire de langues — extraits d’un ensemble d’entraînement d’articles distinct de l’ensemble de test utilisé pour l’évaluation. Deuxièmement, nous avons évalué au niveau du paragraphe (50 à 200 mots), afin de coller à l’unité réelle de traduction en production. Troisièmement, nous avons ajouté des traductions humaines de référence au prompt d’évaluation MQM afin que les juges puissent comparer directement la terminologie. Quatrièmement, nous avons réduit le nombre de juges de six à quatre. Deepseek et QWEN ne relevaient que 1 à 3 erreurs par paragraphe, contre 5 à 15 pour des juges plus stricts — trop indulgents pour apporter un signal utile.

Le signal est apparu immédiatement.

Conception de l’étude#

Jeu de données. Nous voulions le type de texte le plus dense en terminologie afin de pousser l’injection de glossaire dans ses retranchements. L’AI Act de l’UE (règlement 2024/1689) s’y prêtait parfaitement : un texte réglementaire formel où chaque paragraphe contient des termes dont les traductions sont officiellement définies. EUR-Lex publie des traductions humaines officielles dans les cinq langues cibles, ce qui permet une évaluation paragraphe par paragraphe face à une vérité terrain. 15 articles, de l’anglais vers l’allemand, le français, l’espagnol, le portugais et l’italien.

Moteurs. Chaque fournisseur a été testé avec deux configurations de moteur de localisation : un moteur brut (le LLM seul — sans glossaire, sans récupération, traduisant uniquement à partir de ses connaissances d’entraînement) et un moteur augmenté par RAL (le même modèle, avec un glossaire métier, un profil de voix de marque et des instructions propres à la langue appliqués au moment de l’inférence). Dix moteurs au total, avec la même configuration partagée entre tous les moteurs augmentés par RAL.

FournisseurModèleMoteur brutMoteur RAL
Anthropicclaude-opus-4.6modèle seulglossaire + voix de marque + instructions
OpenAIgpt-5.4modèle seulglossaire + voix de marque + instructions
Googlegemini-3.1-pro-previewmodèle seulglossaire + voix de marque + instructions
Mistralmistral-large-2512modèle seulglossaire + voix de marque + instructions
Deepseekdeepseek-v3.2modèle seulglossaire + voix de marque + instructions

QWEN figurait au départ dans l’étude, mais a été retiré de l’ensemble final — les traductions étaient lentes et peu fiables, le même problème qui l’a disqualifié comme juge.

Configuration RAL. Chaque moteur augmenté contenait 72 termes de glossaire par paire de langues (70 traductions personnalisées plus 2 éléments non traduisibles), un profil de voix de marque (registre réglementaire formel de l’UE) et 13 instructions propres à chaque langue. Les termes du glossaire ont été extraits d’un ensemble d’entraînement d’articles distinct de l’ensemble de test utilisé pour l’évaluation. Exemples d’entrées : EN « provider » → PT « prestador » (et non « fornecedor ») ; EN « high-risk AI system » → PT « sistema de IA de risco elevado » (et non « sistema de IA de alto risco »). Au moment de l’inférence, seuls les termes correspondant au paragraphe en cours sont récupérés et transmis au modèle — la taille du glossaire n’encombre pas la fenêtre de contexte. Les moteurs ont été configurés sur Lingo.dev comme des moteurs de localisation avec état — un contexte persistant appliqué à chaque requête.

Évaluation. Chaque paragraphe traduit a été évalué par quatre juges LLM, puis les scores ont été moyennés afin d’atténuer les biais individuels. Chaque juge évalue les sorties de tous les fournisseurs, pas seulement les siennes :

JugeModèle
Anthropicclaude-sonnet-4.6
OpenAIgpt-4.1
Googlegemini-2.5-flash
Mistralmistral-large-2512

GEMBA-MQM. MQM (Multidimensional Quality Metrics) est un cadre standard d’évaluation de la qualité des traductions — normalement appliqué par des annotateurs humains formés. GEMBA-MQM, la méthode d’évaluation lauréate de WMT23, remplace les annotateurs humains par un LLM tout en suivant le même protocole MQM : le juge lit la traduction et signale chaque erreur, en lui attribuant une catégorie et un niveau de gravité.

Catégories d’erreurs : exactitude, fluidité, style, terminologie. Les pondérations de gravité suivent la norme officielle MQM : mineure = 1, majeure = 5, critique = 25.

Score MQM par paragraphe : max(0, 1 - weighted penalty / word count). Un paragraphe de 50 mots avec une erreur terminologique majeure obtient 1 - 5/50 = 0.90. Un paragraphe parfait obtient 1,0. Les nombres d’erreurs dans les tableaux de résultats sont additionnés sur l’ensemble des quatre juges et de tous les paragraphes pour un fournisseur et une langue donnés.

Une différence par rapport au prompt GEMBA-MQM standard : nous avons ajouté la traduction humaine de référence. GEMBA-MQM est conçu sans référence — le juge évalue la qualité sans voir la « bonne » réponse. Nous avons ajouté ces références parce qu’EUR-Lex publie les traductions officielles de l’AI Act de l’UE dans les cinq langues cibles, donnant ainsi aux juges une vérité terrain à laquelle comparer la terminologie.

GEMBA-DA. Un score de qualité holistique de 0 à 1 utilisant le prompt GEMBA-DA (également lauréat de WMT23). Contrairement à MQM, il produit un score unique sans annotation d’erreurs. Nous l’incluons comme garde-fou — comme le montrent les résultats, il ne peut pas détecter les différences au niveau terminologique.

Deepseek a été exclu du panel de juges en raison d’une notation trop indulgente (1 à 3 erreurs par paragraphe contre 5 à 15 pour des juges plus stricts). La moyenne sur quatre juges atténue les biais individuels, et l’amélioration relative entre brut et RAL reste cohérente chez chacun d’eux.

Taille de l’échantillon. 535 observations appariées au niveau du paragraphe par fournisseur (107 paragraphes × 5 langues). Plus de 42 000 jugements de qualité individuels au total (535 paragraphes × 5 fournisseurs × 2 configurations × 8 scores chacun).

Les erreurs terminologiques chutent de 16,6 à 44,6 %#

FournisseurErreurs brutesErreurs RALRéduction
Mistral3,3361,847-44.6%
Deepseek3,6722,127-42.1%
OpenAI2,2761,508-33.7%
Anthropic1,5591,179-24.4%
Google1,9011,586-16.6%

Nombre d’erreurs terminologiques selon MQM sur 15 articles, 5 langues et 4 juges.

L’amélioration a évolué à l’inverse du score de départ. Mistral et Deepseek — avec les plus gros volumes d’erreurs brutes — ont enregistré des réductions de 42,1 à 44,6 %. Anthropic et Google — dont l’entraînement intégrait déjà davantage de terminologie juridique de l’UE — ont affiché des gains plus modestes. Le schéma est clair : la RAL compense ce que le modèle ne sait pas déjà.

Dans le même temps, GEMBA-DA — le score holistique — n’a relevé qu’un delta de 0,0007 à 0,0178 entre le brut et la RAL chez tous les fournisseurs. Les mêmes traductions pour lesquelles MQM a relevé 16,6 à 44,6 % d’erreurs terminologiques en plus ont reçu des scores holistiques presque identiques. C’est là tout l’angle mort de la mesure : une évaluation holistique, quelle que soit la granularité, ne peut pas détecter les écarts de qualité au niveau terminologique.

Le total des erreurs (toutes catégories MQM confondues) a montré une baisse plus faible, mais constante, chez les cinq fournisseurs :

FournisseurTotal brutTotal RALÉvolution
Deepseek10,4239,014-13.5%
Mistral8,8467,812-11.7%
OpenAI7,5637,155-5.4%
Google7,7937,545-3.2%
Anthropic6,2326,039-3.1%

L’écart entre la réduction des erreurs terminologiques (16.6-44.6%) et la réduction totale (3.1-13.5%) s’explique en grande partie par le style. Les juges LLM ont tendance à signaler un texte comme « maladroit » dès qu’il s’écarte de leurs préférences issues des données d’entraînement, même lorsque cet écart le rapproche de la référence officielle — une limite connue sous le nom de biais d’auto-préférence. La terminologie et l’exactitude sont ancrées dans la référence ; pour le style, il n’existe pas d’autre point d’ancrage que le propre ressenti du juge sur ce qui sonne naturel.

Significativité statistique#

La réduction des erreurs terminologiques a été testée pour chaque fournisseur à l’aide d’un test des rangs signés de Wilcoxon apparié (unilatéral, avec correction de Holm-Bonferroni appliquée aux cinq fournisseurs). Les nombres d’erreurs terminologiques par paragraphe ont été additionnés sur quatre juges, puis appariés paragraphe par paragraphe (même source, mêmes juges, brut vs RAL).

FournisseurParagraphes appariésRéduction moyenne/paragrapheIC à 95 %d de Cohenp (ajusté)
Mistral5322.80[2.42, 3.21]0.60< 0.001
Deepseek5262.94[2.45, 3.44]0.50< 0.001
OpenAI5351.44[1.12, 1.77]0.37< 0.001
Anthropic5330.71[0.50, 0.93]0.28< 0.001
Google5330.59[0.34, 0.85]0.20< 0.001

Les cinq fournisseurs affichent des réductions statistiquement significatives des erreurs terminologiques (p < 0.001 après correction de Holm-Bonferroni pour comparaisons multiples), avec des intervalles de confiance à 95 % qui excluent zéro. Les tailles d’effet vont de modérées à fortes (Mistral, d = 0.60) à faibles (Google, d = 0.20) — ce qui confirme que les modèles dont la couverture terminologique de départ est la plus faible tirent davantage parti du RAL.

Là où le RAL a le plus d’impact#

Le portugais a affiché les plus fortes améliorations terminologiques chez tous les fournisseurs. La terminologie juridique portugaise diverge fortement du portugais courant, et les termes juridiques de l’UE en portugais sont sous-représentés dans les données d’entraînement des LLM. Le français a affiché les gains les plus faibles — les termes juridiques français sont bien représentés dans les corpus d’entraînement.

Étude de cas : OpenAI en portugais

La sortie brute d’OpenAI a traduit l’AI Act de l’UE en portugais en utilisant « alto risco » 71 fois (le « high risk » courant), « fornecedores » 39 fois et « fornecedor » 36 fois. Les traductions officielles d’EUR-Lex utilisent « risco elevado » et « prestadores ». Avec le RAL, les erreurs terminologiques d’OpenAI en portugais sont passées de 648 à 266 — soit une réduction de 59 %.

Le constat se généralise : les langues dont la terminologie métier s’éloigne davantage de la distribution d’entraînement du LLM bénéficient plus du RAL.

Le mécanisme#

Le mécanisme en jeu est simple. Au moment de l’inférence, le moteur décompose le texte d’entrée en groupes de n-grammes et les vectorise. Il lance ensuite une recherche par similarité cosinus dans l’index vectoriel du glossaire pour trouver les termes correspondants. Les correspondances trouvées sont injectées dans la fenêtre de contexte du LLM aux côtés du texte source. Le modèle ne devine pas « fornecedor » ou « prestador » — il voit la bonne correspondance dans le contexte et l’utilise. Sur le plan structurel, c’est identique au RAG : vectoriser, récupérer, injecter, générer.

Classement des fournisseurs par qualité brute#

Sans RAL — sortie brute du modèle uniquement :

RangFournisseurMQM moy.
1Anthropic0.955
2OpenAI0.942
3Google0.938
4Mistral0.915
5Deepseek0.883

L’écart de 0.072 entre Anthropic et Deepseek représente environ 3 à 4 erreurs supplémentaires par paragraphe de 100 mots. Le RAL a resserré cet écart : Mistral avec RAL (moy. 0.940) s’est rapproché de la qualité brute de Google (0.938). Un modèle dont le coût par token ne représente qu’une fraction de celui des autres, enrichi d’un glossaire de 72 termes, a égalé la précision terminologique d’un modèle plus coûteux qui n’en disposait pas.

Ce que cela signifie en production#

L’écart de qualité entre la sortie brute d’un LLM et une localisation prête pour la production est un problème de contexte — et il s’amplifie avec le temps. Après dix mises en production sans RAL, trois traductions erronées différentes de « provider » coexistent dans le produit.

Le RAL casse cette dynamique. Le glossaire est persistant — il s’applique à chaque requête, indépendamment de ce qui a changé. Le glossaire de 72 termes qui a réduit les erreurs de 16.6-44.6% dans notre étude n’est pas une amélioration ponctuelle. C’est une couche de cohérence qui s’applique à chaque demande de traduction, pendant toute la durée de vie du produit.

Deux enseignements pour les équipes qui déploient des traductions par LLM : d’abord, les scores de qualité holistiques ne détectent pas les problèmes de terminologie. GEMBA-DA — la méthode gagnante du WMT23 — a attribué aux traductions brutes et aux traductions enrichies par RAL des scores séparés par seulement 0.0007-0.0178. MQM, lui, a relevé 16.6-44.6% d’erreurs terminologiques en moins. Si vous évaluez au niveau de la page avec un score unique, vous passez à côté d’une partie essentielle du tableau.

Ensuite, la solution est plus simple que le problème ne le laisse penser. Un glossaire métier injecté au moment de l’inférence a réduit les erreurs terminologiques chez tous les fournisseurs que nous avons testés. Le modèle qui traduit le mieux (Anthropic, MQM 0.955) s’est tout de même amélioré. Le modèle avec le taux d’erreur initial le plus élevé (Deepseek, MQM 0.883) est aussi celui qui a le plus progressé.

Le RAL est à la localisation ce que le RAG est à la génération : la couche d’ingénierie entre le modèle et la production.

Prochaines étapes#

Découvrez Lingo.dev v1.0
La plateforme d’ingénierie de la localisation conçue autour du RAL
Moteurs de localisation
Configurez les modèles, les glossaires et la voix de marque pour chaque langue

Plateforme

API de localisationAPI des tâches asynchronesMoteurs de localisationDétection de la langueLingo.dev Platform MCPTarifs

Outils développeur

Lingo React MCPLingo CLILingo GitHub ActionLingo React Compiler
Alpha

Ressources

DocumentationLabsGuidesChangelogLanguesModèles LLM

Entreprise

BlogRechercheRéserver une démoClientsCarrières
Recrutement
humans.txt

Communauté

GitHubDiscordTwitterLinkedIn
Basés à San Francisco + partout dans le monde
SOC 2 Type II·CCPA·GDPR
Soutenu par Y Combinator
Combinator
& Initialized Capital
Initialized Capital
& nos clients
Confidentialité·Conditions·Cookies·security.txt

© 2026 Lingo.dev (Replexica, Inc).

Tous les systèmes fonctionnent normalement
Se connecterS’inscrireRéserver une démo
Veronica PrilutskayaVeronica Prilutskaya, Directeur produit et cofondateur·Publié il y a 4 mois·13 min de lecture