Si un pipeline de localisation utilise la génération augmentée par récupération pour injecter des termes de glossaire dans la fenêtre de contexte du modèle, alors il a un problème de rappel de récupération qui n'a jamais été mesuré.
Le schéma est toujours le même : on embed le texte d'entrée, on lance une recherche par similarité cosinus dans une base terminologique, puis on injecte les top-k résultats dans le prompt. La sortie est grammaticalement correcte. La terminologie est incorrecte. L'erreur reste invisible, à moins qu'une personne parle les deux langues et connaisse le glossaire.
Nous avons d'abord construit cette version naïve. Puis nous avons mesuré le rappel de récupération sur des glossaires de production — et nous avons constaté que le système passait à côté de la majorité des termes applicables sur de vrais payloads.
| Technique | Localisation augmentée par récupération (RAL) — enrichissement du contexte au moment de l'inférence |
| Correctif principal | Décomposition en n-grammes avant l'embedding, plutôt qu'un embedding au niveau de la phrase |
| Modes de récupération | 3 (ignorer / précharger / recherche vectorielle), sélectionnés requête par requête selon la cardinalité du glossaire |
| Calibrage du seuil | Continu, chaque semaine, à partir de scores de qualité par paire de langues |
| Réduction des erreurs terminologiques | 17 à 45 % sur cinq fournisseurs de LLM (étude contrôlée, plus de 42 000 évaluations de qualité) |
| Évaluation | Évaluation indépendante intermodèle, asynchrone, par requête |
Pourquoi les embeddings de phrase passent-ils à côté des termes du glossaire ?#
Un terme de glossaire fait 1 à 3 mots. "Localization engine." "Access token." "Deployment pipeline."
Le texte d'entrée est un objet JSON dont les valeurs vont de deux mots (un libellé de bouton) à deux cents mots (une description produit). Quand on embed la chaîne complète "Configure the localization engine for production deployment", le vecteur obtenu capture le sens sémantique global de la phrase — quelque chose autour de la configuration et des systèmes de production. Le groupe de mots pertinent pour le glossaire, "localization engine", se dissout dans cette représentation au niveau de la phrase.
La similarité cosinus entre ce vecteur de phrase et l'entrée de glossaire "localization engine" tombe dans une plage de 0,6 à 0,7. En dessous du seuil de récupération. Le terme est bien présent dans l'entrée. Le système de récupération le manque.
Le problème, c'est la granularité : des représentations au niveau de la phrase interrogent des cibles au niveau du groupe de mots. Le modèle d'embedding représente fidèlement le sens de la phrase dans son ensemble. La terminologie qui la compose n'occupe aucune zone indépendante dans l'espace vectoriel.
Nous l'avons appris à nos dépens. Sur des payloads de production — des objets JSON imbriqués avec 20 à 50 clés et des valeurs de longueur variable — la récupération au niveau de la phrase passait à côté de la majorité des termes de glossaire applicables. La requête de localisation se terminait sans problème. La sortie était fluide. Mais "localization engine" devenait "translation tool" — grammaticalement correct, sémantiquement proche, mais terminologiquement faux. Et le pipeline signalait un succès.
Comment la décomposition en n-grammes corrige-t-elle la récupération des termes de glossaire ?#
Le correctif a finalement consisté à décomposer l'entrée en unités au niveau du groupe de mots avant l'embedding. Chaque valeur de chaîne devient un ensemble de fenêtres de n-grammes qui se chevauchent :
Input: "Configure the localization engine for production"
1-grams: [configure, the, localization, engine, for, production]
2-grams: [configure the, the localization, localization engine,
engine for, for production]
3-grams: [configure the localization, the localization engine,
localization engine for, engine for production]Chaque n-gramme devient une requête de récupération indépendante. "Localization engine" interroge le glossaire comme groupe de mots autonome — et trouve sa correspondance avec une forte similarité.
Le pipeline de décomposition :
- Extraire récursivement toutes les valeurs de type chaîne des structures JSON imbriquées
- Découper en phrases, supprimer le HTML et les annotations de balisage
- Normaliser les espaces, retirer les guillemets englobants, déséchapper le formatage
- Générer des groupes de mots chevauchants de 1, 2 et 3 grammes à partir de chaque phrase
Un paragraphe de 50 mots produit environ 150 n-grammes. Un payload API typique de 20 clés produit entre 1 000 et 3 000 groupes de mots interrogeables. Chaque groupe de mots est embeddé indépendamment, et chaque embedding lance une requête de plus proche voisin sur l'index vectoriel du glossaire.
Nous avons mesuré l'écart sur les mêmes payloads de production qui avaient révélé le problème initial. Les termes du glossaire correspondent désormais quel que soit le contexte de phrase qui les entoure — un terme de 2 mots enfoui dans une description produit de 200 mots est récupéré avec le même rappel qu'un libellé autonome.
Comment fonctionne la récupération adaptative selon la taille du glossaire ?#
La décomposition en n-grammes et l'embedding par lots sont la bonne approche pour les grands glossaires. Pour les petits, cette approche s'est révélée inutilement coûteuse en calcul.
Un moteur de localisation configuré avec 8 termes de glossaire se traite plus rapidement avec une injection directe — une seule requête en base de données, déterministe, en dessous de la milliseconde. Un moteur de localisation avec 2 000 termes nécessite une recherche vectorielle — les limites de la fenêtre de contexte et la dilution de la pertinence rendent une injection complète impossible.
Trois modes de récupération s'appliquent requête par requête, sélectionnés selon la cardinalité du glossaire pour la paire de langues :
| Mode | Condition | Comportement |
|---|---|---|
| Ignorer | Zéro élément correspondant | Aucun embedding, aucune recherche, aucune injection |
| Précharger | Sous le seuil de cardinalité | Une seule requête en base de données charge tous les éléments correspondants ; injection directe |
| Recherche | Au-dessus du seuil de cardinalité | Décomposition complète en n-grammes → embedding par lots → recherche vectorielle des plus proches voisins |
Le seuil de cardinalité qui sépare le préchargement de la recherche est défini à partir du profilage de latence sur le trafic de production, puis ajusté à mesure que les performances du modèle d'embedding, la distribution des tailles de glossaire et les caractéristiques de l'infrastructure évoluent. La valeur initiale que nous avons déployée a tenu environ trois semaines avant que la télémétrie n'indique qu'il fallait la revoir. Depuis, elle a été ajustée plusieurs fois — nous avons découvert que le seuil optimal dérive à mesure que les moteurs accumulent des termes de glossaire et que les caractéristiques des modèles d'embedding évoluent au fil des mises à jour des fournisseurs.
La latence de récupération évolue avec la complexité du glossaire, pas avec la taille du payload. Un moteur de localisation avec 10 termes se traite en quelques millisecondes, quelle que soit la longueur de l'entrée. Un moteur de localisation avec 500 termes utilise le pipeline de décomposition complet, tout en restant dans le budget de latence d'une étape durable de workflow en arrière-plan.
Comment le seuil de similarité est-il calibré pour la récupération des termes de glossaire ?#
Chaque embedding de n-gramme interroge l'index vectoriel à la recherche des plus proches voisins au-dessus d'un seuil de similarité. Les correspondances sous ce seuil sont écartées comme du bruit.
Le seuil détermine à la fois la précision et le rappel de la récupération :
- Trop permissif : des termes sans rapport s'infiltrent dans le prompt. Le modèle voit un contexte de glossaire qui ne s'applique pas à l'entrée et le suit parfois — produisant une sortie qui reprend une terminologie issue d'un domaine sans rapport.
- Trop strict : des variantes de formulation légitimes et des formes morphologiques sont exclues. "Deploying" ne correspond plus à l'entrée de glossaire "deploy." Le rappel baisse.
Nous avons constaté que le bon seuil varie selon la paire de langues. La récupération anglais→allemand présente des distributions de similarité différentes de l'anglais→japonais, où la distance morphologique entre les n-grammes source et les entrées du glossaire diffère structurellement. Un seuil global unique produisait un rappel incohérent selon les paires de langues que nous avons mesurées.
Le seuil est désormais calibré en continu à partir de scores de qualité par paire de langues issus d'un pipeline d'évaluation indépendant. Lorsque le système d'évaluation détecte une hausse de la non-conformité au glossaire (des termes présents dans l'entrée mais absents de la sortie), cela signifie que le rappel de récupération s'est dégradé, et le seuil est assoupli. Lorsqu'il détecte que le modèle applique une terminologie non pertinente, les injections de faux positifs ont augmenté, et le seuil est resserré.
Ce calibrage s'exécute chaque semaine. C'est indispensable — le comportement des modèles d'embedding évolue entre les mises à jour des fournisseurs, la distribution des glossaires change à mesure que les équipes ajoutent des termes, et les caractéristiques du texte d'entrée évoluent à mesure que les produits grandissent.
Comment les termes de glossaire récupérés sont-ils injectés dans le modèle de localisation ?#
Les éléments de glossaire récupérés se répartissent en deux classes de contraintes, avec des comportements d'application différents dans le prompt système du modèle :
Termes non traduisibles — des chaînes en langue source qui doivent apparaître telles quelles dans la sortie cible. Noms de marque, identifiants techniques, noms de produit. Le modèle les préserve à l'identique.
Traductions personnalisées — des correspondances source→cible qui priment sur le propre jugement du modèle. "Localization engine" doit devenir "moteur de localisation." Le modèle les traite comme des contraintes lexicales non négociables.
Les deux classes sont injectées dans le prompt système sous forme de règles ayant une priorité explicite sur le comportement par défaut du modèle. La hiérarchie du prompt impose le respect du glossaire avant les préférences linguistiques du modèle.
La distinction compte au moment de l'évaluation : le modèle d'évaluation indépendant vérifie si les éléments non traduisibles ont bien été préservés à l'identique et si les traductions personnalisées ont été appliquées exactement. Deux critères de vérification pour deux types de contraintes. Nous avons compris très tôt qu'en les fusionnant dans une seule catégorie "glossaire", l'évaluation devenait peu fiable — un terme préservé tel quel alors qu'il aurait dû être traduit (ou l'inverse) pouvait être noté comme correct dans une vérification unifiée.
Comment valider la qualité de la localisation dans des langues que vous ne parlez pas ?#
L'ensemble du pipeline de récupération et de localisation peut s'exécuter sans erreur et produire une sortie terminologiquement incorrecte. Un terme de glossaire manqué ne génère aucun signal d'erreur. Une traduction personnalisée mal appliquée renvoie un 200. Le pipeline réussit. La sortie est incorrecte.
C'est le trou noir de l'observabilité en localisation que la plupart des équipes ne comblent jamais.
La récupération est couplée à une évaluation indépendante et asynchrone. Une fois la requête de localisation terminée, des modèles d'évaluation distincts évaluent la sortie par rapport à la configuration du moteur de localisation :
- Respect du glossaire — les termes non traduisibles ont-ils été préservés ? Les traductions personnalisées ont-elles été appliquées exactement ?
- Respect des instructions — les règles spécifiques à la langue ont-elles été suivies ?
- Critères d'évaluation personnalisés — des dimensions de qualité par moteur définies par l'équipe de localisation
Les modèles de scoring s’exécutent sur une infrastructure distincte de celle du modèle de localisation. Ils fonctionnent de façon asynchrone dans des workflows en arrière-plan, déclenchés après chaque requête passant par un moteur de localisation avec le scoring activé. Un modèle localise ; un autre évalue. Cette évaluation croisée entre modèles élimine le biais d’auto-évaluation.
Les résultats du scoring servent ensuite à recalibrer la récupération :
- Le scoring détecte une hausse du non-respect du glossaire pour une paire de langues
- L’analyse montre que le rappel de la récupération a baissé – le seuil a dérivé par rapport à la distribution actuelle du glossaire
- Le seuil est ajusté ; le rappel remonte ; les scores de conformité se stabilisent
C’est cette boucle qui rend le système auto-correctif. Le scoring apporte le niveau d’observabilité dont la récupération seule manque. Sans cela, les équipes livrent du contenu localisé dans des langues qu’elles ne maîtrisent pas, sans aucun signal indiquant si le glossaire qu’elles ont construit est réellement appliqué.
Pourquoi le rappel de la récupération a-t-il un effet cumulatif dans le temps ?#
Chaque requête de localisation qui applique correctement les termes du glossaire renforce la cohérence terminologique dans l’ensemble du produit. Chaque requête qui laisse passer un terme introduit une dérive – une interface dit "moteur de localisation", une autre dit "outil de localisation", une troisième dit "module de localisation". À l’échelle de 30 langues et de livraisons hebdomadaires, ces incohérences s’accumulent.
La différence entre un rappel de récupération élevé et faible ne se résume pas à un écart de qualité par requête. C’est un mécanisme cumulatif de cohérence. Un rappel élevé signifie que le glossaire s’applique uniformément sur chaque interface, chaque langue, chaque livraison. Un rappel faible signifie que le glossaire ne se déclenche qu’occasionnellement – l’équivalent, sur le plan structurel, de ne pas avoir de glossaire, simplement avec une dégradation plus lente.
Ce que cela implique pour l’ingénierie de la localisation#
Le problème de récupération décrit ici n’est propre à aucune implémentation en particulier. Il est structurel dans tout système qui tente une localisation tenant compte du glossaire via une recherche fondée sur les embeddings. Le décalage de granularité entre des représentations d’entrée au niveau de la phrase et des cibles de glossaire au niveau du syntagme existe quel que soit le modèle d’embedding, la base de données vectorielle ou le LLM chargé de générer la sortie.
Les équipes qui développent l’automatisation de la localisation sont face à un choix : accepter la récupération au niveau de la phrase avec son déficit de rappel invisible, ou mettre en place l’infrastructure de décomposition et de calibrage qui permet de le résorber. La seconde voie exige trois systèmes – décomposition en n-grammes, récupération adaptative et boucle de scoring réinjectée dans la gestion des seuils. Chacun suit sa propre cadence opérationnelle : la logique de décomposition évolue au rythme des changements de formats d’entrée, les seuils de récupération bougent à mesure que les glossaires s’étoffent, et les critères de scoring s’affinent à mesure que les équipes de localisation identifient les dimensions qui comptent pour leur contenu.
Obtenir une qualité de production avec la localisation augmentée par récupération relève d’une pratique d’ingénierie continue – un système conçu, instrumenté, observé et ajusté en permanence. La discipline d’ingénierie de la localisation qui émerge autour de ce travail reflète la réalité opérationnelle : l’infrastructure de localisation exige la même attention continue que les services backend, les pipelines CI/CD et les piles d’observabilité.
Prochaines étapes#
FAQ#
Qu’est-ce que la localisation augmentée par récupération (RAL) ? La localisation augmentée par récupération enrichit chaque requête de localisation avec des termes du glossaire, des règles de voix de marque et des instructions propres à la langue au moment de l’inférence – le même schéma récupérer-injecter que celui du RAG, appliqué à la localisation. Dans une étude contrôlée menée auprès de cinq fournisseurs de LLM et sur cinq langues européennes, le RAL a réduit les erreurs terminologiques de 17 à 45 % par rapport aux mêmes modèles sans enrichissement contextuel.
Pourquoi l’embedding au niveau de la phrase passe-t-il à côté des termes du glossaire ? Les termes du glossaire comptent généralement 1 à 3 mots. Lorsqu’ils sont intégrés à une phrase complète, ils se fondent dans le vecteur sémantique de la phrase. L’embedding capture le sens global de la phrase – "moteur de localisation" dans "Configure the localization engine for production" n’est pas représenté comme un élément distinct. La similarité cosinus entre le vecteur de la phrase et l’entrée du glossaire tombe alors sous le seuil de récupération.
Comment la décomposition en n-grammes améliore-t-elle le rappel de la récupération ? Au lieu d’intégrer des chaînes d’entrée complètes, le système décompose le texte en syntagmes de 1, 2 et 3 grammes qui se chevauchent avant l’embedding. Chaque syntagme devient une requête de récupération indépendante. Un terme de glossaire de 2 mots enfoui dans un paragraphe de 200 mots bénéficie alors du même rappel qu’un libellé autonome – parce qu’il est interrogé indépendamment de son contexte environnant.
Combien de modes de récupération le système utilise-t-il ? Trois. Skip (zéro élément de glossaire – aucune récupération nécessaire), preload (en dessous d’un seuil de cardinalité – chargement direct de tous les éléments) et recherche vectorielle (au-dessus du seuil – décomposition complète en n-grammes et embedding). Le mode est sélectionné pour chaque requête en fonction de la cardinalité du glossaire pour la paire de langues concernée.
Comment le seuil de similarité est-il maintenu ? Le seuil est calibré chaque semaine à partir des scores de qualité par paire de langues issus d’un pipeline de scoring indépendant. Lorsque le non-respect du glossaire tend à augmenter, le seuil est assoupli pour améliorer le rappel. Lorsque des termes non pertinents s’infiltrent dans les prompts, le seuil est resserré. Différentes paires de langues nécessitent des seuils différents en raison de distances morphologiques variables.
Comment fonctionne le scoring inter-modèles pour la qualité de la localisation ? Après chaque requête de localisation, un modèle distinct – exécuté sur une infrastructure différente – évalue si les termes du glossaire ont été correctement appliqués, si les instructions propres à la langue ont été respectées et si des critères de qualité personnalisés ont été remplis. Un modèle localise ; un autre évalue. Cela élimine le biais d’auto-évaluation et apporte le niveau d’observabilité dont la récupération seule manque.
Que se passe-t-il lorsque le rappel de récupération du glossaire est faible ? Un faible rappel de récupération signifie que le glossaire se déclenche de manière incohérente – une interface obtient le bon terme, une autre non. À l’échelle de plus de 30 langues et de livraisons hebdomadaires, ces incohérences se transforment en dérive terminologique. Le glossaire existe, mais n’impose pas réellement son application. Sur plusieurs mois, cela revient structurellement à ne pas avoir de glossaire.
Qu’est-ce que le déficit d’observabilité en localisation ? Un pipeline de localisation peut s’exécuter sans erreur tout en produisant une sortie terminologiquement incorrecte. Les termes du glossaire manqués ne génèrent aucun signal d’erreur – l’API renvoie 200, la traduction est grammaticalement valide. Le déficit d’observabilité correspond à l’écart entre "le pipeline a réussi" et "la terminologie est correcte". Un scoring indépendant comble cet écart en mesurant le respect du glossaire à chaque requête.
