Aller au contenu

Évaluer séparément la langue et l’exactitude métier

Une phrase fluide peut désigner le mauvais environnement. Évaluez séparément lisibilité, sens et action déduite dans une IA multilingue.

Philipp Reuter2 min de lecture
Deux pages avec des cadres d’image et des lignes de texte, dont une sur un porte-bloc bleu.

Une traduction facile à lire peut contenir une consigne de travail erronée. L’automatisation multilingue demande donc d’évaluer séparément qualité linguistique et exactitude métier. Un ton poli ou une phrase compréhensible ne suffit pas à autoriser l’action suivante.

Une phrase fluide peut désigner la mauvaise cible

Dans cet exemple fictif, une consigne allemande est traduite pour une équipe d’assistance travaillant en anglais. Le texte source est : Nur die Testumgebung neu starten. Die Produktivumgebung unverändert lassen. Un exemple anglais délibérément incorrect est : Restart the production environment. Il s’agit d’un cas d’erreur construit.

La phrase anglaise est compréhensible. Sur le fond, elle remplace la cible de test par l’environnement de production et omet la restriction explicite. Une vérification de la seule fluidité n’examinerait pas suffisamment le choix de l’environnement cible.

L’équipe consigne donc deux jugements : le texte est-il utilisable dans la langue cible et conserve-t-il la consigne voulue, y compris l’environnement et la restriction ? Avant exécution, il faut aussi vérifier l’action que l’application en déduit et si elle est autorisée.

Un identifiant de langue a une autre fonction

Microsoft décrit la détection linguistique comme l’identification de la langue prédominante d’un document avec un score de confiance associé. Ce score concerne la détection de la langue. Il ne prouve ni l’exactitude de la traduction ni la pertinence d’une demande de redémarrage.

Une traduction réussie peut également être mal associée ensuite. Si le texte traduit indique toujours l’environnement de test mais que l’application choisit une autre cible, l’écart se situe dans une étape de traitement ultérieure. La vérification doit donc permettre de voir le texte et l’action déduite.

Examiner les cas par langue et type d’erreur

Microsoft recommande de comparer les évaluations d’IA sur les mêmes cas et d’examiner les erreurs individuelles. Pour ce parcours, les cas doivent aussi inclure négations, restrictions et environnements nommés différemment. La consigne attendue reste consignée de manière vérifiable.

Distinguez les résultats par langue et type de cas. Une bonne évaluation globale ne montre sinon pas dans quelle langue une restriction importante disparaît. Associez à l’évaluation linguistique et métier des personnes capables de juger la langue concernée et le processus de travail.

Une validation demande des résultats adaptés à l’usage prévu. Les textes bien rédigés en font partie ; le sens conservé et l’action suivante vérifiée déterminent si l’automatisation remplit la tâche.

Sources

Écrit par

  • Philipp ReuterRédacteur qualité logiciellePhilipp Reuter écrit chez ASES sur les tests logiciels et la préparation des nouvelles versions. Ses articles portent sur l’analyse des erreurs, les tests de recette et la vérification des modifications apportées aux applications existantes.

Suivre ASES

À lire aussi

Tous les articles

IA & automatisation avec ASES

Assistants IA et processus automatisés