Bring Your Own Engine

Le contenu est traduit de l’anglais par Phrase Language AI.

La fonctionnalité Bring Your Own Engine (BYO Engine) permet l'intégration de moteurs de traduction automatique (TA) externes dans Phrase afin de les utiliser dans des flux de travail de traduction comme n'importe quel autre fournisseur de TA.

Le BYO Engine convient aux entités suivantes :

Les entreprises disposant de modèles de TA spécifiques à un domaine.
Les prestataires de services linguistiques (LSP) disposant de moteurs personnalisés pour leurs clients ou de piles technologiques d’IA de prédilection.
Les organisations ayant des politiques internes qui exigent l'utilisation de moteurs spécifiques (par exemple, Gemini, LLM internes, etc.).

Des moteurs entraînés sur mesure peuvent être utilisés ou les traductions peuvent être acheminées vers des LLM ou des fournisseurs de TA internes afin de conserver un contrôle total sur la qualité, la confidentialité et les coûts, tout en continuant à bénéficier des mémoires de traduction (TM), des glossaires, du QPS et de l'éditeur TAO de Phrase.

Où un BYO Engine peut être utilisé

Une fois intégré, un BYO Engine est disponible pour la pré-traduction. Configurez-le dans un profil Phrase Language AI et utilisez ce profil pour la pré-traduction depuis les projets Phrase TMS, Phrase Portal, les projets Phrase Strings, Phrase Studio et Phrase Language AI via l’API.

Configurer un BYO Engine

Création de l'adaptateur

L'organisation doit créer et tester un adaptateur d'API léger. Cet adaptateur permet la communication entre Phrase et le moteur.

L'adaptateur doit prendre en charge :
- Les demandes de traduction
- La prise en charge des paires de langues
- La vérification de l'état du moteur (Phrase envoie une demande d'état)
L'infrastructure sous-jacente (moteur de TA ou LLM) doit être hébergée et maintenue par l'organisation.
Phrase nécessite des autorisations pour se connecter à cette infrastructure.
L'adaptateur doit renvoyer des traductions avec le même nombre de segments et le même ordre.

Intégration du moteur dans un profil MT

Une fois l’adaptateur d’API implémenté et déployé, le BYO Engine devient disponible dans Phrase Language AI : il peut être sélectionné dans les profils MT et affecté à des projets.

Pour connecter un BYO Engine à un profil MT :

Depuis la page du profil MT de Phrase Language AI, cliquez sur Connecter des moteurs MT.

La page Connecter un moteur MT s'affiche.
Sélectionnez Bring Your Own (BYO) Engine.

La page de configuration du BYO Engine s'ouvre.
Saisissez l'URL de base du moteur.
Fournissez les identifiants en fonction de la méthode d'authentification (en-tête HTTP ou identifiants client (OAuth 2.0)).
Indiquez si vous souhaitez utiliser le cache de traduction. Activé par défaut.

Réduit le trafic et accélère les réponses aux demandes de traduction en réutilisant les segments traduits au cours des 30 derniers jours. Il s'agit uniquement d'une optimisation des performances des appels ; cela ne réduit pas le coût de traduction. Laissez cette option activée par défaut ; ne la désactivez que lorsque l’adaptateur du moteur sous-jacent est en cours de développement.
Si nécessaire, fournissez toute information supplémentaire sur le moteur dans la rubrique Étiquettes personnalisées.
Cliquez sur Valider la connexion pour vérifier si l'intégration du moteur fonctionne.
Cliquez sur Ajouter.

Le moteur est désormais disponible pour être activé dans le profil.

Astuce

Lorsque vous utilisez un BYO Engine, n’activez aucun autre moteur dans le profil MT. Cela garantit que le BYO Engine est sélectionné pour la pré-traduction.

Modifier un BYO Engine

Pour modifier un BYO Engine, cliquez sur l’icône de modification sur la vignette du moteur.

Supprimer un BYO Engine

Pour supprimer un BYO Engine :

Cliquez sur l’icône de modification sur la vignette du moteur.
Cliquez sur Supprimer le BYO Engine.

FAQ

Q :	Pourquoi la requête de statut est-elle requise ? Est-elle envoyée par Phrase au moteur, ou est-ce au client de la gérer ?
R :	Phrase envoie la requête pour vérifier si le moteur fonctionne ou non.
Q :	Une requête peut contenir 500 `maxItems` dans `segments`. Cela implique-t-il que 500 phrases sources doivent être traduites en temps réel ?
R :	Les appels synchrones et asynchrones acceptent tous deux de 1 à 500 segments. En pratique, les appels synchrones depuis l’éditeur contiennent un seul segment, tandis que les flux de travail via l’API et les traitements par lots (pré-traduction, analyse) peuvent en envoyer jusqu’à 500. Le flux asynchrone est soumis à la même limite ; seule la soumission de la tâche est séparée de la récupération du résultat. Le délai d’expiration des requêtes asynchrones est d’environ 30 minutes. Nous ne basculons pas automatiquement du mode synchrone au mode asynchrone si votre adaptateur rejette une requête. Pour en savoir plus sur ce qu’il faut attendre de Phrase (nombre de segments, test de validation du moteur, nouvelles tentatives et délais), consultez le guide du BYO Engine.
Q :	Tous les termes d'un glossaire sont-ils envoyés dans une requête ou seulement un sous-ensemble ?
R :	Tous les termes du glossaire sont envoyés.
Q :	Est-il possible de connecter un LLM ?
R :	Cela devrait être possible avec une couche d’adaptation. Tant que le moteur renvoie des segments tels que définis dans le schéma, Phrase ne nécessite pas de moteur ou de LLM spécifique.
Q :	Une évaluation de la qualité (QE) personnalisée est-elle possible ?
R :	La QE tierce n'est pas prise en charge.
Q :	Comment les balises sont-elles gérées ?
R :	Le contenu reçu par Phrase est prétraité. Les balises HTML sont converties en marqueurs, qui sont ensuite transmis tels quels.
Q :	Pouvons-nous implémenter uniquement l'approche asynchrone ? Cela fonctionnera-t-il correctement dans toutes les fonctionnalités de Phrase (pré-traduction, éditeur, etc.) ?
R :	Non, les deux approches (idéalement tous les points de terminaison) doivent être implémentées. Le point de terminaison synchrone est utilisé, par exemple, par l’éditeur, tandis que le point de terminaison asynchrone est utilisé pour des fonctionnalités telles que la pré-traduction.
Q :	Que se passe-t-il lorsque le moteur reçoit plusieurs requêtes en même temps ?
R :	Le moteur doit être capable de gérer cela. Veillez à gérer correctement les accès concurrents et à garantir la sûreté des threads pour tous les points de terminaison, en particulier les points de terminaison asynchrones.
Q :	Comment fonctionnent les métadonnées de requête ?
R :	Les métadonnées de requête, configurées en tant qu'étiquettes personnalisées dans la configuration de BYO Engine, prennent en charge des espaces réservés dynamiques qui sont résolus avant que la requête n'atteigne l'adaptateur : `{project_uid}`, `{job_uid}` et `{idm_organization_uid}`. Par exemple, une étiquette personnalisée avec la clé `project_uid` et la valeur `{project_uid}` envoie l'UID réel du projet Phrase TMS à l'adaptateur. La résolution des espaces réservés s'applique uniquement à l'intérieur des valeurs textuelles. Un espace réservé inconnu est envoyé à l'adaptateur tel quel, sans résolution.
Q :	Comment fonctionnent les métadonnées de segment ?
R :	Actuellement, elles doivent faire partie du schéma.
Q :	Lors du traitement par traduction automatique, le BYO Engine utilise-t-il le RAG pour récupérer du contexte ?
R :	Non, BYOE n’utilise pas le RAG. Les utilisateurs peuvent exploiter les mémoires de traduction pour déterminer quels segments sont traduits, mais celles-ci ne sont pas utilisées dans le processus de traduction automatique lui-même. En effet, les moteurs de traduction automatique doivent être spécialement conçus pour intégrer les données des mémoires de traduction à l’aide du RAG. Or, dans les scénarios BYOE, il n’est pas possible de maîtriser la conception ni la configuration de ces moteurs.

Référence du schéma de l'adaptateur

L'adaptateur doit renvoyer des réponses qui correspondent exactement aux noms de champs et aux valeurs d'énumération suivants. Toute incompatibilité entraîne une erreur générique INTERNAL_ERROR renvoyée par Phrase, même si l’adaptateur renvoie une réponse 200 OK.

POST /status doit renvoyer un champ status avec une valeur d'énumération strictement en minuscules, soit ok, soit not_ok. Exemple : { "status": "ok" }
POST /languages doit renvoyer un tableau languagePairs (camelCase), chaque entrée contenant un champ sourceLanguage et un champ targetLanguage. Exemple : { "languagePairs": [ { "sourceLanguage": "en", "targetLanguage": "es" } ] }
POST /translate et GET /translateAsyncResult/{id} doivent renvoyer des champs de premier niveau sourceLanguage et targetLanguage, ainsi qu'un tableau segments où chaque segment inclut à la fois un champ text (le texte source renvoyé) et un champ translatedText. Le renvoi du seul champ translatedText, ou l'utilisation d'un nom de clé différent, provoque un échec de désérialisation.
POST /translateAsync ne nécessite qu'un champ id dans sa réponse. Un champ status ne fait pas partie de ce schéma de réponse et est ignoré s'il est présent.
GET /translateAsyncStatus/{id} doit renvoyer un champ status contenant l’une des trois valeurs d’énumération suivantes : running si la tâche est en cours de traitement, done si elle s’est terminée avec succès ou failed si elle a échoué. Si la tâche a échoué, un champ facultatif detail peut décrire la cause de l’échec. Exemples de valeurs : { "status": "running" }, { "status": "done" }, { "status": "failed", "detail": "Description of translation failure" }